感謝大家的蒞臨，小編在文章末尾為大家準備了一些福利，需要的可以獲取哦。

前言

測試作為整個項目中的一環，在項目流程中起著不可或缺的作用。部分團隊是缺少項目管理角色的，這個時候，測試對項目流程的推進、項目質量的保證顯得尤為重要。

好的測試，能在整個項目流程中以 QA 角度做好項目管理和及時的風險預警，讓項目如期上線且保障質量。

業界一直強調測試前置，那么測試在項目中，如何根據項目情況做前置工作推進項目流程，讓大家都開心工作呢？

本文以自己所在的項目組為例講述項目流程中的一些事，希望可以與大家一同探討~

一、QA 在項目中扮演的角色

【why】明確目標是什么：

明確做這個項目的目標是什么，可適當根據目標對需求實現、項目質量、研發提測時間點等做一些調節。

【when】項目的 deadline：

考慮項目組的特殊性，我們需要知道項目需要什么時候上線，明確項目 deadline，根據時間節點制定合適的測試計劃。

【what】各階段我們需要做什么：

可以重點關注項目流程中，QA 參與與輸出的環節。有輸入才會有輸出，所以輸出的環節往往是需要 QA 花費時間去思考的地方。

【how】遇到風險點時怎么做：

測試階段，除了 QA 環節的風險點需要及時暴露和 push 外，這個階段研發和產品也在做一些工作。在項目流程管理中，作為最下游的參與者，需要關注這些風險點，及時暴露和 push 解決。

【who】QA、RD、PM

二、我們面臨的挑戰

2.1 挑戰點

2.2 關于提測質量

針對上述挑戰的內容，我們可以看到提測質量上，我們存在不足之處。我們之前做過提高冒煙用例比例、冒煙交叉執行、時間預估增加冒煙時間等嘗試，最后發現收獲的效果有限。主要原因如下：

基于以上原因，我們可以看到在質量與效率之間需要做一定的選擇時，需要向項目效率傾斜，所以我們既然無法更好地改變提測質量，那就去改變我們能改變的。

三、面對這些挑戰，QA 可以做什么

QA 可以做什么讓整個迭代周期變短，在 bug 很多的情況下還能快速迭代且線上問題較少呢？先來看下我們的項目流程：

從整個項目流程上看，可能與很多團隊如出一轍。

在流程上，QA 作為下游的一個部分，可以看到 QA 參與輸出的內容其實有很多，這些部分就是我們可以嘗試去改變提升的點。

那么我們從這些輸出內容看下，面對上述挑戰，QA 都做了哪些改變以及還有哪些困境。

3.1 項目排期計劃

項目排期計劃模板：

【when】項目排期一般是需求評審完后，根據需求拆分需求模塊和開發模塊。

排期計劃中，QA 的工作：熟悉需求，拆分需求模塊，制定測試計劃

QA 同學加入進模塊拆解，能更好的了解需求，拆分的開發模塊也能更快的知道當有 bug 時，bug 是屬于哪個端的，提給哪位對應的開發。

根據各模塊的提測時間和大致開發周期，QA 同學也能制定對應的測試計劃。

【what】-- QA 具體需要做什么

1.協助開發拆分功能模塊，確保模塊都有對應的開發負責人

2.確認項目 deadline、開發總預計時間和提測時間。

3.2 測試計劃制定

項目測試計劃模板：

【when】測試計劃一般在項目排期給出后 1 天內提供，后續根據排期動態調整。

測試計劃中，QA 的工作：根據需求預估時間和人力，明確測試環境與策略，制定合理的測試計劃，預估風險

【what】-- QA 具體需要做什么

以上 1、2 兩點盡早提供，其余可在對應時間點給出。當然，如遇到需求變更、人力變更等需要及時提出和調整。

【how】-- 具體怎么做

根據開發排期，動態制定和調整合理測試的計劃。

· 根據提測時間，決定用例執行順序與分配：

如下圖拆分的測試計劃，后臺配置（星火）與用戶端提測時間不一致，結合兩個提測時間點，我們利用用戶端提測前的時間，先執行后臺配置的用例，這樣即使是分步提測，我們也能確保每次提測時測試資源能跟上。

· 根據功能制定測試輪次：

