在早期的軟件工程實踐中，軟件測試計劃的制定通常是在需求分析以及測試需求分析完成後開始，並且是整個軟件研發生命周期中的重要環節。

但是，在敏捷開發模式下，你可能會有這樣的疑問，軟件測試計劃還有那麽重要嗎？我所在的軟件項目壓根兒就沒有正式的測試計劃，不也沒出什麽大問題嗎？

的確，對於很多非產品型的互聯網公司，由於采用了敏捷開發模式，的確很少去制定傳統意義上的測試計劃了，但這並不是說它們就不再制定測試計劃了。

只不過是，測試計劃的表現形式已經不再是傳統意義上龐大的、正式的測試計劃文檔了，而更多的是體現在每個叠代（sprint）的計劃環節，而且這樣的短期測試計劃可以非常迅速地根據項目情況實時調整。

所以說，測試計劃依舊存在，只是從原來的一次性集中制定測試計劃，變成了以叠代的方式持續制定測試計劃。 但是對於傳統軟件企業，或者是做非互聯網軟件產品的企業，它們通常還是會有非常正式的軟件測試計劃。

由此可見，無論對於早期最具典型性的瀑布開發模型，還是現在的敏捷開發模型，測試計劃的重要性始終沒有發生變化。那麽，你可能會問，測試計劃的重要性到底體現在哪些方面呢？在回答這個問題之前，我先跟你聊聊如果沒有測試計劃會帶來什麽問題。

沒有測試計劃會怎麽樣？
如果沒有測試計劃，會帶來哪些問題呢？

很難確切地知道具體的測試範圍，以及應該采取的具體測試策略；

很難預估具體的工作量和所需要的測試工程師數量，同時還會造成各個測試工程師的分工不明確，引發某些測試工作被重復執行而有些測試則被遺漏的問題；

測試的整體進度完全不可控，甚至很難確切知道目前測試的完成情況，對於測試完成時間就更難預估準確的時間節點了；

整個項目對潛在風險的抵抗能力很弱，很難應對需求的變更以及其他突發事件。

從這些問題中，你可以逆向思維推導出，一份好的測試計劃要包括：測試範圍、測試策略、測試資源、測試進度和測試風險預估，這五大方面，並且每一部分都要給出應對可能出現問題的解決辦法。

測試範圍
顧名思義，測試範圍描述的是被測對象以及主要的測試內容。

比如，對於用戶登錄模塊，功能測試既需要測試瀏覽器端又需要測試移動端，同時還考慮登錄的安全和並發性能相關的非功能性需求的測試等。

測試範圍的確定通常是在測試需求分析完成後進行，所以確定測試範圍的過程在一定程度上也是對測試需求分析的進一步檢驗，這將有助於在早期階段就發現潛在的測試遺漏。

同時，由於不可能進行窮盡測試，而且測試的時間和資源都是有限的，所以必須有所取舍，進行有針對性的測試。因此，測試範圍中需要明確“測什麽”和“不測什麽”。

測試策略的話題
測試策略簡單來講就是需要明確“先測什麽後測什麽”和“如何來測”這兩個問題。

病有輕重緩急，測試也是一樣的道理，重要的項先測，而不重要的項要後測。測試策略會要求我們明確測試的重點，以及各項測試的先後順序。

比如，對用戶登錄模塊來講，“用戶無法正常登錄”和“用戶無法重置密碼”這兩個潛在問題，對業務的影響孰輕孰重一目了然，所以，你應該按照優先級來先測“用戶正常登錄”，再測“用戶重置密碼”。

測試策略還需要說明，采用什麽樣的測試類型和測試方法。 這裏需要註意的是，不僅要給出為什麽要選用這個測試類型，還要詳細說明具體的實施方法。

第一，功能測試

對於功能測試，你應該根據測試需求分析的思維導圖來設計測試用例。

主線業務的功能測試由於經常需要執行回歸測試，所以你需要考慮實施自動化測試，並且根據項目技術棧和測試團隊成員的習慣與能力來選擇合適的自動化測試框架。

這裏需要註意的是，你通常應該先實現主幹業務流程的測試自動化。

實際操作時，你通常需要先列出主要的功能測試點，並決定哪些測試點適合采用自動化測試，並且決定具體使用什麽樣的框架和技術。

