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

需求帶著小姨子跑路啦，沒有需求我咋測試啦。。。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

那么在發生事件的過程中，如果我們在回顧自己的測試工作，確實沒有發現自己工作的明顯失職，那么我們就要回溯到我們工作的上游，看看是不是哪個環節最終導致了問題的發生。

測試執行工作的上游工作是什么，從近往遠來說，就是：測試設計，測試分析，測試計劃，編碼開發，產品設計，產品分析，項目需求。

這其中任意環節如果出現問題，甚至可能只是小瑕疵小波浪，都有可能在下游發展成洪澇。

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

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

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

當然，在闡述的過程中，一個誠懇和中立的態度是有幫助的，畢竟你有可能將加之于你的指控，導向了另一個環節或個體的工作上去。

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

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

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

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

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

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

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

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

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

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

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

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