敏捷自动化测试（3）——让断言再也不成为自动化测试的负担

    做者: 殷坤  来源: InfoQ

　　在本系列的第一篇文章“咱们的测试为何不够敏捷”中，根据实例总结出敏捷自动化测试的两大阻碍：“脚本维护困难”、“断言条件繁琐”。本文针对在不失自动化测试有效性的前提下如何下降断言成原本分享一些实践经验。

　　目前业界常见的自动化测试工具在断言方面大多都是采用“指哪儿打哪儿”的细粒度模式，即，在自动化测试过程当中只能对设置为断言条件的字段（页面元素）进行断言。并且这些测试工具即便提供录制脚本的功能，但对于断言每每还须要测试人员手工补充插入。

　　除了补充、维护断言条件的工做量大以外，这种断言模式还存在一些明显的不足，下面结合一个实际的例子（以下图）进行分析：

• 没法感知未设为断言对象的字段上发生的错误

  以上图为例，若是在“增长用户”的测试脚本以后只对列表中的“用户姓名是否存在” 进行断言，那么就可能遗漏“入职日期没有提交成功”的错误。并且因为页面的信息量每每很大，咱们是不可能对全部字段都设置为断言条件的。

• 难以对于UI样式或UI逻辑进行断言

  以上图为例，有一个UI样式类的缺陷（左侧菜单树的根节点“console”下面多出来一条虚 线）和一个UI逻辑类的缺陷（右侧用户列表只有一页，但“下一页”和“最后一页”图标依然是能够点击的，即没有灰显）。此类缺陷即便对于经验丰富、心思缜 密的测试人员，在人工测试时也是极可能发现不了的，而且在自动化测试过程当中也很难进行断言。

　　即便存在上述问题，测试脚本中是否有充分的断言，依然是评判自动化测试有效性的一个重要指标。但实施过自动化测试的人应该都会有这样的体会：“大部分断言在大部分状况下只是佐证软件是运行正常的”。

　　固然，全部人都应该是很是期待看到这样的结果，毕竟谁也不但愿每次回归测试时都是用例大面积不经过。只是辛辛苦苦写这些断言语句的测试人员内心未免有些“小遗憾”。

　　本系列上篇文章中谈到“不少人一提到自动化测试脚本，立刻就想到须要提供录制工具”，但若是换个角度思考，极可能就是“柳暗花明又一村”。

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

　　笔者这边的一个经验就是“按照完整的业务流程来组织测试用例，只对少许、必要的关键点进行断言”。以“租户对虚拟化资源的申请使用”为例，来具体看看测试用例的组织方式：

1. 新租户注册；
2. 管理员登陆系统，对注册租户进行审批，而后退出系统；
3. 审批后的租户登陆系统；
4. 租户申请所须要的虚拟化资源（好比，40G硬盘、2核CPU、2G内存），而后退出系统；
5. 管理员登陆系统，对租户申请的资源进行审批，而后退出系统；
6. 租户登陆系统，在已申请资源的基础上建立安装指定操做系统的虚拟机；
7. 断言虚拟机是否建立成功；
8. 租户退出系统；
9. 管理员登陆系统，删除租户；
10. 断言租户以前申请的资源是否被彻底释放；
11. 租户再次登陆系统，断言是否没法登陆；

　　上述测试用例就是按照完整的业务流程进行组织，而且只对少许关键点（七、十、11）进行断言，若是整个用例能够运行经过，就能证实这个业务是没有问题的。

　　另外还有一个值得考虑的现象，就是相对于自动化测试而言，一个优秀的测试人员在人工测试时是如何判断功能正确与否的呢？他不会死板的只盯着某几 个输入域的值，他必定还会同时关注页面上全部数据的正确性、会更加关注业务流程是否正确、会更敏锐的发现页面样式或UI逻辑类的缺陷。

　　为了兼顾“证实软件正常运行”和“人性化的识别软件缺陷”，一个优秀的测试工具应该考虑提供如下多种断言机制。

　　1、 控件级细粒度断言

