如果說到最困擾軟件測試工程師的幾大問題，我們最先能想到的無非是以下幾點：

需求帶著小姨子跑路啦，沒有需求我咋測試?yán)?。?！?/p>

開發(fā)牛皮哄哄啦，他打了我，還說我報的不是BUG。。。

測試時間不夠啦，項目質(zhì)量這么爛怎么還要上線啦，人家不要面子的嗎。。。

還有，今天又有人問我，‘這個Bug你怎么沒測試出來呢？‘。。。

沒錯相信每一位測試工程師都經(jīng)歷過這樣的苦惱，那就是背鍋！

怎么別的小哥哥小姐姐都是C位出道，我們卻他喵的是背鍋位出道。。。

做為一個測試工程師，背鍋你怕了嗎。今天我們就要拉起橫幅，貼起大字報：對背鍋說不！

不想背鍋怎么辦哦，躲在桌子底下也躲不過去的樣子。那要怎么辦？很簡單，甩鍋！

下面我們就來教大家怎么甩鍋：

首先，我們的前提是，你的本職測試工作要高質(zhì)量的完成。

如果說測試覆蓋的不足，粗心大意導(dǎo)致我們遺漏了重要問題，被帶入了后期階段甚至是上線以后。那么我們首先要想的不應(yīng)該是甩鍋和推卸責(zé)任。

那么第一件要做的事情就是對問題進行回顧，分析到底類似這樣的問題遺漏，究竟是不是由我們個人的工作失職所造成的。

如果確實我們確實在測試過程中由于自己的失誤而帶來了問題，那么我們應(yīng)該勇于承認(rèn)自己工作的不足，并對相關(guān)利益相關(guān)方表達誠懇的歉意。

承認(rèn)問題還不是最重要，更重要的是我們要主動去總結(jié)在事件發(fā)生過程中我們的失誤所在，并提出改進的思路和方法。所謂亡羊補牢為時未晚，這樣誠懇和負(fù)責(zé)任的態(tài)度相信會幫助你去緩解工作失誤所帶來的指責(zé)和信心缺失。一般來說，如果不是重大失誤，我們的團隊也不會過多的追究這種問題。

其次，我們可以去對事件發(fā)生的過程進行流程上的回溯。

我們的測試不是獨立存在的事物，我們的測試團隊也不是獨立存在的團隊，我們測試活動也是環(huán)環(huán)相扣的一種鏈條式工程。測試工作是研發(fā)團隊里依賴性最強的工種，我們最終工作的產(chǎn)出，與我們的上游流程的完備程度是息息相關(guān)的。

那么在發(fā)生事件的過程中，如果我們在回顧自己的測試工作，確實沒有發(fā)現(xiàn)自己工作的明顯失職，那么我們就要回溯到我們工作的上游，看看是不是哪個環(huán)節(jié)最終導(dǎo)致了問題的發(fā)生。

測試執(zhí)行工作的上游工作是什么，從近往遠(yuǎn)來說，就是：測試設(shè)計，測試分析，測試計劃，編碼開發(fā)，產(chǎn)品設(shè)計，產(chǎn)品分析，項目需求。

這其中任意環(huán)節(jié)如果出現(xiàn)問題，甚至可能只是小瑕疵小波浪，都有可能在下游發(fā)展成洪澇。

比如說，一個具有二義性的需求，就可能導(dǎo)致開發(fā)和測試對于某個功能點有著完全南轅北轍的理解。那么最終這種理解的偏差，就會體現(xiàn)在測試的實現(xiàn)上，造成最終環(huán)節(jié)的問題。

又比如說，在測試計劃的階段，也許就對測試的覆蓋方面估算不足-比如丟失了可用性測試內(nèi)容-最終導(dǎo)致測試執(zhí)行階段對產(chǎn)品某方面特性質(zhì)量把控的缺失。

所以，我們可以去回溯我們測試執(zhí)行的上游流程，找出導(dǎo)致問題的根源所在。進而我們需要將我們的發(fā)現(xiàn)，合理的去闡述給我們的管理團隊直屬領(lǐng)導(dǎo)，只要我們的依據(jù)屬實，相信就可以減輕我們對于事件的責(zé)任，更好的一個情況是還可以促進項目流程的改進，防止以后出現(xiàn)類似問題。

