是誰的責任的問題我就不回答了

就算全世界的軟件研發(fā)理論都認為測試不能發(fā)現100％的bug,且整個研發(fā)團隊需要對bug負責

然并卵

最終命中的炮灰大部分時候仍然是測試人員

我來說說怎么辦

測試人員需要怎么有理有據地保護自己

首先

事前諸葛亮要當

你需要充分了解每次發(fā)布的重點設計的變更

制定有效的測試計劃

設計有效的測試用例

與相關人員review并改進

要隨時掌握研發(fā)進度

對任何可能影響到測試的變動要非常敏感

并及時做出反應

或者修改測試計劃測試用例或者匯報測試風險

你甚至要了解程序員的編碼習慣

知道哪個程序員代碼質量可靠哪個是bug大王

對bug大王要掌握他們常犯的代碼錯誤

其次

事后諸葛亮的事必須要做而且要做好

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

沒有這一步

你就沒有日后發(fā)言的主動權

你的測試效率也不會太高

你負責的產品的質量也不可控

第一條

每個post-relesebug都應該做以下分析

－bug的產生階段：需求期？設計期？代碼期？等等

－bug的產生原因：需求不清楚？設計錯誤？代碼失誤？測試環(huán)境局限或數據不足？培訓不到位相關人員沒理解功能？等等

－為什么沒有在測試階段發(fā)現：測試用例設計失誤？研發(fā)流程不完善？測試資源不足？測試時間太緊張？測試人員失誤？等等

－以后項目中避免同類bug的方案

第二條

針對整個項目測試做以下分析

－測試coverage分析

－產品bug分布：哪個功能bug成堆，哪個模塊總有最嚴重bug，哪類功能升級或bug修復會引發(fā)大規(guī)模bug爆發(fā)，等等

－測試用例效率分析：平均一個測試用例發(fā)現多少bug，針對不同模塊哪類測試用例最有效，等等

－測試效率分析：測試的每個階段消耗資源情況

－研發(fā)流程回顧：整個研發(fā)流程中，哪部分好，哪部分需要改進，如何改進

－同類項目對比：與同類其他項目比，本次測試在上述方面好在哪兒差在哪兒原因為何如何改進

如果你把這些都做了

用數據說話

用事實說話

你就掌握了更多的主動權

比如你提到的測試只有1－2天

一個月測了幾個版本

我理解你是在抱怨工作量太大測不過來

但如果我是你老板

感情上我可以理解

但理智上我肯定不接受這樣的抱怨

建議你換一種說法：

老板

按以往同類項目經驗

這個測試需要3天能夠達到比較理想的測試結果

原因是啥啥啥

如果只有2天

我將運用啥啥啥測試方案

重點測試啥啥功能啥啥模塊

保證本次發(fā)布的要點被測到

我將不能覆蓋啥啥啥測試啥啥啥功能啥啥啥模塊

因此可能的質量風險是啥啥啥請問您有什么建議？

很顯然

上述那些啥啥啥

需要你有強有力的數據支撐

如果你能說出這些內容

并能應對你的老板針對你說的這些內容可能提出的問題

說明你對測試工作很了解

對被測產品很了解

那么你的測試計劃應該是周密的

產品的質量是可預測并可控的

風險和意外的幾率是低的

就算最終真的出現質量問題

應該也不會是大問題

加上事后諸葛亮的處理

這些問題再次發(fā)生的幾率也會非常非常低

如果你沒有這些數據說不出這些話

說明你還沒有成為一名合格的測試人員

請聯系網站客服，了解詳細的優(yōu)惠課程信息~

優(yōu)質、權威、便捷、省心