軟體質量保障全流程實踐分享

關於軟體質量保障，其實都是大同小異，去年9月份自己也根據公司的情況，總結了下來。

目錄
一. 軟體質量保障流程
二. 整合測試
三. 測試環境管理
四. 持續整合
五. 測試用例管理
六. 缺陷管理
七. 釋出後管理
八. 結束語

一. 軟體質量保障流程

1.1 微服務產品的特點

微服務架構下，一個大型複雜軟體系統不再是一個單體，而是一系列相互獨立的微服務，特點鮮明：

• 每個服務獨立，開發技術棧獨立
• 每個服務可以獨立開發、部署、釋出
• 服務之間通過輕量級通訊機制溝通，常用的是 RESTful API

1.2 微服務產品測試的痛點

由於每個服務都有對外暴露的介面，而且服務之間還可能互相依賴，直接導致：

• 介面數量翻倍增長
• 測試場景翻倍增長

這使得在敏捷交付的模式下，測試工作挑戰巨大。如何能在「周」「天」甚至「小時」的釋出週期下，進行高效的測試，是微服務架構產品的測試中常常思考的問題。

1.3 軟體質量保障全流程

1.3.1 角色

在產品的釋出週期中，所有角色的聯絡相當緊密。每個角色有自己不同的職責，但最終都是為產品質量負責。

• 產品經理 —— 管理需求和專案計劃
• 研發 —— 專案任務開發工作
• 研發負責人 —— 研發團隊管理及程式碼質量管控
• 測試 —— 軟體質量保障
• 運維 —— 應用部署和執行管理

除了按照「需求->編碼->測試→釋出」常規的順序交流外，不同角色之間也隨時交流資訊。

1.3.2 DevOps

無論是外部需求，還是內部反饋，都會被一一記錄，供下一輪迭代評審。每一次迭代之中包含著無數區域性迭代，由大家一起評審需求變更和承諾交付。

1.3.3 落地全流程

整個產品質量保障全流程從需求開始，一直到交付上線，全流程如下：

需求評審 → 編碼 → 單元測試 → 程式碼掃描 → 構建映象 → 部署測試環境 → 介面自動化測試 → 端到端自動化測試 → 提測 → 手動測試 → 釋出 → 上線

利用 Jenkins 對接 JIRA、Git、SonarQube、Registry 等各種工具實現 CI/CD，讓工程師不再把時間和精力花費在構建、測試環境搭建和自動化測試執行這些重複性操作上。

通過提交程式碼自動觸發流水線，進行單元測試，然後通過 Sonar-Scan 進行靜態程式碼掃描，達到要求後會構建容器映象，構建完成會自動部署測試環境，並觸發自動化測試，測試通過後即可打上標籤進行正式提測，在此之前的階段都是通過自動觸發，工程師只要把主要精力均放在結果上，待測試驗證符合要求後，映象才會最終釋出並上線。

二. 整合測試

2.1 介面

介面測試通常分三步走：

準備測試資料 → 對被測介面發起請求 → 驗證返回結果

測試資料是一個非常重要的輸入，在介面不變的情況下，利用大量的資料驅動測試，從而實現較高的覆蓋率。

通常我們使用命令列工具 cURL 或者圖形化介面工具 Postman 對介面發起請求，無論哪個工具，都需要對返回結果進行斷言以判斷是否符合預期。

驗證返回結果不僅僅是驗證返回的狀態碼，還要驗證返回值，返回值的準確性則需要通過查詢資料庫等方法進行驗證。

另外，我們通過 Swagger 來管理介面文件，以力求不同的開發人員釋出統一標準的介面文件，供大家使用。

2.2 介面自動化

通常，介面是提前定義的，且不輕易變化，比較穩定，因此測試工程師可以根據定義好的介面文件，在開發編碼的同時，實現介面自動化測試指令碼，提高未來的測試效率，並且可以實現測試前置。

我們基於 Pytest 框架以及 Swagger 3.0 標準封裝改造出一款輕量級介面自動化測試框架，自動解析介面文件並且生成能被 Pytest 驅動的測試用例結構，工程師只花精力編寫測試資料。

介面自動化的實現本不難，主要難在測試資料的準備和返回值的驗證。

每次都使用相同的測試資料一定是不合適的，因此，測試資料需要有一定的自動生成能力。

而返回值有很多是測試過程中才能生成得知的，如 UUID ，這類資料的驗證需要實時去資料庫獲取。

2.3 端到端

