年輕的時候去面過一個相對于當時我的比較高端的管理崗位，當時的我情況是，開發經驗相對豐富， 但管理經驗還欠缺。對方當時面臨一個具體的問題。

網站建設哪家好，找成都創新互聯公司！專注于網頁設計、網站建設、微信開發、小程序設計、集團企業網站建設等服務項目。為回饋新老客戶創新互聯還提供了曲陽免費建站歡迎大家使用！

　　“我們最近生產上，出現了一個比較嚴重的事故，復盤的時候，開發噴測試，測試噴開發，都覺得是對方的問題。對于類似情況你有沒有什么解決和處理的經驗。如何提高軟件質量”

　　我當時對這個問題回答的比較單薄，無非就說，大家要團結合作，開發要加強自測，測試要考慮全面，有責任心。這么說雖然沒錯，但是只有戰略沒有戰術，也沒實例經驗。最終，顯然對方也不是很滿意， 無緣了這個崗位。

　　如今的我已不再是曾經的那個少年，雖然錯過的人已經錯過， 但問題長存， 都說人在不同的階段，對相同的問題，會有不同的答案，于是鍋叔在這里重新回答一次……

　　

　　具體這件事情，建議從三個層面來處理。　　

　　

　　一、就事論事

　　這一層比較簡單，具體問題要具體分析， 要了解下這個問題的出現的原因， 歸屬的類型，然后才能明確責任。 一刀切的讓所有的生產Bug都由測試背鍋是不科學的。

• 如果需求明確，正向用例就應該覆蓋到，沒有被測出，那顯然屬于測試全責。進一步需要追查，這個部分的用例是誰編寫的，是否遺漏，執行了沒有，為什么沒有測出。
• 如果屬于一些特殊數據，特殊流程下觸發的bug，不能認為全是測試的問題，開發也需要承擔部分。 可以具體分析下代碼，是否屬于那種開發人員容易意識到而“有意忽略”的問題。實際開發經驗豐富的同學肯定容易理解，有些bug是，開發容易而且應該想到，而測試難以測出的。例如“并發減庫存”這類問題，僅通過功能測試很難測出，在開發設計時，就應該進行考慮。
• 也有可能存在開發，測試都很無辜，需求背鍋的情況，做出來的東西就不符合用戶的實際需要。或者需求，測試一起背鍋的情況， 需求調整需要連帶修改的需求，沒有做出調整，測試也沒有回歸到。例如只考慮了新增輸入校驗，沒有考慮編輯已有數據的校驗等。

　　

　　二、舉一反三

　　復盤的目的，主要應該不是為了追責。而是為了優化流程。弄清事情的發生原因后，應該建立對應的流程，機制，避免類似的事情重復發生。例如，用例的執行應該能追溯，測試開發能力不足的，要培訓，要編寫對應操作規范等，缺少評審的流程加入評審。

　　三、統籌安排

　　如果公司覺得此事暴露了軟件質量的不足，期望改進開發質量，那么就要理解，軟件的質量控制和軟件測試，其實是不同范圍的事情。質量改進包含的范圍遠大于軟件測試，對這一點要在團隊中進行宣貫，統一認識。

　　提高軟件質量不等于提高測試質量，質量控制是一個貫穿開發流程始終的活動，需要團隊的所有角色共同參與，為交付質量共同負責。

　　

　　 1、產品，需求人員的質量責任

　　

　非常容易想到的一個職責是——不能理解錯用戶的原始需求，否則就將帶著整個團隊南轅北轍了，但這其實只是一個最基本的要求。

　　除此之外另一個重要的職責是——傳達清楚，即把需求全面，準確的傳達給用戶。

