《軟件測試的藝術（原書第三版）》

 

 

本書從第1版付梓到現在已經30余年，是軟件測試領域的經典著作。本書結構清晰、講解生動活潑，簡明扼要地展示了久經考驗的軟件測試方法和智慧。

作 者：（美）梅耶（Myers, G. J.） 等著，張曉明，黃琳 譯

出 版 社：機械工業出版社

出版時間：2012年3月

市圖書簽：TP311.55 481 000837340

譯者序

序言

前言

第1章 一次自評價測試

10分鍾編寫測試用例：

三角形測驗評價：

　　以我們的經驗來看，高水平的專業程序員平均得分僅7.8分（滿分14分）。

　　【筆者本次得分13分，缺少內容用紅色標注了。】

　　測試用例即使滿足了上述條件，也不能確保找出所有可能的錯誤。

　　這個測驗說明，即使測試這樣一個小程序，也不是一件容易的事情。因此，想象一下測試一個十萬行代碼的交通管理系統、一個編譯器，甚至一個工資管理程序的難度。

第2章 軟件測試的心理學和經濟學

2.1 軟件測試的心理學

　　這不是微妙了文字游戲，理解軟件測試的真正定義，對於成功地進行軟件測試有很大的影響。人類行為總是傾向於具有高度目標性，確立一個正確的目標有着重要的心理學影響。

    它暗示了軟件測試是一個破壞性的過程，甚至是一個“施虐”的過程，這就說明為什么大多數人都覺得它困難。這種定義可能違反了我們的願望；所幸的是，我們大多數人總是對生活充滿建設性而不是破壞性的願景。大多數人都本能的傾向於創造事物，而不是將事物破壞。它還暗示了對於一個特定的程序，應該如何設計測試用例（測試數據），哪些人應該而哪些人又不應該執行測試。

==================== 華麗的分割線 ========================

　　增進對軟件測試定義的理解，分析一下“成功的”和“不成功的”：

　　類比一下病人看醫生的情況，病人因為身體不適而去看醫生。如果以上對病人進行了一些檢查和化驗，卻沒有診斷出任何病因，我們就不會認為檢查和化驗是“成功的”，因為病人支付了昂貴的費用和精力，而病狀卻依然如故。病人會因此而質疑醫生的診斷能力。但是，如果醫生診斷出病人是胃潰瘍，那么這次檢測就是“成功的”，醫生可以開始進行相應的治療。

　　類推到軟件測試中來，能發現錯誤的測試用例不太可能被認為是“不成功的”，也就是說，能發現錯誤就證明他是值得設計的。“不成功的”測試用例，會看到程序輸出正確的結果而沒有發現任何錯誤。

==================== 華麗的分割線 ========================

　　考慮一下第一章中的“三角形測試程序”，即使我們證明了程序能夠識別不規則三角形、等腰三角形、等邊三角形，但是在完成了不應執行的任務后（例如：將判斷三邊1、2、3為一個不規則三角形或將三邊0、0、0說成等邊三角形），程序仍然是錯的。

==================== 華麗的分割線 ========================

總結一下：

• 軟件測試更適宜被視為視圖發現程序中錯誤（假設其存在）的破壞性的過程。

• 一個成功的測試用例，通過誘發程序發生錯誤，可以在這個方向上促進軟件質量的改進。

• 最終我們還是要通過軟件測試來建立某種程度的信心：

• 軟件做了其應該做的，未做其不應該做的。

• 通過對錯誤的不斷研究是實現這一目的的最佳途徑。

2.2 軟件測試的經濟學

　　一般來說，要發現程序中的“所有”錯誤也是不缺實際的。這個基本的問題反過來暗示出軟件測試的經濟學問題、測試人員對被測軟件的期望以及測試用例的設計方式。

　　為了應對測試經濟學調整，應該在開始之前建立某些策略。黑盒測試和白盒測試是兩種最普遍的策略。

2.2.1 黑盒測試

　　黑盒測試是一種重要的測試策略，又稱為數據驅動的測試或輸入-輸出驅動的測試。

　　這種方法中，測試數據完全來源於軟件規范（換句話說，不需要去了解程序的內部結構）。

　　如果想用這種方法來發現程序所有錯誤，判定標准就是“窮舉輸入測試”，即將所有可能的輸入條件都作為測試用例。

　　若要窮舉測試第一章的“三角形程序”，實際要創建無限的測試用例。如果程序中使用數據存儲，不僅要測試所有有效和無效的事務處理，還要測試所有可能的事物處理順序。

　　上述說明，“窮舉輸入測試”是無法實現的。一方面是我們無法測試一個程序以確保它是無錯的；二是軟件測試中需要考慮的是一個基本問題是軟件測試的經濟學。測試投入的目標在於通過有線的測試用例，最大限度的提高發現問題的數量，以取得最好的測試效果。

@ 對程序做些合理但非無懈可擊的假設，這種思路將形成本書的第四章中的軟件測試用例設計策略的部分方法。

2.2.2 白盒測試

　　另一種測試策略稱為白盒測試或稱邏輯驅動的測試，允許我們檢查程序的邏輯結構，從中獲取測試數據。

　　遺憾的是，常常忽略了程序的規范。

　　針對這種測試策略進行“窮舉路徑測試”，即如果使用測試用例執行了程序中所有可能的控制流程路徑，那么程序有可能得到了完全測試。

　　“窮舉路徑測試即完全的測試”論斷存在兩個問題：

1. 程序中不同邏輯路徑的數量可能達到天文數字。
2. 雖然可以測試程序中的所有路徑，但是它可能仍然存在着錯誤：
   • 單純的窮舉路徑測試，不能保證程序符合其設計規范（例如升序、降序效果反了）。
   • ……不能發現缺少哪些必須路徑。
   • ……可能不會暴露數據敏感錯誤。

　　總之，盡管窮舉輸入測試要強於窮舉路徑測試，但兩者都不是有效的方法，因為兩者都不可行。也許有一種，將黑盒測試和白盒測試的要素結合起來，行程一個合理並不十分完美的測試策略。

@本書第四章將深入討論。