專利名稱：一種自動化測試輔助系統(tǒng)及相應的軟件自動測試方法
技術領域：
本發(fā)明涉及一種計算機軟件測試技術，尤其是一種對某個應用軟件的功能的執(zhí)行可靠性進行自動測試的測試技術。
背景技術：
目前對功能軟件或應用軟件的自動測試有多種方法，主要方法有一、捕捉/回放機制直接使用商業(yè)軟件腳本程序的編寫測試案例100a用商業(yè)測試軟件200a對被測軟件300a進行自動測試，如

圖1所示。使用這種方法，測試人員不僅需要熟悉測試案例，而且需要熟悉商業(yè)軟件腳本程序的編寫，同時編寫的測試腳本也存在正確性驗證的問題。因此會耗費大量的時間在腳本維護上，而不是專注于應用軟件的測試本身；二、功能分解法部分利用數(shù)據(jù)驅(qū)動引擎(Data Driven Engine)框架100c對案例100b進行測試，如圖2所示。按照該框架所提供的案例模板和關鍵字，使用通用的商業(yè)軟件(如EXCEL)編寫案例，案例中包括了描述測試過程中進行操作所需要的控制數(shù)據(jù)、測試輸入數(shù)據(jù)、預期結果數(shù)據(jù)，測試人員只需要熟悉案例編寫方法(如案例的關鍵字等)，而不必涉及測試腳本的修改和維護，也就是將測試設計和測試自動化看成為兩個互相分開的過程。
把所有的測試任務分解為最基本的功能，將數(shù)據(jù)和功能區(qū)分開，引入了層級式的架構，使用結構化和模塊化的設計。包括驅(qū)動腳本、測試案例腳本、商業(yè)功能腳本、子程序腳本、用戶定義功能。
例如測試“進行一次支付，并驗證帳戶數(shù)據(jù)的準確性”。
如果使用“功能分解方法”，則這個案例就可能被分解為以下商業(yè)功能，然后就每個商業(yè)功能分別編寫腳本①導航從主菜單進入支付屏幕②進行一次支付
③驗證現(xiàn)金流的正確性④退回主要菜單⑤接入帳戶系統(tǒng)⑥驗證帳戶系統(tǒng)更新⑦退回到主菜單這樣的測試方法，其優(yōu)點非常明顯1.應用被分解為若干個基本的“商業(yè)功能”，只要對這些商業(yè)功能編寫腳本，而具體的數(shù)據(jù)則通過輸入數(shù)據(jù)文件和驗證數(shù)據(jù)文件進行。如果應用改變了，只需要更改這些“商業(yè)功能腳本”即可。
2.“商業(yè)功能腳本”是針對測試每一個基本商業(yè)功能的，因此，很容易組合這些商業(yè)功能腳本以實現(xiàn)一系列更為復雜的操作。
方法二相比于方法一已經(jīng)在測試用的案例編寫上取得了很大的進步，但是，還存在如下不足之處1.每一個商業(yè)功能都需要一個腳本，一旦有上百個商業(yè)功能的話，就需要上百個腳本；2.一旦改動測試集，就需要改動成百上千個輸入數(shù)據(jù)文件/驗證數(shù)據(jù)文件；3.不僅需要各種腳本，而且每個“商業(yè)功能腳本”往往需要與之對應的輸入數(shù)據(jù)文件/驗證數(shù)據(jù)文件；4.使用文本文件編寫輸入數(shù)據(jù)文件/驗證數(shù)據(jù)文件，很容易犯錯誤。
三、關鍵字驅(qū)動方法(如測試計劃驅(qū)動方法TEST PLAN DRIVEN)屬于DDE(數(shù)據(jù)驅(qū)動引擎框架)的一種，按照其所提供的模板、關鍵詞，使用EXCEL文件編寫測試案例。在測試案例中包括進行操作所需要的控制數(shù)據(jù)、輸入測試數(shù)據(jù)、預期結果數(shù)據(jù)等。
腳本編寫人員與測試案例編寫人員可以獨立。由前者負責將案例中的關鍵詞轉(zhuǎn)換為商業(yè)測試軟件的腳本，熟悉商業(yè)測試軟件腳本的編寫，而后者只需要關注案例的編寫，即只需要熟悉案例模板的格式。
該方法主要是由如下模塊實現(xiàn)的
驅(qū)動腳本①進行框架的初始化；②調(diào)用特殊應用的控制腳本，將測試案例的名稱傳送給控制腳本(測試案例是以TAB分割的文本文件格式)；控制腳本①讀入和處理以TAB分割的文本文件；②在關鍵詞和數(shù)據(jù)之間建立一種對應關系；③根據(jù)關鍵詞調(diào)用功能腳本；功能腳本①處理從“控制腳本”傳送過來的輸入序列②執(zhí)行特定的動作(如進行一次按鍵操作、輸入一個數(shù)據(jù)、驗證一個數(shù)據(jù)等)；③報告一些錯誤情況；該方法三與方法二相比，由于采用了完全的DDE技術，其有兩種主要的實現(xiàn)方法其一案例不采用結構化的編寫，即在案例中直接明確每一步的具體操作，這樣即使在不同的案例中包含相同的幾個步驟也只能重復輸入，導致使編寫案例重復性太大，而且案例維護也相當不方便；其二、案例編寫采用結構化方法進行，即將基本的功能抽象出來，封裝為流程，然后采用案例調(diào)用流程的方法，這樣就大大簡化了案例編寫的復雜性。由于采用了以上的結構化設計技術，其后果必然在每次測試的時候，需要把所有的流程都裝入到內(nèi)存中，大大增加了系統(tǒng)的開銷，也增加了案例測試的時間。而事實上，每次測試的時候，并不會涉及所有的案例和流程，而僅僅涉及其中一部分。如此大的系統(tǒng)開銷，使案例的執(zhí)行速度顯著降低。

