轉載自：https://www.jianshu.com/p/a33069eed3a9
本文主要記錄的是《軟件測試的藝術》一書的讀書筆記以及相關的知識，歡迎大家提出自己的觀點，進行討論與分享。持續更新...
1，前言
1.軟件測試爲什麼變得更加困難？湧現出大量的編程語言/操作系統以及硬件平臺等。
2.所謂軟件測試，就是一個過程或一系列過程，用來確認計算機代碼完成了其該完成的功能，不執行其不該有的操作。軟件應當是可預測且穩定的，不會給用戶帶來意外驚奇。
2，軟件測試的心理學和經濟學
2.1.軟件測試的心理學
人類行爲總是傾向於具有高度目標性，確立一個正確的目標有着重要的影響。
1.我們每當要測試一個程序時，應當想到要爲程序增加一些價值。而通過測試來增加程序的價值是指提高程序的可靠性或質量，提高可靠性是指找出並最終修改程序的錯誤。
2.定義：測試是爲發現錯誤而執行程序的過程。並且軟件測試是一個破壞性的過程，甚至是一個施虐的過程。
3.不成功的測試用例，會看到程序輸出正確的結果而沒發現任何錯誤。？？？測試用例沒發現錯誤就認爲該測試用例是不成功的測試用例嗎？
4.軟件測試更適宜被視爲試圖發現程序中錯誤（假設其存在）的破壞性的過程。軟件做了其應該做的，未做其不應該做的。
2.2 軟件測試的經濟學
窮舉測試是不切實際的。
1. 黑盒測試又被稱爲數據驅動的測試或輸入/輸出驅動的測試。窮舉測試用例不可能實現。
2.測試投入的目標在於通過有限的測試用例，最大限度地提高發現問題的數量，以取得好的測試效果。
2.白盒測試又稱爲邏輯驅動的測試。
3.窮舉路徑測試也並非是完全的測試。第一，即使窮舉，也不能保證程序符合其設計規範，比如編寫升序排序卻寫成降序。第二，程序可能會因爲缺少某些路徑而存在問題。第三，窮舉路徑測試可能不會暴露數據敏感錯誤。
2.3 軟件測試的原則
1.測試用例中一個必須部分是對預期輸出或結果的定義。
測試用例包含兩個部分：1，對程序輸入數據的描述；2，對程序在上述輸入數據下的正確輸出結果的精確描述。
2.程序員應當避免測試自己編寫的程序。
3.編寫軟件的組織部應當測試自己的編寫的軟件。
4.應當徹底檢查每個測試的結果。
5.測試用例的編寫不僅應當根據有效和預期的輸入情況，而且也應當根據無效和未預料到的輸入情況。
6.檢查程序是否“未做其應該做的”僅是測試的一般，測試的另一半是檢查程序是否“做了不應該做的”。
7.應避免測試用例用後即棄，除非軟件本身就是一個一次性的軟件。
對程序的更改容易導致程序先前可以執行的部分發生故障，而這種故障是不容易被發現的，保留測試用例用作迴歸測試。
8.計劃測試工作時不應默許假定不會發現錯誤。
9.程序某部分存在更多錯誤的可能性與該部分已發現錯誤的數量成正比。
10.軟件測試是一項極富創造性，極具智力挑戰的工作。
3.代碼檢查、走查與評審
人工測試：非基於計算機測試的過程，在程序開始編碼之後，基於計算機的測試開始之前進行。有代碼檢查，代碼走查，桌面檢查，同行評審以及可用性測試。
3.1 代碼檢查與走查
1.代碼檢查和走查都需要人們組成一個小組來閱讀或者直觀檢查特定的程序，進行頭腦風暴，目標是找出錯誤，但不是改正錯誤。換句話說是測試而不是調試。
2.代碼走查的另一個優點是一旦發現錯誤通常就能在代碼中對其進行精確定位，這就降低了調試的成本。
3.代碼檢查和走查通常會有效的查出30%-70%的邏輯設計和編碼錯誤，和基於計算機的測試是互補的。
3.2 代碼檢查
1.通常四個人：協調人員（非編碼人員），編碼人員，測試專家等。
2.代碼檢查要將注意力集中在發現錯誤上，而不是糾正錯誤。
3.對事不對人
4.代碼檢查可以提升編程人員的編碼技術
5.代碼檢查錯誤列表：數據引用錯誤、數據聲明錯誤、運算錯誤、比較錯誤、控制流錯誤、接口錯誤、輸入/輸出錯誤、其他檢查
3.3 代碼走查
跟代碼檢查相似，但規程稍微不同，錯誤檢查技術也不一樣。
走查小組建議包括：一個經驗豐富的程序員，一個程序設計語言專家，一個程序員新手（可以給出新穎不帶偏見的觀點），最終維護程序的人員，一位來自其他不同項目的人員，一位來自該軟件編程小組的程序員。
3.4 桌面檢查
一個人閱讀程序，對照錯誤檢查表檢查程序，對程序推演測試數據。
3.5 同行評審
讓程序員對自身的編程技術進行自我評價。
4.測試用例的設計
由於成本和時間的約束，軟件測試最關心的問題是：在所有可能的測試用例中，哪個子集最有可能發現最多的錯誤？
4.1 白盒測試
白盒測試關注的是測試用例執行的程度或覆蓋程序邏輯結構（源代碼）的程度。
邏輯覆蓋測試：
1.語句覆蓋：程序中的每條語句至少被執行一次。
2.判定（分支）覆蓋：使得每一個判斷都至少有一個爲真和爲假的輸出結果。
3.條件覆蓋：確保將一個判斷中的每個條件的所有可能的結果至少執行一次。
4.判定/條件覆蓋：將一個判斷中的每個條件的所有可能的結果至少執行一次，將每個判斷的所有可能的結果至少執行一次，將每個入口點都至少調用一次。
5.多重條件覆蓋：將每個判定中的所有可能的條件結果的組合，以及所有的入口點都至少執行一次。
4.2 黑盒測試
1.等價類劃分：確定等價類->生成測試用例。等價類劃分是一個啓發式的過程，需要根據實際情況進行劃分，但一般情況下要劃分爲兩個不同的組：有效等價類和無效等價類。(可以參考一些等價類劃分的指導原則）
2.邊界值分析：考慮邊界值分析會獲得更高的測試回報率。邊界值分析不僅要考慮輸入空間的邊界值，還要考慮輸出空間的的邊界值。（參考一些通用指南和規則）
3.因果圖分析：因果圖有助於用一個系統的方法選擇出高效的測試用例集，還可以指出規格說明的不完整和不明確之處。是根據條件的組合生成測試用例的系統性的方法，將規格說明轉換爲一個布爾邏輯網絡。
確定規格說明中的因果關係，因指一個明確的輸入條件或輸入條件的等價類，果指一個輸出條件或系統轉換（輸入對程序或系統狀態的延續影響）
4.錯誤猜測：利用直覺和經驗猜測出錯的可能類型，然後編寫測試用例還暴露這些錯誤。
4.3 測試策略
1.如果規格說明裏麪包含條件組合的情況，應首先使用因果分析方法
2.在任何情況下都應該使用邊界值分析方法，對輸入和輸出邊界都要進行測試
3.應該爲輸入和輸出確定有效和無效等價類，必要的情況下對上面的測試用例進行補充
4.使用錯誤猜測技術增加更多的測試用例
5.針對上述的測試用例集檢查程序的邏輯結構，應考慮使用邏輯覆蓋準則
5.模塊（單元）測試
模塊測試中測試用例的設計過程：使用一種或多種白盒測試方法分析模塊的邏輯，然後使用黑盒測試方法對照模塊的規格說明以補充測試用例。它是大規模的白盒測試。
5.1 增量測試
1. 驅動模塊：用來將測試用例驅動或傳輸到被測模塊中。
2.樁模塊：測試上層模塊時用來模擬下層模塊的的模塊。
3.自頂向下測試：缺點：必須開發樁模塊，創建測試環境可能很難，甚至無法執行...
4.自底向上測試：缺點：必須開發驅動模塊，知道最後一個模塊添加進去，程序才形成一個整體。
5.2 工具
單元測試有很多測試用具，最出名的就是xUnit，這本書沒講。
6.更高級別的測試
當程序無法實現其最終用戶要求的合理功能時，就發生了一個錯誤。
根據軟件開發的過程，對應的測試是模塊測試、集成測試、功能測試、系統測試、驗收測試和安裝測試。
6.1 功能測試
1.功能測試是一個試圖發現程序與其外部規格說明之間存在不一致的過程。外部規格說明是一份從最終用戶角度對程序行爲的精確描述。
2.功能測試通常是一項黑盒操作，等價類劃分，邊界值分析，因果圖分析和錯誤猜測很適合功能測試。
6.2 系統測試
系統測試目的：將系統或程序與其初始目標進行比較，也就是說比較程序、程序目標和用戶文檔之間的不一致性。
1. 能力測試：逐條語句地檢查目標文檔，判斷程序是否滿足。（利用好問題清單）
2.容量測試：使程序經受大容量數據的檢驗。目的是爲了證明程序不能處理目標文檔中規定的數據容量。（考慮到該測試需要耗費大量的資源，所以不可進行過多的容量測試，但每個程序至少應該進行幾次容量測試）
3.強度測試：使程序承受高負載或強度的檢驗，所謂高強度是指在很短的時間間隔內達到的數據或操作的數量峯值。（有些也叫做壓力測試）
4.可用性測試：又叫用戶體驗測試，通過發動最終用戶在真是環境下對應用程序進行測試。
5.安全性測試：設計測試用例來突破程序安全檢查的過程。
6.性能測試：測試軟件在特定負載和配置環境下程序的響應時間和吞吐率不滿足要求。
7.存儲測試：設計測試用例來證明軟件的存儲目標（內存或輔助存儲）沒有達到。
8.配置測試：測試軟件在不同配置環境下（操作系統，瀏覽器等）程序不同的反應。
9.兼容性/轉換測試：測試軟件在不同版本或者環境下的反應。
10.安裝測試：發現軟件在安裝過程中出現的各種問題。
11.可靠性測試：可靠性測試是爲了提高軟件的可靠性，如果軟件的目標中包含了對可靠性的特別描述，就必須設計專門的可靠性測試。
12.可恢復性測試：證明系統的恢復機制不能夠正確發揮作用。恢復機制是當系統發生故障時，如何從程序錯誤、硬件失效和數據錯誤中恢復過來。
13.服務/可維護性測試：測試軟件的服務和可維護性目標。
14.文檔測試：檢車用戶文檔的正確性，主要方法是根據文檔來確定系統測試用例的形式，用戶文檔作爲審查的對象。
15.過程測試：對已規定的人工過程（如系統操作員、數據庫管理員或最終用戶的操作過程進行測試）
16.系統測試的執行：不能由程序員來進行測試；不能由該程序開發的機構來執行測試。執行系統測試的人思考問題的方式必須與最終用戶相同，必須充分了解最終用戶的態度和應用環境以及程序的使用方式。
6.3驗收測試
將程序與其最初的需求及最終用戶當前的需要進行比較的過程。通常由程序的客戶或最終用戶來進行，但明智的開發者會引導客戶在開發過程和產品發佈之前進行用戶測試。
6.4測試的計劃與控制
一個良好的測試計劃應該包括：目標、結束準則、進度、責任、測試用例庫及標準、工具、計算機時間、硬件配置、集成、跟蹤步驟、調試步驟、迴歸測試。
6.5測試結束準則
1.(不是最佳)測試用例來源於(1)滿足多重條件覆蓋準則，(2)對模塊接口規格說明進行邊界值分析，產生的多有測試用例最終都是不成功的。
2.(也許是最有價值的準則)以確切的數量來描述結束測試的條件。
3.(涉及到許多判斷和直覺)在測試過程中記錄每個單位時間內發現的錯誤的數量，通過檢查統計曲線的形狀，常常可以決定究竟是繼續該階段的測試還是結束它並來時下一測試階段。
最佳的可能是三種的組合。
7.可用性（用戶體驗）測試
可用性就像軟件的臉蛋。
7.1可用性測試的基本要素
1.是否考慮到最終用戶的理解力、教育背景以及環境壓力。
2.程序的輸出是否有意義、沒有侮辱性的詞語以及是否含糊不清？
3.錯誤診斷的提示信息是否清晰易懂還是需要計算機博士纔可讀懂？
4.用戶界面上是否保持與概念一致、內部的連貫性、語法的一致性？是否符合約定的使用習慣/語義和句法規律、格式、樣式以及縮寫習慣？
5.需要高精確性和準確度的軟件系統是否提供足夠有效的輸入驗證？
6.系統是不是包含了太多選項或者包含的一些選項不會被使用，是不是符合人的思維和邏輯？
7.對於來自用戶的輸入，系統是否能夠及時做出反應？比如鼠標點擊會不會表現出被按壓/彈起的狀態。
8.程序的操作是否很容易上手？
9.軟件的設計是否有助於用戶準確輸入？
10.用戶的操作可以輕鬆重複嗎嗎？
11.用戶是否確定能夠在衆多的功能和菜單中來回切換而不發生意外？用戶會不會推薦給其他用戶？
12.軟件的功能實現是否達到了設計的規格要求？
可用性測試基本上屬於黑盒測試的範疇。
7.2可用性測試流程
1.測試用戶的選擇：需要同一組用戶完成多個測試以及不同組用戶完成多個測試。有經驗的測試專家以及外行人，合理性選擇。與時候局外人或許可以給出不一樣的見解。
2.需要多少用戶進行測試：並不是越多越好，是情況而定，主要原則就是用最少的成本達到最高的測試回報。
3.數據採集方法：錄製測試過程並使用“發聲思考”可以很好的記錄可用性測試數據以及用戶對軟件的使用感受。“眼球追蹤”技術很複雜但卻很有用，可以使用在武器導航，機器人控制，車輛控制以及其他隊速讀和響應有特別要求的系統。
4.可用性調查問卷：可以學學問卷調查設計技巧，一個原則：儘量不要讓用戶做過主觀的回答，減少用戶輸入。主要採取三個形式：是否問題/真假問題/某種程度的同意反對
5.何時收工：沒有一定的原則，根據經驗來看。
8.調試
調試是執行一次成功的測試之後所有進行的工作。
8.1 調試方法
1.蠻力法調試：利用內存信息輸出來調試、根據一般的“在程序中插入打印語句”建議來調試、使用自動化的調試工具。蠻力法調試忽略了思考的過程，效率比較低下。
2.歸納法調試：從細節轉到全局，從線索出發，尋找線索之間的聯繫。步驟如下：確定相關數據->組織數據->做出假設->證明假設->證明假設->解決問題/
3.演繹法調試：從一些普遍的理論或前提出發，使用排除和精煉的過程，達到一個結論。步驟如下：列舉出所有可能的原因或假設->利用數據排除可能的原因->提煉剩下的假設->證明剩下的假設->修復問題。其中有一個循環的過程。
4.回溯法調試：沿着程序的邏輯結構回溯不正確的結果，直到找出程序邏輯出錯的位置。
5.測試法調試：當發現了某個被懷疑的錯誤的症狀之後，我們需要編寫與原先有所變化的測試用例，儘量確定錯誤的位置。
8.2 調試的原則
1.定位錯誤的原則：動腦筋/遇到僵局留到稍後解決/遇到問題把問題描述給其他人聽/僅將調試工具作爲第二種手段/避免能使用實驗法-僅將其作爲最後的手段
2.修改錯誤的技術：存在一個缺陷的地方有可能還存在其他缺陷；/應糾正錯誤本身而非其症狀；/正確糾正錯誤的可能性並非100%；/隨着程序規模的增加正確修改錯誤的可能性反而降低；/應該意識到糾正錯誤會引入新錯誤的可能性；/修改錯誤的過程也是臨時回到設計階段的過程；/應修改源代碼而不是目標代碼。
敏捷開發模式下的測試、互聯網應用測試和移動應用測試目前不打算精讀，到時候分主題進行閱讀。
總體框架結構圖
