01、什么是測試策略
簡單來說，測試策略主要關注兩個問題：
測什么：測什么是指質量需求是什么、需要關注質量的哪些方面，比如應用的功能范圍、性能、安全、易用性等非功能需求。
怎么測：怎么測就是采用什么辦法來幫助系統實現質量需求，而不僅僅是手動和自動化的測試方法，也包括一切為質量保障服務的流程、環境、基礎設施和人員等。
設計測試策略的目標是“減少缺陷的出現和發布”。其中“減少缺陷的出現”可以通過測試前移等方法來解決，在進行軟件需求分析和架構設計的時候發現缺陷；而“減少缺陷發布”可以使用各種測試方法、技術來驗證和測試編碼完成的功能。
02、傳統測試活動中的測試策略設計
在傳統的測試活動中，測試策略一般會在項目目標明確后開始設計。整個測試策略會包含但不僅限于以下幾個方面：
測試的對象和范圍是什么（測試什么東西，哪些不需要測試）
測試目標是什么（為了讓產品完全符合商業化的標準，還是小范圍適用等）
測試的重點和難點有哪些（測試難點在哪里，需要什么樣的支持）
如何安排各類測試活動（先測試什么再測試什么，什么時候集成測試等）
資源投入情況（測試時長、人員配置、環境等）
類似的文檔結構如下：
03、它為什么會被逐漸忽略
看了上面的介紹，你大概也能猜到測試策略為什么會被逐漸忽略了，個人的看法如下：
1. 沒有時間
在敏捷研發的大環境下，每個迭代相對于傳統版本的測試時間更少了迭代測試是什么意思，我們沒有時間去寫這么重的文檔了，而且它看起來與敏捷的理念相反。
2. 測試內容明確
在一個迭代周期內，通過需求實例化，每個迭代測試的內容更清晰且聚焦了，那么原來的很多內容都不再需要了。如下所示：
測試的對象和范圍是什么（測試什么東西，哪些不需要測試）
測試目標是什么（為了讓產品完全符合商業化的標準，還是小范圍適用等）
測試的重點和難點有哪些（測試難點在哪里，需要什么樣的支持）
如何安排各類測試活動（先測試什么再測試什么迭代測試是什么意思，什么時候集成測試等）
資源投入情況（測試時長、人員配置、環境等）
3. 測試慣性作用
與傳統的測試不同，敏捷測試是一直在持續地進行，持續的反饋。所以不需要像傳統的測試那樣在項目初期去初始化一個環境（會一直存在），不需要關心測試時長（每個迭代相對固定），對于各類測試活動也變得不再敏感（本質上是一直在做集成測試）。所以由于敏捷測試的連貫性，測試策略中的部分內容也不再需要關注了，如下所示：
測試的對象和范圍是什么（測試什么東西，哪些不需要測試）
測試目標是什么（為了讓產品完全符合商業化的標準，還是小范圍適用等）
測試的重點和難點有哪些（測試難點在哪里，需要什么樣的支持）
如何安排各類測試活動（先測試什么再測試什么，什么時候集成測試等）
資源投入情況（測試時長、人員配置、環境等）
所以，還剩下什么呢？個人認為，剩下的東西，才是測試策略最核心的東西：測試難點在哪里？如何識別出來并給出解決方案。
04、敏捷測試中是否需要測試策略
先給結論，還是要有的。但不并不是每個迭代都需要，在一些核心特性的迭代中，在一些基礎能力構建的迭代中，還是需要停下來，好好思考一下如何開展更有效的測試方法，我們需要提前為這個迭代的測試活動做些什么。同時，這份測試策略不宜太長，一頁內最好，要保證團隊所有成員能夠隨時看到這份策略并得到團隊的整體認可。
個人的經驗小結如下，（希望得到更多的建議）
1. 目標導向：本次迭代的內容是否完全推向用戶？用戶在哪些場景下會使用到這些功能？客戶最關心的指標是什么？可用性，還是穩定性？這些需要在迭代計劃會開始前，溝通并確認清楚。除了卡片上的顯式需求，是否有些隱式的需求，如合規、安全、性能、可靠性等等。
2. 識別風險：測試過程中可能出現的風險有哪些？在需求端，風險主要來自于需求的優先級調整，團隊對需求的理解是否到位。在研發設計階段，風險有常見的幾種：研發是否引入了新技術？前后端的人員是否能配合到位？是否有外部依賴？對老功能的影響會有哪些等等。測試團隊自身的風險，常見的有人員的變更、測試能力不足等。
如何應對這些風險呢？常見的思路有4種：回避風險、轉移風險、減輕風險以及接受風險。具體的就不展開了，需要結合項目和團隊的具體情況來說，減輕風險是最常見的方案。
3. 測試難點：當前迭代或者項目的測試難點在哪里，是否需要前置準備一些關聯數據？是否需要自己搭建一個項目來驗證（筆者所帶的團隊經常需要測試一些底層的項目，比如SDK，比如網關組件，比如一些數據統計類的項目等等）？當測試團隊遇到問題時，如何幫助他們解決這類問題。