【正文】 CaseLoader包主要用來(lái)裝載數(shù)據(jù)管理器中生成的內(nèi)部測(cè)試用例數(shù)據(jù)，為測(cè)試引擎提供數(shù)據(jù)來(lái)源。針對(duì)每一個(gè)關(guān)鍵字都在索引表中存儲(chǔ)一個(gè)PositonEntry類。如果索引創(chuàng)建的過(guò)程出錯(cuò)即可判定文件的格式存在問(wèn)題。IndexGenerator類負(fù)責(zé)創(chuàng)建索引的全過(guò)程。indexGenerator package中的類實(shí)現(xiàn)了對(duì)一份特定格式的文檔創(chuàng)建索引的功能。此外，由于每次執(zhí)行測(cè)試用例所得到的訂單號(hào)都是會(huì)改變的，所以用戶需要額外地提供一個(gè)基準(zhǔn)訂單號(hào)文件和對(duì)應(yīng)的目標(biāo)訂單號(hào)文件來(lái)確保校驗(yàn)的正常執(zhí)行。在轉(zhuǎn)化之前，系統(tǒng)首先裝載FieldConfigLoader包中的FieldCfgInfo類，并且由IndexGenerator模塊對(duì)用戶提供的基準(zhǔn)文件創(chuàng)建一個(gè)數(shù)據(jù)索引以提高解析和轉(zhuǎn)化的效率。當(dāng)校驗(yàn)引擎需要對(duì)某一特定的數(shù)據(jù)類型進(jìn)行校驗(yàn)的時(shí)候，會(huì)從中獲取相應(yīng)的校驗(yàn)方法類。CKMethodCfgLoaderManager類負(fù)責(zé)對(duì)這些校驗(yàn)方法類的裝載過(guò)程進(jìn)行管理和監(jiān)控。而其他的格式則使用確定每一個(gè)域在一條記錄中的起始和終結(jié)位置來(lái)解析，那么針對(duì)這樣的格式需要另一個(gè)解析類LengthSpliter。SpliterFactory是一個(gè)抽象的工廠化類。Format類是用戶定義的各種格式的表示，一個(gè)Format類代表一種具體的格式。它內(nèi)部的類結(jié)構(gòu)層次圖如下：圖44. Field config package類圖FieldLoaderManager類主要負(fù)責(zé)對(duì)用戶定義的格式信息的解析和裝載。它給用戶提供提供了統(tǒng)一的接口來(lái)構(gòu)建特定的DataBaseAccess類。因?yàn)檫@三者數(shù)據(jù)庫(kù)表結(jié)構(gòu)的差異很大，所以無(wú)法定義一個(gè)通用的查詢過(guò)程來(lái)實(shí)現(xiàn)對(duì)三個(gè)數(shù)據(jù)庫(kù)的查詢。下圖中不僅描述了各個(gè)模塊之間的關(guān)系還包括了模塊與數(shù)據(jù)文件之間的關(guān)系。手工校驗(yàn)這么一份文件的工作量是巨大的，如果只進(jìn)行一次的校驗(yàn)，結(jié)果是得不償失的。為了方便起見(jiàn)。如委托時(shí)間（Order Time），交易時(shí)間（Action Time）等。我們可以根據(jù)測(cè)試用例文檔中說(shuō)明的測(cè)試步驟按照業(yè)務(wù)邏輯來(lái)直接確定這些域的值，比如：股票名稱（Symbol），委托數(shù)量（Original_Quantity），委托價(jià)格（Price）等。固定域的基準(zhǔn)值從用戶提供的基準(zhǔn)文件中獲得，非固定域的基準(zhǔn)值從數(shù)據(jù)庫(kù)中查詢獲得。 輸入和輸出用戶在使用Smart Checker時(shí)需要提供一份基準(zhǔn)文件（baseline file）作為校驗(yàn)的標(biāo)準(zhǔn)值，另外提供一份需要檢驗(yàn)的目標(biāo)文件（Target file）。Smart Checker在校驗(yàn)文件的過(guò)程中應(yīng)盡量少地占用系統(tǒng)資源，原則上不超過(guò)6M。另外一份測(cè)試報(bào)告則是對(duì)每一個(gè)測(cè)試用例的測(cè)試步驟的詳細(xì)記錄，所有校驗(yàn)過(guò)程的中間數(shù)據(jù)都將被記錄在里面，這樣使得用戶可以快速深入地定位問(wèn)題產(chǎn)生的原因。smart checker對(duì)于每次的測(cè)試任務(wù)都要給出兩份測(cè)試報(bào)告。該工具能夠適用于絕大多數(shù)的數(shù)據(jù)文件校驗(yàn)工作。如果在UAT環(huán)境下，那么每天的日志記錄將會(huì)達(dá)到上萬(wàn)條。就拿其中的TAGS系統(tǒng)的操作日志文件為例，該日志文件的每條記錄都是對(duì)實(shí)際股票交易信息的記錄，每條記錄包含47個(gè)域。它們有各自的需求規(guī)定，具體的匯報(bào)規(guī)則都可以在納斯達(dá)克的官方網(wǎng)站上找到。比如XML，LCS算法等。Xpath表達(dá)式也可以表示數(shù)值和布爾運(yùn)算符等數(shù)據(jù)類型[9]。最開(kāi)始，W3C準(zhǔn)備創(chuàng)建一種樣式表語(yǔ)言，稱為可擴(kuò)展樣式表語(yǔ)言(XSL)，很快人們發(fā)現(xiàn)，在XML文檔上操作的樣式表語(yǔ)言需要兩類主要的功能:也就是與表示和附加信息相關(guān)的功能，將數(shù)據(jù)轉(zhuǎn)換為特定類型的結(jié)果樹[2]。其后對(duì)文檔的所有操作都是在對(duì)象樹上的進(jìn)行。這種對(duì)象模型實(shí)現(xiàn)的基本功能包括:. 描述文檔表示和操作的接口。所以XML Schema具有強(qiáng)制文檔內(nèi)容和結(jié)構(gòu)的能力，它是XML世界中的一種不但重要而且強(qiáng)大的新標(biāo)準(zhǔn)[3]。如果違反這些規(guī)則解析器就會(huì)拒絕解析你的Schema以及任何同它相聯(lián)系的文檔。 Schema和DTDXML只說(shuō)明數(shù)據(jù)的結(jié)構(gòu)而并不關(guān)心數(shù)據(jù)是如何具體描述的、數(shù)據(jù)是否正確。同樣是SGML的一個(gè)簡(jiǎn)化子集，它將SGML的豐富功能與HTML的易用性結(jié)合到Web的應(yīng)用中，以一種開(kāi)放的自我描述方式定義了數(shù)據(jù)結(jié)構(gòu)，在描述數(shù)據(jù)內(nèi)容的同時(shí)能突出對(duì)結(jié)構(gòu)的描述，從而體現(xiàn)出數(shù)據(jù)之間的關(guān)系。 } max=c[j]。 { if(c[j]max) } { if(str2[i]= =str1[j])j)i++)基本的偽代碼如下： len1=()。我們用兩個(gè)標(biāo)記變量來(lái)標(biāo)記矩陣中值最大的元素的位置，在矩陣生成的過(guò)程中來(lái)判斷當(dāng)前生成的元素的值是不是最大的，據(jù)此來(lái)改變標(biāo)記變量的值，那么到矩陣完成的時(shí)候，最長(zhǎng)匹配子串的位置和長(zhǎng)度就已經(jīng)出來(lái)了。但是在0和1的矩陣中找最長(zhǎng)的1對(duì)角線序列又要花去一定的時(shí)間。然后求出對(duì)角線最長(zhǎng)的1序列，其對(duì)應(yīng)的位置就是最長(zhǎng)匹配子串的位置[3]。如果該子串與基準(zhǔn)記錄相同則可以確定目標(biāo)記錄是正確的，如果子串與基準(zhǔn)記錄不相同，則可以判定目標(biāo)記錄有錯(cuò)誤，而同時(shí)子串記錄的則是正確的域。對(duì)于這種格式，如果采用線性循環(huán)的方式進(jìn)行一對(duì)一的比對(duì)將會(huì)降低校驗(yàn)的效率。是最為理想的校驗(yàn)方法。一個(gè)測(cè)試用例通常是由多條日志記錄組成的，我們需要依次檢驗(yàn)每一條的日志記錄。7遍歷任務(wù)鏈表，以任務(wù)鏈表中的數(shù)據(jù)為驅(qū)動(dòng)校驗(yàn)指定的日志文件。 5將從數(shù)據(jù)庫(kù)中查詢到的數(shù)據(jù)信息和用戶提供的基準(zhǔn)文件中的信息進(jìn)行合并在，轉(zhuǎn)化成一個(gè)的內(nèi)部數(shù)據(jù)文件?？紤]到擴(kuò)展性，系統(tǒng)必須允許用戶配置特定的校驗(yàn)?zāi)K。 對(duì)系統(tǒng)的某些異常和錯(cuò)誤進(jìn)行日志的記錄。報(bào)告和日志（Report amp。用戶界面（UI）:并將這些信息和模塊提供給校驗(yàn)引擎。 對(duì)基準(zhǔn)數(shù)據(jù)信息文件中的原始的基準(zhǔn)數(shù)據(jù)信息進(jìn)行加工轉(zhuǎn)化處理來(lái)產(chǎn)生測(cè)試基準(zhǔn)數(shù)據(jù)，這些基準(zhǔn)數(shù)據(jù)以測(cè)試用例為單位進(jìn)行組織，以統(tǒng)一的格式存儲(chǔ)于持久數(shù)據(jù)存儲(chǔ)多項(xiàng)中，這些轉(zhuǎn)化后的數(shù)據(jù)被用作測(cè)試用例的內(nèi)部數(shù)據(jù)表示。數(shù)據(jù)管理器（Data Manager）主要有三大功能： 從系統(tǒng)服務(wù)器上下載所需要校驗(yàn)的數(shù)據(jù)信息以文件的形式存儲(chǔ)在本地。基準(zhǔn)數(shù)據(jù)信息是一類模板信息， 這類信息已經(jīng)預(yù)先經(jīng)過(guò)一定的手段來(lái)確保其正確性，從而可以作為校驗(yàn)的一個(gè)基準(zhǔn)。目標(biāo)數(shù)據(jù)信息是要校驗(yàn)的數(shù)據(jù)信息。（如監(jiān)控網(wǎng)絡(luò)流量，抓取頁(yè)面對(duì)象，捕獲用戶操作行為等）[11]因此，在使用這些工具對(duì)實(shí)際的項(xiàng)目進(jìn)行測(cè)試時(shí)，必須用工具自帶的腳本語(yǔ)言或工具包寫測(cè)試腳本。 本章小結(jié)基于上述5種基本框架產(chǎn)生的一些自動(dòng)化測(cè)試工具（如Rational Robot ，Winrunner）都給實(shí)際的軟件測(cè)試工作帶來(lái)了很大的方便。這一方式倡導(dǎo)只用腳本實(shí)現(xiàn)驅(qū)動(dòng)邏輯(這一塊也常叫framework)， 而測(cè)試邏輯和測(cè)試數(shù)據(jù)都不放在腳本中(至少不與framework 放在同一處)。關(guān)鍵字驅(qū)動(dòng)腳本的數(shù)量不隨測(cè)試用例的數(shù)量變化， 而僅隨軟件規(guī)模而增加。關(guān)鍵字驅(qū)動(dòng)(Keyword Driven， 有時(shí)也叫TableDriven) 是腳本技術(shù)的一種， 實(shí)際上是比較復(fù)雜的數(shù)據(jù)驅(qū)動(dòng)技術(shù)的邏輯擴(kuò)展， 將數(shù)據(jù)文件變成測(cè)試用例的描述， 用一系列關(guān)鍵字指定要執(zhí)行的任務(wù)。關(guān)鍵字驅(qū)動(dòng)測(cè)試看上去與手工測(cè)試用例很類似。數(shù)據(jù)驅(qū)動(dòng)需要很少的代碼來(lái)產(chǎn)生大量的測(cè)試用例， 這與表驅(qū)動(dòng)極其類似[1]。在表驅(qū)動(dòng)測(cè)試中，它的測(cè)試用例是包含在數(shù)據(jù)文件而不是在腳本中， 對(duì)于數(shù)據(jù)而言， 腳本僅僅是一個(gè)“驅(qū)動(dòng)器”，或者是一個(gè)傳送機(jī)構(gòu)。在這里測(cè)試的輸入數(shù)據(jù)是從數(shù)據(jù)文件中讀取( 數(shù)據(jù)池，ODBC 源，cvs 文件，excel 文件，DAO 對(duì)象，ADO 對(duì)象等) ，并且通過(guò)捕獲工具生成或者手工生成的代碼腳本被載入到變量中。 測(cè)試庫(kù)框架測(cè)試庫(kù)框架( Test Library Architecture) 與模塊化測(cè)試腳本框架很類似，并且具有同樣的優(yōu)點(diǎn)。在這5種框架中，這個(gè)應(yīng)該是最容易掌握和使用的。傳統(tǒng)的結(jié)構(gòu)化線形腳本已經(jīng)無(wú)法滿足上面的要求， 新一代的自動(dòng)化測(cè)試框架提出無(wú)疑為自動(dòng)化測(cè)試提供了解決問(wèn)題的手段。后來(lái)，一種新的自動(dòng)化測(cè)試產(chǎn)品—— 自動(dòng)化測(cè)試框架出現(xiàn)了．它可以減少實(shí)現(xiàn)和維護(hù)的成本．使測(cè)試人員可以把精力集中在應(yīng)用程序的測(cè)試用例設(shè)計(jì)上，而不是開(kāi)發(fā)測(cè)試。這些測(cè)試方法雖然最容易應(yīng)用 但是幾乎不可能維護(hù)。詳細(xì)介紹了主要的類的功能和交互關(guān)系。同時(shí)也論述了在校驗(yàn)引擎中被使用到的數(shù)據(jù)比對(duì)算法——線性循環(huán)比對(duì)算法和LCS算法。論文第二章介紹了現(xiàn)有的軟件自動(dòng)化測(cè)試框架，介紹了模塊化測(cè)試框架，測(cè)試庫(kù)框架，數(shù)據(jù)驅(qū)動(dòng)測(cè)試框架，關(guān)鍵字驅(qū)動(dòng)測(cè)試框架和混合測(cè)試框架。在以往的手工測(cè)試中，測(cè)試員需要對(duì)日志文件中的每條記錄根據(jù)測(cè)試用例和測(cè)試數(shù)據(jù)進(jìn)行檢驗(yàn)。同樣，軟件自動(dòng)測(cè)試并不是萬(wàn)能的，并不能解決所有的問(wèn)題，甚至自動(dòng)化測(cè)試本身還存在這個(gè)方面的問(wèn)題。最好的軟件測(cè)試工具是能夠?qū)⑺蜏y(cè)試需求達(dá)成一致，而且他們提供高度可定義的工作流程和跟蹤報(bào)告能力，但這是不可能的，要達(dá)到這樣的要求無(wú)異于再開(kāi)發(fā)一個(gè)應(yīng)用程序。測(cè)試工具和測(cè)試過(guò)程是不相同的。所以說(shuō)軟件測(cè)試自動(dòng)化跟軟件測(cè)試一樣，也有它自己的生命周期。正確、合理的實(shí)施測(cè)試自動(dòng)化，能夠快速、徹底的對(duì)軟件進(jìn)行測(cè)試， 從而提高軟件質(zhì)量， 節(jié)省經(jīng)費(fèi)， 縮短產(chǎn)品發(fā)布周期。關(guān)鍵詞　軟件測(cè)試 軟件測(cè)試自動(dòng)化框架 XML LCSAbstractSoftware testing is an important stage of software life cycle and a key factor which affect the quality of software. The technology of software test automation can greatly reduce the testing cost and improve efficiency and accurate of software testing. Software testing automation contains three aspect of conception——test data generate automation, test case execute automation and test result data collect and analyze automation. Most existing automated testing tools mainly focused on achieving the first two aspects. We design a fame work used to verify text data automatically. And develop a tool called Smart Checker based on this frame work to full fill the requirement of Compliance project. In this paper， we pare features of existing test automation frameworks first. Then specify the architecture of Datadriven formatting automatic calibration frame work. XML technology and LCS algorism which applied in the framework will be introduced. At last，we do a further specification for the design and implementation of data verify automation tool ——Smart Checker.Keywords　 software test soft ware test automation framework XML LCS 目錄摘要 IAbstract II第1章 緒論 1 課題背景和意義 1 論文所做的工作 2第2章 軟件自動(dòng)化測(cè)試框架的介紹 3 自動(dòng)化測(cè)試框架概述 3 模塊化測(cè)試框架 3 測(cè)試庫(kù)框架 4 數(shù)據(jù)驅(qū)動(dòng)測(cè)試框架 4 關(guān)鍵字驅(qū)動(dòng)或標(biāo)驅(qū)動(dòng)測(cè)試框架 4 混合測(cè)試自動(dòng)化框架 5 本章小結(jié) 5第3章 數(shù)據(jù)驅(qū)動(dòng)的信息自動(dòng)化校驗(yàn)框架的設(shè)計(jì)和應(yīng)用技術(shù)的研究 7 總體架構(gòu)分析和設(shè)計(jì) 7 系統(tǒng)工作流程 9 校驗(yàn)過(guò)程 10 線性循環(huán)校驗(yàn) 10 LCS算法 11 XML技術(shù)的研究和應(yīng)用 14 XML簡(jiǎn)介 14 Schema和DTD 14 DOM 15 XSL 15 Xpath 15 本章小結(jié) 16第4章 Smart Checker的實(shí)現(xiàn) 17 總體需求分析 17 Compliance的介紹 17 測(cè)試任務(wù)說(shuō)明 17 功能性需求 18 性能需求 18 移植性和擴(kuò)展性需求 18 輸入和輸出 18 數(shù)據(jù)映射關(guān)系 19 系統(tǒng)架構(gòu)設(shè)計(jì) 19 系統(tǒng)模塊設(shè)計(jì) 21 數(shù)據(jù)引擎（Data Engine） 21 數(shù)據(jù)管理器（Data Manager） 23 校驗(yàn)引擎（Checking Engine） 28 報(bào)告、日志生成模塊（Report amp。本文首先對(duì)現(xiàn)有的軟件測(cè)試自動(dòng)化框架的特點(diǎn)進(jìn)行分析和比較。軟件測(cè)試自動(dòng)化可分為：測(cè)試腳本、測(cè)試數(shù)據(jù)的自動(dòng)化生成，測(cè)試用例的自動(dòng)化執(zhí)行，測(cè)試結(jié)果的自動(dòng)化采集和分析三個(gè)方面。軟件自動(dòng)化測(cè)試技術(shù)可以減少軟件測(cè)試的開(kāi)銷，提高測(cè)試的效率和準(zhǔn)確率。并在此框架基礎(chǔ)上實(shí)現(xiàn)了一個(gè)符合Compliance項(xiàng)目實(shí)際的文本校驗(yàn)工具——Smart Checker。最后在框架的基礎(chǔ)上進(jìn)一步對(duì)自動(dòng)化數(shù)據(jù)校驗(yàn)工具——Smart Checker的實(shí)現(xiàn)進(jìn)行闡述。自動(dòng)化測(cè)試可以減少或消除一些手工測(cè)試中的重復(fù)和煩瑣， 節(jié)約測(cè)試所必需的時(shí)間和提高測(cè)試的一致