DevOps研效：TestX 持续测试中开发实践赋能

导语：DevOps时代下，要想构建能够支撑起数字化转型要求的研发能力，与之适配的测试能力必不可少，打破以往项目内产品、开发、测试团队各自为战，认知存异的窘况，通过测试前置、打通自动化、测试贯穿，真正意义上提升团队研发效率和质量。本文将 TestX - 测试协同团队结合自身产品能力，经过探索和实践总结出一套高效高质开发工作流分享给大家～

持续交付催生持续测试

DevOps模式的转换，使得持续交付成为软件研发能力的核心诉求，其关键抓手是实现软件业务价值持续、高效向业务用户交付。

图1 DevOps研发模式

整个持续交付流程包括计划、编码、构建、测试、发布、部署、运维和监控环节，实现整个迭代闭环，对于其中任一环节，都要遵循以下要求：

• 执行过程需要“够快”，满足效率要求；
• 执行效果需要“够准”，满足质量要求；
• 执行衔接需要“够稳”，满足高速运转。

参照要求，先后引入了Scrum敏捷研发模型、持续构建、持续部署等一系列最佳实践，相比于其他环节，测试领域存在的执行效率低、反馈时间长、测试价值认可等瓶颈问题逐步催生出“持续测试”理念。

从持续测试看测试未来

随着敏捷宣言四大核心价值观提出，团队更高目标是为客户带来价值的行为和结果，而非传统死板完成既定事项，这里我们先回看下四大核心价值观：

1. 个体和互动高于流程和工具；

2. 工作的软件高于想尽的文档；

3. 客户合作高于合同谈判；

4. 响应变化高于遵循计划。

持续测试作为 DevOps 开发流程中的重要一环，“四个高于”的要求对其同样适用，在软件研发生命周期过程中，持续测试提供了持续的反馈机制，在产品交付管道中充当催化剂，每个阶段的测试反馈确保缺陷在开发工程的早期能被解决。

在传统测试流程中，测试人员通常采用的实践为：规划测试工作 - 识别测试内容 - 制定测试策略 - 创建手工测试 - 执行测试 - 报告测试进度。可看出，传统测试重点关注测试工作是否可以按计划完成，耗费大量人力成本在进行低效手动测试工作，且并未创建稳健可维护的自动化测试框架。

图2 三类研发模型对比

随着敏捷研发的广泛应用，增强了自动化测试比例，呈现出以底层运行速度快、消耗小的单元测试为主的正三角模式，强调持续发现缺陷并迅速修复。

进而到了 DevOps 时代，持续测试不仅仅是在整个交付流程中执行自动化测试，还需要持续对业务和技术风险分析，以及整个持续集成过程的流程改进。从本质上来说，它是伴随 DevOps 发展出来的一种文化，要求团队中每个成员都把产品质量当作是共同的责任，它也是一种管理风险的方法，可通过提高测试流程的有效性和效率来消除测试瓶颈。

落地迭代内持续测试

基于上文提及介绍，「 TestX - 测试协同」平台的研发团队以【持续测试】为核心理念，在实践中探索出高效高质开发工作流，结合实际问题，沉心打磨自身产品。团队内维持两周一迭代的节奏，与开发工作同步，拓宽测试时间窗口，下图为团队总结完整工作流程图：

图3 团队研发工作流

遇到问题及阻碍

异地团队协同工作磨合之初，遇到的问题及阻碍无异于以下：

1. 需求传达不清晰，多人多想法，存在理解差异成本；
2. 工作阶段断层，测试不充分，未覆盖所有受影响功能，导致出现线上问题；
3. testing/staging/prod 发布后，人工确认发布内容，存在低质重复劳动；
4. 开发阶段，前后端联调过程，相互等待对方验证，拉长开发周期...

「 TestX - 测试协同」团队经研讨后，决定借助自身产品特性探索新的需求研发工作流，加强引入自动化测试与其结合，团队角色面向确定性开展工作。

产品设计与需求评审

前期需求采集分析完成设计后，在迭代规划会上，产品就需求设计与团队一起进行解读、工作量评估，将完整需求内容落实在 TAPD 排单中，需求单必要内容包含：

研发过程中，应该以代表业务价值的需求作为一个整体进行交付。产品与开发依据优先级明确功能点、前后端/其他模块接口细节、技术难点风险点以及工期。因此在开发实现编码前，测试用例可以完成编写及评审，每个需求可达到开发完成后随即测试通过，处于可交付的状态。借助「TestX - 持续测试」，我们做到：

1. 在持续测试平台，编写测试用例，团队共同发现完善需求细节，输出相应验收标准（Acceptance Critreia，简称 AC）。

2. 在持续测试平台，创建用例评审（评审标题为 TAPD需求单标题），选中相关测试用例。平台自动创建需求评审群内，可与关联方讨论需求细节，明确开发工作点。

实际效果：

1. 开发对人日评估负责，即：开发阶段避免出现接口/网络与设想不一致，或预先的设计方案有误导致需求延期；
2. 产品对用例评审负责，即：用例评审通过情况后，避免验收阶段，进行需求变更；
3. 迭代内的需求完全被用例+评审覆盖，平台自动创建用例评审群，可用于后续事项的推进，一事一群，轻松辨别需求所处状态及交付反馈。

迭代开发

完成以上步骤后，迭代过程中，开发按照需求优先级顺序进行编码：

1. 找到需求对应的评审群，修改群名添加【开发中】的标题。；
2. 根据评审内的用例功能，进行业务开发，对于前端，需要在完成需求开发的同时，编写覆盖需求的 Cypress 测试用例（详细可查看：Cypress 前端测试自动化）；
3. 完成开发后，merge 代码到集成测试分支（dev/coding-testing）；
4. dev/coding-testing 分支的提交会触发流水线 CT-集成测试环境部署 ，该流水线完成以下工作：

• 部署集成测试环境（个人开发环境，env_name= coding-ct）；
• 圈选持续测试用例库，dev/coding-testing 分支，所有已自动化的用例，创建测试计划；
• 启动自动化测试任务 自动化测试 执行对 SIT 环境的自动化测试。

1. 自动化测试通过，在评审群通知产品进行需求验收，同时修改群名为【验收中】
2. 开发其他需求

利用自动化测试保证需求变更不引入新的问题，同时减少前后端联调拉扯时间。

验收测试与部署投产

在 SIT 集成测试通过后，利用持续测试平台提供一键发起测试计划功能，创建测试计 划并修改群名为【评审中】，机器人可在评审群中提醒相关人员进行验收。后续流程：

1. 验收后，在工蜂提交分支 merge 到 master，走大仓发布流程进行需求发布；
2. 在发布到 staing 后，启动自动化任务 对 staging 环境进行自动化测试；
3. 在发布到 prod 后，启动自动化任务 对 prod 环境进行自动化测试；
4. 自动化测试通过后，修改评审群名【已发布】同时知会产品，该需求已发布。

持续测试对团队的价值

探索实践中不断接收到团队内来自各方的反馈。

开发小哥收起了商业假笑😊，他说：需求拆解更清晰、工作范围更明确、一事一毕，再也不用一边battle一边开发一边删了重写，增加了与产品有产出的有效紧密沟通，每次交付的都是完整业务价值的成品。

产品妹子露出了会心一笑😏，她说：需求和用例建立了关系，对高优需求交付风险把控一目了然，追踪需求进度更方便，每个需求的完整链路数据留痕记录，这些内容沉淀也为团队合作持续改进提供指引。