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