對于主干功能：需要多次執行測試用例，一般制定三輪的測試，一輪在測試環境，二輪預發環境，三輪線上環境。

對于對內的、不影響用戶使用的功能：制定一輪測試，在測試環境測一輪。比如星火等配置后臺是給運營使用的，做一輪測試，上預發后產品走查驗證 + 配置內容即可。

活動類的功能：依據活動的復雜程度和使用頻次，制定測試輪次。比如新年活動，是一次性的活動且活動時間緊，評估后我們在預發做了一輪測試就上線了，上線質量也一樣較好。具體測試流程：活動類測試流程嘗試。

· 按照模塊、用例量與難度劃分，制定每人每天用例執行目標

一輪測試模塊劃分根據用例編寫與熟悉度劃分

· 實行交叉測試，避免因不熟悉導致遺漏或效率降低

二輪進測試進行交叉，利用 TC 平臺的任務指派，也可以清楚看到組員的任務數量與完成情況。

如下圖，測試計劃的拆解與人員分配，細致劃分到每人每日的工作目標，且各模塊的分配會進行交叉，一輪測試人員發現用例不完善或測試不方便的地方也提供了文檔以便二輪人員盡快上手測試。

[小結]：

我們可以看到，調整測試計劃的 4 種方式，主要目的都是通過這些辦法去更高效地去完成測試任務，保障項目如期上線；更完善、全面地去發現 bug，提升項目質量。

測試計劃的合理調整分配，是面對項目過程中各種挑戰的有效方式之一。

3.3 jira 定制化流程

jira 版本發布管理：從產品建立版本開始，到最終復盤，整個流程和數據統計都體現在 jira 看板中，方便統一管理。

項目進度自動同步：如下，項目組成員能很清晰地知道當前項目進度，且版本進度每天都會自動在大群同步；完結的項目，也會根據項目情況自動同步復盤信息。

【小結】：

1.定制化的流程，讓流程更加統一規范和智能化。

2.關鍵信息的及時同步，能減少每日站會、信息同步會等重復會議，節約了時間。

各團隊之前的協作更加順暢，那團隊協同效率和人效也就自然而然能進一步提高。

2021Q1 效率工具的需求收集提效討論中，提 bug 流程的優化建議一一實現了，每個人提 bug 的速度大幅提升，主要匯總如下：

bug 區分問題類型 —— 使 bug 分類更精準，能更好地分析數據，push 對應人員

bug 狀態展示優化 —— 各狀態一目了然，更快找到需要處理的 bug

bug 描述預置版本、步驟、設備等信息 —— 減少重復內容輸入，提 bug 效率更高

jira 移動版接入使用 —— 附件內容更方便上傳，bug 描述更準確，減少因無法復現、描述不清等原因帶來的重復溝通成本

bug 流程新增：一輪漏測、fix bug 引入選項、bug 描述不清的狀態 —— 當然這些指標目的不是為了追究是開發或是測試的責任，是為了分析 bug，總結原因，從中找出不足的地方（比如用例設計不完善、開發修復 bug 未自測等問題），大家共同進步，提升項目質量，從而讓項目進行更流暢與高效。

自動提醒開發 QAfix 和驗收 bug：—— 精準找到需要處理 bug，處理效率大大提升

項目流程復盤中，我們約定 p1bug 當天需要 fix，p2bug 原則上 fix 周期不超過 T+1 天，驗收不超過 T+2 天。如下圖，就是根據形成的規范自動提醒研發、測試的內容：

【小結】：

即使是預置的一些提 bug 信息和界面優化，也讓測試更 “優雅” 地工作，提 bug 和驗 bug 也更有勁兒了。

T+1 修復周期的約定與消息推送，給了研發一個心理預期，正如我們根據項目情況調整測試策略一般，研發也根據我們給的預期調整了工作模式，從而使研發 fix bug 周期保障到最短，高效且有質量地修復了 bug。

工作流程的調整與滿滿預期的加持，讓整個團隊的工作效率極大提高。

3.4 測試報告

【when】一般項目提測后，需要每日下班前發送日報

【what】-- QA 具體需要做什么

匯總其他 QA 的進度，根據項目情況發送日報 or 周報。

日報中風險項一環節可根據項目情況修改，同步計劃、提醒事項等都可以寫入。

