3.1調(diào)試測試

×我們必須創(chuàng)建測試以重現(xiàn)問題

×我們必須多次運(yùn)行測試以簡化問題

×我們必須重新運(yùn)行測試以觀察運(yùn)行過程

×我們必須重新運(yùn)行測試以驗(yàn)證修改是否成功

×每個(gè)版本發(fā)布之前，我們必須重新運(yùn)行測試，以便發(fā)現(xiàn)將來不會再次出現(xiàn)，這種稱為回歸測試

在調(diào)試過程中需要頻繁的進(jìn)行自動(dòng)測試，應(yīng)此最好盡可能的采用自動(dòng)化測試。通常通過使用自動(dòng)化測試技術(shù)，可以更容易的進(jìn)行全面測試，自動(dòng)化測試的好處在于：

×可以重用已有測試

×可以進(jìn)行一些困難的、無法手工執(zhí)行的測試（如：大規(guī)模的隨機(jī)性測試）

×重復(fù)測試

×增強(qiáng)對軟件的信心

3.2控制程序

        通常，自動(dòng)化測試必須模擬程序所處的環(huán)境---也就是說，測試必須提供程序的輸入，并且評估程序的輸出。但是模擬環(huán)境需要很多技巧，如果環(huán)境中包括和程序進(jìn)行交互的用戶，自動(dòng)測試就必須模擬真實(shí)的用戶（包括他們的所有能力）。

        通過區(qū)分不同的接口，可以避開部分模擬難題，從而使得控制和評估都更易于自動(dòng)化。下圖是典型的三層接口劃分：

×表現(xiàn)層處理和用戶（或者構(gòu)建程序環(huán)境的任何事物）之間的交互

×功能層封裝程序的實(shí)際功能，功能獨(dú)立于表現(xiàn)層

×單元層把功能分解成多個(gè)單元，這些單元相互協(xié)作形成一個(gè)整體

3.3在表現(xiàn)層測試

3.3.1低級交互

        在最低級的抽象級別，用戶輸入被看做鼠標(biāo)和鍵盤的事件流，這種事件流可以是被捕獲和重放，即用時(shí)間記錄器的時(shí)間流替代實(shí)際輸入設(shè)備的事件流。

（PS：如果是在windows上測試需要UI交互的程序，貌似可以直接簡單的試用key_event mouse_event等幾個(gè)api就能模擬時(shí)間送進(jìn)來了；當(dāng)然，還有socket類的測試，管道什么的，，，）

3.3.2系統(tǒng)級交互（高階主題，主要是將在系統(tǒng)（如虛擬機(jī)）級別模擬外部操作）

3.3.3高級交互

        使用更高級抽象級別的事件流（或者腳本）來模擬外部操作。比如圖形程序的測試，以前是直接算坐標(biāo)控制，現(xiàn)在用更聰明的手段（標(biāo)識button的text，輸入指定的語句而不是裸的**_event）。簡而言之就是輸入更加具有邏輯性，更加接近“人工智能”

3.3.4 評估測試結(jié)果

        不管是事件流還是通過用戶控件控制應(yīng)用程序，都存在一個(gè)重要的問題：模擬環(huán)境必須檢查程序的輸出。

×必須通過檢查輸出進(jìn)行同步，應(yīng)為模擬用戶可能會一直等待直到一個(gè)特定的動(dòng)作結(jié)束。

×必須通過檢查程序輸出來進(jìn)行結(jié)果評估，測試的最終目的是確定結(jié)果是否和我們的預(yù)期相符。

        表現(xiàn)層測試的優(yōu)點(diǎn)是：它總能實(shí)現(xiàn)。我們總是可以模擬和自動(dòng)執(zhí)行用戶的行為。但是，這是唯一的優(yōu)點(diǎn)。通常表現(xiàn)層測試只是用于：

×問題發(fā)生在表現(xiàn)層

×計(jì)算機(jī)程序可以很方便的調(diào)用表現(xiàn)層

×沒有其他的選擇（如：由于表現(xiàn)層和功能層沒有被清晰的分離，或者無法在較低層次上進(jìn)行測試）

界面對人越友好，它對計(jì)算機(jī)程序就越不友好。。。所以表現(xiàn)層測試應(yīng)該不是最適合自動(dòng)化測試的接口（至少對非表示層coder來說）

3.4在功能層測試

        相比較于模擬用戶交互，更加可取的方法是為程序設(shè)計(jì)一個(gè)適合于進(jìn)行自動(dòng)化的接口---或者通俗的說，設(shè)計(jì)接口時(shí)要考慮和測試系統(tǒng)的交互。比如通過提供腳本語言接口，腳本語言允許最終用戶或者測試人員通過簡單的方式自動(dòng)執(zhí)行某些任務(wù)。

        在功能層進(jìn)行測試的最大優(yōu)點(diǎn)是：很容易獲取和評估結(jié)果。但是，這種測試的前提條件是能清晰的分離表現(xiàn)層和功能層。而一些陳舊的程序都是獨(dú)立的整體，沒有進(jìn)行表現(xiàn)層和功能層的分離。這種情況下，有三種選擇：

