自动化测试异常处理与用例管理.docx

自动化测试异常处理与用例管理.docx

《自动化测试异常处理与用例管理.docx》由会员分享，可在线阅读，更多相关《自动化测试异常处理与用例管理.docx（23页珍藏版）》请在冰豆网上搜索。

自动化测试异常处理与用例管理

测试用例的前置条件和后置条件

除了第二点中谈到的数据需要准备外，在测试用例这个Level，必须有一些条件满足，您才能开始执行它。

比如准备一个初始设置条件下的IE浏览器和已安装过老版本该软件的XP系统。

这些可重用的准入条件，可以考虑不作为特定用例的Step，而是把它提取出来，作为SetupSection或叫Pre-Condition。

对于后置条件或Post-condition，往往我们用它来做一些处理或恢复，比如在上面的取款例子中，如果我们要用相同的帐号重复测试，在正

好取完所有金额，余额为零的情况下，可以通过一些步骤或数据库脚本重置帐号余额。

同样，您为某个用例设置浏览器禁用了Cookie，执行完该用例后，是不是也是需要回复到默认设置的状态呢？

集中的把这些步骤整理成一个相对独立的操作单元，具体用例中只要引用就可以了，这样会便于对用例的理解和在多处复用。

顺便说一下，对于一些类似软件运行环境的条件，比如安装和配置测试中，需要3种操作系统和3种浏览器的组合等，我们可以把他放在

TestSet这个Level上来，不用写多个用例，只是在测试计划和执行的管理系统中作为测试集的一个环境参数，恰当地表达出来就可以。

4.常用业务操作（KnowledgeBase）

对于一个大型的应用，比如银行系统，开发和测试工作是长期的，持续的一个过程，这样的系统很适合引入自动化测试。

它业务逻辑复杂，测试技术性要求高，往往使用了不同厂商的工具和多种脚本语言（如Shell，Python等），也存在了很多可用的遗留脚本。

这些完成一些预定业务操作的脚本单元，是可以直接借用的。

为了在公司和产品层面，管理好这些可复用的资源，一种好的方式是给它们标上号，如KB_PRJ01_Module02_XXX，集中管理起来，以后的用例中只要调用即可。

举例来说，在银行业务测试中我们，需要模拟和银联的接口，让测试帐号向外汇款，取得响应信息，并保存结果，这可能是个复杂而底层

的处理过程，对一般员工是不需要，也没有权限去深入掌握的。

这时，将他们包装成一个个Shell脚本或小工具，做好使用说明和统一建档，在以后的项目测试中，只要调用就可以了。

如此，可以大大提高各个有相关接口的模块的自动化测试工作效率。

根据以往工作中常见的一些问题，对于如何写好测试用例（不仅针对自动化测试），做以下做几点补充：

推荐不推荐

将用例的内容描述清楚，强调怎么操作，验证什么，然后期待的结果是什么。

Copy需求和设计文档中的内容；描述成：

什么条件下，逻辑会是怎样。

这样对测试用例的阅读和执行人员，不具有可操作性。

期待的结果要写具体，如：

系统反应是什么；结果数字是多少；用户被带到什么页面；显示什么成功信息；后台或数据库中该记录的修改后结果是怎么样的。

描述成：

”验证系统返回正确结果“；”页面元素显示跟SPEC一致“；”操作成功“等比较抽象的说法。

自动化测试用例设计的原则

很多公司在实施自动化测试的过程中，往往会把所有的手工测试用例作为自动化测试用例，并且直接进行脚本的开发工作，甚至有些公司不写自动化测试用例，直接想当然地开发测试脚本，这些都是极其不规范的做法，甚至很有可能

是导致最后自动化测试项目失败的最大原因。

那么问题就来了，为什么不能使用手工测试用例完全替代自动化测试用例呢？

有以下几点原因，同时也是自动化测试用例的设计原则

●原则1：

自动化测试用例的范围往往是核心业务流程或者重复执行率较高的。