發(fā)明內(nèi)容
本發(fā)明的目的是要解決如下技術問題，利用現(xiàn)有的商業(yè)化測試軟件，可以更方便的生成測試案例，并且高效準確地完成特定的功能測試任務。
①案例編寫的獨立性要求將案例編寫相對獨立于商業(yè)測試軟件腳本的編寫；②采用案例調(diào)用流程的方法，增加了案例維護的方便性③降低了內(nèi)存的占用率，提高了案例執(zhí)行的效率④測試正確性要求/對例外情況的處理。
本發(fā)明的主要技術方案是①采用了DDE數(shù)據(jù)驅(qū)動引擎技術，使案例編寫人員與測試腳本維護人員相對獨立；②定義了一定案例格式，采用了結構化的案例編寫方法。這樣就可以在具體測試應用改變的情況下不改動所有的案例文件，只需要改動調(diào)用流程的順序或已經(jīng)輸入數(shù)據(jù)的數(shù)值就可以了。因為“流程”定義了一系列基本操作的集合，即某個功能的測試需要使用若干個測試案例，而每個測試案例則由若干“基本操作”和“流程”的組成，而一個“流程”是若干個“基本操作”的集合，參見附圖3。通過“案例”調(diào)用“流程”和“基本操作”，“流程”調(diào)用“基本操作”的方法實現(xiàn)測試案例“結構化”。
③采用了案例的動態(tài)執(zhí)行和延遲裝載技術——即把案例名(流程名)、案例模板(流程模板)的裝入與具體的案例數(shù)據(jù)(流程數(shù)據(jù))的裝入分為兩步進行。即將案例測試區(qū)分為案例初始化和案例執(zhí)行兩步。相比于一次裝入全部流程的方法，采用本發(fā)明，相關測試速度可以提高10倍到20倍。
本發(fā)明的系統(tǒng)結構如下一種自動化測試輔助系統(tǒng)軟件測試系統(tǒng)，用來驅(qū)動商業(yè)測試軟件，由如下模塊組成a)動態(tài)執(zhí)行控制模塊，b)案例調(diào)度模塊，c)語法分析模塊，d)文件接口，e)測試執(zhí)行軟件接口，f)測試管理工具接口；其中，本系統(tǒng)測試所需要的案例文件、流程文件和案例測試的執(zhí)行序列文件，均通過所述的文件接口讀入到系統(tǒng)運行的內(nèi)存；測試執(zhí)行軟件接口連接到商業(yè)測試執(zhí)行軟件并驅(qū)動該商業(yè)測試軟件，測試管理工具接口連接到測試管理工具；動態(tài)執(zhí)行控制模塊一端與案例調(diào)度模塊連接，另一端分別連接到語法分析模塊、測試執(zhí)行軟件接口、測試管理工具接口，通過調(diào)用案例調(diào)度模塊對案例進行讀入，調(diào)用語法分析模塊對案例進行分析、執(zhí)行，并轉(zhuǎn)換為相應的商業(yè)測試軟件腳本，通過測試執(zhí)行軟件接口驅(qū)動商業(yè)測試軟件，將執(zhí)行結果通過測試管理工具接口記載到測試管理工具中。
使用本發(fā)明自動化測試輔助系統(tǒng)的軟件自動測試方法主要包括如下步驟a)初始化裝載；b)進行案例調(diào)度；c)分析案例、加載案例數(shù)據(jù)；d)執(zhí)行案例并生成腳本函數(shù)供商業(yè)測試軟件進行測試；e)將測試結果與期望數(shù)據(jù)進行比較；f)寫日志文件，同時將運行結果輸入到測試管理工具。
其中的初始化裝載包括如下內(nèi)容把系統(tǒng)運行所需要的配置文件的相關參數(shù)調(diào)入內(nèi)存，包含了案例文件名、流程文件名、案例執(zhí)行序列文件名、跟被測軟件相關的參數(shù)，和跟測試管理工具相關的參數(shù)，分別根據(jù)案例文件名和流程文件名讀入案例文件和流程文件，對其中的案例模板部分進行分析，同時也對流程文件中的流程模板進行分析，(但不裝入案例數(shù)據(jù)或者流程數(shù)據(jù))，根據(jù)案例執(zhí)行序列文件名把案例執(zhí)行序列調(diào)入內(nèi)存。
所述的案例文件、流程文件和案例執(zhí)行序列文件可以是存放在多個文件中，也可以存放在一個文件的多個不同的工作表中。
所述的案例調(diào)度是由動態(tài)執(zhí)行控制模塊進行案例調(diào)度。
所述的案例執(zhí)行序列中記載了該序列要執(zhí)行的案例是屬于哪個測試集的。
對其中的案例模板部分進行分析包括對該模板的指令序列進行初步分析，在內(nèi)存中形成案例模板與案例模板指令序列之間的對應關系。還包括對基于每個案例模板的案例進行識別，在內(nèi)存中形成案例、案例模板、案例在案例文件中的位置之間的對應關系。
同樣地，還包括對該流程的指令序列進行初步分析，在內(nèi)存中形成流程模板與流程模板指令序列之間的對應關系；對基于每個流程模板的流程進行識別，在內(nèi)存中形成流程、流程模板、流程在流程文件中的位置之間的對應關系。
所述的分析案例、加載案例數(shù)據(jù)指判斷案例數(shù)據(jù)是否已經(jīng)裝載到內(nèi)存中，并根據(jù)分析結果加載案例數(shù)據(jù)，該步驟由動態(tài)執(zhí)行控制模塊來完成的。
本發(fā)明的測試方法中，所述的案例調(diào)度也可以由測試管理工具進行，對執(zhí)行失敗的案例或者需要重新運行的案例，可以使用測試管理工具方便地選擇以構成下一次的案例執(zhí)行序列，從而實現(xiàn)非人工輸入案例執(zhí)行序列，從而使系統(tǒng)的自動化程度更高，因為通過測試管理工具，案例執(zhí)行序列可以自動生成，并且可以靈活組合。
本發(fā)明的測試案例生成方法如下采用結構化的案例編寫方式，減少了案例編寫中的重復工作量，并且提高了案例的可重復性。
基于案例的動態(tài)執(zhí)行和延遲裝載技術，該系統(tǒng)在案例的編寫方式上采用了對操作流程的復用機制，具體如下引入類似于程序設計中過程調(diào)用的語義，在編寫案例的時候，如果每次均需執(zhí)行相同的一系列的操作步驟，就可以將這一系列操作步驟抽象出來，定義稱為一個流程模板，每一組具有不同的輸入數(shù)據(jù)但與具有相同操作步驟的集合定義為不同的流程，這些流程同屬于一個流程模板，先編寫這些流程與流程模板，然后在案例編寫中，調(diào)用已經(jīng)定義好的流程，從而既簡化了案例的編寫過程，增加了案例的可維護性，同時也能提高了案例的執(zhí)行速度，減少了案例執(zhí)行過程中的內(nèi)存消耗。
案例執(zhí)行序列定義了需要執(zhí)行了案例名稱等數(shù)據(jù)，根據(jù)其顯示的案例名稱調(diào)用相應的案例，其基本結構如表1
表1

