自动化测试异常处理与用例管理系统Word文档格式.docx
《自动化测试异常处理与用例管理系统Word文档格式.docx》由会员分享，可在线阅读，更多相关《自动化测试异常处理与用例管理系统Word文档格式.docx（22页珍藏版）》请在冰豆网上搜索。
系统反应是什么；
结果数字是多少；
用户被带到什么页面；
显示什么成功信息；
后台或数据库中该记录的修改后结果是怎么样的。
”验证系统返回正确结果“；
”页面元素显示跟SPEC一致“；
”操作成功“等比较抽象的说法。
业务逻辑性较强的应用软件，做到以业务流为主线，来组织用例。
以页面形式组织用例。
以Module、Function、测试类型、基本业务流、备选业务流的树状结构形式，分层次组织用例；
使用用例管理工具。
Word格式的扁平组织结构，不利于管理和阅读。
用一个属性字段，建立用例和Spec等文档的某个章节间的映射。
无法和需求对应，以后难以计算用例覆盖率，测试执行覆盖率。
每个Module、Function、特定业务的一组测试用例，之间做到独立、没有耦合。
用例之间有依赖，无法做到：
挑选30%的用例做回归测试。
在时间和成本允许的情况下，尽量做到：
用例粒度为“一种不同的操作，得到不同的结果，就单独写一个用例“。
在用例中的操作步骤中，甚至期待结果中，仍然存在条件分支。
对于复杂的业务操作过程，如”一次顺序的表单签核过程“和”一次完整的信贷手续“，单独增加一些贯穿整个业务流的大型测试用例。
对于一个长业务操作，只存在比较零散的细节用例。
将用例分优先等级，便于在回归测试时挑选核心业务或用户操作密集的用例。
用例没有优先级和重要程度的定义。
自动化测试用例设计的原则
很多公司在实施自动化测试的过程中，往往会把所有的手工测试用例作为自动化测试用例，并且直接进行脚本的开发工作，甚至有些公司不写自动化测试用例，直接想当然地开发测试脚本，这些都是极其不规范的做法，甚至很有可能是导致最后自动化测试项目失败的最大原因。
那么问题就来了，为什么不能使用手工测试用例完全替代自动化测试用例呢？
有以下几点原因，同时也是自动化测试用例的设计原则
●
原则1：
自动化测试用例的范围往往是核心业务流程或者重复执行率较高的。
在选取自动化测试用例范围时，很多测试工程师或者上级领导可能心里会过分依赖自动化测试，会认为自动化测试就应该覆盖所有的手工测试用例，自动化测试的覆盖率就应该达到百分之百。
其实恰好相反，这样的想法往往会导致自动化测试最终失败。
在一些大型项目中，往往测试用例的数量会很庞大，而且如果遇到一些繁杂的被测程序（特别是C/S架构），脚本开发工作往往会相当耗时间，并且很多测试用例甚至根本就不能通过自动化来实现。
举些例子，现在很多公司自动化测试都是刚起步，对自动化测试的了解程度只是停留在字面上，在公司对测试也不是非常重视的情况下，当然不太愿意去花精力招一个具有自动化测试开发经验的工程师，很多还是停留在使用工具的录制回放功能来完成自动化测试。
正是存在这样的技术限制情况下，往往在实施中，会出现很多录制回放不能解决的问题，测试工具完全无法识别测试对象，无法识别一些特殊的加密测试控件。
还有，如果项目的变更频率，测试用例数量大的话，增加了后期的维护工作量等，都是造成最终失败的一些隐患。
投入越大，损失越大。
因此，往往我们会选取最核心的一些业务路径或者是重复执行率较高的一些手工测试用例进行自动化测试，这样能够充分发挥出自动化测试的优势。
●
原则2：
自动化测试用例的选择一般以“正向”为主。
手工测试用例分正常情况和异常情况，在设计的时候，可能往往会去设计很多异常情况来验证程序是否有Bug，并且一个正常情况的测试用例往往会对应几十个非正常情况的测试用例，而每种异常情况的测试用例都会有各种各样的预期结果。
在自动化测试中，很多人喜欢将正常情况称为“正向”；
反之，异常情况则称为“反向”。
下面，我们试想以下，如果将这些异常情况全部转化、反应到自动化测试脚本中，那肯定需要非常繁琐的判断才能做到。
这个对于自动化测试工程师来说，其现有的工作量还是今后的脚本维护量都是不可小视的。
对于整个自动化测试项目来说，如果每个异常情况都要写进脚本中，那真的是花了大价钱买一堆小东西，小东西真正能发挥大作用的毕竟很少。
因此，真正在自动化测试项目实施中，往往会舍弃反向用例，个别比较重要的除外。
使每个东西都能发挥其最大的作用才是企业最想看到的。
功能自动化测试主要还是用于回归测试，回归测试的目的就是保证新增功能后老功能是否能够正常继续运作。
而自动化测试则是让测试人员从繁琐又枯燥的重复手工测试中解放出来，这就是目的和目标。
原则3：
不是所有手工测试用例都可以使用自动化测试来实现的。
这里纠正许多测试从业人员的一个错误观念，刚接触测试自动化的普遍都会认为手工测试用例全部要转化为自动化测试用例，但是在真正实施的时候，却发现很多测试用例是自动化无法实现的，或者有些测试用例根本就没有必要去自动化的。
例如，有些用例会牵涉到硬件设备辅助的，最简单的例子就是用例执行过程中需要使用刷卡机才能获取卡号信息（如果有技术能力，当然不排除自行开发接口供测试工具调用，但毕竟能有技术实力做到这一步的不多，能有这样的重视程度的更不多）；
再比如，有些测试用例是需要与合作机构进行互动联调，联调时是需要和对方实时沟通，以及根据具体情况给予响应的，这些情况多数还是只能使用手工人为地来完成。
当然，决定是否转化为自动化测试，必须事先有一个规范文档来定义哪些是需要转化为自动化测试哪些是不需要的，否则测试工程师就会不知所措，没有一个标准。
一旦有了这个标准，自动化测试工程师就可以严格按照文档里的流程去完成需要转化部分的自动化测试用例的脚本开发工作了。
原则4：
手工测试用例可以不用回归原点，而自动化用例往往是必须的。
很多有经验的自动化测试从业人员一定有这样的经历，很多时候脚本写完后，第一次执行没有任何问题，而第二次执行时立刻就会报错，原因就是没有回归原点。
所谓回归原点就是执行的测试用例最终需要恢复其在执行前的初始状态，如果没有回归原点，就会把此脚本称之为死脚本。
举个最简单的例子，比如添加用户功能，我们都知道每个用户名都是唯一的，当写完一个添加用户的脚本之后，执行第一次没有问题，因为执行前此用户还不存在，但是当执行第二次时，程序就会出现用户重复而报错，此时这个添加用户的脚本就失去了它的价值，在这种情况下，我们就需要在自动化测试用例的最后加上删除这个用户的步骤，这样在下次执行用例时就不会出现用户重复的情况了。
当然，除了回归原点，还可以使用另一种方式进行，那就是初始化数据，比如ATM机取款，假设需要执行取款100元的操作，而银行卡余额是120元，当测试脚本第一次执行时可能没有任何问题，但是第二次系统就会报余额不足，这样就成为了死脚本，解决方案有两种：
一种是直接进行初始化数据，每次执行用例之前都重置下余额（只需大于100即可）；
第二种方法可以在用例执行前，先查询下余额是否大于100，若大于等于则继续，若小于则做一笔充值100的操作，这样即可解决。
两种方式可以看具体情况使用，数据初始化方便，但有时候初始化之后可能会影响到其他自动化测试用例的执行，而第二种方式相对在脚本上需要稍微花点功夫。
究竟使用哪种方式还需要具体情况具体分析。
总之，在执行自动化测试用例之前做好数据准备，这也是自动化测试的关键步骤。
原则5：
自动化测试用例和手工测试用例不同，不需要每个步骤都写预期结果。
在手工测试用例的设计过程中，几乎每一个测试步骤都有一个预期结果。
但是，在自动化测试用例的设计中并不采用，在自动化测试用例中，只有准备在测试脚本中设置成检查点的步骤才有预期结果，其他所有的步骤只将它看作一个步骤，这样做的好处是一目了然、目的明显、层次分明，以后写测试脚本直接跟着自动化测试用例就行了。
因为经过前面的探讨应该已经知道，自动化测试中并不是所有的东西都需要验证的。
所以，作者在前面的章节中也提到过，基本上手工测试用例多多少少都要进行一些转换的，就是因为它们之间的格式是不一致的。
举一个简单的例子，假设需要设计一个注册页面的自动化测试用例，有10几个表单需要填写，在手工测试用例中，每个表单的填写都一定会有预期结果，因为它的确在检查每一项是对了还是错了，只是用的是你的眼睛在检查而已，所以速度非常的快，甚至你自己潜意识都忽略了其实你已经检查了。
但是，在自动化测试中，我们知道如果你要检查，那一定需要写代码，如果每项都检查，那代码量有多大是可想而知的，不是说做不到，只是这样做根本不符合自动化测试的特点。
所以，绝大部分时候，这些在自动化测试中可有可无的检查，我们全部“不检查”，只当做一个业务流程和步骤，是不需要设立预期结果的。
难以对于UI样式或UI逻辑进行断言
以上图为例，有一个UI样式类的缺陷（左侧菜单树的根节点“console”下面多出来一条虚线）和一个UI逻辑类的缺陷（右侧用户列表只有一页，但“下一页”和“最后一页”图标依然是可以点击的，即没有灰显）。
此类缺陷即使对于经验丰富、心思缜密的测试人员，在人工测试时也是很可能发现不了的，并且在自动化测试过程中也很难进行断言。
即使存在上述问题，测试脚本中是否有充分的断言，依然是评判自动化测试有效性的一个重要指标。
但实施过自动化测试的人应该都会有这样的体会：
“大部分断言在大部分情况下只是佐证软件是运行正常的”。
当然，所有人都应该是非常期待看到这样的结果，毕竟谁也不希望每次回归测试时都是用例大面积不通过。
只是辛辛苦苦写这些断言语句的测试人员心里未免有些“小遗憾”。
本系列上篇文章中谈到“很多人一提到自动化测试脚本，马上就想到需要提供录制工具”，但如果换个角度思考，很可能就是“柳暗花明又一村”。
在这里，我们同样换个角度思考，假设我们的自动化测试主要目标是为了证明软件运行正常，那么我们会怎么做？
笔者这边的一个经验就是“按照完整的业务流程来组织测试用例，只对少量、必要的关键点进行断言”。
以“租户对虚拟化资源的申请使用”为例，来具体看看测试用例的组织方式：
1.新租户注册；
2.管理员登录系统，对注册租户进行审批，然后退出系统；
3.审批后的租户登录系统；
4.租户申请所需要的虚拟化资源（比如，40G硬盘、2核CPU、2G内存），然后退出系统；
5.管理员登录系统，对租户申请的资源进行审批，然后退出系统；
6.租户登录系统，在已申请资源的基础上创建安装指定操作系统的虚拟机；
7.断言虚拟机是否创建成功；
8.租户退出系统；
9.管理员登录系统，删除租户；
10.断言租户之前申请的资源是否被完全释放；
11.租户再次登录系统，断言是否无法登录；
上述测试用例就是按照完整的业务流程进行组织，并且只对少量关键点（7、10、11）进行断言，如果整个用例可以运行通过，就能证明这个业务是没有问题的。
另外还有一个值得考虑的现象，就是相对于自动化测试而言，一个优秀的测试人员在人工测试时是如何判断功能正确与否的呢？
他不会死板的只盯着某几个输入域的值，他一定还会同时关注页面上所有数据的正确性、会更加关注业务流程是否正确、会更敏锐的发现页面样式或UI逻辑类的缺陷。
为了兼顾“证明软件正常运行”和“人性化的识别软件缺陷”，一个优秀的测试工具应该考虑提供以下多种断言机制。
一、控件级细粒度断言
即前面提到的最常见的断言方式。
在测试过程中，可以在任何位置增加断言脚本，来判断页面指定控件是否存在、控件显示值是否为预期结果等。
通常建议只对关键校验点进行断言。
二、页面级粗粒度断言
通过对比前（之前测试通过）后（后续持续发布）版本在测试用例路径和输入参数相同的情况下，整个页面内容（包括截图和数据）是否严格相同来做粗粒度断言。
通过页面截图进行断言有两个实现要点：
首先要选择一个合适的截图方案（笔者推荐采用SeleniumWebDriver提供的TakesScreenshot接口）；
其次需要提供图片对比工具，以便测试人员可以一眼看出两个版本页面截图的差异。
下面是笔者在测试框架中实现的截图自动化对比功能的实际效果。
下图中左侧部分是“实际结果截图”、右侧是“预期结果截图”、中间部分是差异对比，测试人员一眼便可看出其中的Bug：
“表格行选中的翻页缓存（在当前页选中几条记录，翻到下一页再翻回本页，需要保持之前的行选中状态）功能丢失了”。
通过页面数据进行断言的实现方式相对简单一些，首先要提取页面上所有的数据（或文本），接着进行格式化，然后再自动化对比。
“页面级粗粒度断言”的特点及应用场景如下：
∙无需编写任何断言语句；
∙需要能够提供可用于自动对比的历史正确版本，特别适用于可以持续构建的项目；
∙能判断出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:
密码"
8:
[Required（ErrorMessage="
9:
[DataType（DataType.Password）]
10:
publicstringPassword{get;
11:
然后我们定义了如下一个HomeController。
基于HTTP-GET的Action方法Index将会呈现一个用户登录View，该View使用创建的LoginInfo对象作为其Model。
真正的用户验证逻辑定义在另一个应用了HttpPostAttrubute特性的Index方法中：
如果用户名不为Foo，抛出InvalidUserNameException异常；
如果密码不是“password”，则抛出InvalidPasswordException异常。
InvalidUserNameException和InvalidPasswordException是我们自定义的两种异常类型。
[ExceptionPolicy（"
defaultPolicy"
publicclassHomeController:
ExtendedController
publicActionResultIndex（）
returnView（newLoginInfo（））;
[HttpPost]
[HandleErrorAction（"
OnIndexError"
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:
26:
publicActionResultOnIndexError（LoginInfologinInfo）
27:
28:
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对象以
升级会员 