我测了啊，我真测了！

对测试人员来讲，什么事情比较尴尬？
——线上出问题。

再尴尬一点儿呢？
——没测到，线上出问题。

最尴尬呢？
——明明测到了，线上还是出问题。

场景1：没测到，生产环境出问题

意料之内情理之中，这太正常了。没测到出了问题不该惊讶，没出问题才该烧香。此时不应指责出问题，而应思考没测到的原因是什么。第一反应是测试人员遗漏了，好像也没更多原因。但当我们把视角切换到真实研发过程中，就会发现没测到的原因实在太多了！

1. 没考虑到，测试漏测了
   这真是测试的锅，测试人员确实应该全面理解业务，设计高效覆盖的用例集。但在功能设计时如有良好规划，可以减少没想到造成的漏测。

2. 考虑到了，但还是没测
   一般是时间紧任务急，来不及测，但又没向团队暴露风险。多半也是测试的失职。

3. 不可抗力必须上线，来不及测
   大家清楚的知道风险，但遇到不可抗力，如法律法规等，无法完成全部测试就必须上线，这种情况我们且上且观察，共同承担风险，并充分思考线上事故的紧急预案。

4. 流程问题，未经测试就上线
   开发自己上线了功能，没经过测试人员测试，也没有充分自测。这种鬼故事在过去的职业生涯中我至少见过5次。还是不能寄希望于人的专业性，更多应依赖于可控可追溯的流程体系来保证。

5. 大家认同不需要测，直接上
   比如修改文案，或做简单的图片替换等。越是认为没问题的，往往越出幺蛾子。就好比我们埋头苦干往往没人看，刚要划水，抬头就是老板清静如水的目光。软件就跟成精了一样，分分钟教你做人，质量工作真是一丝都不能倦怠。

6. 所有人都没想到，就没测
   之前的一个项目上，既有常规功能的迭代上线，又有特殊功能只迭代不上线，为了好区分，我们为不上线的功能做了开关，其实代码都上去了，只是Feature没打开。一次规模稍大的常规上线部署完成后，按照惯例验证生产环境，测试人员惊讶地发现本该关着的功能被打开了，不该出现的功能出现了。于是连忙把开关关掉，并排查原因，发现是有一个数据库脚本把开关数据导到生产环境了。从此以后，每次上线我们都会检查所有Feature Toggle的状态。

以上列举了一些原因，可能还有其他更多原因。不管什么原因没测到，终究还是让缺陷逃逸到生产了。但只要我们找到没测到的原因，有针对性的改进，还是比较容易避免这类问题的。

场景2：明明测了，生产环境还出问题

常在河边走哪有不湿鞋，测了还出事儿，这才是该怀疑人生的场景。这种情况往往问题也不好排查，通常是先赶紧排查问题，一定时间窗内找不到问题或无法快速解决，哪怕先回滚呢，事后我们再仔细复盘。测了还出事儿其实并不少见，原因也同样有很多。

1. 以为测了，其实没测
   由于测试人员对业务理解不够充分，或者测试设计能力不足，以为已经充分测试了，但其实遗漏了比较关键的测试用例。这类问题可以直接等同于场景1中的某种情况。

2. 环境差异性
   由于生产环境和测试环境的差异性导致测试结果的失效。不妨脑洞一下，都有哪些因素造成了环境差异性？比如软件配置上的差异：数据库账户、接口配置、服务和端口、第三方插件、集成服务、不同的应用渠道等……或者其他硬件上的差异。这种情况下可能并不是被测软件本身的缺陷，但由于环境差异性导致了测试环境通过的用例，在生产环境下得到了不同的结果。

3. 数据差异性
   由于测试数据的差异性导致的生产环境缺陷并不少见。在测试环境，测试人员选取典型的测试数据进行测试，或许是批量生成的有一定规律的测试数据。这些数据可能用着顺手每次都会被复用，也可能形成了针对特定业务的测试数据集。这是好事，但往往就像耐药性一样，这些被测软件用习惯的数据不利于揭示新的或隐藏的缺陷。而在生产环境，由于用户量大、操作不规范、真实业务的复杂性等原因，使得生产环境的数据更具备多样性，这就给测试结果的准确性带来更大的挑战。（可参考文末推荐阅读文章了解更多内容）

4. 用户量级/业务量级差异性
   这其实也是数据差异性的一种，单提出来是因为引发的缺陷不同，上一种情况引发的是特定测试用例的结果不准确，或者说是普通的缺陷。而由于业务量级不同引发的往往是性能缺陷，高并发、大量堆积的业务数据造成服务中断等，这些情况引发的缺陷往往业务影响更大，定位、修复和性能调优的难度也更大。哪怕在测试环境进行了充分的性能测试，也极有可能在生产环境并行大量其他业务的条件下，造成灾难般的性能缺陷。

5. 其他集成问题
   与集成方约定的上线时间、切换动作、兼容方式、集成验证等，都有可能在测试环境和生产环境有所不同。因此，在上线后与集成方一起验证集成功能的正确性非常必要。毕竟相比于自己的软件缺陷，集成引起的缺陷可控性更差，修复周期也更长。应尽早发现这类缺陷，以免造成更大的损失。

6. 上线不完全
   这种就更诡异了，软件功能完全没问题，各种差异性也已排除或修复，但仍然可能因为发布问题死在线上。由于发布本身的复杂性、上线功能较多、服务间功能耦合、或是上线步骤繁琐、手动操作过多等原因，都有可能引起上线不完整，一部分关键代码没有上线。这类问题好发现好排查，但着实恶心人，本不应发生。

测试到底该解决什么问题？

先上结论，相比于发现更多缺陷，我认为测试最应该解决的问题是（每个字都很重要）：

排除
用户或客户
对软件的预期
和软件真正的表现
在生产环境上的
差异

具体怎么做呢？可参考以下列表逐步递进地完善实践：

1. 充分了解被测业务
2. 提升测试设计能力
3. 在测试环境，确保软件业务功能没问题
4. 充分思考环境差异性
5. 排除数据差异性，用多样化的数据进行测试
6. 排除或尽力约束集成方问题
7. 在预生产环境进行完整的回归测试和发布演练（在发布过程复杂或对发布时间限制较严格时可选）
8. 对发布后可能出现的风险进行预判，确认快速恢复机制
9. 采用自动化流程、发布预演等实践，确保软件完全发布
10. 完成上线后，立即对生产环境进行允许的测试和检验
11. 投产使用后，持续监控服务日志和业务数据

本文就进行到这儿了。大家遇到过哪些类似的血泪故事呢？欢迎分享和讨论。
——————————————————————————————————————————

推荐阅读
1.《生产环境又有问题？都是脏数据惹的祸！》
2.《一次Testing in Production方案的探索》