軟件計劃測試系列(六)——事 測試計劃
本計劃的上一篇《計劃測試系列(五)——時》，是我的軟肋，寫得很糟糕，但為了保持完整性，還是貼出來了，看著寥寥幾人的訪問量，覺得應該加油寫出更好的東西出來。廢話少說，開始念叨計劃測試系列中關于事的部分。
測試是做什么事的呢?測試是為了……趕緊打住，我指的“事” 是一個測試項目過程中所做的具體的事，不是拿著《軟件測試》或者其他的經典來念句子的。按照自己在上一篇中的理解，軟件項目流程或者說一個迭代必定要經過計劃實施總結這幾個階段。對于測試來講我們可以將各個階段再細分，然后就成了下面這個樣子：
制定測試計劃
至于計劃的作用就不再贅述了，而測試計劃作為計劃測試活動的結晶，理應受到重視。在實際項目中我發現自己寫出來的測試計劃這個文檔本身意義并不大，至少沒有計劃測試的過程那般有意義。在很多軟件作坊之中，測試計劃自一出生便被打入冷宮，測試計劃的意義僅僅是作坊主朝自己臉上貼金而使用的一種手段。 鄙人推薦的方法是完成一個交差的測試計劃后，維護一個名為測試計劃實質上更像測試設計(Test Design Spec)的文檔，在整個測試執行過程中該文檔都起著提綱的作用，而且任何讀者都可以通過這份Test Design Spec中了解Aaron對項目測試的想法和測試思路。我在自己所處的項目組中爭取到了Test Design Spec的Review機會。偶是這樣告訴他們的：擔心自己理解錯誤了PM的意思，擔心自己想的跟Dev不一樣，想先把事情說清楚，所以偶要Review。
關于測試計劃的內容在本系列文章的第二篇我們也聊過——《計劃測試系列(二)——測試計劃 》。
測試軟件需求
軟件需求是測試應該覆蓋到的地方，這也是為什么很多軟件方法提倡測試盡早介入到軟件開發進程中的原因之一。對于PM提供的那份Feature列表或者Feature Spec，我們應該抱著懷疑的態度，PM不是項目對象領域的專家，他會犯錯，他也會馬虎，他也會有腦袋短路的時候，所以這個時侯需要包括測試人員在內的很多項目成員來一起檢查這個list或者spec，稱之為Review。對于測試人員及其他參與Review的人員應該實現閱讀文檔并了解項目相關領域的知識。剛才提到的Test Design Spec的Review工作比較好地完成了任務，當然限于相關業務知識和經驗，Test Design Spec的質量會有高有低，Reivew的效果也就可能很不一樣。建議先不斷錘煉自己的Test Design Spec之后再提交Review，俺自己一般要到V1.3版本才敢拿出去跟PM和Dev“分享”。
測試用例設計
有關測試用例設計的方法，諸如等價類劃分，邊界值分析，甚至需求矩陣方法等等，在這里就不在閑聊，這些東西網絡上已有的文檔要比我講的專業的多，更何況這些內容也不是本文的目的所在。
執行測試
主要是指測試用例的執行，但是還應該包括測試用例的更新，還包括bug的提交和管理等等內容。我在周期稍長的迭代中還會每周發一個Weekly Test Report給項目組成員，幫助他們了解一周來測試工作的進展(以測試用例的數量趨勢，分布)，還會報告當前的bug相關的信息(Bug總數，趨勢，嚴重 bug分布，區域分布等)，這些對于幫助項目順利進行很有幫助。
報告測試結果
我在周期稍長的迭代中會每周發一個Weekly Test Report給項目組成員，幫助他們了解一周來測試工作的進展(以測試用例的數量趨勢，分布)，還會報告當前的bug相關的信息(Bug總數，趨勢，嚴重 bug分布，區域分布等)，這些對于幫助項目順利進行很有幫助。當然，在一個迭代結束或者項目結束之后我們也要提交一個測試報告，這是一份總結性的報告。
安裝測試
考慮軟件所使用的各種硬軟件環境等問題，不僅僅在計劃的過程中體現到，還要檢查部署文檔或者產品說明書中是否包含了安裝環境的定義和介紹。
自動化測試
自動化測試的范疇及涉及的內容很多，根據項目組的實際情況引入和實施自動化測試是軟件測試發展的趨勢。
性能測試
性能測試的范疇又包括了壓力測試，負載測試，性能測試(狹義)，大容量測試等等，這些都要根據實際需求加以取舍和安排，并在計劃中體現出來。
更新(軟件變更)測試
主要指版本的升級測試，尤其對于產品性質的軟件更應該注意這方面的問題。
測試工作本身還包括了其他很多內容，Failover和Switchover測試等等很多內容都需要考慮，有時候還要對軟件的邏輯關系，軟件的物理關系進行測試，還有更常見的界面測試，可用性測試，驗收測試等。這些測試及測試程度的取舍則取決與項目實際情況(時間，成本等等)以及測試人員個人的經驗等等。
文章來源于領測軟件測試網 http://www.k11sc111.com/
