这种情况下，我们就要阐述，甚至跟利益相关方去科普我们的测试理念，测试的局限性。我们摆事实-拿出我们的测试过程记录和缺陷记录，去告诉相关方：我们的测试是没有问题的，是提供了足够覆盖的，只是在我们的测试实施完毕之后，代码又因为新的迭代而引入了问题，这不是我们能随时控制的。
还有我们的系统测试毕竟是在一个测试环境上去执行的，我们虽然会尽力让测试环境与生产环境尽量接近，但是一般是不可能达到完全重现的。比如我们所采用的服务器的量级，我们的内网测试环境，我们的测试数据的数量级以及一些真实环境中可能出现的突发情况，我们都不能完全的模拟。而这种差别最终导致我们系统测试阶段不能发现一些生产环境中的问题，那么当然不能归结成我们工作的失误。遇到这种情况，我们就要阐述清楚问题的所在，也可以去展示我们的测试环境的限制（比如在测试环境中重复bug的重现流程，它并不能在测试环境中复现）。
再次，我们要将测试的过程进行合理的归档。
我们测试的产出其实不单单是测试计划文档，缺陷报告，测试总结报告这些东西。其实测试的执行过程和记录也是一种很重要的归档，测试的执行过程记录，做为我们测试工作的完备程度的支撑是非常有效的。
在日常工作中，我们还可以使用小段的时间，对我们的测试工作进行更多的归档。比如说，我们可以去记录每天的测试工作日志；可以去通过邮件和讨论群组进行测试过程的报告汇总；对于一些文档轻量化的工作，比如探索性测试，随机测试，我们也要去列出测试的纲领和记录过程；测试用例更是有时间写，就一定要去写去编排，就算没有时间也要去写测试大纲和条目。
有了这些文档，在遇到锅从天降的情况时，我们就可以拿出这些文档，对我们当时的工作情况进行回顾并用他们来支持我们工作没有问题的论点。
========================================================================================================================================================
好了说了这么多，相信会对做为软件测试工程师的你有所帮助，这个话题我们就说到这。
以后再遇到这样的情况，不要恐慌不要烦恼，如果是问题我们就承认它是问题；但如果不是我们的问题，那这个锅我们可不接！