你不知道的軟件測試計劃

你不知道的軟件測試計劃    軟件測試

話說測試計劃就那么一些字兒，白紙黑字明明白白放那兒，應該不會有什么玄機。如果你是一個開發人員，這倒也不奇怪；如果你是一個測試計劃制定者或審閱者，你還是覺得測試計劃如此而已的話，那你可以好好看看我的見解。一不小心寫得有點小多，而且全是小字兒，希望不要看花眼。

　　Part I 測試計劃閱讀的五重境界

　　在我看來，測試計劃的作者和讀者有以下五重境界。

　　第一重：什么都有用

　　對于一個測試新手來講，好不容易找到一份測試計劃模板，準備大干一場好好看看測試計劃里面有哪些道道，看著看著發現很多東西都不知道，所以也分不清主次，自然也就覺得什么都很重要了。

　　第二重：什么都沒用

　　當一個測試新手漸漸熟悉了測試的一些基礎知識之后，回過頭去看那些測試計劃，發現里面什么“實質性”的內容都沒有，沒有他所關心的測試中的具體的方法，還沒有一份測試用例來的有用。

　　第三重：僅部分有用

　　漸漸的，這個新手也不可避免地開始關注測試流程這一塊的東西，再回過頭看那個測試計劃模板。這回感覺又不一樣了，有些以前覺得沒有多大用處的東西還是多多少少可以幫助我們更好的測試，比如測試計劃模板中考慮到的要執行哪些類型的測試這部分內容應該就很有用，但是其他部分貌似還是很“虛”，一點實際用處都沒有。

　　第四重：什么都有用

　　這是我自認為達到的水平級別~現在的我發現，一份好的測試計劃模板中的所有內容都是有用的，包括風險分析這些我之前認為是用來湊字數的部分其實都是有著它的作用的，而且一份好的測試計劃模板所包含的內容遠遠不止你從字面上讀出來的那么簡單，而這些也是我今天想要和大家一起分享的東西。

　　第五重：什么都沒用

　　我還沒有達到這種級別，所以這只是我揣測的一種境界。當某一類測試做的非常久非常熟了，對于這類測試的整個流程以及需要注意到的各個方面都已經爛熟于心，自然就不會把測試計劃中的條條框框放在眼里了，或許這就是所謂的“隨心所欲不逾矩”吧~（不過，我也想過，好記性不如爛筆頭，或許這種達人級別的境界壓根就沒必要應用于實踐吧。）

　　Part II 測試計劃文檔中容易被人忽略的部分

　　● 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.anti-gravitydesign.com