作者：京東物流 宋雪薇

1 前言

項目管理是一個繁雜的過程，每個階段需要涉及到不同人員、資源的協(xié)調(diào)配合。每個角色都有自己的定位和任務(wù)，為了緊密配合項目經(jīng)理或無分配項目經(jīng)理運行項目的場景下確保項目成員共同達成項目目標(biāo)，不同的角色掌握相應(yīng)的項目管理意識就尤為重要。

那么，測試角色作為項目交付的質(zhì)量把控者，具備相應(yīng)的項目管理意識在項目的高質(zhì)量、高效率交付目標(biāo)上有著重要作用，如前置識別質(zhì)量風(fēng)險、進度風(fēng)險等。本文旨在梳理、談?wù)摐y試角色在項目各階段如何評估測試范圍及風(fēng)險、前置暴露問題以及推進測試進度等項目管理事項，高效協(xié)作及交付測試角色產(chǎn)物，最終與項目各方共同推進達到高質(zhì)量、高效率交付的目標(biāo)。

2 現(xiàn)狀及思考

在現(xiàn)有敏捷迭代快速交付模式下，針對某一需求/項目會拆分至各個團隊，各個團隊節(jié)奏及交付目標(biāo)不完全一致，且無項目經(jīng)理角色跟蹤推進的情況下，存在后置與協(xié)作團隊溝通確認事項，如：未拉齊依賴方排期、前期未識別出改動系統(tǒng)、需求/設(shè)計變更未及時同步相關(guān)方、無設(shè)計方案溝通導(dǎo)致提測內(nèi)容不滿足提測標(biāo)準(zhǔn)，等均可影響交付節(jié)奏。那么作為測試角色的我們可以做哪些事情？

核心主旨：高效溝通協(xié)作，提前思考后續(xù)階段較容易影響進度、質(zhì)量問題及風(fēng)險點，暴露問題，前置溝通、評估及推進相關(guān)事宜；避免問題后置暴露在測試階段；下一章節(jié)就讓我們來詳談各個階段測試角色可提前關(guān)注事項，與各方高效協(xié)作共同推進解決的相關(guān)tips。

3 詳談測試介入各階段的項目管理tips

3.1 需求評審階段

軟件測試的第一步就是需求評審，只有對軟件需求做了準(zhǔn)確、完整的評審后，才能對接下來各種測試工作的開展做好基礎(chǔ)，如需求評審理解偏差，后期很多測試任務(wù)都將會受到影響。

需求評審?fù)瓿尚枇私饽男┬畔ⅲ?/h4>

1. 優(yōu)先級——識別項目/需求重點程度，優(yōu)先級，以及期望上線時間情況（定位后續(xù)跟進力度）
2. 需求背景——該需求基于什么業(yè)務(wù)背景改造（便于需求理解不偏差及后續(xù)測試階段重點關(guān)注的核心目標(biāo)）
3. 改動范圍——評審改動范圍基于現(xiàn)有系統(tǒng)是否有沖突、是否明確合理，是否影響其他系統(tǒng)，也可關(guān)注下體驗問題（避免后續(xù)開發(fā)測試階段流程不通返工）
4. 識別改動/交互系統(tǒng)——明確該需求是否涉及其他系統(tǒng)改動，識別改動系統(tǒng)/是否需配合聯(lián)調(diào)系統(tǒng)（識別改動系統(tǒng)前置協(xié)調(diào)拉齊相關(guān)系統(tǒng)周期，避免后續(xù)階段臨時協(xié)調(diào)資源情況）
5. 測試節(jié)點——軟件需要進行哪些方面的測試，如功能測試、聯(lián)調(diào)測試、回歸測試、性能測試、穩(wěn)定性測試、兼容性測試、安全測試等
6. 測試環(huán)境——明確交互系統(tǒng)是否支持測試環(huán)境聯(lián)調(diào)（可前置協(xié)調(diào)/前置確定聯(lián)調(diào)方案，避免后置溝通確定環(huán)境占用測試周期）
7. 測試數(shù)據(jù)——根據(jù)改動范圍思考測試數(shù)據(jù)來源，識別是否可內(nèi)部閉環(huán)造數(shù)，是否可使用測試小工具
8. 測試方式——可前置思考使用功能測試、自動化測試
9. 測試人員——識別測試干系人、明確主測試方（如重點項目/需求需要主測試情況）

