3.1調試測試
×我們必須創建測試以重現問題
×我們必須多次運行測試以簡化問題
×我們必須重新運行測試以觀察運行過程
×我們必須重新運行測試以驗證修改是否成功
×每個版本發布之前，我們必須重新運行測試，以便發現將來不會再次出現，這種稱為回歸測試
在調試過程中需要頻繁的進行自動測試，應此最好盡可能的采用自動化測試。通常通過使用自動化測試技術，可以更容易的進行全面測試，自動化測試的好處在于：
×可以重用已有測試
×可以進行一些困難的、無法手工執行的測試（如：大規模的隨機性測試）
×重復測試
×增強對軟件的信心
3.2控制程序
通常，自動化測試必須模擬程序所處的環境---也就是說，測試必須提供程序的輸入，并且評估程序的輸出。但是模擬環境需要很多技巧，如果環境中包括和程序進行交互的用戶，自動測試就必須模擬真實的用戶（包括他們的所有能力）。
通過區分不同的接口，可以避開部分模擬難題，從而使得控制和評估都更易于自動化。下圖是典型的三層接口劃分：
×表現層處理和用戶（或者構建程序環境的任何事物）之間的交互
×功能層封裝程序的實際功能，功能獨立于表現層
×單元層把功能分解成多個單元，這些單元相互協作形成一個整體
3.3在表現層測試
3.3.1低級交互
在最低級的抽象級別，用戶輸入被看做鼠標和鍵盤的事件流，這種事件流可以是被捕獲和重放，即用時間記錄器的時間流替代實際輸入設備的事件流。
（PS：如果是在windows上測試需要UI交互的程序，貌似可以直接簡單的試用key_event mouse_event等幾個api就能模擬時間送進來了；當然，還有socket類的測試，管道什么的，，，）
3.3.2系統級交互（高階主題，主要是將在系統（如虛擬機）級別模擬外部操作）
3.3.3高級交互
使用更高級抽象級別的事件流（或者腳本）來模擬外部操作。比如圖形程序的測試，以前是直接算坐標控制，現在用更聰明的手段（標識button的text，輸入指定的語句而不是裸的**_event）。簡而言之就是輸入更加具有邏輯性，更加接近“人工智能”
3.3.4 評估測試結果
不管是事件流還是通過用戶控件控制應用程序，都存在一個重要的問題：模擬環境必須檢查程序的輸出。
×必須通過檢查輸出進行同步，應為模擬用戶可能會一直等待直到一個特定的動作結束。
×必須通過檢查程序輸出來進行結果評估，測試的最終目的是確定結果是否和我們的預期相符。
表現層測試的優點是：它總能實現。我們總是可以模擬和自動執行用戶的行為。但是，這是唯一的優點。通常表現層測試只是用于：
×問題發生在表現層
×計算機程序可以很方便的調用表現層
×沒有其他的選擇（如：由于表現層和功能層沒有被清晰的分離，或者無法在較低層次上進行測試）
界面對人越友好，它對計算機程序就越不友好。。。所以表現層測試應該不是最適合自動化測試的接口（至少對非表示層coder來說）
3.4在功能層測試
相比較于模擬用戶交互，更加可取的方法是為程序設計一個適合于進行自動化的接口---或者通俗的說，設計接口時要考慮和測試系統的交互。比如通過提供腳本語言接口，腳本語言允許最終用戶或者測試人員通過簡單的方式自動執行某些任務。
在功能層進行測試的最大優點是：很容易獲取和評估結果。但是，這種測試的前提條件是能清晰的分離表現層和功能層。而一些陳舊的程序都是獨立的整體，沒有進行表現層和功能層的分離。這種情況下，有三種選擇：
×繼續在表現層惡心的測試，然后繼續糾結
×重新進行大幅度的重新設計，以分離表現層和功能層，或者至少減少他們之間的依賴關系
×分解程序，并且直接測試獨立的單元
3.5在單元層測試
任何復雜的程度都可以分解成大量獨立的單元---子程序、函數、庫、模塊、抽象數據類型、對象、類、包、組建、beans或者設計方案和語言提供的任何分解機制。單元之間通過接口同學---就像程序之間通過他們所處的環境進行通信一樣。
現在的想法不是需要自動運行整個程序，而是自動運行某個特定的單元。其優點是自動運行分離的單元一般都比自動運行整個程序容易的多。當然，缺點是自能自動化某個特定的單元行為，于是必須考慮在分離單元的過程中引入的問題。
最終用戶通常是不能訪問單元的，因此不可能通過用戶腳本來執行系統的功能。但是，程序員可以使用外圍程序訪問服務的方式訪問單元（PS: 這句有點繞口，感覺是讓程序員自己去寫code做單元測試）
所有的單元測試工具都提供了一個能組織大量單獨測試用例的測試框架---每個測試覆蓋一個獨立的單元。單元測試應該能在沒有任何用戶交互的情況下自動運行，測試框架會按照要求運行部分或者所有的單元測試，然后概要顯示運行單元測試以及各自的輸出結果。運行某一個單元測試時，測試框架會按照以下三個步驟進行：
×建立單元測試以及運行的周邊環境。通常一個單元可能需要其他單元或者操作環境的服務。該步驟建立起能使測試運行的環境。
×執行單元測試。每個測試用例覆蓋該單元的一個可能的行為，用例首先執行所有操作，然后驗證輸出是否與預期相符。
×重新清理測試環境。
3.6分離單元
有一些程序的功能層依賴于表現層，根本不可能把他們分離。比如print_to_file，把當前網頁打印到文件中。為了防止覆蓋已經存在的文件，會請求用戶確認是否已經存在。（這個其實也可以使用的代碼搞定，麻煩點，不過“確認”這個功能的測試就是必須UI和用戶參與）
×表現層依賴功能層，應為他需要調用print_to_file()
×功能層依賴表現層，應為他需要調用confirm_loss()
問題就來了：如何切斷依賴關系，使單元可以更好分離？
對于這個例子處理起來比較容易?？梢宰尯瘮蛋凑諆煞N方式運行：自動模式禁止用戶確認功能，總是返回true；交互模式，打開用戶確認功能，等待用戶回答。更加通用的方式是：參數化print_to_file函數，使他能與不同的表現層工作。
（PS：其實還可以通過引入一個中間層來解決，假設給print_to_file()加上參數，然后core不再依賴pressntation，而是依賴一個消息模塊、或者控制模塊，那么只要寫一個模擬發送消息、模擬控制的模塊即可。解決循環依賴直接的辦法是引入中間層）
3.7為調試而設計
依賴抽象而不是具象這一原則對于減少依賴關系有很大幫助。實際上可以利用這種方法創建整個應用程序框架，其中最流行的一個例子就是模型-視圖-控制器架構模式，該模式能從應用程序級上解除功能層和表現層之間的耦合。
如何創建一個這樣的系統？最關鍵的還是分離功能層和表現層。我們決不希望核心功能依賴某個特定視圖。MVC模式就是解決這類問題的一個通用方案。他把職責分解為兩個部分：
×模型管理核心數據，并且提供處理這些核心數據的服務。
×個總觀察者注冊或者粘附(attach)在模型上，核心數據一旦發生變化，他們就會得到通知。
觀察者又可以分成兩種類型：
×視圖負責以特定的方式顯示核心數據
×控制器負責處理輸入時間并調用模型服務
用戶和控制器交互是，他最終可能會調用一個改變核心數據的服務。這是注冊在模型上的所有視圖都會得到通知。也就是說，他們能從模型那里獲得數據以及更新顯示。從而用戶也就得到反饋。
MVC給測試和調試帶來的好處：對于測試來說可以創建和添加新的控制器來調用模型提供的服務---例如，能自動記錄執行這些服務的控制器。對于調試來說，可以支持特殊的視圖來記錄模型的所有變化。最后，可以單獨的檢查每一個觀察者和模型，減少復雜性。
3.8預防未知問題