品質保障體系的搭建，并非測試人員一方的責任，需要産品、研發、項目經理、運維工程師一起參與來搭建這個體系。
一、研發流程階段
1. 需求階段
需求階段主要確定「産品經理」輸出的原始需求能被項目經理、研發人員、測試人員所認可。
1.1 流程概述
- 「項目經理」進行項目立項，「産品經理」收集、整理各方需求，并輸出産品需求規格書，即PRD
- 「項目經理」、「研發負責人」、「測試負責人」對PRD進行評審，并提出意見或建議
- 「産品經理」根據需求評審的結果進行評估分析，并對PRD進行修訂
-
「項目經理」、「研發負責人」、「測試負責人」針對修訂後的需求進行二次确認，評審通過後，需求定稿存入項目空間。定稿後的需求在核心要點上不允許進行随意變更，如需變更則需走需求變更流程
（這裡産品要輸出的東西需要補充：需求說明書、UI設計等）
1.2 需求評審
評審要點：
- 正确性：
- 是否清晰準确的陳述了要開發的功能
- 完整性：
- 正常場景、異常場景是否均有考慮到
- UI、互動設計是否完整
- 流程類需求是否有清晰的流程圖
- 是否存在隐藏的需求
- 合理性：
- 是否與現有功能沖突，存在沖突時是否有相容方案
- 使用者體驗是否合理
- 可行性：
- 需求中的功能是否具有可操作性，能否通過現有技術實作
- 可測試性：
- 是否每項需求均有驗證的标準及方法，可通過設計測試用例或者其他驗證方法來進行測試
- 可傳遞性：
- 評估是否能在規定時間内進行傳遞
- 傳遞成本是否過高，例如部署、遷移
- 無二義性：
- 需求是否存在模糊描述，例如：同已有邏輯
- 配置設定優先級：
- 是否對所有需求都進行了優先級配置設定；若所有需求都一樣重要，那麼在項目管理過程中便無法靈活管控資源及進度
評審人員：
項目經理、産品經理、測試負責人、研發負責人
1.3 規範
1、統一的需求文檔模闆、互動設計規範說明、UI設計規範說明
2、評審必須登記評審記錄和會議紀要。記錄包括時間、評審項目、評審内容、參與人員、主持産品經理（項目負責）、内容紀要、記錄人
3、産品需求評審通過，即鎖定需求内容。如無十分必要不能随意變更
4、需求變更需走變更流程，并征得研發、測試、項目經理一緻認可
2. 研發階段
2.1 流程概述
- 「研發負責人」針對需求進行研發方案設計，并組織「産品經理」「測試負責人」進行評審
- 「研發負責人」對開發任務進行拆解、排期，并指派到個人
- 「研發人員」進行開發實作并聯調
- 「研發負責人」組織完成代碼review、研發自測，自測通過後進入版本提測
- 「運維人員」就研發提測的版本，部署到測試環境，傳遞給「測試人員」
2.2 研發設計方案
-
研發方案設計
研發的技術方案裡至少需要包含：
- 需求說明：
- 需求背景
- 需求拆解
- 概要設計，包含系統現狀、總體設計思路、系統架構圖、系統流程圖
- 詳細設計：
- 接口設計：提供接口設計文檔，包括入參出參字段定義，接口參數校驗邏輯，異常情況的處理和傳回的錯誤碼。
- 系統間互動流程：結合系統間流程圖說明整筆業務請求涉及哪些系統組成部分，業務的發起來源，系統間互動調用了具體哪個接口，請求處理基本步驟和資料落地存儲邏輯。
- 系統内處理流程：結合業務處理流程圖說明請求如何加工計算資料，處理的具體步驟，最終處理完成之後結果如何儲存，或者傳輸到什麼地方。
- 存儲設計：包括存儲結構（包括MySQL、ES、Redis、OSS等）設計，包括表和字段的概念定義，各個表之間的關聯，業務系統如何使用這些庫表。
- 安全問題：資料安全、接口安全
- 需求說明：
-
研發設計評審
評審要點：
- 正确性
- 技術設計是否可以滿足業務需求中的全部功能要求？
- 對異常場景考慮是否充分？
- 可測性
- 是否可測？
- 預期結果是否穩定？
- 非功能性
- 是否考慮了安全性、性能、穩定性、擴充性、可靠性等非功能品質屬性？
- 相容性
- 對不同形态和版本的終端是否相容？
- 對上下遊的服務和資料是否相容
- 部署方案
- 部署邏輯是否合理？
- 是否需要對資料結構、緩存、各類配置進行操作？
評審人員：
項目經理、研發工程師、測試工程師、産品經理
- 正确性
2.3 研發自測
【參與人員】開發
○ 【用例占比】所有核心主鍊路用例（P0、P1）用例；
○ 【通過标準】完成冒煙用例的驗證，測試會驗證開發同學的冒煙結果，通過後，需求進入提測階段，否則打回重新冒煙
3. 測試階段
測試階段主要是通過測試政策、測試用例以及一系列的測試手段等確定版本品質。
3.1 流程概述
- 根據需求功能、研發設計方案，結合現有測試資源、測試能力，制定合理的測試計劃，來確定能夠在規定時間内傳遞産品
- 「測試工程師」根據配置設定的任務進行測試用例設計，并組織「産品經理」、「研發工程師」進行評審定稿
- 版本提測後，「測試工程師」對系統進行冒煙測試，檢驗版本是否達到測試準入标準，若準入驗證通過則進行大規模測試，若不通過則版本打回研發
- 版本正式提測後，「測試工程師」根據制定的測試計劃，運用各種測試方法對系統進行測試，以確定版本品質
- 版本測試通過後，由「測試負責人」輸出測試報告，并就遺留缺陷組織「項目經理」「産品經理」進行評審确認是否可遺留
3.2 測試計劃
-
測試計劃制定：
由測試負責人根據需求、研發設計方案、傳遞時間、資源情況評估，制定測試計劃，確定版本可如期傳遞。
測試計劃核心要素：
測試計劃制定規範：後續補充文檔測試範圍：新功能、舊功能，分别需要覆寫哪些
測試時間：什麼時間測試開始，什麼時間結束
測試政策：需要安排幾輪測試？每一輪的測試重點有哪些？需要運用哪些測試方法（性能、安全、穩定性測試等）、測試工具？
測試環境：在什麼環境測？環境配置要求如何？
測試資源：需要哪些人力資源投入，資源如何安排
風險控制：識别的風險有哪些？對應的解決方案？
-
測試計劃評審：
評審要點：
參與人員：項目經理、産品經理、研發負責人、測試工程師- 測試環境：測試環境要求是否清晰，是否可提供
- 測試範圍：
- 是否覆寫了業務和技術需求？對于已有功能是否安排了必要的回歸？
- 是否存在測試過度？
- 測試優先級：對待測子產品是否進行了優先級配置設定
- 測試政策：
- 安排的測試輪次是否合理？是否包含包含基礎的冒煙、驗收等測試
- 風險控制：項目風險是哪些？（資源、技術）是否有對應的解決方案？
3.3 測試用例
-
測試用例設計
可參考文章：測試用例規範
-
測試用例評審
評審的時間不宜過早或過晚，一般提測前2天左右完成；單次評審時間不宜超過1個小時。
評審要點：
- 測試範圍：測試用例是否覆寫了業務和技術需求？對于已有功能是否進行了必要的回歸？
- 異常情況：用例是否考慮了非正常操作或其他異常情況？
- 易讀性：測試用例是否包含前置條件、操作步驟、期望結果等必要資訊？
- 非功能性設計：針對非功能性的需求和技術設計，測試用例是否設計充分？
通過标準：
确定用例覆寫所有設計的功能點，且明确每個用例的驗證點
評審人員：
産品經理、研發工程師、測試工程師
3.4 環境準備
- 測試環境部署，確定基礎環境搭建到位
- 應用服務架構，架構盡量與生産環境一緻
- 測試資料構造
- 用戶端裝置，例如測試移動端産品，則需相容的裝置機型、版本需提前準備就緒
3.5 測試準入
制定測試準入标準，若滿足标準則進入SIT測試階段，若不滿足則進行整改，直至滿足後方可進入下一階段。
測試準入條件：
- 需求規定的功能均已實作
- 研發自測通過率95%以上
- 測試用例已設計完畢，并評審通過，更新至用例管理平台
- 測試環境、工具、資料已準備就緒
- 測試用例在管理平台已完成配置設定指派
- 冒煙測試用例執行通過率95%以上
3.6 測試執行
根據測試計劃、測試政策要求，對待測系統服務進行功能測試、性能測試、安全測試等。測試執行過程中核心保障測試進度管理、缺陷管理。
-
缺陷管理
缺陷标準規範，參考：
BUG描述規範
BUG處理流程規範
- 進度管理
- 嚴格按照測試計劃确定的優先級進行測試任務的執行
- 測試進度日報；測試執行人員每天按統一的模闆彙報各自的測試進度及關鍵問題，測試負責人彙總後，再按統一的模闆整合彙報到項目組，彙總的進度日報裡關鍵資訊需包含
整體測試進度
活躍BUG統計
關鍵問題
主要風險
- 測試範圍變更管理；包括對需求變更、人員請假、環境異常、優先級調整等導緻的測試政策、測試計劃變更，需嚴格控制變更情況，若有風險，需及時溝通解決
3.7 測試報告
測試報告規範後續補充
3.8 測試準出
測試準出條件：
- 被測項目滿足産品需求
- SIT測試覆寫率100%
- 已輸出測試報告
- P0、P1、P2級BUG修複率100%
- P3、P4級BUG修複率95%以上
- 遺留問題均已評審通過，并有解決方案（延期處理/暫不處理/轉需求/挂起等）
- 性能名額符合要求
4. 傳遞階段
傳遞階段主要確定産品釋出後，能完整、穩定在客戶線上環境運作。
4.1 流程概述
- 「項目經理」「産品經理」對産品進行UAT驗證，必要時還需要業務方參與，确認需求實作滿足業務方要求
- 釋出材料準備：
- changelog說明，由「産品經理」準備
- 使用者教育訓練手冊，由「産品經理」準備
- 服務版本号，由「測試經理」最終确認，并同「研發人員」「運維人員」達成一緻
- 遺留問題清單，由「測試經理」準備；需注意這裡的遺留問題必須是項目組評審通過的
- 測試報告，由「測試經理」準備
- 上線釋出方案，由「測試經理」組織「研發人員」、「運維人員」制定，方案包括：資料庫腳本執行、各服務釋出版本号、部署順序、部署時間點、部署復原方案（包括資料庫復原和應用程式復原）等
- 線上功能checklist，由「測試經理」準備，用于釋出後對線上環境的功能回歸，時間需控制在1個小時内
- 執行釋出流程，由「DBA」、「運維人員」按計劃執行釋出流程，由「研發人員」核對部署與配置的正确性，最後由「測試人員」進行功能checklist執行，驗證結果及問題回報到開發處，嚴重問題若無法在計劃時間内解決則執行復原方案，不影響功能的問題則進行記錄，遺留後續疊代計劃處理
4.2 預演方案
如釋出流程複雜，不可控因素較多，可視情況組織釋出預演練。即在指定環境模拟一遍正式釋出的流程。方案上基本同正式釋出一緻，差別僅在于操作的環境。
演練過程需記錄每個流程的耗時及問題點，演練結束後組織複盤，并針對問題點進行流程的調整優化。
4.3 上線方案
上線方案主要明确釋出流程的每一個步驟、預計執行時間、負責人及問題解決預案，確定版本能正常部署到生産環境。
釋出前
- 服務更新配置表，确定伺服器CPU/記憶體規格、環境變量配置、業務配置等；配置需提前梳理并由研發、運維确認無誤
- 釋出平台、資料庫權限臨時開放給對應人員
- 各子產品上線checklist定稿
- 資料執行腳本核對
釋出中
- 資料備份
- 資料腳本執行流程
- 各服務部署先後順序及預計執行時間
- 服務間依賴關聯，啟動順序約定
釋出後
- checklist執行驗證
風險及解決方案
- 關鍵環節的風險預判及應急預案
- 服務復原政策及流程
- 資料復原政策及流程
4.4 線上checklist
-
開發部分
主要負責確定服務部署的正确性。checklist内容至少需包含如下：
- 服務版本号是否正确
- 服務配置檢查，例如伺服器CPU/記憶體規格等、環境變量、業務配置
- 服務啟動是否正常，健康狀态是否正常等
- 服務日志接口是否有異常報錯
- 資料遷移校驗，資料正确性
-
測試部分
主要負責驗證線上環境核心功能流程可正常運作。
功能checklist
checklist設計完後需組織産品經理、研發經理、項目經理進行評審。
checklist的設計部分需遵循：
- checklist的目的主要是保障核心功能流程正常，而非SIT階段的BUG挖掘，是以在用例設計上，要差別于功能用例設計
- 需區分哪些可自動化覆寫，哪些需要人工驗證
- 需配置設定指派到人，并且整體驗證時長需控制在1個小時内
全鍊路壓測
核心驗證系統穩定性。需提前确認壓測場景、壓測時長，并組織評審通過
5. 運維階段
版本釋出上線後，還需要確定能夠實時監控，及時發現異常并告警，在規定時間内進行定位解決，保障生産穩定性。
5.1 監控告警
明确監控方法、監控名額、告警機制。
具體後續補充
5.2 故障處理
故障處理流程規範，後續補充
二、持續內建持續傳遞 CI/CD
明确各種“類生産環境”的作用及差異點，保障環境穩定可用；常見環境劃分包括：
- 開發環境
- 測試環境
- 預釋出環境
- 生産環境
基于以上環境，将各種測試技術和自動化技術內建起來，使代碼送出後能 自動建構、部署、測試，生成工具鍊。
三、測試體系建設
1. 效率
1、測試左移：
- 做好過程品質把控，包括需求評審、研發設計評審，減少無效返工
- 研發自測推進，由測試提供研發自測用例，或研發提供測試評審，推進研發自測，提升版本提測品質 并通過測試準入驗證，把控研發提測品質
- 制定測試準入标準，設計冒煙測試用例，如果冒煙測試通過率<90%，則提測版本打回開發
2、測試政策：
旨在減少不必要的測試，盡早暴露重點問題并推進解決。有效的測試政策，能最大限度提升測試效率。
常見測試政策制定：以上僅供參考，實際需根據項目具體情況進行調整
- 冒煙測試：隻驗證核心功能鍊路，不需要細測，暴露出影響流程的BUG；冒煙測試的用例通常選擇BVT用例執行
- 第一輪：新功能全面細測，舊功能隻測試BVT+高等級用例，盡可能挖掘所有能發現的BUG
- 第二輪——第x輪：驗證上一輪BUG，并根據上一輪測試情況，調整本輪測試政策
- 回歸測試：驗證全部BUG，所有功能進行BVT+高等級用例測試，保障核心功能流程
3、自動化測試：
- 根據業務特點，建構核心功能鍊路自動化能力，用于冒煙驗證、釋出內建回歸，來提升傳遞效率，常見有接口自動化、UI自動化，需根據項目及團隊情況選擇合适的自動化手段；
自動化測試效益分析：
ROI = 自動化提升的效率/自動化産生的成本 = （手工用例執行的時間 - 自動化用例執行時間）* 自動化用例的有效執行次數 / 自動化用例編寫和維護的總成本
- 持續內建與持續傳遞
4、專項解決痛點：
- 分析實際影響效率的痛點問題，制定對應的解決方案；不限于工具支撐、人員補充、人員培養等
- 缺陷輔助定位工具；在研發測試階段，我們有大量的開發工作量實際是耗費在缺陷的确認、重制、定位、修改、驗證上，對于疑難或機率性缺陷若有工具能輔助定位分析，則效率能大大提升
2. 品質
1、測試模型
基于深入了解行業産品特性，産出測試模型，包括但不限于： 業務流程、業務特性樹、業務場景等。測試模型建構的合理性和完整性是後續品質保障的基礎
2、測試規範
遵循制定好的規範，減少過程無效溝通及返工。包括但不限于：用例編寫規範、測試過程規範、BUG編寫規範、BUG處理規範、壓測規範等
3、測試技術
-
接口測試
接口測試是測試系統元件間接口的一種測試。接口測試主要用于檢測外部系統與系統之間以及内部各個子系統之間的互動點。測試的重點是要檢查資料的交換，傳遞和控制管理過程，以及系統間的互相邏輯依賴關系等
接口測試工具：Postman、Jmeter、Apipost為什麼要進行接口測試
1.越底層發現bug，它的修複成本是越低的。
2.前端随便變，接口測好了，後端不用變，前後端是兩撥人開發的。
3.檢查系統的安全性、穩定性，前端傳參不可信。
4.如今的系統複雜度不斷上升，傳統的測試方法成本急劇增加且測試效率大幅下降，接口測試可以提供這種情況下的解決方案。
5. 接口測試相對容易實作自動化持續內建，且相對UI自動化也比較穩定，可以減少人工回歸測試人力成本與時間，縮短測試周期，支援後端快速發版需求。接口持續內建是為什麼能低成本高收益的根源。
6. 現在很多系統前後端架構是分離的，從安全層面來說做接口測試很有必要。
-
安全測試
滲透測試，以成功入侵系統，證明系統存在安全問題為出發點，以攻擊者的角度來看待 和思考問題
安全測試工具：Burp Suite 、AppScan、Nmap、kail Linux等
-
性能測試
性能測試是通過增加使用者請求通路量來測試軟體或應用程式的穩定性及響應時間。
目的是驗證軟體系統是否能夠達到需求提出的性能名額，同時發現軟體系統中存在的性能瓶頸。
性能測試工具：LoadRunner、Jmeter等
-
全鍊路壓測
微服務架構下，單服務接口性能測試很難模拟出接近生産環境的場景和資料規模，單接口壓測通過并不能代表整個系統鍊路的性能。尤其是QPS 比較高的場景，如果不進行全鍊路壓測，隻要鍊路中一個環節挂掉，就會引起整個鍊路的崩潰。
全鍊路壓測是基于實際的生産業務場景和系統環境，模拟海量的使用者請求和資料，對整個業務鍊路進行各種場景的測試驗證，持續發現并進行瓶頸調優，保障系統穩定性。
全鍊路壓測的目标
- 實作生産環境的壓測服務，模拟真實的生産峰值場景，以發現真實的線上瓶頸并實作監控分析
- 實作精準的容量規劃，確定線上系統的正常運作
- 實作壓測流量和生産流量的隔離，避免對生産流量産生影響
-
其他專項測試
同樣在微服務背景下，很多企業項目開始進行容器化部署。為應對Kubernetes+Docker+微服務部署模式的特性，提高測試品質，在測試技術上也衍生出各種專項測試技術，例如：
1、系統容災測試：
通過模拟斷電、斷網、服務崩潰等異常情況，驗證系統的健康狀态監視和異常情況下的功能切換、系統恢複能力
2、pod彈性擴縮容測試：
通過模拟使用者請求，增大/降低系統服務負載，驗證服務是否能在負載大的時候，自動進行擴容，確定所有請求能正常響應，當負載小的時候自動進行縮容，以避免資源浪費。彈性擴縮容的測試驗證除了關注功能本身外，還需要關注擴容、縮容的速度；縮容政策，例如當有請求還在被指定縮容的pod上時，如何能確定不影響使用者正常使用
3、服務負載均衡測試：
單台服務的負載是有限的，當負載較大時，就需要有多台相同的伺服器，此時為避免流量全部打到同一台服務上導緻負載過大而異常，就需要有負載均衡政策調配，控制流量的走向。而測試則通過工具模拟請求，驗證負載均衡政策是否合理，是否能正常生效
…等等
3. 組織過程資産
通過制定标準組織過程資産沉澱模闆和節奏，保障過程資産有效沉澱，可以複用。
組織過程資産包括：
1、空間目錄
例如下圖，實際可根據内部情況調整
2、流程規範
包括但不限于測試流程定義、測試計劃模闆、測試用例模闆、報告模闆、缺陷規範、釋出規範等
-
流程定義
規定項目流程中所需的活動、活動階段、負責人等，包括：項目立項、裡程碑确定、需求評審、用例設計、測試計劃、測試執行、測試總結、UAT試用、版本釋出、過程品質管理
-
标準定義
品質标準定義：測試覆寫率、有效BUG率、整體漏測率、BUG收斂情況等
-
文檔模闆
包括測試計劃模闆、測試用例模闆、測試報告模闆、缺陷登記模闆等
-
測試用例庫
功能用例庫、自動化用例庫
3、測試方法沉澱
各類測試方法、測試技術沉澱（接口測試、自動化測試、性能測試、安全測試、專項測試等）
4、固資管理
例如：測試環境資訊、測試裝置資訊維護
5、業務知識庫
6、教育訓練材料
内部分享課程材料
四、度量與營運
“你如果無法度量它，就無法管理它”
1. 品質度量名額
過程品質：
- 需求品質
- 需求評審打回次數
- 需求變更次數
- 需求增加次數
- 需求品質BUG數
- 開發品質
- 提測品質
- 測試準入打回次數
- 代碼品質
- P0/P1 BUG占比
- BUG工時比
- 測試品質
- 測試覆寫率
- 有效BUG率
- 整體漏測率
- BUG收斂情況
- 釋出品質
- 釋出復原率
傳遞品質：
- 線上故障：線上故障數、故障級别、線上故障恢複時長、線上缺陷數
- 服務穩定性：服務可用性、錯誤類型分布、錯誤數量、錯誤率、報警數
- 服務可用性：度量線上服務的性能，接口響應時間、慢響應率、慢查詢、最大QPS
- 服務安全性：安全漏洞嚴重問題數
2. 效率度量名額
- 傳遞周期比、工時比
3. SMART原則
- 具體的 specific
- 可度量 measurable
- 可達到 attainable
- 與其他目标有相關性 relevant
- 有明确的截止期限 time-bound
4. PDCA閉環
- Plan 制定改進計劃
- 品質痛點驅動
- 品質目标驅動
- Do 實施落地計劃
- 資料收集和聚合
- Check 複盤和回報
- 書面總結報告
- 複盤總結會
- Action 改進和推廣
五、品質文化建設
想把品質做好，流程和方法是"術"的層面，文化是“道”的層面。文化是組織成員表現出來的共同的信念、價值觀、态度、制度和行為模式。
在大多數品質保障體系推行過程中更多關注的是可見的品質标準、要求、操作程式等，換句話說，也就是被要求應該如何做，而不是主動、自發的品質意識和行為。
品質文化的建設應該自上而下，由高層主導建構文化，并推行以獲得品質認知統一，讓所有人參與到持續改進中，輔以一系列獎懲制度。