對於需要手工測試的測試點，你要決定采用什麽類型的測試用例設計方法，以及如何準備相關的測試數據。

另外，你還要評估被測軟件的可測試性，如果有可測試性的問題，需要提前考慮切實可行的變通方案，甚至要求開發人員提供可測試性的接口。

第二，兼容性測試

對於兼容性測試來說，Web 測試需要確定覆蓋的瀏覽器類型和版本，移動設備測試需要確定覆蓋的設備類型和具體 iOS/Android 的版本等。

你可能會問，我要怎麽確定需要覆蓋的移動設備類型以及 iOS/Android 的版本列表呢？這個問題其實並不難：

如果是既有產品，你可以通過大數據技術分析產品的歷史數據得出 Top 30% 的移動設備以及 iOS/Android 的版本列表，那麽兼容性測試只需覆蓋這部分即可。
如果是一個全新的產品，你可以通過 TalkingData 這樣的網站來查看目前主流的移動設備，分辨率大小、iOS/Android 版本等信息來確定測試範圍。
兼容性測試的實施，往往是在功能測試的後期，也就是說需要等功能基本都穩定了，才會開始兼容性測試。

當然也有特例，比如，對於前端引入了新的前端框架或者組件庫，往往就會先在前期做兼容性評估，以確保不會引入後期無法解決的兼容性問題。

兼容性測試用例的選取，往往來自於已經實現的自動化測試用例。道理很簡單，因為兼容性測試往往要覆蓋最常用的業務場景，而這些最常用的業務場景通常也是首批實現自動化測試的目標。

所以，我們的 GUI 自動化框架，就需要能夠支持同一套測試腳本在不做修改的前提下，運行於不同的瀏覽器。

第三，性能測試

對於性能測試，需要在明確了性能需求（並發用戶數、響應時間、事務吞吐量等）的前提下，結合被測系統的特點，設計性能測試場景並確定性能測試框架。

比如，是直接在 API 級別發起壓力測試，還是必須模擬終端用戶行為進行基於協議的壓力測試。再比如，是基於模塊進行壓力測試，還是發起全鏈路壓測。

如果性能是背景數據敏感的場景，還需要確定背景數據量級與分布，並決定產生背景數據的技術方案，比如是通過 API 並發調用來產生測試數據，還是直接在數據庫上做批量 insert 和 update 操作，或者是兩種方式的結合。

最後，無論采用哪種方式，都需要明確待開發的單用戶腳本的數量，以便後續能夠順利組裝壓測測試場景。

性能測試的實施，是一個比較復雜的問題。首先，需要根據你想要解決的問題，確定性能測試的類型；然後，根據具體的性能測試類型開展測試。

性能測試的實施，往往先要根據業務場景來決定需要開發哪些單用戶腳本，腳本的開發會涉及到很多性能測試腳本特有的概念，比如思考時間、集合點、動態關聯等等。

腳本開發完成後，你還要以腳本為單位組織測試場景（Scenario），場景定義簡單來說就是百分之多少的用戶在做登錄、百分之多少的用戶在做查詢、每個用戶的操作步驟之間需要等待多少時間、並發用戶的增速是 5 秒一個，還是 5 秒 2 個等等。

最後，才是具體的測試場景執行。和自動化功能測試不同，性能測試執行完成後性能測試報告的解讀，是整個測試過程中最關鍵的點。

如果你現在不太清楚我上面提到的一些概念也沒關系，我會在後續的文章中為你詳細講解。

除了我給你詳細分析的、最常用的功能測試、兼容性測試和性能測試外，還有很多測試類型（比如，接口測試、集成測試、安全測試、容量驗證、安裝測試、故障恢復測試等）。這些測試類型，都有各自的應用場景，也相應有獨特的測試方法，在這裏我就不再一一展開了，如果你有關於這些測試類型的問題，可以給我留言討論。

測試資源
測試資源通常包括測試人員和測試環境，這兩類資源都是有限的。測試計劃的目的就是，保證在有限資源下的產出最大化。所以，測試資源就是需要明確“誰來測”和“在哪裏測”這兩個問題。

測試人員是最重要的，直接關系到整個測試項目的成敗和效率。測試人員的資源通常有兩個維度：一是，測試工程師的數量；二是，測試工程師的個人經驗和能力。

