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

[CodingNET]

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

持续测试带来的变革

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

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

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

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

如何实践迭代内的持续测试

测试过程一般包括计划、设计用例、执行这几个环节，下图就是在敏捷模式的迭代中的测试视角的经典工作流。让我们从敏捷模式下测试视角的经典工作流出发，探讨一下如何在一个迭代中实践持续测试。

基于上述场景，我们可以根据如下步骤开展测试活动，达成与开发的工作同步、拓宽测试时间窗口的目标：

首先，在迭代规划会上，产品经理就需求故事与团队一起进行解读、分析和工作量评估。在任务认领时，开发和测试（或者充当此角色的另外的开发）结对负责某一个需求故事。当迭代规划完成时，其实就可以创建迭代对应的测试计划，计划内应该包括迭代故事列表以及相应的验收标准（ Acceptance Criteria，简称 AC ）。

然后，在迭代过程中，应该以代表业务价值的需求故事作为一个整体进行交付。也就是说，结对的开发和测试应该以同样优先级处理某一个需求故事，尽可能快地实现故事的端到端交付后，再处理下一需求故事。因此在开发实现编码的同时，测试也应该同步编写该故事的测试用例——多数情况下是对 AC 进行细节性的展开和编写补充完整。当用例编写完毕后及时进行评审，甚至在接口契约得到保障的情况下实现接口自动化测试的编码。这样每个故事都是开发完成后马上测试通过，处于可交付的状态。

最后，在迭代完成后，甚至可以执行一遍覆盖了当前迭代的需求故事所对应的测试用例集，依据测试报告反映的整体测试情况进行回顾，以待持续改进。

CODING 如何助力实践迭代内的持续测试

基于上文提及的场景，CODING 以 [测试计划为测试活动的主体] 为理念，设计并打磨产品，力求给用户带来“沉浸式”的测试体验。接下来将演示如何在 CODING 测试管理中开展一个完整迭代的测试活动：

1.迭代规划会上： 首先，从项目协同中规划好的迭代开始，查看 /创建团队的测试计划、并关联对应迭代。

然后在团队测试计划创建完成后，计划中会展示迭代的需求故事。接着为需求故事创建相应的功能用例，内容上可能只是带上规划会中达成一致的验收标准（ AC ），把相关的用例任务分配给对应的测试同学，就形成了一个测试团队视角的迭代看板。这些操作完全可以在规划会上或会后的短时间内完成，测试计划包括了迭代故事列表以及相应的 AC 作为内容的用例，暂且称之为“测试计划 alpha 版”。

2.迭代进行中： 开发同学实现编码的同时，测试同学同步编写该故事的测试用例，用例逐步补充完整的测试计划可以称为“测试计划 beta 版”。当用例编写完毕之后及时进行评审，甚至在接口契约得到保障的情况下实现接口自动化测试的编码。这样的节奏也就实现了测试与开发的工作同步。

需求故事提测后，执行测试用例，对照用例步骤验证功能是否正常。在这样“小步快走”的模式下，迭代在任何时候结束都可以交付有业务价值的需求故事，而不是一批“半成品”。如此通过开发测试的紧密协同工作，逐步接近体现业务价值的持续交付。

3.发布的时候： 在迭代最后需求故事都完成后，我们就可以获得包含完整测试用例内容的“测试计划正式版”。由此生成测试报告，根据通过率和报告反映出来的风险来判断是否可以发布到下一个环境（如 STG ）。

总结

CODING 迭代视角的测试工作流的核心理念是引导测试的前置，在过程中增强了测试与其他角色的协作和反馈。目的是通过产品能力来帮助团队固化良好实践，从而实现高效的测试：

首先，尽早规划了测试。从需求规划会开始，在充分理解需求并认领任务之后，我们就可以圈定测试范围，并由此产生简单版本的测试计划、并快速制定验收标准和完成初步用例的编写。

其次，通过建立需求和用例的关系，对高优先级（业务价值）的需求所需测试做到一目了然，为基于风险的测试策略（ Risk-based Testing ）打下基础。

再次，迭代进行过程中实现测试和开发工作的并行开展。在开发工程师进行业务代码实现的同时，测试工程师可以对测试用例作进一步细化补充完整，甚至实现测试的自动化代码实现。通过紧密协同、“小步快走”，每次交付的都是完整业务价值的“成品”。

最后，测试过程中的操作以及产生的数据并记录下来，能够快速的反馈给团队，而这些沉淀下来的数据，将成为工程实践持续改进的指引。