快速完成和读懂测试计划
?
每個項目測試計劃都會不一樣，但是一般情況下，每個公司都會有相應的模板，尤其是項目很頻繁的公司，相對應的模板應該就更全面，并且更容易修改，更能適應新項目。
?
并且，經常接觸測試計劃的人可能會察覺到，實際上很多測試的計劃都大同小意，里面有很多相似的模塊，像是說明，缺陷管理，項目通過標準，暫停標準，恢復標準，風險管理，等等，都是可以直接套用的，并且這其中有過多的官方的術語，就是一種套話，客套話，很多文字是為了使文章更好去讀，讀起來更舒服，充當的是綠葉的角色。
?
但是基本上說包含核心的內容都是根據不同的項目量身定做的，比如具體要測試特性，測試的milestone，schedule等等，這些是測試人員的測試的依據，時間安排的標準，是絕對馬虎不得的，這也是測試計劃的精髓所在。
?
所以總的來說測試計劃可以宏觀的認為包含兩個部分，一個是具體項目的測試安排，日程安排，人員分工，任務分工，里程碑的成果物等等，另一個是，適用于很多項目的一些約定俗成的標準，管理的方案，風險、缺陷的管理等等，這些不必隨著項目的變化而更改，只要有一份模板，針對不同的項目進行簡單的更改就可以了。
?
其實這種寫測試計劃的方法也可以減少你的時間，更高效更有速度的閱讀測試計劃，因為當你拿到手中的是20幾頁的測試計劃時，如果你選擇從頭一點一點的看，那真的很佩服你，如果是你的母語還好，文檔若是一種外語，對自己來說很鬧心，對公司來說也很浪費成本呀。一旦你清楚了測試計劃中的竅門，你完全可一跳過那些標準，直接找到最核心的安排，分工，這樣可以為您省去很多時間，也可以為公司創造更大的價值。
?
如果您不是第一次接觸測試計劃，想必對這些會有一些感覺，對于讀測試計劃而言，知道這些是不夠的，而需要的是去剖析一篇測試計劃，一旦將其中的各個模塊都弄懂了，在以后的閱讀中就會是飛速了，不管閱讀那個公司的，因為他們的本質是一樣的，就有點像只要你掌握了一門編程語言，在去學其他的語言，也就是幾個小時的事了。
?
所以，理論講到這里開篇也開到這里，接下來，我們就以隨便的一篇文檔進行剖析，最后可能會給各位一些網上普遍的測試模板，可以作為練習，自己閱讀一下，是否可以快速閱讀。
?
我的這篇文檔并非母語，所以各位要有準備，我們先從目錄入手，簡單預覽一下：
Test plan
1,introduction
2,test items
3,features to be tested
4,feature not to be tested
5,approach
6,item pass/fail criteria
7,suspension criteria and resumption requirement
8,test deliverables
9,testing task and schedule
10,environmental needs
11,staffing
12risks management
13,approvals
看起來有點多，不過仔細分析一下，里面需要寫項只有1，3，4，8，9，10，11這幾項，并且每一項需要寫的東西都不多，其他的模塊基本上都是綠葉啦！
在這些需要寫的模塊中，有些還只是更改部分就行了，并且，在有些項目中，其中的有些東西都可以省略，但是要看具體公司的規定，有些公司測試計劃是越多越好呀，顯得嚴謹周密，結果讓寫的人鬧心，看得人也不舒心呀！
第1項中，有三項需要更改：
product summary(產品目錄)，主要就是列出一些項目的功能特性，包含哪些模塊，哪些軟件，對與比較大的系統列出來，更有利于后面的分析，但是小的系統就沒什么必要了。
references(參考文獻)，這個就比較隨意了，一般都會列出不同參與者的一些資料
product milestore candidates(里程碑)，這個是比較重要的，但是在后期也會出現，這里就是一個概覽，一般都用表格的方式。
第3項，是核心的東西，一般的就用這項來代替需求分析了，可能額外沒有具體的需求分析文檔，所以閱讀時這是最重要的，和需求是統一等級的，所以在編寫的時候也不僅僅測試經理自己寫，可能更多的回去參考開發的需求，或者開發文檔中的一些特性項目，這個應該不需要原創太多，主要是需求分析人員已經做好的東西搬過來了。
第4項相對前面，就會好理解很多，主要由于一些硬性條件沒法滿足，無法進行測試的東西做一些說明。
第8項，可以和里程碑相對應起來，但是又沒有里程碑那么重要，就是在測試過程的小階段說產生的成果物提前進行的一個預計，主要就是為了把一個很大的目標（一個一年或半年的項目順利完成），拆分成一個月的成果檢驗（里程碑），然后再拆分兩周的小任務，可以指導你短期的工作，但是，這個也會根據時間做適當的相應的調整的。
第9項，這里主要的就是將里程碑進行完善和優化，要能夠具體看了就知道怎么實施的文檔。還有就是日程的安排，要對時間把握，另外有寫時候會額外加一個文檔schedule，專門就是做時間方面的計劃的。
第10項是，環境要求，這個就比較容易了，有什么寫什么。
第11項也是比較重要核心的東西，但是，有寫的很詳細，有些寫的很寬松；對于大的項目，這個就會寫的很簡略，因為周期半年的項目沒辦法一下子把人員的任務都安排好呀，只能標記上需要哪些團隊，都負責什么樣的任務。具體的在根據具體的情況進行人員的分配。但是有些時候，對于項目比較小，可能就幾周，人員也不多的時候，就需要將具體的分工分配下去，我當時分工分的很細，所以當時這個花費我很多時間去寫，對后期的影響也很大，正因為這個任務分配的仔細，后期人執行起來有計可循，按照規定，每個人完成任務也都很有成就感。
其余的就是額外的，基本也是不用動的，這其中包含了一個大塊，里面有些很多文檔的內容很豐富占了整個測試計劃的很大的篇幅。
第2項，列出了使用的測試的步驟，基本每個項目都可以按照這么去測試，里面包括冒泡，功能性能之類的，還會對具體的做一些特定的說明，尤其是公司會使用特定的工具。
第5項這是篇幅最大的一個，里面冉冉就是一個測試方案的縮寫版本，所以，這部分完全可以取代測試方案了，里面包括了測試用例的設計規則，使用的測試的方法（冒煙，交互性，系統，性能等等），缺陷管理的方法，缺陷曲線，會議評審的方式，測量和度量，這些都包括目標和范圍，所以里面分析的很細，想必很多公司在弄這個的時候都是集結了很多經驗的。
第12項，風險管理，就是根據公司制定的了。
綜上所述，對這一個測試計劃做了簡單 的分析，相信可以類比到很多的測試計劃。
最后，再小小的總結一下，測試計劃，其實是很簡單的文檔，寫起來簡單，讀起來也簡單，因為他有太多的相似和雷同，手中只要有一個模板，就有參考，再根據實際情況做一些小的調整。要弄清楚的是測試計劃中核心部分和綠葉部分。
轉載于:https://www.cnblogs.com/feiers/archive/2010/05/07/1729954.html
總結
以上是生活随笔為你收集整理的快速完成和读懂测试计划的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： arm流水线相关
- 下一篇： wireshark的使用方法（转）