《軟件測試的藝術》讀書筆記 - 1

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

 

 

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

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

出 版 社：機械工業出版社

出版時間：2012年3月

市圖書簽：TP311.55 481 000837340

---

譯者序

序言

前言

第1章 一次自評價測試

 

10分鍾編寫測試用例：

序號	用例	預計輸出
1	a 或 b 或 c = 0	不成立
2	a 或 b 或 c < 0	不成立
3	a = b = c 且 > 0	等邊三角形
4	c ≥ a + b （×3，abc相互顛倒）	不成立
5	a = b 且 c < a + b （×3，abc相互顛倒）	等腰三角形
6	c < a + b （×3，abc相互顛倒）	不規則三角形
7	a、b、c 錄入非Int類型字符（×6，abc相互顛倒）	不成立
8	a、b、c 只錄其中入1個或兩個值	不成立

 

三角形測驗評價：

 

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

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

 

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

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

---

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

2.1 軟件測試的心理學

“軟件測試就是證明軟件不存在錯誤的過程。”

“軟件測試的目的在於證明軟件能夠正確完成其預定的功能。”

“軟件測試就是證明‘軟件做了其應該做的’的過程。”

———— 這些定義都本末倒置的。

 

　　每當測試一個程序時，應當想到要為程序增加一些價值。通過測試來增加程序的價值。是指測試提高了程序的可靠性或質量。提高程序的可靠性，是指找出並最終修改了程序的錯誤。

　　因此，不要只是為了證明程序能夠正確運行而去測試程序；相反，應該一開始就假設程序中隱藏着錯誤（這種假設幾乎都是成立），然后測試程序，發現盡可能多的錯誤。

 

“測試是為了發現錯誤而執行程序的過程”。

———— 如此定義更為合適。

 

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

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

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

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

當項目經理總結測試用例執行結果時，將沒有發現錯誤的測試過程稱為一次“成功的測試”，而將發現了某個新錯誤的測試成為“不成功的測試”。

———— 這又是一次本末倒置。

 

 

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

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

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

 

諸如“軟件測試就是證明‘軟件做了其應該做的’的過程。”
此類定義所帶來的問題是：

 

　　 程序及時能夠完成預期功能，也仍然可能隱藏錯誤。也就是說，程序在沒有實現預期功能時，其錯誤是清晰地顯現出來的；如果程序做了其不應該做的，這同樣是一個錯誤。

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

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

總結一下：

 

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

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

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

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

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

 

---

 

2.2 軟件測試的經濟學

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

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

2.2.1 黑盒測試

 

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

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

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

 

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

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

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

 

 

2.2.2 白盒測試

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

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

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

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

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

 

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

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