持续测试 | 测试流程提效：在 CODING 中实践迭代内的持续测试

本文作者：程胜聪 - CODING 产品经理

持续测试带来的变革

持续测试（或者敏捷测试）要求测试作为基础活动贯穿于软件交付的整个过程中。相比起在 DevOps 时代陷入困境的传统测试模式，持续测试首要改变的是“测试后置“的状况，强调测试前置，通过尽早定义测试、测试与开发并行、在过程中保持紧密协作，从而实现快速反馈业务风险的目的。持续测试的实践变革是关于人、流程和技术的全面工程：既需要技术上的支撑，比如持续集成、持续部署的基础能力，也需要人员自动化代码能力的提升，同时对流程的改进也是其中不可或缺的一环。

正如敏捷宣言开篇提出的四个核心价值，团队应该聚焦在为客户带来价值的行为和结果、而不是传统的按部就班完成既定项目的事项和生产过程交付物，这对测试的要求也是一样：

1. 个体和互动高于流程和工具；
2. 工作的软件高于详尽的文档；
3. 客户合作高于合同谈判；
4. 响应变化高于遵循计划。

然而，对于上述宣言中的“四个高于”字面上的理解，大家往往容易产生困惑：协作很重要，那么是不是流程、文档、计划就不再需要了呢？其实不然，毕竟软件的内在复杂度还在，那么为了更好地交付软件而进行的计划和文档说明就仍然有着重要的价值。只不过我们需要改变原来过于臃肿的流程、文档、计划，让其不再成为团队快速响应目标的束缚。所以，**“轻流程”、“合适粒度”、“尽早计划”**才是我们应该作出的适当的改变。如果说自动化测试和精准测试是在测试执行这个单点上对效率的提升，那么迭代内测试则是在整体流程上的对测试效率进行提升。

如何