1、335/136_軟件測試面試必備第18章測試策略模式18.1 記錄測試(也稱為記錄與回放測試、機器人用戶測試、捕獲/回放測試)如何預備軟件的自動化測試？通過記錄與應用程序的交互并使用測試工具回放它們來自動化測試。圖18-1 記錄測試示意圖自動化測試有幾個目的。在回歸測試軟件更改之后，它們能夠用于這些軟件。它們有助于歸檔軟件的行為。在寫軟件之前，它們能夠指定其行為。如何預備自動化測試腳本，對能夠將它們用于什么目的、它們對SUT中的變更有多健壯以及預備它們需要多少技能與努力等產生阻礙。記錄測試使得能夠在構建SUT之后、改變它之前迅速創(chuàng)建回歸測試。18.1.1 運行原理我們使用一種工具，它會監(jiān)控我們

2、與SUT的交互。這種工具記錄大多數SUT對我們的通信以及我們對SUT的響應。錄音會話完成之后，能夠將它保存在文件里以便稍后回放。預備運行測試時，能夠從工具的“回放”部分開始，并讓它指向錄音會話。它啟動SUT，并給它提供響應SUT輸出的記錄輸入。在錄音會話內，它也能夠比較SUT的輸出及其響應。錯誤匹配可能導致測試失敗。有些記錄測試工具同意調整錄音會話內SUT表現與回放過程中SUT表現之間比較的敏感性。大多數記錄測試工具通過用戶界面與SUT交互。18.1.2 使用時機假如應用程序正在運行，但不希望對它進行太多變更，就能夠使用記錄測試進行回歸測試?，F有應用程序需要重構(可能修改功能性)而沒有可用的腳

3、本測試用作回歸測試時，也能夠使用記錄測試。通常，生成一組記錄測試比預備具有相同功能性的腳本測試更快。在理論上，任何明白如何運行應用程序的人都能夠完成測試記錄，幾乎不需要專業(yè)技術。實際上，許多商業(yè)工具都值得深入學習。同時，需要一些專業(yè)技術來添加“檢查點”，以便調整回放工具的敏感性，或者調整測試腳本(假如記錄工具記錄了錯誤信息)。大多數記錄測試工具通過用戶界面與SUT交互。假如SUT的用戶界面不斷進展，這種方法特不容易讓它們變得脆弱(接口敏感性，參見“脆弱測試”)。甚至是小的變更(例如改變按鈕或字段的內部名稱)也足以讓回放工具產生錯誤。這些工具也傾向于在低級不詳細記錄信息，如此會讓測試難以理解(參

4、見“模糊測試”)。因此，假如對SUT的變更中止了這些工具，也專門難手動修復它們。因此，假如SUT不斷進展，就要預備有規(guī)律地再記錄測試。假如要使用作為文檔的測試或者要使用這些測試驅動新的開發(fā)，就應該考慮使用腳本測試。使用商業(yè)記錄測試工具難以實現這些目標，因為大多數工具不同意定義用于測試記錄的高級語言。將記錄測試性能構建到應用程序本身之中或者使用重構的記錄測試能夠解決那個問題。變體：重構的記錄測試這兩種策略的混合是，使用“記錄、重構、回放”1 名稱“記錄、重構、回放”是Adam Geras提出來的。順序從最新記錄測試中提取一組“動作組件”或“動詞”，然后通過測試用例來調用這些“動作組件”(而不是使

5、用詳細的內聯代碼)。大多數商業(yè)捕獲/回放工具提供將字面值轉換為參數的方法，要緊的測試用例能夠將這些參數傳遞到“動作組件”。屏幕改變時，只需再記錄“動作組件”，所有測試用例自動使用新的“動作組件”定義接著運行。這種策略在效能上與使用測試有用程序方法與單元測試中的SUT交互相同。它同意使用重構的記錄測試組件作為腳本測試1 名稱“記錄、重構、回放”是Adam Geras提出來的。2 BPT是“業(yè)務進程測試(Business Process Testing)”的縮寫。18.1.3 實現方式講明使用記錄測試策略時，有兩種差不多選擇：能夠獲得第三方工具，它記錄與應用程序交互時發(fā)生的通信；能夠將“記錄與回放

6、”機制內置于應用程序。1. 變體：外部測試記錄在商業(yè)上有許多測試記錄工具可用，每種工具都有自身的優(yōu)缺點。最好的選擇取決于應用程序用戶接口的性質、預算、要驗證的功能性的復雜性以及其他可能的因素。假如要使用測試來驅動開發(fā)，就需要選擇使用測試記錄文件格式的工具，這種格式能夠手動編輯且易于理解。需要手動編寫內容，假如使用“記錄與回放”工具來執(zhí)行測試，這種情況也依舊腳本測試的示例。2. 變體：內置測試記錄也能夠將記錄測試性能內置于SUT。在那種情況下，能夠用相當高的級不定義測試腳本“語言”，級不足夠高，就能夠在構建系統之前手動編寫測試。實際上，有報告講Microsoft Excel電子數據表的VBA宏性

