是谁的责任的问题我就不回答了 

就算全世界的软件研发理论都认为测试不能发现100％的bug,且整个研发团队需要对bug负责

然并卵 

最终命中的炮灰大部分时候仍然是测试人员  

我来说说怎么办 

测试人员需要怎么有理有据地保护自己  

首先 

事前诸葛亮要当 

你需要充分了解每次发布的重点设计的变更 

制定有效的测试计划 

设计有效的测试用例 

与相关人员review并改进 

要随时掌握研发进度 

对任何可能影响到测试的变动要非常敏感 

并及时做出反应 

或者修改测试计划测试用例或者汇报测试风险 

你甚至要了解程序员的编码习惯 

知道哪个程序员代码质量可靠哪个是bug大王 

对bug大王要掌握他们常犯的代码错误  

其次 

事后诸葛亮的事必须要做而且要做好 

而且非常非常非常非常重要  

没有这一步 

你就没有日后发言的主动权 

你的测试效率也不会太高 

你负责的产品的质量也不可控   

条 

每个post-relese bug都应该做以下分析 

－bug的产生阶段：需求期？设计期？代码期？等等 

－bug的产生原因：需求不清楚？设计错误？代码失误？测试环境局限或数据不足？培训不到位相关人员没理解功能？等等 

－为什么没有在测试阶段发现：测试用例设计失误？研发流程不完善？测试资源不足？测试时间太紧张？测试人员失误？等等 

－以后项目中避免同类bug的方案  

第二条 

针对整个项目测试做以下分析 

－测试coverage分析 

－产品bug分布：哪个功能bug成堆，哪个模块总有严重bug，哪类功能升级或bug修复会引发大规模bug爆发，等等 

－测试用例效率分析：平均一个测试用例发现多少bug，针对不同模块哪类测试用例有效，等等 

－测试效率分析：测试的每个阶段消耗资源情况 

－研发流程回顾：整个研发流程中，哪部分好，哪部分需要改进，如何改进 

－同类项目对比：与同类其他项目比，本次测试在上述方面好在哪儿差在哪儿原因为何如何改进  

如果你把这些都做了 

用数据说话 

用事实说话 

你就掌握了更多的主动权  

比如你提到的测试只有1－2天 

一个月测了几个版本 

我理解你是在抱怨工作量太大测不过来 

但如果我是你老板 

感情上我可以理解 

但理智上我肯定不接受这样的抱怨  

建议你换一种说法： 

老板 

按以往同类项目经验 

这个测试需要3天能够达到比较理想的测试结果 

原因是啥啥啥 

如果只有2天 

我将运用啥啥啥测试方案 

重点测试啥啥功能啥啥模块 

保证本次发布的要点被测到 

我将不能覆盖啥啥啥测试啥啥啥功能啥啥啥模块 

因此可能的质量风险是啥啥啥 请问您有什么建议？  

很显然 

上述那些啥啥啥 

需要你有强有力的数据支撑 

如果你能说出这些内容 

并能应对你的老板针对你说的这些内容可能提出的问题 

说明你对测试工作很了解 

对被测产品很了解 

那么你的测试计划应该是周密的 

产品的质量是可预测并可控的 

风险和意外的几率是低的 

就算最终真的出现质量问题 

应该也不会是大问题 

加上事后诸葛亮的处理 

这些问题再次发生的几率也会非常非常低  

如果你没有这些数据说不出这些话 

说明你还没有成为一名合格的测试人员

请联系网站，了解详细的优惠课程信息~
优质、、便捷、省心