在选取自动化测试用例范围时，很多测试工程师或者上级领导可能心里会过分依赖自动化测试，会认为自动化测试就应该覆盖所有的手工测试用例，自动化测试的覆盖率就应该达到百分之百。

其实恰好相反，这样的想法往往会导

致自动化测试最终失败。

在一些大型项目中，往往测试用例的数量会很庞大，而且如果遇到一些繁杂的被测程序（特

别是C/S架构），脚本开发工作往往会相当耗时间，并且很多测试用例甚至根本就不能通过自动化来实现。

举些例子，现在很多公司自动化测试都是刚起步，对自动化测试的了解程度只是停留在字面上，在公司对测试也不是非常重视的情况下，当然不太愿意去花精力招一个具有自动化测试开发经验的工程师，很多还是停留在使用工具的录制回放功能来完成自动化测试。

正是存在这样的技术限制情况下，往往在实施中，会出现很多录制回放不能解决的问题，测试工具完全无法识别测试对象，无法识别一些特殊的加密测试控件。

还有，如果项目的变更频率，测试用例数量大的话，增

加了后期的维护工作量等，都是造成最终失败的一些隐患。

投入越大，损失越大。

因此，往往我们会选取最核心的一些业务路径或者是重复执行率较高的一些手工测试用例进行自动化测试，这样能够充分发挥出自动化测试的优势。

●原则2：

自动化测试用例的选择一般以“正向”为主。

手工测试用例分正常情况和异常情况，在设计的时候，可能往往会去设计很多异常情况来验证程序是否有Bug，并且一个正常情况的测试用例往往会对应几十个非正常情况的测试用例，而每种异常情况的测试用例都会有各种各样的

预期结果。

在自动化测试中，很多人喜欢将正常情况称为“正向”；反之，异常情况则称为“反向”。

下面，我们试想以下，如果将这些异常情况全部转化、反应到自动化测试脚本中，那肯定需要非常繁琐的判断才能做到。

这个对于自动化测试工程师来说，其现有的工作量还是今后的脚本维护量都是不可小视的。

对于整个自动化测试项目来说，如果每个异常

情况都要写进脚本中，那真的是花了大价钱买一堆小东西，小东西真正能发挥大作用的毕竟很少。

因此，真正在自动化测试项目实施中，往往会舍弃反向用例，个别比较重要的除外。

使每个东西都能发挥其最大的作用才是企业最想看

到的。

功能自动化测试主要还是用于回归测试，回归测试的目的就是保证新增功能后老功能是否能够正常继续运作。

而自动化测试则是让测试人员从繁琐又枯燥的重复手工测试中解放出来，这就是目的和目标。

原则3：

不是所有手工测试用例都可以使用自动化测试来实现的。

这里纠正许多测试从业人员的一个错误观念，刚接触测试自动化的普遍都会认为手工测试用例全部要转化为自动化测试用例，但是在真正实施的时候，却发现很多测试用例是自动化无法实现的，或者有些测试用例根本就没有必要

去自动化的。

例如，有些用例会牵涉到硬件设备辅助的，最简单的例子就是用例执行过程中需要使用刷卡机才能获取卡号信息（如果有技术能力，当然不排除自行开发接口供测试工具调用，但毕竟能有技术实力做到这一步的不多，能有

这样的重视程度的更不多）；再比如，有些测试用例是需要与合作机构进行互动联调，联调时是需要和对方实时沟通，

以及根据具体情况给予响应的，这些情况多数还是只能使用手工人为地来完成。

当然，决定是否转化为自动化测试，必须事先有一个规范文档来定义哪些是需要转化为自动化测试哪些是不需要的，否则测试工程师就会不知所措，没有

一个标准。

一旦有了这个标准，自动化测试工程师就可以严格按照文档里的流程去完成需要转化部分的自动化测试用例

的脚本开发工作了。

原则4：

手工测试用例可以不用回归原点，而自动化用例往往是必须的。

