軟件測試的藝術(原書第3版)

軟件測試的藝術(原書第3版) Glenford J.Myers Tom Badgett Corey Sandler 53個想法 ◆ 序言 >> 如何確保所開發的所有軟件做了其應該做的，並且同樣重要的是，未做其不應該做的？ ◆ 第1章 一次自評價測試 >> 所謂軟件測試，就是一個過程或一系列過程，用來確認計算機代碼完成了其應該完成的功能，不執行其不該有的操作。 ◆ 2.1 軟件測試的心理學 >> 如果我們的目標在於證明程序中存在錯誤，我們設計的測試數據就有可能更多地發現問題 >> 軟件測試是一個破壞性的過程，甚至是一個“施虐”的過程 >> 所謂“不成功的”測試，僅指未能適當地對程序進行檢查，在大多數情況下，未能找出錯誤的測試被認爲是“不成功的”，這是因爲認爲軟件中不包含錯誤的觀點基本上是不切實際的。 ◆ 2.2.1 黑盒測試 >> 黑盒測試是一種重要的測試策略，又稱爲數據驅動的測試或輸入/輸出驅動的測試。 ◆ 2.2.2 白盒測試 >> 白盒測試或稱邏輯驅動的測試，允許我們檢查程序的內部結構。 ◆ 2.3 軟件測試的原則 >> 原則1：測試用例中一個必需部分是對預期輸出或結果的定義。 >> 克服這種傾向的一種方法，就是通過事先精確定義程序的預期輸出，鼓勵人們對所有的輸出進行仔細檢查。 >> 原則2：程序員應當避免測試自己編寫的程序。 >> 當程序員“建設性”地設計和編寫完程序之後，很難讓他突然改變視角以一種“破壞性”的眼光來審查程序。 >> 原則3：編寫軟件的組織不應當測試自己編寫的軟件。 >> 原則4：應當徹底檢查每個測試的執行結果。 >> 原則5：測試用例的編寫不僅應當根據有效和預期的輸入情況，而且也應當根據無效和未預料到的輸入情況。 >> 原則6：檢查程序是否“未做其應該做的”僅是測試的一半，測試的另一半是檢查程序是否“做了其不應該做的”。 >> 原則7：應避免測試用例用後即棄，除非軟件本身就是一個一次性的軟件。 >> 保留測試用例，當程序其他部件發生更動後重新執行，這就是我們所謂的“迴歸測試”。 >> 原則8：計劃測試工作時不應默許假定不會發現錯誤。 >> 原則9：程序某部分存在更多錯誤的可能性，與該部分已發現錯誤的數量成正比。 >> 假如某個程序由兩個模塊、類或子程序A和B組成，模塊A中已經發現了五個錯誤，而模塊B中僅僅找到了一處錯誤。如果模塊A所經過的測試並不是故意設計得更爲嚴格，那麼該原則告訴我們，模塊A與模塊B相比，存在更多錯誤的可能性要大。 >> 錯誤總是傾向於聚集存在，而在一個具體的程序中，某些部分要比其他部分更容易存在錯誤 ◆ 第3章 代碼檢查、走查與評審 過於心急而引入新的缺陷 >首先，人們普遍認識到錯誤發現得越早，改正錯誤的成本越低，正確改正錯誤的可能性也越大。其次，程序員在開始基於計算機的測試時似乎要經歷一個心理上的轉變。從內部產生的壓力似乎會急劇增長，併產生一個趨勢，要“儘可能快地修正這個缺陷”。由於這些壓力的存在，程序員在改正某個由基於計算機測試發現的錯誤時所犯的失誤，要比改正早期發現的問題時所犯的失誤更多一些。 >> 首先，人們普遍認識到錯誤發現得越早，改正錯誤的成本越低，正確改正錯誤的可能性也越大。其次，程序員在開始基於計算機的測試時似乎要經歷一個心理上的轉變。從內部產生的壓力似乎會急劇增長，併產生一個趨勢，要“儘可能快地修正這個缺陷”。由於這些壓力的存在，程序員在改正某個由基於計算機測試發現的錯誤時所犯的失誤，要比改正早期發現的問題時所犯的失誤更多一些。 ◆ 3.1 代碼檢查與走查 >> 代碼檢查、走查以及可用性測試是三種主要的人工測試方法。 每月月底進行一次桌面檢查 >代碼檢查與走查是對過去桌面檢查過程（在提交測試前由程序員閱讀自己程序的過程）的改進。與原方法相比，代碼檢查與走查更爲有效，同樣是因爲在實施過程中，除了軟件編寫者本人，還有其他人蔘與進來。 >> 程序中的錯誤總數始終是未知的。 >> 然而，一些測試人員在使用了人工方法之後發現，對於某些特定類型的錯誤，人工方法比基於計算機的方法更有效，而對於其他錯誤類型，基於計算機的方法更有效。這就意味着，代碼檢查/走查與基於計算機的測試是互補的。缺少其中任何一種，錯誤檢查的效率都會降低。 ◆ 3.2.2 檢查議程與注意事項 >> 這份錯誤清單也要進行分析、歸納，用以提煉錯誤列表，以便提高以後代碼檢查的效率 ◆ 3.2.3 對事不對人，和人有關的注意事項 >> 大多數人建議應對代碼檢查的結果進行保密，僅限於參與者範圍內部 ◆ 3.2.4 代碼檢查的衍生功效 >> 其一，程序員通常會得到編程風格、算法選擇及編程技術等方面的反饋信息。其二，其他參與者也可以通過接觸程序員的錯誤和編程風格而同樣受益匪淺。 ◆ 3.3.4 比較錯誤 >> 6.在二進制的計算機上，是否有用二進制表示的小數或浮點數的比較運算？ ◆ 3.3.6 接口錯誤 所有文檔裏的數字都要有單位 >3.實參的量綱是否與對應形參的量綱相匹配 >> 3.實參的量綱是否與對應形參的量綱相匹配？ ◆ 3.5 桌面檢查 >> 它是一個完全沒有約束的過程 ◆ 4.1 白盒測試 通過系統測試來覆蓋 >因此，條件覆蓋或判定/條件覆蓋準則不一定會發現邏輯表達式中的錯誤 >> 因此，條件覆蓋或判定/條件覆蓋準則不一定會發現邏輯表達式中的錯誤 ◆ 4.2.1 等價劃分 有效等價類可以一條測試用例測試多個目的，無效等價類一條測試用例儘量只用於測試一個目的。 >1.爲每個等價類設置一個不同的編號。 2.編寫新的測試用例，儘可能多地覆蓋那些尚未被涵蓋的有效等價類，直到所有的有效等價類都被測試用例所覆蓋（包含進去）。 3.編寫新的用例，覆蓋一個且僅一個尚未被涵蓋的無效等價類，直到所有的無效等價類都被測試用例所覆蓋。 用單個測試用例覆蓋無效等價類，是因爲某些特定的輸入錯誤檢查可能會屏蔽或取代其他輸入錯誤檢查。舉例來說，如果規格說明規定了“請輸入書籍類型（硬皮、軟皮或活頁）及數量（1～999）”，代表兩個錯誤輸入（書籍類型錯誤，數量錯誤）的測試用例“XYZ 0”，很可能不會執行對數量的檢查，因爲程序也許會提示“XYZ是未知的書籍類型”，就不檢查輸入的其餘部分了。 ◆ 第6章 更高級別的測試 >> 首先，我們可以使軟件開發過程更加精密，以防其中出現很多錯誤；其次，在每個階段結束時可以引入一個獨立的驗證過程，在進入下一個階段之前儘可能多地發現問題。 ◆ 8.4 回溯法調試 >> 換句話說，從程序產生不正確結果（如打印了不正確的數據）的地方開始，從該處觀察到的結果推斷出程序變量應該是些什麼值。在頭腦中，從這個位置開始逆向執行程序，重複使用“如果程序在此處的狀態是這樣的，那麼程序在上面位置的狀態就必然是那樣的”過程，就能很快定位出錯誤。 ◆ 8.5 測試法調試 >> 供測試的測試用例，其目的是暴露出以前尚未發現的錯誤；供調試的測試用例，其目的是提供有用的信息，供定位某個被懷疑的錯誤之用。 ◆ 8.6.1 定位錯誤的原則 >> 1.動腦筋 >> ·讓自己置身於安靜、沒有干擾的環境之中，這些干擾通常指同事的談話聲、打電話、手機鈴聲以及其他潛在的干擾因素，確保這些不會分散你的注意力。·不看代碼，在腦海中思考程序是怎麼設計的，並思考表現異常的地方本應該是什麼樣的。·把注意力集中在思考程序正確行爲的過程上，並想象那些可能導致錯誤設計的代碼實現方式。 >> 2.如果遇到了僵局，就留到稍後解決 第二天寫的代碼明顯比昨晚加班寫的代碼質量高 >如果在合理時間內（也許小型程序爲30分鐘，大一點的程序爲幾個小時），我們還不能定位某個問題，就丟開它，做些其他的事情，因爲思維的效率開始明顯下降。 >> 如果在合理時間內（也許小型程序爲30分鐘，大一點的程序爲幾個小時），我們還不能定位某個問題，就丟開它，做些其他的事情，因爲思維的效率開始明顯下降。 >> 3.如果遇到了困境，就把問題描述給其他人聽與其他人交談可能會幫助我們發現一些新的東西。事實上，經常是僅僅將問題描述給一個好的傾聽者時，我們就會突然找到問題的解決之道，而無須傾聽者提供任何幫助。 ◆ 8.6.2 修改錯誤的技術 >> 1.存在一個缺陷的地方，很有可能還存在其他缺陷 >> 2.應糾正錯誤本身，而不僅是其症狀 >> 3.正確糾正錯誤的可能性並非100% >> 我們永遠也不要假設爲糾正錯誤而增加到程序中的代碼是正確的。用新的語句替換原來的語句，這種修改要遠比程序中原先的代碼更易發生錯誤。 >> 4.隨着程序規模的增加，正確修改錯誤的可能性反而降低 >> 5.應意識改正錯誤會引入新錯誤的可能性 >> 6.修改錯誤的過程也是臨時回到設計階段的過程

