基于規范的測試
檢查相關文檔中的關于程序的每一個聲明，例如設計規范、需求列表、用戶接口描述，發布原型、或者用戶手冊。
在企業中，嚴格按他們的規范進行測試是非常重要的(有激發性的)。比如，如果規范是合同的一部分，遵照規范是非常重要的。同樣，產品必須遵照他們的聲明，關乎生命的產品必須遵照所有與安全相關的規范。
規范驅動的測試一般是比較弱的，對特定規范條目進行測試的這類測試是明顯不具有代表性的。
某些基于規范測試的團隊僅僅局限于文檔中的描述。對他們來說，一個好的測試集合包含了規范中為每一個聲明制定的明確的、有關的測試。
其他團隊對規范中的問題有長遠見解。他們發現，對說明詳盡的產品進行的大多數信息測試經常會出現規范中的不明確點，或者檢查說明不詳盡的產品。
基于風險的測試
設想程序失敗的一個情形，然后設計一個或多個測試來檢查這個程序是否真的會在那種情形下失敗。
一個完美的基于風險測試的集合應該基于一個詳盡的風險列表，一個每種情形都能使程序失敗的列表。
一個好的基于風險的測試是一個致力于解決特定風險測試的一個典型代表。
測試中出現重大失誤或者對手產品有明顯失誤，在這種程度上，基于風險的失敗會是非�？煽�、非常有激發性的。但是，很多基于風險的測試在理論上(實際應用中不可能發生)是被忽略的。(潛在失誤)從實際存在的失誤中測出來的風險是很有價值的，會使測試更可靠。
基于風險的測試在于傳遞高度的信息價值，因為你有理由相信產品中確實存在你要測的問題。我們能從程序能否通過測試中學到很多東西。
壓力測試
下面是壓力測試的幾種不同定義：
一個普通的定義，用一個峰值脈沖活動來沖擊程序，看他是否會失敗。 軟件測試
IEEE標準610.12-1990是這樣定義的：“測試把致使系統故障做為目標來評價一個系統或組件是否超出其指定的需求�！�
為監視程序如何失敗而用第三種方法使程序陷入故障。
比如，如果測試使用了過多的輸入，那么你不只是測試規定的限額。你不斷增加輸入的尺度或速度，直到程序最終失敗或者你確信進一步的增加不會導致失敗。事實上程序最終失敗不會明顯的令人驚訝或者激動。當你看到失敗，詢問暴露了什么弱點以及在低于極限環境下時其中哪些弱點會被觸發是令人感興趣的。Jorgensen(2003)提供了一個這種類型的有誘惑力的例子。
我是以第三種定義工作的。
這些測試是很有力度的。
有些人忽視了壓力測試使得對顧客的使用不具代表性，因此不可靠、不具目的性。壓力測試的另一個問題是失敗是沒用的，除非測試提供了一個解決問題的信息，或者領導測試的人員對其應用非常熟悉。
一個好的壓力測試推動了你想增加的極限，包括足夠的診斷支持使你在看到失敗時，非常容易地發現。
有些測試人員，比如Alberto Savoia(2000)，用類似壓力測試來暴露失敗，這很難察看系統是否同時運行了若干個任務。這些失敗通常在系統的理論限制內暴露出來，因此它們是更可靠、更有目的性，但它們不便于解決問題。
回歸測試
設計、開發和保存測試的目的是有規律地重復利用它們，發生變更之后對程序做重復測試。
有必要注意的一點(考慮回歸測試)是這不是測試類型的一個直交列表。你可以給你的回歸測試集合輸入域測試或者基于規范的測試或者其他任何測試類型。
所以這些與其他測試之間有什么不同之處?我將用例子來回答這個問題：
假設一個測試人員創建了一組域測試并保存之以便于復用。這是域測試還是回歸測試?
在創建測試時如果測試人員主要考慮區分變量，并找到最具代表性的一個時，我認為它是主要是域測試。
如果測試人員主要考慮創建一個復用測試集合的話，我認為它主要是回歸測試。
如果是第一次設計的回歸測試，那他們應該是有力的、可靠的等等。但是，在一個測試多次運行并通過之后，程序不可能在下一次測試時失敗，除非發生了較大的變更或者部分代碼變更直接參與了這個測試。因此，多數情況下，回歸測試會產生很小的信息價值。
一個好的回歸測試是為復用設計的。它是完全文檔化的和可維護的。(建議：提高GUI級測試的可維護性，參見Graham & Fewster,1999;Kaner,1998; Pettichord,2002,以及www.perrichord.com上的論文)。
如果變更減少了程序進行回歸測試在功能或范圍上的錯誤，那么一個設計的好的回歸測試可能會失敗。
文章來源于領測軟件測試網 http://www.kjueaiud.com/