【正文】 出到其他平臺的經(jīng)驗。圖182 腳本測試示意圖自動化測試有幾個目的。它們有助于歸檔軟件的行為。如何準備自動化測試腳本，這將影響可以將它們用于什么目的、它們對SUT中的變更有多健壯以及準備它們需要多少技能與努力。 運行原理通過寫測試程序來自動化測試，這些測試程序為了執(zhí)行其功能性而與SUT交互。這些測試程序通常稱為“測試腳本”，以便與它們測試的產(chǎn)品代碼區(qū)分開來。因為它更容易從用相同編程語言寫的軟件中直接訪問單個單元?？蛻魷y試稍微有些復(fù)雜。記錄測試不能很好滿足這種需要，因為沒有用來記錄它們的應(yīng)用程序時它難以記錄測試。項目上的大多數(shù)業(yè)務(wù)用戶不可能對學(xué)習(xí)如何準備腳本測試感興趣。一種定義數(shù)據(jù)驅(qū)動測試的開源架構(gòu)是Fit及FitNesse。在現(xiàn)有遺留應(yīng)用程序3 在測試驅(qū)動程序中，遺留應(yīng)用程序是缺乏自動化測試安全網(wǎng)的系統(tǒng)。隨后可以準備可測試應(yīng)用程序的腳本測試?，F(xiàn)在，我們更喜歡使用測試自動化架構(gòu)來寫腳本測試，例如，用與SUT相同的語言寫的xUnit。要最小化手動干預(yù)，各測試方法應(yīng)該實現(xiàn)自檢測試(也就是可重復(fù)的測試)。final BigDecimal EXTENDED_PRICE = BASE_PRICE。Invoice invoice = createInvoice(customer)。// Verify OuteLineItem expected =createLineItem( QUAN_ONE, NO_CUST_DISCOUNT,EXTENDED_PRICE, PRODUCT, invoice)。}public void testChangeQuantity_severalQuantity(){final int ORIGINAL_QUANTITY = 3。final BigDecimal BASE_PRICE =( new BigDecimal(NEW_QUANTITY))。// Set Up FixtureCustomer customer = createACustomer(CUST_DISCOUNT_PC)。Product product = createAProduct( UNIT_PRICE)。// Exercise SUT(product, NEW_QUANTITY)。assertContainsExactlyOneLineItem( invoice, expected )。稱它們?yōu)槟_本測試的不利之處是，該術(shù)語容易將手動測試過程中應(yīng)遵循的腳本與不用腳本的測試(例如探測測試)相混淆。最好可以從[TDDBE] 或[TDDAPG]開始。圖183 數(shù)據(jù)驅(qū)動測試示意圖測試可能有很多重復(fù)，不僅因為必須多次運行相同測試，而且因為許多測試只是略有不同。每個測試都由相同的步驟組成。數(shù)據(jù)驅(qū)動測試可以獲得好的覆蓋率同時又能最小化需要編寫和維護的測試碼的數(shù)量。可以將隨著測試改變而改變的數(shù)據(jù)放置到數(shù)據(jù)驅(qū)動測試文件中，解釋程序讀取該文件來執(zhí)行測試。第一階段，解釋程序檢索文件中的測試數(shù)據(jù)，然后使用文件中的數(shù)據(jù)建立測試夾具。第三階段，它比較SUT生成的實際結(jié)果(例如返回值、測試后狀態(tài))與文件的預(yù)期結(jié)果。第四階段，解釋程序進行必要的夾具拆卸，然后繼續(xù)執(zhí)行文件中的下一個測試。Fit是寫數(shù)據(jù)驅(qū)動測試架構(gòu)的普遍示例。然而，它也可以用作腳本測試策略的一部分。數(shù)據(jù)驅(qū)動測試是讓業(yè)務(wù)人員寫自動化測試的理想策略。當有許多不同的數(shù)據(jù)值，同時又希望使用這些值來執(zhí)行SUT(其中每個數(shù)據(jù)值都要執(zhí)行相同系列的步驟)時，可以考慮使用數(shù)據(jù)驅(qū)動測試作為腳本測試的一部分。也可能在具有不同數(shù)據(jù)值的不同序列中安排一組標準步驟，和在遞增的表格測試(參見“參數(shù)化測試”)中一樣。決定是否使用數(shù)據(jù)驅(qū)動測試的另一個因素，是配置數(shù)據(jù)是不是硬編碼或驅(qū)動要測試的行為。這種行為很不正常，因為它表示，當改變配置數(shù)據(jù)庫中的數(shù)據(jù)時，必須將變更提交給源代碼庫[SCM]4 當然，也應(yīng)該管理在版本控制庫里的測試數(shù)據(jù)，但這個主題在另一本書中討論，詳情請參見[RDb]。讓測試變成數(shù)據(jù)驅(qū)動，對配置數(shù)據(jù)或元對象的變更就由對數(shù)據(jù)驅(qū)動測試的變更驅(qū)動，這是一種更正常的關(guān)系。使用數(shù)據(jù)驅(qū)動測試作為獨立的測試策略通常使用開源工具(例如Fit)或商業(yè)記錄測試工具(例如QTP)。不管選擇哪種策略，如果可能，都應(yīng)該使用相應(yīng)的測試自動化架構(gòu)。這兩個部分都應(yīng)該保持在版本控制之下，以便可以知道它們隨著時間推移如何演變，同時還允許收回所有錯誤的變更。給用戶提供數(shù)據(jù)驅(qū)動測試文件授權(quán)工具(例如FitNesse)可以讓這種操作透明，或者可以建立“用戶友好”庫，例如剛好支持版本控制的文檔管理系統(tǒng)。沒有這樣做可能導(dǎo)致缺陷進入未檢測到的軟件，一旦檢測到缺陷，就要付出更多努力來檢修。一種選擇是保持兩組輸入文件，將通過的測試從“仍是紅色”文件遷移到“都是綠色”文件中，該文件作為自動構(gòu)建過程一部分用于回歸測試。Ward Cunningham最初將Fit這種架構(gòu)作為在自動化測試中包含業(yè)務(wù)用戶的方法。Fit由兩部分組成：架構(gòu)和用戶創(chuàng)建的夾具。它在每個表的左上單元查找夾具類名，然后搜索該類的可執(zhí)行測試?？梢灾貙懠軜?gòu)定義的方法來指定表中各單元出現(xiàn)的情況。Fit表也可以包含SUT的預(yù)期結(jié)果。然而，與xUnit中的斷言方法不一樣，F(xiàn)it在遇到第一個不匹配預(yù)期值的值時不會終止測試。使用Fit有幾個好處：q 與構(gòu)建自己的測試解釋程序[GOF]相比，要寫的代碼更少。q 測試不會在遇到第一個失敗的斷言時停止。q 照現(xiàn)在的樣子，有大量夾具類型可以用來子類化或使用。因此需要將各種測試邏輯轉(zhuǎn)換為表格表示法，這不太合適，特別是對習(xí)慣于從過程思考的開發(fā)人員而言尤其如此。q 這些測試在每個測試中都要采用相同的SUT交互邏輯5 表格數(shù)據(jù)必須在夾具建立或執(zhí)行SUT階段注入SUT，或者在結(jié)果驗證階段從SUT中檢索。要運行幾種不同類型的測試，很可能就必須為每種類型的測試構(gòu)建一個或多個不同的夾具。雖然現(xiàn)在有許多不同夾具類型可以用來子類化或使用，但這種使用方法與要求開發(fā)人員學(xué)習(xí)以便完成任務(wù)的方法不同。q Fit測試通常沒有集成到開發(fā)人員通過xUnit運行的回歸測試中。有些團隊將Fit測試作為其持續(xù)集成構(gòu)建過程的一部分，以部分解決這個問題。當然，這些問題都是可以克服的。2. 變體：天真xUnit測試解釋程序當需要作為基于xUnit的腳本測試策略的一部分運行的數(shù)據(jù)驅(qū)動測試的數(shù)量較小時，最簡單的實現(xiàn)方式是寫包含循環(huán)的測試方法，該循環(huán)從文件讀取一組輸入數(shù)據(jù)值以及預(yù)期結(jié)果。和表格測試一樣，這種構(gòu)建數(shù)據(jù)驅(qū)動測試解釋程序的方法會產(chǎn)生具有許多斷言的單個測試用例對象。因此，將一組參數(shù)化測試轉(zhuǎn)換為單個數(shù)據(jù)驅(qū)動測試會減少執(zhí)行的測試數(shù)量。因此，遺漏了許多缺陷定位。q 需要確保出現(xiàn)失敗時，斷言失敗能說出正在執(zhí)行哪個子測試。然而，仍然需要能夠以一種有意義的方法報告測試結(jié)果(例如，“失敗子測試3和6以及……”)。解釋程序可以依據(jù)動作單詞分派給不同的參數(shù)化測試。要這樣做，可以為數(shù)據(jù)驅(qū)動測試文件中的每個條目構(gòu)建測試用例對象，然后用特定測試的測試數(shù)據(jù)初始化每個對象6 這與xUnit的內(nèi)置測試方法發(fā)現(xiàn)(參見“測試發(fā)現(xiàn)”)機制的運行原理類似，但后者接受的是測試數(shù)據(jù)和測試方法名稱。構(gòu)建測試套件時，該對象知道如何執(zhí)行具有加載數(shù)據(jù)的參數(shù)化測試。因此，可以讓測試運行器以正常方式計算測試、錯誤及失敗。要求運行時該對象會閱讀數(shù)據(jù)驅(qū)動測試文件并重新執(zhí)行所有測試。完成后，測試用例對象必須給測試運行器報告測試、失敗和錯誤的準確數(shù)量。 啟發(fā)示例假設(shè)有一組測試如下所示：def test_extrefsourceXml = extref id=39。 /expectedHtml = a href=39。abc/agenerateAndVerifyHtml(sourceXml,expectedHtml,extref)enddef test_testterm_normalsourceXml = testterm id=39。/expectedHtml = a href=39。abc/agenerateAndVerifyHtml(sourceXml,expectedHtml,testterm)enddef test_testterm_pluralsourceXml = testterms id=39。/expectedHtml = a href=39。abcs/agenerateAndVerifyHtml(sourceXml,expectedHtml,plural)end如下定義參數(shù)化測試可以簡化這些測試：def generateAndVerifyHtml( sourceXml, expectedHtml,message, amp。 重構(gòu)說明當然，解決方案是將參數(shù)化測試的公共邏輯提取到數(shù)據(jù)驅(qū)動測試解釋程序中，并將所有參數(shù)集合到任何人都可以編輯的單個數(shù)據(jù)文件中。該邏輯可以調(diào)用現(xiàn)有的參數(shù)化測試邏輯，并讓xUnit記錄測試執(zhí)行統(tǒng)計。每個測試都由test元素組成，它有三個主要部分：q 告訴數(shù)據(jù)驅(qū)動測試解釋程序要運行哪種測試邏輯的動作(例如，crossref)。abc39。39。abc39。39。abc39。39。數(shù)據(jù)驅(qū)動測試解釋程序封裝用來驗證預(yù)期結(jié)果的所有邏輯，使用的方法與參數(shù)化測試使用的方法相同。另外，許多XML編輯器會將XML轉(zhuǎn)換為基于表格的輸入以簡化編輯。 示例：使用CSV輸入文件的xUnit數(shù)據(jù)驅(qū)動測試使用CSV文件，前面示例中的測試則如下所示：ID, Action, SourceXml, ExpectedHtml Extref,crossref,extref id=39。/,a href=39。abc/a TTerm,crossref,testterm id=39。/,a href=39。abc/a TTerms,crossref,testterms id=39。/,a href=39。abcs/a這個解釋程序相對簡單，并且建立在為參數(shù)化測試而開發(fā)的邏輯之上。def test_crossrefexecuteDataDrivenTest enddef executeDataDrivenTest filename dataFile = (filename) do | line |desc, action, part2 = (,) sourceXml, expectedHtml, leftOver = (,) if crossref= =generateAndVerifyHtml sourceXml, expectedHtml, desc else new verbs go before here as elsif39。而回歸測試可以接受這種行為，雖然它沒有提供很好的缺陷定位。表181 使用Fit架構(gòu)構(gòu)建的數(shù)據(jù)驅(qū)動測試idactionsource XMLexpected HtrnlOExtrefcrossrefextref id=39。 /a href=39。?abc?/aTestTermcrossreftestterm id=39。 /a href=39。?abc?/aTestTerm Pluralcrossreftestterm id=39。 suffix=s/a href=39。?abcs?/a使用Fit時，測試解釋程序是測試專用的Fit夾具類擴充的Fit架構(gòu)：public class CrossrefHandlerFixture extends ColumnFixture { // Input columns public String id。 public String sourceXML。 }}Fit架構(gòu)依據(jù)列標題，為Fit表中每一行的每一個單元調(diào)用這種夾具類的方法。以()結(jié)尾的列名稱表示Fit調(diào)用的函數(shù)，然后將其結(jié)果與單元格內(nèi)容作比較。這種帶陰影的表格非常便于總結(jié)運行測試文件后的結(jié)果。abc39。abc .html39。abcd39。 abc .html39。abc39。39。abc. html39。寫和運行自動化測試包含幾個步驟，但對于每個測試而言其中許多步驟都相同。使用測試自動化架構(gòu)是一種最小化寫全自動化測試努力的方法。這些機制能夠找出單個測試、將它們組合為測試套件、依次執(zhí)行每個測試、驗證預(yù)期結(jié)果、收集和報告測試失敗或錯誤以及發(fā)生失敗或錯誤時能夠清除它們。 這樣做的原因構(gòu)建可重復(fù)且健壯的全自動化測試，該過程比寫調(diào)用SUT的測試腳本更復(fù)雜。需要建立和拆卸測試夾具，需要指定運行哪個(哪些)測試，運行一組測試后還要報告結(jié)果。只提供實現(xiàn)最常見功能性的架構(gòu)，可以大大降低啟動成本，學(xué)習(xí)使用架構(gòu)時，才需要付出唯一的入門成本。使用架構(gòu)也有助于將運行測試所需邏輯的實現(xiàn)方式與測試邏輯隔離開。它還可以確保不同測試自動化人員寫的測試可以方便地在單個測試運行中運行，并可以提供測試結(jié)果的單獨報告。它們可分為兩大類：“機器人用戶”測試工具和腳本測試。1. 變體：機器人用戶測試架構(gòu)許多第三方測試自動化工具可以通過用戶界面測試應(yīng)用程序。這種隱喻提供了一些非常誘人的營銷材料，因為記錄測試會話時，它讓測試自動化就像手動運行一些測試那樣簡單。大多數(shù)測試自動化工具也是架構(gòu)，這些架構(gòu)支持許多“構(gòu)件識別器”插件。2. 變體：測試自動化架構(gòu)的xUnit家族大多數(shù)單元測試工具屬于自動化手寫腳本測試(參見“腳本測試”)的測試架構(gòu)的xUnit家族。單元測試架構(gòu)的xUnit家族由幾個主要組件組成。它構(gòu)建測試用例對象，將它們集合到測試套件對象里，并調(diào)用各種測試方法。3. 變體：數(shù)據(jù)驅(qū)動測試架構(gòu)數(shù)據(jù)驅(qū)動測試架構(gòu)可以插入