《C++代码整洁之道：C++17 可持续软件开发模式实践》 —2.2　测试入门

2.2　测试入门

在软件开发项目中有不同级别的质量保证措施，这些不同级别的质量保证措施通常用金字塔的形式形象地表述，也就是所谓的测试金字塔。这一基本概念是由Scrum Alliance创始人之一、美国软件开发工程师Mike Cohn提出的，他曾在其著作《Succeeding with Agile》[Cohn09]中描述了测试金字塔，Cohn用测试金字塔描述了高效的软件测试所需的自动化程度。在随后的几年里，测试金字塔得到了进一步发展，如图2-1所示。

当然，金字塔形状并非偶然，它背后的信息是，你要比其他类型的测试进行更多次的低层次单元测试（几乎100%代码覆盖率），但是为什么会这样？

实践表明，关于测试实施和维护的总成本是朝着金字塔顶端增长的。大型系统的测试和手动的用户验收测试通常是很复杂的，并且通常需要大规模的组织又不易实施自动化。例如，一个自动化的UI测试是很难编写的，通常是比较脆弱的，而且相对较慢。因此，这些测试通常是手动进行的，它适合于客户审核（验收测试）和QA定期的探索性测试，但是在日常开发过程中使用它们太耗费时间且代价昂贵。

图2-1　测试金字塔

此外，大型系统测试或UI驱动测试完全不适合检查整个系统中所有可能的执行情况。软件系统中有太多处理各种可能情况的代码、异常和错误处理，交叉相关问题（安全性、事务处理、日志记录……）以及其他所需的辅助功能，但这些通常是无法通过普通用户接口去触发的。

非常重要的一点是，如果系统级别的测试失败了，则可能难以找到错误的确切原因。系统测试通常基于系统的测试用例，执行用例期间涉及许多组件，这意味着要执行数百甚至数千行代码，这其中的哪一行代码导致了测试失败？这个问题通常无法轻易回答，它需要花费时间和代价去分析。

不幸的是，在一些软件开发项目中，你会发现退化的测试金字塔，如图2-2所示。 在这样的项目中，人们把更多的精力投入到了较高层次的测试中，而忽略了基本的单元测试（Ice Cream Cone Anti-Pattern）。在极端情况下，他们完全不做单元测试（Cup Cake Anti-Pattern）。

因此，由一系列可选而有用的测试组件作为支撑，且基于广泛而廉价、精心制作、快速、定期维护、能完全自动化的单元测试的测试平台，可以成为确保软件系统高质量的坚实基础。

图2-2　退化的测试金字塔（反模式）