将测试工作作为前锋

要成功实施持续交付，我们必须要相信能够在不影响现有功能的情况下快速有序的交付新功能。这里，我们讨论一下如何通过Pipeline确保高质量的持续交付。

通常的做法是先开发功能，然后进行测试。这样就导致测试成了应用上线路上的一个路障。毕竟，代码都已经在那儿了---还等什么呢？无法避免的延迟导致测试被压缩或者中断，于是也就导致交付了低质量的功能。

在持续交付环境中，我们采用了更具有生产力的方式。有了自动化的可测试规范，测试变成了首要的事情，可以先于开发工作启动。自动化的测试可以是开发过程的一部分持续的执行。这种方式给我们提供了Pipeline所有阶段的功能和质量层次的实时反映。

• 可执行规范：自动化验收测试

传统的规范会随着需求和功能的变化过时而被束之高阁。冗长的文档首先被转换为测试用例，然后手工执行。这样费时费力的过程还可能会导致测试无法验证最初设想的功能。

采用持续交付，我们切换到了可执行规范。这些规范是采用了结构化的自然语言形成的，可以被业务和测试工具所理解。再也没有迷失在转换为测试用例的问题了：规范本身就是功能验收测试。

• 质量大于功能--自动化非功能测试

写一个小的程序运行在便携本等相对友好的环境中并不是难事，可是，在真实的业务环境中交付可靠的经过验收的高质量软件是比较有挑战性的。

• 保持系统正常运行--自动化回归测试

持续交付的成功实施需要我们在不影响已有功能的情况下，非常有信心能够快速且有节奏的交付新的功能。否则，就是出现了回归问题。

避免回归问题的一个有效的测试类型是白盒测试。

软件开发领域中，对一段代码行为所做的测试被称为单元测试。在TDD，开发者通常在写真正的代码之前先写单元测试代码。一旦模块的单元测试创建了，变会经常运行以保证该模块的功能正确。

从管理者的角度，好的回归测试有两个度量指标：覆盖度和执行时间。覆盖度是表示有多少系统行为被测试用例验证的百分比。测试覆盖度达到100%可能会花费大量的时间，导致业务上无法接受。所以，需要在覆盖度和花费时间之间达到某种平衡。比如，关键的每个变更需要全覆盖，优化配置和工具、并行测试减少执行时间等。