这两天在重温Rex Black 写的《软件测试实践》这本书，对其中反应测试方法有点体会，分享一下。这里借用了不少书中的术语。

　　反应测试（reactive test）是一种动态的测试方法，能够发现边界值、等价类和正交表等静态测试方法可能遗漏的缺陷。做反应测试比较难的是这种测试方法会依赖于测试者的技能和直觉，来自相似应用的经验，以及来自相似技术的经验。在反应测试开始前，没有预先进行高度细节化的设计，也就是说没有具体的测试用例，这些测试用例都是在测试之中进行具体化的。

　　说到这里，一定会有人认为反应测试就是探索测试或者随机测试。但是不然，反应测试中的确包含了探索测试，但绝对不是随机测试或者说是毫无计划的即兴测试。反应测试通常会使用到以下的方法：缺陷归类法（bug taxonomy），一个常见的系统弱点或过去成功的攻击的列表，一个缺陷围猎方法（bug hunting）、一套测试章程（test charter）和一个清单（checklist）。

　　对反应测试的两个挑战是工作量和工作时间的估计和对测试覆盖率的跟踪。对于挑战一，可以使用固定时间的方法，就是先初步的预估一个时间，按照这个时间去执行，然后根据执行的情况再去确定剩下的时间。例如安排了2个小时去测试一个功能点，在测试两个小时后，根据发现的缺陷的数量来决定还需要多久的测试。这里先不讨论挑战二，因为下面的一些方法会解答这个问题。

　　还是需要说明的一点，反应测试不是随机测试，它是有的放矢的，那么第一个方法就是缺陷归类。通过测试者的经验和对系统的熟悉，猜测可能会出现的缺陷，把这些缺陷在一个列表上记录下来，那么攻击（James Whittaker 《如何攻破软件》中提出）就是对猜想的尝试。如果以前有成功的攻击列表当然也是可以借鉴的。

　　第二个方法就是缺陷围猎。这个方法是建立第一步的基础之上的，因为做完第一步，第二步才是有鱼可捕，有鸟可猎。这个时候，你对缺陷的敏感可能会指引你从一个缺陷找到另外一个缺陷，就像聪明的猎人总是能从一只鸟找到一群鸟一样。

　　第三个方法就是探索性测试。我个人觉得这是对第二个方法的具体的实施，探索式测试做起来可要比说起来难多了。因为探索性测试很容易让测试者偏离测试的方向。

　　第四个方法就是清单。把你所做的反应测试用清单列出来，这样就不至于陷入到为了找缺陷而找缺陷的陷阱中。测试不是为了找缺陷，而是帮助项目管理风险。所以可以把反应测试和预先设计，编写好的测试用例结合执行。

　　最后打一个小小的比方，纯属杜撰。如果把测试方法比作一个帮派的武功的话，那边界值和等价类就像是少林和武当的罗汉拳和八卦掌，那反应测试就像是杨过的黯然销魂掌。