　　“準確”可以理解為要把你的需求描述清楚，條理清楚，避免歧義。實踐中很多bug的產生，是因為開發人員遺漏一些細節需求導致的。這類bug的情況，通常功能較為細節，例如一些細節的校驗，提示的文字，與同類功能的細小差異等。這類問題可以通過在需求編寫形式上上，使用逐一列出，重點強調的方式會比把所有需求無差別寫成一坨文字，降低發生的比率。歧義情況的出現，多是由于語言描述不嚴謹，不具體導致的，可以有意識多使用邏輯性描述，實踐所占比例不高，適當注意即可。

　　“全面”實際是一個非常難以達成的要求，需要需求人員有較高的素質。這類問題造成的bug在運行維護多年，持續迭代的系統上暴露的非常多。抽象來說就是修改了某功能，要對應修改系統中對于此功能為有依賴的其他功能。對于陳年老系統，要考慮周全非常困難。簡單的例子如，為了增強賬號安全，增加了注冊用戶名的長度，也允許加入特殊符號。需求人員應該想到，此處修改除了影響用戶注冊頁面的用戶名輸入框校驗規則外，也同時需要修改，用戶登錄頁面的用戶名輸入規則，如果有其他客戶端如移動端，也需要同步修改，如果后臺有用戶管理，搜索，用戶名搜索框允許輸入內容可能也要同步修改。甚至要求高的UI界面， 因為長度變化，可能會導致顯示異常，也要一并考慮到。

　　而產品架構，則是更高層次的要求， 要求需求人員對產品的功能，實體，概念，做恰當的抽象，并有一定前瞻性。 產品架構其實是技術架構的基礎，如果產品沒有一個需求上的框架，那技術架構也是無法恰當提出的，隨機應變會成為日常，修改成本會升高，穩定性會變差。　　

　　 2、開發人員

　　

·　　開發人員主要是要強調自測，對自己的交付物負責。實踐中，開發人員常反懟說，我們又不是測試， 我們都測了要測試干啥。 因此也確實涉及到一個度的問題。實踐中一個最基本的要求是， 對于需求對應的正向用例應該自測到，通俗說就是需求明確提到的功能開發自測應該覆蓋。例如“新增的用戶，點擊用戶名稱，能夠顯示用戶詳情"，開發人員至少要保證自測下， 新增一個用戶，點擊其用戶名，顯示詳情這個流程。如果沒有問題算通過。而測試人員則要考慮的更多。例如編輯的用戶，導入的用戶能不能正常顯示？有特殊邊界輸入的，選填項不填的，顯示是不是正常。

　　情況往往也不會這么簡單， 現代系統通常分工比較細，一個功能通常由幾個開發人員合作完成，他們之前通常通過接口定義來銜接，也就是各自按約定的接口協議，實現功能即可。這種情況下，除了要求按照接口自測外，還要要求，這幾個人中指定一個人負責串聯的測試，保證功能正確。因為實踐中接口難以定義的事無巨細。 這里的接口可能是前后臺間的http接口，也可能是基于數據庫表的接口（一個存，一個取）。如一個負責用戶存的開發只驗證了用戶信息有沒有寫入數據庫表。 另外一個負責展示的開發人員只驗證了，自己在數據庫手動填寫的數據，能不能正常的被讀取顯示到頁面上。 如果沒人負責串聯驗證下這個過程，那接口對接環節的bug就無法發現，例如，存取的字段不對應，空值的表示不一致null與""等。

　　開發人員自測確實可以更早的發現bug，降低bug修改的成本，不需要經過 ，“測試提”，"開發查"，"開發改","測試驗"的過程。但鍋叔覺得這只是開發自測收益中較小的一面，更大的收益在于，提高開發人員的質量意識，不是功能寫完就算是開發完。通過結合其他追溯機制，可以推動開發人員，使用更合理的設計，主動進行重構優化。

　　

　　 3、測試人員

　　