模擬使用者場景，進行基於消費者契約的業務主流程端到端測試，覆蓋使用者觸發頻率最高的操作。比如以電商舉例：

登入 → 搜尋產品 → 選擇 → 加入購物車 → 提交訂單 → 確認支付 → 收貨確認 → 新增評論 → 搜尋訂單

這種測試通常可以在時間有限的情況作為最基礎的驗證，以確保沒有阻塞性問題，保證使用者體驗。

但一個產品的業務主流程通常不會發生太大變化，是一項不斷重複的工作，因此，我們優化了測試操作流程，從而實施自動化。

2.4 UI 自動化

無論是 PC 端 Web UI 還是移動端應用 UI，現在都有比較成熟的自動化測試解決方案。對於 Web UI，我們期望其能夠在容器中執行，所以選擇了基於 Python 的 Selenium 呼叫 Headless Chrome「無頭瀏覽器」，採用以關鍵字驅動的 Robot Framework 框架實現自動化測試。

WebUI 的操作主要是在頁面輸入和點選，因此我們採用 PageObject 設計模式封裝頁面元素，以此達到靈活使用關鍵字的拼裝實現產品業務頁面操作。

當頁面出現錯誤，或非預期結果時，除了列印詳盡的日誌，還會自動截圖插入到 HTML 的測試報告中。

三. 測試環境管理

3.1 構建映象

我們所有的微服務均由流水線通過 Docker 構建出容器映象，推送到獨立的映象倉庫中。

3.2 測試環境搭建

為了減少測試過程中髒資料的干擾，有些伺服器是需要全新安裝的。

除此之外，通常產品都是支援多種平臺的，因此也需要在多平臺上進行安裝測試，並且需要按照交付文件中的安裝方法進行驗證。

3.3 測試環境自動化運維

考慮到迭代週期短，應用場景複雜，準備全套測試環境還是需要花費不少精力，所以我們採用自動化的方式來管理和部署測試環境，並且 VM 和 Docker 容器並存。

對於相對穩定的測試用第三方伺服器，直接使用 VM 搭建，不需要特別的維護；一些用於產品的中介軟體或需要常常清理的測試用伺服器，除了使用 ESXi Server 的 VM 快照回滾，還會結合容器化部署，測完即刪。

這些操作都通過自動化指令碼執行，並且由流水線根據需求自動觸發。

四. 持續整合

4.1 單元測試

單元測試是產品質量檢驗的第一道關卡，其重要性和高效性不言而喻。單元測試做得好，會大大降低返工成本。單元測試除了關注通過率，還會在執行後通過 Sonar 分析出覆蓋率，兩者結合綜合參考。

4.2 靜態程式碼掃描

我們利用 Sonar-Scan 對所有程式碼進行掃描，並在 SonarQube 上設定一定的質量門限，達到質量標準的才會被標記為「通過」返回到流水線狀態。

4.3 構建

微服務產品的各個元件都是以容器映象的形式構建釋出，推送到指定映象倉庫。我們直接在流水線中進行 Docker 構建並推送。

4.4 部署

檢測到有指定版本新映象生成，就會開始自動部署測試環境，並以無人值守的方式進行預測試。

4.5 自動化整合測試

通常我們把自動化測試前置到提測前，以此作為是否達到提測要求的快速驗證。

測試通過後，會郵件通知到相關人員，正式作為 RC*「釋出候選版本」*提測。

五. 測試用例管理

5.1 JIRA Zephyr

我們使用 JIRA 的 Zephyr 外掛管理測試用例，若干測試用例通過模組和標籤進行篩選分類。

通過 Zephyr 的測試迴圈來做測試計劃，每輪發布中包含若干迴圈，一次迴圈相當於一次迭代。

每次迭代會關聯具體的測試用例集，新功能和迴歸通過不同目錄分類。

Zephyr 可以追蹤出已分配用例的執行情況。

5.2 測試用例的分類

我們把測試用例按照功能模組進行分類，由於測試用例在 JIRA 中沒有目錄結構，因此需要靠標籤來篩選。

另外，針對不同型別的測試用例，我們也做了特殊的標籤，如 API、E2E 等等。

5.3 測試計劃

Zephyr 在每一輪發布中可以包含多個測試迴圈，一次迴圈相當於一次迭代。

在每個迭代中，我們關聯了計劃執行的測試用例，並根據分類歸在不同的目錄中。

5.4 測試用例的執行狀態

測試迴圈可以實時獲取測試用例執行情況，若測試用例執行狀態為「失敗」，我們會關聯一個 JIRA Issue。

