1 一次自評價測試
所謂軟體測試，就是一個過程或一系列過程，用來确認計算機代碼完成了其應該完成的功能，不執行其不該執行的功能。
2 軟體測試的心理學和經濟學
2.1 軟體測試的心理學
軟體測試是為發現錯誤而執行程式的過程。
2.2 軟體測試的經濟學
要想完全測試一個軟體不論是從黑盒測試還是白盒測試的角度來看都是不可能的。那我們要做的就是如何提供成本效益高的測試用例。
2.3 軟體測試的原則
原則1：測試用例中一個必須的部分是對預期輸出或結果的定義
原則2：程式員應當避免測試自己編寫的程式
原則3：編寫軟體的組織不應當測試自己編寫的軟體
原則4：應當測底檢查每個測試的執行結果
原則5：測試用例的編寫不僅應當根據有效和預期的輸入情況，而且也應當根據無效和未預料到的輸入情況
原則6：檢查程式是否“未做其應當做的”僅是測試的一半，測試的另一半是檢查程式是否“做了其不應該做的”
原則7：應避免測試用例用後即棄，除非軟體本身就是一個一次性的軟體
原則8：計劃測試工作時不應該默許假定不會發現錯誤
原則9：程式某部分存在更多錯誤的可能性，與該部分已發現錯誤的數量成正比
原則10：軟體測試是一項極富創造性、極具智力挑戰性的工作
3 代碼檢查、走查與評審
代碼檢查、走查以及可用性測試是三種主要的人工測試方法
3.1 代碼檢查
代碼檢查：以組為機關閱讀代碼 檢查過程：1）由程式編碼人員逐條語句講述程式的邏輯結構。在講述的過程中，小組的其他成員應提問、判斷是否存在錯誤。 2）參考常見的編碼錯誤清單分析程式（資料引用錯誤、資料聲明錯誤、運算錯誤、比較錯誤、控制流程錯誤、接口錯誤）
3.2 代碼走查
不同與代碼檢查，代碼走查會對一些書面用例進行人腦推演
4 測試用例的設計
推薦的步驟是先使用黑盒測試方法來設計測試用例，然後視情況需要使用白盒測試方法來設計補充的測試用例 白盒測試的方法：1）語句覆寫。2）判定覆寫。3）條件覆寫。4）判定/條件覆寫。5）多重條件覆寫。 黑盒測試的方法：1）等價類劃分。2）邊界值分析。3）因果圖分析。4）錯誤猜想。
4.1 白盒測試
白盒測試關注的是測試用例執行的程度或覆寫程式邏輯結構（源代碼）的程度
語句覆寫：較弱的準則，将程式中的每條語句至少執行一次。
判定覆寫或分支覆寫：較強的邏輯覆寫準則，必需編寫足夠的測試用例，使得每個判斷都至少有一個為真和為假的輸出結果。也就是說每條分支路勁都必須至少周遊一次。
條件覆寫：比判定覆寫更強的準則，條件覆寫要編寫足夠的測試用例以確定将一個判斷中的每個條件的所有可能的結果至少執行一次。
判定/條件覆寫：設計出充足的測試用例，将一個判斷中的每個條件的所有可能的結果至少執行一次，将每個判斷的所有可能的結果至少執行一次，将每個入口點都至少調用一次。
多重條件覆寫：要求編寫足夠多的測試用例，将每個判定中的所有可能的條件結果的組合，以及所有的入口點都至少執行一次。
4.2 黑盒測試
等價劃分的步驟：1）确定等價類；2）生成測試用例。
1）确定等價類：選取每一個輸入條件（通常是規格說明中的一個句子或短語）并将其劃分為兩個或更多的組。有效等價類（代表對程式的有效輸入）無效等價類（代表的則是其他任何可能的輸入條件，即不正确的輸入值）。
2）生成測試用例：a）為每個等價類設定一個不同的編号。 b）編寫新的測試用例，盡可能的覆寫那些未被覆寫的有效等價類，直到所有的有效等價類都被測試用例覆寫（包含進去）。 c）編寫新的用例，覆寫一個且僅一個尚未被涵蓋的無效等價類，直到所有的無效等價類都被測試用例所覆寫。
邊界值分析：指輸入和輸出等價類中的那些恰好處于邊界、或超越邊界、或在邊界以下的狀态。
步驟：1） 與從等價類中挑選出任意一個元素作為代表不同，邊界值分析需要選擇一個或多個元素，以便等價類的每個邊界都經過一次測試。 2） 與僅僅關注輸入條件（輸入空間）不同，還需要考慮從結果空間（輸出等價類）設計測試用例。
因果圖：是一種形式語言，用自然語言描述的規格說明可以轉換為因果圖。因果圖實際上是一種數字邏輯電路（一個組合的邏輯網絡），但沒有使用标準的電子符号，而是使用了稍微簡單點的符号。生成測試用例的過程如下
步驟：1） 将規格說明分解為可執行的片段。
2） 确定規格說明中的因果關系。
3） 分析規格說明的語義内容，并将其轉換為連接配接因果關系的布爾圖。所謂的因果圖。
4） 給圖加上注解符号，說明由于文法或環境的限制而不能聯系起來的“因”和“果”。
5） 通過仔細的跟蹤圖中的狀态變化情況，将因果圖轉換成一個有限項的判定表。表中的每一列代表一個測試用例。
6） 将判定表中的列轉換成測試用例。 錯誤猜測：利用直覺和經驗猜測出錯的可能類型，然後編寫測試用例來暴露這些錯誤。
4.3 測試政策
1）如果規格說明中包含輸入條件組合的情況，應首先使用因果圖分析方法。
2）在任何情況下都應使用邊界值分析方法。 3）應為輸入和輸出确定有效和無效等價類，在必要情況下對上面确認的測試用例進行補充。 4）使用錯誤猜測技術增加更多的測試用例。 5）針對上述測試用例集檢查程式的邏輯結構。
5 子產品（單元）測試
子產品測試的目的是将子產品的功能與定義子產品的功能規格說明或接口規格說明進行比較。這裡測試的目标不是為了說明子產品符合其規格說明，而是為了揭示出子產品與其規格說明存在沖突。 子產品測試的步驟：1）測試用例的設計 2）執行子產品測試和內建的順序 子產品測試的測試用例設計如下：使用一種或多種白盒測試方法分析子產品的邏輯結構，然後使用黑盒測試方法對照子產品的規格說明以補充測試用例 非增量測試：先獨立地測試每個子產品，然後再将這些子產品組裝成完整的程式。又叫“崩潰（big-bang）”測試。 增量測試：先将下一步要測試的子產品組裝到測試完成的子產品集合中，然後再進行測試。又叫內建測試。1） 自頂向下；2） 自底向上。
6 更進階别的測試
子產品測試的目的是發現程式子產品與其接口規格說明之間的不一緻。
功能測試的目的是為了證明程式未能符合其外部規格說明。
系統測試的目的是為了證明軟體産品與其初始目标不一緻。（外部規格說明不能作為擷取系統測試用例的基礎）
6.2 系統測試
能力測試：確定程式的目标功能實作
容量測試：發現處理大容量資料時的程式異常
強度測試：發現在大規模負載、高強度不間斷持續的資料進行中的異常
可用性測試：評估最終使用者在使用軟體并與軟體互動時存在的可用性問題
安全性測試：試圖攻破程式的安全防線
性能測試：評估程式的的響應時間和吞吐率
存儲測試：確定程式可以正确處理其對存儲的需求
配置測試：檢查程式是否能在推薦配置上流程運作
相容性/轉換測試：評估新版本是否能相容老的版本 安裝測試：確定能夠在所有支援的平台上安裝軟體 可靠性測試：評估程式是否能達到規格說明中的運作時常和平均故障間隔時間要求 可恢複性測試：測試系統恢複相關的功能是否按設計要求實作 服務/可維護性測試：評估系統是否擁有良好的資料處理和日志機制，以備技術支援和調試之需 文檔測試：校驗所有使用者文檔是否準确 過程測試：對軟體作業系統或維護所需涉及的流程進行評估和确定
6.3 驗收測試
驗收測試是将程式與其最初的需求及最終使用者目前的需要進行比較的過程。該測試通常是有程式的客戶或最終使用者來進行。 Alpha測試是由使用者在 開發環境下進行的測試，也可以是開發機構内部的使用者在模拟實際操作環境下進行的測試。開發者坐在使用者旁邊，這是在開發者受控的環境下進行的測試。由開發者随時記錄下錯誤情況和使用中的問題。
Beta測試是由軟體的多個使用者在一個或多個使用者的 實際使用環境下進行的測試。開發者通常不在測試現場，這是在開發者無法控制的環境下進行的測試。由使用者記錄下遇到的所有問題，定期向開發者報告。beta測試是一模拟真實的使用環境進而發現缺陷的一種測試
6.4 安裝測試
安裝測試：1）使用者必須選擇大量的選項。2）必須配置設定并加載檔案和庫。3）必須進行有效的硬體配置。4）軟體可能要求網絡聯通，以便與其他軟體連接配接
6.5 測試的計劃與控制
一個良好的測試計劃應該包括：1）目标，必須定義每個測試階段的目标。2）結束準則，必須制定準則以規定每個測試階段何時可以結束。3）進度，每個階段都必須有時間表。4）責任。5）測試用例庫及标準。6）工具。7）計算機時間。8）硬體配置。9）內建。10）跟蹤步驟。11）調試步驟。12）回歸測試。
6.6 測試結束準則
有三類較為有用的準則。 第一類，但不是最佳的準則，根據的是特定的測試用例設計技術，
子產品測試結束：測試用例來源于（1）滿足多重條件覆寫準則，以及（2）對子產品接口規格說明進行邊界值分析，産生的所有測試用例最終都是不成功的。
功能測試結束：測試用例來源于（1）因果圖分析（2）邊界值分析，以及（3）錯誤猜測，産生的所有測試用例最終都是不成功的。
第二類：也許也是最有價值的準則，是以确切的數量來描述結束測試的條件。預測錯誤（總數量，發現的個數，各個階段的産生），用發現的錯誤與預測的比例來結束。
第三類：需要我們在測試的過程中記錄每個機關時間内發現的錯誤數量，通過檢查統計曲線的形狀，常常可以決定究竟是繼續該階段的測試，還是結束它并開始下一測試階段。
8 調試
調試：是執行一次成功的測試之後所要進行的工作，所謂成功的測試，是指它可以證明程式沒有實作預期的功能。 調試的步驟：1）确定程式中可疑錯誤的準确性質和位置；2）修改錯誤。 蠻力法調試：不需要過多思考，是耗費腦力最少的方法，但同時也是效率低下，通常來講不是很成功的。1）利用記憶體資訊輸出來調試。2）根據一般的“在程式中插入列印語句”建議來調試。3）使用自動化的調試工具進行調試。 歸納法調試：認真的思考能發現大部分錯誤，甚至不需要調試人員使用調試工具。歸納法是一種特殊的思考過程，可以從細節轉到全局，也就是從線索出發，尋找線索之間的聯系。1）确定相關資料。2）組織資料。3）做出假設。4）證明假設。 演繹發調試：從一些普遍的理論或前提出發，使用排除和精煉的過程，達到一個結論。1）列舉是以可能的原因或假設。2）利用資料排除可能的原因。3）提煉剩下的假設。4）證明剩下的假設。 回溯發調試：在小型程式中定位錯誤的一種有效方法是沿着程式的邏輯結構回溯不正确的結果，直到找出程式邏輯出錯的位置。 測試法調試：供測試的測試用例，其目的是暴露出以前尚未發現的錯誤；供調試的測試用例，其目的是提供有用的資訊，供定位某個被懷疑的錯誤之用。 調試的原則：1）動腦筋。2）如果遇到僵局，就留到稍後解決。3）如果遇到了困境，就把問題描述給其他人聽。4）僅将測試工具作為第二種手段。5）避免使用試驗法----僅将其作為最後的手段。 修改錯誤的技術：1）存在一個缺陷的地方，很有可能還存在其他缺陷。2）應糾正錯誤本身，而不是其症狀。3）正确糾正錯誤的可能性并非100%。4）正确修改錯誤的可能性随着程式的增加而降低。5）應意識改正錯誤會引入新錯誤的可能性。6）修改錯誤的過程也是臨時回到設計階段的過程。7）應修改源代碼，而不是目标代碼。 錯誤分析：1）錯誤出現在什麼地方？2）誰制造了這個錯誤？3）哪些做得不正确？4）如何避免該錯誤的出現？5）為什麼錯誤沒有早些發現？6）該如何更早地發現錯誤？
9 靈活開發模式下的測試
極限程式設計（XP）：XP模型高度依賴子產品的單元和驗收測試。對每個無論多小的遞增的代碼變更都必須進行單元測試，以確定代碼庫滿足其規格說明書。1）聆聽客戶和其他程式員的談話。2）與客戶合作，開發應用程式的規格說明和測試用例。3）結對編碼。4）測試代碼庫。 極限測試（TP）：該方法強調連續測試，包含單元測試和驗收測試。 極限單元測試：多月代碼子產品中編碼開始之前必須設計好單元測試用例，在産品釋出之前須通過單元測試。
極限驗收測試：目的是判斷應用程式是否滿足如功能性和易用性等其他需求。在設計/計劃階段，有開發人員和客戶來設計驗收測試。
極限測試的重點在于單元測試和驗收測試，一旦代碼庫發生了變更，就需要進行單元測試，在重要的釋出結點，有客戶來執行驗收測試。極限測試還要求在開始程式編碼之前，根據程式的規格說明設計測試配件，在這種方式中，開發的程式要通過單元測試，進而提高程式滿足其規格說明的可能性。
10 網際網路應用測試
表示層的測試：1）内容測試；2）Web站點結構；3）使用者環境 業務層的測試：1）性能；2）資料有效性；3）事務 資料層的測試：1）響應時間測試；2）資料完整性測試；3）容錯性和可恢複性測試
11 移動應用測試
移動應用測試分類： 安裝/解除安裝，網絡基礎設施，來電和短信的處理，記憶體不足，按鍵，退出（關機），充電，電量，硬體資源 測試方法： 真機測試 基于模拟器的測試