軟件測試知識帖(1-20)

軟件測試知識帖(1-20)

來源：測試時代(www.testage.net)

第1帖【2004－5－10】：軟件測試的理想模式是什麼？

Brian Marick：我不認爲存在什麼理想模式。我覺得讓開發人員承擔某些測試也許會更加有效，而其他測試則由獨立測試組來進行。因爲如果你把所有測試都交給獨立測試組，他們不可能有時間把所有測試都做好。所以，最佳的方式是讓開發人員承擔一定量的測試，獨立測試組給予他們支持。獨立測試組主要承擔整個系統的測試，去尋找開發人員還沒有發現的缺陷，如子系統間的交互、運行條件、內存使用等。

如何更有效地開展系統測試呢？讓測試人員在項目初期就參與進蹤去，讓他們看到第一版的系統需求、用戶手冊和系統原型，在系統實現前就對需求進行捕獲和跟蹤。在該過程中，他們從這些文檔構造最初的測試設計。這也可以通過檢視或評審的形式進行，並且在該過程中會發現一些缺陷。大家都知道，這個階段，問題發現是非常“便宜”的。

這樣，系統測試工程師在項目早期就介入，產生測試設計及基本的需要測試的項目列表。這時不可能產生一個絕對完備的測試設計，因爲書寫完整測試的條件還不成熟，但這卻是構建完整測試的基礎。

注：Brian Marick是Reliability Software公司的專職測試技術顧問。

第2帖【2004－5－11】：測試經理角色定位

Johanna Rothman：測試經理服務於兩種完全不同的客戶：測試工程師和高層管理者。對於測試工程師，測試經理幫助他們開發產品測試策略，積累產品測試經驗並在測試組內充分共享。對於高層管理者，測試經理蒐集儘可能全面的產品信息，供其就產品是否可以發佈進行決策。但是有一點是相同的：無論是對於測試工程師還是高層管理者，測試經理將幫助其定義和校驗產品發佈標準。

產品發佈標準的定義和校驗：作爲一個測試經理，應該找機會與市場、開發人員商討產品發佈標準，並根據客戶的反饋對該標準進行修正和校驗。開發部門的工作是如何達到公司對產品的期望，要用客戶需求爲開發人員勾畫出客戶眼中的產品以及產品應如何工作。一旦產品被清楚地定義，就可以通過測試去驗證產品在多大程度上滿足了客戶需求。

對於測試工程師而言有一點非常重要：將測試任務按優先級劃分，使產品發佈標準得以滿足。由於只有極少數的項目有充足的時間去完成所有事情，所以告訴測試工程師關於“測什麼和何時測”是測試經理的一個重要職責。

高層管理者需要充分理解產品發佈標準，以決定產品是否可以按時發佈。我不認爲測試組有權利裁決產品是否應該被髮布，該權利在組織高層管理者那裏。在有了一個通過討論、達成一致的產品發佈標準後，項目組也可以更清楚地瞭解和認識產品質量。

第3帖【2004－5－12】：測試的基本原則

（美）Roger S. Pressman

在設計有效測試用例之前，測試工程師必需理解軟件測試的基本原則。這裏有一組測試原則：

1、所有的測試都應追溯到用戶需求。正如我們所知：軟件測試的目標在於揭示錯誤。而最嚴重的錯誤（從用戶角度來看）是那些導致程序無法滿足需求的錯誤。

2、應該在測試工作真正開始前的較長時間內就進行測試計劃。測試計劃可以在需求模型一完成就開始，詳細的測試用例定義可以在設計模型被確定後立即開始。因此，所有測試應該在任何代碼被產生前就進行計劃和設計。

3、Pareto原則應用於軟件測試。簡單地講，Pareto原則暗示着測試發現的錯誤中的80％很可能起源於程序模塊中的20％。當然，問題在於如何孤立這些有疑點的模塊並進行徹底的測試。