　　測試人員在很多人的觀念里，是天然的負責軟件交付質量的人員，其質量責任主要就是做“好測試”。做好測試，無非依賴于，扎實的軟件測試理論基礎，和對系統業務的充分理解。 測試理論屬于通用技能，只能通過學習思考，積累提高。而對系統業務的充分理解，對測試人員的穩定性是有一定要求的。 如果你們公司的測試人員是共享資源性質的，那應該盡量讓他們穩定服務于，1個或幾個項目。尤其對于長期迭代，周期較長的項目，人員穩定性非常重要，切換成本高昂。

　　質量控制是測試工作的超集，因此提高軟件質量，也要求測試人員額外承擔一部分質量分析統計工作。因為Bug直接由測試人員記錄產生， 由其來進行這類工作更為直接。常見的統計指標如，

　　用例通過率，重激活Bug數，需求問題Bug數，未自測Bug數，遺漏需求Bug數，生產發現Bug數。

　　都是開發質量的評價依據，是復盤優化的基礎數據。測試人員在測試工作中，或者生產環境支持過程中，在bug管理管理工具中，應對bug類型，進行識別歸類， 用于日后統計分析。

　　這也要求，測試人員要客觀公正，真實反應質量數據。這里也提下，個人不贊成Bug與績效明確的掛鉤，否則容易造成開發測試對立，內耗嚴重，非常糟心。-_-||。

　　 4、管理人員

　　

　　管理人員，首先明白，研發有其自身遵循的客觀規律。所謂給技術以時間，凡事總有個測試，優化的過程，如果總是隨意拍腦袋，削減研發評估的研發周期，那么，因為功能是顯而易見，一定要交付的，所以首先被壓縮的一定就是質量。例如一個系統計劃開發一個月，測試一個月， 領導一拍腦袋，開發測試壓縮成一個月， 那實際上，可能就開發3三個周，測試一個周，中間的各類評審也都被扔的七七八八，開發設計怎么方便怎么來， 測試就走走主要功能能用就行。這樣質量就不要苛責了，相當于把測試交給最終用戶，對于長期迭代的項目，也會累積不菲的重構債務。

　　建立評審，復盤機制，是高級管理人員的職責。 重要的評審公司多小也應該具備，如需求評審，開發設計評審，測試方案/用例評審。同樣復盤，如結項復盤，或以時間為周期的月復盤，季度復盤。

　　基層管理人員，參與組織評審時，應保證評審不流于形式。如需求評審， 就是降低需求BUG的重要環節， 系統大了，需求人員自身的能力，也很難考慮的面面俱到，需要開發，測試共同，幫忙考慮，新需求對已有系統各處的影響。評審過程也是一個傳達質量價值觀的好機會， 在“好改，工作量小”和“規范，長遠可維護”中盡量選擇，規范的需求設計， 開發設計方案。要倡導細心和減少Bug是有非常有技術含量和挑戰的事情，而不是一件麻煩的事情， 讓開發多花精力在一次作對上。

　　 復盤是一個重要的回溯機制，質量問題應該都能追溯到個人，誰提的需求，誰寫的，誰測的。 到不一定要跟績效掛鉤，但責任到人的方式，確實可以推動大家，建立質量意識，遵守質量規范。用例通過率低的模塊的原因？需求Bug的數量較多，提示我們要重視需求編寫，評審，提高需求編寫人員能力，未自測bug多，提示開發人員責任心不強，生產的Bug數多，要分析，是否為常見問題，測試是否應該覆蓋，如果是用戶的日常操作，而回歸流程卻沒有納入，要考慮測試與用戶多溝通，了解用戶使用習慣。　　　

　　OK先到這里，上面的回答，你給幾分 :-)。

　　

　　

　　曾經有一份真摯的愛情擺在我面前,但我沒有珍惜,等到失去了我才后悔莫及,塵世間最痛苦的事莫過于此……o(*￣︶￣*)o

標題名稱：如何提高團隊開發質量
網頁網址：http://www.yijiale78.com/article48/dschihp.html

成都網站建設公司_創新互聯，為您提供網站收錄、商城網站、外貿網站建設、響應式網站、小程序開發、手機網站建設

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