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