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