如何建立有效的软件测试准则?

如何建立有效的软件测试准则?

典型的既无意义，也不能实现目标的两个测试结束准则：

1用完了安排的测试时间后，测试便结束。

第一条准则没有任何作用，因为可以什么都不做就能满足它。它并不能衡量测试的质量。第二条准则同样无用。因为它与测试用例的质量无关，而且也不能实现测试目标，它下意识里鼓励编写发现错误可能性较低的测试用例。

下面有三类较为有用的结束准则：

第一类，但不是最佳的准则，根据的是特定的测试用例设计技术。

例如对于模块测试：测试用例来源于(1)满足多重条件覆盖准则(2)对模块接口规格说明进行边界值分析，产生的所有测试用例最终都是不成功的。

对于功能测试：测试用例来源于(1)因果图分析(2)边界值分析(3)错误猜测，产生的所有测试用例最终都是不成功的。

第二类，也许也是最有价值的准则，是以确切的数量来描述结束测试的条件。如Bug数量或测试时间。

用好这类准则要解两个问题。一个问题是判断如何获得要发现的错误数量。这需要进行下面几个预测：

1)预测出程序中错误的总数量。

2)预测这些错误中有多大比例可能通过测试而发现。

3)预测这些错误中有多少是由各个设计阶段产生的，以及在什么样的测试阶段能够发现这些问题。

可以通过几种方法来大致预测错误的总数。一种方法是利用以前程序的经验来预测出数字。另外，还存在多种预测模型。还有一种获得预计数字的粗略方法是使用行业范围内的平均值。在编码结束时(进行代码走查或检查之前)，一般程序中的错误数量大致是每100行语句中含4～8个错误。

第二个预测包含一定程度的随意猜测，考虑了程序的性质以及未发现的错误造成的后果。

第三个预测最为困难。现有的数据表明，在大型程序中，大约有40%的错误是编码和逻辑设计错误，剩下的错误则产生于早期的设计阶段。

另一个明显问题是过度地预测。

所以如果在测试周期内没有发现预测的错误数目，项目经理可以聘请一个局外人来分析测试用例，判断问题究竟是测试用例不足，不是测试用例很棒却没什么错误可发现。

第三类结束准则需要我们在测试过程中记录每单位时间内发现的错误数量。通过检查统计曲线的形状(趋势是增长还是下降收敛)常常可以决定究竟是继续该阶段的测试，还是结束它并开始下一测试阶段。

最佳的结束准则可能是上述三种类型的组合。

对于模块测试而言，特别是由于多数项目在此阶段没有正式跟踪已发现的错误，最佳的结束准则可能是第一类。

而对于功能测试和系统测试而言，结束准则可能是发现了既定数量的错误，或用完了计划的时间，再出现什么都不管，但条件是错误分析与时间图的对比表明测试的效率已经很低了.