×繼續(xù)在表現(xiàn)層惡心的測試，然后繼續(xù)糾結(jié)

×重新進(jìn)行大幅度的重新設(shè)計(jì)，以分離表現(xiàn)層和功能層，或者至少減少他們之間的依賴關(guān)系

×分解程序，并且直接測試獨(dú)立的單元

3.5在單元層測試

        任何復(fù)雜的程度都可以分解成大量獨(dú)立的單元---子程序、函數(shù)、庫、模塊、抽象數(shù)據(jù)類型、對象、類、包、組建、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做單元測試）

        所有的單元測試工具都提供了一個(gè)能組織大量單獨(dú)測試用例的測試框架---每個(gè)測試覆蓋一個(gè)獨(dú)立的單元。單元測試應(yīng)該能在沒有任何用戶交互的情況下自動(dòng)運(yùn)行，測試框架會按照要求運(yùn)行部分或者所有的單元測試，然后概要顯示運(yùn)行單元測試以及各自的輸出結(jié)果。運(yùn)行某一個(gè)單元測試時(shí)，測試框架會按照以下三個(gè)步驟進(jìn)行：

×建立單元測試以及運(yùn)行的周邊環(huán)境。通常一個(gè)單元可能需要其他單元或者操作環(huán)境的服務(wù)。該步驟建立起能使測試運(yùn)行的環(huán)境。

×執(zhí)行單元測試。每個(gè)測試用例覆蓋該單元的一個(gè)可能的行為，用例首先執(zhí)行所有操作，然后驗(yàn)證輸出是否與預(yù)期相符。

×重新清理測試環(huán)境。

3.6分離單元

        有一些程序的功能層依賴于表現(xiàn)層，根本不可能把他們分離。比如print_to_file，把當(dāng)前網(wǎng)頁打印到文件中。為了防止覆蓋已經(jīng)存在的文件，會請求用戶確認(rèn)是否已經(jīng)存在。（這個(gè)其實(shí)也可以使用的代碼搞定，麻煩點(diǎn)，不過“確認(rèn)”這個(gè)功能的測試就是必須UI和用戶參與）

×表現(xiàn)層依賴功能層，應(yīng)為他需要調(diào)用print_to_file()

×功能層依賴表現(xiàn)層，應(yīng)為他需要調(diào)用confirm_loss()

問題就來了：如何切斷依賴關(guān)系，使單元可以更好分離？

對于這個(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ì)

        依賴抽象而不是具象這一原則對于減少依賴關(guān)系有很大幫助。實(shí)際上可以利用這種方法創(chuàng)建整個(gè)應(yīng)用程序框架，其中最流行的一個(gè)例子就是模型-視圖-控制器架構(gòu)模式，該模式能從應(yīng)用程序級上解除功能層和表現(xiàn)層之間的耦合。

        如何創(chuàng)建一個(gè)這樣的系統(tǒng)？最關(guān)鍵的還是分離功能層和表現(xiàn)層。我們決不希望核心功能依賴某個(gè)特定視圖。MVC模式就是解決這類問題的一個(gè)通用方案。他把職責(zé)分解為兩個(gè)部分：

×模型管理核心數(shù)據(jù)，并且提供處理這些核心數(shù)據(jù)的服務(wù)。

×個(gè)總觀察者注冊或者粘附(attach)在模型上，核心數(shù)據(jù)一旦發(fā)生變化，他們就會得到通知。

觀察者又可以分成兩種類型：

×視圖負(fù)責(zé)以特定的方式顯示核心數(shù)據(jù)

×控制器負(fù)責(zé)處理輸入時(shí)間并調(diào)用模型服務(wù)

用戶和控制器交互是，他最終可能會調(diào)用一個(gè)改變核心數(shù)據(jù)的服務(wù)。這是注冊在模型上的所有視圖都會得到通知。也就是說，他們能從模型那里獲得數(shù)據(jù)以及更新顯示。從而用戶也就得到反饋。

MVC給測試和調(diào)試帶來的好處：對于測試來說可以創(chuàng)建和添加新的控制器來調(diào)用模型提供的服務(wù)---例如，能自動(dòng)記錄執(zhí)行這些服務(wù)的控制器。對于調(diào)試來說，可以支持特殊的視圖來記錄模型的所有變化。最后，可以單獨(dú)的檢查每一個(gè)觀察者和模型，減少復(fù)雜性。

3.8預(yù)防未知問題