3.2 設(shè)計評審階段

設(shè)計評審為評價設(shè)計滿足質(zhì)量要求的能力，識別問題及提出解決辦法。設(shè)計過程中越早增加質(zhì)量保證活動對最終設(shè)計效果的影響就越明顯。目前較大項目/邏輯較復(fù)雜需求/研發(fā)優(yōu)化，均需研發(fā)輸出設(shè)計評審文檔并邀請測試參與涉及評審。

設(shè)計評審時需要check的內(nèi)容：

1. 設(shè)計思路滿足需求——結(jié)合需求背景及內(nèi)容優(yōu)先關(guān)注設(shè)計思路是否與需求評審階段理解的有偏差
2. 設(shè)計內(nèi)容是否存在遺漏——評估是否存在遺漏功能
3. 關(guān)注實現(xiàn)方式——實時、異步等處理方式對后續(xù)測試排期、方式及測試難度有參考價值
4. 評估改動設(shè)計影響——基于原有系統(tǒng)改動除本次需求修改內(nèi)容是否影響原有功能，是需明確影響范圍，研發(fā)側(cè)輸出影響范圍
5. 明確階段范圍——根據(jù)需求是否存在拆解階段交付，是需明確各階段交付內(nèi)容
6. 交互方/依賴方實現(xiàn)方式——關(guān)注交互方/依賴方實現(xiàn)方式
7. UAT/灰度/上線方案——根據(jù)上線特性，前置溝通UAT/灰度/上線方案

3.3 排期階段

排期階段是項目管理中重要的一環(huán)，時常在此階段會暴露一些風(fēng)險，排期容易出現(xiàn)兩個問題，一是排期不合理，二是后續(xù)不能按照排期穩(wěn)步推進，好的排期就要盡量避免這兩個問題，那么測試階段合理的排期就需盡可能多的參考該節(jié)點及之前節(jié)點項目各方提供的有效信息，全局評估、拆分任務(wù)交付，最終提供較合理排期。

輸出測試排期需要考慮的維度：

1. 參考項目重點程度、優(yōu)先級——是否優(yōu)先級與已排期需求沖突，需參考優(yōu)先級調(diào)整資源及排期
2. 結(jié)合需求、設(shè)計參考及核對研發(fā)工時及排期、階段交付內(nèi)容——研發(fā)提供拆解后的任務(wù)排期是否合理（前置功能是否提前交付，依賴的任務(wù)是否有序等），測試依據(jù)研發(fā)排期時間提供可并行/串行等較合理的測試排期
3. 關(guān)注研發(fā)是否有聯(lián)調(diào)排期——需保障提測質(zhì)量，時間緊任務(wù)重情況下是否壓縮研發(fā)聯(lián)調(diào)排期，可能影響提測質(zhì)量及測試交付時間
4. 測試聯(lián)調(diào)排期——測試輸出聯(lián)調(diào)周期需拉齊對接系統(tǒng)排期（可協(xié)同產(chǎn)品溝通拉齊），避免臨時協(xié)調(diào)聯(lián)調(diào)時間導(dǎo)致延期
5. APP排期——需確認實現(xiàn)方式為：原生/flutter
6. 明確方案是否存在變更——可再次明確需求/設(shè)計方案是否存在變更未同步情況
7. 明確主測試方——如涉及多方系統(tǒng)，排期階段可明確主產(chǎn)品、主研發(fā)、主測試方

3.4 測試用例編寫、評審階段

測試用例的編寫必須依據(jù)需求文檔，結(jié)合設(shè)計方案，確認所有以疑問點，覆蓋所有功能需求點，跟進需求情況輸出冒煙測試用例、功能測試用例、聯(lián)調(diào)測試用例，思考業(yè)務(wù)實操場景，模擬用戶場景串聯(lián)流程保障測試內(nèi)容的高覆蓋。并在用例評審節(jié)點邀請產(chǎn)研參與評審，有序進行用例評審，確認疑問共同完善測試點并會后輸出評審會議紀(jì)要。

測試用例編寫、評審階段需要注意的事項：

