● Project Goal & None Goal
說實話這是我之前認為測試計劃里面最沒用的部分，因此被我拋棄了很久時間，而據我所知這也是測試計劃中最容易被人忽略的部分。不過，現在我卻喜歡并且建議將這部分重視起來。作為一個項目來講，尤其是產品類項目，整個Team需要明確自己應該做什么樣的產品，不應該把產品做成什么樣子，這個部分寫在測試計劃的第一部分，時不時瞅一瞅，提醒我們要向著正確的方向走。否則，在錯誤的道路上跑的越快，錯的越遠。
● 版本歷史信息和狀態信息
這一部分容易被人忽略是因為幾乎所有的文檔中都有這一部分，或許因為這個緣故，這一塊反而成了文檔中最不受人關注的部分，大多數人一看文檔直接跳到目錄，甚至直接跳到內容的汪洋中大海撈針。版本變遷中最有用的部分是備注部分，一般這一部分介紹了文檔最新更改的部分以幫助讀者快速了解文檔的一些基本情況。其次，其中的狀態信息也會很有用，因為對于讀者來講，花費半小時看一份Draft是沒有多大意義的。其他因為類似原因(因經常出現在各種文檔中反而遭受忽略)而容易被人忽略的部分還包括“術語和縮略語”“引用”“文檔介紹”“目錄”，幾乎所有的常見文檔元素~
一份好的文檔中這些部分都會恰到好處，讀者閱讀一份好的文檔可能不會感受到欣喜，但是如果閱讀一份沒有或者寫的很糟的文檔則絕對會感受到痛苦甚至直接不看文檔，這也從另一個方面導致了文檔總是容易被人冷落，尤其是測試文檔。
● 測試接收標準和測試結束標準
這一部分主要是容易流于形式而被人忽略，對于很多項目來講，根本沒有所謂的標準而言，領導說開干，什么時候干好，ok，這就是開始標準和結束標準，而對于質量這些東西則早被拋到了最后。是的，或許有人會說，即使我們指定了一份好的測試標準，即使我們的領導也不會毫無理由的橫加干涉，但是市場等原因也會造成產品在沒有達到產品發布標準的時候發布出去。對于這個觀點，網上通用的反對理由是：沒有質量保證的產品最終會被淘汰，而且會累及公司的名譽。而我需要另外加一條理由：即使一個人系上安全帶開車也會因為車禍掛掉，但系上安全帶出事的概率要比不系要低很多吧。
● 風險分析
我之前在寫測試計劃的時候，這一塊一直是流于形式的客套話，寫完了就完了，從此再也不去管它，沒有把風險分析的作用利用起來。關于風險分析，文章后面還會專門提到。
Part III 測試計劃文檔中隱含的信息
● 優先級
或許文檔的作者并沒有直接標出那些計劃事項是具有高優先級，哪些是低優先級的工作項，如果在這種情況下讀者仍然能很清晰地知道自己先做什么后做什么——至少應該知道今天和明天應該做什么吧——的話，那么測試計劃的作者很可能把優先級隱含到了測試進度(Test Scheduler)安排這一部分了，一般來講先要完成的事情優先級是最高的，而直接將優先級融入測試進度安排也是一種不錯的選擇。不過這種做法也有一些弊端，如果將工作項“寫死”到進度安排中，當遇到某個工作項暫時延遲的時候會造成Test Scheduler的變化而影響其他工作項的執行時間。
● Uncovered
在測試計劃中，有一個部分叫做Test Scope，而這一部分一般又會被劃分成Covered和Uncovered兩個部分。這兩部分有什么玄機呢?大家應該知道測試的無窮盡特征，想到了這一點可能會有人馬上反應過來：那Uncovered部分豈不是有很多內容?那為什么事實上Uncovered部分并沒有洋洋灑灑幾千字將我們沒有做到的盡可能列出來呢?其實，一份測試計劃只能表現出在特定項目中的測試(比如如果不需要security test，那么測試計劃中可能就不曾提到security test，甚至在not Covered部分也未曾提到。測試類型方法太多了，如果都在not Covered部分提到，那完全可以另外出一本書了)，所以Uncovered部分提到的只是常見的測試類型或者方法，以及部分功能或者UI等內容，這部分是告訴讀者，這一部分我們在測試里面不會——至少是不會專門設計相關的測試用例——測試的啊。這時候，我們一般會在Uncovered內容的后半部分看到關于為什么不覆蓋到這一部分的“官方解釋”。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
