作為一名軟體開發人員的實踐者，針對這一問題，最有發言權了。我想結合自己的工作經驗，從以下幾個方面分享一下的觀點。

每個人都不希望軟體上線後出現重大bug，但是問題既然已經發生了，我們首先應該集中優勢力量，去解決修復問題，而不是急於追究責任。

一、無論是開發人員，還是測試人員，當前最重要的工作應該是團結一致，把有限的精力第一時間投入到解決問題上，而不是互相推諉，追究各自的責任。

二、專案經理等應該及時與客戶溝通，分析bug影響的範圍，確認缺陷是否給客戶帶來重大影響？是否給客戶帶來損失，積極安撫客戶。

三、積極主動向各級領導彙報問題情況，取得各級領導與客戶諒解。

從事軟體行業的人，肯定都知道。在軟體開發的過程中，軟體缺陷的產生是不可避免的。既然問題產生了，就不能聽之任之，肯定有環節出現了問題？從軟體本身、團隊工作、技術問題、專案管理等角度分析，就可以瞭解造成軟體缺陷的主要因素。

1、軟體本身的問題？比如是否需求收集不清晰導致？還是架構設計複雜，沒有好的系統結構?還是開發編碼階段程式邏輯路徑或資料範圍的邊界考慮不夠周全？還是測試階段測試用例不充分的問題？還是實施部署階段現場環境，系統引數的配置錯誤等問題。要積極分析原因，防微杜漸。

2、團隊工作的問題?比如不同階段的開發人員相互理解不一致，溝通不充分?還是專案組成員技術水平參差不齊，新員工較多，或培訓不夠等原因引起的問題？或者是人員態度不端正，疏忽大意引起的問題？

3、技術問題？比如演算法錯誤？系統設計約束錯誤？架構設計不合理等？

4、專案管理？如缺乏質量文化，不重視質量計劃？專案流程不完整？開發流程不完善？文件不完善，風險估計不足？系統測試不充分?

中間只要有一個環節做的不好，可能就會影響整個系統。集中發現不足環境，在以後的開發中進行解決，防微杜漸，杜絕產生類似錯誤。

一般來說，除了那些責任真的很清晰的Bug之外，很多Bug都是開發、測試、策劃、專案經理共責的，為了團隊的團結，也沒有必要去討論哪個團隊負主要責任。個人認為，除非是團隊人員的主觀疏忽大意或態度不端正導致的重大bug，否則不宜追究個人責任。

1、如果測試時間還是比較充足，測試用例有寫，但是還是漏測的，那就是測試的責任。這屬於測試人員的主觀疏忽。可以考慮追求測試責任。

2、如果測試時間不充足，測試用例有寫，但是因為時間不足而降低迴歸測試範圍，導致漏測的，那一般是專案組各個角色共責的。

3、如果有開發修改了功能沒有通知測試人員，導致線上漏測的，那就是開發的責任。

4、如果策劃人員在迴歸測試階段還提了需求變更，在測試人員明確告知風險的情況下還堅持要上需求變更的，那就是策劃的責任。

5、如果因開發人員個人大意，不遵守編碼規範，不進行單元測試，不遵守開發制度等主管原因導致的重大缺陷，可考慮追究責任。

1:功能測試（黑盒測試）

--流程：根據需求文件（包含預期設計要求）整理功能點，編寫測試用例，進 行功能測試，生成測試報 告總結，提交bug，二次測試...直至達到預期設計要求（無bug）

--又名：黑盒測試

--依據：需求文件

--執行：測試用例

--工具：pc端：瀏覽器谷歌，IE，火狐 移動端：ip4/5/6/7...

--方法：等價類劃分，邊界值分析，錯誤推測，因果圖法，判定表驅動分析方法，正交實驗設計方法， 功能圖分析方法

--錯誤：功能錯誤或遺漏，介面錯誤，資料結構或外部資料庫訪問錯誤，效能錯誤，初始化和終止錯誤

2:效能測試（平臺趨於穩定，一般在功能測試之後進行。）

