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