如何保證軟體質量

用體溫計量體溫不能治病，它只能證明一個人生了病；同樣地，對軟體的測試，並不能提高軟體質量，它只能證明程式碼中存在缺陷。

1. 軟體測試危機

1.1 國內軟體測試的困境

目前的軟體開發環境中，最在乎軟體質量的是使用者、專案經理，最應該在乎軟體質量的軟體測試人員並不關心軟體本身的質量，他們只想找bug。

早期的軟體開發過程中，軟體的質量僅僅只是靠編碼後的測試來驗證，誰能真正提高軟體的質量呢，其實是開發人員，因此那時候軟體開發人員的薪水要比測試人員高很多。

後來，大多數軟體開發團隊意識到，只有提高整體的軟體開發效率，才能激烈的競爭中佔有優勢。這一時期有兩個明顯的特徵：軟體測試的週期越來越短，因為在交付的壓力下，不再有以前那樣充足的測試時間；軟體測試人員的工作貫穿整個軟體開發的週期。軟體開發的W模型很好地詮釋了這一時期的軟體測試工作特徵，軟體測試有了專門的團隊，測試人員的地位相比於過去有了明顯的提高。

再後來軟體開發的流程演變成螺旋模型，摒棄了W模型的長週期，追求增量開發，隨著一輪又一輪的編碼和測試，軟體開發處於一種不斷迭代的過程中。現在流行的敏捷開發模型，本質上還是螺旋模型。

即使是螺旋模型，測試人員始終還是從事著質量控制（Quality Control）的工作，不斷手段多麼花哨，介面測試，自動化測試，效能測試，安全測試，各種先進的測試工具，本質上和手工點點點找bug並沒有什麼不同。在軟體的開發過程中，測試人員依然是很被動，被動體現在不能主動提高軟體的質量。

1.2 軟體測試人員的危機

軟體測試人員將會分層，有管理能力熟悉測試流程的順利成章地成為測試過程的管理者，程式碼能力強的演變為測試工具的開發者（為專案定製的自動化黑盒測試工具，為專案定製的效能測試工具等等），程式碼能力差的就只能從事點點點的黑盒測試。

黑盒測試崗位門檻較低，可替代性強。在不遠的將來，黑盒測試人員不是被測試開發人員取代，就是被測試工具開發人員開發的測試工具取代。值得一提的是：當黑盒測試被取代之後，測試過程管理者也會有失業的風險，他們必須要轉型為測試架構師才能適應潮流，才不會被後浪拍死在沙灘上。

2. 解決危機

2.1 引入軟體質量保證

絕大多數公司招聘測試人員，更多地是：想通過他們的測試工作，去發現軟體中存在的問題，修復缺陷，從而提高軟體的質量。很明顯，這是一種頭痛醫腳的行為，提高軟體的質量難道不是更應該去直接提高程式碼質量嗎？

對於測試人員來講，解決軟體測試危機的辦法就是專注於提高整個開發過程的質量，也就是說，成為軟體開發專案的質量保證人員（Quality Assurance）。測試人員更多的是需要在整個軟體開發的過程中，通過制定標準，監督執行，保證每一個環節的質量，從而提高整個軟體開發過程的質量。這其實是一整套解決方案，當你的過程有了標準化的、成熟的解決方案之後，軟體的質量一定是過硬的。

2.2 質量保證的思路

對於螺旋模型而言，最基本的單元就是：

需求分析->詳細設計->編碼->整合->測試->驗收

那麼每一個過程都應該有對應的工作過程及體現工作過程的文件，質量保障人員就可以根據以往成功的經驗，制定合理的質量標準體系來指導和優化工作過程，同時也在實踐中優化質量體系。

3. 如何保證軟體質量

如何保證軟體質量這個問題很寬泛，應該保證以下幾個方面的質量，那麼軟體的質量將得到保證。

3.1 需求文件質量

• 需求描述詳盡：無缺漏，無歧義，無重複，沒有無法實現的，沒有巨大風險
• 需求指標明確：前提條件明確，資料指標精確。

3.2 設計文件質量

• 欄位定義明確：欄位沒有混淆，資料來源和走向清晰
• 邏輯清晰通暢：軟體操作不會進入死衚衕，使用者使用場景考慮全面
• 互動簡單易懂 ：每個按鈕點選前是怎樣，點選後會有什麼變化
• 提供豐富的輔助文件：Visio流程圖，Xmind思維導圖，Axure互動原型設計文件等

3.3 程式碼質量

• 優質的框架設計：根據專案的實際情況選擇合適的技術棧，底層設計容錯性高、健壯性好、可擴充套件性好，前端相容性好、效能好
• 編碼規範：參考阿里巴巴的java編碼規範制定
• 程式碼走查：開發人員自己或者結對進行程式碼走查，考慮邏輯是否完備，資料處理是否到位，場景是否缺漏，演算法效能是否最優
• 程式碼評審：評價程式碼是否還有改進的空間等
• 單元測試：開發人員自行編寫單元測試，測試函式方法是否滿足要求，隨著程式碼版本的迭代，能否保持原來的功能

3.4 測試質量

3.4.1 測試策略

後端測試：介面測試，壓力測試，部署測試，安全測試

前端測試：UI測試，效能測試，相容性測試，安全測試

3.4.2 測試方法的質量

• 設計合理的測試方法
• 測試方法的評審
• 改進優化測試方法

3.4.3 測試用例質量

• 良好的用例設計方法：等價類劃分、因果圖法、場景分析法、正交分析法、路徑覆蓋、邏輯覆蓋、語句覆蓋
• 用例評審：保證測試的廣度（介面、介面、資料庫、日誌）和深度（測試要點的精細程度）
• 測試用例維護：測試過程中補全缺漏的和思路有問題的用例，記錄線上故障並新增到測試用例中

3.4.4 缺陷質量

• 缺陷分級：一般四級分類法，
• 缺陷記錄：bug管理系統，bug的生命週期理論
• 缺陷反思：bug評審，開發避免類似錯誤，測試在設計測試用例的時候考慮類似情景

3.5 部署質量

不是說保證了設計、開發、測試質量之後，產品上線後質量一定好。因為部署上線還有一整套流程，部署流程的質量，直接決定了產品的上線質量。
部署環境：硬體環境和軟體環境，是否滿足功能和效能要求
部署時機：選擇對使用者影響最小的時機，一般遊戲更新選在午夜。
部署引數：測試環境的引數和正式環境的引數往往是不同的，往往涉及到引數的調整。
自動化部署：流程化，自動化的部署將大大減少人為失誤。

3.6 風險控制

• 專案風險：需求變動，開發環境不能滿足，人員缺失，技術自身風險，安全風險
• 風險預測：根據專案實際情況和自身的軟體開發經驗，找到薄弱環節和不確定的環節，這些往往都是風險高發處
• 降低風險： 在可能發生風險的地方做好兩手，甚至多手打算

3.7 組織技術學習

從長遠來看，提升團隊的技術水平，也能夠提升軟體產品的質量

4.結論

保證軟體質量需要一整套的質量保證體系，搭建這樣的體系是QA的核心競爭力。QA人員在從業的道路上需要不斷地打磨自己的業務能力、技術能力、團隊合作能力，才能在激烈的市場競爭中立於不敗之地。