“我就优化了下，影响不大的”，开发如是说。相信大部分测试人员听到这话，恨不得跳起来骂人。在正常的情况下，只有通过充分地测试，才能保障软件的质量和稳定性，如果开发人员可能会出于个人的需求，私自将代码上线，这对软件的稳定性会带来很大的风险。
真的是这样吗？软件系统真的就这么脆弱吗？
最近有小伙伴找我吐槽了这件事，系统地思考了下解决方案，仅供参考。
01
对于研发不论是有心还是无心的“夹带私货”，从风险的角度来看，主要有以下几点风险：
流程规范：这种形式一定是违反了既定的流程规范，如果多次出现，流程将流于形式，不再具有约束力，引发更大的风险；
测试遗漏：由于开发没有告知测试，测试人员不会做针对性的测试及影响范围评估，容易导致测试遗漏，引发不可控的风险；
爆发半径不可控：没有评估风险，容易给生产环境埋雷，不知道什么时候发爆发问题，影响范围有多大，行为不可控，风险不可控；
02
清楚了这种行为带来的危害，那就需要通过一定的手段来避免。最简单的方式就是加强流程的卡控，不让这种事情发生，把风险规避在源头。常见的方案有以下几种：
代码提交规范：在提交代码的时候，需要描述清楚提交代码的作用。借助于提交匹配规则，让代码提交注释不再随意。在团队的实践中，会要求按照 “Type: Description < Issue-ID>” 的格式来描述，Type包含常见的类型，例如feat、fix、merge、revert、test等，Description为描述字段，不超过50个字，Issue-ID为平台对应的StoryID，非必填，方便跟踪。
版本信息管理：根据结构化的Commit信息，提取当前版本的版本内容，让测试人员可以快速评估发布范围，同时，这个日志也可以作为制品的一个基础信息，用于溯源。
代码评审：基于前面两项，结合人为的代码评审，在代码合并到测试分支前，进行充分的审计，避免不明用意的代码被提交。
通过流程规范，可以有效地避免“夹带私货”情况产生。如果发生类似的问题，测试人员通也会要求开发加强约束，遵守流程规范。好像也没有其他更好的办法了。
真的吗？
03
测试人员如果只是这么被动地解决的问题，就很难产生价值，而且人为的操作本身就具备太多的不可控性。从质量保障体系的角度出发，笔者认为还有其他几件事可以做。
必要的自动化测试：从重构的角度上看，我们应该鼓励开发进行适当的优化和重构，减少代码债务，只要风险可控即可。所以，引入一定的自动化测试，保障核心及主干流程，就可以做到风险可控。在团队的实践中，会要求测试环境、UAT环境、生产环境的流水线中一定要集成自动化测试，保障核心功能不受影响，避免重大风险。
一次编译，多次部署：在正常提交测试的时候，开发一般都会告知影响范围，测试也会进行回归测试验证，最怕的是在临上线前做优化。那么践行一次编译，多次部署理论，就可以有效地避免这个问题，即测试的制品，就一定是发布的制品，除了配置不一样，其他完成一样，这样也是可以控制风险的。
以上是从测试遗漏，风险控制的思路上来思考。
04
从风险评估中，还有一项是爆发半径不可控的风险，对于这个风险，可以从测试右移的思路来控制风险爆发半径，有以下几种做法：
测试右移：由于测试环境的局限性，我们需要针对生产环境做一定的回归测试（对于只读操作和可隔离特性的测试），针对核心功能进行一定频次的拨测，确认功能的稳定性。
告警机制：通过蓝绿发布、灰度发布、监控预警，建立分级告警机制等手段，可以有效地控制风险爆发半径，减少损失。
05
系统可能很脆弱，会因为开发的一段代码导致整个系统不可用。作为测试，从流程上规范研发操作只是提升系统反脆弱的一种方法，而且是一种非常被动的操作。我们应该建立起一套完善的质量保障体系，在风险可控的情况下，让开发有重构和优化的空间，为他们的行为保驾护航，提升系统的反脆弱性。
业内其实有很多这类的实践，比如混沌测试。虽然我们的代码经不起混沌测试的折腾，但也不应该因为小部分的重构和优化，让系统出现不可控的风险。
共勉。
