各位小伙伴們還記上個月小紅書APP崩潰閃退，導致大批用戶卸載APP重裝的事故嗎？閃退Bug從凌晨持續(xù)到第二天上午。

事發(fā)第二天，就有研發(fā)在線承認了，因為自己的失誤導致了這次事件，評論區(qū)也有人擔心博主會不會失去工作。

這件事會到此為止嗎？有研發(fā)人員承認了錯誤，測試人員還需要負責嗎？

也由此引出一個測試人員的最大疑問：

項目上線后出了嚴重Bug，到底是誰的責任？

目前存在如下兩種觀點：

Mr.Zhou

Mr.Zhou是企業(yè)的研發(fā)總監(jiān)，他看到這個Bug時，確定是測試的鍋。

他認為：測試工程師是軟件產(chǎn)品質(zhì)量的最后一個把關(guān)者，沒有做好更新測試，才導致版本發(fā)布上線后APP更新崩潰。因此，背鍋俠必需是測試工程師。

Mr.Li

Mr.Li是企業(yè)的測試負責人，他看到這個問題后，認為應(yīng)該具體問題具體分析。

首先，需要確定該Bug產(chǎn)生的原因：

修改其它Bug帶出的新Bug；

開發(fā)新需求出現(xiàn)的Bug。

修改其它Bug帶出新Bug

如果是前者，開發(fā)修改Bug后，有沒有把修改的代碼涉及到的場景告知測試工程師。

情況1

未告知，測試工程師存在漏測，背鍋俠：開發(fā)工程師。

情況2

告知，測試工程師沒測，背鍋俠：測試工程師。

開發(fā)新需求出現(xiàn)的Bug

如果是后者，那就需要查看該版本的《系統(tǒng)測試計劃》(產(chǎn)、研、測評審通過)的測試范圍，確認該新需求是否在該版本的測試范圍之內(nèi)。

情況1

如果不在該測試范圍之內(nèi)，測試工程師不背鍋。

情況2

如果在測試范圍之內(nèi)，查看該新需求對應(yīng)的測試用例或測試點(產(chǎn)、研、測評審通過)，該Bug有沒有對應(yīng)的測試用例或測試點。

如果沒有，該測試用例是如何評審通過的？背鍋人：用例評審人員和用例編寫者。

如果有，該測試用例測試結(jié)果是通過還是不通過？

1、如果測試結(jié)果：通過，測試工程師提供測試數(shù)據(jù)，并對比測試時間和代碼提交時間：

如果代碼提交時間晚于測試時間，可能后來開發(fā)偷偷改了代碼，背鍋俠：開發(fā)工程師；

如果代碼提交時間早于版本編譯時間和測試時間，背鍋俠：測試工程師。

2、如果測試結(jié)果：不通過，測試工程師是否預警并告知領(lǐng)導？

如果沒有，背鍋俠：測試工程師；

如果有，背鍋俠：領(lǐng)導。

如果確認是領(lǐng)導的責任，那就需要結(jié)合《系統(tǒng)測試報告》里的”結(jié)論”，具體確定是哪些領(lǐng)導背鍋。

測試不通過，背鍋俠：支持上線的領(lǐng)導；

測試通過，背鍋俠：測試領(lǐng)導。

大家支持誰的觀點？

最后：在我的V：atstudy-js，可以免費領(lǐng)取一份10G軟件測試工程師面試寶典文檔資料。以及相對應(yīng)的視頻學習教程免費分享！其中包括了有基礎(chǔ)知識、Linux必備、Shell、互聯(lián)網(wǎng)程序原理、Mysql數(shù)據(jù)庫、抓包工具專題、接口測試工具、測試進階-Python編程、Web自動化測試、APP自動化測試、接口自動化測試、測試高級持續(xù)集成、測試架構(gòu)開發(fā)測試框架、性能測試、安全測試等。