　　即前面提到的最多见的断言方式。在测试过程当中，能够在任何位置增长断言脚本，来判断页面指定控件是否存在、控件显示值是否为预期结果等。一般建议只对关键校验点进行断言。

　　2、 页面级粗粒度断言

　　经过对比前（以前测试经过）后（后续持续发布）版本在测试用例路径和输入参数相同的情 况下，整个页面内容（包括截图和数据）是否严格相同来作粗粒度断言。

　　经过页面截图进行断言有两个实现要点：首先要选择一个合适的截图方案（笔者推荐采用Selenium WebDriver提供的TakesScreenshot接口）；其次须要提供图片对比工具，以便测试人员能够一眼看出两个版本页面截图的差别。

　　下面是笔者在测试框架中实现的截图自动化对比功能的实际效果。下图中左侧部分是“实际结果截图”、右侧是“预期结果截图”、中间部分是差别对 比，测试人员一眼即可看出其中的Bug：“表格行选中的翻页缓存（在当前页选中几条记录，翻到下一页再翻回本页，须要保持以前的行选中状态）功能丢失 了”。

　　经过页面数据进行断言的实现方式相对简单一些，首先要提取页面上全部的数据（或文本），接着进行格式化，而后再自动化对比。 “页面级粗粒度断言”的特色及应用场景以下：

• 无需编写任何断言语句；
• 须要可以提供可用于自动对比的历史正确版本，特别适用于能够持续构建的项目；
• 能判断出UI样式和UI逻辑类的错误；
• 因为对比绝对精准，致使可能存在误判，所以须要人工对差别图片进行排查； 【注】因为不少Web页面都有渐入渐出、点击时按钮变色等很炫的效果，因此在两次截图的瞬间可能页面的动态样式是不同的，这就是所谓的“误判”。笔者对 于一个“动态样式”适中的项目采用这种断言方式，统计结果代表误判率在20%左右。
• 鉴于回归测试的时候，一般大部分用例应该是能够经过的，因此“页面级粗粒度断言”的投入产出比很是占优点！

　　3、 基于业务逻辑断言

　　在测试设计时把有依赖关系的用例一块儿执行，若是某个步骤出现问题，即使不设置任何断言语句，在当前步骤或后续步骤的测试用例也会执行失败。下面以“增长、查询、修改、删除”这个最典型的流程来讲明（以下图所示）。

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

1. 若是在“增长记录A”的用例中包含对是否增长成功的断言，那么测试用例从“增长记录A”开始出错；
2. 若是在“增长记录A”中不包含断言，而是在“查询A”的用例中包含是否有查询结果的断言，那么测试用例会从“查询A”开始出错；
3. 若是在“查询A”中也不包含断言，那么测试用例会从“修改查询结果”开始出错。

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

• 无需编写任何断言语句，但测试设计要考虑业务逻辑顺序；
• 与“页面级粗粒度断言”相比，不须要提供可用于对比的历史正确版本，一般适用于项目刚开发或样式作总体调整等状况；
• 断言错误的位置不精准，可能延后；
• 执行过程每一步都作截图备份（经过Selenium WebDriver能够很方便的实现），能够很是有效的辅助定位准确的出错缘由；
• 鉴于回归测试的时候，一般大部分用例应该是能够经过的，因此“基于业务逻辑断言”的投入产出比很是占优点！

　　4、 自定义扩展断言

　　在人工测试时常常有些操做结果的正确与否在当前页面没法作出判断，须要到其它页面甚至系统外部（好比，数据库、输出日志）获取信息来作出判断。以最多见的“基于数据库进行断言”为例，测试工具须要支持把断言时用到“预期结果”和“实际结果”配置为对应的SQL语句。

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

　　本系列文章至此，已经分享了如何下降测试脚本的编写、维护成本，如何在不失测试有效性的前提下减小断言成本。改善上述两大问题以后，自动化测试 基本上就能够比较顺利的开展了。接下来如何让自动化测试的价值最大化呢？答案就是频繁的执行测试脚本。所以下一步要作的就是持续集成（或者称为每日构 建）。