测试人员的自我修养

本文主要是介绍测试人员的自我修养，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

QAS:是负责检查和评估软件产品质量的专业人员，他们通过执行一系列测试来确保软件产品的功能、性能和安全性符合设计要求。

当产品上线后，有 bug：

“测试为什么没有测试发现这个问题？肯定是测试的责任！”

当产品上线后，用户反馈使用体验不太好：

“测试为什么没有想着去提高用户的体验？”

当用户的 bug 测试也发现，但是开发没有修复时：

“测试为什么不找产品经理确认？这么严重 bug 测试要让开发修复的啊！”

当产品上线没有 bug，反馈良好的时候：

“咱们开发还是很靠谱的，做出来的东西质量杠杠的！”

以上的场景，就是大家非常熟悉的测试“大型背锅现场”！

那么，这些锅我们可以甩出去吗？

当然是可以的！接下来给大家普及一下，测试猿如何优雅的甩锅！

测试猿甩锅秘籍

一、过硬的专业技能，塑造避锅铜墙铁壁

强大的测试思维，可以设计出周密的测试用例，测试覆盖更加全面；

从提高自己的专业技术出发，不管是从测试点的提取，还是从测试用例的设计和编写，都做到极度专业，能够设计出来覆盖非常全的测试用例，那么出现在用户面前的 bug 和问题就会越少，自然也就不会有锅从天上来了；

规范的测试流程，可以让开发、产品、测试一起来评审测试用例，保证测试质量；

其实很多公司有很多用户的问题和 bug，根本原因是测试流程不是很规范：比如需求确定了之后，没有需求评审，开发和测试各做各自的，没有达到理解的一致性；比如测试用例写完没有用例评审和规范，就会容易出现一些漏测和错测的情况，也就自然用户反馈的问题会增多；所以，一个成熟且规范的测试流程，是保证产品质量的前提和基础；

详细的 bug 记录和缺陷跟踪流程，提高测试效率同时，也可以让发现的 bug 有迹可循。

发现的 bug 不管是必现还是偶现的都应该要记录到缺陷管理平台，做好跟踪；如果是开发没有修复的 bug，不管是什么原因（延期，无效 bug，重复 bug，无法复现等）都要做好跟进和备注；以后如果用户发现类似的问题，可以从自己的 bug 管理工具里找到对应的问题的记录和参与人员，可以合理的“规避责任”。

专业的技能和工具的使用，让测试工作更加高效和彻底

让自己掌握更多更专业的技能，能够更加深入的分析问题和缺陷；比如数据库的使用，抓包工具（fiddler、Charles 等）的使用，网络协议相关的知识（HTTP 协议、HTTPS 协议等），接口测试工具（Jmeter、Postman 等）；这些技能可以让测试更加掌握项目中的主导地位，让你说的话有理有据，更有说服力；因为减少“背锅”的命运的发生；

二、良好的职场习惯，是“甩锅”必备良药

遇到冲突和歧义，先主动沟通，最后找产品/项目经理确定拍板

当测试和开发之间有问题的理解和认知达不到一致的时候，一定要先主动沟通，推动事情的进程；比如开发说测试开的 bug 不是 bug，测试不要一味的认同开发，也不要盲目的反对的开发，要主动联系沟通具体的原因，并站在用户的角度和基于需求的基础上罗列需要修复 bug 的证据；如果主动沟通依然无法达到一致，一定要找到可以拍板的人--比如产品经理、比如项目经理沟通，确认这个 bug 的是否要修复；

主动沟通，一方面避免问题可以有效的推动问题的解决，一方面可以由多方分析和确认问题而避免导致重要 bug 的修复遗漏。

凡事留好证据，做好责任规避

在职场总是会有一些人将说过的事情被动或者主动的忘记，所以如果是一些重要的问题的结论和决策，我们一定要保留好相关的证据。

比如上面讲的案例，开发和测试的关于这个 bug 是否要修复的问题，最终得到了产品经理的确认说不修复了，那么这个结论一定要保留下文字或者图片的证据，添加到 bug 的备注里；这样，如果万一以后用户也遇到同样的问题，就可以把这个 bug 找出来，并找到当初不修复这个原因，测试就不会是这个问题的”背锅侠”了；

还有类似的相关的问题，都要做好右键、文字截图等证据，方便需要的时候用作甩锅的证据。