测试模式点滴:验证模式

准备实践自动化测试的朋友可以看看这本书: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内容和IEweb服务器通信的内容,这也是利用IE留出的MSHTML COM接口的后门验证模式例子。在后门验证模式的帮助下,状态验证模式可以比较方便的实现。

l 门卫断言验证

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

l 差别断言验证

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

你可能感兴趣的:(游戏,windows,单元测试,软件测试,IE)