聊聊发版提测和发布评审

看到有同学提问关于测试准入准出标准的问题，说自己公司研发测试流程混乱，线上发布后问题比较多，不知道如何优化解决。其实这个问题一般在初创公司或者新项目出现的比较多，优化的方向和方法业内也比较成熟了，这篇文章谈谈我对于准入准出的理解。

从软件工程的角度来说，一个软件产品从无到有要经历如下几个阶段：

研发阶段主要包括编码实现、测试验证和运维发布。严格来说，为了控制风险，保障最终交付的软件产品达到需求预期的质量标准，在整个生命周期的每个阶段都应该有对应的准入准出标准。对应到测试环节，则是我们所说的质量门禁。在质量门禁这一定义中，我个人认为最重要的有两个环节：发版提测和发布评审。

发版提测，是软件从编码实现环节转移到测试验证环节的入口。我们都听过这样一句话：质量是设计和实现出来的，不是测试出来的。同理，提测阶段做的如何，对后续的测试工作开展有很大的影响。如果没有提测这一门禁，有很大可能测试刚开始就会遇到很多问题，比如表结构未同步，接口请求失败，主流程阻塞，影响整体的进度和测试效率，随之就会导致加班、多次的返工。

发版提测环节的准入标准，一般要从如下几个角度去考虑：

• 功能是否实现：这一点除了开发本地自测以外，很重要的一点是测试用例评审。通过测试用例评审，开发和测试双方对于本版本要实现的需求功能和准出标准达成一致。

• 流程是否顺畅：一般的做法是测试提供本版本的 P0 测试用例(主流程直接相关)让开发进行冒烟测试，测试同学负责验收，如果冒烟测试不通过，则打回重新提测。

• 变更是否完成：这里的变更主要指的是对应的表结构是否同步到测试环境，对应的基准测试数据是否铺底完成，内外部的调用依赖是否通畅(如果是否，则考虑配置 mock)，以及新服务部署和白名单等配置项。

当然，除了上述几点强制项之外，还有如下几点补充项，适度评估是否作为准入标准。

• 单元测试：确保每个功能模块都经过充分的单元测试，以发现潜在的缺陷(不强制)。

• 联调测试：将各个功能模块进行端到端的联调，确保整个系统的协同工作正常(开发自行组织)。

• 变更确认：提测前，与开发和产品团队确认需求是否有所变更，并修改相应的需求文档(建议项)。

• 接口文档：确保开发团队准备了完善的接口文档，以便测试团队进行接口测试(建议项)。

• 提测范围：开发需要罗列提测版本、范围及相关风险清单，确保测试了解测试的重点和潜在问题(测试跟进)。

• 环境准备：在提测前，确保测试环境准备就绪，可以正常跑通(对应上述的变更部分)。

• 版本控制：使用版本控制系统（如 Git）来跟踪代码变更，确保团队成员都能获取到最新的代码。

除了这些内容，提测时还可能会遇到这些问题：

• 是否自动化跑主流程用例：根据团队基础技术建设和能力以及资源富余成都决定。

• 多分支多环境，如何解决：做好代码版本管理、请求打标染色、测试环境治理。

经过充分测试验证后，如果认为软件质量已经满足了预期的质量标准(也可能到了发布时间)，就需要考虑线上发布事项。线上发布是软件生命周期的最后一个环节(一个版本迭代周期内)，发布一般就意味着交付用户使用，一切成为定局。因此在线上发布前，需要通过发布评审来充分评估整个软件，确保发布质量满足预期要求和质量标准。

发布评审可以视为测试阶段的准出节点，在发布评审环节，需要考虑如下几个方面：

• 功能完整性：所有需求是否都已实现，是否存在遗漏。

• 安全和兼容性：是否存在安全漏洞，是否能兼容不同操作系统和设备。

• 缺陷修复状态：已发现 BUG 是否都已修复并验证通过，异常场景是否有足够冗余。

• 性能和扩展能力：性能指标是否达标，服务是否可以水平扩容，能否支撑线上业务正常运行。

• 文档完整和准确性：用户手册、运维操作指南和相关技术文档是否准备完毕且准确无误。

• 发布计划和风险预案：线上发布的详细计划，可能出现的问题和对应的解决策略，是否有过演练。

在发布计划中，需要包括发布时间、发布渠道、发布方式等内容。重点需要考虑这些因素：

• 发布优先级：应用依赖关系，先发布哪个应用，后发布哪个应用。

• 相关配置变更：包括数据库的表结构变更、数据变更、应用白名单是否添加。

• 数据准备和线上验证：缓存数据是否已经预热、线上验证的脚本 &用例 &测试数据是否准备完毕。

• 风险管理和应急预案：发布过程出现问题的应对策略，是否回滚、是否限流、是否灰度以及沟通协调策略。

综合考虑以上各个方面，通过发布评审这一测试准出标准，可以在最大范围内保障软件在发布时达到预期的质量和业务目标。