1. 確認需求文檔版本及標(biāo)準(zhǔn)——明確最新PRD版本（存在產(chǎn)研線下溝通后未同步測試情況，盡量避免），如有原型需明確原型及PRD內(nèi)容描述不一致情況下如何開展測試工作
2. 思考細節(jié)邏輯合理性及歧義描述——思考細節(jié)邏輯描述是否合理，PRD描述存在歧義點需標(biāo)注明確
3. 包含充分的異常測試用例——豐富異常用例，避免異常情況下功能異常
4. 識別用戶體驗問題——提示信息是否明確、頁面功能是否易用
5. 業(yè)務(wù)范圍和系統(tǒng)設(shè)計維度補全用例——跟進需求及設(shè)計細化測試維度豐富測試用例
6. 測試數(shù)據(jù)、賬號、配置等——識別測試數(shù)據(jù)、賬號及配置是否需協(xié)同方配合，是否可使用工具等提升效率，如需全流程連通在該階段記錄
7. 測試用例評審——與產(chǎn)研側(cè)確認測試范圍、溝通疑問，評審用例設(shè)計的清晰度與合理性，優(yōu)先級排定是否合理，是否覆蓋了需求上所有測試點，用例是否具有很好的可執(zhí)行性，用例的冗余處理機制，是否設(shè)計了充足的異常測試用例，是否從用戶的角度出發(fā)來設(shè)計用戶使用場景和使用流程的測試用例，是否簡潔、復(fù)用性強。
8. 聯(lián)調(diào)用例評審——輸出交互場景與交互方評審，如為主測試，評審前串聯(lián)整個項目/需求的流程場景用例，組織評審、明確測試數(shù)據(jù)、賬號、配置等信息
9. 用例評審會議紀(jì)要——記錄待確認點及已確認點

3.5 編碼階段

編碼階段作為研發(fā)角色活動，通過編碼過程來實現(xiàn)產(chǎn)品需求，此階段的異常等需相關(guān)方知悉；

研發(fā)階段需同步的信息：

1. 需求/方案變更——是否存在需求/方案變更，是否及時同步至產(chǎn)品、測試側(cè)
2. 是否有提測延期風(fēng)險——存在延期風(fēng)險會壓縮后續(xù)測試周期，需前置識別并拋出

3.6 代碼評審階段

代碼評審是研發(fā)全流程的工程實踐之一，通過代碼評審可以更好的保障產(chǎn)品質(zhì)量和代碼質(zhì)量；可根據(jù)改動大小與研發(fā)側(cè)溝通進行線上/線下等評審方式參與。

代碼評審階段需檢驗的標(biāo)準(zhǔn)：

1. 慢sql、空指針等——可有意識評審慢sql、空指針等問題
2. 業(yè)務(wù)邏輯——測試人員需關(guān)注是否有明顯的邏輯錯誤，改動是否遵循業(yè)務(wù)邏輯
3. 補全回歸用例——跟進改動范圍可識別需改動影響原有功能部分，特別注意需確保主流程是否影響，補充回歸用例
4. 文檔——提供新接口/修改接口是否有相應(yīng)的接口文檔更新維護
5. 需求沖突識別——關(guān)注改動范圍，識別其他需求是否也存在改動該段代碼問題，避免需求沖突
6. 提高個人代碼評審能力——學(xué)習(xí)研發(fā)針對代碼評審的意見/建議以及好的代碼實現(xiàn)邏輯，便于問題更早的發(fā)現(xiàn)（以及代碼編寫規(guī)范、可讀性、可維護性等）

3.7 冒煙測試階段

冒煙測試是指在對一個新版本進行系統(tǒng)大規(guī)模的測試之前，先驗證一下軟件的基本功能是否實現(xiàn)，是否具備可測性，盡早發(fā)現(xiàn)較阻塞進度問題，提前識別。

冒煙測試階段重點關(guān)注的維度：

1. 基本功能驗證——優(yōu)先驗證基本功能是否可用，便于后續(xù)邏輯等較復(fù)雜功能開展
2. 主流程驗證——優(yōu)先識別主流程問題，避免流程阻塞，阻礙測試進度，提前暴露流程問題及風(fēng)險（方式依據(jù)項目/需求情況有效采取手工/自動化方式進行）