4、測試應從“小規模”開始，逐步轉向“大規模”。最初的測試通常把焦點放在單個程序模塊上，進一步測試的焦點則轉向在集成的模塊簇中尋找錯誤，最後在整個系統中尋找錯誤。

5、窮舉測試是不可能的。即使是一個大小適度的程序，其路徑排列的數量也非常大。因此，在測試中不可能運行路徑的每一種組合。然而，充分覆蓋程序邏輯，並確保程序設計中使用的所有條件是有可能的。

6、爲了達到最佳效果，應該由獨立的第三方來構造測試。“最佳效果”指最有可能發現錯誤的測試（測試的主要目標），所以創建系統的軟件工程師並不是構造軟件測試的最佳人選。

第4帖【2004－5－13】：什麼是“好”的測試？

什麼是“好”的測試？ Kaner，Falk & Nguyen

1、一個好的測試發現錯誤的可能性很高

爲了達到這個目標，測試者必需理解軟件、並嘗試設想軟件如何才能失敗，例如：在GUI（圖形用戶界面）中有一種潛在的錯誤，即錯誤識別鼠標位置，那麼就應該設計一個測試集來驗證是否存在鼠標位置識別的錯誤。

2、一個好的測試並不冗餘

測試的時間和資源是有限的，沒有必要構造一個與其他測試用例完全相同的測試，每一個測試都應該有不同的用途〔哪怕是細微的差異〕。例如，軟件SafeHome中有一個模塊被用來識別用戶密碼以決定是否啓動系統，爲了測試密碼輸入的錯誤，測試者設計了一系列的輸入密碼。在不同的測試中輸入有效與無效密碼（4個數字），然而，每一個有效/無效密碼將只檢測一種不同錯誤模式，例如一個將8080作爲有效密碼的系統將不會接受非法密碼1234，如果接受1234，將產生錯誤，另一個測試輸入1235，與1234的測試意圖相同，因此是冗餘的，然而，非法輸入8081或8180就有些細微的差異，即對與有效密碼相近但並不相同的密碼應該進行測試。

3、一個好的測試應該是“最佳品種”

在一組目的相似的測試中，時間和資源的限制可能隻影響其某個子集的執行，此時，應該使用最可能找到所有錯誤的測試。

4、一個好的測試既不會太簡單，也不會太複雜

雖然有時會將一組測試組合到一個測試用例中，其副作用可能屏蔽錯誤，通常每一個測試應該獨立執行。

第5帖【2004－5－14】：軟件可測試性

Roger S. Pressman

理想情況下，軟件工程師在設計計算機程序、系統或產品時應該考慮可測試性，這就使得測試工程師能夠更容易地設計有效的測試用例。

什麼是“可測試性”？軟件的可測試性是指軟件發現故障並隔離、定位其故障的能力特性，以及在一定的時間和成本前提下，進行測試設計、測試執行的能力。James

Bach這樣描述可測試性：軟件可測試性就是一個計算機程序能夠被測試的容易程度。

以下是一個常見的軟件可測試性檢查表：

·可操作性－“運行地越好，被測試的效率越高。”

·可觀察性－“所看見的，就是所測試的。”

·可控制性－“對軟件的控制越好，測試越能夠被自動執行與優化。”

·可分解性－“通過控制測試範圍，能夠更好地分解問題，執行更靈巧的再測試。”

·簡單性－“需要測試的內容越少，測試的速度越快。”

·穩定性－“改變越少，對測試的破壞越小。”

·易理解性－“得到的信息越多，進行的測試越靈巧。”

第6帖【2004－5－15】：實時系統測試

Roger S. Pressman

很多實時系統的時間依賴性和異步性給測試帶來新的困難－－時間！測試用例的設計者考慮的不僅是白盒和黑盒測試用例，而且包括事件處理（如中斷處理）、數據的時間序列以及處理數據的任務（進程）的併發性。很多情況下，提供的測試數據有時使得實時系統在某狀態下可以正常運行，而同樣的數據在系統處於不同狀態時有時又會導致錯誤。

