阿里測試團隊：如何建設(shè)軟件質(zhì)量保障體系

互聯(lián)網(wǎng)敏捷化開發(fā)風格盛行的趨勢下，測試地位趨于邊緣化，受限于公司和部門的固有風格化，經(jīng)常和開發(fā)人員一起跟著產(chǎn)品經(jīng)理疲于做折返跑運動。這里不聊開發(fā)產(chǎn)品測試那些事，打鐵還需自身硬，主要講下如何從測試和項目整體出發(fā)、建立一套穩(wěn)定有效的質(zhì)量保障體系。

版本的發(fā)布，一般分為以下類型：

本文著重聊下項目類型，比較適用于中、大型互聯(lián)網(wǎng)公司。

參與角色，常規(guī)有：產(chǎn)品、開發(fā)、測試、運維、業(yè)務(wù)驗收方。

項目的階段性活動有以下：

質(zhì)量保障體系，依賴于合格的流程，而以上這些活動是保障質(zhì)量的基礎(chǔ)。

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

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

關(guān)鍵詞：需求文檔、設(shè)計文檔、測試文檔

需求和設(shè)計產(chǎn)出方為產(chǎn)品、開發(fā)，測試需要做好流程監(jiān)督，這里重點說下測試文檔。

測試文檔，從業(yè)務(wù)領(lǐng)域來說，一般有測試計劃、測試用例、業(yè)務(wù)總結(jié)文檔。

測試計劃，描述測試活動的規(guī)劃、策略，運籌帷幄，防患于未然。里面重要的幾個點，測試范圍、測試策略、測試進度、準入準出標準、風險評估。測試范圍，內(nèi)部需要細化到模塊，外部是否有依賴方或被依賴方，需要提前告知對方，安排聯(lián)調(diào)。測試策略，人員的安排，每一階段的測試活動，工具的使用、自動化、性能的介入。測試進度，需要固定的跟蹤，如定期同步測試進度，告知風險。可提測的準入標準，測試后期是否符合上線條件的準出標準，業(yè)務(wù)人員的及時驗收、反饋。風險評估，一般是時間規(guī)劃不足，不能按時交付。

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

業(yè)務(wù)總結(jié)文檔，是對當前系統(tǒng)業(yè)務(wù)的描述、匯總，通過該文檔，可以一目了然當前系統(tǒng)的基礎(chǔ)邏輯。更側(cè)重于從業(yè)務(wù)邏輯角度描述系統(tǒng)，是測試人員的幫助文檔，需要在每次迭代后及時更新，無需去翻看測試用例。熟悉、掌握系統(tǒng)核心業(yè)務(wù)，是測試人員的一項基礎(chǔ)能力。

信息的傳遞具有時效性，一份需求從產(chǎn)品->項目經(jīng)理->研發(fā)團隊->測試團隊，如果測試團隊在最后測試準備階段接入，會丟失很多的信息。軟件的生命周期如果用W模型來定義，那么每個階段，測試的活動都是聯(lián)動的。

所以，每個階段的產(chǎn)出對應(yīng)的評審是必不可少的：需求評審、開發(fā)設(shè)計評審、測試計劃評審、測試用例評審。

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

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

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

生產(chǎn)驗證，一般是在發(fā)布后，使用測試賬號在生產(chǎn)進行可測試性驗證。生產(chǎn)的發(fā)布比較復雜，包括代碼的發(fā)布、配置變更、DB變更、運維操作、網(wǎng)絡(luò)層通信等，每個環(huán)節(jié)的疏忽或誤操作，都會影響到本次發(fā)布。

版本測試是為了保證當前版本需求的質(zhì)量，而回歸測試時保證整個系統(tǒng)業(yè)務(wù)的質(zhì)量，重要性不言而喻。

測試人員的一個盲點，愿意花費大部分時間在了版本測試上，而用少量的時間做回歸測試，這個習慣是致命的。需求的改動，是小范圍的，影響可能是全局的，對于支付類的業(yè)務(wù)更是不能有一絲的輕視。

所以，測試團隊要重視回歸測試，并預(yù)留足夠的時間比重來做這一塊。一定要維護、寫好回歸用例，從業(yè)務(wù)影響上設(shè)定用例的優(yōu)先級，這樣才能有足夠的信心應(yīng)對每一次的版本發(fā)布。

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

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

已暴露問題，一般為生產(chǎn)問題，需要做團隊內(nèi)部的復盤整理，參與方，包括產(chǎn)品、研發(fā)、測試。建議一個月至少一次，總結(jié)問題，進而完善質(zhì)量保障體系。

版本發(fā)布成功以后，還需要監(jiān)控新版本系統(tǒng)的運行健康情況。

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

監(jiān)控包括：數(shù)據(jù)庫監(jiān)控、應(yīng)用服務(wù)監(jiān)控、異常日志報警、數(shù)據(jù)量暴或暴減異常預(yù)警。

PS:  最近由狂師老師親自授課主講的「全棧測試開發(fā)技能訓練營」二期正在招生，課程非常值得推薦，課程大綱可閱：重磅消息 | 2021年最新全棧測試開發(fā)技能實戰(zhàn)指南（第2期）

轉(zhuǎn)載自：http://navo.top/BVBBVf