如何提升產品質量-開發維度

最近，咱們的產品上線了，上線以後，穩定是最重要的，可是，出現了幾回bug，都是不該該犯的錯誤，因此，避免bug特別是重大bug出現，提升產品質量，很是迫切。

產品開發過程

產品開發過程：需求分析、設計、編碼、單元測試、集成測試、功能測試、Beta測試和發佈。在工程師開發以前，策劃或產品提過來的需求、策劃的配置文件或者後期的測試，均可能影響產品質量，可是，本文側重於從開發者角度談提升產品質量。先分享一張來自《Code Complete》的插圖。

能夠看到，隨着項目規模變大，架構、設計和集成測試、系統測試須要的時間會更多，而編碼和開發者測試的時間更少。所以，提升效率最爲明顯的方法是提升產品質量， 減小測試、調試和修改所需時間。因此，設計、測試和編碼一樣重要，要分配更多時間，編碼完 != 工做完成。

測試的重要

在不少大一些的IT公司，好比微軟，開發職位叫Software Development Engineer，SDE，軟件開發工程師;測試職位叫Software Development Engineer in Test，SDET，軟件測試開發工程師，可見測試人員本質仍是開發工程師。這有別於咱們在公司裏經常見到的QA，我是作遊戲的，我見到的QA都是打開遊 戲，而後點點點，從表現上測試功能是否正常，這樣測試是沒法全面測試的，這也難怪在不少公司裏QA比開發團隊地位低。我以爲，對於測試這個職位，要作好， 是很難的。他要能讀懂策劃文檔和開發文檔，從源頭上開始着手。若是白盒測試，要能看懂別人寫的代碼;若是黑盒測試，要和開發人員多溝通，畫出來實現的流程 圖，而且分析網絡協議;而後，設計完備的測試用例。若是不根據需求、設計和實現，設計完備的測試流程，而只是操做一下試試功能是否正常，不少隱藏的bug 是測試不出來的。

 

以微軟和google爲表明的保證產品質量的作法，都有道理，並且都是成功的。可是，我我的更傾向於full stack developer，第一，招不少SDET對大部分公司都不現實，合格的SDET薪資不會比SDE低;第二，我認爲開發人員要對本身的開發的內容負責，主 動的想辦法提升產品質量，而不是被動的等測試。

產品質量目標

評估產品質量，經常使用的是千行代碼缺陷率，如下是查到的一些業界的千行代碼缺陷率數據。典型的統計代表，在開發階段，平均50~60個，交付後 15~18個;微軟內部測試的產品10-20個，正式發佈產品0.5個;某外包公司，A級≤ 0.5個，B級≤1個，C級≤5個;航天飛機的軟件，0個/50萬行。缺陷率作到平均水平的1/10是不多見的，而若是10倍以上，產品可能永遠也不會完 工。

集成測試

跟性能瓶頸同樣，80%的錯誤每每出如今20%的代碼中。大部分錯誤都是低級錯誤，好比，對需求或設計的誤解、書寫錯誤、賦值語句、邊界錯誤或循環錯誤。大多數錯誤是容易改正的。另外，warning是不少錯誤的根源，因此工程裏要禁止warning。

發現錯誤

主要經過檢查和測試。檢查包括：需求檢查、設計檢查、代碼詳查，測試包括：單元測試、集成測試、系統測試等。

有統計數據代表：單元測試的平均錯誤檢出率是25%，集成測試35%，小規模Beta測試35%，系統測試45%。而對設計和代碼進行詳查的錯誤檢出率分別是55%和60%。

檢查

閱讀代碼要比測試平均每小時多發現80%多的錯誤，代碼檢查和測試所得到的收效之比爲8:1。這是由於，錯誤越早發現，解決成本越低。

檢查方法：協同編程，詳查需求、設計、代碼。不只僅是檢查，要提早思考怎麼作?帶着思考檢查。

單元測試

1. 基於結構的測試。測試用例要覆蓋每一條控制語句，if for while and or switch case等。

2. 數據流測試，避免重複初始化、重複銷燬、定義不使用、未初始化使用等狀況，檢測數據流變化。

3. 錯誤猜想：

1). 邊界分析，>=與>的區別，null、size是0的狀況，好比測試小於MAX，三種邊界狀況MAX，10000個好友/道具的時候會不會致使遊戲卡死?

2). 複合邊界，int add(int a, int b)，a和b都小於2^31，可是，若是a和b都很大，它們的和會不會出界?

3). 壞數據，過小/大的數據，未初始化的數據，錯誤類型的數據，錯誤長度的數據等。

4). 向前兼容和向後兼容。好比，遊戲最新版本是2.5，可是有的玩家一直不更新，仍是1.0，要兼容這些玩家。

集成測試

在單元測試的基礎上，將全部模塊按照設計要求組裝成爲子系統或系統，進行集成測試。

執行方案

綜合考，制定「詳查+單元測試+集成測試+系統測試」的方案，來提升咱們的產品質量。有些方法，好比協同編程、淨室開發，雖然很好，可是對於咱們的團隊來講，執行起來太難。

詳查：先本身詳查，從需求開始，而後是設計和編碼;而後，團隊中的小夥伴互查。關於詳查，有兩點須要注意：1. 檢查前，要先制定代碼規範，讓開發人員不把精力耗在代碼規範的爭執上。2. 詳查結果不做爲員工表現的考覈標準，考覈應該基於最終的產品。

單元測試：重點是理清流程，針對每一個流程都測試到。集成測試：把單元測試的功能組合起來測試，側重於模塊的總體性。系統測試：有點像QA的廣泛工做，從功能上測試，各個需求點是否都正常。

執行：我首先制定了代碼規範，並給你們講解，而後徵求你們的意見統一。而後，寫了一份本文章的內部版本，並給你們詳細講解(爲了讓小夥伴們更容易，內 部版本細節比較豐富，舉了一些例子，寫的比較囉嗦，稍微精簡、加工以後，造成了這篇blog)。另外，須要注意，詳查結果不要做爲員工表現的考覈標準，考 核應該基於最終的產品。