敏捷自动化测试(7)

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

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

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

　　当然，所有人都应该是非常期待看到这样的结果，毕竟谁也不希望每次回归测试时都是用例大面积不通过。只是辛辛苦苦写这些断言语句的测试人员心里未免有些“小遗憾”。

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

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

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

　　1)新租户注册;

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

　　3)审批后的租户登录系统;

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

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

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

　　7)断言虚拟机是否创建成功;

　　8)租户退出系统;

　　9)管理员登录系统，删除租户;

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

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

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

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

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

　　一、 控件级细粒度断言

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

　　二、 页面级粗粒度断言

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

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

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

　　通过页面数据进行断言的实现方式相对简单一些，首先要提取页面上所有的数据(或文本)，接着进行格式化，然后再自动化对比。 “页面级粗粒度断言”的特点及应用场景如下：

原文转自：http://www.uml.org.cn/Test/201307154.asp