很多有经验的自动化测试从业人员一定有这样的经历，很多时候脚本写完后，第一次执行没有任何问题，而第二次执行时立刻就会报错，原因就是没有回归原点。

所谓回归原点就是执行的测试用例最终需要恢复其在执行前的初始

状态，如果没有回归原点，就会把此脚本称之为死脚本。

举个最简单的例子，比如添加用户功能，我们都知道每个用

户名都是唯一的，当写完一个添加用户的脚本之后，执行第一次没有问题，因为执行前此用户还不存在，但是当执行第二次时，程序就会出现用户重复而报错，此时这个添加用户的脚本就失去了它的价值，在这种情况下，我们就需要在

自动化测试用例的最后加上删除这个用户的步骤，这样在下次执行用例时就不会出现用户重复的情况了。

当然，除了回归原点，还可以使用另一种方式进行，那就是初始化数据，比如ATM机取款，假设需要执行取款100元的操作，而银行卡余额是120元，当测试脚本第一次执行时可能没有任何问题，但是第二次系统就会报余额不足，这样就成为了

死脚本，解决方案有两种：

一种是直接进行初始化数据，每次执行用例之前都重置下余额（只需大于100即可）；第

二种方法可以在用例执行前，先查询下余额是否大于100，若大于等于则继续，若小于则做一笔充值100的操作，这样即可解决。

两种方式可以看具体情况使用，数据初始化方便，但有时候初始化之后可能会影响到其他自动化测试用例

的执行，而第二种方式相对在脚本上需要稍微花点功夫。

究竟使用哪种方式还需要具体情况具体分析。

总之，在执行自动化测试用例之前做好数据准备，这也是自动化测试的关键步骤。

原则5：

自动化测试用例和手工测试用例不同，不需要每个步骤都写预期结果。

在手工测试用例的设计过程中，几乎每一个测试步骤都有一个预期结果。

但是，在自动化测试用例的设计中并不

试的人应该都会有这样的体会：

“大部分断言在大部分情况下只是佐证软件是运行正常的”。

当然，所有人都应该是非常期待看到这样的结果，毕竟谁也不希望每次回归测试时都是用例大面积不通过。

只是辛辛苦苦写这些断言语句的测试人员心里未免有些“小遗憾”。

本系列上篇文章中谈到“很多人一提到自动化测试脚本，马上就想到需要提供录制工具”，但如果换个角度思考，很可能就是“柳暗花明又一村”。

在这里，我们同样换个角度思考，假设我们的自动化测试主要目标是为了证明软件运行正常，那么我们会怎么做？

笔者这边的一个经验就是“按照完整的业务流程来组织测试用例，只对少量、必要的关键点进行断言”。

以“租户对虚拟化资源的申请使用”为例，来具体看看测试用例的组织方式：

1.新租户注册；

2.管理员登录系统，对注册租户进行审批，然后退出系统；

3.审批后的租户登录系统；

4.租户申请所需要的虚拟化资源（比如，40G硬盘、2核CPU、2G内存），然后退出系统；

5.管理员登录系统，对租户申请的资源进行审批，然后退出系统；

6.租户登录系统，在已申请资源的基础上创建安装指定操作系统的虚拟机；

7.断言虚拟机是否创建成功；

8.租户退出系统；

9.管理员登录系统，删除租户；

10.断言租户之前申请的资源是否被完全释放；

11.租户再次登录系统，断言是否无法登录；

上述测试用例就是按照完整的业务流程进行组织，并且只对少量关键点（7、10、11）进行断言，如果整个用例可以运行通过，就能证明这个业务是没有问题的。

通过页面数据进行断言的实现方式相对简单一些，首先要提取页面上所有的数据（或文本），接着进行格式化，然后再自动化对比。

“页面级粗粒度断言”的特点及应用场景如下：

无需编写任何断言语句；

需要能够提供可用于自动对比的历史正确版本，特别适用于可以持续构建的项目；能判断出UI样式和UI逻辑类的错误；

由于对比绝对精准，导致可能存在误判，因此需要人工对差异图片进行排查；【注】由于很多Web页面都

