测试结果的精准性

测试结果的精准性

一，True Positive(TP)。当软件存在缺陷时，测试用例失败。这是一种期望结果。

二，True Negative(TN)。当软件不存在缺陷时，测试用例成功。这也是一种期望结果。

三，False Positive(FP)。当软件不存在缺陷时，测试用例失败。这不是一种期望结果，因为出现了误报。

四，False Negative(FN)。当软件存在缺陷时，测试用例成功。这也不是一种期望结果，因为出现了漏报。

根据这四个术语，可以衍生出一系列度量测试结果精准性的指标，例如：正确率(accuracy, TP+TN / TP+TN+FP+FN)，精度(precision，TP / TP+FP)，召回率(recall, TP / TP+FN)等。这些指标各有长处和不足，我们暂且不展开讨论。

这些指标有一个共同点，那就是如果要得到优化，需要从减少False Postive或False Negative两类非期望的测试结果着手。那么，这两类测试结果分别有什么危害，又应该如何减少呢?

先看False Positve，即误报缺陷的情况。误报的危害主要两个。一是浪费大家的时间和精力，去分析原本并不存在的缺陷;二是降低了测试结果的公信力。这就好比"狼来了"的故事，当测试结果经常出现误报时，大家会对测试失去耐心和信任，而后果可能是真正的缺陷被忽视。

如何减少False Positive的情况?一方面，我们需要设计好测试的前置条件，只有前置条件全部满足了，我们才开始正式执行测试步骤。另一方面，我们需要提高测试环境，测试依赖库和测试脚本的质量与稳定性，让它们足够健壮和可靠。

再看False Negative。从某种程度上说，False Negative是比False Positive更严重的结果。漏报缺陷，最好的结果是我们能在后续测试阶段发现它，而最坏的结果是缺陷一直到软件部署后，用户规模使用时才爆发，从而造成巨大的商业损失。

如何减少False Negative的情况?一种常见做法是借鉴"变异测试"的思想，故意在软件中插入错误代码，然后观察测试用例是否发生期望之中的失败。在测试驱动开发(TDD)和探索性测试中，这种做法经常被使用。另外，为了提高测试覆盖面，还可以随机化数据或参数，以验证软件是否能够在无数的输入组合下工作。

这里，针对False Positve和False Negative两种异常结果，简要介绍了各自的应对方法。从根本上说，要提高测试结果精准性，要做好以下两项长期性工作。

一，在设计和实现测试用例时，提高思维的严谨性。多思考和反问一个基本问题，那就是如果软件失败，测试用例是否能够检测得到?是否应该添加更多的检验条件和规则?

二，在项目实施过程中，做好测试监控工作。基于大量测试用例历史执行数据，我们可能发现许多改进测试的机会。例如，对那些永远都不失败的测试用例，需要考虑其存在的合理性;对于在同一个软件版本上时而成功时而失败的测试用例，需要分析其背后的原因。

以上就是我对精准测试，尤其是如何提高测试结果的精准性的一点思考。总的来说，精准测试挑战大，问题多，这篇文章只是开了一个头而已。