静态案例设计与动态案例设计

在传统的软件开发周期中，测试员反馈软件的bug,再用已经完成的测试案例，针对修复的软件进行验证。在这种测试流程中，测试案例的设计是固定的，在软件验证过程中，我们期望error counter 逐渐减少，甚至为零。但是，这种案例设计的弱点，就是这些固定的案例，只能验证发现的具体问题是否改正，， 一般来说，我们在某个功能发现了问题，这个功能就有可能有更多的问题。使用固定的案例，在regression test 过程中，测试的涵盖范围已经缩小了（如果开发员为了项目进度，只针对发现问题的特定案例，来修改程序，那么，我们用同样的案例来检验这个错误，其实已经是无效的了。）

这个问题，我们可以用“动态案例”设计来解决：当测试发现软件的错误后，我们应该针对发现的问题，设计更多的案例，用既有的案例，加上新设计的案例，针对开发员的修复版本，在进行验证，就不会出现如上所说的问题了。当然，这个方法，也有它的弱点，测试的工作量会变大，在一定程度上，也会增加测试成本和测试周期。由于增加测试案例是基于既有案例的，这种工作量一般不会太大，相较减小测试覆盖率而增加的风险，我们这么做还是值得的。