3.8 功能測試階段（內(nèi)部測試階段）

功能測試階段開始了大規(guī)模的測試工作，在此期間仔細詳盡的測試，

功能測試階段核心把控的思想：

1. 明確變更同步——針對測試階段任何變更需同步至相關(guān)方，避免一方不知情
2. 識別需求沖突——共同測試需求，測試分支、需求相互影響
3. 測試數(shù)據(jù)高效使用——分析測試數(shù)據(jù)是否可驗證多用例，高效使用測試數(shù)據(jù)驗證盡可能多用例提升效率
4. 測試問題務(wù)必拋出——測試階段發(fā)現(xiàn)的問題即使較小也需要拋出來提供給相關(guān)確認方確認，如無需更改則記錄相關(guān)結(jié)論
5. 探索性測試——探索性測試，可在測試階段發(fā)現(xiàn)前期未識別到的影響功能等
6. 測試進度報告、風(fēng)險拋出——針對時間較長/較大需求、項目發(fā)送測試進度報告，暴露風(fēng)險（識別是否有影響進度、質(zhì)量等風(fēng)險問題，拋出問題，記錄待確認問題及已溝通確認問題

3.9 聯(lián)調(diào)測試階段（包含研發(fā)聯(lián)調(diào)、測試聯(lián)調(diào)）

聯(lián)調(diào)測試為了保障該需求/項目的所有改動場景下發(fā)的數(shù)據(jù)在全鏈路系統(tǒng)下正常流轉(zhuǎn)閉環(huán)，覆蓋用戶真實實操場景來確保項目/需求的交付質(zhì)量。

聯(lián)調(diào)測試階段注重：

1. 研發(fā)聯(lián)調(diào)環(huán)節(jié)——再次核對涉及系統(tǒng)交互需求/項目，研發(fā)聯(lián)調(diào)工作是否覆蓋主流程測試點
2. 聯(lián)調(diào)場景驗證——與全鏈路系統(tǒng)進行聯(lián)調(diào)測試驗證，覆蓋用戶真實實操場景
3. 補全聯(lián)調(diào)場景——在聯(lián)調(diào)階段，可能存在場景覆蓋不全情況，可有選擇性了解上下游系統(tǒng)邏輯，可覆蓋補全聯(lián)調(diào)場景，且針對接口及消息盡量全的確保數(shù)據(jù)傳輸場景

3.10 穩(wěn)定性測試（適用于APP）

為保障APP端用戶體驗，APP穩(wěn)定性測試不可或缺，上線前針對上線版本進行穩(wěn)定性測試已加入到APP測試流程中，日常針對APP穩(wěn)定性隨機測試也持續(xù)監(jiān)控。

穩(wěn)定性測試需監(jiān)控：

1. 崩潰率——監(jiān)控阿凡達平臺統(tǒng)計，分析APP線上崩潰原因，豐富穩(wěn)定性測試腳本
2. CPU實時監(jiān)控——記錄穩(wěn)定性測試期間對應(yīng)版本的CPU占用數(shù)據(jù)，平均值、最大值
3. 內(nèi)存實時監(jiān)控——記錄穩(wěn)定性測試期間對應(yīng)版本內(nèi)存占用數(shù)據(jù)，平均值、最大值
4. 網(wǎng)絡(luò)實時監(jiān)控——記錄穩(wěn)定性測試期間對應(yīng)版本流量占用數(shù)據(jù)，平均值、最大值

3.11 UAT階段

UAT階段主要為業(yè)務(wù)驗收階段，用戶角色驗收產(chǎn)研測交付內(nèi)容，為確保UAT順利進行，較大項目/需求測試人員有針對性進行主流程拉通測試可提前發(fā)現(xiàn)配置、環(huán)境因素所產(chǎn)生的問題，此環(huán)節(jié)可加快UAT進度確保項目更高效交付（該階段可根據(jù)項目訴求調(diào)整）。

UAT階段應(yīng)保障：

1. 拉通主流程——根據(jù)項目/需求大小確定是否需拉通UAT，避免UAT因配置/環(huán)境等原因產(chǎn)生流程阻塞
2. 跟進/復(fù)盤UAT問題——針對較大項目/需求跟進及復(fù)盤UAT中產(chǎn)生的問題，規(guī)避重復(fù)問題產(chǎn)生事項

