来源：圆小豆的美梦工场
作者：于晓南
意料之内情理之中，这太正常了。没测到出了问题不该惊讶，没出问题才该烧香。此时不应指责出问题，而应思考没测到的原因是什么。第一反应是测试人员遗漏了，好像也没更多原因。但当我们把视角切换到真实研发过程中，就会发现没测到的原因实在太多了！
这真是测试的锅，测试人员确实应该全面理解业务，设计高效覆盖的用例集。但在功能设计时如有良好规划，可以减少没想到造成的漏测。一般是时间紧任务急，来不及测，但又没向团队暴露风险。多半也是测试的失职。大家清楚地知道风险，但遇到不可抗力，如法律法规等，无法完成全部测试就必须上线，这种情况我们且上且观察，共同承担风险，并充分思考线上事故的紧急预案。开发自己上线了功能，没经过测试人员测试，也没有充分自测。这种鬼故事在过去的职业生涯中我至少见过5次。还是不能寄希望于人的专业性，应更多依赖于可控可追溯的流程体系来保证。比如修改文案，或做简单的图片替换等。越是认为没问题的，往往越出幺蛾子。就好比我们埋头苦干往往没人看，刚要划水，抬头就是老板清静如水的目光。软件就跟成精了一样，分分钟教你做人，质量工作真是一丝都不能倦怠。之前的一个项目上，既有常规功能的迭代上线，又有特殊功能只迭代不上线，为了好区分，我们为不上线的功能做了开关，其实代码都上去了，只是Feature没打开。一次规模稍大的常规上线部署完成后，按照惯例验证生产环境，测试人员惊讶地发现本该关着的功能被打开了，不该出现的功能出现了。于是连忙把开关关掉，并排查原因，发现是有一个数据库脚本把开关数据导到生产环境了。从此以后，每次上线我们都会检查所有Feature Toggle的状态。以上列举了一些原因，可能还有其他更多原因。不管什么原因没测到，终究还是让缺陷逃逸到生产了。但只要我们找到没测到的原因，有针对性地改进，还是比较容易避免这类问题的。常在河边走哪有不湿鞋，测了还出事儿，这才是该怀疑人生的场景。这种情况往往问题也不好排查，通常是先赶紧排查问题，一定时间窗内找不到问题或无法快速解决，哪怕先回滚呢，事后我们再仔细复盘。测了还出事儿其实并不少见，原因也同样有很多。
由于测试人员对业务理解不够充分，或者测试设计能力不足，以为已经充分测试了，但其实遗漏了比较关键的测试用例。这类问题可以直接等同于场景1中的某种情况。由于生产环境和测试环境的差异性导致测试结果的失效。不妨脑洞一下，都有哪些因素造成了环境差异？比如软件配置上的差异：数据库账户、接口配置、服务和端口、第三方插件、集成服务、不同的应用渠道等……或者其他硬件上的差异。这种情况下可能并不是被测软件本身的缺陷，但由于环境差异性导致了测试环境通过的用例，在生产环境下得到了不同的结果。由于测试数据的差异性导致的生产环境缺陷并不少见。在测试环境，测试人员选取典型的测试数据进行测试，或许是批量生成的有一定规律的测试数据。这些数据可能用着顺手每次都会被复用，也可能形成了针对特定业务的测试数据集。这是好事儿，但往往就像耐药性一样，这些被测软件用习惯的数据不利于揭示新的或隐藏的缺陷。而在生产环境，由于用户量大、操作不规范、真实业务的复杂性等原因，使得生产环境的数据更具备多样性，这就给测试结果的准确性带来更大的挑战。这其实也是数据差异性的一种，单提出来是因为引发的缺陷不同，上一种情况引发的是特定测试用例的结果不准确，或者说是普通的缺陷。而由于业务量级不同引发的往往是性能缺陷，高并发、大量堆积的业务数据造成服务中断等，这些情况引发的缺陷往往业务影响更大，定位、修复和性能调优的难度也更大。哪怕在测试环境进行了充分的性能测试，也极有可能在生产环境并行大量其他业务的条件下，造成灾难般的性能缺陷。与集成方约定的上线时间、切换动作、兼容方式、集成验证等，都有可能在测试环境和生产环境有所不同。因此，在上线后与集成方一起验证集成功能的正确性非常必要。毕竟相比于自己的软件缺陷，集成引起的缺陷可控性更差，修复周期也更长。应尽早发现这类缺陷，以免造成更大的损失。这就更诡异了，软件功能完全没问题，各种差异性也已排除或修复，但仍然可能因为发布问题死在线上。由于发布本身的复杂性、上线功能较多、服务间功能耦合、或是上线步骤繁琐、手动操作过多等原因，都有可能引起上线不完整，一部分关键代码没有上线。这类问题好发现好排查，但着实恶心人，本不应发生。先上结论，相比于发现更多缺陷，我认为测试最应该解决的问题是：（每个字都很重要）
充分了解被测业务；
提升测试设计能力；
在测试环境，确保软件业务功能没问题；
充分思考环境差异性；
排除数据差异性，用多样化的数据进行测试；
排除或尽力约束集成方问题；
在预生产环境进行完整的回归测试和发布演练（在发布过程复杂或对发布时间限制较严格时可选）；
对发布后可能出现的风险进行预判，确认快速恢复机制；
采用自动化流程、发布预演等实践，确保软件完全发布；
完成上线后，立即对生产环境进行允许的测试和检验；
投产使用后，持续监控服务日志和业务数据。
本文就进行到这儿了。大家遇到过哪些类似的“血泪故事”呢？欢迎分享和讨论。IDCF DevOps黑客马拉松，独创端到端DevOps体验，精益创业+敏捷开发+DevOps流水线的完美结合，2021年仅有的3场公开课，数千人参与并一致五星推荐的金牌训练营，追求卓越的你一定不能错过！
11月6-7日，深圳站，企业组队参赛&个人参赛均可，一年等一回，错过等一年，赶紧上车~👇
