如何寫一份靠譜的軟件測試計劃？(6)

　　安裝測試

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

　　自動化測試

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

　　性能測試

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

　　更新(軟件變更)測試

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

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

　　(七)——我們什么時候停止?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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