你會發現，測試工程師的經驗和能力不足，很難通過測試人員的數量來彌補。相反地，測試工程師的經驗和能力都非常強的情況下，測試人員的數量可以適當地減少。

通常在測試團隊中，測試工程師既有資深，也會有初級，那麽你就必須針對團隊的實際情況去安排測試計劃。比如，難度較大的工作，或者一些新工具、新方法的應用，又或者自動化測試開發工作，通常由資深的測試工程師來承擔；而那些相對機械性、難度較小的工作，則由初級工程師完成。

可見，你要想規劃好測試資源，除了要了解項目本身外，還必須對測試團隊的人員特點有清晰的把控。另外，我強烈建議你把具體的任務清晰地落實到每個人的身上，這將有利於建立清晰的責任機制，避免後續可能發生的扯皮。

相對於測試人員，測試環境就比較好理解了。不同的項目，可能會使用共享的測試環境，也可能使用專用的測試環境，甚至還會直接使用生產環境。另外，對於目前一些已經實現容器化部署與發布的項目，測試環境就會變得更簡單與輕量級，這部分內容我會在後續的文章中給你詳細講解。

測試進度
在明確了測試範圍、測試策略和測試資源之後，你就要考慮具體的測試進度了。測試進度主要描述各類測試的開始時間，所需工作量，預計完成時間，並以此為依據來建議最終產品的上線發布時間。

比如，版本接受測試（Build Acceptance Test）的工作量，冒煙測試（Smoke Test）的工作量，自動化腳本開發的工作量，缺陷修復的驗證工作量，需要幾輪回歸測試、每一輪回歸測試的工作量等等。

在傳統瀑布模型中，測試進度完全依賴於開發完成並遞交測試版本的時間。如果開發提交測試版本發生了延誤，那麽在不裁剪測試需求的情況下，產品整體的上線時間就同樣會延期。

然而在敏捷模式下，測試活動貫穿於整個開發過程，很多測試工作會和開發工作同步進行，比如采用行為驅動開發（Behavior-Driven Development）模式，這樣測試進度就不會完全依賴於開發遞交可測試版本的時間。

行為驅動開發，就是平時我們經常說的 BDD，指的是可以通過自然語言書寫非程序員可讀的測試用例，並通過 StepDef 來關聯基於自然語言的步驟描述和具體的業務操作，最典型的框架就是知名“Cucumber”。

測試風險預估
俗話說，計劃趕不上變化，對於測試也是一樣的道理，很少有整個測試過程是完全按照原本測試計劃執行的。通常需求變更、開發延期、發現重大缺陷和人員變動是引入項目測試風險的主要原因。

對於需求變更，比如增加需求、刪減需求、修改需求等，一定要重新進行測試需求分析，確定變更後的測試範圍和資源評估，並與項目經理和產品經理及時溝通因此引起的測試進度變化。測試經理 / 測試負責人切忌不能有自己咬牙扛過去的想法，否則無論是對測試團隊還是對產品本身都不會有任何好處。

另外，隨著測試的開展，你可能會發現前期對於測試工作量的預估不夠準確，也可能發現需要增加更多的測試類型，也可能發現因為要修改測試架構的嚴重缺陷而導致很多的測試需要全回歸，還有可能出現開發遞交測試版本延期，或者人員變動等各種情況。

所以，在制定測試計劃時，你就要預估整個測試過程中可能存在的潛在風險，以及當這些風險發生時的應對策略。 那麽，在真的遇到類似問題時，你才可以做到心中不慌，有條不紊地應對這些挑戰。

總結
軟件測試同軟件項目一樣，也要制定詳細的測試計劃。雖然在敏捷開發模式下，軟件測試不再局限於厚重的、正式的計劃文檔，但是測試計劃的重要性絲毫沒有發生變化。

一份成功的測試計劃，必須清楚地描述：測試範圍、測試策略、測試資源、測試進度和測試風險預估這五個最重要的方面。

測試範圍需要明確“測什麽”和“不測什麽”；測試策略需要明確“先測什麽後測什麽”和“如何來測”；測試資源需要明確“誰來測”和“在哪裏測”；測試進度是需要明確各類測試的開始時間，所需工作量和預計完成時間；測試風險預估是需要明確如何有效應對各種潛在的變化。

如何才能做好測試計劃-----打卡第八天