網際網路敏捷化開發風格盛行的趨勢下，測試地位趨於邊緣化，受限於公司和部門的固有風格化，經常和開發人員一起跟著產品經理疲於做折返跑運動。這裡不聊開發產品測試那些事，打鐵還需自身硬，主要講下如何從測試和專案整體出發、建立一套穩定有效的質量保障體系。

版本釋出

版本的釋出，一般分為以下型別：

• 專案，週期較長，立項到上線在3周以上
• 迭代，正常小版本迭代，以周為單位
• 生產問題修復，線上問題緊急處理，即時發版

本文著重聊下專案型別，比較適用於中、大型網際網路公司。 參與角色，常規有：產品、開發、測試、運維、業務驗收方。 專案的階段性活動有以下：

• 立項、需求宣講
• 設計、編碼、整合
• 計劃、準備策略、執行測試
• 業務方驗收，原則上建議分批驗收，問題發現在源頭
• 生產釋出、線上驗證
• 業務監控，線上質量的重要保證，把影響控制在小範圍內，預先發現並解決

質量保障體系，依賴於合格的流程，而以上這些活動是保障質量的基礎。

下面進入本文的重點，衡量質量保障體系好壞的標準，不是裡面的內容多麼充實、飽滿，而在於執行力。落地後，需要整個團隊去遵守，形成思維化習慣而落地，在執行的過程中不斷去優化，進而繼續堅持。

質量保障體系的核心包括以下幾點：

1. 文件
2. 評審機制
3. 准入、準出標準
4. 重視迴歸測試
5. 生產問題定期覆盤
6. 生產監控、報警機制

下面逐條解釋下每一點的核心價值和策略。

一. 文件管理

關鍵詞：需求文件、設計文件、測試文件

需求和設計產出方為產品、開發，測試需要做好流程監督，這裡重點說下測試文件。

測試文件，從業務領域來說，一般有測試計劃、測試用例、業務總結文件。

測試計劃

測試計劃，描述測試活動的規劃、策略，運籌帷幄，防患於未然。裡面重要的幾個點，測試範圍、測試策略、測試進度、准入準出標準、風險評估。測試範圍，內部需要細化到模組，外部是否有依賴方或被依賴方，需要提前告知對方，安排聯調。測試策略，人員的安排，每一階段的測試活動，工具的使用、自動化、效能的介入。測試進度，需要固定的跟蹤，如定期同步測試進度，告知風險。可提測的准入標準，測試後期是否符合上線條件的準出標準，業務人員的及時驗收、反饋。風險評估，一般是時間規劃不足，不能按時交付。

測試用例

測試用例，是測試執行文件，不建議做迭代維護，可讀性差，描述更多的是對業務細則的如何測試，包含邊界值、有效等價類等測試方法，過於瑣碎，不適合提煉維護。所以，我對測試用例的定義是，當前版本有效。

業務總結文件，是對當前系統業務的描述、彙總，通過該文件，可以一目瞭然當前系統的基礎邏輯。更側重於從業務邏輯角度描述系統，是測試人員的幫助文件，需要在每次迭代後及時更新，無需去翻看測試用例。熟悉、掌握系統核心業務，是測試人員的一項基礎能力。

二.評審機制

資訊的傳遞具有時效性，一份需求從產品->專案經理->研發團隊->測試團隊，如果測試團隊在最後測試準備階段接入，會丟失很多的資訊。軟體的生命週期如果用W模型來定義，那麼每個階段，測試的活動都是聯動的。

所以，每個階段的產出對應的評審是必不可少的：需求評審、開發設計評審、測試計劃評審、測試用例評審。

三.准入、準出標準

准入標準，即提測標準，為冒煙測試用例通過，驗收人為測試人員，通過率可以酌情而定，比如超過70%的通過率則提測通過，否則打回。冒煙測試用例會維護並分享給開發人員，提測前，開發人員內部自測下，提高溝通效率。

制定提測標準的目的是為了約束開發工作能按時交付，如果測試的週期為10天，開發提測質量較差，導致修復阻塞性問題花費了兩三天，這樣會影響版本按時上線。出於質量的考慮，專案會順延上線，每個環節都是螺絲釘，環環相扣，不能顧此失彼。

準出標準，即符合上線的標準，一般參考點有兩個：測試報告、業務驗收。例如通過率超過95%才能符合上線，遺留缺陷登記P3的數量，是否影響業務功能。業務驗收，介入越早越好，可以分批驗收。

生產驗證，一般是在釋出後，使用測試賬號在生產進行可測試性驗證。生產的釋出比較複雜，包括程式碼的釋出、配置變更、DB變更、運維操作、網路層通訊等，每個環節的疏忽或誤操作，都會影響到本次釋出。

四.迴歸測試

版本測試是為了保證當前版本需求的質量，而回歸測試時保證整個系統業務的質量，重要性不言而喻。

測試人員的一個盲點，願意花費大部分時間在了版本測試上，而用少量的時間做迴歸測試，這個習慣是致命的。需求的改動，是小範圍的，影響可能是全域性的，對於支付類的業務更是不能有一絲的輕視。

所以，測試團隊要重視迴歸測試，並預留足夠的時間比重來做這一塊。一定要維護、寫好迴歸用例，從業務影響上設定用例的優先順序，這樣才能有足夠的信心應對每一次的版本釋出。

五.問題覆盤

問題覆盤，包括潛在風險、已暴露問題。

潛在風險，如排期過短、流程不規範等，需要提前介入，重新評估，避免風險在最後暴露。

已暴露問題，一般為生產問題，需要做團隊內部的覆盤整理，參與方，包括產品、研發、測試。建議一個月至少一次，總結問題，進而完善質量保障體系。

六.監控報警

版本釋出成功以後，還需要監控新版本系統的執行健康情況。

這裡有個灰度的概念，新版本的更新，可以先開放給少部分使用者使用，執行一段時間後，沒有問題，再開放給全部使用者。

監控包括：資料庫監控、應用服務監控、異常日誌報警、資料量暴或暴減異常預警。 ———————————————— 版權宣告：本文為CSDN博主「愛吃胡蘿蔔的兔子」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處連結及本宣告。 原文連結：https://blog.csdn.net/zsibiao/article/details/106544859