計劃測試系列

（六）——事

本計劃的上一篇《計劃測試系列（五）——時》，是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分布，區域分布等），這些對于幫助項目順利進行很有幫助。當然，在一個迭代結束或者項目結束之后我們也要提交一個測試報告，這是一份總結性的報告。

安裝測試

考慮軟件所使用的各種硬軟件環境等問題，不僅僅在計劃的過程中體現到，還要檢查部署文檔或者產品說明書中是否包含了安裝環境的定義和介紹。

自動化測試

自動化測試的范疇及涉及的內容很多，根據項目組的實際情況引入和實施自動化測試是軟件測試發展的趨勢。

性能測試

性能測試的范疇又包括了壓力測試，負載測試，性能測試（狹義），大容量測試等等，這些都要根據實際需求加以取舍和安排，并在計劃中體現出來。

更新（軟件變更）測試

主要指版本的升級測試，尤其對于產品性質的軟件更應該注意這方面的問題。

測試工作本身還包括了其他很多內容，Failover和Switchover測試等等很多內容都需要考慮，有時候還要對軟件的邏輯關系，軟件的物理關系進行測試，還有更常見的界面測試，可用性測試，驗收測試等。這些測試及測試程度的取舍則取決與項目實際情況（時間，成本等等）以及測試人員個人的經驗等等。

（七）——我們什么時候停止？

我們什么時候停止我們的項目？我們應該在我們達到目標的時候停止�？墒�，目標是什么？Aaron認為所謂目標，即測試應該實現的可度量的要求，這個東西更常見的叫法——測試停止標準。

不知道有沒有程序員會笑話Aaron說：我們項目就是一個測試人員在點點，甚至不要測試人員點點我們也可以順利交付給客戶很有用的產品；不知道有沒有測試人員會講：我們測試的時候除了用例之外什么都沒有，更不用說什么無聊的測試停止標準 =! 不過Aaron告訴你，真要在項目里面有了這么個東西，只會對大家都好。你想，測試停止標準就是那可以止渴的“梅”，有了它咱就有了奮斗的方向，有了等到出頭之日的盼頭。同時因為一些項目組中測試標準也會作為版本發布標準——盡管這兩者還是有區別的——所以測試停止標準對于開發人員和PM也是有用的。

當然，并不是所有的測試停止標準都會有這般功效，在Aaron看來，一個合格的測試停止標準應該滿足一下條件：

在計劃階段盡早訂立測試停止標準

沒有規矩不成方圓，先定下規矩可以幫助我們一開始就計劃的時候就在畫著“方圓”，而不是等畫了一點點之后才發現用的“規矩”不是標準版的，那樣浪費了時間。

測試停止標準應該獲得項目負責人的確認

這一條尤其適用于并不是那么和諧的項目組以及習慣優柔寡斷的項目負責人領導的項目組。還要注意口說無憑，所以立字為據有時候也是需要的~我們的目的是要使規矩“定”下來。

對于這一條，存在這兩個風險：

一是容易導致不和諧：如果項目負責人簽了，感覺像是兄弟們在給他上枷鎖似的，更像是把一些責任推到他的身上去了。（因為存在這樣一種情況，大家訂立一個規矩，可是后來做的東西讓top leader不滿意，普通組員這個時候好歹還可以推說我們組的規矩是這樣做的，不需要問，當時簽字確認的項目負責人這下子責任就大了。）

二是因為需求變化，因為測試停止標準要求滿足可度量性（具體內容在后文詳談），所以可能會涉及到比較細致的東西，比如某個核心模塊應該怎么樣才算行——如果在后期需求變了，會不得不更改“定”下來的測試停止標準了。

對于這些風險的預防和處理，Aaron雖然有些心得，但是考慮到各個作坊情況不一樣，Aaron就不誤導各位了。

測試停止標準應該是可度量的

Aaron看來，對于測試停止標準，“可度量”這個要求是必需的，用抽象的語言來描述測試停止標準是無意義的。如在測試停止標準里面出現“在適當的時間停止測試”這句話是不對的，所謂“合適的時間”這類詞匯，要么讓人不解其意，要么出現“一千個觀眾眼中有一千個哈姆萊特”這種情況，因此一個準確的定義是必需的。

測試停止標準都是可以達到的

這個很容易理解，如果標準里面出現了要我們三五個人十來桿搶在一個月內造一個跟windows Xp一模一樣的操作系統給客戶，那定這個標準的人怕是跟Aaron前天一樣SB了~測試停止標準之中切忌出現不可能實現的或者很難達到的目標，比如在測試停止標準里面出現“修復所有的bug”這種條文，我們就要考慮實際情況中我們是否可能修復所有的bug，項目的要求是否如此嚴格——所有的bug都必須修復，而不是被處理（修復，延遲并報告等處理方式），是否允許部分bug推遲修復？

測試停止標準的檢查者

測試停止標準作為一個驗收標準，還需要明確規定標準執法者。沒有規矩不成方圓，但是有了規矩而不執行，也是成不了“方圓”的，所以需要執法者或者說護法者，在這里體現為檢查和核實我們的測試是否達到了標準。有時候，為了表示民主，大家一起說了算在人數不多的項目組也是一個可取的方式。

Aaron講了自己的一些理解，但看著過于抽象，所以就繼續具體點講一下。開發人員貼code，Aaron這邊沒Code，只好貼幾張便簽紙

上面幾張便簽來自網絡和個人實踐，Aaron只是摘選部分，切不可直接拿來作模板，否則就是Aaron的誤人子弟的罪過了~這幾張便簽紙并不能直接幫助讀者建立起一個適合自己項目的“測試停止標準”，因為Aaron相信大家的能力。Aaron將測試停止標準扯到計劃測試系列的目的，是要提醒讀者在計劃的時候就要有看到我們的結果的眼光。項目也好，測試過程也好，都是以結果為導向的，沒有最后的成功，中間過程即使很完美，對于項目（產品）自身是沒有任何意義的（大多數情況下，項目成員在吞食失敗的挫折感的同時，至少還收獲了經驗，所以可能還會有人會享受失敗項目中的“美好的過程”）。

文章來源于領測軟件測試網 http://www.kjueaiud.com/