另外，實時系統的軟件和硬件之間的密切關係也會導致測試問題，軟件測試必須考慮硬件故障對軟件處理的影響，這種故障很難實時仿真。由於實時系統的特殊性和複雜性，還沒有一個完善的綜合性的測試用例設計方法，但是，大致可以分爲以下四個步驟：

1、任務測試。測試實時系統的第一步是獨立的測試各個任務。對每一個任務設計白盒和黑盒測試用例，並在測試時執行每個任務。任務測試能夠發現邏輯和功能錯誤，但是不能發現時間和行爲錯誤。

2、行爲測試。利用CASE工具創建軟件模型，就可能仿真實時系統，並按照外部事件的序列檢查其行爲，這些分析活動可作爲創建實時系統時設計測試用例的基礎。

3、任務間測試。在隔離了任務內部和系統行爲錯誤以後，測試就要轉向時間相關的錯誤。用不同的數據率和處理負載來測試與其他任務通訊的異步任務，看任務間的同步是否會產生錯誤。另外，測試通過消息隊列和數據存儲進行通訊的任務，以發現這些數據存儲區區域大小方面的錯誤。

4、系統測試。集成軟件和硬件，並進行大範圍的系統測試，以發現軟件/硬件接口間的錯誤。

第7帖【2004－5－16】：單元測試、集成測試、系統測試、驗收測試、迴歸測試

Software Research

單元測試：單元測試是對軟件中的基本組成單位進行的測試，如一個模塊、一個過程等等。它是軟件動態測試的最基本的部分，也是最重要的部分之一，其目的是檢驗軟件基本組成單位的正確性。一個軟件單元的正確性是相對於該單元的規約而言的。因此，單元測試以被測試單位的規約爲基準。單元測試的主要方法有控制流測試、數據流測試、排錯測試、分域測試等等。

集成測試：集成測試是在軟件系統集成過程中所進行的測試，其主要目的是檢查軟件單位之間的接口是否正確。它根據集成測試計劃，一邊將模塊或其他軟件單位組合成越來越大的系統，一邊運行該系統，以分析所組成的系統是否正確，各組成部分是否合拍。集成測試的策略主要有自頂向下和自底向上兩種。

系統測試：系統測試是對已經集成好的軟件系統進行徹底的測試，以驗證軟件系統的正確性和性能等滿足其規約所指定的要求，檢查軟件的行爲和輸出是否正確並非一項簡單的任務，它被稱爲測試的“先知者問題”。因此，系統測試應該按照測試計劃進行，其輸入、輸出和其他動態運行行爲應該與軟件規約進行對比。軟件系統測試方法很多，主要有功能測試、性能測試、隨機測試等等。

驗收測試：驗收測試旨在向軟件的購買者展示該軟件系統滿足其用戶的需求。它的測試數據通常是系統測試的測試數據的子集。所不同的是，驗收測試常常有軟件系統的購買者代表在現場，甚至是在軟件安裝使用的現場。這是軟件在投入使用之前的最後測試。

迴歸測試：迴歸測試是在軟件維護階段，對軟件進行修改之後進行的測試。其目的是檢驗對軟件進行的修改是否正確。這裏，修改的正確性有兩重含義：一是所作的修改達到了預定目的，如錯誤得到改正，能夠適應新的運行環境等等；二是不影響軟件的其他功能的正確性。

第8帖【2004－5－17】：軟件測試策略

Roger S. Pressman

測試是一系列可以事先計劃並且可以系統地進行管理的活動。正是由於這個原因，應當爲軟件工程過程定義一個軟件測試的模板－我們可以把特定的測試用例方法放置進去的一系列步驟。

人們已經提出了許多軟件測試策略，所有這些策略都爲如開發人員提供了一個供測試用的模板，而且它們都包含下列的類屬特徵：

·測試開始於模塊層，然後“延伸”到整個基於計算機的系統集合中。

·不同的測試技術適用於不同的時間點。

·測試是由軟件的開發人員和（對於大型系統而言）獨立的測試組來管理的。