另外，為了讓所有人都看到直觀的看到測試用例的執行與狀態，我們利用 Grafana 定製了一個看板，使得測試結果視覺化，讓大家對產品質量有一個感性的解讀。

5.5 測試報告

一份完整的測試報告，包含：

摘要總結
  一句話總結本輪迭代測試的結論
  程式碼改動範圍
    新功能
    缺陷修復
  測試版本
    映象名
    映象版本
  測試環境資訊
    伺服器名稱
    伺服器版本
缺陷驗證
  新發現
  已修復
  已驗證
測試詳情
  新功能驗證
  迴歸測試
  效能測試
  安全性測試

六. 缺陷管理

6.1 JIRA

缺陷的管理都在 JIRA 中完成，對於缺陷的釋出，我們有著嚴謹的格式。除了填入 Sprint 資訊供相關人員追蹤外，還額外要求填入一些必要的標籤，以標註缺陷發現的迭代週期、缺陷的型別、缺陷的功能模組，作為經驗教訓總結時的資料分析。

我們要求的必填項

• 專案
• 問題型別
• 主題
• 模組
• 描述
• Sprint
• 優先順序
• 標籤

6.2 缺陷的處理

開發工程師領取到屬於自己的缺陷後，將其拖入「處理中」，修復自測後再拖入「待驗證」交由測試工程師做最後的驗證，並留下關於該缺陷的備註，如根本原因、解決方案等。

測試工程師驗證時會填寫詳細的驗證環境和步驟，有利於若問題重現，可找到歷史記錄進行分析。

6.3 缺陷的追蹤

利用 JIRA 的衝刺看板追蹤每個缺陷的當前階段，在測試交付前應該都在「已驗證後關閉」的狀態，非問題的 ISSUE 一般不會很多。

七. 釋出後管理

7.1 缺陷分析

除了利用 JIRA 自身的看板，我們還利用 Grafana 增強了在當前衝刺期內的多樣趨勢圖，以便於所有人都對一個週期內的進度有個直觀感知，並且針對每個新功能也展現缺陷狀態，這些資料都將作為本輪迭代軟體質量的評估資料來源之一。

對於缺陷的追蹤，我們更關注在產品釋出後，如何利用這些歷史資料來提升未來的軟體質量。

每輪迭代有一些正常規律，比如缺陷數量通常在前兩個釋出候選版本較多，相對複雜的新功能產生的缺陷數量會相對較多。

若出現後期某個候選版本缺陷數量突然增多，則要考慮產生該現象的原因，在釋出前，就要考慮重新評估該原因帶來的影響。

而對於沒有產生任何缺陷記錄的程式碼改動，同樣要引起注意，需要評估測試的覆蓋程度和深度。

所有缺陷的來源通常有：

• 測試發現
• 開發發現
• 客戶現場

每種來源都將作為軟體質量不同的改進方向。

而對於缺陷的類別，比如：迴歸、新功能、偶發、概率等等。

也是我們分析的一個方向。

其中迴歸問題是我們特別關注的，同時也是最影響軟體質量信心的一種。

7.2 迴歸改進

每輪發布之後，需要對迴歸測試的範圍進行更新，以增加新的覆蓋點，主要的來源有：

• 最近一輪期間新功能的驗證
• 最近一輪期間 Hotfix 的驗證
• 最近一輪期間客戶反饋的問題
• 最近一輪期間開發和測試新發現的缺陷
• 由於對技術和產品的積累，測試主動新增的測試用例

7.3 測試用例自動化

迴歸測試是一個非常尷尬的測試範圍。

理論上來說，迴歸測試不應該出現執行失敗，所以很多時候，迴歸測試是增強軟體質量信心的一種手段。

但迴歸測試的範圍是不斷擴大的，每一輪的新功能測試範圍，必然會有一部分會歸納到下一輪的迴歸測試範圍內。

因此，迴歸測試的範圍就像一個永遠滾不完的雪球，越來越大，越來越重。

介面測試是迴歸範圍中最容易實現自動化，並且投入產出效果最佳的測試範圍，並且實現介面測試自動化的最佳時期就是開發過程中。

但仍然還有相當多的測試用例是需要多花點精力才能實現自動化的，因此在產品釋出後，我們都會對這些遺留的可自動化測試用例持續的實現。

八. 結束語

軟體質量是產品的血液，需要整個團隊共同保障，特別是在 DevOps 團隊中，成員的職責逐漸變得模糊，更應人人關注。

以上是一個比較通用的全流程，具體細節需要根據自身產品特性做調整。