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