7、能是Excel自動化測試機制的開端。18.1.4 示例：內置測試記錄從表面上看，提供記錄測試的代碼樣本沒有意義，因為這種模式處理生成測試的方法，而不是表示它的方法?；胤艤y試時，實際上確實是數據驅動測試。同樣，通常不重構到記錄測試，因為它經常是項目嘗試的第一種測試自動化策略。而且，假如發(fā)覺有過多遺漏的測試，還能夠在嘗試腳本測試之后引入記錄測試，因為手動自動化的成本太高。在那種情況下，不應該試圖將現有腳本測試轉換為記錄測試，應該記錄新測試。下面是應用程序本身記錄的測試的示例。該測試用來回歸測試安全關鍵的應用程序，同時在它從OS2上的C移植到Windows上的C+之后。請注意，記錄的信息如何形成用戶

8、易于理解的域專用高級語言。 5566 SOUTH SOUTH NORTH SOUTH NORTH 該樣本表示回放測試的輸出。內置回放機制插入了actual元素。status屬性表示這些元素是否匹配expected值。將樣式表應用于這些文件來格式化它們，就像具有彩色編碼結果的Fit測試一樣。然后項目的商業(yè)用戶能夠進行記錄、回放和結果分析。在軟件的表示層插入掛鉤能夠記錄用戶和用戶響應提供的選項列表。其中一個掛鉤的示例如下所示：if (playback_is_on() choice = get_choice_for_playback(dialog_id, choices_list); else ch

9、oice = display_dialog(choices_list, row, col, title, key); if (recording_is_on() record_choice(dialog_id, choices_list, choice, key); 方法get_choice_for_playback檢索used-value元素的內容，而不是要求用戶從選項列表中選取。方法record_choice生成actual元素并“斷言”expected元素，記錄各元素status屬性的結果。注意，當處于回放模式時，recording_is_on()返回true以便記錄測試結果。18.1.

10、5 示例：商業(yè)記錄與回放測試工具幾乎有所商業(yè)測試工具都使用“記錄與回放”隱喻。每種工具都定義自己的記錄測試文件格式，其中大多數都特不冗長。下面是使用Mercury Interactive的QuickTest Professional QTP工具記錄的測試的“簡短”摘要。它顯示于“專家視圖”中，該視圖表示真正記錄的內容：VbScript程序！該示例包括手動插入的注釋(前綴為)來講明測試在做什么，假如改變導致測試不再運行的應用程序之后記錄測試，那么就會丟失這些注釋。 GoToPageMaintainTaxonomy()Browser(Inf).Page(Inf).WebButton(Login).

11、ClickBrowser(Inf).Page(Inf_2).Check CheckPoint(Inf_2)Browser(Inf).Page(Inf_2).Link(TAXONOMY LINKING).ClickBrowser(Inf).Page(Inf_3).Check CheckPoint(Inf_3)Browser(Inf).Page(Inf_3).Link(MAINTAIN TAXONOMY).ClickBrowser(Inf).Page(Inf_4).Check CheckPoint(Inf_4) AddTerm(A,Top Level, Top Level Definition)B

12、rowser(Inf).Page(Inf_4).Link(Add).Clickwait 4Browser(Inf_2).Page(Inf).Check CheckPoint(Inf_5)Browser(Inf_2).Page(Inf).WebEdit(childCodeSuffi x).Set ABrowser(Inf_2).Page(Inf).WebEdit(taxonomyDto.descript).Set Top Level Browser(Inf_2).Page(Inf).WebEdit(taxonomyDto.definiti).Set Top Level Definition Br

13、owser(Inf_2).Page(Inf).WebButton(Save).Click wait 4Browser(Inf).Page(Inf_5).Check CheckPoint(Inf_5_2) SelectTerm(A-Top Level) Browser(Inf).Page(Inf_5).WebList(selectedTaxonomyCode).Select A-Top Level AddTerm(B,Second Top Level, Second Top Level Definition)Browser(Inf).Page(Inf_5).Link(Add).Click wai

14、t 4 Browser(Inf_2).Page(Inf_2).Check CheckPoint(Inf_2_2)infofi le_;_Inform_Alberta_21.inf_;_hightlight id_; _Browser(Inf_2).Page(Inf_2)_;_ and it goes on, and on, and on 注意，測試依據應用程序用戶界面描述所有輸入和輸出的方法。如此要緊會產生兩個問題：模糊測試(由記錄信息的具體性質所導致)和接口敏感性(導致脆弱測試)。18.1.6 重構講明讓該測試作為文檔能夠使之更有用，能夠降低或幸免高測試維護成本，支持使用一系列提取方法Fow

15、ler重構組成使用高級語言的其他測試。18.1.7 示例：重構的商業(yè)記錄測試下面的示例顯示重構來交流意圖的相同測試：GoToPage_MaintainTaxonomy()AddTerm(A,Top Level, Top Level Defi nition)SelectTerm(A-Top Level)AddTerm(B,Second Top Level, Second Top Level Defi nition)注意，該測試的意圖變得特不明顯。提取的測試有用程序方法如下所示：Method GoToPage_MaintainTaxonomy()Browser(Inf).Page(Inf).Web

16、Button(Login).Click Browser(Inf).Page(Inf_2).Check CheckPoint(Inf_2) Browser(Inf).Page(Inf_2).Link(TAXONOMY LINKING).Click Browser(Inf).Page(Inf_3).Check CheckPoint(Inf_3) Browser(Inf).Page(Inf_3).Link(MAINTAIN TAXONOMY).Click Browser(Inf).Page(Inf_4).Check CheckPoint(Inf_4)EndMethod AddTerm( code,

17、name, description)Browser(Inf).Page(Inf_4).Link(Add).Clickwait 4Browser(Inf_2).Page(Inf).Check CheckPoint(Inf_5)Browser(Inf_2).Page(Inf).WebEdit(childCodeSuffi x).Set code Browser(Inf_2).Page(Inf).WebEdit(taxonomyDto.descript).Set name Browser(Inf_2).Page(Inf).WebEdit(taxonomyDto.defi niti).Set desc

18、ription Browser(Inf_2).Page(Inf).WebButton(Save).Click wait 4Browser(Inf).Page(Inf_5).Check CheckPoint(Inf_5_2) endMethod SelectTerm( path )Browser(Inf).Page(Inf_5).WebList(selectedTaxonomyCode).Select pathBrowser(Inf).Page(Inf_5).Link(Add).Clickwait 4 end我將那個示例編在一起是為了講明與xUnit中做法的類似之處。不要隨便運行該示例，因為在語

19、句構成上它可能不正確。18.1.8 高級閱讀論文“Agile Regression Testing Using Record and PlayBack”ARTRP介紹了將記錄測試機制內置于應用程序以利于將它導出到其他平臺的經驗。18.2 腳本測試(也稱為手寫測試、手動編碼測試、程序測試、自動化單元測試) 如何預備軟件的自動化測試？通過手動寫測試程序來自動化測試。圖18-2 腳本測試示意圖自動化測試有幾個目的。在回歸測試軟件更改之后，它們能夠用于這些軟件。它們有助于歸檔軟件的行為。在寫軟件之前，它們能夠指定其行為。如何預備自動化測試腳本，這將阻礙能夠將它們用于什么目的、它們對SUT中的變更有多健

20、壯以及預備它們需要多少技能與努力。腳本測試同意在開發(fā)軟件之前預備測試，以便它們有助于驅動設計。18.2.1 運行原理通過寫測試程序來自動化測試，這些測試程序為了執(zhí)行其功能性而與SUT交互。和記錄測試不一樣，這些測試能夠是客戶測試或單元測試。這些測試程序通常稱為“測試腳本”，以便與它們測試的產品代碼區(qū)分開來。18.2.2 使用時機預備軟件的單元測試時，通常使用腳本測試。因為它更容易從用相同編程語言寫的軟件中直接訪問單個單元。它也同意執(zhí)行所有代碼路徑，包括“不合理的”。客戶測試略微有些復雜。當使用自動化故事測試來驅動軟件開發(fā)時，應該使用腳本測試。記錄測試不能專門好滿足這種需要，因為沒有用來記錄它們

21、的應用程序時它難以記錄測試。預備腳本測試能夠使用編程經驗以及測試方法中的經驗。項目上的大多數業(yè)務用戶不可能對學習如何預備腳本測試感興趣。在編程語言中進行腳本測試的方法之一是，定義測試SUT的高級語言，然后作為數據驅動測試解釋程序GOF實現該語言。一種定義數據驅動測試的開源架構是Fit及FitNesse。Canoo WebTest是支持這種類型測試的另一種工具。在現有遺留應用程序3 在測試驅動程序中，遺留應用程序是缺乏自動化測試安全網的系統。中，3 在測試驅動程序中，遺留應用程序是缺乏自動化測試安全網的系統。18.2.3 實現方式講明傳統上腳本測試寫作“測試程序”，通常使用特定的測試腳本語言。現

22、在，我們更喜愛使用測試自動化架構來寫腳本測試，例如，用與SUT相同的語言寫的xUnit。在這種情況下，通常以測試用例類上測試方法的形式捕獲各測試程序。要最小化手動干預，各測試方法應該實現自檢測試(也確實是可重復的測試)。18.2.4 示例：腳本測試下面是用JUnit寫的腳本測試的示例：public void testAddLineItem_quantityOne()final BigDecimal BASE_PRICE = UNIT_PRICE;final BigDecimal EXTENDED_PRICE = BASE_PRICE;/ Set Up FixtureCustomer custo

23、mer = createACustomer(NO_CUST_DISCOUNT);Invoice invoice = createInvoice(customer);/ Exercise SUTinvoice.addItemQuantity(PRODUCT, QUAN_ONE);/ Verify OutcomeLineItem expected =createLineItem( QUAN_ONE, NO_CUST_DISCOUNT,EXTENDED_PRICE, PRODUCT, invoice);assertContainsExactlyOneLineItem( invoice, expect

24、ed );public void testChangeQuantity_severalQuantity()final int ORIGINAL_QUANTITY = 3;final int NEW_QUANTITY = 5;final BigDecimal BASE_PRICE =UNIT_PRICE.multiply( new BigDecimal(NEW_QUANTITY);final BigDecimal EXTENDED_PRICE =BASE_PRICE.subtract(BASE_PRICE.multiply(CUST_DISCOUNT_PC.movePointLeft(2);/

25、Set Up FixtureCustomer customer = createACustomer(CUST_DISCOUNT_PC);Invoice invoice = createInvoice(customer);Product product = createAProduct( UNIT_PRICE);invoice.addItemQuantity(product, ORIGINAL_QUANTITY);/ Exercise SUTinvoice.changeQuantityForProduct(product, NEW_QUANTITY);/ Verify OutcomeLineIt

26、em expected = createLineItem( NEW_QUANTITY,CUST_DISCOUNT_PC, EXTENDED_PRICE, PRODUCT, invoice);assertContainsExactlyOneLineItem( invoice, expected ); 18.2.5 關于名稱自動化測試程序通常稱為“測試腳本”，可能是因為繼承了這些測試程序，這些程序最初在解釋性測試腳本語言(例如Tcl)中實現。稱它們?yōu)槟_本測試的不利之處是，該術語容易將手動測試過程中應遵循的腳本與不用腳本的測試(例如探測測試)相混淆。18.2.6 高級閱讀 或TDD-APG開始。18

27、.3 數據驅動測試 如何預備軟件的自動化測試？如何減少測試碼復制？將各測試所需的信息存儲在數據文件里，并寫閱讀文件和執(zhí)行測試的解釋程序。圖18-3 數據驅動測試示意圖測試可能有專門多重復，不僅因為必須多次運行相同測試，而且因為許多測試只是略有不同。例如，要運行本質上相同但系統輸入略有不同的測試，并驗證實際輸出是不是具有相應改變。每個測試都由相同的步驟組成。擁有這么多測試是確保完好功能性覆蓋率的好方法，但關于測試可維護性而言它卻不是好方法，因為對某個測試算法的變更一定會傳播給所有類似測試。數據驅動測試能夠獲得好的覆蓋率同時又能最小化需要編寫和維護的測試碼的數量。18.3.1 運行原理寫數據驅動測

28、試解釋程序，它包含測試的所有公共邏輯。能夠將隨著測試改變而改變的數據放置到數據驅動測試文件中，解釋程序讀取該文件來執(zhí)行測試。關于每個測試而言，它實現相同系列的動作來實現四時期測試。第一時期，解釋程序檢索文件中的測試數據，然后使用文件中的數據建立測試夾具。第二時期，它執(zhí)行具有文件指定參數的SUT。第三時期，它比較SUT生成的實際結果(例如返回值、測試后狀態(tài))與文件的預期結果。假如結果不匹配，它將測試標記為失?。患偃鏢UT拋出異常，它捕獲異常并相應地標記測試然后接著。第四時期，解釋程序進行必要的夾具拆卸，然后接著執(zhí)行文件中的下一個測試。需要一系列復雜步驟的測試能夠簡化為數據驅動測試文件中的一行數據

29、。Fit是寫數據驅動測試架構的普遍示例。18.3.2 使用時機數據驅動測試是記錄測試和腳本測試的可選策略。然而，它也能夠用作腳本測試策略的一部分。實際上，回放記錄測試時，它們確實是數據驅動測試。數據驅動測試是讓業(yè)務人員寫自動化測試的理想策略。保持數據文件格式簡單，就可能讓業(yè)務人員用數據填充文件并執(zhí)行測試，而無需要求技術人員寫各種測試的測試碼。當有許多不同的數據值，同時又希望使用這些值來執(zhí)行SUT(其中每個數據值都要執(zhí)行相同系列的步驟)時，能夠考慮使用數據驅動測試作為腳本測試的一部分。通常會發(fā)覺這種相似性會隨著時刻的推移而變化，因此要先重構到參數化測試，然后重構到數據驅動測試。也可能在具有不同數

30、據值的不同序列中安排一組標準步驟，和在遞增的表格測試(參見“參數化測試”)中一樣。這種方法具有最好的覆蓋率，同時需要維護的測試碼數量也最少，假如需要，還能夠專門方便地添加更多測試。決定是否使用數據驅動測試的另一個因素，是配置數據是不是硬編碼或驅動要測試的行為。假如使用腳本測試自動化用于數據驅動行為的測試，當配置數據改變時，就必須更新測試程序。這種行為專門不正常，因為它表示，當改變配置數據庫中的數據時，必須將變更提交給源代碼庫SCM4 因此，4 因此，也應該治理在版本操縱庫里的測試數據，但那個主題在另一本書中討論，詳情請參見RDb。18.3.3 實現方式講明實現方式選擇取決因此否使用數據驅動測試

31、作為不同的測試策略或作為基于xUnit策略的一部分。使用數據驅動測試作為獨立的測試策略通常使用開源工具(例如Fit)或商業(yè)記錄測試工具(例如QTP)。使用數據驅動測試作為腳本測試策略的一部分可能要實現xUnit內的數據驅動測試解釋程序。不管選擇哪種策略，假如可能，都應該使用相應的測試自動化架構。如此做能夠有效地將測試轉換為兩個部分：數據驅動測試解釋程序和數據驅動測試文件。這兩個部分都應該保持在版本操縱之下，以便能夠明白它們隨著時刻推移如何演變，同時還同意收回所有錯誤的變更。將數據驅動測試文件存儲在某種類型的庫中至關重要，盡管這種概念與業(yè)務用戶不相關。給用戶提供數據驅動測試文件授權工具(例如Fi

32、tNesse)能夠讓這種操作透明，或者能夠建立“用戶友好”庫，例如剛好支持版本操縱的文檔治理系統。作為持續(xù)集成過程的一部分運行這些測試，以便確定曾經通過的測試沒有突然失敗，如此至關重要。沒有如此做可能導致缺陷進入未檢測到的軟件，一旦檢測到缺陷，就要付出更多努力來檢修。在持續(xù)集成過程中包含客戶測試要求能夠記錄通過的客戶測試，因為提交所有代碼之前不能確保所有客戶測試都通過。一種選擇是保持兩組輸入文件，將通過的測試從“仍是紅色”文件遷移到“差不多上綠色”文件中，該文件作為自動構建過程一部分用于回歸測試。1. 變體：數據驅動測試架構(Fit)使用數據驅動測試作為測試策略時，應該考慮使用預制數據驅動測試

33、架構。Ward Cunningham最初將Fit這種架構作為在自動化測試中包含業(yè)務用戶的方法。盡管Fit通常用于自動化客戶測試，但假如測試數量授權構建必需的夾具，它也可用于單元測試。Fit由兩部分組成：架構和用戶創(chuàng)建的夾具。Fit架構是通用數據驅動測試解釋程序，該解釋程序讀取輸入文件并找出其中的所有表。它在每個表的左上單元查找夾具類名，然后搜索該類的可執(zhí)行測試。當它找到類并讀取該表的行和列時，它會創(chuàng)建該類的實例并將控件傳遞給該實例。能夠重寫架構定義的方法來指定表中各單元出現的情況。因此，Fit夾具是適配器，Fit調用它來解釋數據表并調用SUT上的方法。Fit表也能夠包含SUT的預期結果。Fit

34、將指定的值與SUT返回的實際值進行比較。然而，與xUnit中的斷言方法不一樣，Fit在遇到第一個不匹配預期值的值時可不能終止測試。相反，它給表中的各個單元涂上顏色，綠色單元表示與預期值相匹配的實際值，紅色單元表示錯誤的或意料之外的值。使用Fit有幾個好處：與構建自己的測試解釋程序GOF相比，要寫的代碼更少。輸出對業(yè)務人員也有意義，而不只是對技術人員有意義。測試可不能在遇到第一個失敗的斷言時停止。Fit能夠用一種能夠專門容易看出失敗模式的方法傳達多種失敗/錯誤。照現在的模樣，有大量夾具類型能夠用來子類化或使用。那么，什么緣故不在所有單元測試中都使用Fit取代xUnit呢？使用Fit的要緊不足如下

35、所述：在構建Fit夾具之前，測試場景必須特不易于理解。因此需要將各種測試邏輯轉換為表格表示法，這不太合適，特不是對適應于從過程考慮的開發(fā)人員而言尤其如此。它適合擁有能夠為客戶測試寫Fit夾具的測試者的情況，但這種方法不適合于真正的單元測試，除非測試者與開發(fā)人員的比例為11。這些測試在每個測試中都要采納相同的SUT交互邏輯5 表格數據必須在夾具建立或執(zhí)行SUT時期注入SUT，或者在結果驗證時期從SUT中檢索。5 表格數據必須在夾具建立或執(zhí)行SUT時期注入SUT，或者在結果驗證時期從SUT中檢索。Fit測試通常沒有集成到開發(fā)人員通過xUnit運行的回歸測試中。相反，這些測試必須單獨運行，如此每次檢

36、入時它們有可能不運行。有些團隊將Fit測試作為其持續(xù)集成構建過程的一部分，以部分解決那個問題。有的團隊報告差不多擁有輔助“客戶”構建服務或運行所有客戶測試的服務器。因此，這些問題差不多上能夠克服的。總的來講，xUnit架構比Fit架構更適合于單元測試；Fit架構比xUnit架構更適合于客戶測試。2. 變體：天真xUnit測試解釋程序當需要作為基于xUnit的腳本測試策略的一部分運行的數據驅動測試的數量較小時，最簡單的實現方式是寫包含循環(huán)的測試方法，該循環(huán)從文件讀取一組輸入數據值以及預期結果。這與將單個參數化測試及其所有調用者轉換為表格測試(參見“參數化測試”)具有相同意義。和表格測試一樣，這種

37、構建數據驅動測試解釋程序的方法會產生具有許多斷言的單個測試用例對象。它有以下幾種結果：整組數據驅動測試將計算為單個測試。因此，將一組參數化測試轉換為單個數據驅動測試會減少執(zhí)行的測試數量。當遇到第一個失敗或錯誤時會停止執(zhí)行數據驅動測試。因此，遺漏了許多缺陷定位。有些xUnit變體同意指定失敗的斷言不中止測試方法的執(zhí)行。需要確保出現失敗時，斷言失敗能講出正在執(zhí)行哪個子測試。在循環(huán)中包含try/catch語句，同時包含測試邏輯然后接著代碼執(zhí)行，如此能夠解決最后兩個問題。然而，仍然需要能夠以一種有意義的方法報告測試結果(例如，“失敗子測試1、3和6以及”)。要更方便地擴充數據驅動測試解釋程序來處理相同

38、數據文件中幾種不同類型的測試，能夠包含“動詞”或“動作單詞”作為數據文件中各條目的一部分。解釋程序能夠依據動作單詞分派給不同的參數化測試。3. 變體：測試套件對象生成器讓測試套件工廠(參見“測試枚舉”)上的suite方法偽造與測試發(fā)覺內置機制相同的測試套件對象結構，就能夠幸免與天真xUnit測試解釋程序相關的“第一次失敗時就停止”那個問題。要如此做，能夠為數據驅動測試文件中的每個條目構建測試用例對象，然后用特定測試的測試數據初始化每個對象6 這與xUnit的內置測試方法發(fā)覺6 這與xUnit的內置測試方法發(fā)覺(參見“測試發(fā)覺”)機制的運行原理類似，但后者同意的是測試數據和測試方法名稱。4. 變

39、體：測試套件對象模擬器構建測試套件對象的方法之一是創(chuàng)建像一個對象那樣運行的測試用例對象。要求運行時該對象會閱讀數據驅動測試文件并重新執(zhí)行所有測試。它必須捕獲參數化測試拋出的所有異常，然后接著執(zhí)行后面的測試。完成后，測試用例對象必須給測試運行器報告測試、失敗和錯誤的準確數量。它也要實現測試運行器依靠的標準測試接口上的其他方法，例如返回“套件”中測試的數量、返回套件中每個測試的名稱和狀態(tài)(關于圖形測試樹探測器，參見“測試運行器”)。18.3.4 啟發(fā)示例假設有一組測試如下所示：def test_extrefsourceXml = expectedHtml = abcgenerateAndVerif

40、yHtml(sourceXml,expectedHtml,)enddef test_testterm_normalsourceXml = expectedHtml = abcgenerateAndVerifyHtml(sourceXml,expectedHtml,)enddef test_testterm_pluralsourceXml = expectedHtml = abcsgenerateAndVerifyHtml(sourceXml,expectedHtml,)end如下定義參數化測試能夠簡化這些測試：def generateAndVerifyHtml( sourceXml, expe

41、ctedHtml,message, &block) mockFile = MockFile.new sourceXml.delete!(t)handler = setupHandler(sourceXml, mockFile )block.call unless block = = nil handler.printBodyContents actual_html = mockFile.output assert_equal_html(expectedHtml, actual_html, message + html output) actual_html end這些測試存在的要緊問題是，這些

42、測試依舊用代碼寫的，而實際上它們之間的唯一不同是用作輸入的數據。18.3.5 重構講明因此，解決方案是將參數化測試的公共邏輯提取到數據驅動測試解釋程序中，并將所有參數集合到任何人都能夠編輯的單個數據文件中。需要寫“主”測試，它明白從哪個文件閱讀測試數據，明白閱讀和分析測試文件的一些邏輯。該邏輯能夠調用現有的參數化測試邏輯，并讓xUnit記錄測試執(zhí)行統計。18.3.6 示例：使用XML數據文件的xUnit數據驅動測試本示例中，使用XML形式文件。每個測試都由test元素組成，它有三個要緊部分：告訴數據驅動測試解釋程序要運行哪種測試邏輯的動作(例如，crossref)。傳遞給SUT的輸入，那個地點

43、是sourceXml元素希望SUT(在expectedHtml元素中)生成的HTML這三個部分包裝在testsuite元素里： crossref abc crossref abc crossref abcs 所有擁有XML編輯器的人都能夠編輯那個XML文件，而不必擔心引入測試邏輯錯誤。數據驅動測試解釋程序封裝用來驗證預期結果的所有邏輯，使用的方法與參數化測試使用的方法相同。出于查看的目的，通過定義樣式表對用戶隱藏了XML的結構。另外，許多XML編輯器會將XML轉換為基于表格的輸入以簡化編輯。為了幸免處理操作XML的復雜性，解釋程序也能夠使用CSV文件作為輸入。18.3.7 示例：使用CSV輸入

44、文件的xUnit數據驅動測試使用CSV文件，前面示例中的測試則如下所示：ID, Action, SourceXml, ExpectedHtml Extref,crossref,abc TTerm,crossref,abc TTerms,crossref,abcs那個解釋程序相對簡單，同時建立在為參數化測試而開發(fā)的邏輯之上。它閱讀CSV文件，并使用Ruby的split函數分析各行。def test_crossrefexecuteDataDrivenTest CrossrefHandlerTest.txt enddef executeDataDrivenTest filename dataFile

45、 = File.open(filename) dataFile.each_line do | line |desc, action, part2 = line.split(,) sourceXml, expectedHtml, leftOver = part2.split(,) if crossref= =action.stripgenerateAndVerifyHtml sourceXml, expectedHtml, desc else # new verbs go before here as elsifsreport_error( unknown action + action.str

46、ip ) end end end除非將generateAndVerifyHtml的實現方式改變?yōu)椴东@斷言失敗和增加失敗計數器，這種數據驅動測試才會在遇到第一個失敗斷言時停止執(zhí)行。而回歸測試能夠同意這種行為，盡管它沒有提供專門好的缺陷定位。18.3.8 示例：使用Fit架構的數據驅動測試假如要進一步操縱用戶的行為，能夠創(chuàng)建Fit“列夾具”，其中有id、action、source XML和expected Html()各列，讓用戶編輯HTML Web頁面(如表18-1所示)。表18-1 使用Fit架構構建的數據驅動測試Com.xunitpattens.fit.CrossrefHandlerFixt

47、ureidactionsource XMLexpected HtrnlOExtrefcrossref?abc?TestTermcrossref?abc?TestTerm Pluralcrossref?abcs?使用Fit時，測試解釋程序是測試專用的Fit夾具類擴充的Fit架構：public class CrossrefHandlerFixture extends ColumnFixture / Input columns public String id;public String action; public String sourceXML;/ Output columnspublic S

48、tring expectedHtml() return generateHtml(sourceXML); Fit架構依據列標題，為Fit表中每一行的每一個單元調用這種夾具類的方法。簡單的名稱解釋為夾具的實例變量(例如id、source XML)。以()結尾的列名稱表示Fit調用的函數，然后將其結果與單元格內容作比較。結果輸出如表18-2所示。這種帶陰影的表格特不便于總結運行測試文件后的結果。表18-2 執(zhí)行Fit測試的結果com. xunitpattems.fit.CrossrefHandlerFixtureidActionsource XMLexpected HtrnlQextrefcros

49、sref?abc?TestTermcrossref?abc?TestTerm Pluralcrossref?abcs? 預期?abc? 實際18.4 測試自動化架構 如何讓編寫和運行不同人寫的測試更方便？能夠使用架構，該架構提供運行測試邏輯所需的所有機制，因此測試作者只需要提供測試專用邏輯就行了。寫和運行自動化測試包含幾個步驟，但關于每個測試而言其中許多步驟都相同。假如每個測試都必須包含這些步驟的實現方式，寫自動化測試就變得專門單調、專門耗時刻、容易出錯同時成本專門高。使用測試自動化架構是一種最小化寫全自動化測試努力的方法。圖18-4 測試自動化架構示意圖18.4.1 運行原理能夠構建一種架構

50、，它實現運行測試套件和記錄結果所需的所有機制。這些機制能夠找出單個測試、將它們組合為測試套件、依次執(zhí)行每個測試、驗證預期結果、收集和報告測試失敗或錯誤以及發(fā)生失敗或錯誤時能夠清除它們。這種架構提供了一種方法來插入并運行測試自動化人員寫的測試專用行為。18.4.2 如此做的緣故構建可重復且健壯的全自動化測試，該過程比寫調用SUT的測試腳本更復雜。需要應付成功情況和錯誤情況，以及預期結果與意外結果。需要建立和拆卸測試夾具，需要指定運行哪個(哪些)測試，運行一組測試后還要報告結果。構建全自動化測試需要的努力可能是測試自動化的嚴峻阻礙。只提供實現最常見功能性的架構，能夠大大降低啟動成本，學習使用架構時

51、，才需要付出唯一的入門成本。同樣，假如實現公共協議還能夠降低成本，例如xUnit，在熟悉第一個架構之后，更容易學習第二或者第三個架構。使用架構也有助于將運行測試所需邏輯的實現方式與測試邏輯隔離開。這種方法有助于減少測試碼復制和最小化模糊測試發(fā)生的概率。它還能夠確保不同測試自動化人員寫的測試能夠方便地在單個測試運行中運行，并能夠提供測試結果的單獨報告。18.4.3 實現方式講明有許多種測試自動化架構可用，既有商業(yè)廠商的，也有開源資源。它們可分為兩大類：“機器人用戶”測試工具和腳本測試。后面一類可進一步細分為測試自動化架構下的xUnit和數據驅動測試家族。1. 變體：機器人用戶測試架構許多第三方測

52、試自動化工具能夠通過用戶界面測試應用程序。其中大多數使用“記錄與回放”測試隱喻。這種隱喻提供了一些特不誘人的營銷材料，因為記錄測試會話時，它讓測試自動化就像手動運行一些測試那樣簡單。這種機器人用戶測試工具由兩個要緊部分組成：“測試記錄器”，它監(jiān)控和記錄用戶與SUT之間的交互；“測試運行器”，它執(zhí)行記錄的測試。大多數測試自動化工具也是架構，這些架構支持許多“構件識不器”插件。大多數商業(yè)工具都有一批內置的構件識不器。2. 變體：測試自動化架構的xUnit家族大多數單元測試工具屬于自動化手寫腳本測試(參見“腳本測試”)的測試架構的xUnit家族。xUnit差不多移植到(或者重新開發(fā))當前大多數編程語

53、言。單元測試架構的xUnit家族由幾個要緊組件組成。最顯而易見的是測試運行器，能夠從命令行或者作為圖形測試運行器(參見“測試運行器”)調用它。它構建測試用例對象，將它們集合到測試套件對象里，并調用各種測試方法。xUnit架構的其他要緊組件是內置斷言方法庫，這些斷言方法在測試方法里使用，用來指定各個測試的預期結果。3. 變體：數據驅動測試架構數據驅動測試架構能夠插入解釋程序，這些解釋程序明白如何執(zhí)行特定類型的測試步驟。實際上，這種靈活性用“動詞”和對象擴充輸入文件的格式。這種架構還提供讀入文件的測試運行器，遇到相應數據格式時能夠將控件傳遞給插件，并能夠記錄測試運行的統計數據。數據驅動測試架構家族

54、最聞名的成員是Fit，它讓測試自動化人員能夠用表的形式寫測試，而且能夠“插入”夾具類，這些類明白如何解釋特定格式的表。18.4.4 示例：測試自動化架構測試自動化架構在某種程度上大概與各種可能的自動化測試方法不同。要理解這些變體，請參考記錄測試、腳本測試和數據驅動測試，并查看各自測試自動化架構的示例。18.4.5 高級閱讀xUnit測試自動化架構一些最常見的示例有JUnit(Java)、SUnit (Smalltalk)、CppUnit (C+)、NUnit(所有.NET語言)、runit (Ruby)、PyUnit(Python)和VbUnit(Visual Basic)。在上能夠找到最新的

55、完整列表，以及可用擴展(如HttpUnit、Cactus)的列表。其他開源測試自動化架構包括Fit、Canoo Web-Test和Watir。商業(yè)測試自動化架構包括QTP、BPT和 eCATT等。在Test-Driven DevelopmentBy Example TDD-BE中，Kent Beck通過用Python構建測試自動化架構來講明TDD。在他比作“自己進行腦外科手術”的方法中，他使用新興測試自動化架構來運行自己為各種新性能所寫的測試。這一應用是TDD和步步為營法的最好示例。18.5 最小夾具(也稱為最小上下文) 應該使用哪種夾具策略？應該盡可能為每個測試使用最小、最簡單的夾具。圖18

56、-5 最小夾具示意圖每個測試都需要某種類型的測試夾具。理解測試的關鍵是理解測試夾具，并認識到它如何阻礙測試的預期結果。假如夾具又小又簡單，那么測試就更容易理解。18.5.1 如此做的緣故最小夾具關于實現作為文檔測試和幸免緩慢測試至關重要。使用最小夾具的測試總是比使用包含不必要或不相關信息的夾具的測試更容易理解。不管使用新奇夾具依舊共享夾具，結果總是如此，盡管使用共享夾具構建的最小夾具需要的努力更高，因為它必試。18.5.2 實現方式講明設計的夾具只包含那些關于表示測試驗證的行為絕對必不可少的對象。換句話講，確實是“假如對象對理解測試無關緊要，那么不要在夾具中包含它就至關重要。”要構建最小夾具，

57、就要“殘酷地”從夾具中刪除那些無助于測試傳達SUT行為的東西。能夠考慮兩種形式的“最小化”：能夠刪除整個對象。也確實是講，不構建對象作為夾具的一部分。假如對象對證明SUT的行為無關緊要，就全然不用包含它。假如對象的多余屬性無助于理解預期行為，就能夠將它們隱藏起來。要想明白作為夾具一部分的對象是否必不可少，一種簡單方法確實是刪除它。假如導致測試失敗，那么對象在某種程序上可能是必需的。因此，假如作為我們不感興趣的某個方法的參數或者從未使用的屬性(盡管由于某種緣故需要該屬性所屬的對象)，它可能是必需的。包含這些類型的對象作為夾具建立的一部分確信會導致模糊測試。能夠用下面兩種方法之一刪除這些不必要的對

58、象：(1)隱藏它們；(2)同意啞元對象或使用實體鏈裁剪(參見“測試樁”)來刪除這些對象。然而，假如SUT執(zhí)行測試中的邏輯時確實訪問該對象，那么就要求包含該對象作為測試夾具的一部分。假如確定對象關于測試執(zhí)行必不可少，那么現在就要看看該對象關于理解測試是不是有用。假如將它初始化為“幕后”，理解測試會變得更難嗎？假如作為奇妙訪客(參見“模糊測試”)，該對象會導致模糊測試嗎？假如是，就要讓該對象保持可見。邊界值確實是如此一個專門好的例子，在其中需要保持具有邊界值的對象或屬性可見。假如確定對象或屬性對理解測試無關緊要，就應該從測試方法中刪除它，但不需要從測試夾具中刪除它。創(chuàng)建方法是實現這一目標的常見方法

59、。使用創(chuàng)建方法用有意義的默認值填充所有“無關緊要”的屬性，能夠隱藏不阻礙測試結果但構造對象時又必需的屬性。也能夠在創(chuàng)建方法內隱藏需要的依靠對象的創(chuàng)建，例如當寫需要格式不良好的對象作為輸入的測試時(使用無效輸入測試SUT)。在這種情況下，為了弄清晰那個問題，能夠顯示傳遞給SUT的對象的所有有效屬性，應該有許多如此的無關屬性。只是，需要關注無效屬性。要如此做，能夠調用創(chuàng)建方法來構造有效對象，然后用無效值(想用那個值驗證SUT是否會正確處理)取代單個屬性，如此用最少的代碼通過一種壞屬性模式(參見“派生值”)來構建格式不良好的對象。18.6 標準夾具(也稱為標準上下文) 應該使用哪種夾具策略？能夠重復

60、使用跨多個測試的測試夾具設計。要執(zhí)行自動化測試，需要易于理解且完全確定的測試夾具。為每個測試設計自定義測試夾具需要額外努力。標準夾具能夠再利用多個測試中相同的夾具設計，且無需共享相同的夾具實例。圖18-6 標準夾具示意圖18.6.1 運行原理標準夾具關乎態(tài)度勝過關乎技術。它要求在測試過程中盡早決定設計一些或許多測試都能夠使用的標準夾具，而不是從單獨設計的測試中提取公共夾具。從某種意義上講，標準夾具是整個測試套件的測試夾具“預先進行大量設計(Big Design Upfront)”的結果。因此，能夠使用這種公共測試夾具設計定義具體的測試。標準夾具的選擇與新奇夾具和共享夾具之間的選擇無關。在定義上