持续测试 | 测试流程提效：在 CODING 中实践迭代内的持续测试
本文做者：程胜聪 - CODING 产品经理
持续测试带来的变革
持续测试（或者敏捷测试）要求测试做为基础活动贯穿于软件交付的整个过程当中。相比起在 DevOps 时代陷入困境的传统测试模式，持续测试首要改变的是“测试后置“的情况，强调测试前置，经过尽早定义测试、测试与开发并行、在过程当中保持紧密协做，从而实现快速反馈业务风险的目的。持续测试的实践变革是关于人、流程和技术的全面工程：既须要技术上的支撑，好比持续集成、持续部署的基础能力，也须要人员自动化代码能力的提高，同时对流程的改进也是其中不可或缺的一环。工具
正如敏捷宣言开篇提出的四个核心价值，团队应该聚焦在为客户带来价值的行为和结果、而不是传统的循序渐进完成既定项目的事项和生产过程交付物，这对测试的要求也是同样：测试
- 个体和互动高于流程和工具；
- 工做的软件高于详尽的文档；
- 客户合做高于合同谈判；
- 响应变化高于遵循计划。
然而，对于上述宣言中的“四个高于”字面上的理解，你们每每容易产生困惑：协做很重要，那么是否是流程、文档、计划就再也不须要了呢？其实否则，毕竟软件的内在复杂度还在，那么为了更好地交付软件而进行的计划和文档说明就仍然有着重要的价值。只不过咱们须要改变原来过于臃肿的流程、文档、计划，让其再也不成为团队快速响应目标的束缚。因此，“轻流程”、“合适粒度”、“尽早计划”才是咱们应该做出的适当的改变。若是说自动化测试和精准测试是在测试执行这个单点上对效率的提高，那么迭代内测试则是在总体流程上的对测试效率进行提高。编码
如何实践迭代内的持续测试
测试过程通常包括计划、设计用例、执行这几个环节，下图就是在敏捷模式的迭代中的测试视角的经典工做流。让咱们从敏捷模式下测试视角的经典工做流出发，探讨一下如何在一个迭代中实践持续测试。spa
基于上述场景，咱们能够根据以下步骤开展测试活动，达成与开发的工做同步、拓宽测试时间窗口的目标：设计
首先，在迭代规划会上，产品经理就需求故事与团队一块儿进行解读、分析和工做量评估。在任务认领时，开发和测试（或者充当此角色的另外的开发）结对负责某一个需求故事。当迭代规划完成时，其实就能够建立迭代对应的测试计划，计划内应该包括迭代故事列表以及相应的验收标准（Acceptance Criteria，简称 AC）。接口
而后，在迭代过程当中，应该以表明业务价值的需求故事做为一个总体进行交付。也就是说，结对的开发和测试应该以一样优先级处理某一个需求故事，尽量快地实现故事的端到端交付后，再处理下一需求故事。所以在开发实现编码的同时，测试也应该同步编写该故事的测试用例——多数状况下是对 AC 进行细节性的展开和编写补充完整。当用例编写完毕后及时进行评审，甚至在接口契约获得保障的状况下实现接口自动化测试的编码。这样每一个故事都是开发完成后立刻测试经过，处于可交付的状态。开发
最后，在迭代完成后，甚至能够执行一遍覆盖了当前迭代的需求故事所对应的测试用例集，依据测试报告反映的总体测试状况进行回顾，以待持续改进。rem
CODING 如何助力实践迭代内的持续测试
基于上文说起的场景，CODING 以【测试计划为测试活动的主体】为理念，设计并打磨产品，力求给用户带来“沉浸式”的测试体验。接下来将演示如何在 CODING 测试管理中开展一个完整迭代的测试活动：文档
- 迭代规划会上：
首先，从项目协同中规划好的迭代开始，查看/建立团队的测试计划、并关联对应迭代。部署
而后在团队测试计划建立完成后，计划中会展现迭代的需求故事。接着为需求故事建立相应的功能用例，内容上可能只是带上规划会中达成一致的验收标准（AC），把相关的用例任务分配给对应的测试同窗，就造成了一个测试团队视角的迭代看板。这些操做彻底能够在规划会上或会后的短期内完成，测试计划包括了迭代故事列表以及相应的 AC 做为内容的用例，暂且称之为“测试计划 alpha 版”。
- 迭代进行中：
开发同窗实现编码的同时，测试同窗同步编写该故事的测试用例，用例逐步补充完整的测试计划能够称为“测试计划 beta 版”。当用例编写完毕以后及时进行评审，甚至在接口契约获得保障的状况下实现接口自动化测试的编码。这样的节奏也就实现了测试与开发的工做同步。
需求故事提测后，执行测试用例，对照用例步骤验证功能是否正常。在这样“小步快走”的模式下，迭代在任什么时候候结束均可以交付有业务价值的需求故事，而不是一批“半成品”。如此经过开发测试的紧密协同工做，逐步接近体现业务价值的持续交付。
- 发布的时候：
在迭代最后需求故事都完成后，咱们就能够得到包含完整测试用例内容的“测试计划正式版”。由今生成测试报告，根据经过率和报告反映出来的风险来判断是否能够发布到下一个环境（如 STG）。
总结
CODING 迭代视角的测试工做流的核心理念是引导测试的前置，在过程当中加强了测试与其余角色的协做和反馈。目的是经过产品能力来帮助团队固化良好实践，从而实现高效的测试：
首先，尽早规划了测试。从需求规划会开始，在充分理解需求并认领任务以后，咱们就能够圈定测试范围，并由此产生简单版本的测试计划、并快速制定验收标准和完成初步用例的编写。
其次，经过创建需求和用例的关系，对高优先级（业务价值）的需求所需测试作到一目了然，为基于风险的测试策略（Risk-based Testing）打下基础。
再次，迭代进行过程当中实现测试和开发工做的并行开展。在开发工程师进行业务代码实现的同时，测试工程师能够对测试用例做进一步细化补充完整，甚至实现测试的自动化代码实现。经过紧密协同、“小步快走”，每次交付的都是完整业务价值的“成品”。
最后，测试过程当中的操做以及产生的数据并记录下来，可以快速的反馈给团队，而这些沉淀下来的数据，将成为工程实践持续改进的指引。