摘自《trends in software testing，软件测试发展趋势》
摘要：技术债指团队有意或无意为了获得项目的短期收益而做出的技术决策。测试债是近年来新出现并引起软件界关注的概念。本文讨论测试债的组成要素和偿还测试债的策略，并通过案例研究讨论在项目中如何发现“测试发霉”及重构测试偿还债务。本文适合IT公司的经理和领导，以及相关研究者阅读。
1 引言
1.1 技术债
Ward Cunningham于1992年最早提出“技术债”，指为了短期提高开发速度对软件质量造成的长期影响，借用经济学上的术语说明短时间的获益如果不偿还将带来的长期伤害。
借贷就会产生财务债，如果不偿还，债务利息会不断增长，直至偿还不起导致经济破产。技术债也是如此，如果在开发过程中有意无意走捷径就会产生债务。如果通过重构补偿这种捷径，则债务不会引发问题，但如果任凭技术债持续积累而不采取偿还措施，则会使软件“技术破产”。
软件项目中的高技术债会在多个方面影响项目，整个公司都可能会在债务重压下寸步难行。如果不理会技术债，轻者不能及时对客户的问题作出响应，重者打乱公司的发展节奏，即变更成本随技术债的增加而增加，导致生产率下降。公司要在有限的时间内更关注功能，而不是质量，导致产生更多技术债，从而陷入恶性循环。技术债还会打击开发团队士气。
以下是一些产生技术债的常见因素：
进度压力
缺少高水平工程师
缺少文档
过程和标准运用不足
没有测试套件
补偿措施滞后
知识不足
技术债可以在需求、体系结构、设计、编码、测试、构建、文档、基础设施和版本控制等多个方面产生。图1给出了技术债的几个主要方面。通常如果代码债被高度重视就会产生技术债。最近设计债、体系结构债也开始引起重视。
图1 几种维度不同的技术债
如果走了与测试有关的捷径就会出现测试债。比如如果完全没有做单元测试（对于老项目是很常见的）就会产生测试债。这是因为不完成单元测试是一种捷径，虽然可以加快开发进度，但是会对软件质量产生长远影响。
1.2 测试债的重要性
经常发现经验不足的公司欠下测试债，最终因为高企的测试债而不得不为生存挣扎。本来是想先人一步将产品推向市场，为此公司完全关注开发功能，但是到了测试阶段，开发人员只是快速地在自己的机器上测试了一下最常用的场景，而不是充分、综合的测试。通过史诗般的努力，团队可能会在相对很短的时间内成功地开发并交付能够运行的产品，甚至快速占领相当大的市场份额。不过最初的成功常常并不能持久。在开发第一个版本时欠下了大量测试债，比如没有创建并执行自动化测试，或执行的测试覆盖率很不理想。到了第二个版本时，团队首先必须集中力量通过在测试上大量投入来偿还欠下的测试债。任何延迟还债或没有重视还债都会导致产品的可信性下降，如果债务过重，还会导致开发难以推进，出现“技术破产”，放弃产品研发。
1.3 测试债的一般原因
软件团队一般会面临进度的巨大压力，需要接口拿出价值，团队常常因为没有测试债常识而牺牲测试最佳实践，并欠下测试债。
工程师经验不足也是产生测试债的一个原因。开发人员常常没有接受过单元测试的训练，大多只是“在岗”学习如何测试。而单元测试的质量严重依赖编写测试用例的工程师水平。水平不高的测试人员编写的难以维护的单元测试用例是产生测试债的一个因素。
“数字魔咒”是另一个产生测试债的不那么明显的常见因素，很多软件团队仅仅关注诸如测试覆盖率和总测试用例数这样的数字，关注让管理层满意，结果是拿到“数字”却牺牲了测试质量。
测试债的另一个原因是测试基础设施工具不足，例如使用过时的测试框架，使测试用例编写效率不高，难以升级。
其他因素还包括测试策划不充分、估计偏差过大等。
2 测试债分类
2.1 单元测试
单元测试有很多捷径会导致测试债：
单元测试不充分
单元测试不明确：单元测试是活着的文档，有助于理解被测代码的功能。如果单元测试数据不完整，会对对理解被测试的理解造成困难
带外部依赖的单元测试：单元测试应该独立执行，应该与外部依赖因素隔离。比如单元测试直接访问数据库而不是进行隔离这种依赖性，即使下层功能没有问题也可能由于外部原因，例如网络问题造成测试失败
单元测试中的断言不合适：很多情况下，断言的错误或非优化使用会导致测试债。例如陷于“数字魔咒”的团队为了提高覆盖率而不使用必要断言。类似的，断言条件重复使用对增加测试价值也没有意义。甚至有时给出的断言条件是错误的。有时测试条件需要人工检查，而没有写入断言语句，结果每次测试都需要人工干预。
2.2 探索式测试
探索式测试方法不依赖正式测试用例的定义。这种测试中，测试人员根据直觉和知识而不是正式的测试用例设计开展测试。开发团队发现探索式测试很有吸引力，因为其富有创造性、不受限制并且费效比高。探索式测试对于安全性测试等很有效果，因为这种测试需要测试工程师具有大量经验和创造性，以发现安全方面的脆弱性。
但是过度依赖探索式测试也会带来问题，部分因素包括：
随着应用的复杂度提高，探索式测试的成本和工作量也会增加，比结构化测试的难度也更大。
测试经理很难理解和监视测试工作进展。
重新执行测试既困难也开销大
完全依赖探索式测试会产生测试债，但如果探索式测试结合手工测试和自动化测试就会取得效益。如果做了这种结合，以下因素会产生测试债：
不准确的估计：由于更多的残留缺陷，基于探索式测试的测试结果评估可能导致额外的返工，直接影响维护成本
测试人员经验不足：探索式测试的主要优势源自测试人员的经验
文档差
此外，如果探索式测试的过往测试活动记录得不到很好维护，还会带来其他问题，例如工作量估计问题等。
2.3 手工测试
在手工测试中，测试工程师按照测试规格说明描述的步骤执行测试用例。以下是一些与手工测试有关的常见测试债：
有限的测试执行：通常可用的资源和时间对于完成完备、深入的测试都是不够的，所以只会执行测试用例的一个子集
不恰当的测试设计：手工测试是很费时费力的过程。测试用例可能设计为大量变化，包括不同的数据组合，需要测试人员执行所有这些组合。由于这非常耗费人力，测试人员只执行少量比较容易的场景
缺少测试评审：
2.4 自动化测试
自动化测试不需要手工介入，执行预先脚本化了的测试用例并检查执行结果。单是只依靠手工测试不做自动化测试本身就会产生测试债。自动化测试是有效回归测试的关键。以下是与自动化测试有关的测试债常见因素：
不恰当或不充分的基础设施：在与客户基础设施不同的基础设施上实施测试可能产生预期外的结果，从而降低对系统的信心。测试应能够使用习惯的硬件或设备。例如对于嵌入式系统，测试常常使用仿真器或模拟器。虽然可以简化测试，但是省去在实际硬件设备上的测试环节会产生测试债
没有编码标准：自动化测试需要遵循公共标准，如果不采用公共编码标准会增加测试代码的维护工作
未修改的测试用例：不对过时的测试用例修改会降低对测试用例的信心，降低测试质量，增加维护工作
运用记录回放：使用记录回放工具测试GUI应用是很容易的。但是使用这样的工具也有缺点，例如对UI的一点改变都会需要对测试更新。已经有比记录回放更好的替代工具
3 测试债的管理
在现实中出现测试债是不可避免的，对于管理测试债重要的是要跟踪测试债，并定期偿还，使其受控。关键是采用精心设计的实用方法评估和偿还测试债。
不过需要注意的是，有时出现测试债是好事，因为这使得团队能够达到其目标。例如，可能不能完全解决测试评审中发现的所有问题，因为必须满足交付时限。这样会产生测试债，但是只要已经制定了计划在未来的发布中解决测试评审中发现的问题，并且这种计划被恰当地跟踪和执行，那么这种测试债就是可接受的。
另外一点也很重要，就是要避免测试债的积累。做到避免要靠提高开发团队对测试债的认识。例如关注“清洁编码”实践，定期测试评审等。
3.1 偿还测试债的一般过程
管理测试债的关键是偿还测试债。通常软件项目会逐渐积累相当多的测试债，在这种情况下需要评估测试债的程度，并做出偿还计划。现实中不大可能只关注测试债，根据我们的经验需要采取以下步骤：
量化测试债，取得管理层支持，执行大范围的偿还
周期性地偿还技术债
避免增加测试债
3.2 管理测试债的战略性方法
管理技术债只靠战术方法是不够的。战略性方法包括改造工作方式。
采用针对测试代码的有效编码实践
结对编程
清洁编程
在不增加或删除测试用例的情况下，使测试代码更易理解
这些因素相互影响和关联。
实行有效的测试实践
10分钟构建。对于减少修改开发人员机器上的代码以迁移到目标环境所需的时间，快速而完备的构建是很重要的。根据经验，构建、测试和部署软件（包括编译代码、运行测试用例、配置机器，如注册设置、拷贝文件等，启动软件）应该只需要10分钟，而很多情况这些工作需要几个小时。通过采用合适的实践（例如增量编译）把这些工作压缩到10分钟数量级是可行的。
无脚本测试自动化。传统GUI测试方法是使用记录回放工具，虽然上手很快但是很难维护。通过编写脚本的GUI测试自动化工作量大，技能要求高，而且维护也比较困难。新出现的方法是无脚本的测试自动化，通过GUI由对象和行动生成测试用例，能够更好地适应GUI的修改、技术演化，能适应后期修改，相对比较容易维护。
4 未来方向
“测试臭味”这个概念已广泛用于描述测试债。测试臭味有三种不同的类型：代码臭味，即存在于测试代码中的臭味；行为臭味，即测试用例执行时对测试结果有不良影响；项目臭味，即整个项目的健康状况。单元测试中的代码臭味已经引起普遍重视，其他两种臭味尚未引起业界重视。
主流集成化开发环境包括Visual Studio、Eclipse和支持自动化代码重构的IntelliJ UDEA。虽然已经出现了检查测试臭味的工具（例如TestLint），但是还没有支持自动化改造测试臭味的工具或IDE。
已经有技术债量化工具，包括针对编码债和设计债的，例如SonarQube，但是还没有针对测试债的工具。
测试债是向管理层说明测试过程走捷径成本的最佳元素，因此测试成熟度评估框架和方法可以纳入测试债因素。