文/秋之川
這是《落葉》文集里第 336 片落葉，希望你能喜歡，不為別的，只為這份堅持。
第十九章 單獨制定測試策略的意義在哪里？
昨天，老大就怎么制定測試策略，發(fā)給我兩篇文章學習，見附錄。學完之后，我產(chǎn)生了一個疑惑：測試策略常見的場景是用于應對那些“一定會”或“可能會”發(fā)生的風險，那單獨制定測試策略的意義在哪里呢？為什么不能將測試策略和風險管理合在一起去做呢？
我將我的疑惑發(fā)給了老大，很快，他就回復了我。
風險管理
管理的是項目風險，項目風險是一種不確定的事件或條件，一旦發(fā)生，就會對一個或多個項目目標造成積極或消極的影響，比如范圍、進度、成本和質(zhì)量。
面向的對象：
- 已知的風險
- 未知的風險
產(chǎn)出：
- 應對方案
- 應急儲備
測試策略
是在一定的軟件測試標準、測試規(guī)范的指導下，依據(jù)測試項目的特定環(huán)境約束而規(guī)定的軟件測試的原則、方式和方法的集合。
面向的對象：
- 測試階段
- 功能性測試需求
- 非功能性的測試需求，性能測試需求、安全測試需求
- 測試項目風險
- 測試項目問題
產(chǎn)出：
- 針對不同測試需求和測試目標所采用的測試技術策略
- 針對風險的測試策略
- 針對測試資源（人力、設備和時間）約束的測試策略
- 針對不同測試階段的測試策略
略做對比，我們不難看出，測試風險管理是測試策略的一種輸入，或者說是它面向的眾多對象中的其中之一。
為什么我們不能只做風險管理，因為它所應對的僅僅是項目中的風險。而測試策略可以在項目開始之初，根據(jù)必要的輸入信息，來做如下決策：
- 是否要在單元測試階段執(zhí)行每日代碼評審
- 是否可以利用自動化測試來保證功能性的回歸測試
- 是否要在代碼提測的里程碑前幾天就開始運行每日 BVT
- 是否要同步開發(fā)接口自動化測試腳本去保證后端接口的參數(shù)完整性和邏輯正確性
- 是否要對測試用例進行評級，在測試時間被壓縮的時候，確保第一優(yōu)先級的用例都能被執(zhí)行
- 是否要讓資深測試工程師只負責測試點梳理、測試用例的設計和驗收測試，而讓初級工程師聚焦于測試用例的執(zhí)行和回歸測試
- 是同時開始所有需求的測試，還是按提測先后或者需求優(yōu)先級，逐步釋放相應的測試資源
- 性能測試中的調(diào)優(yōu)分析是否需要開發(fā)介入?yún)f(xié)助
所以，單獨做測試策略，能讓你站在一個俯瞰全局的高度，去思考整個測試項目過程中，通過自問自答一些問題，讓自己逐漸地掌控整個測試項目過程，對每一步都做到心中有數(shù)和應對有方。：
- 我們需要做些什么？
- 我們是否需要這么做？
- 我們應該做些什么？
- 我們應該怎么做？
- 怎么做性價比最高？
說完這些，老大讓我回去嘗試著思考一下這次的測試策略。
附錄：
《告訴你如何從執(zhí)行測試到管理測試》帶你邁出第（19）步！，點擊這里可查看完整地圖
作者簡介：14 年測試 + 11 年項目管理 + 11 年團隊管理 = 一個測試老兵
