对于研发自测上线项目，测试同学可以做点啥？

在软件研发过程中，不可避免的存在由研发自测后上线的项目。在这种完全由研发同学独立完成开发、测试、发布上线的项目，测试同学可以提前为研发同学做点啥？

我们算法测试团队，提出了四步曲的设想：

第一步：定标准

定标准，即明确可研发自测上线的范围。业界对研发自测的标准非常多，我们建议遵循以下三个维度来制定：

影响面

• 对核心链路有影响，则测试介入
• 对公司核心业务有影响，则测试介入

复杂度

• 涉及复杂链路或复杂逻辑，则测试介入
• 难以通过现有的简单测试手段来测试，则测试介入
• 涉及架构变更（如技术方案升级、应用功能拆分等等），则测试介入

工作量

• 研发投入时长 >= X人/日（X由各个公司自行定义），则测试介入

不满足上述三个维度标准的项目，可以考虑研发自测上线。

第二步：赋能

赋能，指帮助研发做好自测。我们从研发自测整个实施过程来看，可以做哪些赋能动作：

测试准备：

1.测试数据准备：对于聚焦在具体模块或应用的研发同学而言，上下游测试数据准备，是阻碍研发同学做好自测的一大痛点。因此：

• 可以看下测试工具是否完备，如是否有一站式造数平台——数据工厂，数据Mock平台等数据准备工具；
• 我们可以再往前走一步，看看是否能将上述的平台能力进一步封装成简单易用的组件，研发同学只需要点一下组件，就能生成所需要的测试数据。

2.测试环境准备：测试环境稳定性，是阻碍研发进行自测的第二大痛点。时不时的环境异常，会给测试结果带来非常多的噪声，降低研发自测的积极性。因此：

• 是否有独立的联调环境，在该环境下可独立部署应用依赖的上下游服务，通过容器化方式一键拉起部署，用完自动回收；
• 我们还可以再往前走一步，为研发做好平台使用培训，积极推广好的实践案例。（历史经验表明，人都是有惰性的，即使再好的工具，也可能不被发现）

3.测试场景准备：上下游全链路的测试场景设计，往往是研发同学的盲区，对上下游的不了解，使得他们无法确定该做哪些测试动作。而具备全局视野的测试同学，天生具备为研发提供核心链路测试场景的条件。因此：

• 为研发同学提供一套最小合集的主流程核心测试场景。
• 需要我们努力提高测试场景的可读性和可执行性。降低研发同学的执行成本，才能最大化的实现自测场景的覆盖占比。否则，再完善的用例集，也只能用来看！

测试实施：

1.提高测试实施效率：人都是有惰性的，如果一个测试场景的测试实施过程需要经历：测试环境搭建，测试数据准备，mock接口准备，测试步骤逐个操作，逐步查看结果反馈等。我相信，这个过程已经劝退了很多人。因此，我们需要秉承：

• 能自动化实施的，均提供自动化的能力。比如研发在提交代码后，自动触发自动化测试执行流水线：环境搭建->数据准备->测试场景自动化执行->测试结果自动汇总。
• 能做能力聚合的，均依靠平台化建设，将能力聚合在一起。比如，测试实施不仅仅包含用例场景的自动化测试，还包含复杂的业务效果评测、性能压测、故障演练等测试类型。如果能够依托平台化，为研发输出一站式的测试能力集，由其自行组合，自行测试实施。

2.关注结果反馈的3大要求：

• 反馈时效性：测试结果的反馈，时效性非常重要，漫长的等待不仅降低过程效率，也会消磨人的积极性。因此，对于高频的测试项，如场景的自动化测试会约定10分钟内给结果。而对于相对低频的测试项，如业务效果评估，稳定性测试则可适当延长。
• 反馈指标完整性：测试结果反馈需要展现哪些指标项，需要由测试同学来制定标准，从而实现无论哪个研发自测，都能按图索骥的操作，输出合格的自测过程与结论。

• 反馈内容可靠性：由于测试实施过程中的各种不可控因素非常多，因此测试结果中会混入噪声。如何降低噪声，一般有2个方向：

  • 及时维护测试相关组件的有效性（如上文提到的各种技术能力，测试场景等）
  • 依托技术能力，自动筛选噪声和部分解决噪声。然后通过平台的交互设计降低噪声干扰。

第三步：可管控

可管控，指在上线前能够衡量测试效果和规划发布过程，在上线过程中能够发现质量风险，在上线后能够监控线上质量。比如：

发布计划

通过发布计划的设计，来满足对测试效果和发布实施步骤的检查。一般发布计划会涵盖如下内容：

• 发布需求说明（体现需求、变更范围、影响范围、代码说明等）
• 测试报告及结论（测试效果检查，具体指标项，在此不做扩展）
• 配置变更说明及检查结论（涵盖权限，静态、动态配置，网关，数据库，缓存，消息，埋点等）
• 依赖关系说明及检查结论（上下游调用关系，业务链路等）
• 发布方案及步骤说明（灰度方案，监控方案，应急方案，发布时间等）

变更三板斧

依赖公司的变更三板斧，实现：

• 可观测：是否可进行观测（监控）且确认变更成功
• 可灰度：是否可以进行灰度发布（应用发布，配置变更等均需支持）
• 可应急：是否有应急预案（降级，限流，回滚等），且可实施生效

第四步：营造氛围

营造氛围指测试自身的工作氛围和测试与研发合作的工作氛围两个层面：

• 测试自身：在平时的工作中，需要形成注重效能提升的氛围。主动将重复的、手动的测试工作，往工具化上沉淀，往平台化上拓展。将测试能力变成可输出的平台化能力，赋能给其他角色。
• 测试研发合作上：对于研发自测的项目，测试同学千万不能以为交给研发负责上线质量了，就可以不管不顾。我们依然需要做到：服务好过程，跟踪好结果，跟进好问题。营造和谐融洽的合作氛围，帮助研发做好自测，就是帮助测试自身，帮助产品最终成功。

（本文作者：陈震）

本文系哈啰技术团队出品，未经许可，不得进行商业性转载或者使用。非商业目的转载或使用本文内容，敬请注明“内容转载自哈啰技术团队”。