有渐入渐出、点击时按钮变色等很炫的效果，所以在两次截图的瞬间可能页面的动态样式是不一样的，这就

是所谓的“误判”。

笔者对于一个“动态样式”适中的项目采用这种断言方式，统计结果表明误判率在20%左右。

鉴于回归测试的时候，通常大部分用例应该是可以通过的，所以“页面级粗粒度断言”的投入产出比非常占优势！

三、基于业务逻辑断言

在测试设计时把有依赖关系的用例一起执行，如果某个步骤出现问题，即便不设置任何断言语句，在当前步骤或后续步骤的测试用例也会执行失败。

下面以“增加、查询、修改、删除”这个最典型的流程来说明（如下图所示）。

假定在“增加”环节出现问题，那么我们的测试用例执行情况可能出现如下几种结果：

1.如果在“增加记录A”的用例中包含对是否增加成功的断言，那么测试用例从“增加记录A”开始出错；

2.如果在“增加记录A”中不包含断言，而是在“查询A”的用例中包含是否有查询结果的断言，那么测试用例会从“查询A”开始出错；

3.如果在“查询A”中也不包含断言，那么测试用例会从“修改查询结果”开始出错。

所谓“基于业务逻辑断言”，就是指上述第三种情况，其特点及应用场景如下：

无需编写任何断言语句，但测试设计要考虑业务逻辑顺序；

与“页面级粗粒度断言”相比，不需要提供可用于对比的历史正确版本，通常适用于项目刚开发或样式做整体调整等情况；

断言错误的位置不精准，可能延后；

执行过程每一步都做截图备份（通过SeleniumWebDriver可以很方便的实现），可以非常有效的辅助定位准确的出错原因；

鉴于回归测试的时候，通常大部分用例应该是可以通过的，所以“基于业务逻辑断言”的投入产出比非常占优势！

四、自定义扩展断言

在人工测试时经常有些操作结果的正确与否在当前页面无法做出判断，需要到其它页面甚至系统外部（比如，数据库、

输出日志）获取信息来做出判断。

以最常见的“基于数据库进行断言”为例，测试工具需要支持把断言时用到“预期结果”和“实际结果”配置为对应的SQL语句。

以上介绍了从测试工具的角度可以提供的多种断言机制，在自动化测试过程中应该根据项目实际情况，考虑采用上述多种断言的组合，以弥补控件级细粒度断言的不足。

ASP.NETMVC集成EntLib实现“自动化”异常处理[实例篇]

个人觉得异常处理对于程序员来说是最为熟悉的同时也是最难掌握的。

说它熟悉，因为仅仅就是try/catch/finally而已。

说它难以掌握，则是因为很多开发人员却说不清楚try/catch/finally应该置于何处？

什么情况下需要对异常进行日志记录？

什么情况下需要对异常进行封装？

什么情况下需要对异常进行替换？

对于捕获的异常，在什么情况下需要将其再次抛出？

什么情况下则不需要？

合理的异常处理应该是场景驱动的，在不同的场景下，采用的异常处理策略往往是不同的。

异常处理的策略应该是可配置的，因为应用程序出现怎样的异常往往是不可预测的，现有异常策略的不足往往需要在真正出现某种异常的时候才会体现出来，所以我们需要一种动态可配置的异常处理策略维护方式。

目前有一些开源的异常处理框架提供了这种可配置

的、场景驱动的异常处理方式，EntLib的ExceptionHandlingApplicationBlock（以下简称EHAB）就是一个不错的选择。

[源代码从这里下载][本文已经同步到《HowASP.NETMVCWorks?

》中]

一、通过指定Handle-Error-Action响应请求二、通过ErrorView显示错误消息

三、自动创建JsonResult响应Ajax请求

一、通过指定Handle-Error-Action响应请求

在正式介绍如何通过扩展实现与EntLib以实现自动化异常处理之前，我们不妨先来体验一下异常处理具有怎样的“自动化”特性。

