博主：CKL的思考空間     https://mp.weixin.qq.com/s/jOitgxhSRKnQiBpDqeXbwg    

你有多久沒聽過測試策略這個詞了？它就像個走失的小孩，慢慢迷失在快速迭代的敏捷潮流中。曾何幾時，測試策略是測試活動的重要一環，它指導著整個測試活動的開展，是高階測試人員必備的技能。今天，我們來聊聊這個被逐漸忽略的測試技能。

01

什麼是測試策略

維基百科上有一大段關於測試策略的定義，這裡就不貼出來了，簡單來說，測試策略主要關注兩個問題：

測什麼： 測什麼是指質量需求是什麼、需要關注質量的哪些方面，比如應用的功能範圍、效能、安全、易用性等非功能需求。
怎麼測： 怎麼測就是採用什麼辦法來幫助系統實現質量需求，而不僅僅是手動和自動化的測試方法，也包括一切為質量保障服務的流程、環境、基礎設施和人員等。

設計測試策略的目標是“減少缺陷的出現和釋出”。其中“減少缺陷的出現”可以通過測試前移等方法來解決，在進行軟體需求分析和架構設計的時候發現缺陷；而“減少缺陷釋出”可以使用各種測試方法、技術來驗證和測試編碼完成的功能。

02

傳統測試活動中的測試策略設計

在傳統的測試活動中，測試策略一般會在專案目標明確後開始設計。整個測試策略會包含但不僅限於以下幾個方面：

   測試的物件和範圍是什麼（測試什麼東西，哪些不需要測試）

    測試目標是什麼（為了讓產品完全符合商業化的標準，還是小範圍適用等）

    測試的重點和難點有哪些（測試難點在哪裡，需要什麼樣的支援）

    如何安排各類測試活動（先測試什麼再測試什麼，什麼時候整合測試等）

    資源投入情況（測試時長、人員配置、環境等）

類似的文件結構如下：

03

它為什麼會被逐漸忽略

看了上面的介紹，你大概也能猜到測試策略為什麼會被逐漸忽略了，個人的看法如下：

1. 沒有時間

在敏捷研發的大環境下，每個迭代相對於傳統版本的測試時間更少了，我們沒有時間去寫這麼重的文件了，而且它看起來與敏捷的理念相反。

2. 測試內容明確

在一個迭代週期內，通過需求例項化，每個迭代測試的內容更清晰且聚焦了，那麼原來的很多內容都不再需要了。如下所示：

   測試的物件和範圍是什麼（測試什麼東西，哪些不需要測試）

    測試目標是什麼（為了讓產品完全符合商業化的標準，還是小範圍適用等）

    測試的重點和難點有哪些（測試難點在哪裡，需要什麼樣的支援）

    如何安排各類測試活動（先測試什麼再測試什麼，什麼時候整合測試等）

    資源投入情況（測試時長、人員配置、環境等）

3. 測試慣性作用

與傳統的測試不同，敏捷測試是一直在持續地進行，持續的反饋。所以不需要像傳統的測試那樣在專案初期去初始化一個環境（會一直存在），不需要關心測試時長（每個迭代相對固定），對於各類測試活動也變得不再敏感（本質上是一直在做整合測試）。所以由於敏捷測試的連貫性，測試策略中的部分內容也不再需要關注了，如下所示：

   測試的物件和範圍是什麼（測試什麼東西，哪些不需要測試）

    測試目標是什麼（為了讓產品完全符合商業化的標準，還是小範圍適用等）

    測試的重點和難點有哪些（測試難點在哪裡，需要什麼樣的支援）

    如何安排各類測試活動（先測試什麼再測試什麼，什麼時候整合測試等）

    資源投入情況（測試時長、人員配置、環境等）

所以，還剩下什麼呢？個人認為，剩下的東西，才是測試策略最核心的東西：測試難點在哪裡？如何識別出來並給出解決方案。

04

敏捷測試中是否需要測試策略

先給結論，還是要有的。但不併不是每個迭代都需要，在一些核心特性的迭代中，在一些基礎能力構建的迭代中，還是需要停下來，好好思考一下如何開展更有效的測試方法，我們需要提前為這個迭代的測試活動做些什麼。同時，這份測試策略不宜太長，一頁內最好，要保證團隊所有成員能夠隨時看到這份策略並得到團隊的整體認可。

個人的經驗小結如下，（希望得到更多的建議）

1. 目標導向：本次迭代的內容是否完全推向使用者？使用者在哪些場景下會使用到這些功能？客戶最關心的指標是什麼？可用性，還是穩定性？這些需要在迭代計劃會開始前，溝通並確認清楚。除了卡片上的顯式需求，是否有些隱式的需求，如合規、安全、效能、可靠性等等。

2. 識別風險：測試過程中可能出現的風險有哪些？在需求端，風險主要來自於需求的優先順序調整，團隊對需求的理解是否到位。在研發設計階段，風險有常見的幾種：研發是否引入了新技術？前後端的人員是否能配合到位？是否有外部依賴？對老功能的影響會有哪些等等。測試團隊自身的風險，常見的有人員的變更、測試能力不足等。

如何應對這些風險呢？常見的思路有4種：迴避風險、轉移風險、減輕風險以及接受風險。具體的就不展開了，需要結合專案和團隊的具體情況來說，減輕風險是最常見的方案。

3. 測試難點：當前迭代或者專案的測試難點在哪裡，是否需要前置準備一些關聯資料？是否需要自己搭建一個專案來驗證（筆者所帶的團隊經常需要測試一些底層的專案，比如SDK，比如閘道器元件，比如一些資料統計類的專案等等）？當測試團隊遇到問題時，如何幫助他們解決這類問題。

05

具體案例分享

在閘道器專案的某個迭代中，測試人員找到我，希望我能夠協助他們完成迭代的測試策略制定，因為他們在瞭解需求的過程中發現了部分業務的測試難點，沒有具體的測試思路（底層應用的測試相對於業務層的測試，更加考驗測試人員的能力）。經過和專案組及測試人員溝通後，形成了一份如下的測試策略：

基於這份測試策略，在迭代的測試過程中，就可以相對有信心的開展測試活動，而不是在測試過程中遇到問題了，再想辦法處理。

06

小結

三思而後行，在敏捷的環境中，我們雖然不再需要一份大而全的測試策略文件，但是在迭代開始前，還是要好好思考一下如何開展更有效的測試方法，我們需要提前為這個迭代的測試活動做些什麼，它將指導我們更好的開展測試活動。而不是接到測試任務就開始測試，等遇到問題後，才開始想著如何處理。