·測試和調試是不同的活動，但是調試必須能夠適應任何的測試策略。

軟件測試策略必須提供可以用來檢驗一小段源代碼是否得以正確實現的低層測試，同時也要提供能夠驗證整個系統的功能是否符合用戶需求的高層測試。一種策略必須爲使用者提供指南，並且爲管理者提供一系列的重要的里程碑。因爲測試策略的步驟是在軟件完成的最終期限的壓力已經開始出現的時候纔開始進行的，所以測試的進度必須是可測量的，而且問題要儘可能早的暴露出來。

第9帖【2004－5－18】：白盒測試

Rex Black

白盒測試，也稱爲結構化測試、基於代碼的測試，是一種測試用例設計方法，它從程序的控制結構導出測試用例。用白盒測試產生的測試用例能夠：

1）保證一個模塊中的所有獨立路徑至少被使用一次；

2）對所有邏輯值均需測試true和false；

3）在上下邊界及可操作範圍內運行所有循環；

4）檢查內部數據結構以確保其有效性。

“我們應該更注重於保證程序需求的實現，爲什麼要花費時間和精力來擔心（和測試）邏輯細節？”

答案在於軟件自身的缺陷：

1、邏輯錯誤和不正確假設與一條程序路徑被運行的可能性成反比。當我們設計和實現主流之外的功能、條件或控制時，錯誤往往開始出現在我們工作中。日常處理往往被很好地瞭解，而“特殊情況”的處理則難於發現。

2、我們經常相信某邏輯路徑不可能被執行，而事實上，它可能在正常的基礎上被執行。程序的邏輯流有時是違反直覺的，這意味着我們關於控制流和數據流的一些無意識的假設可能導致設計錯誤，只有路徑測試才能發現這些錯誤。

3、筆誤是隨機的。當一個程序被翻譯爲程序設計語言源代碼時，有可能產生某些筆誤，很多將被語法檢查機制發現，但是，其他的會在測試開始時纔會被發現。筆誤出現在主流上和不明顯的邏輯路徑上的機率是一樣的。

正如Beizer所說的：“錯誤潛伏在角落裏，聚集在邊界上”，而白盒測試更可能發現它。

白盒測試是一種邏輯覆蓋方法，主要包括：

語句覆蓋

判定覆蓋

條件覆蓋

判定-條件覆蓋

條件組合覆蓋

路徑覆蓋

第10帖【2004－5－19】：黑盒測試

黑盒測試注重於測試軟件的功能性需求，也即黑盒測試使軟件工程師派生出執行程序所有功能需求的輸入條件。黑盒測試並不是白盒測試的替代品，而是用於輔助白盒測試發現其他類型的錯誤。黑盒測試試圖發現以下類型的錯誤：

1）功能錯誤或遺漏；

2）界面錯誤；

3）數據結構或外部數據庫訪問錯誤；

4）性能錯誤；

5）初始化和終止錯誤。

白盒測試在測試的早期採用，而黑盒測試主要用於測試的後期。黑盒測試故意不考慮控制結構，而是注意信息域。黑盒測試用於回答以下問題：

1）如何測試功能的有效性？

2）何種類型的輸入會產生好的測試用例？

3）系統是否對特定的輸入值尤其敏感？

4）如何分隔數據類的邊界？

5）系統能夠承受何種數據率和數據量？

6）特定類型的數據組合會對系統產生何種影響？

運用黑盒測試方法，可以導出滿足以下標準的測試用例集：

1）所設計的測試用例能夠減少達到合理測試所需的附加測試用例數；

2）所設計的測試用例能夠告知某些類型錯誤的存在或不存在，而不是僅僅與特定測試相關的錯誤。

第11帖【2004－5－20】：軟件測試充分性準則

（1）空測試對任何軟件都是不充分的。

（2）對任何軟件都存在有限的充分測試集合。

（3）如果一個軟件系統在一個測試數據集合上的測試是充分的，那麼再多測試一些數據也應該是充分的。這一特性稱爲單調性。

