博客

如果说到最困扰软件测试工程师的几大问题，我们最先能想到的无非是以下几点：

需求带着小姨子跑路啦，没有需求我咋测试啦。。。

开发牛皮哄哄啦，他打了我，还说我报的不是BUG。。。

测试时间不够啦，项目质量这么烂怎么还要上线啦，人家不要面子的吗。。。

还有，今天又有人问我，‘

这个Bug你怎么没测试出来呢？

‘。。。

没错相信每一位测试工程师都经历过这样的苦恼，那就是

背锅

！

怎么别的小哥哥小姐姐都是C位出道，我们却他喵的是

背锅位

出道。。。

做为一个测试工程师，背锅你怕了吗。今天我们就要拉起横幅，贴起大字报：

对背锅说不！

不想背锅怎么办哦，躲在桌子底下也躲不过去的样子。那要怎么办？很简单，

甩锅！

下面我们就来教大家怎么甩锅：

首先，我们的前提是，你的本职测试工作要高质量的完成。

如果说测试覆盖的不足，粗心大意导致我们遗漏了重要问题，被带入了后期阶段甚至是上线以后。那么

我们首先要想的不应该是甩锅和推卸责任

。

那么第一件要做的事情就是对问题进行回顾，分析到底类似这样的问题遗漏，究竟是不是由我们个人的工作失职所造成的。

如果确实我们确实在测试过程中由于自己的失误而带来了问题，那么我们应该勇于承认自己工作的不足，并对相关利益相关方表达诚恳的歉意。

承认问题还不是最重要，更重要的是我们要主动去总结在事件发生过程中我们的失误所在，并提出改进的思路和方法。所谓亡羊补牢为时未晚，这样诚恳和负责任的态度相信会帮助你去缓解工作失误所带来的指责和信心缺失。一般来说，如果不是重大失误，我们的团队也不会过多的追究这种问题。

其次，我们可以去对事件发生的过程进行流程上的回溯。

我们的测试不是独立存在的事物，我们的测试团队也不是独立存在的团队，我们测试活动也是环环相扣的一种链条式工程。测试工作是研发团队里依赖性最强的工种，我们最终工作的产出，与我们的上游流程的完备程度是息息相关的。

那么在发生事件的过程中，如果我们在回顾自己的测试工作，确实没有发现自己工作的明显失职，那么

我们就要回溯到我们工作的上游，看看是不是哪个环节最终导致了问题的发生

。

测试执行工作的上游工作是什么，从近往远来说，就是：测试设计，测试分析，测试计划，编码开发，产品设计，产品分析，项目需求。

这其中任意环节如果出现问题，甚至可能只是小瑕疵小波浪，都有可能在下游发展成洪涝。

比如说，一个具有二义性的需求，就可能导致开发和测试对于某个功能点有着完全南辕北辙的理解。那么最终这种理解的偏差，就会体现在测试的实现上，造成最终环节的问题。

又比如说，在测试计划的阶段，也许就对测试的覆盖方面估算不足-比如丢失了可用性测试内容-最终导致测试执行阶段对产品某方面特性质量把控的缺失。

所以，我们可以去回溯我们测试执行的上游流程，找出导致问题的根源所在。进而我们需要将我们的发现，合理的去阐述给我们的管理团队直属领导，只要我们的依据属实，相信就可以减轻我们对于事件的责任，更好的一个情况是还可以促进项目流程的改进，防止以后出现类似问题。

当然，在阐述的过程中，一个诚恳和中立的态度是有帮助的，毕竟你有可能将加之于你的指控，导向了另一个环节或个体的工作上去。

再次，我们要摆事实，讲道理

。

我们要知道，

测试本身就不是万能的

，不是完美的。我们的测试七大核心原则中也强调，我们不应该追求一个完全的测试（即找到所有问题）。

我们的测试过程本身是一项系统工程，它本身就是有局限性的。比如我们的测试执行，每次执行的轮次是有一定时间鸿沟的。在现在的软件开发大环境下，持续集成的理念被广泛应用，系统的迭代和增量每天都在发生。这些迭代和增量每一个都有可能对我们已测过的功能产生冲击甚至造成破坏，我们的测试不可能每天都跟随的代码更新去覆盖，就算使用非常高水平的自动化测试去覆盖回归测试，也是避免不了在我们测试完成之后，系统功能又被破坏的。

这种情况下，我们就要阐述，甚至跟利益相关方去科普我们的测试理念，测试的局限性。我们摆事实-拿出我们的测试过程记录和缺陷记录，去告诉相关方：我们的测试是没有问题的，是提供了足够覆盖的，只是在我们的测试实施完毕之后，代码又因为新的迭代而引入了问题，这不是我们能随时控制的。

还有我们的系统测试毕竟是在一个测试环境上去执行的，我们虽然会尽力让测试环境与生产环境尽量接近，但是一般是不可能达到完全重现的。比如我们所采用的服务器的量级，我们的内网测试环境，我们的测试数据的数量级以及一些真实环境中可能出现的突发情况，我们都不能完全的模拟。而这种差别最终导致我们系统测试阶段不能发现一些生产环境中的问题，那么当然不能归结成我们工作的失误。遇到这种情况，我们就要阐述清楚问题的所在，也可以去展示我们的测试环境的限制（比如在测试环境中重复bug的重现流程，它并不能在测试环境中复现）。

再次，我们要将测试的过程进行合理的归档。

我们测试的产出其实不单单是测试计划文档，缺陷报告，测试总结报告这些东西。其实测试的执行过程和记录也是一种很重要的归档，测试的执行过程记录，做为我们测试工作的完备程度的支撑是非常有效的。

在日常工作中，我们还可以使用小段的时间，对我们的测试工作进行更多的归档。比如说，我们可以去记录每天的测试工作日志；可以去通过邮件和讨论群组进行测试过程的报告汇总；对于一些文档轻量化的工作，比如探索性测试，随机测试，我们也要去列出测试的纲领和记录过程；测试用例更是有时间写，就一定要去写去编排，就算没有时间也要去写测试大纲和条目。

有了这些文档，在遇到锅从天降的情况时，我们就可以拿出这些文档，对我们当时的工作情况进行回顾并用他们来支持我们工作没有问题的论点。

========================================================================================================================================================

以后再遇到这样的情况，不要恐慌不要烦恼，如果是问题我们就承认它是问题；但如果不是我们的问题，那这个锅我们可不接！