本文主旨是想沉淀一下如何寫測試計劃。但是經(jīng)過了一段時間翻閱資料讥邻，我發(fā)現(xiàn)網(wǎng)上大部分測試計劃模板的內容多而雜，基本都是適用于傳統(tǒng)項目的。剛好研究了一段時間如何給敏捷項目做測試計劃邦尊，同時也在公司內成功進行了推廣，把我目前所學所想沉淀下來优烧。
敏捷項目的測試計劃蝉揍，首先要知道，什么是敏捷項目和敏捷測試畦娄？
敏捷項目
相對于傳統(tǒng)項目少則三五個月又沾，多則一年兩年，最近幾年火起來的敏捷項目纷责，讓團隊成果產出的速度更快了起來捍掺。傳統(tǒng)項目往往功能體系較為完整、龐大的系統(tǒng)再膳，具備較為完善的文檔挺勿，較為固定的流程，通常通過設立里程碑來標記一個階段的完結喂柒。敏捷項目相對于傳統(tǒng)項目更加靈活不瓶，周期短（一星期/半個月/一個月），更加注重高迭代灾杰、響應變化蚊丐。
敏捷項目的特點：需求變化快、項目周期短艳吠。
敏捷測試
在敏捷項目的大前提下麦备，我們可以知道，在短周期內要做極致詳盡的測試計劃（大家可以百度一下傳統(tǒng)項目的測試計劃模板）幾乎是不可能的。所以敏捷測試相對于傳統(tǒng)項目的測試凛篙，測試計劃黍匾、測試用例等流程和內容上會有不同程度的簡化。大家更注重與團隊溝通呛梆，注重于高效產出锐涯。測試人員則是更實際的從需求階段就參與到整個項目，在需求產出 到 發(fā)布上線 的階段中填物，持續(xù)不斷的對產品質量做出反饋纹腌。
測試人員對質量的反饋，貫穿整個項目周期滞磺。
寫測試計劃
什么是測試計劃
測試計劃是指導測試過程的綱領性文件升薯。是為了達成一定時期內的目標，進行的任務規(guī)劃和行動步驟設計雁刷。
為什么要做測試計劃
當你身處一個項目中覆劈，請你嘗試回答以下幾個問題：
- 本項目的發(fā)布主題是什么？重要需求是哪些沛励？
- 你有多少測試工時责语，能否在預期時間內保質完成測試任務？
- 項目內各測試人員的工作是否飽和目派， 分工是否均衡坤候？
- 分工是否明確，是否有工作重復或遺漏企蹭？
- 是否有外部依賴白筹？如何獲取外部依賴的進度？
- 可能出現(xiàn)什么風險谅摄？有什么準備徒河？
- 什么時候可以進行產品驗收？
- 最終成果的測試質量標準是哪些送漠？
我認為顽照，一切能讓你回答出這些問題的準備，都可以稱之為“做測試計劃”闽寡。
之前我經(jīng)常見到這種情況：
- 發(fā)布時間是確定的代兵，但測試完結時間就是發(fā)布時間，根本不知道質量過不過關爷狈。導致大家發(fā)布前匆匆忙忙測試植影，發(fā)布后匆匆忙忙處理線上故障；
- 發(fā)布的時候質量是否可靠涎永，大家都不知道思币；
- 我們的新功能需要依賴外部團隊的一個新接口鹿响，但新接口什么時候給出來？給不出來我們就一直等等等;
- 兩個人一起參與測試支救，前期測試A忙忙忙抢野，后期測試B忙忙忙，忙不忙的看運氣;
- 開發(fā)前期提測功能少各墨，快發(fā)布了，批量提測启涯，導致測試忙不過來...
也有人抱怨：
需求安排下來贬堵，開發(fā)人員說能做完就排進來了，可測不完怎么辦结洼？
想讓開發(fā)分批提測黎做，讓后期測試壓力小一點，可是開發(fā)有自己的節(jié)奏怎么辦松忍？
針對以上問題蒸殿，我只想說，我們要盡早分析我們可能遇到的問題鸣峭，才能盡早的實施解決方案宏所。而寫測試計劃的過程，就是一個分析我們可能遇到問題的最有效摊溶、最全面的方式爬骤。做完完整的測試計劃，上面的問題都有了答案莫换，你的所有抱怨霞玄，都可以有真憑實據(jù)。
什么時候做完測試計劃
接上面的話拉岁，盡早分析我們可能遇到的問題坷剧，才能盡早的實施解決方案，所以喊暖，當你知道要進行測試的那一刻起惫企，你的所有關注，都可能形成測試計劃的一部分哄啄。因為測試計劃文檔雅任，一定是要有一定的積累和設計后，才能形成一份完善的文檔咨跌。
與此同時沪么，測試計劃受產品的需求、開發(fā)的設計锌半、測試的分析禽车、項目的周期寇漫、外部影響這幾方面的影響，應該是一個初稿+不斷完善的過程殉摔。隨著項目推進州胳，不斷完善計劃，收集反饋逸月，如此往復栓撞。
所以我的項目中，我們的測試人員會在planning（計劃會議碗硬，即大家在一起確認需求的開發(fā)和測試工時）結束后瓤湘，開始寫測試用例之前，完成測試計劃初稿的撰寫恩尾，讓測試計劃能夠作用與之后的每一個階段 ——有人會說弛说，敏捷測試不是從需求開始，測試就在參與了嗎翰意，為什么測試準備階段測試計劃才開始生效木人？是的，需求階段測試的參與冀偶，是在于對產品的理解醒第，從測試的角度提出產品設計上的問題，這個階段在敏捷測試中蔫磨，可以歸結與敏捷的測試體系和公司/團隊文化淘讥，不需要在測試計劃中單獨體現(xiàn)。言歸正傳堤如，在測試準備階段之前完成的是測試計劃的初稿蒲列，這個初稿中，允許有未確定的事項存在搀罢，正如上面所說蝗岖，我們的測試計劃是個初稿+不斷完善的過程，在后面的每一個階段榔至，我們都可以繼續(xù)完善或者變更初稿中的內容抵赢。這個現(xiàn)象跟敏捷宣言中的“響應變化”有異曲同工的感覺。
我們期望測試計劃能帶來什么唧取？
假設我們已經(jīng)有了一份詳細的測試計劃铅鲤，
* 領導看到了你的測試計劃，能夠根據(jù)測試計劃了解項目資源枫弟，進行宏觀調控邢享、相應資源配置等
* 測試人員：能夠了解整個項目測試情況以及項目測試不同階段的所要進行的工作等
* 其他人員：了解測試人員的工作內容，能夠知道在這個周期中淡诗，需要何時給你提供協(xié)助骇塘，進行有關配合工作
測試計劃的內容
其實就是項目中需要參與測試的人員搞清楚的幾個基礎項伊履。通過確立這些基礎項，我們就能最大程度的剖析出我們的測試項目款违，有效克服測試的盲目性唐瀑。
我們要做的就是把下面這些內容，整理為測試計劃的要素插爹。
- 明確測試資源
- 明確時間節(jié)點
- 明確需求內容
- 明確測試內容/測試范圍
- 明確了開發(fā)的設計并討論過測試方案
- 明確關鍵需求的策略
- 明確需要的協(xié)助
- 明確可預估的風險哄辣，并有相應的應對策略
- 明確時間估算和消耗
- 明確測試任務分配
- 明確輸出內容
- 明確質量要求
經(jīng)過我一段時間的資料分析和總結，我覺得在敏捷項目中赠尾，能包含以下幾點的測試計劃柔滔，基本已經(jīng)完備了測試計劃的所有要素。
即 項目背景萍虽、測試資源、測試內容及安排形真、測試策略杉编、風險預估、關鍵時間節(jié)點咆霜、預期質量目標邓馒。
敏捷項目的測試計劃要素
如何讓測試計劃更有執(zhí)行力
主要有兩方面，一方面是撰寫測試計劃的tester蛾坯，一方面是文檔內容光酣。
對于撰寫者，首先要充分了解當前團隊成員的特定脉课，因為人員也是一個風險救军，例如，我一般會重點關注質量不佳的開發(fā)小伙伴的提測時間倘零。另外唱遭，撰寫者需要充分了解當前團隊的研發(fā)活動，了解我們要經(jīng)歷幾個測試階段呈驶，換幾套測試環(huán)境拷泽，什么時候是一輪測試的節(jié)點，什么時候該要求開發(fā)人員全部提測完畢袖瞻，以此來安排測試活動的時間司致。
對于文檔內容，也是要求撰寫者「計劃」「如何」「去做」聋迎。請一定要認真研究這3個詞脂矫，每個詞都能讓你的測試計劃文檔更飽滿，更有意義砌庄。測試計劃報告的平臺可以開發(fā)羹唠，模板可以提供給你奕枢，但是測試計劃的內容到底有沒有用，就要真的要用心去做安排佩微。
我對我的測試計劃有3個要求：
1缝彬、范圍清晰。要明確測試資源哺眯、測試范圍谷浅、時間節(jié)點
2、策略合理奶卓。利用合理的策略一疯，節(jié)約測試成本、強化測試效果
3夺姑、風險控制墩邀。盡量挖掘測試過程中可能遇到的風險，早發(fā)現(xiàn)早預防
風險預估
提到風險評估盏浙，大家會覺得這個詞并不陌生眉睹，但如果真正要對一個項目做風險評估，很多人會覺得無從下手废膘，因為我們要考慮的是還未發(fā)生的事情竹海。
如果不知道從何下手，不妨先試試把各式各樣的風險分個類（如下表）斋配。然后按照時間線，來想一想在項目的不同階段菩鲜，我們可能會遇到哪些問題园细。
上面講了如何識別和發(fā)現(xiàn)風險，接下來談談接校，應對風險的4種方法猛频。
風險預估模板
測試策略
有些人搞不清楚測試策略和測試計劃有啥不一樣。
簡單來講蛛勉，測試計劃主要目標是包含所有關于測試的信息鹿寻，比如為什么測、測什么诽凌、什么時候測侣诵、怎么測痢法、誰來測等狱窘。
測試策略詳細描述了QA使用什么樣的具體測試方法來達成測試目標，給測試流程和活動設置了標準财搁，主要關注測什么和怎么測蘸炸。
由此可見，測試計劃涵蓋的內容遠遠多于測試策略提茁，并且包含了測試策略淹禾。
首先看一下，如何判斷一個需求需要做測試策略茴扁，可以根據(jù)下面的3個原則進行思考：
1铃岔、除了手工測試，我可以通過別的什么手段峭火，可以更快更好的保障質量德撬？
2、在完成目標的前提下躲胳，是否可以通過一定的手段節(jié)約測試成本（如減少些測試時間、釋放些測試人力）纤勒；
3坯苹、不是所有需求都需要寫測試策略，實在沒有摇天，常規(guī)測試方法就是保障質量的基礎手段粹湃。
測試策略舉例
關于測試計劃評審
現(xiàn)在的項目，往往會議比較多泉坐，產品需求要評審为鳄、設計要評審、測試分析要評審腕让、測試用例要評審... 那測試計劃要不要評審孤钦？答案是，需要纯丸，但又不全需要偏形。
我們比較認同的評審方式可以分為兩種：
常規(guī)迭代 （大部分需求是團隊內）這種迭代項目的測試計劃，因為人員穩(wěn)定觉鼻、測試階段穩(wěn)定俊扭，大部分迭代的測試計劃內容都是通用的，只重點分析測試策略和風險即可坠陈，這時候萨惑，只要保障測試人員了解開發(fā)的設計和重點難點捐康，能夠針對性的產出較為規(guī)范的測試策略，就沒有什么太大的問題庸蔼，這種迭代往往是可以不用大范圍組織評審的解总，只要確保信息互通，確保你的測試策略是對應的開發(fā)認可的朱嘴，就足夠了倾鲫。
而對于較為重大的迭代，有多個團隊參與萍嬉，涉及外部交互的恳谎，這種迭代是一定一定要組織測試計劃評審的，要把你的測試計劃同步給其他團隊粟矿，也能同時至少其他團隊的測試安排示弓，這樣更有利于大家達成質量共識，也更容易在測試時間和測試階段上保持一致行冰，以防后期大家進度不一致溺蕉，互相掣肘，影響整體進度悼做。
測試計劃評審疯特，是測試人員對于測試工作的一個公開，接受每個角色對于我們測試工作安排的檢驗肛走，不要因為麻煩就不做漓雅，因為重要項目的測試計劃不做評審，后期可能面臨更大的麻煩朽色，還是那句話邻吞，行動一定要趁早趁早趁早！
測試計劃發(fā)給誰
1葫男、直接參與者：項目經(jīng)理抱冷、開發(fā)人員、產品經(jīng)理梢褐、測試人員以及其他與需求有關的參與者
2旺遮、間接參與者：外部需求或對外需求的對接人員
3、需要誰協(xié)助：測試策略中寫明的需要外部協(xié)助時的參與人員
4盈咳、其他關注者：你的領導等關注項目概況以及測試資源的人
最后想說的話
近期面試了一些測試人員趣效，當我問TA如何把控項目進度的時候，大部分人都會回答猪贪，按照測試計劃跷敬、或者按照測試組長分配給我的任務進行執(zhí)行。但我問測試計劃或者組長任務怎么安排出來的，大部分人回答不出個所以然西傀，其中不乏有工作了5斤寇、6年的被試者。當你不能把控好原來你自己的項目拥褂，我如何相信你能把控好我的項目呢娘锁？當我們在一個敏捷項目中的時候，因為產品變化太快了饺鹃，我們往往需要更精細的測試計劃才能讓我們的節(jié)奏不打亂莫秆，方向不會偏航，所以我希望我們測試人員悔详，都能夠具備這種把控項目的能力镊屎。你可以不做，但希望你會做茄螃。
【原創(chuàng)文章缝驳，轉發(fā)請注明來源！】