以用户登录场景为例，我们在通过VisualStudio的ASP.NETMVC项目模板创建的Web应用中定义了如下一个简单的数据类型LoginInfo封装用户登录需要输入的用户名和密码。

1:

publicclassLoginInfo

2:

3:

{

[DisplayName（"用户名"）]

4:

[Required（ErrorMessage="请输入{0}"）]

5:

publicstringUserName{get;set;}

6:

7:

[DisplayName（"密码"）]

8:

[Required（ErrorMessage="请输入{0}"）]

9:

10:

[DataType（DataType.Password）]

publicstringPassword{get;set;}

11:

}

然后我们定义了如下一个HomeController。

基于HTTP-GET的Action方法Index将会呈现一个用户登录View，该View使用创建的LoginInfo对象作为其Model。

真正的用户验证逻辑定义在另一个应用了HttpPostAttrubute特性的Index方法中：

如果用户名不为Foo，抛出InvalidUserNameException异常；如果密码不是“password”，则抛出InvalidPasswordException异常。

InvalidUserNameException和InvalidPasswordException是我们自定义的两种异常类型。

1:

[ExceptionPolicy（"defaultPolicy"）]

2:

publicclassHomeController:

ExtendedController3:

{

4:

publicActionResultIndex（）5:

{

6:

returnView（newLoginInfo（））;

7:

}

8:

9:

[HttpPost]

10:

[HandleErrorAction（"OnIndexError"）]

11:

publicActionResultIndex（LoginInfologinInfo）12:

{

13:

if（string.Compare（loginInfo.UserName,"foo",true）!

=0）

14:

{

15:

thrownewInvalidUserNameException（）;16:

}

17:

18:

if（loginInfo.Password!

="password"）

19:

{

20:

thrownewInvalidPasswordException（）;21:

}

22:

returnView（loginInfo）;

23:

}

24:

25:

[HttpPost]

26:

publicActionResultOnIndexError（LoginInfologinInfo）27:

{

28:

returnView（loginInfo）;

29:

}

30:

}

上面定义的HomeController具有三点与自动化异常处理相关的地方：

HomeController继承自自定义的基类ExtendedController，后者完成了对异常的自动化处理。

HomeController类型上应用了自定义的ExceptionPolicyAttribute特性用于指定默认采用的异常处理策略名称

（“defaultPolicy”）。

基于HTTP-POST的Index方法上应用了HandleErrorActionAttribute特性用于指定一个Handle-Error-Action名称，当异常在目标Action执行过程中抛出并通过EHAB处理后，指定的Action会被执行以实现对请求的响应。

对于我们的例子来说，从Index方法抛出的异常被处理后会调用OnIndexError方法作为对当前请求的响应。

下面是代表登录页面的View的定义，这是一个Model类型为LoginInfo的强类型View。

在该View中，作为Model的LoginInfo对象以编辑默认呈现在一个表单中，表单中提供了一个“登录”提交表单。

除此之外，View中还具有个ValidationSummary。

1:

@modelLoginInfo

2:

3:

4:

5:

6:

.validation-summary-errors{color:

Red}

7:

8:

9:

10:

@using（Html.BeginForm（））

11:

{

12:

@Html.ValidationSummary（true）

13:

@Html.EditorForModel（）

14:

15:

}

16:

17:

通过HomeController的定义我们知道两种不同类型的异常（InvalidUserNameException和InvalidPasswordException）分别在输入无效用户名和密码是被抛出来，而我们需要处理的就是这两种类型的异常。

正对它们的异常处理策略定义在

如下的配置中，策略名称就是通过应用在HomeController上的ExceptionPolicyAttribute特性指定的“defaultPolicy”。

1:

2:

3:

4:

type="Microsoft.Practices.EnterpriseLibrary.ExceptionHandling.Configuration.ExceptionHandlingSettings,Microsoft.Practices.EnterpriseLibrary.ExceptionHandling"/>

5:

6:

7:

8:

9:

10:

11:

12:

13:

14:

15:

16:

17:

18: