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

事發(fā)第二天，就有研發(fā)在線承認(rèn)了，因?yàn)樽约旱氖д`導(dǎo)致了這次事件，評論區(qū)也有人擔(dān)心博主會不會失去工作。

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

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

項(xiàng)目上線后出了嚴(yán)重Bug，到底是誰的責(zé)任？

目前存在如下兩種觀點(diǎn)：

Mr.Zhou

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

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

Mr.Li

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

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

修改其它Bug帶出的新Bug；

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

修改其它Bug帶出新Bug

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

情況1

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

情況2

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

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

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

情況1

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

情況2

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

如果沒有，該測試用例是如何評審?fù)ㄟ^的？背鍋人：用例評審人員和用例編寫者。

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

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

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

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

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

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

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

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

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

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

大家支持誰的觀點(diǎn)？

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