（4）即使對軟件所有成分都進行了充分的測試，也並不意味着整個軟件的測試已經充分了。這一特性稱爲非複合性。

（5）即使對一個軟件系統整體的測試是充分的，也並不意味着軟件系統中各個成分都已經充分地得到了測試。這個特性稱爲非分解性。

（6）軟件測試的充分性應該與軟件的需求和軟件的實現都相關。

（7）軟件越複雜，需要的測試數據就越多。這一特性稱爲複雜性。

（8）測試得越多，進一步測試所能得到的充分性增長就越少。這一特性稱爲回報遞減率。

第12帖【2004－5－21】：靜態測試

在軟件開發過程中，每產生一個文檔，都必須對它進行測試，以確定它的質量是否滿足要求。這樣的檢查工作與全面質量管理的思想是一致的，也與項目管理過程相一致。每當一個文檔通過了靜態測試，就標誌着一項開發工作的總結，標誌着項目取得了一定的進展，進入了一個新的階段。

靜態測試的基本特徵是在對軟件進行分析、檢查和測試時不實際運行被測試的程序。它可以用於對各種軟件文檔進行測試，是軟件開發中十分有效的質量控制方法之一。在軟件開發過程中的早期階段，由於可運行的代碼尚未產生，不可能進行動態測試，而這些階段的中間產品的質量直接關係到軟件開發的成敗與開銷的大小，因此，在這些階段，靜態測試的作用尤爲重要。在軟件開發多年的生產實踐經驗和教訓的基礎上，人們總結出了一些行之有效的靜態測試技術和方法，如結構化走通、正規檢視等等。這些方法和測試技術可以與軟件質量的定量度量技術相結合，對軟件開發過程進行監視、控制，從而保障軟件質量。

第13帖【2004－5－22】：什麼是測試需求？

Brian Marick

測試需求的概念比較簡單。例如，比方說一個計算平方根的程序，如果輸入一個大於或等於零的數，程序可以給出一個結果；如果輸入一個小於零的數，程序將指出輸入錯誤。讀過《軟件測試的藝術》一書的工程師都會立即聯想到邊界值。對數值零進行測試；對零非常接近的負數進行測試，這就是兩個具體的測試需求。

在一個更加複雜的程序中，你可以將打算測試的項目做成一個列表。但是，這些測試需求都不會確定具體的測試數據。例如，一個銀行交易程序，一個測試需求是試圖支付客戶的金額爲負數，另一個測試需求是交易中的客戶並不存在，等等。你有一系列這樣的測試需求，它們並沒有指出具體的數值或數據，如客戶的姓名。

測試的下一步是選擇滿足這些測試需求的輸入值/測試數據。一個簡單的測試用例可能會同時滿足好幾個測試需求。一個用例能同時滿足好幾個測試需求，當然是最理想的情況，但是這樣做的代價較高。另外一種方法是爲每一個測試需求設計一個單獨的測試用例，就可以不必考慮那些複雜的測試用例，但是這些相對簡單的測試用例發現缺陷的能力就會有所下降。

這裏有一個測試需求的實例：對一個哈希表的插入操作進行測試，有以下這些測試需求：

1）插入一個新的條目

2）插入失敗－條目已經存在

3）插入失敗－表已滿

4）哈希表在插入前爲空

這些就是測試需求，而非測試用例，因爲它們沒有對被插入元素進行描述。另外你也不能馬上就着手書寫用例，就好象軟件需求完成後不能立即進行編碼一樣。還需要對測試需求進行評審，確保正確和沒有需求遺漏。

這應該只是對測試需求的一個方面的理解

測試需求應該包含兩個方面的內容：

1、確定測什麼，就是上面這位仁兄所說。

2、測試對產品的需求，解決需要產品爲測試提供什麼特性，可以更好的去測試的問題，就是我們常說的可測試性需求。

第14帖【2004－5－30】：GUI測試

Roger S. Pressman

