3条测试用例设计原则，实现持续集成测试

1. 可靠性

以任何频率运行的任何测试用例都必须可靠&＃xff1b;也就是说&＃xff0c;测试用例不能是片状的。考虑自动检查&＃xff1a;在持续集成环境中&＃xff0c;这个测试用例每天可能会为单个团队运行数十或数百次。
 

如果测试只有 99% 的可靠性&＃xff08;每100次测试执行中有一个错误报告&＃xff09;&＃xff0c;并且您每天运行 200 次&＃xff0c;那么您的团队每天将至少调查两次误报失败。将其乘以可以包含数万个测试用例的单元测试套件&＃xff0c;数学就变得清晰了。

任何不是至少99.9%可靠的测试用例都应该删除&＃xff0c;直到它可以超过可靠性阈值。
 

但是可靠性是什么样的呢&＃xff1f;测试用例必须采取一切预防措施以避免假阴性或假阳性。它必须是可重复的&＃xff0c;无需外部人工干预&＃xff1b;它必须自行清理。

在完全自动化的系统中&＃xff0c;人们通常没有时间&＃xff0c;例如&＃xff0c;每隔几次测试运行就删除SQL数据库上的表。即使是手动运行的测试用例也必须在其自身之后进行清理&＃xff0c;因为不断变化的起始状态对测试执行者来说是一种难以管理的心理负担。

2. 重要性

例如&＃xff0c;尝试对无法编译的代码运行单元测试是没有意义的。如果底层包的单元测试没有通过&＃xff0c;那么运行API级别的集成测试套件就毫无意义。

始终尽可能快地运行重要的测试用例&＃xff0c;并始终首先运行快的测试。这些几乎总是你的单元测试&＃xff1b;典型的单元测试在几微秒内执行&＃xff0c;并且通常可以并行运行。在我的持续集成系统中&＃xff0c;我通常可以在大约 90 秒内处理数以万计的单元测试。

集成测试是一种跨越边界的测试&＃xff0c;通常至少包括一个HTTP或其他机器对机器的边界。这些测试用例以毫秒为单位执行&＃xff0c;并且比单元测试慢几个数量级。

专业测试是任何比集成测试&＃xff08;例如端到端自动化 UI 测试&＃xff09;慢得多的测试&＃xff0c;或者需要人工干预或解释从而减慢整体结果报告速度的测试。

虽然比单元测试慢的测试当然有价值&＃xff0c;并且在持续集成系统中绝对占有一席之地&＃xff0c;但那个地方是在运行更快、更可靠的测试之后。

3. 特异性

一个好的测试用例应该尽可能少地单独做&＃xff0c;以尽快产生通过/失败的结果。如果有无限的时间来执行测试运行&＃xff0c;重叠覆盖和冗余测试就不是很重要了。

如果整个集成测试通过的预算只有五分钟&＃xff0c;而每个集成测试用例需要10毫秒&＃xff0c;那么只有时间运行30,000个测试用例。如果正在进行基于UI的测试&＃xff0c;每次测试的时间接近1秒&＃xff0c;那么只有300个测试用例的时间。

图 2. 始终以清晰、描述性的方式命名测试用例。正如您在上面看到的&＃xff0c;这使得诊断故障变得更加容易。

每个测试用例都应该是一个明确问题的明确答案&＃xff0c;这些问题的组合构成了一个测试套件&＃xff0c;该套件将对所有被测功能给出明确的答案。命名清晰的原子测试用例应该可以很容易地定位测试失败的潜在原因&＃xff0c;并且还可以一目了然地了解哪些已测试和哪些未测试。

当测试用例清晰且具有原子性时&＃xff0c;很容易找到覆盖重叠&＃xff0c;从而很容易找到删除的候选对象。