push 開發 fix bug：p1 修復周期不超過 T+1 天，bug 數量較多時，可根據測試情況適當催開發修改（比如一輪測試接近尾聲，還有很多服務端前端 bug，就需要催一下了）

【how】-- 具體怎么做

在 galaxy 平臺工具上，實現了日報自動生成工具，每日可自動生成日報內容，方便大家看進度，且日報中還有當前 bug 狀態和鏈接，研發也能更快找到自己的 bug。

日報一鍵生成效果如下：

日報的自動生成，節省了測試每日匯總進度的時間，更是直接大幅減少了關鍵信息的溝通同步成本，是人效和團隊協同效率提升的又一次加成 buff。

【when】項目上線后，對項目進行總結梳理

【how】-- 具體怎么做

結合 jira 的使用流程，可一鍵生成測試報告并同步質量平臺。

生成的測試報告示例：

3.5 項目復盤

【when】項目上線后的一周內，小型項目如有必要可合并組織

【why】復盤的目的：針對項目中不足之處，共同討論對策，爭取下次做得更好

【what】-- QA 具體需要做什么

數據文檔準備：形式其實不做限制，需要的數據、文檔等準備好即可，也可以與開發輪流組織。

會議上形成的 todo list 需要進行跟進處理

【how】-- 具體怎么做

復盤例子：

復盤提效 jira 看板：如下圖

（ps：催 bug 或者發日報的時候也可以使用，比較清晰）

【小結】：定期做項目復盤，讓團隊意識到我們當前存在的問題，推進項目流程一次比一次做得更好。

【不足】：

當然，在復盤過程中，各團隊雖然達成一些共識共同改進，也遇到了一系列問題。

問題一：項目節奏已經很緊張的情況下，大家可能都在趕項目進度，沒有余力去做復盤總結工作，追求效率從而忽視了質量。

問題二：復盤形成的 todolist 也沒時間去跟進，導致復盤的總結內容最后不了了之，復盤失去意義。

問題三：一些復盤改進點，往往由于各種特殊原因而不能按規定執行 。

基于以上原因，復盤收獲的效果是比較有限的，也是我們今后需要探討與改進的一個命題。

四、項目風險

4.1 風險評估

項目流程中，我們關注各個階段需要做什么事的同時也會做項目管理與把控，關注項目風險，守住 deadline。

風險可以分為兩類：質量風險和進度風險

舉個例子：

用例編寫的時間不夠，影響測試時間和上線時間，我們稱之為進度風險；而用例編寫時，編寫用例人員不熟該功能，用例覆蓋不足，我們可以稱之為質量風險。

這里我們主要關注的是項目進度，所以著重關注進度風險一項。進度風險，就是在項目進度中出現的風險從而影響了整個項目的時間點。

在測試計中，我們設計了風險一欄放于第一位，目的就是讓 QA 在項目流程中，及時從測試角度去觀測和記錄風險。

比如：

4.2 風險對策

面對風險出現時，需要 case by case 討論。在進度風險出現時，首要原則就是及時暴露風險、尋找方法去盡可能降低風險。

項目組很多項目因與其他部門配合，有固定 deadline 并且允許有部分已知問題帶上線，那么我們一般從測試開發角度去商議的解決辦法如下：

以上方案如果還不能守住 deadline，就要考慮項目延期。

結語

上述內容是作者所在項目組結合已有的測試流程，針對項目遇到的挑戰進行流程推進以及推進后的總結介紹。

鑒于不同項目組的特殊和差異性，文中提到的方法和手段可能只是冰山一角，不一定完全適用各類項目。根據項目情況做前置工作推進項目流程，其實是一個很大的命題，不同項目組有時存在的問題也不盡相同，測試在項目流程中還能做哪些更 nice 的事，還是需要靠大家在現有情況下去進行探索和總結。也歡迎大家留言與評論區留言交流~

福利

為方便大家自學軟件測試，特意給大家準備了一份200G的超實用干貨學習資源，涉及的內容非常全面。關注公眾號【清風酔】自行獲取

主體內容包含：阿里、騰訊、美團、字節跳動等等測試面試題，功能測試、性能測試、自動化測試等學習視頻等知識內容。

人生是一個逆水行舟的過程，不進則退，咱們一起加油吧！

覺得資源不錯就點個贊吧~

責任編輯：Rex_08