不懂軟件開發，也不懂軟件測試。這個週末快速學習了本書。從幾個方面都值得推薦：一，項目管理，尤其項目複雜到一定程度，而質量的重要性又生死攸關時；二，對於複雜技術的質量的管控，這點可以稍微展開一點，近年來幾個概念非常熱，包括元宇宙，數字孿生，工業軟件，甚至大模型。這幾個概念，都涉及對複雜的物理世界的建模。建模的質量，受限於數據的可獲取性，開發人員的知識結構和能力，大模型對常識和因果關係的欠缺等等因素。從驗證的角度，確保模型的缺陷及早發現，從而獲得質量的提升，是非常關鍵的一環。本書從相對成熟的軟件測試的領域提煉出的方法論，技術，和流程，對於上述的更廣泛的事項的質量提升，具有很強的參考意義，值得進一步細讀

舉例的編程語言有點過時，如cobol語言，但是測試知識還是值得一看。

很基礎的一本書，系統例子也有點老，不過測試方法論真是幾十年沒變了。

很經典的軟件測試書籍。 用通俗易懂的語言表達測試場景和測試方法。對軟件測試感興趣的朋友可以閱讀學習。

在閱讀《軟件測試藝術》這本書的過程中，我深感其不僅是一本關於技術層面的書籍，更是一本關於思維方式和方法的藝術指南。這本書從多個角度和層面展示了軟件測試的重要性和複雜性，同時也揭示瞭如何運用智慧和策略來應對軟件測試中的各種挑戰。 書中提到的一個觀點讓我印象深刻，那就是軟件測試並不僅僅是找出錯誤，更是一種對軟件質量的全面評估。這種評估需要測試人員具備深入的技術知識和敏銳的洞察力，以便在複雜的軟件系統中發現問題並提出改進建議。這讓我意識到，作爲一名軟件測試人員，我們不僅要具備紮實的技術基礎，還需要擁有一種獨特的思維方式和洞察力，以應對不斷變化的軟件環境和需求。 在閱讀過程中，我也深刻體會到了測試用例的重要性。測試用例是測試工作的基礎，其質量直接影響到測試的效果和效率。書中提到的關於測試用例的編寫、評審和執行的策略和方法，讓我更加明白瞭如何編寫高質量的測試用例，並如何在測試過程中不斷優化和完善它們。同時，我也認識到了測試用例編寫中可能存在的問題，如冗餘、錯誤或缺失等，這些問題都可能影響到測試的質量和效果。 此外，書中還提到了許多關於軟件測試的理念和方法，如黑盒測試、白盒測試、自動化測試等。這些理念和方法不僅讓我對軟件測試有了更深入的瞭解，也爲我提供了在實際工作中解決問題的思路和方法。同時，我也認識到了不同測試方法之間的優缺點和適用範圍，這讓我能夠更加靈活地選擇和應用不同的測試方法，以適應不同的測試需求和環境。 總的來說，《軟件測試藝術》這本書不僅提供了豐富的技術知識和實踐經驗，更重要的是它教會了我如何以一種藝術的眼光來看待軟件測試工作。這本書讓我深刻認識到，軟件測試不僅是一項技術工作，更是一種需要智慧和策略的藝術。通過學習和實踐書中的理念和方法，我相信我能夠更好地應對軟件測試中的各種挑戰和問題，爲軟件質量的提升貢獻自己的力量。

本書主要講方法論和經驗總結，本人看次數2次了，5年前和現在。本書適合有一定經驗的測試或者開發人員看，可以查漏補缺，糾正錯誤的測試思想，但不適合小白，5年前本人沒有生產經驗很難感同身受，看的打瞌睡，但現在看能引發很多思考。

快速翻閱看完了，總體來看比較陳舊，同時結合實際測試工作中內容較少，收穫較小。 不過能看出，上次看的測試架構師一書中有參考此內容。

讓我收穫很多 以後可以多複習一下

「202603 —— 軟件測試的藝術」 基礎概念解釋的很詳盡，對初學者很友好的一本入門測試書📖