軟體測試 - 方法

軟體測試可以使用不同的方法。本章簡要介紹了可用的方法。

黑盒測試

在不瞭解應用程式內部工作原理的情況下進行測試的技術稱為黑盒測試。測試人員對系統架構一無所知，也無法訪問原始碼。通常，在執行黑盒測試時，測試人員會透過提供輸入並檢查輸出與系統的使用者介面進行互動，而不知道輸入是如何以及在哪裡處理的。

下表列出了黑盒測試的優缺點。

優點	缺點
非常適合大型程式碼段，並且效率高。	覆蓋範圍有限，因為實際上只執行了選定的測試場景。
不需要訪問程式碼。	測試效率低下，因為測試人員對應用程式的瞭解有限。
透過清晰定義的角色，明確地區分了使用者的視角和開發人員的視角。	盲目覆蓋，因為測試人員無法針對特定的程式碼段或容易出錯的區域。
大量中等技能的測試人員可以在不瞭解實現、程式語言或作業系統的情況下測試應用程式。	測試用例的設計難度較大。

白盒測試是對程式碼內部邏輯和結構的詳細檢查。白盒測試也稱為**玻璃盒測試**或**開盒測試**。為了對應用程式執行**白盒**測試，測試人員需要了解程式碼的內部工作原理。

測試人員需要檢視原始碼，並找出哪個單元/程式碼塊的行為不正常。

下表列出了白盒測試的優缺點。

優點	缺點
由於測試人員瞭解原始碼，因此很容易找出哪種型別的資料可以有效地幫助測試應用程式。	由於需要熟練的測試人員來執行白盒測試，因此成本會增加。
有助於最佳化程式碼。	有時不可能檢視每個角落和縫隙以找出可能導致問題的隱藏錯誤，因為許多路徑將不會被測試。
可以刪除額外的程式碼行，這可能會引入隱藏的缺陷。	白盒測試難以維護，因為它需要諸如程式碼分析器和除錯工具之類的專用工具。
由於測試人員瞭解程式碼，因此在編寫測試場景期間可以獲得最大程度的覆蓋率。

灰盒測試是一種在對應用程式的內部工作原理了解有限的情況下測試應用程式的技術。在軟體測試中，“瞭解得越多，越好”這句話在測試應用程式時具有很大的分量。

掌握系統領域總是能讓測試人員比那些領域知識有限的人更有優勢。與僅測試應用程式使用者介面的黑盒測試不同，在灰盒測試中，測試人員可以訪問設計文件和資料庫。擁有這些知識，測試人員可以在制定測試計劃時準備更好的測試資料和測試場景。

優點	缺點
在儘可能的情況下，提供黑盒測試和白盒測試的組合優勢。	由於無法訪問原始碼，因此檢查程式碼和測試覆蓋率的能力受到限制。
灰盒測試人員不依賴於原始碼；相反，他們依賴於介面定義和功能規範。	如果軟體設計師已經運行了測試用例，則測試可能會冗餘。
基於有限的可用資訊，灰盒測試人員可以設計出優秀的測試場景，尤其是在通訊協議和資料型別處理方面。	測試每個可能的輸入流是不現實的，因為這將花費不合理的時間；因此，許多程式路徑將不會被測試。
測試是從使用者的角度而不是設計人員的角度進行的。

下表列出了區分黑盒測試、灰盒測試和白盒測試的要點。

黑盒測試	灰盒測試	白盒測試
不需要了解應用程式的內部工作原理。	測試人員對應用程式的內部工作原理了解有限。	測試人員完全瞭解應用程式的內部工作原理。
也稱為閉合盒測試、資料驅動測試或功能測試。	也稱為半透明測試，因為測試人員對應用程式內部的瞭解有限。	也稱為透明盒測試、結構測試或基於程式碼的測試。
由終端使用者以及測試人員和開發人員執行。	由終端使用者以及測試人員和開發人員執行。	通常由測試人員和開發人員執行。
測試基於外部期望 - 應用程式的內部行為未知。	測試基於高階資料庫圖表和資料流圖表。	內部工作原理完全已知，測試人員可以相應地設計測試資料。
它非常詳盡且最不費時。	部分費時且詳盡。	最詳盡且最費時的測試型別。
不適合演算法測試。	不適合演算法測試。	適合演算法測試。
這隻能透過試錯法來完成。	如果已知，可以測試資料域和內部邊界。	可以更好地測試資料域和內部邊界。

列印頁面