3.12 上線前master回歸測試階段

上線前master回歸未確保長時間需求不上線分支及版本沖突等因素，上線當(dāng)前進行master回歸操作可有效確保發(fā)布內(nèi)容運行穩(wěn)定，保障質(zhì)量。

master回歸階段需check：

1. master回歸測試——回歸上線功能主流程以及原有流程主流程，規(guī)避測試分支與上線分支代碼沖突等問題

4 暴露風(fēng)險最終與協(xié)作方共同確定運作策略

在項目各環(huán)節(jié)已前置思考可能帶來的風(fēng)險，提前規(guī)避、提前暴露，但并不能完全保障，那么在暴露風(fēng)險后，可參考風(fēng)險程度分析與分類定位，與項目各方高效協(xié)作，共同商榷解除風(fēng)險的可行性方案以及后續(xù)運行策略。

4.1 風(fēng)險程度分析

• 極?。簺]有危害或微小危害 20%
• 輕度：輕度危害 40%
• 中度：中等 60%
• 重度：較大危害 80%
• 極大：重度危害 100%

4.2 風(fēng)險識別分類/分解結(jié)構(gòu)

• 技術(shù)類：明確是否為需求/技術(shù)層面引起的風(fēng)險
• 組織類：明確是否為項目依賴關(guān)系、資源等原因引起的風(fēng)險
• 外部：明確外部影響具體原因

4.3 與協(xié)作方共同商榷風(fēng)險推進方案

測試人員可根據(jù)測試角度定位風(fēng)險優(yōu)先級，優(yōu)先解決風(fēng)險程度較高問題，且優(yōu)先級較高風(fēng)險需同步至上級知悉，必要時可采取升級等方式處理；

1. 如為技術(shù)類風(fēng)險——與項目經(jīng)理、產(chǎn)品、研發(fā)共同評估技術(shù)層面解除方案；
2. 如為組織類風(fēng)險——與項目經(jīng)理、產(chǎn)品、研發(fā)共同協(xié)同調(diào)整計劃/申請資源等方式處理；
3. 如為外部風(fēng)險——測試人員需提供具體問題，協(xié)同項目經(jīng)理、產(chǎn)品溝通具體原因，采取相對應(yīng)的應(yīng)對措施；

4.4 舉例說明

4.4.1 舉例一

背景：管理工作臺項目（優(yōu)先級top1，交付時間緊，開發(fā)工作量大）產(chǎn)生問題：因測試周期時間緊，為避免延期提測，測試在研發(fā)階段明確提測時間時，發(fā)現(xiàn)提測存在延期風(fēng)險

• 風(fēng)險程度分析及分類：組織類-重度風(fēng)險
  （識別階段：研發(fā)階段，識別及反饋角色：測試人員，類型：進度類）
• 與協(xié)作方商榷推進方案（解決過程及方案）：
  因項目優(yōu)先級較高，測試人員將此風(fēng)險反饋至主產(chǎn)品及產(chǎn)品負責(zé)人處，因各方前期了解的信息存在差異化/關(guān)注點不一致等，線下拉齊會議溝通，根據(jù)交付優(yōu)先級拆解交付內(nèi)容，迭代提測進行測試，最終拉齊前、后端研發(fā)、測試交付目標(biāo)一致，并調(diào)配資源進行各項任務(wù)交付，風(fēng)險解除。

小結(jié)：依據(jù)風(fēng)險程度，可內(nèi)部解除的快速推進落地，需耗時較長/協(xié)調(diào)資源等需及時反饋至上級溝通，確保風(fēng)險盡快解除落地。

5 總結(jié)

前置評估、高效協(xié)作

保障在前置階段通過測試經(jīng)驗總結(jié)提前思考后續(xù)階段會帶來的影響，包含但不僅限于：信息不同步、影響范圍不明確、依賴關(guān)系不清晰等，前置有意識的識別較容易影響進度、質(zhì)量問題及風(fēng)險點，并暴露問題，繼而與相關(guān)協(xié)作方高效協(xié)作、評估及推進風(fēng)險點解除，避免問題后置暴露在測試階段甚至交付上線階段。