本文主旨是想沉淀一下如何寫測試計劃。但是經過了一段時間翻閱資料，我發現網上大部分測試計劃模板的內容多而雜，基本都是適用于傳統項目的。剛好研究了一段時間如何給敏捷項目做測試計劃，同時也在公司內成功進行了推廣，把我目前所學所想沉淀下來。
敏捷項目的測試計劃，首先要知道，什么是敏捷項目和敏捷測試？
敏捷項目
相對于傳統項目少則三五個月，多則一年兩年，最近幾年火起來的敏捷項目，讓團隊成果產出的速度更快了起來。傳統項目往往功能體系較為完整、龐大的系統，具備較為完善的文檔，較為固定的流程，通常通過設立里程碑來標記一個階段的完結。敏捷項目相對于傳統項目更加靈活，周期短（一星期/半個月/一個月），更加注重高迭代、響應變化。
敏捷項目的特點：需求變化快、項目周期短。
敏捷測試
在敏捷項目的大前提下，我們可以知道，在短周期內要做極致詳盡的測試計劃（大家可以百度一下傳統項目的測試計劃模板）幾乎是不可能的。所以敏捷測試相對于傳統項目的測試，測試計劃、測試用例等流程和內容上會有不同程度的簡化。大家更注重與團隊溝通，注重于高效產出。測試人員則是更實際的從需求階段就參與到整個項目，在需求產出 到 發布上線 的階段中，持續不斷的對產品質量做出反饋。
測試人員對質量的反饋，貫穿整個項目周期。
寫測試計劃
什么是測試計劃
測試計劃是指導測試過程的綱領性文件。是為了達成一定時期內的目標，進行的任務規劃和行動步驟設計。
為什么要做測試計劃
當你身處一個項目中，請你嘗試回答以下幾個問題：
- 本項目的發布主題是什么？重要需求是哪些？
- 你有多少測試工時，能否在預期時間內保質完成測試任務？
- 項目內各測試人員的工作是否飽和， 分工是否均衡？
- 分工是否明確，是否有工作重復或遺漏？
- 是否有外部依賴？如何獲取外部依賴的進度？
- 可能出現什么風險？有什么準備？
- 什么時候可以進行產品驗收？
- 最終成果的測試質量標準是哪些？
我認為，一切能讓你回答出這些問題的準備，都可以稱之為“做測試計劃”。
之前我經常見到這種情況：
- 發布時間是確定的，但測試完結時間就是發布時間，根本不知道質量過不過關。導致大家發布前匆匆忙忙測試，發布后匆匆忙忙處理線上故障；
- 發布的時候質量是否可靠，大家都不知道；
- 我們的新功能需要依賴外部團隊的一個新接口，但新接口什么時候給出來？給不出來我們就一直等等等;
- 兩個人一起參與測試，前期測試A忙忙忙，后期測試B忙忙忙，忙不忙的看運氣;
- 開發前期提測功能少，快發布了，批量提測，導致測試忙不過來...
也有人抱怨：
需求安排下來，開發人員說能做完就排進來了，可測不完怎么辦？
想讓開發分批提測，讓后期測試壓力小一點，可是開發有自己的節奏怎么辦？
針對以上問題，我只想說，我們要盡早分析我們可能遇到的問題，才能盡早的實施解決方案。而寫測試計劃的過程，就是一個分析我們可能遇到問題的最有效、最全面的方式。做完完整的測試計劃，上面的問題都有了答案，你的所有抱怨，都可以有真憑實據。
什么時候做完測試計劃
接上面的話，盡早分析我們可能遇到的問題，才能盡早的實施解決方案，所以，當你知道要進行測試的那一刻起，你的所有關注，都可能形成測試計劃的一部分。因為測試計劃文檔，一定是要有一定的積累和設計后，才能形成一份完善的文檔。
與此同時，測試計劃受產品的需求、開發的設計、測試的分析、項目的周期、外部影響這幾方面的影響，應該是一個初稿+不斷完善的過程。隨著項目推進，不斷完善計劃，收集反饋，如此往復。
所以我的項目中，我們的測試人員會在planning（計劃會議，即大家在一起確認需求的開發和測試工時）結束后，開始寫測試用例之前，完成測試計劃初稿的撰寫，讓測試計劃能夠作用與之后的每一個階段 ——有人會說，敏捷測試不是從需求開始，測試就在參與了嗎，為什么測試準備階段測試計劃才開始生效？是的，需求階段測試的參與，是在于對產品的理解，從測試的角度提出產品設計上的問題，這個階段在敏捷測試中，可以歸結與敏捷的測試體系和公司/團隊文化，不需要在測試計劃中單獨體現。言歸正傳，在測試準備階段之前完成的是測試計劃的初稿，這個初稿中，允許有未確定的事項存在，正如上面所說，我們的測試計劃是個初稿+不斷完善的過程，在后面的每一個階段，我們都可以繼續完善或者變更初稿中的內容。這個現象跟敏捷宣言中的“響應變化”有異曲同工的感覺。
我們期望測試計劃能帶來什么？
假設我們已經有了一份詳細的測試計劃，
* 領導看到了你的測試計劃，能夠根據測試計劃了解項目資源，進行宏觀調控、相應資源配置等
* 測試人員：能夠了解整個項目測試情況以及項目測試不同階段的所要進行的工作等
* 其他人員：了解測試人員的工作內容，能夠知道在這個周期中，需要何時給你提供協助，進行有關配合工作
測試計劃的內容
其實就是項目中需要參與測試的人員搞清楚的幾個基礎項。通過確立這些基礎項，我們就能最大程度的剖析出我們的測試項目，有效克服測試的盲目性。
我們要做的就是把下面這些內容，整理為測試計劃的要素。
- 明確測試資源
- 明確時間節點
- 明確需求內容
- 明確測試內容/測試范圍
- 明確了開發的設計并討論過測試方案
- 明確關鍵需求的策略
- 明確需要的協助
- 明確可預估的風險，并有相應的應對策略
- 明確時間估算和消耗
- 明確測試任務分配
- 明確輸出內容
- 明確質量要求
經過我一段時間的資料分析和總結，我覺得在敏捷項目中，能包含以下幾點的測試計劃，基本已經完備了測試計劃的所有要素。
即 項目背景、測試資源、測試內容及安排、測試策略、風險預估、關鍵時間節點、預期質量目標。
敏捷項目的測試計劃要素
如何讓測試計劃更有執行力
主要有兩方面，一方面是撰寫測試計劃的tester，一方面是文檔內容。
對于撰寫者，首先要充分了解當前團隊成員的特定，因為人員也是一個風險，例如，我一般會重點關注質量不佳的開發小伙伴的提測時間。另外，撰寫者需要充分了解當前團隊的研發活動，了解我們要經歷幾個測試階段，換幾套測試環境，什么時候是一輪測試的節點，什么時候該要求開發人員全部提測完畢，以此來安排測試活動的時間。
對于文檔內容，也是要求撰寫者「計劃」「如何」「去做」。請一定要認真研究這3個詞，每個詞都能讓你的測試計劃文檔更飽滿，更有意義。測試計劃報告的平臺可以開發，模板可以提供給你，但是測試計劃的內容到底有沒有用，就要真的要用心去做安排。
我對我的測試計劃有3個要求：
1、范圍清晰。要明確測試資源、測試范圍、時間節點
2、策略合理。利用合理的策略，節約測試成本、強化測試效果
3、風險控制。盡量挖掘測試過程中可能遇到的風險，早發現早預防
風險預估
提到風險評估，大家會覺得這個詞并不陌生，但如果真正要對一個項目做風險評估，很多人會覺得無從下手，因為我們要考慮的是還未發生的事情。
如果不知道從何下手，不妨先試試把各式各樣的風險分個類（如下表）。然后按照時間線，來想一想在項目的不同階段，我們可能會遇到哪些問題。
上面講了如何識別和發現風險，接下來談談，應對風險的4種方法。
風險預估模板
測試策略
有些人搞不清楚測試策略和測試計劃有啥不一樣。
簡單來講，測試計劃主要目標是包含所有關于測試的信息，比如為什么測、測什么、什么時候測、怎么測、誰來測等。
測試策略詳細描述了QA使用什么樣的具體測試方法來達成測試目標，給測試流程和活動設置了標準，主要關注測什么和怎么測。
由此可見，測試計劃涵蓋的內容遠遠多于測試策略，并且包含了測試策略。
首先看一下，如何判斷一個需求需要做測試策略，可以根據下面的3個原則進行思考：
1、除了手工測試，我可以通過別的什么手段，可以更快更好的保障質量？
2、在完成目標的前提下，是否可以通過一定的手段節約測試成本（如減少些測試時間、釋放些測試人力）；
3、不是所有需求都需要寫測試策略，實在沒有，常規測試方法就是保障質量的基礎手段。
測試策略舉例
關于測試計劃評審
現在的項目，往往會議比較多，產品需求要評審、設計要評審、測試分析要評審、測試用例要評審... 那測試計劃要不要評審？答案是，需要，但又不全需要。
我們比較認同的評審方式可以分為兩種：
常規迭代 （大部分需求是團隊內）這種迭代項目的測試計劃，因為人員穩定、測試階段穩定，大部分迭代的測試計劃內容都是通用的，只重點分析測試策略和風險即可，這時候，只要保障測試人員了解開發的設計和重點難點，能夠針對性的產出較為規范的測試策略，就沒有什么太大的問題，這種迭代往往是可以不用大范圍組織評審的，只要確保信息互通，確保你的測試策略是對應的開發認可的，就足夠了。
而對于較為重大的迭代，有多個團隊參與，涉及外部交互的，這種迭代是一定一定要組織測試計劃評審的，要把你的測試計劃同步給其他團隊，也能同時至少其他團隊的測試安排，這樣更有利于大家達成質量共識，也更容易在測試時間和測試階段上保持一致，以防后期大家進度不一致，互相掣肘，影響整體進度。
測試計劃評審，是測試人員對于測試工作的一個公開，接受每個角色對于我們測試工作安排的檢驗，不要因為麻煩就不做，因為重要項目的測試計劃不做評審，后期可能面臨更大的麻煩，還是那句話，行動一定要趁早趁早趁早！
測試計劃發給誰
1、直接參與者：項目經理、開發人員、產品經理、測試人員以及其他與需求有關的參與者
2、間接參與者：外部需求或對外需求的對接人員
3、需要誰協助：測試策略中寫明的需要外部協助時的參與人員
4、其他關注者：你的領導等關注項目概況以及測試資源的人
最后想說的話
近期面試了一些測試人員，當我問TA如何把控項目進度的時候，大部分人都會回答，按照測試計劃、或者按照測試組長分配給我的任務進行執行。但我問測試計劃或者組長任務怎么安排出來的，大部分人回答不出個所以然，其中不乏有工作了5、6年的被試者。當你不能把控好原來你自己的項目，我如何相信你能把控好我的項目呢？當我們在一個敏捷項目中的時候，因為產品變化太快了，我們往往需要更精細的測試計劃才能讓我們的節奏不打亂，方向不會偏航，所以我希望我們測試人員，都能夠具備這種把控項目的能力。你可以不做，但希望你會做。
【原創文章，轉發請注明來源！】