圖形用戶界面（GUI）對軟件測試提出了有趣的挑戰，因爲GUI開發環境有可複用的構件，開發用戶界面更加省時而且更加精確。同時，GUI的複雜性也增加了，從而加大了設計和執行測試用例的難度。因爲現在GUI設計和實現有了越來越多的類似，所以也就產生了一系列的測試標準。下列問題可以作爲常見GUI測試的指南：

窗口：

·窗口是否基於相關的輸入和菜單命令適當地打開？

·窗口能否改變大小、移動和滾動？

·窗口中的數據內容能否用鼠標、功能鍵、方向鍵和鍵盤訪問？

·當被覆蓋並重新調用後，窗口能否正確地再生？

·需要時能否使用所有窗口相關的功能？

·所有窗口相關的功能是可操作的嗎？

·是否有相關的下拉式菜單、工具條、滾動條、對話框、按鈕、圖標和其他控制可爲窗口使用，並適當地顯示？

·顯示多個窗口時，窗口的名稱是否被適當地表示？

·活動窗口是否被適當地加亮？

·如果使用多任務，是否所有的窗口被實時更新？

·多次或不正確按鼠標是否會導致無法預料的副作用？

·窗口的聲音和顏色提示和窗口的操作順序是否符合需求？

·窗口是否正確地被關閉？

第15帖【2004－5－31】：Client/Server測試

Roger S. Pressman

通常，客戶/服務器軟件的測試發生在三個不同的層次：

（1）個體的客戶端應用以“分離的”模式被測試--不考慮服務器和底層網絡的運行；

（2）客戶端軟件和關聯的服務器端應用被一起測試，但網絡運行不被明顯的考慮；

（3）完整的C/S體系結構，包括網絡運行和性能，被測試。

下面的測試方法是C/S應用中經常用到的：

應用功能測試--客戶端應用被獨立地執行，以揭示在其運行中的錯誤。

服務器測試--測試服務器的協調和數據管理功能，也考慮服務器性能（整體反映時間和數據吞吐量）。

數據庫測試--測試服務器存儲的數據的精確性和完整性，檢查客戶端應用提交的事務，以保證數據被正確地存儲、更新和檢索。

事務測試--創建一系列的測試以保證每類事務被按照需求處理。測試着重於處理的正確性，也關注性能問題。

網絡通信測試--這些測試驗證網絡節點間的通信正常地發生，並且消息傳遞、事務和相關的網絡交通無錯的發生。

第16帖【2004－6－1】：軟件質量

“每一個程序都能正確地做某件事，但是這並不是我們想要它作的事情。”這樣的軟件不能算一個質量好的軟件。

我們如何定義軟件質量呢？可以從不同的角度來看待軟件質量並對其定義，它們有一些共同點：強調軟件與得到了清晰描述的功能和性能需求的符合度、明顯的文檔標準以及被認爲是所有專業開發的軟件所具備的隱式特徵。

ISO9126從如下幾個方面來衡量軟件質量：功能性、可靠性、可用性、可維護性、效率、可移植性。

如下三個方面應該尤其被重視：

1、軟件需求是質量測度的基礎。需求符合性的缺乏也就是缺乏質量；

2、特定的過程定義了一套開發標準，用以指導軟件開發的方式。如果標準未能遵守，那麼缺少質量就幾乎是肯定的結論；

3、除了功能需求等顯示的需求外，要對非功能的隱式需求重視（例如，對好的可維護性的期望）。如果軟件符合其他顯式的需求，但是未能滿足隱式需求，軟件質量仍然是值得懷疑的。

軟件質量是一個多因素的複雜混合，這些因素隨着不同的應用和需要它們的用戶而變化。測試時需要根據一定的質量標準有針對性的進行測試。

第17帖【2004－6－2】系統測試方法之恢復測試

Roger S. Pressman

許多基於計算機的系統必須在一定的時間內從錯誤中恢復過來，然後繼續運行。在有些情況下，一個系統必須是可以容錯的，這就是說，運行過程中的錯誤不能使整個系統的功能都停止。在其他情況下，一個系統錯誤必須在一個特定的時間段之內改正，否則就會造成嚴重損失。

