慢测试

众所周知，对某些风险估计的不充分和突然的变化往往会使得本来就不宽裕的项目开发时间雪上加霜，进度的压力如滚雪球般堆积到软件开发的后期。到了测试阶段，为了消化掉前期的延时保证按时交付，测试从一开始执行就背负着时间的压力往前冲。但是一直都在高速奔跑的状态下，当速度成为一种惯性时，思维往往也有惯性。测试中一味的高速反而对质量是一种损害，有时我们也需要“慢测试”，即测试人员刻意放慢输入和点击的速度，边想边看边测。

1． 与exploratory testing的关系

“慢测试”与exploratory testing（探索性测试）在某些理念上有相通之处。因为探索性测试强调在学习中不断深入对被测试软件的理解，从而执行更有效的测试。测试中知识的积累和任何知识的积累一样都有一个学习曲线，不可能一蹴而就。人的测试和monkey testing 的区别在于我们进行的是更有目的性和明确预期的活动。不然，飞快地随便点点即使能出几个bug，又有什么意义呢？测试更象地雷战，我们的任务是对前进途中不得不经过的地方（如基本路径）和我们认为可能雷区最集中的地方（如复杂路径和特殊数据）清除最危险的地雷（缺陷）。风险低的地方我们胆子大一点，可以走得快一点，查得少一点。风险高的地方必须一步一个脚印，慢慢看，仔细查，“快”不是我们追求的目标。

但慢测试又有些不象探索性测试。它本身不是一种单独的测试方法，而只是一种理念，希望提醒人们能注意对测试节奏的把握。通常“慢测试”发现的缺陷并不少，有时甚至会发现更多或者更严重的但隐藏更深的问题。所以慢测试并不意味着低效率和少缺陷。通过快慢测试节奏的配合和转换，测试的效率和有效性往往能达到更佳的一个状态。

2． 何时特别需要慢测试

虽然我提倡任何一个较大的版本（如测试时间超过4周）都最好能快慢测试相结合，但有一些情况下慢测试的好处更明显。如测试一个全新的或者不熟悉的模块时，对质量要求很高，或者已经对某版本进行过几轮速测试，测试时间还有，但测试人员有点黔驴技穷的感觉时等等。

3． 如何做慢测试

（1）      磨刀法：测试执行时花些时间再次讨论和澄清一些需求、设计和实现的细节。这些精力看似拖慢了测试的进度，其实磨刀不误砍柴功。在稍长一点的一个时间范围来看，对测试效率和产品质量绝对是有帮助的。

（2）      头脑风暴法：不看系统，头脑中迅速过一遍：近期改动最多的地方在哪里？可能还有缺陷的地方在哪里？前期我的测试流程、数据和入口是否还有遗漏的？与上下游模块的耦合是否已经充分测试？一些边边角角的功能是否已经测试了？。。。如此，想必已经大致有个概念知道如何跳出前期自己测试的框框，在后续测试中继续一探究竟。

（3）      贴身盯人法：测试执行时不再飞速地输入和点击，而是慢下来，仔细盯着每个页面，特别注意一些小字段和细节逻辑，并刻意尝试改变惯用的操作顺序去执行意图的业务流程。

今日得到工作中的启发，仓促之中成文，想必还有许多可以补充之处，欢迎指正。