共计 2527 个字符，预计需要花费 7 分钟才能阅读完成。
- 对测试人员来讲，什么事件比拟难堪？——线上出问题。
- 再难堪一点儿呢？——没测到，线上出问题。
- 最难堪呢？——明明测到了，线上还是出问题。
场景 1：没测到，生产环境出问题
预料之内情理之中，这太失常了。没测到出了问题不该诧异，没出问题才该烧香。此时不应指摘出问题，而应思考没测到的起因是什么。第一反馈是测试人员脱漏了，如同也没更多起因。但当咱们把视角切换到实在研发过程中，就会发现没测到的起因切实太多了！
- 没思考到，测试漏测了
这真是测试的锅，测试人员的确应该全面了解业务，设计高效笼罩的用例集。但在功能设计时如有良好布局，能够缩小没想到造成的漏测。
- 思考到了，但还是没测
个别是工夫紧工作急，来不及测，但又没向团队裸露危险。多半也是测试的尽职。
- 不可抗力必须上线，来不及测
大家分明的晓得危险，但遇到不可抗力，如法律法规等，无奈实现全副测试就必须上线，这种状况咱们且上且察看，独特承担风险，并充沛思考线上事变的紧急预案。
- 流程问题，未经测试就上线
开发本人上线了性能，没通过测试人员测试，也没有充沛自测。这种鬼故事在过来的职业生涯中我至多见过 5 次。还是不能寄希望于人的专业性，应更多依赖于可控可追溯的流程体系来保障。
- 大家认同不须要测，间接上
比方批改文案，或做简略的图片替换等。越是认为没问题的，往往越出幺蛾子。就好比咱们埋头苦干往往没人看，刚要划水，低头就是老板清静如水的眼光。软件就跟成精了一样，分分钟教你做人，品质工作真是一丝都不能倦怠。
- 所有人都没想到，就没测
之前的一个我的项目上，既有惯例性能的迭代上线，又有非凡性能只迭代不上线，为了好辨别，咱们为不上线的性能做了开关，其实代码都下来了，只是 Feature 没关上。一次规模稍大的惯例上线部署实现后，依照常规验证生产环境，测试人员诧异地发现本该关着的性能被关上了，不该呈现的性能呈现了。于是连忙把开关关掉，并排查起因，发现是有一个数据库脚本把开关数据导到生产环境了。从此以后，每次上线咱们都会查看所有 Feature Toggle 的状态。
以上列举了一些起因，可能还有其余更多起因。不论什么起因没测到，究竟还是让缺点逃逸到生产了。但只有咱们找到没测到的起因，有针对性地改良，还是比拟容易防止这类问题的。
场景 2：明明测了，生产环境还出问题
常在河边走哪有不湿鞋，测了还出事儿，这才是该狐疑人生的场景。这种状况往往问题也不好排查，通常是先连忙排查问题，肯定工夫窗内找不到问题或无奈疾速解决，哪怕先回滚呢，预先咱们再认真复盘。测了还出事儿其实并不少见，起因也同样有很多。
- 认为测了，其实没测
因为测试人员对业务了解不够充沛，或者测试设计能力有余，认为曾经充沛测试了，但其实脱漏了比拟要害的测试用例。这类问题能够间接等同于场景 1 中的某种状况。
- 环境差异性
因为生产环境和测试环境的差异性导致测试后果的生效。无妨脑洞一下，都有哪些因素造成了环境差别？比方软件配置上的差别：数据库账户、接口配置、服务和端口、第三方插件、集成服务、不同的利用渠道等……或者其余硬件上的差别。这种状况下可能并不是被测软件自身的缺点，但因为环境差异性导致了测试环境通过的用例，在生产环境下失去了不同的后果。
- 数据差异性
因为测试数据的差异性导致的生产环境缺点并不少见。在测试环境，测试人员选取典型的测试数据进行测试，或者是批量生成的有肯定法则的测试数据。这些数据可能用着棘手每次都会被复用，也可能造成了针对特定业务的测试数据集。这是好事儿，但往往就像耐药性一样，这些被测软件用习惯的数据不利于揭示新的或暗藏的缺点。而在生产环境，因为用户量大、操作不标准、实在业务的复杂性等起因，使得生产环境的数据更具备多样性，这就给测试后果的准确性带来更大的挑战。
- 用户量级 / 业务量级差异性
这其实也是数据差异性的一种，单提出来是因为引发的缺点不同，上一种状况引发的是特定测试用例的后果不精确，或者说是一般的缺点。而因为业务量级不同引发的往往是性能缺点，高并发、大量沉积的业务数据造成服务中断等，这些状况引发的缺点往往业务影响更大，定位、修复和性能调优的难度也更大。哪怕在测试环境进行了充沛的性能测试，也极有可能在生产环境并行大量其余业务的条件下，造成劫难般的性能缺点。
- 其余集成问题
与集成方约定的上线工夫、切换动作、兼容形式、集成验证等，都有可能在测试环境和生产环境有所不同。因而，在上线后与集成方一起验证集成性能的正确性十分必要。毕竟相比于本人的软件缺陷，集成引起的缺点可控性更差，修复周期也更长。应尽早发现这类缺点，免得造成更大的损失。
- 上线不齐全
这就更诡异了，软件性能齐全没问题，各种差异性也已排除或修复，但依然可能因为公布问题死在线上。因为公布自身的复杂性、上线性能较多、服务间性能耦合、或是上线步骤繁琐、手动操作过多等起因，都有可能引起上线不残缺，一部分要害代码没有上线。这类问题好发现好排查，但着实恶心人，本不应产生。
测试到底该解决什么问题？
先上论断，相比于发现更多缺点，我认为测试最应该解决的问题是：
（每个字都很重要）
排除
用户或客户
对软件的预期
和软件真正的体现
在生产环境上的
差别
具体怎么做呢？可参考以下列表逐渐递进地欠缺实际：
- 充沛理解被测业务
- 晋升测试设计能力
- 在测试环境，确保软件业务性能没问题
- 充沛思考环境差异性
- 排除数据差异性，用多样化的数据进行测试
- 排除或尽力束缚集成方问题
- 在预生产环境进行残缺的回归测试和公布演练（在公布过程简单或对公布工夫限度较严格时可选）
- 对公布后可能呈现的危险进行预判，确认疾速复原机制
- 采纳自动化流程、公布预演等实际，确保软件齐全公布
- 实现上线后，立刻对生产环境进行容许的测试和测验
- 投产应用后，继续监控服务日志和业务数据
本文就进行到这儿了。大家遇到过哪些相似的“血泪故事”呢？欢送分享和探讨。
起源：圆小豆的美梦工场
作者：于晓南
申明：文章取得作者受权在 IDCF 社区公众号（devopshub）转发。优质内容共享给思否平台的技术伙伴，如原作者有其余思考请分割小编删除，致谢。
IDCF【冬哥有话说】收费直播，关注公众号回复“冬哥”获取地址
- 10 月 21 日（周四）晚 8 点，丰志强分享《组织级麻利转型》
- 10 月 28 日（周四）晚 8 点，钱勇分享《toB SaaS 从策略到产品经营的天龙八步》