當(dāng)然，在闡述的過程中，一個誠懇和中立的態(tài)度是有幫助的，畢竟你有可能將加之于你的指控，導(dǎo)向了另一個環(huán)節(jié)或個體的工作上去。

再次，我們要擺事實，講道理。

我們要知道，測試本身就不是萬能的，不是完美的。我們的測試七大核心原則中也強調(diào)，我們不應(yīng)該追求一個完全的測試（即找到所有問題）。

我們的測試過程本身是一項系統(tǒng)工程，它本身就是有局限性的。比如我們的測試執(zhí)行，每次執(zhí)行的輪次是有一定時間鴻溝的。在現(xiàn)在的軟件開發(fā)大環(huán)境下，持續(xù)集成的理念被廣泛應(yīng)用，系統(tǒng)的迭代和增量每天都在發(fā)生。這些迭代和增量每一個都有可能對我們已測過的功能產(chǎn)生沖擊甚至造成破壞，我們的測試不可能每天都跟隨的代碼更新去覆蓋，就算使用非常高水平的自動化測試去覆蓋回歸測試，也是避免不了在我們測試完成之后，系統(tǒng)功能又被破壞的。

這種情況下，我們就要闡述，甚至跟利益相關(guān)方去科普我們的測試?yán)砟睿瑴y試的局限性。我們擺事實-拿出我們的測試過程記錄和缺陷記錄，去告訴相關(guān)方：我們的測試是沒有問題的，是提供了足夠覆蓋的，只是在我們的測試實施完畢之后，代碼又因為新的迭代而引入了問題，這不是我們能隨時控制的。

還有我們的系統(tǒng)測試畢竟是在一個測試環(huán)境上去執(zhí)行的，我們雖然會盡力讓測試環(huán)境與生產(chǎn)環(huán)境盡量接近，但是一般是不可能達到完全重現(xiàn)的。比如我們所采用的服務(wù)器的量級，我們的內(nèi)網(wǎng)測試環(huán)境，我們的測試數(shù)據(jù)的數(shù)量級以及一些真實環(huán)境中可能出現(xiàn)的突發(fā)情況，我們都不能完全的模擬。而這種差別最終導(dǎo)致我們系統(tǒng)測試階段不能發(fā)現(xiàn)一些生產(chǎn)環(huán)境中的問題，那么當(dāng)然不能歸結(jié)成我們工作的失誤。遇到這種情況，我們就要闡述清楚問題的所在，也可以去展示我們的測試環(huán)境的限制（比如在測試環(huán)境中重復(fù)bug的重現(xiàn)流程，它并不能在測試環(huán)境中復(fù)現(xiàn)）。

再次，我們要將測試的過程進行合理的歸檔。

我們測試的產(chǎn)出其實不單單是測試計劃文檔，缺陷報告，測試總結(jié)報告這些東西。其實測試的執(zhí)行過程和記錄也是一種很重要的歸檔，測試的執(zhí)行過程記錄，做為我們測試工作的完備程度的支撐是非常有效的。

在日常工作中，我們還可以使用小段的時間，對我們的測試工作進行更多的歸檔。比如說，我們可以去記錄每天的測試工作日志；可以去通過郵件和討論群組進行測試過程的報告匯總；對于一些文檔輕量化的工作，比如探索性測試，隨機測試，我們也要去列出測試的綱領(lǐng)和記錄過程；測試用例更是有時間寫，就一定要去寫去編排，就算沒有時間也要去寫測試大綱和條目。

有了這些文檔，在遇到鍋從天降的情況時，我們就可以拿出這些文檔，對我們當(dāng)時的工作情況進行回顧并用他們來支持我們工作沒有問題的論點。

========================================================================================================================================================

好了說了這么多，相信會對做為軟件測試工程師的你有所幫助，這個話題我們就說到這。

以后再遇到這樣的情況，不要恐慌不要煩惱，如果是問題我們就承認(rèn)它是問題；但如果不是我們的問題，那這個鍋我們可不接！