测试模式点滴：验证模式

准备实践自动化测试的朋友可以看看这本书：XUnit Test Patterns——Refactoring Test Code，及其网站http://xunitpatterns.com/。估计国内还没有译本。书的内容不错，只是倾向于单元测试，还糅合了其它诸如“反测试模式”（文中称为bad smells，大概如同code complete里面描述的bad smells差不多，只是这里从自动化测试代码的角度而言）的内容。我对测试模式比较感兴趣，就采摘一些与大家共享。

前面谈论了各种准备和清理的模式，实际上还没接触到测试的根本目的，也就是，软件功能到底有没有bug。一般的测试用例分别从两个角度实现这个目的，要么是找错，要么是确认没有错，可以统称为验证。这里我们来看看各种验证的测试模式。

l  状态验证

需要测试的代码在接受一系列输入之后，内部状态会处于某一种组合。状态验证的出发点就是检查这些状态是不是符合预期。这个方法假定检查到的状态能反映软件功能实现与否。有时候这个假定不见得可靠。比如说，一个用HTML表示的表格，可能每个表格里面的值都是正确的，但是显示出来不见得就是预期效果，例如<table>标签的属性可能不对，或者页面其它部分把表格覆盖了也有可能。这种模式的好处是状态在很多情况下是比较容易获取，坏处是它不见得能证明软件功能没有问题。当然了，如果状态都不对，软件功能肯定有问题，所以它可以用来找错。

l  行为验证

软件总是表现一定的行为，例如都需要产生输出。行为验证的出发点就是检查预期的行为有没有出现。与状态验证不一样的是，它并不在乎内部状态是怎么样，转而关注外部表现，例如界面，与其它系统的通信，与操作系统的交互，等等。如果用一个前台是web，后台是数据库的软件系统为例，后台适用于状态验证，前台适用于行为验证。

行为验证相对状态验证要困难一些，因为行为往往可以表达为一系列相关的状态，自然要比状态验证要复杂一些。有时软件的行为还是跟时间和空间密切相关的，例如媒体播放器或者视频游戏等，这种情况下自动的验证要困难得多。

l  后门验证

一个软件的内部状态不见得是能被测试程序访问的。如果在内部留有后门那就不一样。有一些测试软件就实现了这些目的。比如Visual Studio的工具集里面有个Spy++，能够得到指定Windows窗口上处理过的消息，这就是一个利用Windows消息钩子的后门验证模式例子；又比如从Internet Explorer 8开始捆绑的一个工具F12开发人员工具，能够获取IE所显示的页面的HTML结构，CSS内容和IE与web服务器通信的内容，这也是利用IE留出的MSHTML COM接口的后门验证模式例子。在后门验证模式的帮助下，状态验证模式可以比较方便的实现。

l  门卫断言验证

断言（assertion）的目的是在某个状态不如预期的时候立即引起注意。如同状态验证模式的特点，验证过了不代表没有问题，不过则代表一定有问题。所以门卫断言验证就是一种找错的模式。举个例子，电子地图的行车路线功能可以从众多内部状态上分别验证，但是可以用比较简单的方法：两地之间的行车路线总长应该落在一个合理范围以内，例如从直线距离到横向和纵向距离之和之间。这个断言不通过且功能没问题的概率太低了。

l  差别断言验证

软件在不同或者先后输入的条件下的输入往往是有关联的，如果某一情况下各个状态准确验证有困难，使得状态验证不容易实现的话，检验这些关联，简称为差别断言验证，也是一种办法。还是以电子地图的行车路线为例，如果甲地到乙地的路线为A，乙地道甲地的路线为B，那么两条路线可能因为单行路的关系有差别，但是总长的差别也不应该相差太远，或者各段路线也不应相差太多。这个断言不通过且功能没问题的概率也是很低的。