--流程：根據需求文件（效能需求分析），確定參加效能測試人員（一般研發，dba需要監聽jvm,資料庫）和測試時間，測試結果分析-調優（不滿足效能要求時提交給dba和研發進行調優），生成變成報告總結。

--依據：需求文件

--工具：loadrunner，（badboday+jemter）

--方法：負載測試-就是讓系統在一定得負載壓力下進行正常的工作，觀察系統的表現能否滿足使用者的需求。

壓力測試 ：再滿足效能要求下，進行壓力測試，直至到程式瓶頸處。

基準測試 ：新增模組時，關閉該模組，錄取系統性能指標為基準，開啟模組進行測試。

穩定性測試：很簡單，長時間進行負載測試，從而觀察系統的穩定性。

　　 併發測試 ：驗證系統的併發能力。透過一定的併發量觀察系統在該併發量的情況下所表現出來的行為特徵，確定系統是否滿足設計的併發需要。併發測試是系統觀點的測試行為。

3:自動化測試

廣義上：自動化測試包含自動化功能測試，自動化效能測試，非手動話都是自動化測試

狹義上：自動化測試更偏重於研發，不光需要掌握相關工具還需要有一定的開發能力。自動化主要包含 三個層面的自動化，單元測試自動化，介面測試自動化和web測試自動化，自動化更注重業務 的實現。

公zhong號 搜尋：IT興趣社群

軟體上線後出現了重大bug，軟體測試工程師負和開發人員誰負主要責任？

先說下這個，軟體上線後出現了重大bug，公司內耗無用，先考慮的是怎麼解決問題，找準問題發生的原因，哪些點出了問題，避免這種情況再次發生。

1，需求覆蓋不到的地方，描述不清楚的地方，需求，設計和測試都要承擔一定的責任，需求的責任最重。

說需求人員的責任大家都容易理解，為什麼說設計和測試還有PM都有責任，是因為需求的評審是需要設計和測試參與的，角度不同，具體這裡就不展開了。

除非判斷就是需求採集中的重大缺陷，否則設計和測試都有關聯的次要責任。

2，設計過程，開發過程沒有實現，需求檢查到了，設計和開發卻沒有彌補。

設計或/和開發的責任，PM責任最大，監管不到位。

3，測試過程中的疏漏，前面那位說的比較完全了。

測試用例沒有覆蓋，測試用例覆蓋了卻沒有執行，各有不同的偏重點，前者參與評審的相關人員都有責任，後者測試組的完全責任，PM也有對應責任。

4，交付部署中出現的問題

版本拿錯的責任，一般在於PM，配置管理員和測試經理，也有可能是因為沒有足夠明確的制度造成了混亂，這樣需要部門經理或者更高層的人員來牽頭負責。

版本拿對了，安裝過程出錯，交付部署人員的責任最大，專案經理次之。

最大責任應該是開發人員，程式碼寫好了需要檢查一遍，這是對工作的基本負責，也是對職業的基本守則，然後再打包成軟體

工程師負責次要責任，工程師起了個監督的作用，到了工程測試的軟體，他檢查第二次，再放到機器裡執行測試。

1，需求覆蓋不到的地方，描述不清楚的地方，需求，設計和測試都要承擔一定的責任，需求的責任最重。 說需求人員的責任大家都容易理解，為什麼說設計和測試還有PM都有責任，是因為需求的評審是需要設計和測試參與的，角度不同，具體這裡就不展開了。 除非判斷就是需求採集中的重大缺陷，否則設計和測試都有關聯的次要責任。

2，設計過程，開發過程沒有實現，需求檢查到了，設計和開發卻沒有彌補。 設計或/和開發的責任，PM責任最大，監管不到位。

3，測試過程中的疏漏，前面那位說的比較完全了。 測試用例沒有覆蓋，測試用例覆蓋了卻沒有執行，各有不同的偏重點，前者參與評審的相關人員都有責任，後者測試組的完全責任，PM也有對應責任。

4，交付部署中出現的問題 版本拿錯的責任，一般在於PM，配置管理員和測試經理，也有可能是因為沒有足夠明確的制度造成了混亂，這樣需要部門經理或者更高層的人員來牽頭負責。 版本拿對了，安裝過程出錯，交付部署人員的責任最大，專案經理次之。 大體上就是這樣分類和對應，應該算是比較全了

