关于Squish断言检查的添加方法，以及结果不稳定时的解决对策，自动化脚本虽然可以进行按钮的点击和内容的输入，但是这只能证明测试流程被跑通了，功能的最终结果是不是正确并不能被保证；所以在开展自动化测试的时候，断言检查是不能被缺少的；通常所说的Squish断言，其实更多的是指验证点，也就是把某个对象属性、表格数据、截图或者界面状态拿来检查，看看它们是不是和预期一样；关于如何把断言添加进去，以及结果不稳定要怎么处理，重点并不是要把检查点加得越多越好，而是测试人员要把它们加在关键的位置上，那些经常发生变化的内容需要被避开。

　　一、Squish断言检查怎么添加

　　在把断言添加进去之前，测试人员首先要把测试流程确认一下，看看系统是不是已经走到了需要检查的界面状态；比如在登录成功以后对用户名进行检查，或者在保存操作完成后对提示语进行核对，还有在查询结束以后去检查表格里的结果，这些位置才比较适合放置断言；如果页面还没有完全加载完，系统就急着开始检查，那么就算断言写得再怎么正确，误报的情况也还是会被触发的。

　　1、通过录制界面添加检查点

　　在进行脚本录制的时候，测试人员可以在Squish控制条里面去选择和验证相关的各种功能，然后利用对象拾取工具，把需要检查的控件选中；Squish不但支持通过集成开发环境的点选方式来把验证点创建出来，而且直接在脚本里用API编写断言的方式也是可行的，在实际的项目开发中，这两种办法可以被混合着使用。

　　2、在脚本里手动写断言

　　在对脚本进行后期整理的阶段，把关键的断言写清楚是更加被推荐的做法；比较经常被用到的是test.compare()以及test.verify()这两个函数；前面的函数更适合用来对比两个数值是不是相等的，后面的函数则更适合用来对一个布尔条件是不是真的进行判断；这些函数运行之后，成功或者失败的记录都会被写进Squish的测试日志里面。

　　3、根据对象类型选择检查方式

　　一般的按钮、输入框和标签，它们都挺适合被用属性断言来检查的；至于表格、列表还有树形节点，去检查它们的行数、单元格里面的数值以及关键列的内容是更合适的；只有当界面的布局发生变动、图标需要被显示、或者遇到复杂的控件样式时，截图或者视觉检查才需要被考虑进来；Squish里面也提供表格验证的功能，测试人员可以对整个表格或者类似的网格控件执行整体的验证，从而不需要把每个单元格的代码都手写一遍。

　　二、Squish断言检查结果不稳定怎么办

　　断言一会儿能通过、一会儿又失败，这通常gentleman并不是因为Squish系统在“随机捣乱”，而是因为测试人员没有把检查的条件写得足够稳妥；比较常见的原因可以被分成三类，分别是对象还没有刷新完毕、预期的数值自己会发生改变、以及检查的范围被扩大得太大了。

　　1、先确认是不是等待时机问题

　　很多不稳定的断言情况都和等待的时间有关系；比如把查询按钮点击了以后，表格对象虽然已经能够被系统找到了，但是数据其实还在刷新的过程中；如果脚本紧接着就去对行数做检查，那么结果可能一会儿是0，一会儿又是完整的数量；`waitForObject()`这个函数等待的是对象可以被访问，也就是说它只管对象存在、能看见并且可以用，但是控件被等到了，并不代表里面的数据内容也已经被刷新完了。

　　2、动态内容不要做死匹配

　　断言不稳定的另一个很平常的原因，就是测试人员把那些动态的内容写成了固定的死数值；比如时间戳、订单的号码、文件的路径、运行花掉的时间、还有随机产生的数据，这些内容在每一次执行的时候都可能是不同的；所以它们是不能被直接拿来做完全相的判断的。

　　更加稳妥的办法是测试人员只把核心的业务数值拿来检查；比如查询的结果里面虽然有10列，大家不一定把每一列都加上断言，可以把重点放在检查名称、状态、金额和数量这些关键的字词上；而像时间、流水号这一类字段，格式能被检查通过就可以了，不需要去检查它具体的数值。

　　3、截图和视觉断言要控制环境差异

　　图片类的断言是最容易被测试环境所影响的；屏幕的分辨率、系统的字体、主题的样式、浏览器、平台、动态的数据、还有界面样式的变动，这些都可能把视觉上的差异带过来；Squish的视觉验证在文档里也被明确指出了会受到这些因素的干扰，像屏幕的尺寸、字体、系统的主题、平台以及动态的数据，都会把像素的结果搞得出现偏差。

　　三、断言维护时要注意哪些问题

　　断言并不是被加得越多就越安全的；如果断言太少，脚本就仅仅是在“跑个流程”；要是断言太多了，又会把测试用例变得特别脆弱，只要有一点点没关系的变动就会导致失败；比较合适的方法，就是测试人员要围绕着业务的最终结果来把关键的断言加上去。

　　1、关键的结果检查需要在每个流程里被保留

　　比如在登录的流程里，测试人员要检查主界面是不是被成功进入了；在保存的流程里，要检查成功提示有没有弹出来，以及数据是不是真的被写进了系统；在删除的流程里，则要检查目标数据是不是不再被列表显示了；测试人员不要每点击一下按钮就把一个断言加进去，如果这样做的话，后期的维护成本就会被抬得很高。

　　2、失败的日志需要被写得清楚一些

　　在用手写断言的时候，测试人员可以把一些上下文的信息加到失败提示里面；比如不要只让日志显示“比较失败”，而是要让人能看出来究竟是“保存的提示和预期不符”还是“查询出来的结果是空的”；在后期需要大批量去跑回归测试的时候，这一类信息能够把很多排查的时间给节省下来。

　　3、断言失败后要先对是业务问题还是脚本问题做出判断

　　断言发生失败并不一定是一件糟糕的事，它可能真的是把软件的缺陷给找出来了；在进行排查的时候，测试人员不要马上就把断言修改了，而是应该先把被测系统的实际界面状态看一看；要是功能的结果本来就不对，那这就是产品的问题；如果是界面表现正确但是断言却失败了，测试人员再去对对象识别、等待的条件、动态的数据以及预期的数值进行检查。

总结

　　从整体上来看，关于Squish断言检查怎么添加，以及Squish断言检查结果不稳定怎么办这两个问题，关键的地方可以用一句话来概括：断言要把业务的结果检查好，而不要总是盯着那些容易改变的表面内容；属性断言需要被优先使用，表格断言要对关键的数据进行选择，截图断言要把环境的差异控制住，然后再把合适的等待条件配合起来，这样脚本才能既把问题发现出来，又不会让误报天天发生。