软件测试 | 针对看起来很小的代码错误执行后续测试

当发现编码错误时，程序所处状态时程序员不想要或可能没有料到的。数据现在也可能时预期不可能的值。如果在第一次失效后继续使用这个程序，任何情况都有可能发生。

如果看到的时小失效，不要只是重视该失效并写入报告。程序处于脆弱状态，尝试利用这一点，继续测试，并可能发现内部缺陷的实际影响时糟糕得多的失效，例如系统崩溃或数据损坏。

我们建议尝试三种后续测试：

变化自己的行为（通过改变操作方式改变条件）。例如，让程序不断反复进入失效状态。有积累影响吗？尝试与该任务相关的失效操作。例如，当在屏幕上增加两个数字时，如果程序意外地稍微上移一点显示，则尝试测试这种缺陷是否影响加法或影响数字。尝试与该失效相关的操作。如果失效时在做了加法处理后显示意外上移，可尝试先上移显示再做加法。尝试刷新屏幕然后再做加法。尝试重新定义数字显示的尺寸后再做加法。也可以尝试更快速地输入数字，或以某种方式改变测试活动的速度。当然，还可以尝试各种其他探索式测试手段。有时这种方法很有用：与运行很多无关的其他测试，直接在不重新启动或重新设置的情况下继续使用程序。

变化程序选项和设置（通过改变被测程序改变条件）。典型的变化时使用不同的数据库、改变持久变量的取值、改变程序使用内存的方式，或改变程序允许测试员修改的任何其他选择（任何其他选项或偏好或设置）。在屏幕上移例子中，也许可以改变程序的窗口尺寸、要显示的数字精度或拼写检查器的背景活动设置。

变化软件和硬件环境（通过改变与被测程序一起运行的软件或正在使用的硬件改变条件）。这不是配置测试，不是要检查标准配置上的缺陷，而是要调查怎样变更配置才会使得这个失效暴露充分。例如，如果认为时序可能时个因素，就使用不同速度的处理器或视频显示或通信连接。如果认为内存可能有关，就使用内存较少（或较多）的计算机，或改变虚拟内存设置。

后续测试可以一直进行下去。应该做多少呢？对于每个认为反应了编码错误的失效（没有体现程序员意愿的代码）至少要做几分钟的后续测试。

对于有些失效要多做一些后续测试，可能需要一天的时间。要相信自己的判断。如果认为再做一些测试可能会发现有价值的新信息，就继续测试。如果认为现在对该缺陷的了解，通过继续测试也不会再深入了，就停止这种测试，并编写错误报告。要相信自己的判断。

搜索微信公众号：TestingStudio 霍格沃兹的干货都很硬核