测试何时终止？--质量评估

  测试同学应该都有过类似经历，这个项目测到什么时候可以结束？这个迭代已经没有缺陷了是否可以上线了？相信有一部分同学都是靠感觉，或是项目倒排期，如果有点儿要求的可能会做到以下场景：

• 场景一：项目计划时间到了，就发布产品。
• 场景二：将缺陷修复率作为产品的质量目标，产品必须达到一定的缺陷修复率，才能发布；
• 场景三：为产品建立了很多指标来作为质量目标，如：缺陷修复率、测试代码覆盖率等，产品必须达到制定的质量目标，才能发布；

分析

• 场景一说明测试团队当前还没有产品质量评估的具体办法，于是只有将“时间”作为底线。
• 场景二和场景一相比，已经有了判断标准，可以说是有质的改变，但其评价标准太过于单一。而对一个产品来说，要想对它的质量进行客观准确的评价，要结合质量六属性、开发过程及测试过程，单纯通过一个指标很难判断准确；
• 场景三看起来很好，但在实际操作时，费时费力对这些指标进行统计、分析和跟踪，最后都达到了，但是对产品质量的好坏依然感到心里没底。

解决方案

  一个优秀的产品质量评估模型，应具备如下特质：

• 多维度：能够覆盖质量评估的各个纬度，能够帮助评估者全面分析和考虑。
• 定量+定性：指标和分析相结合，能够有效避免在只有指标的情况下，被“绕”过去，变得形同虚设。
• 过程+结果：不仅评估测试的结果，还对过程进行分析和评估。

软件产品质量评估模型

测试覆盖度评估：对测试范围及测试的深度与广度进行分析和评估。
测试过程评估：对测试过程和测试的投入情况来进行分析与评估。
缺陷分析：对测试结果进行分析和评估。

image.png

剖析

需求覆盖度评估：需求覆盖度是“已经测试验证的产品需求数”和“产品需求规格总数”的比值。
需求覆盖度的目标必须是100%，即测试保证对产品承诺要实现的需求都进行了验证，并要对产品是否满足需求给出评估。

代码覆盖度评估：代码覆盖度是“已经测试到的代码数量”和“程序中可执行语句的总数量”的比值。此覆盖度可通过工具进行统计；
代码覆盖度分为：全量覆盖率和差异覆盖率，根据项目的不同，设置不同的测试通过条件。比如：新项目，全量覆盖率要在90%，并说明未覆盖到的原因；迭代项目，差异覆盖率要达到80%，并说明未覆盖到的原因。

测试用例分析：通过测试用例执行率、测试用例执行通过率、测试用例和非测试用例发现缺陷比，进行测试用例分析；
进入到测试阶段后，每天应该有测试过程的评估产出，对于测试阻塞（指测试用例因为产品开发「一般指缺陷」、测试「如测试环境不具备」等原因，无法被执行的测试用例）这种情况，测试需要提前识别这些问题，进行风险识别和控制。

测试方法分析：在测试之前，测试就需要根据产品的质量要求，根据测试目标、测试的深度和广度来确定测试方法；在测试用例评审时，保证各个特性使用的测试方法和测试策略相符，可以通过测试执行时的日报、周报，测试用例执行情况等方式去跟踪和分析。

测试投入分析：测试投入分析主要从测试人员安排和测试投入工作量来进行分析，确认重要的、高风险的特性能够保证测试投入，符合测试策略。

缺陷密度分析：缺陷密度是指每千行代码发现的缺陷数。确定了缺陷密度后，还可以顺带得到缺陷总数。通过缺陷密度，可以帮助我们评估当前已经发现的缺陷总数是否足够多。如果缺陷密度和预期偏差较大，原则上不应该退出测试，发布产品。

缺陷修复情况分析：缺陷修复率是指产品“已经修复解决的缺陷总数”和“已经发现缺陷总数”的比值。缺陷修复率能够帮助我们确定当前产品发现的缺陷是否被有效修复，为当前的产品质量是否达到测试质量目标提供最直接的判断依据。在测试开始时应该就确定缺陷修复率目标，如果最终缺陷修复率不能达到预期，原则上不应该退出测试，发布产品。

缺陷趋势分析：缺陷趋势是指“随着测试时间的进行，测试发现的缺陷趋势和开发解决缺陷的趋势”。进行此项分析的重要原因在于：缺陷趋势分析能够帮助我们判断当前系统是否还能很容易地发现缺陷，进而确定是否可以退出测试，发布产品。

缺陷年龄分析：进行缺陷年龄分析，能够确认每个可能引入缺陷环节、可能引入的缺陷是否都已经被有效去除。

image.png

未完待续。。。。。。