如何寫好一份軟件測試計劃？(5)

　　回到上面的“月圓之夜”的故事片段上來，這個片段提醒了我們在時間計劃的時候還有一些問題需要注意。上面提到計劃失敗是因為“月圓”這個外界因素沒有達到要求，這就提醒我們在計劃的過程中，應當盡量減少對于外界的依賴，如果依賴是必需的，那么對于依賴可能導致的意外我們要多出幾套應急方案。另外，在項目執行過程中，及時檢查項目進度也是必要的，這可以避免我們跑在錯誤的道路上，那樣只會越錯越遠，這部分不屬于計劃測試的范疇，因此不做考慮了，如果有興趣可以看一下持續集成相關的資料。

　　(六)——事

　　本計劃的上一篇《計劃測試系列(五)——時》，是Aaron的軟肋，寫得很糟糕，但為了保持完整性，Aaron還是貼出來了，看著寥寥幾人的訪問量，Aaron覺得應該加油寫出更好的東西出來。廢話少說，開始念叨計劃測試系列中關于事的部分。

　　測試是做什么事的呢?測試是為了……趕緊打住，Aaron指的“事” 是一個測試項目過程中所做的具體的事，不是拿著《軟件測試》或者其他的經典來念句子的。按照Aaron自己在上一篇中的理解，軟件項目流程或者說一個迭代必定要經過計劃實施總結這幾個階段。對于測試來講我們可以將各個階段再細分，然后就成了下面這個樣子：

　　制定測試計劃

　　至于計劃的作用就不再贅述了，而測試計劃作為計劃測試活動的結晶，理應受到重視。在實際項目中Aaron發現自己寫出來的測試計劃這個文檔本身意義并不大，至少沒有計劃測試的過程那般有意義。在很多軟件作坊之中，測試計劃自一出生便被打入冷宮，測試計劃的意義僅僅是作坊主朝自己臉上貼金而使用的一種手段。Aaron推薦的方法是完成一個交差的測試計劃后，維護一個名為測試計劃實質上更像測試設計(Test Design Spec)的文檔，在整個測試執行過程中該文檔都起著提綱的作用，而且任何讀者都可以通過這份Test Design Spec中了解Aaron對項目測試的想法和測試思路。Aaron在自己所處的項目組中爭取到了Test Design Spec的Review機會。Aaron是這樣告訴他們的：Aaron擔心自己理解錯誤了PM的意思，Aaron擔心自己想的跟Dev不一樣，Aaron 想先把事情說清楚，所以Aaron要Review。

　　關于測試計劃的內容Aaron在本系列文章的第二篇也聊過——《計劃測試系列(二)——測試計劃 》。

　　測試軟件需求

　　軟件需求是測試應該覆蓋到的地方，這也是為什么很多軟件方法提倡測試盡早介入到軟件開發進程中的原因之一。對于PM提供的那份Feature列表或者 Feature Spec，我們應該抱著懷疑的態度，PM不是項目對象領域的專家，他會犯錯，他也會馬虎，他也會有腦袋短路的時候，所以這個時侯需要包括測試人員在內的很多項目成員來一起檢查這個list或者spec，稱之為Review。對于測試人員及其他參與Review的人員應該實現閱讀文檔并了解項目相關領域的知識。Aaron剛才提到的Test Design Spec的Review工作比較好地完成了任務，當然限于相關業務知識和經驗，Test Design Spec的質量會有高有低，Reivew的效果也就可能很不一樣。Aaron建議先不斷錘煉自己的Test Design Spec之后再提交Review，Aaron自己一般要到V1.3版本才敢拿出去跟PM和Dev“分享”。

　　測試用例設計

　　有關測試用例設計的方法，諸如等價類劃分，邊界值分析，甚至需求矩陣方法等等，Aaron在這里就不在閑聊，這些東西網絡上已有的文檔要比Aaron講的專業的多，更何況這些內容也不是本文的目的所在。

　　執行測試

　　主要是指測試用例的執行，但是還應該包括測試用例的更新，還包括bug的提交和管理等等內容。Aaron在周期稍長的迭代中還會每周發一個Weekly Test Report給項目組成員，幫助他們了解一周來測試工作的進展(以測試用例的數量趨勢，分布)，還會報告當前的bug相關的信息(Bug總數，趨勢，嚴重 bug分布，區域分布等)，這些對于幫助項目順利進行很有幫助。

　　報告測試結果

　　Aaron在周期稍長的迭代中會每周發一個Weekly Test Report給項目組成員，幫助他們了解一周來測試工作的進展(以測試用例的數量趨勢，分布)，還會報告當前的bug相關的信息(Bug總數，趨勢，嚴重 bug分布，區域分布等)，這些對于幫助項目順利進行很有幫助。當然，在一個迭代結束或者項目結束之后我們也要提交一個測試報告，這是一份總結性的報告。

原文轉自：http://www.uml.org.cn/Test/200911128.asp