重溫一下測試的理論，似曾相識。
今天看大這個文檔轉載阿里測試團隊：如何建設軟件質量保障體系 (qq.com) ：）
互聯網敏捷化開發風格盛行的趨勢下，測試地位趨於邊緣化，受限於公司和部門的固有風格化，經常和開發人員一起跟着產品經理疲於做折返跑運動。
這里不聊開發產品測試那些事，打鐵還需自身硬，主要講下如何從測試和項目整體出發、建立一套穩定有效的質量保障體系。
版本的發布，一般分為以下類型：
-
項目，周期較長，立項到上線在3周以上
-
迭代，正常小版本迭代，以周為單位
-
生產問題修復，線上問題緊急處理，即時發版
本文着重聊下項目類型，比較適用於中、大型互聯網公司。
參與角色，常規有：產品、開發、測試、運維、業務驗收方。
項目的階段性活動有以下：
-
立項、需求宣講
-
設計、編碼、集成
-
計划、准備策略、執行測試
-
業務方驗收，原則上建議分批驗收，問題發現在源頭
-
生產發布、線上驗證
-
業務監控，線上質量的重要保證，把影響控制在小范圍內，預先發現並解決
質量保障體系，依賴於合格的流程，而以上這些活動是保障質量的基礎。
下面進入本文的重點，衡量質量保障體系好壞的標准，不是里面的內容多么充實、飽滿，而在於執行力。落地后，需要整個團隊去遵守，形成思維化習慣而落地，在執行的過程中不斷去優化，進而繼續堅持。
質量保障體系的核心包括以下幾點：
-
文檔
-
評審機制
-
准入、准出標准
-
重視回歸測試
-
生產問題定期復盤
-
生產監控、報警機制
下面逐條解釋下每一點的核心價值和策略。
01文檔管理
關鍵詞：需求文檔、設計文檔、測試文檔
需求和設計產出方為產品、開發，測試需要做好流程監督，這里重點說下測試文檔。
測試文檔，從業務領域來說，一般有測試計划、測試用例、業務總結文檔。
測試計划，描述測試活動的規划、策略，運籌帷幄，防患於未然。里面重要的幾個點，測試范圍、測試策略、測試進度、准入准出標准、風險評估。測試范圍，內部需要細化到模塊，外部是否有依賴方或被依賴方，需要提前告知對方，安排聯調。測試策略，人員的安排，每一階段的測試活動，工具的使用、自動化、性能的介入。測試進度，需要固定的跟蹤，如定期同步測試進度，告知風險。可提測的准入標准，測試后期是否符合上線條件的准出標准，業務人員的及時驗收、反饋。風險評估，一般是時間規划不足，不能按時交付。
測試用例，是測試執行文檔，不建議做迭代維護，可讀性差，描述更多的是對業務細則的如何測試，包含邊界值、有效等價類等測試方法，過於瑣碎，不適合提煉維護。所以，我對測試用例的定義是，當前版本有效。
業務總結文檔，是對當前系統業務的描述、匯總，通過該文檔，可以一目了然當前系統的基礎邏輯。更側重於從業務邏輯角度描述系統，是測試人員的幫助文檔，需要在每次迭代后及時更新，無需去翻看測試用例。熟悉、掌握系統核心業務，是測試人員的一項基礎能力。
02評審機制
信息的傳遞具有時效性，一份需求從產品->項目經理->研發團隊->測試團隊，如果測試團隊在最后測試准備階段接入，會丟失很多的信息。軟件的生命周期如果用W模型來定義，那么每個階段，測試的活動都是聯動的。
所以，每個階段的產出對應的評審是必不可少的：需求評審、開發設計評審、測試計划評審、測試用例評審
03准入、准出標准
准入標准，即提測標准，為冒煙測試用例通過，驗收人為測試人員，通過率可以酌情而定，比如超過70%的通過率則提測通過，否則打回。冒煙測試用例會維護並分享給開發人員，提測前，開發人員內部自測下，提高溝通效率。
制定提測標准的目的是為了約束開發工作能按時交付，如果測試的周期為10天，開發提測質量較差，導致修復阻塞性問題花費了兩三天，這樣會影響版本按時上線。出於質量的考慮，項目會順延上線，每個環節都是螺絲釘，環環相扣，不能顧此失彼。
准出標准，即符合上線的標准，一般參考點有兩個：測試報告、業務驗收。例如通過率超過95%才能符合上線，遺留缺陷登記P3的數量，是否影響業務功能。業務驗收，介入越早越好，可以分批驗收。
生產驗證，一般是在發布后，使用測試賬號在生產進行可測試性驗證。生產的發布比較復雜，包括代碼的發布、配置變更、DB變更、運維操作、網絡層通信等，每個環節的疏忽或誤操作，都會影響到本次發布。
04回歸測試
版本測試是為了保證當前版本需求的質量，而回歸測試時保證整個系統業務的質量，重要性不言而喻。
測試人員的一個盲點，願意花費大部分時間在了版本測試上，而用少量的時間做回歸測試，這個習慣是致命的。需求的改動，是小范圍的，影響可能是全局的，對於支付類的業務更是不能有一絲的輕視。
所以，測試團隊要重視回歸測試，並預留足夠的時間比重來做這一塊。一定要維護、寫好回歸用例，從業務影響上設定用例的優先級，這樣才能有足夠的信心應對每一次的版本發布。
05問題復盤
問題復盤，包括潛在風險、已暴露問題。
潛在風險，如排期過短、流程不規范等，需要提前介入，重新評估，避免風險在最后暴露。
已暴露問題，一般為生產問題，需要做團隊內部的復盤整理，參與方，包括產品、研發、測試。建議一個月至少一次，總結問題，進而完善質量保障體系。
06監控報警
版本發布成功以后，還需要監控新版本系統的運行健康情況。
這里有個灰度的概念，新版本的更新，可以先開放給少部分用戶使用，運行一段時間后，沒有問題，再開放給全部用戶。
監控包括：數據庫監控、應用服務監控、異常日志報警、數據量暴或暴減異常預警。