其中，“是否運行標志”表示本次測試該案例是否需要運行，使用該標志可以避免每次輸入案例名，直接對該標志進行修改就可以便捷地修改需要運行的測試案例；“所屬測試集”則根據(jù)功能的不同將所有的測試案例分解為不同的測試集，在配置文件中可以設置本次需要執(zhí)行的測試集，從而方便地實現(xiàn)某類功能的批量測試；“案例名稱”則與“案例文件”中的案例名稱相對應，根據(jù)該名稱既可以到內(nèi)存中查找該案例是否已經(jīng)裝載，也可以到案例文件中查找相關的案例數(shù)據(jù)；“案例描述”則簡單地描述該測試案例的測試目的。
案例文件則定義了需要測試案例的名稱、操作步驟(調(diào)用流程或直接執(zhí)行基本操作)，其結構舉例如表2表2

如表2所示，“案例文件”主要包括了案例模板、案例數(shù)據(jù)、案例名等組成?！鞍咐０濉笔前咐慕Y構，該結構定義了案例操作的關鍵詞，即每一步執(zhí)行的操作本身，并不涉及具體數(shù)據(jù)(如“調(diào)用流程關鍵詞”、“賦值關鍵詞”，僅僅記錄的是進行什么操作，而不記錄調(diào)用的流程名稱、賦予的具體數(shù)值是多少)，在案例測試的初始化裝載時會對測試案例模板進行分析，在上表中的從上往下一到四行就可以被認為是一個案例模板，通過記錄案例與案例模板的對應關系，就可以知道該案例的第一列是“案例名”、第二列表示“測試的目的”、第五列表示“調(diào)用流程”、第六列表示“選擇交易類型”；“案例數(shù)據(jù)”是指具體的“流程”和“基本操作”，如表2中的“流程A”和“步驟B”都可以被認為是案例數(shù)據(jù)。
流程文件其結構與案例文件基本一致。
本發(fā)明的有益效果·提高案例讀寫的效率本發(fā)明的測試輔助系統(tǒng)利用文件接口可以直接基于某種通用格式的案例文件進行執(zhí)行，保證了測試過程的高效率，同時減小了文件轉(zhuǎn)換過程所帶來的案例文件的版本維護問題。
·系統(tǒng)的可適用性程度提高本發(fā)明所提供的測試輔助系統(tǒng)，通過提供與具體的商業(yè)測試軟件的接口層函數(shù)，就可以與相應的商業(yè)測試軟件協(xié)同使用，因此本發(fā)明易于移植到不同的商業(yè)測試軟件平臺上。
·測試的執(zhí)行效率提高案例的動態(tài)執(zhí)行與延遲裝載，這是本發(fā)明最主要技術點。因為大量案例和流程裝入內(nèi)存之后，會導致內(nèi)存占用率過高，執(zhí)行測試案例的速度減慢。而本發(fā)明的技術方案將測試的初始化過程與案例數(shù)據(jù)的獲取分布在測試的不同階段完成，一方面減少了案例文件的初始化過程的時間；另一方面，案例的延遲裝載技術可以根據(jù)執(zhí)行的具體案例加載案例數(shù)據(jù)，而且在一次運行過程中，某個案例或者流程的數(shù)據(jù)只需要加載一次，后面的案例若需要調(diào)用同一個流程，只需要到內(nèi)存中直接獲取，而不必再次加載，在一定程度上提高了執(zhí)行速度。
以下結合附圖詳細描述本發(fā)明，但實施例的描述是為了說明本發(fā)明的方案，而不是限制本發(fā)明的內(nèi)容。
圖1是直接使用商業(yè)測試軟件進行測試的過程圖；圖2是使用DDE框架進行測試的過程圖；圖3是案例、流程、基本操作的調(diào)用關系圖；圖4是軟件測試運行的網(wǎng)絡連接圖；圖5是自動化測試輔助系統(tǒng)與商業(yè)測試軟件、被測軟件的關系圖；圖6是自動化測試輔助系統(tǒng)模塊結構圖；圖7是測試案例自動化測試的過程圖；圖8是自動化測試的初始化過程圖；圖9是測試案例的執(zhí)行過程圖；圖10是分析并且執(zhí)行案例的流程圖。
圖11是用測試管理工具生成測試執(zhí)行序列的運行流程圖；圖12是本發(fā)明實施例“消費交易”測試的具體過程圖。
具體實施例方式
為了更清楚地說明本發(fā)明，特將若干概念解釋如下(參見圖3)案例執(zhí)行序列定義了需要進行測試的案例，包括需要執(zhí)行的案例名、案例所屬的測試運行集，以及是否需要測試的狀態(tài)標志等。通過定義案例執(zhí)行序列，也就指定了本次測試中所需要執(zhí)行的全部案例。即在“初始化過程”之后，首先應當調(diào)入該“執(zhí)行序列”，然后系統(tǒng)會根據(jù)該執(zhí)行序列調(diào)用相關的案例。
案例用一定格式的通用的軟件來編寫，例如用EXCEL編寫，由案例名稱、流程、基本操作、數(shù)據(jù)、注釋等組成。
案例(流程)模板是案例的結構，該結構定義了案例(流程)的操作關鍵詞，即每一步執(zhí)行的操作本身，并不涉及具體數(shù)據(jù)(如“調(diào)用流程關鍵詞”、“賦值關鍵詞”，僅僅記錄的是什么操作，而不記錄調(diào)用的流程名稱、賦予的具體數(shù)值是多少)。在案例測試初始化的時會對測試案例模板進行分析，同時對流程模板進行分析。
流程是一系列有序基本操作的集合。
基本操作是流程的組成部分，是不能再分割的最小執(zhí)行單位，包括輸入、檢查、賦值等。
參見圖4所示，其為使用本自動化測試輔助系統(tǒng)進行網(wǎng)絡軟件測試的的典型網(wǎng)絡連接示意圖，發(fā)送方和接收方通過被測試網(wǎng)絡3進行連接，商業(yè)測試軟件2通過與發(fā)送方軟件4、接收方軟件5的進行連接就能夠?qū)崿F(xiàn)對發(fā)送方傳送給接收方的過程進行測試，同時驗證所傳送數(shù)據(jù)的正確性；增加了自動化測試輔助系統(tǒng)與商業(yè)測試軟件的連接后，就可以增加測試的自動化程度，直接通過自動化測試輔助系統(tǒng)1讀取案例，并將其轉(zhuǎn)換為特定的商業(yè)測試軟件腳本，通過商業(yè)測試軟件對系統(tǒng)進行自動化測試，并將測試結果反饋到該自動化測試輔助系統(tǒng)進行分析，進而可以進行下一步測試。如圖5所示，本發(fā)明的自動化測試輔助系統(tǒng)1在一定程度上充當了案例文件6與商業(yè)測試軟件2之間的連接橋梁，利用本系統(tǒng)進行自動化測試的時候，首先需要根據(jù)一定的規(guī)則編寫案例文件6，然后通過過本自動化測試輔助系統(tǒng)將相關的案例文件6轉(zhuǎn)換為商業(yè)測試軟件的腳本，在輸入到商業(yè)測試軟件2對被測試軟件7進行測試。
參見圖6，其所示為本發(fā)明的自動化測試輔助系統(tǒng)模塊結構，其中，本系統(tǒng)測試所需要的案例(流程)文件6和案例測試的執(zhí)行序列文件18，均通過所述的文件接口11讀入到系統(tǒng)運行的內(nèi)存；測試執(zhí)行軟件接口15連接到商業(yè)測試執(zhí)行軟件并驅(qū)動該商業(yè)測試軟件2，測試管理工具接口16連接到測試管理工具17；動態(tài)執(zhí)行控制模塊13一端與案例調(diào)度模塊12連接，另一端分別連接到語法分析模塊14、測試執(zhí)行軟件接口15、測試管理工具接口15，通過調(diào)用案例調(diào)度模塊12對案例進行讀入，調(diào)用語法分析模塊14對案例進行分析、執(zhí)行，并轉(zhuǎn)換為相應的商業(yè)測試軟件腳本，通過測試執(zhí)行軟件接口15驅(qū)動商業(yè)測試軟件2，將執(zhí)行結果通過測試管理工具接口16記載到測試管理工具17中。
各個模塊功能介紹案例調(diào)度模塊是測試案例的調(diào)度中心，其工作方式是首先通過文件接口模塊讀入案例執(zhí)行序列，然后根據(jù)所讀入的案例執(zhí)行序列調(diào)度相應的測試案例，通過文件接口模塊將其讀入內(nèi)存。
動態(tài)流程執(zhí)行控制是本系統(tǒng)的核心模塊，該模塊包括三個主要作用其一、通過調(diào)用案例調(diào)度模塊對案例進行讀入；其二、調(diào)用語法分析模塊對案例進行分析、執(zhí)行，并轉(zhuǎn)換為相應的商業(yè)測試軟件腳本，通過測試執(zhí)行軟件接口輸入到商業(yè)測試軟件，從而完成對被測軟件的自動化測試；其三、將執(zhí)行結果反饋到測試管理工具接口。
語法分析模塊該模塊有兩大作用，其一、在案例的初始化階段，對測試案例的模板進行分析，從而構建起測試案例的所有操作步驟在內(nèi)存中的映像；同時對流程進行分析，區(qū)分出動作關鍵字映射到相應的處理功能、輸入數(shù)據(jù)、期望數(shù)據(jù)等信息；其二、在執(zhí)行過程中，對案例數(shù)據(jù)進行語法分析。
文件接口模塊該接口主要將一定格式的測試案例、案例的執(zhí)行序列轉(zhuǎn)換為本系統(tǒng)案例調(diào)度模塊所支持的格式。
本自動化測試輔助系統(tǒng)最突出的特點不僅僅在于采用了DDE框架驅(qū)動，而且在于其采用了動態(tài)執(zhí)行和延遲裝載技術，即將自動化測試過程分解為“案例的初始化過程”和“案例的執(zhí)行過程”兩步，在初始化過程中只將案例模板、流程模板、案例名、流程名記錄到內(nèi)存中，并形成案例模板名、案例模板指令序列、案例名稱、案例在文件中的位置等對應關系；同時形成流程模板名、流程模板指令序列、流程名稱、流程在文件中的位置等對應關系，只有在執(zhí)行的時候才根據(jù)需要裝載有關的案例和流程的數(shù)據(jù)，而不是直接裝載所有的案例數(shù)據(jù)，減少了對系統(tǒng)內(nèi)存的占用。并且采用了案例調(diào)用流程，流程調(diào)用基本操作的兩步調(diào)用，大大簡化了案例的編寫。
參見圖7，其所示為本發(fā)明的自動化測試過程圖，先根據(jù)一定的規(guī)則編寫案例100、然后對進行案例的初始化處理200，最后進行案例的執(zhí)行與結果處理300。
參見圖8，其所示為本發(fā)明的自動化測試流程中初始化處理200過程1、編寫初始化的配置文件201，包括跟測試管理工具相關的參數(shù)、跟數(shù)據(jù)庫相關的參數(shù)、案例執(zhí)行序列的文件名、案例工作表名；2、讀入配置文件，同時分析配置文件所設置的參數(shù)202；3、根據(jù)配置文件讀入案例模板，分析案模板的關鍵詞，在內(nèi)存中形成案例模板名與案例模板指令序列的對應關系203；4、對基于每個模板的案例(流程)進行識別，在內(nèi)存中形成案例(流程)名稱、案例(流程)模板名稱、案例(流程)在文件中的位置之間的對應關系204。
經(jīng)過了這兩個步驟的處理，在內(nèi)存中已經(jīng)形成了案例名(流程名)、案例模板之間的對應關系，同時為了支持延遲裝載所需要的文件位置等信息也一起保存。此時，案例本身的初始化過程已經(jīng)完成。因此，在案例的執(zhí)行過程中，只需訪問案例(流程)的內(nèi)存映象，不必關心具體的案例數(shù)據(jù)是否已經(jīng)裝載。如果在執(zhí)行過程中發(fā)現(xiàn)某個案例(流程)的數(shù)據(jù)不存在，動態(tài)執(zhí)行控制模塊的延遲裝載功能會自動從案例文件中裝載指定案例(流程)的數(shù)據(jù)；如果所訪問的案例(流程)的數(shù)據(jù)已經(jīng)存在，則不需重復裝載，這樣所有的案例(流程)，在一次測試過程中不管使用多少遍，也僅需裝載一次，提高了對案例的處理速度。
每次測試往往僅僅涉及到某個或某幾個測試集，因此就避免了大量裝入所有案例數(shù)據(jù)裝入之后所引起的內(nèi)存占用，從而提高執(zhí)行的效率；同時也避免了通過案例執(zhí)行序列查找案例，而后邊分析案例模板邊執(zhí)行案例而引起的重復分析與執(zhí)行速度變慢。
結構化的案例編寫，減少了重復工作量，并且提高了案例的可重復性。
基于案例的動態(tài)執(zhí)行和延遲裝載技術，該系統(tǒng)在案例的編寫方式上實現(xiàn)了對操作流程的復用機制，具體如下引入類似于程序設計中過程調(diào)用的語義，在編寫案例的時候，如果每次均需執(zhí)行相同的一系列的操作步驟，就可以將這一系列操作步驟抽象出來，定義稱為一個流程模板，每一組具有不同的輸入數(shù)據(jù)但與具有相同操作步驟的集合定義為不同的流程，這些流程同屬于一個流程模板，先編寫這些流程與流程模板，然后在案例編寫中，調(diào)用已經(jīng)定義好的流程，從而既簡化了案例的編寫過程，增加了案例的可維護性，同時也能提高了案例的執(zhí)行速度，減少了案例執(zhí)行過程中的內(nèi)存消耗。
參見圖9，其所示為本發(fā)明的自動化測試流程中案例的執(zhí)行過程300由于在案例的初始化過程中已經(jīng)在系統(tǒng)內(nèi)存中記錄了案例(流程)模板的指令序列、案例(流程)模板名與案例(流程)名的對應關系、某個案例在案例文件中的位置、某個流程在流程中的位置，因此在執(zhí)行過程中主要包括如下步驟①讀入案例執(zhí)行序列301；②根據(jù)該案例的執(zhí)行序列，通過文件接口讀入相關的案例文件302；根據(jù)案例執(zhí)行序列中要執(zhí)行的案例名稱到內(nèi)存中查找相關“案例”是否存在，然后判斷相關案例的數(shù)據(jù)是否已經(jīng)裝載；若數(shù)據(jù)尚未裝載，則通過內(nèi)存中已經(jīng)存在的該案例的存儲位置到案例文件中讀取案例數(shù)據(jù)；③分析并且執(zhí)行案例303；④驅(qū)動商業(yè)測試軟件進行測試304；⑤比較測試結果與期望數(shù)據(jù)305；⑥某個案例執(zhí)行完畢，則將相關的結果通過測試管理工具接口反饋到測試管理工具中306。
參見圖10，分析并且執(zhí)行案例303，根據(jù)初始化過程中形成的該案例所屬模板的指令序列中的關鍵詞判斷這一步驟是調(diào)用某個流程還是執(zhí)行某個基本操作；若屬于執(zhí)行基本操作，則直接通過本自動化測試輔助系統(tǒng)將該操作轉(zhuǎn)換為商業(yè)測試軟件腳本，然后通過商業(yè)測試軟件接口驅(qū)動商業(yè)測試軟件；若為調(diào)用流程，則根據(jù)流程名到內(nèi)存中查找流程數(shù)據(jù)是否已經(jīng)裝載，若沒有裝載，則進行裝載，若已經(jīng)裝載，則直接根據(jù)流程模板分析流程并執(zhí)行一個一個的基本操作，直至該流程執(zhí)行完畢。當一個基本操作或者流程執(zhí)行完畢之后，該自動化測試系統(tǒng)通過語法分析模塊取得案例指令序列的下一個關鍵詞，進行下一步驟的執(zhí)行，直到該案例完全執(zhí)行完畢。(注由于流程代表了一系列基本操作的集合，所以當有大量案例需要測試的情況下，流程的重復程度是很高的，因此很多流程只要裝載一次就可以了，避免了重復裝載流程數(shù)據(jù)帶來的時間損失)。
參見圖11，本發(fā)明的測試管理工具既可以對測試的結果進行自動分析，靈活地組合形成需要再度測試的案例，以取代人工編寫“案例執(zhí)行序列”的過程；也可以案件測試之前把相關的案例信息(主要為案例名、案例功能、案例所屬于的測試案例集)通過接口輸入到測試管理工具(步驟401)，再通過測試管理工具選擇需要測試的案例(步驟402)，形成“案例執(zhí)行序列”；然后本自動化測試輔助系統(tǒng)進行初始化設置，并根據(jù)自動形成的“案例執(zhí)行序列”分析和執(zhí)行相關案例(步驟403)；通過商業(yè)測試軟件進行測試(步驟404)；最后，將測試結果再反饋到測試管理工具中(步驟405)；接著，若需要再進行案例的測試，則仍然可以通過測試管理工具可以對測試的結果進行自動分析，靈活地組合形成需要再度測試的案例，以取代人工編寫“案例執(zhí)行序列”的過程。通過測試管理工具選取案例的執(zhí)行序列主要包括下面幾種方式就案例的選擇而言一種方式是通過測試管理工具提供的界面直接進行操作，測試管理工具的界面列明了所有的案例名、案例描述、案例所屬的測試集、案例被測試的次數(shù)、案例測試成功的次數(shù)、案例測試失敗的次數(shù)等信息，操作人員可以通過界面對需要測試的案例進行選取；另一種方式是通過后臺直接對測試管理工具的數(shù)據(jù)庫進行處理，選取需要執(zhí)行的案例。在選取完成之后，測試管理工具即可以自動生成某種格式的測試案例的執(zhí)行序列，然后通過文件接口將該執(zhí)行序列讀入，由此進行案例測試；也可以不必生成測試案例的執(zhí)行序列，而是直接將這些案例信息讀入內(nèi)存，進而進行案例測試。
實施例1參見圖12，下面以對某個“消費交易”功能進行測試為例對本發(fā)明做詳細說明“消費交易”主要是測試在發(fā)送端輸入必要的數(shù)據(jù)，提交到被測試網(wǎng)絡，然后由網(wǎng)絡進行轉(zhuǎn)接，發(fā)送到接受方進行必要的檢查和處理，再通過網(wǎng)絡回送給發(fā)送端。
案例的測試過程1、編寫測試案例、編寫測試案例執(zhí)行序列、編寫初始化配置文件。
①測試案例執(zhí)行序列的編寫(步驟501)以表格的方式表示，包含了該案例是否需要執(zhí)行、所屬案例集的名稱(案例集目前的分類依據(jù)的是應用，如可以分為預授權案例集、消費案例集、取款案例集等)、案例名稱、案例描述等信息。
②測試案例的編寫(步驟501)同樣以表格的形式出現(xiàn)。主要由案例名稱、關鍵詞、流程名稱、基本數(shù)據(jù)等幾個組成部分，其中每一列的關鍵詞表示所要進行的操作類型，或調(diào)用一個流程，或進行一次賦值操作等。(測試流程的編寫把某些最基本的操作抽象出來編寫為流程模板)。
③初始化配置的編寫(CONFIG.XLS)(步驟502)主要包括環(huán)境的設定、關于數(shù)據(jù)庫連接的參數(shù)、與測試管理工具相關的參數(shù)、執(zhí)行序列文件名、執(zhí)行的案例集名(可以指定本次運行消費案例集，而不運行其他案例集)、以及案例或者流程中所使用到一些常數(shù)。
2、初始化過程(步驟503)①把配置文件調(diào)入內(nèi)存，進行測試系統(tǒng)的環(huán)境配置。
②對案例模板進行分析、對流程模板進行分析(但不裝入案例數(shù)據(jù)與流程數(shù)據(jù))，并在內(nèi)存中形成這樣幾組對應關系將“消費案例”的模板裝入內(nèi)存，即在內(nèi)存中記錄了該模板的指令序列，但并不裝載具體數(shù)據(jù)，如第一步進行賦值操作、第二步調(diào)用流程等，至于具體賦什么值，調(diào)用哪個流程在初始化過程中并不需要加載；建立“每個消費案例”與“消費案例模板”的對應關系，即記錄每個“消費案例”在“案例”文件中的位置，以及每個消費案例的名稱；同時裝載所有“流程”模板，并形成流程與流程模板的對應關系；某個流程在流程文件中的具體位置等信息。
3、“某個消費案例POS-1”進行測試的詳細過程由于在初始化過程中已經(jīng)形成案例與案例模板的對應關系，也就是經(jīng)過初始化，內(nèi)存中記錄了某個案例模板的指令序列，即一步步應該進行什么操作，并且記錄了哪個案例屬于哪個案例模板。因此，在執(zhí)行過程中，首先，導入案例的執(zhí)行序列，然后根據(jù)該執(zhí)行序列所指定的需要執(zhí)行的案例名稱POS-1，查找內(nèi)存中是否存在該案例數(shù)據(jù)，查找結果內(nèi)存中有該案例名，但沒有該案例數(shù)據(jù)，則加載該案例數(shù)據(jù)，再根據(jù)在初始化過程中在內(nèi)存中形成的該案例所屬的案例模板的指令序列進行分析，若該指令需要執(zhí)行，則判斷是屬于調(diào)用流程還是進行基本操作，如果需要調(diào)用流程的話，則根據(jù)流程名稱判斷是否數(shù)據(jù)已經(jīng)裝載，如果沒有裝載，則通過相關的映射把相關的流程數(shù)據(jù)調(diào)入內(nèi)存，然后執(zhí)行流程中的基本操作；若屬于基本操作，則直接執(zhí)行基本操作。
根據(jù)初始化過程中在內(nèi)存中形成的案例POS-1所屬的案例模板的指令序列表明，該案例的指令序列為“調(diào)用流程——調(diào)用流程——賦值——發(fā)送報文——調(diào)用流程——調(diào)用流程——調(diào)用流程——調(diào)用流程……調(diào)用流程”。
因此，在執(zhí)行過程中，加載案例POS-1的數(shù)據(jù)后，將會進行案數(shù)據(jù)和案例模板指令序列匹配，如案例POS-1第一步的數(shù)據(jù)為A，則根據(jù)指令序列第一步為“調(diào)用流程”，就知道該案例第一步的操作為“調(diào)用流程A”。
①受理方頁面設置，調(diào)用流程A(步驟504)流程A的操作為受理方的動作，如設置卡介質(zhì)、交易類型、報文頭選擇(帶報頭、不帶報頭)、新舊密鑰選擇、發(fā)送控制(直接發(fā)送、不發(fā)送、延遲發(fā)送、重復發(fā)送)、加密選擇。在調(diào)用流程A504的過程中，首先判斷該流程的數(shù)據(jù)是否已經(jīng)裝載到內(nèi)存，如果還沒有裝載，則執(zhí)行裝載過程，若已經(jīng)裝載，則直接從內(nèi)存中取得流程數(shù)據(jù)；②發(fā)卡方頁面設置，調(diào)用流程B(步驟505)流程B的操作為自動進行發(fā)卡方的動作(與受理方類似)；③交易類型選擇設置為“消費”(步驟506)這步為賦值操作，用來進行相關域的設置和報文頭的參數(shù)設置；如設置用案例編號EXP010XXN01；④發(fā)送報文(步驟507)發(fā)送報文為一個基本操作，直接將發(fā)卡方的數(shù)據(jù)發(fā)送，該操作直接執(zhí)行，通過本系統(tǒng)的動態(tài)執(zhí)行控制模塊轉(zhuǎn)換為商業(yè)軟件測試腳本；⑤受理方仿真器日志獲取，調(diào)用流程C(步驟508)流程C的作用是對發(fā)送報文日志的數(shù)值與預期的數(shù)值進行比對，是否與預期數(shù)值一致；⑥發(fā)送方仿真器日志獲取，調(diào)用流程D(步驟509)流程D的作用是對發(fā)送報文日志的數(shù)值與預期的數(shù)值進行比對，是否與預期數(shù)值一致；⑦受理方報文檢查，調(diào)用流程E(步驟510)流程E的作用是對受理方的報文進行檢查，判斷結果；⑧發(fā)卡方報文檢查，調(diào)用流程F(步驟511)流程F的作用是對發(fā)卡方的報文進行檢查，判斷結果；
⑨數(shù)據(jù)庫獲取數(shù)據(jù)，調(diào)用流程G(步驟512)；該流程主要實現(xiàn)的是對數(shù)據(jù)庫中的數(shù)據(jù)進行比對；⑩檢查應答報文寫的轉(zhuǎn)接日志，比對結果、生成LOG文件(步驟513)。
將測試結果反饋到測試管理工具(步驟514)。如果案例的執(zhí)行序列指明還有其他案例需要測試，則繼續(xù)讀取案例——初始化——執(zhí)行，只是調(diào)用的流程、執(zhí)行的步驟有所不同而已。
由于采用了本發(fā)明所述的技術手段，取得了如下明顯的效果每次運行并非針對所有運行集進行，也并非會涉及所有的流程，因此把所有案例數(shù)據(jù)調(diào)入內(nèi)存需要很長的時間，在某種程度上也是一種浪費。
將案例的執(zhí)行與案例的初始化相區(qū)分，在初始化過程中只需要調(diào)入案例模板、關鍵詞、案例名稱等信息。這就避免了大量數(shù)據(jù)的調(diào)入，同時也避免了將一個案例所有信息串聯(lián)起來需要耗費的大量時間。
從理論上說，調(diào)度一個案例的時候，通過案例名調(diào)用該案例，同時分析關鍵詞，如果關鍵詞表示調(diào)度流程的話，還需要根據(jù)流程名稱調(diào)度相關的操作與步驟，時間上比原來單個案例的執(zhí)行會有所增加，但根據(jù)我們的測試和實驗數(shù)據(jù)，這種時間上的增加幾乎感覺不出。
例如要測試400個案例，原先其初始化過程需要耗費20到30分鐘，每筆交易測試執(zhí)行速度將近2到3分鐘；而采用了案例的動態(tài)執(zhí)行和延遲裝載之后，速度大幅度提高，其初始化過程只需要2到3分鐘，而每筆交易測試的執(zhí)行速度基本上沒有大的變化。
案例執(zhí)行序列可以是由人工編寫的，并給各個案例指定了其所在的案例子集，和是否執(zhí)行的標志。也可以是由測試管理工具實現(xiàn)案例的動態(tài)運行調(diào)度，可以由測試管理工具自動控制案例執(zhí)行序列，利用測試管理工具對所有案例進行動態(tài)而便捷的調(diào)度。例如我們重新運行的某些案例，或者需要對所有執(zhí)行失敗的案例重新運行的話，我們只要利用測試管理工具修改執(zhí)行序列即可。
權利要求
1.一種自動化測試輔助系統(tǒng)，用于驅(qū)動軟件測試系統(tǒng)中的商業(yè)測試軟件，其特征在于，該系統(tǒng)由如下模塊組成a)動態(tài)執(zhí)行控制模塊，b)案例調(diào)度模塊，c)語法分析模塊，d)文件接口，e)測試執(zhí)行軟件接口，f)測試管理工具接口；其中，本系統(tǒng)測試所需要的案例文件、流程文件和案例測試的執(zhí)行序列文件，均通過所述的文件接口讀入到系統(tǒng)運行的內(nèi)存；測試執(zhí)行軟件接口連接到商業(yè)測試執(zhí)行軟件并驅(qū)動該商業(yè)測試軟件，測試管理工具接口連接到測試管理工具；動態(tài)執(zhí)行控制模塊一端與案例調(diào)度模塊連接，另一端分別連接到語法分析模塊、測試執(zhí)行軟件接口、測試管理工具接口，通過調(diào)用案例調(diào)度模塊對案例進行讀入，調(diào)用語法分析模塊對案例進行分析、執(zhí)行，并轉(zhuǎn)換為相應的商業(yè)測試軟件腳本，通過測試執(zhí)行軟件接口驅(qū)動商業(yè)測試軟件，將執(zhí)行結果通過測試管理工具接口記載到測試管理工具中。
2.如權利要求1所述的自動化測試輔助系統(tǒng)，其特征在于，所述的語法分析模塊包括案例模板分析單元，并且動態(tài)執(zhí)行控制模塊連接到該單元。
3.如權利要求1所述的自動化測試輔助系統(tǒng)，其特征在于所述的文件接口模塊還具有將測試案例、案例的執(zhí)行序列轉(zhuǎn)換為本系統(tǒng)案例調(diào)度模塊所支持的格式的功能。
4.一種使用本發(fā)明的系統(tǒng)的軟件自動測試方法，包括如下步驟a)初始化裝載，b)把案例執(zhí)行序列調(diào)入內(nèi)存，并據(jù)此進行案例調(diào)度；c)分析案例、加載案例數(shù)據(jù)；d)執(zhí)行案例并生成腳本函數(shù)供商業(yè)測試軟件進行測試；e)將測試結果與期望數(shù)據(jù)進行比較；f)寫日志文件，同時將運行結果輸入到測試管理工具。
5.如權利要求4所述的方法，其特征在于，所述的初始化裝載包括如下內(nèi)容把系統(tǒng)運行所需要的配置文件的相關參數(shù)調(diào)入內(nèi)存，包含了案例文件名、流程文件名、案例執(zhí)行序列文件名、跟被測軟件相關的參數(shù)，和跟測試管理工具相關的參數(shù)；分別根據(jù)案例文件名和流程文件名讀入案例文件和流程文件，對其中的案例模板部分進行分析，同時也對流程文件中的流程模板進行分析。
6.如權利要求4所述的方法，其特征在于，所述的案例文件、流程文件和案例執(zhí)行序列文件可以是存放在多個文件中，也可以存放在一個文件的多個不同的工作表中。
7.如權利要求4所述的方法，其特征在于，所述的案例調(diào)度是由動態(tài)執(zhí)行控制模塊進行案例調(diào)度。
8.如權利要求4所述的方法，其特征在于，所述的分析案例、加載案例數(shù)據(jù)指判斷案例數(shù)據(jù)是否已經(jīng)裝載到內(nèi)存中，并根據(jù)分析結果加載案例數(shù)據(jù)，該步驟由動態(tài)執(zhí)行控制模塊來完成的。
9.如權利要求5所述的方法，其特征在于，所述的案例執(zhí)行序列中記載了該序列要執(zhí)行的案例是屬于哪個測試集的。
10.如權利要求5所述的方法，其特征在于，所述的對其中的案例模板部分進行分析，還包括對該模板的指令序列進行初步分析，在內(nèi)存中形成案例模板與案例模板指令序列之間的對應關系。
11.如權利要求10所述的方法，其特征在于，所述的對其中的案例模板部分進行分析，還包括對基于每個模板的案例進行識別，在內(nèi)存中形成案例、案例模板、案例在案例文件中的位置之間的對應關系。
12.如權利要求5所述的方法，其特征在于，所述的對其中的流程模板部分進行分析，還包括對該流程的指令序列進行初步分析，在內(nèi)存中形成流程模板與流程模板指令序列之間的對應關系。
13.如權利要求12所述的方法，其特征在于，所述對其中的流程模板部分進行分析，還包括對基于每個模板的流程進行識別，在內(nèi)存中形成流程、流程模板、流程在流程文件中的位置之間的對應關系。
14.如權利要求6所述的方法，其特征在于，所述的案例調(diào)度是由測試管理工具進行的。
15.如權利要求14所述的方法，其特征在于，對執(zhí)行失敗的案例或者需要重新運行的案例，用測試管理工具動態(tài)修改，以自動生成新的案例執(zhí)行序列。
全文摘要
本發(fā)明提供了一種自動化測試輔助系統(tǒng)以及相應的軟件自動測試方法。本系統(tǒng)由動態(tài)執(zhí)行控制模塊、案例調(diào)度模塊、語法分析模塊、文件接口、測試執(zhí)行軟件接口、測試管理工具接口組成。通過本系統(tǒng)，可以將相關的測試案例方便地轉(zhuǎn)換為商業(yè)測試軟件的腳本，并且將基本操作封裝成流程，實現(xiàn)了由測試案例調(diào)用流程的結構化方法，同時采用案例、流程的動態(tài)執(zhí)行和延遲裝載技術，將案例的測試過程分解為“案例測試的初始化過程”和“案例測試的執(zhí)行過程”兩個步驟，從而一方面實現(xiàn)案例編寫的獨立性、案例和流程的復用，同時降低了系統(tǒng)內(nèi)存的占用率、提高了案例的執(zhí)行效率。
文檔編號G06F11/36GK1744054SQ20041005416
公開日2006年3月8日 申請日期2004年8月31日 優(yōu)先權日2004年8月31日
發(fā)明者柴洪峰, 單懷光, 戚躍民, 郭銳, 胡文斌, 吳金壇, 黎寶華 申請人:中國銀聯(lián)股份有限公司