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

hobli

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

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

hapliu

如果是系统测试的话，发现问题后由开发人员进行修改，如果依然有此错误继续修改，如果此错误解决的话，要从新全面的测试，因为这个功能的缺陷使很多相关的错误隐藏，当把此错误修改后这些错误就会显露出来，要进行重新的详细的测试，而您说的正是功能的错误，正好符合这种情况/
      只测试错误的地方，。发现问题解决就提交PASS，是严重得不负责的做法，很可能影响到软件的质量和用户的投诉，软件的性能，及公司的形象

hobli

首先，谢谢您的关注！

我所说的问题，并不局限于系统测试。还有一个问题我要澄清一下，就是说我强调的是“动态的案例设计”，也就是说，如果发现了问题，提交后得到修复的新版本，测试员应该不仅用所有执行过的已有的案例来测试（也就是说，不仅测试发现错误的地方，而是这是您所说的全面测试），而且应该针对所犯错误相应的增加新的案例。即所谓“动态”设计。