恢復測試是通過各種手段，讓軟件強制性地發生故障，然後來驗證恢復是否能正常進行的一種系統測試方法。如果恢復是自動的（由系統本身來進行的），重新初始化、檢查點機制、數據恢復和重啓動都要進行正確驗證。如果恢復是需要人工干預的，那麼要估算修復的平均時間是否在可以接受的範圍之內。

第18帖【2004－6－3】：系統測試方法之安全測試

Roger S. Pressman

任何管理敏感信息或者能夠對個人造成不正當傷害的計算機系統都是不正當或非法侵入的目標。侵入包括了範圍很廣的活動：只是爲練習而試圖侵入系統的黑客；爲了報復而試圖攻破系統的有怨言的僱員；還有爲了得到非法的利益而試圖侵入系統的不誠實的個人。

安全測試用來驗證集成在系統內的保護機制是否能夠在實際中保護系統不受到非法的侵入。引用Beizer的話來說：“系統的安全當然必須能夠經受住正面的攻擊--但是它也必須能夠經受住側面的和背後的攻擊。”

在安全測試過程中，測試者扮演着一個試圖攻擊系統的個人角色。測試者可以嘗試去通過外部的手段來獲取系統的密碼，可以使用可以瓦解任何防守的客戶軟件來攻擊系統；可以把系統“制服”，使得別人無法訪問；可以有目的地引發系統錯誤，期望在系統恢復過程中侵入系統；可以通過瀏覽非保密的數據，從中找到進入系統的鑰匙；等等。

只要有足夠的時間和資源，好的安全測試就一定能夠最終侵入一個系統。系統設計者的任務就是要把系統設計爲想要攻破系統而付出的代價大於攻破系統之後得到的信息的價值。

第19帖【2004－6－4】：系統測試方法之壓力測試

Roger S. Pressman

在較早的軟件測試步驟中，白盒和黑盒技術對正常的程序功能和性能進行了詳盡的檢查。壓力測試（Stree Testing）的目的是要對付非正常的情形。在本質上說，進行壓力測試的人應該這樣問：“我們能夠將系統折騰到什麼程度而又不會出錯？”

壓力測試是在一種需要反常數量、頻率或資源的方式下運行系統。例如，

（1）當平均每秒出現1個或2箇中斷的情形下，應當對每秒出現10箇中斷的情形來進行特殊的測試；

（2）把輸入數據的量提高一個數量級來測試輸入功能會如何響應；

（3）應當執行需要最大的內存或其他資源的測試用例；

（4）運行一個虛擬的操作系統中可能會引起大量的駐留磁盤數據的測試用例。

從本質上來說，測試者是想要破壞程序。

壓力測試的一個變種是一種被成爲是敏感測試的技術。在有些情況（最常見的是在數學算法中）下，在有效數據界限之內的一個很小範圍的數據可能會引起極端的甚至是錯誤的運行，或者引起性能的急劇下降，這種情形和數學函數中的奇點相類似。敏感測試就是要發現在有效數據輸入裏可能會引發不穩定或者錯誤處理的數據組合。

第20帖【2004－6－5】：系統測試方法之性能測試

Roger S. Pressman

在實時系統和嵌入式系統中，提供符合功能需求但不符合性能需求的軟件是不能被接受的。性能測試就是用來測試軟件在系統中的運行性能的。性能測試可以發生在各個測試階段中，即使是在單元層，一個單獨模塊的性能也可以使用白盒測試來進行評估，然而，只有當整個系統的所有成分都集成到一起之後，才能檢查一個系統的真正性能。

性能測試經常和壓力測試一起進行，而且常常需要硬件和軟件測試設備，這就是說，常常有必要的在一種苛刻的環境中衡量資源的使用（比如，處理器週期）。外部的測試設備可以監測測試執行，當出現情況（如中斷）時記錄下來。通過對系統的檢測，測試者可以發現導致效率降低和系統故障的原因。