另外还有一个值得考虑的现象，就是相对于自动化测试而言，一个优秀的测试人员在人工测试时是如何判断功能正确与否的呢？他不会死板的只盯着某几个输入域的值，他一定还会同时关注页面上所有数据的正确性、会更加关注业务流程是否正确、会更敏锐的发现页面样式或UI逻辑类的缺陷。
为了兼顾“证明软件正常运行”和“人性化的识别软件缺陷”，一个优秀的测试工具应该考虑提供以下多种断言机制。
一、控件级细粒度断言即前面提到的最常见的断言方式。在测试过程中，可以在任何位置增加断言脚本，来判断页面指定控件是否存在、控件显示值是否为预期结果等。通常建议只对关键校验点进行断言。
二、页面级粗粒度断言通过对比前（之前测试通过）后（后续持续发布）版本在测试用例路径和输入参数相同的情 况下，整个页面内容（包括截图和数据）是否严格相同来做粗粒度断言。
通过页面截图进行断言有两个实现要点：首先要选择一个合适的截图方案（笔者推荐采用Selenium WebDriver提供的TakesScreenshot接口）；其次需要提供图片对比工具，以便测试人员可以一眼看出两个版本页面截图的差异。
下面是笔者在测试框架中实现的截图自动化对比功能的实际效果。下图中左侧部分是“实际结果截图”、右侧是“预期结果截图”、中间部分是差异对比，测试人员一眼便可看出其中的Bug：“表格行选中的翻页缓存（在当前页选中几条记录，翻到下一页再翻回本页，需要保持之前的行选中状态）功能丢失了”。
通过页面数据进行断言的实现方式相对简单一些，首先要提取页面上所有的数据（或文本），接着进行格式化，然后再自动化对比。 “页面级粗粒度断言”的特点及应用场景如下：
● 无需编写任何断言语句；
● 需要能够提供可用于自动对比的历史正确版本，特别适用于可以持续构建的项目；
● 能判断出UI样式和UI逻辑类的错误；
● 由于对比绝对精准，导致可能存在误判，因此需要人工对差异图片进行排查； 【注】由于很多Web页面都有渐入渐出、点击时按钮变色等很炫的效果，所以在两次截图的瞬间可能页面的动态样式是不一样的，这就是所谓的“误判”。笔者对于一个“动态样式”适中的项目采用这种断言方式，统计结果表明误判率在20%左右。
● 鉴于回归测试的时候，通常大部分用例应该是可以通过的，所以“页面级粗粒度断言”的投入产出比非常占优势！
三、 基于业务逻辑断言在测试设计时把有依赖关系的用例一起执行，如果某个步骤出现问题，即便不设置任何断言语句，在当前步骤或后续步骤的测试用例也会执行失败。下面以“增加、查询、修改、删除”这个最典型的流程来说明（如下图所示）。
假定在“增加”环节出现问题，那么我们的测试用例执行情况可能出现如下几种结果：
1、如果在“增加记录A”的用例中包含对是否增加成功的断言，那么测试用例从“增加记录A”开始出错；
2、如果在“增加记录A”中不包含断言，而是在“查询A”的用例中包含是否有查询结果的断言，那么测试用例会从“查询A”开始出错；
3、如果在“查询A”中也不包含断言，那么测试用例会从“修改查询结果”开始出错。
所谓“基于业务逻辑断言”，就是指上述第三种情况，其特点及应用场景如下：
● 无需编写任何断言语句，但测试设计要考虑业务逻辑顺序；
● 与“页面级粗粒度断言”相比，不需要提供可用于对比的历史正确版本，通常适用于项目刚开发或样式做整体调整等情况；
● 断言错误的位置不精准，可能延后；
● 执行过程每一步都做截图备份（通过Selenium WebDriver可以很方便的实现），可以非常有效的辅助定位准确的出错原因；
● 鉴于回归测试的时候，通常大部分用例应该是可以通过的，所以“基于业务逻辑断言”的投入产出比非常占优势！
四、自定义扩展断言在人工测试时经常有些操作结果的正确与否在当前页面无法做出判断，需要到其它页面甚至系统外部（比如，数据库、输出日志）获取信息来做出判断。以最常见的“基于数据库进行断言”为例，测试工具需要支持把断言时用到“预期结果”和“实际结果”配置为对应的SQL语句。
以上介绍了从测试工具的角度可以提供的多种断言机制，在自动化测试过程中应该根据项目实际情况，考虑采用上述多种断言的组合，以弥补控件级细粒度断言的不足。
本系列文章至此，已经分享了如何降低测试脚本的编写、维护成本，如何在不失测试有效性的前提下减少断言成本。改善上述两大问题之后，自动化测试基本上就可以比较顺利的开展了。接下来如何让自动化测试的价值最大化呢？答案就是频繁的执行测试脚本。因此下一步要做的就是持续集成（或者称为每日构建）。下一篇文章会分享一个由测试团队主导的持续集成案例，敬请关注！
原文：http://www.infoq.com/cn/articles/Agile-test-automation-3
相关链接：
