对于IT行业来说，无论任何一个项目，都没人敢保证所负责的项目无bug。对于上线的产品，通过对目前市场的发现，如果线上产品出了问题，绝大多数人都会认为是测试人员没有测到，导致问题没有解决。
然而作为测试人员，我们该怎么保护自身呢
首先
1、你需要充分了解每次发布的重点设计的变更
2、制定有效的测试计划
3、设计有效的测试用例
4、与相关人员探讨并改进
5、要随时掌握研发进度
6、对任何可能影响到测试的变动要非常敏感，并及时做出反应或者修改测试计划、测试用例或汇报测试风险
7、还可以了解程序员的编码习惯，知道哪个程序的代码易产生bug
其次
1、每个版本都要对bug做出分析
bug产生的阶段：需求期？设计期？代码期？......
bug产生的原因：需求不明确？设计错误？代码失误？测试环境局限或数据不足？培训不到位相关人员没理解功能？......
为什么没有在测试阶段发现：测试用例设计失误？研发流程不完善？测试资源不足？测试时间太紧张？测试人员失误？......
2、针对整个项目测试分析
测试覆盖分析
产品bug分布：哪个功能bug成堆，哪个模块频繁出现严重bug，哪类功能升级或bug修复会引发大规模bug产生......
测试用例效率分析：平均一个测试用例发现多少bug，针对不同模块哪类测试用例最有效......
测试效率分析：测试的每个阶段消耗资源情况
研发流程回顾：整个研发流程中，哪部分好，哪部分需要改进
同类项目对比：与同类其他项目比，本次测试在上述方面好在哪里，差在哪里，原因是什么，如何改进
如果这些我们都做到了，面对上司我们可以用数据和事实说话，你就能掌握更多的主动权。
比如你提到的测试只有1-2天，一个月测了多个版本，我们可以理解成你这是在抱怨工作量太大，测试忙不过来。但是如果我是老板，感情上可以理解，但是理智上我肯定不接受这样的抱怨。
因此，我们面对老板可以换种表达方式，可以向老板介绍说，按以往同类项目的经验，这个测试需要5天能达到比较理想的测试结果，原因是......，如果只有2天，我将运用......测试方案，重点测试某某功能模块，保证本次发布的要点被测到，但是我将不能覆盖某某模块，因此可能会产生......风险，请问您有什么建议呢？
但是上述中的某某和......需要你用有力的数据支撑，如果你能说出这些强有力的数据，并能应对你的老板针对你的说的内容可能提出的问题，说明你对测试工作很了解，对被测产品很了解。那么你的测试计划应该是周密的，产品的质量是可预测并可控的，风险和意外的几率是低的，就算最终真的出现质量问题，应该也影响不大。
但是如果你预估的合理工作量为10天，但是老板只能给出2天，而老板又不能给出可行方案，又不能说出正当理由，那么说明你的老板不了解这份工作，也不支持你的工作。面对这样的老板，你可以考虑换个能赏识你的老板了。
网友评论