做測試最怕出現生產環境的事故，扣工資，扣績效，。我最怕上線了，雖然感覺已經測完了，用例也跑完了，但是感覺還是不踏實。建議大家還是把測試用例寫的全面，想法不管符合不符合邏輯都要寫一下。另外一定要按照自己寫測試用例去測試，不要隨緣測試！！！用例多評審，團隊多合作！謝謝！！！

以上這個問題，有很多測試員都曾遇到過！

開發將程式寫出來，測試員進行測試。

軟體測試完成後，產品才能生產，在這過程中，難免會遇到軟體會出現問題的情況。

因此，很多測試員就會出現這種疑問：軟體測試完後，還有Bug，責任全都在測試嗎？

首先沒有一個測試能夠保證交付出去的產品是沒有任何bug的，所以有bug在生產線上出現也是很正常的。

很多公司都把所有生產線上的問題歸咎於測試，出現bug就是測試的鍋，因為他們認為測試就應該保證質量；

然而，作為測試，其實做的事情，只能說盡最大可能去發現軟體中的問題，如果問題很多，說明是軟體質量太差，也是開發的問題；

如果在內部測試的時候，bug不多，但是線上bug很多，那就是測試的問題了。

其實，說到底，還是因為職責劃分不清晰導致的“背鍋”。

當測試員與開發之間的職責劃分清晰，確定職責就容易的多了！

那麼，測試員該如何做呢？

01、高效高質完成本職工作

高質高量完成本職工作的前提是精通各種測試技能。

一個合格的測試員必須會測試流程，測試用例/報告編寫，以及資料庫，Jmeter/loadr 測試工具的使用，甚至還需要會Python/Java任意一門自動化語言。

因為只有技能夠硬，測試工作才能出色的完成。

02、制定規範的工作流程

測試工作往往是環環相扣，密不可分的。

有時候一個小瑕疵能引發連鎖反應，產生巨大的後果。

所以，在測試工作中，我們需要對測試工作制定流程，這樣能一定程度上避免產品上線了才發現Bug的存在。

比如說寫好測試用例，就發給開發review，讓開發確認每一個點都覆蓋到，讓開發也參與到這個過程中，揹負一定的責任；

做好測試計劃，如果時間太倉促（比如你一個月需要做5-6個版本，這就已經很頻繁了），沒有辦法做完全覆蓋測試，就一定要跟開發或者產品經理確定好風險，並且把覆蓋率和風險寫在測試報告中。

03、任何需求變更必須有文件歸檔

測試計劃文件，測試報告，測試執行過程和記錄的歸檔。不僅能讓測試員直觀的知道自己每天完成的工作任務和進度，還能找出不足完善測試工作。

任何需求變更進行文件歸檔，無論是開發的修改設計，還是產品測試和更新需求，測試更改測試用例和計劃等。

任何大大小小的問題，都應該有記錄，或者是文件記錄，或者bug 記錄，這樣，線上問題追責的時候，有據可依，測試也可以有說辭，當產品出現問題，也能清晰的定位到責任人。

很多測試員常常戲稱自己是“背鍋俠”，產品上線，只要一出Bug，領導就只盯著自己不放。

但是當你在工作中有一個良好的測試習慣時，再大的“鍋”也輪不到你背。

同時，當職責劃分清晰了，你的績效也就更容易評定啦~

對於線上專案，如果出現BUG，線上問題永遠優先順序最高，毫無置疑，所有開發和測試全部轉入線上問題排查和BUG復現。

對於責任劃分，我們一般線上出問題，測試負主要責任，開發和專案經理也有連帶責任，測試對線上負責，是最後一道安全線，如果測試都不能對自己測過的專案線上負責，那開發更保證不了。

首先要明確，自己開發的，自己測試，是絕對的錯誤。

一般採用，自己開發，專門的測試工程師測試，測試透過，在交叉驗證，保證所有測試用例覆蓋到位，這樣測試的結果就是有保證的。