[論文]數(shù)據(jù)驅(qū)動(dòng)的格式化信息自動(dòng)校驗(yàn)工具.doc

本 科 生 畢 業(yè) 論 文（設(shè)計(jì)）題目 數(shù)據(jù)驅(qū)動(dòng)的格式化信息自動(dòng)校驗(yàn)工具 摘要軟件測(cè)試是軟件生命周期中的一個(gè)重要階段，是保證軟件質(zhì)量的關(guān)鍵因素之一。軟件自動(dòng)化測(cè)試技術(shù)可以減少軟件測(cè)試的開銷，提高測(cè)試的效率和準(zhǔn)確率。軟件測(cè)試自動(dòng)化可分為：測(cè)試腳本、測(cè)試數(shù)據(jù)的自動(dòng)化生成，測(cè)試用例的自動(dòng)化執(zhí)行，測(cè)試結(jié)果的自動(dòng)化采集和分析三個(gè)方面?，F(xiàn)有的自動(dòng)化測(cè)試工具主要偏重于實(shí)現(xiàn)前兩個(gè)方面的功能。本文提出一個(gè)基于數(shù)據(jù)驅(qū)動(dòng)的文件信息自動(dòng)化校驗(yàn)框架。并在此框架基礎(chǔ)上實(shí)現(xiàn)了一個(gè)符合compliance項(xiàng)目實(shí)際的文本校驗(yàn)工具smart checker。本文首先對(duì)現(xiàn)有的軟件測(cè)試自動(dòng)化框架的特點(diǎn)進(jìn)行分析和比較。然后對(duì)提出的基于數(shù)據(jù)驅(qū)動(dòng)的文件信息自動(dòng)化校驗(yàn)框架進(jìn)行闡述。其中會(huì)對(duì)使用到的xml技術(shù)和lcs算法進(jìn)行研究。最后在框架的基礎(chǔ)上進(jìn)一步對(duì)自動(dòng)化數(shù)據(jù)校驗(yàn)工具smart checker的實(shí)現(xiàn)進(jìn)行闡述。關(guān)鍵詞軟件測(cè)試 軟件測(cè)試自動(dòng)化框架 xml lcsiiabstractsoftware 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 conceptiontest 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 compare features of existing test automation frameworks first. then specify the architecture of data-driven 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 iii浙江大學(xué)本科畢業(yè)論文 目錄目錄摘要iabstractii第1章 緒論11.1 課題背景和意義11.2 論文所做的工作2第2章 軟件自動(dòng)化測(cè)試框架的介紹32.1 自動(dòng)化測(cè)試框架概述32.2 模塊化測(cè)試框架32.3 測(cè)試庫(kù)框架42.4 數(shù)據(jù)驅(qū)動(dòng)測(cè)試框架42.5 關(guān)鍵字驅(qū)動(dòng)或標(biāo)驅(qū)動(dòng)測(cè)試框架42.6 混合測(cè)試自動(dòng)化框架52.7 本章小結(jié)5第3章 數(shù)據(jù)驅(qū)動(dòng)的信息自動(dòng)化校驗(yàn)框架的設(shè)計(jì)和應(yīng)用技術(shù)的研究73.1 總體架構(gòu)分析和設(shè)計(jì)73.2 系統(tǒng)工作流程93.3 校驗(yàn)過程103.3.1 線性循環(huán)校驗(yàn)103.3.2 lcs算法113.4 xml技術(shù)的研究和應(yīng)用143.4.1 xml簡(jiǎn)介143.4.2 schema和dtd143.4.3 dom153.4.4 xsl153.4.5 xpath153.5 本章小結(jié)16第4章 smart checker的實(shí)現(xiàn)174.1 總體需求分析174.1.1 compliance的介紹174.1.2 測(cè)試任務(wù)說明174.1.3 功能性需求184.1.4 性能需求184.1.5 移植性和擴(kuò)展性需求184.1.6 輸入和輸出184.1.7 數(shù)據(jù)映射關(guān)系194.2 系統(tǒng)架構(gòu)設(shè)計(jì)194.3 系統(tǒng)模塊設(shè)計(jì)214.3.1 數(shù)據(jù)引擎（data engine）214.3.2 數(shù)據(jù)管理器（data manager）234.3.3 校驗(yàn)引擎（checking engine）284.3.4 報(bào)告、日志生成模塊（report & log）294.4 系統(tǒng)數(shù)據(jù)文件說明304.4.1 用戶輸入文件304.4.2 系統(tǒng)配置文件314.4.3 內(nèi)部數(shù)據(jù)文件324.4.4 系統(tǒng)輸出文件334.5 使用說明334.6 本章小結(jié)37第5章 總結(jié)和展望385.1 總結(jié)385.2 問題和擴(kuò)展38參考文獻(xiàn)39致謝40v浙江大學(xué)本科畢業(yè)論文第1章 緒論第1章 緒論1.1 課題背景和意義軟件測(cè)試是在軟件開發(fā)周期中必不可少的、最耗時(shí)的一部分。從測(cè)試手段來看，軟件測(cè)試分為手工測(cè)試和自動(dòng)化測(cè)試。自動(dòng)化測(cè)試可以減少或消除一些手工測(cè)試中的重復(fù)和煩瑣， 節(jié)約測(cè)試所必需的時(shí)間和提高測(cè)試的一致性和可重復(fù)性， 提高產(chǎn)品質(zhì)量并盡可能在軟件生命周期的早期發(fā)現(xiàn)缺陷。正確、合理的實(shí)施測(cè)試自動(dòng)化，能夠快速、徹底的對(duì)軟件進(jìn)行測(cè)試， 從而提高軟件質(zhì)量， 節(jié)省經(jīng)費(fèi)， 縮短產(chǎn)品發(fā)布周期。但并非任何測(cè)試自動(dòng)化都可以起到預(yù)期效果， 只有好的自動(dòng)化測(cè)試體系才能揚(yáng)長(zhǎng)避短， 在質(zhì)量保障方面有所作為; 否則， 測(cè)試自動(dòng)化可能會(huì)由于其建立和維護(hù)等方面的負(fù)擔(dān)造成延誤工期、成本浪費(fèi)， 甚至最終被完全放棄4。從本質(zhì)上看，軟件測(cè)試自動(dòng)化就是將軟件測(cè)試的手動(dòng)測(cè)試用自動(dòng)化測(cè)試工具代替。所以說軟件測(cè)試自動(dòng)化跟軟件測(cè)試一樣，也有它自己的生命周期。有人就提出和公布了自動(dòng)化測(cè)試生命周期的方法學(xué)(automated test lifecycle methodology， atlm ) 這是一種調(diào)整的結(jié)構(gòu)化方法學(xué)，能確保自動(dòng)化測(cè)試的成功實(shí)現(xiàn)4。它定義了一種四階段方法學(xué)；自動(dòng)化測(cè)試的決定；自動(dòng)化測(cè)試的介紹；測(cè)試計(jì)劃、設(shè)計(jì)和開發(fā)；自動(dòng)化測(cè)試的執(zhí)行和管理軟件測(cè)試自動(dòng)化還有一個(gè)自動(dòng)化程度的問題，畢竟，由于各方面因素的限制，完全的軟件測(cè)試自動(dòng)化是不可能的。這是由測(cè)試過程和測(cè)試工具的本質(zhì)特點(diǎn)所決定的。測(cè)試工具和測(cè)試過程是不相同的。工具是用于促進(jìn)測(cè)試過程的，工具能被用于實(shí)現(xiàn)一個(gè)過程并執(zhí)行測(cè)試過程的各種規(guī)范。在很多情況下，工具自帶的內(nèi)建程序可以被理解為過程。但是它往往是不完整的，不能正確反映過程。最好的軟件測(cè)試工具是能夠?qū)⑺蜏y(cè)試需求達(dá)成一致，而且他們提供高度可定義的工作流程和跟蹤報(bào)告能力，但這是不可能的，要達(dá)到這樣的要求無(wú)異于再開發(fā)一個(gè)應(yīng)用程序。自動(dòng)化回歸測(cè)試貫穿整個(gè)開發(fā)過程的單元測(cè)試、集成測(cè)試和系統(tǒng)測(cè)試，并使用最大和最小發(fā)布版本的系統(tǒng)產(chǎn)品分別測(cè)試。所有領(lǐng)域的自動(dòng)化水平應(yīng)該達(dá)到這樣一種程度，它能夠根據(jù)時(shí)間和成本適應(yīng)用戶的標(biāo)準(zhǔn)。實(shí)現(xiàn)的自動(dòng)化程度越高，測(cè)試過程就越來越有效。同樣，軟件自動(dòng)測(cè)試并不是萬(wàn)能的，并不能解決所有的問題，甚至自動(dòng)化測(cè)試本身還存在這個(gè)方面的問題。因此，對(duì)于軟件測(cè)試自動(dòng)化進(jìn)行研究和探索是非常有價(jià)值的。compliance系統(tǒng)是公司遵照美國(guó)證券交易制度所開發(fā)的一個(gè)交易記錄匯報(bào)系統(tǒng)。當(dāng)前項(xiàng)目組的任務(wù)是對(duì)compliance各個(gè)子系統(tǒng)的日志文件進(jìn)行校驗(yàn)。在以往的手工測(cè)試中，測(cè)試員需要對(duì)日志文件中的每條記錄根據(jù)測(cè)試用例和測(cè)試數(shù)據(jù)進(jìn)行檢驗(yàn)。但是，由于compliance系統(tǒng)的日志文件的數(shù)據(jù)量過分龐大并且各個(gè)子系統(tǒng)的日志格式差別很大。因此根據(jù)軟件自動(dòng)化測(cè)試的相關(guān)知識(shí)和概念，我們分析后認(rèn)為完全有必要開發(fā)一個(gè)日志文件的校驗(yàn)工具來對(duì)compliance系統(tǒng)的各種日志文件進(jìn)行統(tǒng)一的自動(dòng)化校驗(yàn)。1.2 論文所做的工作本文主要描述數(shù)據(jù)驅(qū)動(dòng)的格式化信息自動(dòng)化校驗(yàn)工具的設(shè)計(jì)過程和關(guān)鍵技術(shù)，包括自動(dòng)化測(cè)試框架、數(shù)據(jù)校驗(yàn)框架，關(guān)鍵技術(shù)和系統(tǒng)實(shí)現(xiàn)四個(gè)部分進(jìn)行研究和分析。論文第二章介紹了現(xiàn)有的軟件自動(dòng)化測(cè)試框架，介紹了模塊化測(cè)試框架，測(cè)試庫(kù)框架，數(shù)據(jù)驅(qū)動(dòng)測(cè)試框架，關(guān)鍵字驅(qū)動(dòng)測(cè)試框架和混合測(cè)試框架。比較了不同測(cè)試框架的特點(diǎn)和應(yīng)用環(huán)境。論文第三章提出了數(shù)據(jù)校驗(yàn)框架的設(shè)計(jì)，框架分為數(shù)據(jù)引擎，數(shù)據(jù)管理器，校驗(yàn)引擎，報(bào)告日志生成器，ui五大模塊。并且定義了各個(gè)模塊的功能和交互關(guān)系和接口定義。同時(shí)也論述了在校驗(yàn)引擎中被使用到的數(shù)據(jù)比對(duì)算法線性循環(huán)比對(duì)算法和lcs算法。此外，本章對(duì)用于數(shù)據(jù)轉(zhuǎn)化和存儲(chǔ)的xml技術(shù)也進(jìn)行了論述。在第四章里，我們介紹了基于數(shù)據(jù)校驗(yàn)框架所實(shí)現(xiàn)的自動(dòng)化測(cè)試工具smart checker的設(shè)計(jì)和實(shí)現(xiàn)過程。包括系統(tǒng)需求的提取，軟件架構(gòu)的細(xì)化，軟件模塊的設(shè)計(jì)，數(shù)據(jù)文件的設(shè)計(jì)。詳細(xì)介紹了主要的類的功能和交互關(guān)系。論文最后總結(jié)了論文的主要成果和可能的擴(kuò)展之處，并對(duì)擴(kuò)展問題提出了可能實(shí)現(xiàn)的技術(shù)方案。2浙江大學(xué)本科畢業(yè)論文第2章軟件自動(dòng)化測(cè)試框架的介紹第2章 軟件自動(dòng)化測(cè)試框架的介紹2.1 自動(dòng)化測(cè)試框架概述 自動(dòng)化測(cè)試在過去的2o年中已經(jīng)有了很大的發(fā)展。最初的測(cè)試工具只提供了簡(jiǎn)單的捕捉回放功能：記錄并播放鍵盤按鍵，然后捕捉和比較屏幕。這些測(cè)試方法雖然最容易應(yīng)用 但是幾乎不可能維護(hù)。錄制回放工具最終被功能和靈活性更強(qiáng)的測(cè)試腳本工具代替但是腳本工具也有自己的問題。他們實(shí)現(xiàn)起來需要很強(qiáng)的開發(fā)技術(shù)和經(jīng)驗(yàn)同時(shí)不確定它們是一定可以維護(hù)的。更糟糕的是高度個(gè)性化的腳本工具技術(shù)加上沒有什么文檔記錄最后的結(jié)果經(jīng)常是重寫包含成千上萬(wàn)行代碼的腳本庫(kù)成本開銷巨大。后來，一種新的自動(dòng)化測(cè)試產(chǎn)品 自動(dòng)化測(cè)試框架出現(xiàn)了它可以減少實(shí)現(xiàn)和維護(hù)的成本使測(cè)試人員可以把精力集中在應(yīng)用程序的測(cè)試用例設(shè)計(jì)上，而不是開發(fā)測(cè)試。所謂自動(dòng)化測(cè)試框架，是由一些假設(shè) 概念和為自動(dòng)化測(cè)試提供支持的實(shí)踐組成的集合。自動(dòng)化測(cè)試框架和應(yīng)用軟件開發(fā)的框架有很多類似的地方， 也很強(qiáng)調(diào)模塊化和分層的概念， 通過抽象出不同的層來降低耦合， 增加聚合; 提高腳本開發(fā)效率， 方便維護(hù)， 增強(qiáng)穩(wěn)定性。傳統(tǒng)的結(jié)構(gòu)化線形腳本已經(jīng)無(wú)法滿足上面的要求， 新一代的自動(dòng)化測(cè)試框架提出無(wú)疑為自動(dòng)化測(cè)試提供了解決問題的手段。國(guó)內(nèi)外現(xiàn)有5種基本的軟件測(cè)試自動(dòng)化框架。2.2 模塊化測(cè)試框架模塊化測(cè)試腳本框架( test modularity framework) 需要?jiǎng)?chuàng)建小而獨(dú)立的可以描述的模塊、片斷以及待測(cè)應(yīng)用程序的腳本6。這些樹狀結(jié)構(gòu)的小腳本組合起來，就能組成能用于特定的測(cè)試用例的腳本。在這5種框架中，這個(gè)應(yīng)該是最容易掌握和使用的。在一個(gè)組件上方建立一個(gè)抽象層，使其在余下的應(yīng)用中隱藏起來，這是眾所周知的編程技巧。這把應(yīng)用同組件中的修改隔離開來，提供了程序設(shè)計(jì)的模塊化特性。模塊化測(cè)試腳本框架使用這一抽象或者封裝的原理來提高自動(dòng)測(cè)試組合的可維護(hù)性和可升級(jí)性。2.3 測(cè)試庫(kù)框架測(cè)試庫(kù)框架( test library architecture) 與模塊化測(cè)試腳本框架很類似，并且具有同樣的優(yōu)點(diǎn)。不同的是測(cè)試庫(kù)框架把待測(cè)應(yīng)用程序分解為過程和函數(shù)而不是腳本。這個(gè)框架需要?jiǎng)?chuàng)建描述模塊、片斷以及待測(cè)應(yīng)用程序的功能庫(kù)文件(例如sqabasic libraries，apis，dlls 等)6 。2.4 數(shù)據(jù)驅(qū)動(dòng)測(cè)試框架數(shù)據(jù)驅(qū)動(dòng)(data - driven) 測(cè)試是一個(gè)框架。在這里測(cè)試的輸入數(shù)據(jù)是從數(shù)據(jù)文件中讀取( 數(shù)據(jù)池，odbc 源，cvs 文件，excel 文件，dao 對(duì)象，ado 對(duì)象等) ，并且通過捕獲工具生成或者手工生成的代碼腳本被載入到變量中。在這個(gè)框架中，變量不僅被用來存放輸入值還被用來存放輸出的驗(yàn)證值。整個(gè)程序中， 測(cè)試腳本來讀取數(shù)值文件， 記載測(cè)試狀態(tài)和信息。這類似于表驅(qū)動(dòng)測(cè)試。在表驅(qū)動(dòng)測(cè)試中，它的測(cè)試用例是包含在數(shù)據(jù)文件而不是在腳本中， 對(duì)于數(shù)據(jù)而言， 腳本僅僅是一個(gè)“驅(qū)動(dòng)器”，或者是一個(gè)傳送機(jī)構(gòu)。然而，數(shù)據(jù)驅(qū)動(dòng)測(cè)試不同于表驅(qū)動(dòng)測(cè)試，盡管導(dǎo)航數(shù)據(jù)并不包含在表結(jié)構(gòu)中。在數(shù)據(jù)驅(qū)動(dòng)測(cè)試中， 數(shù)據(jù)文件中只包含測(cè)試數(shù)據(jù)。這個(gè)框架意圖減少你需要執(zhí)行所有測(cè)試用例所需要的總的測(cè)試腳本數(shù)。數(shù)據(jù)驅(qū)動(dòng)需要很少的代碼來產(chǎn)生大量的測(cè)試用例， 這與表驅(qū)動(dòng)極其類似1。2.5 關(guān)鍵字驅(qū)動(dòng)或標(biāo)驅(qū)動(dòng)測(cè)試框架對(duì)于一個(gè)獨(dú)立于應(yīng)用的自動(dòng)化框架， 關(guān)鍵字驅(qū)動(dòng)( keyword - driven) 測(cè)試和表驅(qū)動(dòng)( table - driven) 測(cè)試是可以互換的術(shù)語(yǔ)。這個(gè)框架需要開發(fā)數(shù)據(jù)表和關(guān)鍵字。這些數(shù)據(jù)表和關(guān)鍵字獨(dú)立于執(zhí)行它們的測(cè)試自動(dòng)化工具并可以用來“驅(qū)動(dòng)”待測(cè)應(yīng)用程序和數(shù)據(jù)的測(cè)試腳本代碼。關(guān)鍵字驅(qū)動(dòng)測(cè)試看上去與手工測(cè)試用例很類似。在一個(gè)關(guān)鍵字驅(qū)動(dòng)測(cè)試中，把待測(cè)應(yīng)用程序的功能和每個(gè)測(cè)試的執(zhí)行步驟一起寫到一個(gè)表中1。這個(gè)測(cè)試框架可以通過很少的代碼來產(chǎn)生大量的測(cè)試用例。同樣的代碼在用數(shù)據(jù)表來產(chǎn)生各個(gè)測(cè)試用例的同時(shí)被復(fù)用。關(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)技術(shù)中， 假設(shè)測(cè)試者具有某些被測(cè)系統(tǒng)的知識(shí)， 所以不必告訴測(cè)試者如何進(jìn)行詳細(xì)的動(dòng)作， 只是說明測(cè)試用例做什么， 而不是如何做。這樣在腳本中使用的是說明性方法和描述性方法。描述性方法將被測(cè)軟件的知識(shí)建立在測(cè)試自動(dòng)化環(huán)境中， 這種知識(shí)包含在支持腳本中。關(guān)鍵字驅(qū)動(dòng)腳本的數(shù)量不隨測(cè)試用例的數(shù)量變化， 而僅隨軟件規(guī)模而增加。關(guān)鍵字驅(qū)動(dòng)真正實(shí)現(xiàn)了數(shù)據(jù)與腳本分離， 測(cè)試邏輯與測(cè)試腳本分離， 實(shí)現(xiàn)了測(cè)試的完全定制7。使用模塊化的測(cè)試腳本組織測(cè)試， 因?yàn)樽詣?dòng)化測(cè)試就是編寫測(cè)試腳本去測(cè)試被測(cè)試程序， 所以腳本開發(fā)本身也與程序開發(fā)一樣， 在此使用的其實(shí)就是應(yīng)用程序的一種開發(fā)模式而已2。關(guān)鍵字驅(qū)動(dòng)技術(shù)是在數(shù)據(jù)驅(qū)動(dòng)基礎(chǔ)上發(fā)展起來的， 吸取了數(shù)據(jù)驅(qū)動(dòng)中將可變部分和不可變部分分離以降低維護(hù)工作量的思想， 將測(cè)試邏輯同測(cè)試腳本也分離開來。這一方式倡導(dǎo)只用腳本實(shí)現(xiàn)驅(qū)動(dòng)邏輯(這一塊也常叫framework)， 而測(cè)試邏輯和測(cè)試數(shù)據(jù)都不放在腳本中(至少不與framework 放在同一處)。就gui 測(cè)試而言， 比較有名的framework 有safs(software automation framework support) ， 它的目標(biāo)是試圖建立一個(gè)與平臺(tái)和執(zhí)行工具無(wú)關(guān)的引擎， 目前支持的自動(dòng)化測(cè)試工具中包含rational robot。2.6 混合測(cè)試自動(dòng)化框架最普遍的執(zhí)行框架是上面介紹的所有技術(shù)的一個(gè)結(jié)合，取其長(zhǎng)處，彌補(bǔ)其不足。這個(gè)混合測(cè)試框架是由大部分框架隨著時(shí)間并經(jīng)過若干項(xiàng)目演化而來的。2.7 本章小結(jié)基于上述5種基本框架產(chǎn)生的一些自動(dòng)化測(cè)試工具（如rational robot ，winrunner）都給實(shí)際的軟件測(cè)試工作帶來了很大的方便。使得測(cè)試人員得以把精力放在測(cè)試用例的設(shè)計(jì)上來。但是這些測(cè)試工具主要都是針對(duì)網(wǎng)絡(luò)應(yīng)用和用戶界面測(cè)試而設(shè)計(jì)的，對(duì)于一些跨平臺(tái)的面向數(shù)據(jù)的應(yīng)用往往顯得力不從心。并且為了追求更廣泛的適用性，這些自動(dòng)化測(cè)試工具在設(shè)計(jì)時(shí)，只是對(duì)一些公共的服務(wù)或功能提供了直接的測(cè)試手段。（如監(jiān)控網(wǎng)絡(luò)流量，抓取頁(yè)面對(duì)象，捕獲用戶操作行為等）11因此，在使用這些工具對(duì)實(shí)際的項(xiàng)目進(jìn)行測(cè)試時(shí)，必須用工具自帶的腳本語(yǔ)言或工具包寫測(cè)試腳本。如果針對(duì)一個(gè)功能點(diǎn)很多的項(xiàng)目，就可能要維護(hù)一個(gè)龐大的腳本庫(kù)。這樣給那些對(duì)測(cè)試工具或測(cè)試腳本庫(kù)并不非常熟悉的測(cè)試人員增加了上手的難度，無(wú)形中成為了軟件測(cè)試流程中的一個(gè)風(fēng)險(xiǎn)因素。6浙江大學(xué)本科畢業(yè)論文第3章smart checker的實(shí)現(xiàn)第3章 數(shù)據(jù)驅(qū)動(dòng)的信息自動(dòng)化校驗(yàn)框架的設(shè)計(jì)和應(yīng)用技術(shù)的研究3.1 總體架構(gòu)分析和設(shè)計(jì)數(shù)據(jù)的校驗(yàn)必定有兩類的數(shù)據(jù)信息：目標(biāo)數(shù)據(jù)信息和基準(zhǔn)數(shù)據(jù)信息。目標(biāo)數(shù)據(jù)信息是要校驗(yàn)的數(shù)據(jù)信息。它來源于實(shí)際的應(yīng)該用項(xiàng)目。主要是具體項(xiàng)目中和業(yè)務(wù)相關(guān)的數(shù)據(jù)信息。多以文件或數(shù)據(jù)庫(kù)數(shù)據(jù)的形式存在?；鶞?zhǔn)數(shù)據(jù)信息是一類模板信息， 這類信息已經(jīng)預(yù)先經(jīng)過一定的手段來確保其正確性，從而可以作為校驗(yàn)的一個(gè)基準(zhǔn)。這類數(shù)據(jù)信息多由測(cè)試員提供，或是直接從數(shù)據(jù)庫(kù)中提取。對(duì)于某些簡(jiǎn)單的業(yè)務(wù)邏輯則可能會(huì)根據(jù)需要編寫一定的腳本作為校驗(yàn)的基準(zhǔn)。因此可以對(duì)數(shù)據(jù)自動(dòng)化校驗(yàn)框架進(jìn)行如下的系統(tǒng)劃分圖3-1.數(shù)據(jù)自動(dòng)化框架數(shù)據(jù)引擎（data engine）主要功能： 從系統(tǒng)服務(wù)器上下載所需要校驗(yàn)的數(shù)據(jù)信息以文件的形式存儲(chǔ)在本地。根據(jù)不同系統(tǒng)的需求需要從系統(tǒng)服務(wù)器或數(shù)據(jù)庫(kù)中獲得不同的數(shù)據(jù)信息。由于不同系統(tǒng)應(yīng)用的數(shù)據(jù)庫(kù)結(jié)構(gòu)，服務(wù)器層次差別很大，所以無(wú)法構(gòu)建一個(gè)通用的模塊來統(tǒng)一實(shí)現(xiàn)獲得數(shù)據(jù)的功能。但是可以定義通用的接口提供擴(kuò)展能力。數(shù)據(jù)管理器（data manager）主要有三大功能： 存儲(chǔ)和管理測(cè)試數(shù)據(jù)文件，包括基準(zhǔn)數(shù)據(jù)信息文件，目標(biāo)數(shù)據(jù)信息文件等?？梢詫?shí)現(xiàn)模塊調(diào)用本地?cái)?shù)據(jù)庫(kù)來實(shí)現(xiàn)對(duì)數(shù)據(jù)文件的管理功能，也可以整合第三方測(cè)試管理工具來實(shí)現(xiàn)數(shù)據(jù)文件的管理功能。 對(duì)基準(zhǔn)數(shù)據(jù)信息文件中的原始的基準(zhǔn)數(shù)據(jù)信息進(jìn)行加工轉(zhuǎn)化處理來產(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ù)會(huì)被校驗(yàn)引擎直接裝載，因此是校驗(yàn)引擎的直接數(shù)據(jù)驅(qū)動(dòng)。 根據(jù)用戶配置裝載相應(yīng)的功能模塊和格式信息。并將這些信息和模塊提供給校驗(yàn)引擎。校驗(yàn)引擎（checking engine）: 主要負(fù)責(zé)對(duì)數(shù)據(jù)文件的校驗(yàn)工作。在校驗(yàn)的過程中會(huì)考慮使用部分的數(shù)據(jù)比對(duì)的算法以提高數(shù)據(jù)校驗(yàn)的效率和準(zhǔn)確率。用戶界面（ui）: 提供對(duì)系統(tǒng)簡(jiǎn)單的操作功能同時(shí)反饋少量的校驗(yàn)結(jié)果給用戶?？紤]目前項(xiàng)目的實(shí)際需要只開發(fā)出最常用的功能界面。對(duì)于用戶配置等功能則需要用戶直接通過編輯配置文件來實(shí)現(xiàn)。報(bào)告和日志（report & log）模塊： 主要負(fù)責(zé)將校驗(yàn)結(jié)果以一定的格式寫入到特定的文件中方便用戶定位問題。 對(duì)系統(tǒng)的某些異常和錯(cuò)誤進(jìn)行日志的記錄。3.2 系統(tǒng)工作流程圖3-2.系統(tǒng)工作流程圖1從應(yīng)用服務(wù)器上獲取需要的數(shù)據(jù)信息，從應(yīng)用數(shù)據(jù)庫(kù)中查詢必要的數(shù)據(jù)。2用戶通過界面向系統(tǒng)提供配置信息3裝載用戶配置信息。4根據(jù)用戶的配置裝載必要的校驗(yàn)功能模塊?？紤]到擴(kuò)展性，系統(tǒng)必須允許用戶配置特定的校驗(yàn)?zāi)K。當(dāng)需要驗(yàn)證新的功能點(diǎn)時(shí)，用戶可以自己根據(jù)實(shí)際需要擴(kuò)展部分接口實(shí)現(xiàn)自己的功能模塊。這部分配置功能不一定要在用戶界面中提供。用戶可以手工編輯系統(tǒng)配置文件來實(shí)現(xiàn)模塊的“插拔”和替換。5將從數(shù)據(jù)庫(kù)中查詢到的數(shù)據(jù)信息和用戶提供的基準(zhǔn)文件中的信息進(jìn)行合并在，轉(zhuǎn)化成一個(gè)的內(nèi)部數(shù)據(jù)文件。該文件可以用xml這種目前比較流行的數(shù)據(jù)格式來存儲(chǔ)。6從數(shù)據(jù)池中裝載內(nèi)部數(shù)據(jù)文件構(gòu)建成一個(gè)任務(wù)鏈表。任務(wù)鏈表由一系列測(cè)試用例數(shù)據(jù)組成，測(cè)試用例則分成一系列的用例記錄（record）組成。7遍歷任務(wù)鏈表，以任務(wù)鏈表中的數(shù)據(jù)為驅(qū)動(dòng)校驗(yàn)指定的日志文件。8 由報(bào)告和日志模塊生成測(cè)試報(bào)告3.3 校驗(yàn)過程3.3.1 線性循環(huán)校驗(yàn)tags，act，oats這些系統(tǒng)的數(shù)據(jù)信息有一個(gè)共同的特點(diǎn)，那就是每個(gè)域在一條記錄中所處的位置是固定的，即使該域的值為空，也會(huì)以一定的方式填補(bǔ)空位。對(duì)于這種域位置固定的格式，只需要采用線性循環(huán)檢驗(yàn)的方法就可以了。圖3-3. 線性循環(huán)校驗(yàn)法對(duì)于構(gòu)建的任務(wù)鏈表，我們依次檢驗(yàn)每一個(gè)測(cè)試用例。一個(gè)測(cè)試用例通常是由多條日志記錄組成的，我們需要依次檢驗(yàn)每一條的日志記錄。對(duì)于一條日志記錄，我們要檢驗(yàn)每個(gè)域。這種線性的循環(huán)檢驗(yàn)的方法能夠檢驗(yàn)到整個(gè)任務(wù)鏈表的所有數(shù)據(jù)，能夠提供用戶最詳細(xì)的校驗(yàn)信息。此外該方法的時(shí)間復(fù)雜度為n。是最為理想的校驗(yàn)方法。3.3.2 lcs算法fix協(xié)議的信息日志則比較特殊，它的域名直接在日志中出現(xiàn)，它使用類似“field _name=value”這樣的格式進(jìn)行記錄。如果某個(gè)域的值為空，則該域不會(huì)出現(xiàn)在日志記錄中。因此，在fix信息日志中域的位置是不確定的。對(duì)于這種格式，如果采用線性循環(huán)的方式進(jìn)行一對(duì)一的比對(duì)將會(huì)降低校驗(yàn)的效率。一條含有n個(gè)域的fix記錄的時(shí)間復(fù)雜度是n*n?？紤]到fix協(xié)議中的域排列的先后順序還是可以確定的，因此我們采用lcs算法來比對(duì)基準(zhǔn)記錄和目標(biāo)記錄。lcs算法被用來尋找來確定兩條記錄間最長(zhǎng)的公共子串。如果該子串與基準(zhǔn)記錄相同則可以確定目標(biāo)記錄是正確的，如果子串與基準(zhǔn)記錄不相同，則可以判定目標(biāo)記錄有錯(cuò)誤，而同時(shí)子串記錄的則是正確的域。這樣就能夠方便的給用戶提供出錯(cuò)信息了。原始的lcs算法：lcs問題就是求兩個(gè)字串最長(zhǎng)公共子串的問題。最原始的解法就是用一個(gè)矩陣來記錄兩個(gè)字串中所有位置的兩個(gè)字之間的匹配情況，若是匹配則為1，否則為0。然后求出對(duì)角線最長(zhǎng)的1序列，其對(duì)應(yīng)的位置就是最長(zhǎng)匹配子串的位置3。下面是字符串21232523311324和字符串312123223445的匹配矩陣，0 0 0 1 0 0 0 1 1 0 0 1 0 0 00 1 0 0 0 0 0 0 0 1 1 0 0 0 01 0 1 0 1 0 1 0 0 0 0 0 1 0 00 1 0 0 0 0 0 0 0 1 1 0 0 0 01 0 1 0 1 0 1 0 0 0 0 0 1 0 00 0 0 1 0 0 0 1 1 0 0 1 0 0 01 0 1 0 1 0 1 0 0 0 0 0 1 0 01 0 1 0 1 0 1 0 0 0 0 0 1 0 00 0 0 1 0 0 0 1 1 0 0 1 0 0 00 0 0 0 0 0 0 0 0 0 0 0 0 1 00 0 0 0 0 0 0 0 0 0 0 0 0 1 00 0 0 0 0 1 0 0 0 0 0 0 0 0 00 0 0 0 0 0 0 0 0 0 0 0 0 0 0.前者為x方向的，后者為y方向的。不難找到，紅色傾斜字體部分是最長(zhǎng)的匹配子串。通過查找位置我們得到最長(zhǎng)的匹配子串為：21232。但是在0和1的矩陣中找最長(zhǎng)的1對(duì)角線序列又要花去一定的時(shí)間。通過改進(jìn)矩陣的生成方式和設(shè)置標(biāo)記變量，可以省去這部分時(shí)間。下面是新的矩陣生成方式：0 0 0 1 0 0 0 1 1 0 0 1 0 0 00 1 0 0 0 0 0 0 0 2 1 0 0 0 01 0 2 0 1 0 1 0 0 0 0 0 1 0 00 2 0 0 0 0 0 0 0 1 1 0 0 0 01 0 3 0 1 0 1 0 0 0 0 0 10 00 0 0 4 0 0 0 2 1 0 0 1 0 0 01 0 1 0 5 0 1 0 0 0 0 0 2 0 01 0 1 0 1 0 1 0 0 0 0 0 1 0 00 0 0 2 0 0 0 2 1 0 0 1 0 0 00 0 0 0 0 0 0 0 0 0 0 0 0 1 00 0 0 0 0 0 0 0 0 0 0 0 0 1 00 0 0 0 0 1 0 0 0 0 0 0 0 0 00 0 0 0 0 0 0 0 0 0 0 0 0 0 0當(dāng)字符匹配的時(shí)候，我們并不是簡(jiǎn)單的給相應(yīng)元素賦上1，而是賦上其左上角元素的值加一3。我們用兩個(gè)標(biāo)記變量來標(biāo)記矩陣中值最大的元素的位置，在矩陣生成的過程中來判斷當(dāng)前生成的元素的值是不是最大的，據(jù)此來改變標(biāo)記變量的值，那么到矩陣完成的時(shí)候，最長(zhǎng)匹配子串的位置和長(zhǎng)度就已經(jīng)出來了。這樣做速度比較快，但是花的空間太多。我們注意到在改進(jìn)的矩陣生成方式當(dāng)中，每生成一行，前面的那一行就已經(jīng)沒有用了。因此我們只需使用一維數(shù)組即可?；镜膫未a如下： len1=str1.length(); len2=str2.length(); for(i=0;i=0;j-) if(str2i= =str1j) if(i= =0|j= =0) cj=1; else cj=cj-1+1; else cj=0; if(cjmax) max=cj; maxj=j; 在smartchecker中，我們只需要將原來lcs算法中的子串替換為field list就可以應(yīng)用于fix日志記錄的校驗(yàn)過程中來了。3.4 xml技術(shù)的研究和應(yīng)用3.4.1 xml簡(jiǎn)介xml (extensible markup language可擴(kuò)展標(biāo)識(shí)語(yǔ)言)是由w3c(互聯(lián)網(wǎng)聯(lián)合組織)于1998年2月發(fā)布的標(biāo)準(zhǔn)11。同樣是sgml的一個(gè)簡(jiǎn)化子集，它將sgml的豐富功能與html的易用性結(jié)合到web的應(yīng)用中，以一種開放的自我描述方式定義了數(shù)據(jù)結(jié)構(gòu)，在描述數(shù)據(jù)內(nèi)容的同時(shí)能突出對(duì)結(jié)構(gòu)的描述，從而體現(xiàn)出數(shù)據(jù)之間的關(guān)系。這樣所組織的數(shù)據(jù)對(duì)于應(yīng)用程序和人類都是友好的、可操作的。根據(jù)對(duì)xml的研究，發(fā)現(xiàn)其可擴(kuò)展性，靈活性，自描述性。雖然xml對(duì)于海量數(shù)據(jù)的處理立會(huì)帶來性能上的負(fù)面影響，但是普通的數(shù)據(jù)校驗(yàn)工作的數(shù)據(jù)處理完全可以使用xml來完成。3.4.2 schema和dtdxml只說明數(shù)據(jù)的結(jié)構(gòu)而并不關(guān)心數(shù)據(jù)是如何具體描述的、數(shù)據(jù)是否正確。xml文檔的強(qiáng)制性結(jié)構(gòu)化需求是通過dtd(文檔類型說明)或xml schema來實(shí)現(xiàn)的。xml schema是用一套預(yù)先規(guī)定的xml元素和屬性創(chuàng)建的，這些元素和屬性定義了文檔的結(jié)構(gòu)和內(nèi)容模式。相應(yīng)的一套精巧的規(guī)則指定了每個(gè)schema元素或者屬性的合法用途。如果違反這些規(guī)則解析器就會(huì)拒絕解析你的schema以及任何同它相聯(lián)系的文檔。使用dtd雖然在指定許可的元素、需要的元素以及給定xml文檔中如何組織元素等方面給我們以較大的方便，但是，一旦你想針對(duì)特定元素施加數(shù)據(jù)類型就會(huì)遇到麻煩了。dtd規(guī)范嚴(yán)格地定義了結(jié)構(gòu)，但只支持相對(duì)功能較弱的內(nèi)容類型規(guī)范，而對(duì)強(qiáng)制性結(jié)構(gòu)化卻無(wú)計(jì)可施，xml schema不僅可以讓你定義xml文檔的結(jié)構(gòu)而且還允許你約束文檔的內(nèi)容，這就不同于dtd了。另外，一個(gè)xml schema自身就是一個(gè)xml文檔，其基于標(biāo)簽的語(yǔ)法比dtd中的特殊字符要清楚多了。所以xml schema具有強(qiáng)制文檔內(nèi)容和結(jié)構(gòu)的能力，它是xml世界中的一種不但重要而且強(qiáng)大的新標(biāo)準(zhǔn)3。3.4.3 domdocument object model(文檔對(duì)象模型)簡(jiǎn)稱為dom，是對(duì)web文檔進(jìn)行應(yīng)用開發(fā)、編程的應(yīng)用程序接口(apt)。作為w3c公布的一種跨平臺(tái)、與語(yǔ)言無(wú)關(guān)的接口規(guī)范，dom提供了在不同環(huán)境和應(yīng)用中的標(biāo)準(zhǔn)程序接口，可以用任何語(yǔ)言實(shí)現(xiàn)。dom采用對(duì)象模型和一系列的接口來描述xml文檔的內(nèi)容和結(jié)構(gòu)，即利用對(duì)象把文檔模型化8。這種對(duì)象模型實(shí)現(xiàn)的基本功能包括:. 描述文檔表示和操作的接口;. 接口的行為和屬性;. 接口之間的關(guān)系以及互操作。dom對(duì)結(jié)構(gòu)化的xml文檔進(jìn)行解析，文檔中的指令、元素、實(shí)體、屬性等所有內(nèi)容個(gè)體都用對(duì)象模型表示，整個(gè)文檔的邏輯結(jié)構(gòu)類似一棵樹，生成的對(duì)象模型就是樹的節(jié)點(diǎn)，對(duì)象同時(shí)包含了方法和屬性。其后對(duì)文檔的所有操作都是在對(duì)象樹上的進(jìn)行。利用dom，開發(fā)人員可以動(dòng)態(tài)地創(chuàng)建xml文檔，遍歷結(jié)構(gòu)，添加、修改、刪除內(nèi)容等等。其面向?qū)ο蟮奶匦?，使人們?cè)谔幚韝ml解析相關(guān)的事務(wù)時(shí)節(jié)省大量精力，是一種符合代碼重用思想的強(qiáng)有力編程工具。3.4.4 xslxsl也就是可擴(kuò)展樣式表語(yǔ)言(extensible stylesheet language)。最開始，w3c準(zhǔn)備創(chuàng)建一種樣式表語(yǔ)言，稱為可擴(kuò)展樣式表語(yǔ)言(xsl)，很快人們發(fā)現(xiàn)，在xml文檔上操作的樣式表語(yǔ)言需要兩類主要的功能:也就是與表示和附加信息相關(guān)的功能，將數(shù)據(jù)轉(zhuǎn)換為特定類型的結(jié)果樹2。后來，xsl語(yǔ)言中用于表示(或者格式化方面)的部分被看作是格式化對(duì)象的xsl，或者簡(jiǎn)單的xsl-fo.數(shù)據(jù)轉(zhuǎn)換是由用于轉(zhuǎn)換的xsl處理的，也就是xslt。3.4.5 xpathxpath是另一種w3c標(biāo)準(zhǔn)，在xslt樣式表中使用xpath表達(dá)式來使得源xml文檔中的模板與對(duì)象(比如元素、屬性、處理指令、注釋和文本串)相關(guān)聯(lián)。當(dāng)源樹中的對(duì)象與特定的xpath表達(dá)式匹配的時(shí)候，與這個(gè)對(duì)象相關(guān)聯(lián)的模板將被實(shí)例化，并填入源文檔中的數(shù)據(jù)，然后編寫輸出文檔。xpath表達(dá)式也可以表示數(shù)值和布爾運(yùn)算符等數(shù)據(jù)類型9。所以，xdath也可以用來執(zhí)行簡(jiǎn)單的計(jì)算。3.5 本章小結(jié)這一章主要對(duì)數(shù)據(jù)驅(qū)動(dòng)的信息自動(dòng)化框架的架構(gòu)進(jìn)行分析和設(shè)計(jì)。此外還介紹了為實(shí)現(xiàn)該架構(gòu)所用到的主要技術(shù)。比如xml，lcs算法等。16第4章 smart checker的實(shí)現(xiàn)4.1 總體需求分析4.1.1 compliance的介紹compliance一個(gè)針對(duì)美國(guó)證券交易規(guī)則開發(fā)的交易匯報(bào)系統(tǒng)。按照美國(guó)證券交易規(guī)則的規(guī)定，券商所做的每一筆場(chǎng)外交易都必須在一定的時(shí)間內(nèi)匯報(bào)給證券交易所，托管銀行和結(jié)算公司等金融機(jī)構(gòu)或監(jiān)管機(jī)構(gòu)。compliance系統(tǒng)由oats，tags和act三個(gè)子系統(tǒng)組成，他們分別給nasd的oat，tags和act監(jiān)管系統(tǒng)進(jìn)行報(bào)告。它們有各自的需求規(guī)定，具體的匯報(bào)規(guī)則都可以在納斯達(dá)克的官方網(wǎng)站上找到。4.1.2 測(cè)試任務(wù)說明當(dāng)前項(xiàng)目組的任務(wù)是對(duì)compliance各個(gè)子系統(tǒng)的日志文件進(jìn)行校驗(yàn)。在以往的手工測(cè)試中，測(cè)試員需要對(duì)日志文件中的每條記錄根據(jù)測(cè)試用例和測(cè)試數(shù)據(jù)進(jìn)行檢驗(yàn)。但是，由于compliance系統(tǒng)的日志文件的數(shù)據(jù)量過分龐大。就拿其中的tags系統(tǒng)的操作日志文件為例，該日志文件的每條記錄都是對(duì)實(shí)際股票交易信息的記錄，每條記錄包含47個(gè)域。在qa環(huán)境下一個(gè)日志文件記錄得的是測(cè)試員所有的測(cè)試步驟即模擬交易操作。一共是64個(gè)測(cè)試用例大約將近500條的記錄。如果同時(shí)有多個(gè)測(cè)試員在compliance系統(tǒng)的前端進(jìn)行輸入訂單的操作，那么當(dāng)天的日志文件記錄將會(huì)達(dá)到上千條。如果在uat環(huán)境下，那么每天的日志記錄將會(huì)達(dá)到上萬(wàn)條。此外compliance系統(tǒng)包含多個(gè)子系統(tǒng)，各個(gè)子系統(tǒng)的日志格式差別很大。因此需要開發(fā)一個(gè)日志文件的校驗(yàn)工具來對(duì)compliance系統(tǒng)的各種日志文件進(jìn)行統(tǒng)一的自動(dòng)化校驗(yàn)。當(dāng)前的目標(biāo)是開發(fā)出一個(gè)對(duì)具有一定信息格式的數(shù)據(jù)文件進(jìn)行數(shù)據(jù)校驗(yàn)的自動(dòng)化測(cè)試工具。該工具能夠適用于絕大多數(shù)的數(shù)據(jù)文件校驗(yàn)工作。所以說只要用戶只要根據(jù)實(shí)際的項(xiàng)目需求提供一份簡(jiǎn)單的信息格式說明文件，對(duì)某些特殊域的校驗(yàn)方法也只要編寫簡(jiǎn)單的校驗(yàn)類即可實(shí)現(xiàn)自動(dòng)化的數(shù)據(jù)校驗(yàn)。該工具參考現(xiàn)有的軟件測(cè)試自動(dòng)化框架模型的架構(gòu)，針對(duì)項(xiàng)目應(yīng)用的實(shí)際情況進(jìn)行開發(fā)。4.1.3 功能性需求smart checker必須對(duì)被校驗(yàn)的信息文件的記錄進(jìn)行檢驗(yàn)，在檢驗(yàn)的過程中要對(duì)記錄的每一個(gè)域的值，格式，長(zhǎng)度都按照配置文件的定義進(jìn)行驗(yàn)證，一旦發(fā)現(xiàn)不符合規(guī)范就要向用戶報(bào)告。smart checker對(duì)于每次的測(cè)試任務(wù)都要給出兩份測(cè)試報(bào)告。其中一份是對(duì)測(cè)試結(jié)果的概括性記錄。即說明哪個(gè)測(cè)試用例的結(jié)果是正確的，哪個(gè)是錯(cuò)誤的。這份概要性的記錄可以不生成文檔直接在ui上顯示。另外一份測(cè)試報(bào)告則是對(duì)每一個(gè)測(cè)試用例的測(cè)試步驟的詳細(xì)記錄，所有校驗(yàn)過程的中間數(shù)據(jù)都將被記錄在里面，這樣使得用戶可以快速深入地定位問題產(chǎn)生的原因。smart checker需要給用戶提供一個(gè)簡(jiǎn)單方便的操作界面。4.1.4 性能需求由于在實(shí)際的compliance環(huán)境中，需要校驗(yàn)的數(shù)據(jù)文件通常比較大，通常在2-4m之間。因此對(duì)數(shù)據(jù)文件的校驗(yàn)必須有一定的機(jī)制保證校驗(yàn)的效率。smart checker在校驗(yàn)文件的過程中應(yīng)盡量少地占用系統(tǒng)資源，原則上不超過6m。4.1.5 移植性和擴(kuò)展性需求smart checker 至少能在window 和linux兩大操作系統(tǒng)上運(yùn)行。目前主要是針對(duì)compliance的各個(gè)子系統(tǒng)，包括tags，act，oats。但經(jīng)過對(duì)這3個(gè)子系統(tǒng)的日志文件的格式分析，可以發(fā)現(xiàn)，這三個(gè)系統(tǒng)所包含的格式幾乎可以涵蓋一般的金融業(yè)務(wù)的信息日志的記錄格式了。4.1.6 輸入和輸出用戶在使用smart checker時(shí)需要提供一份基準(zhǔn)文件（baseline file）作為校驗(yàn)的標(biāo)準(zhǔn)值，另外提供一份需要檢驗(yàn)的目標(biāo)文件（target file）。由于在金融系統(tǒng)中每次交易的訂單號(hào)是不固定的，所以必須額外的提供兩份訂單號(hào)文件（baseline_oid file 和 target_oid file）分別用于標(biāo)識(shí)在基準(zhǔn)文件和目標(biāo)文件中各個(gè)測(cè)試用例所對(duì)應(yīng)的訂單號(hào)，從而能夠?qū)烧叩臄?shù)據(jù)記錄進(jìn)行匹配實(shí)現(xiàn)數(shù)據(jù)的校驗(yàn)。在用戶界面上，也額外地提供用戶直接從系統(tǒng)服務(wù)器和數(shù)據(jù)庫(kù)中直接獲取數(shù)據(jù)的功能。4.1.7 數(shù)據(jù)映射關(guān)系針對(duì)compliance系統(tǒng)的日志特點(diǎn)，我們將日志記錄的域分為固定域和非固定域。固定域的基準(zhǔn)值從用戶提供的基準(zhǔn)文件中獲得，非固定域的基準(zhǔn)值從數(shù)據(jù)庫(kù)中查詢獲得。圖4-1.數(shù)據(jù)映射圖4.2 系統(tǒng)架構(gòu)設(shè)計(jì)由于comgpliance系統(tǒng)的日志文件格式都是以一個(gè)個(gè)代表不同含義的數(shù)據(jù)域組成的，因此首先對(duì)這些域的特點(diǎn)進(jìn)行分析?？梢园l(fā)現(xiàn)這些域主要分為兩類：一類我們稱之為固定（fixed）的域。即這些域的值是可以通過測(cè)試用例來確定的。我們可以根據(jù)測(cè)試用例文檔中說明的測(cè)試步驟按照業(yè)務(wù)邏輯來直接確定這些域的值，比如：股票名稱（symbol），委托數(shù)量（original_quantity），委托價(jià)格（price）等。只要測(cè)試用例不變，那每次執(zhí)行測(cè)試用例所得到的日志記錄中這些域的值都是固定不變。另一類我們稱之為變動(dòng)的域。即這些域的值是不可以通過測(cè)試用例來確定的。如委托時(shí)間（order time），交易時(shí)間（action time）等。這些域的值在每次回歸測(cè)試的時(shí)候都會(huì)發(fā)生改變。對(duì)于這兩種不同類型的域，必須采用兩種不同的方法來采集測(cè)試基準(zhǔn)數(shù)據(jù)（base line data）。對(duì)于那些不變的域，可以從原有的歷史測(cè)試數(shù)據(jù)中提取基準(zhǔn)數(shù)據(jù)。為了方便起見。例如針對(duì)tags測(cè)試，我們直接選取一份包含所有tag64個(gè)測(cè)試用例信息的日志文件作為基準(zhǔn)數(shù)據(jù)的來源。在對(duì)這份日志文件進(jìn)行簡(jiǎn)單的手工處理之后就直接作為用戶輸入的基準(zhǔn)文件（baseline file）。當(dāng)然前提是我們已經(jīng)對(duì)該文件進(jìn)行了手工校驗(yàn)，已經(jīng)充分保證了該文件的正確性。手工校驗(yàn)這么一份文件的工作量是巨大的，如果只進(jìn)行一次的校驗(yàn)，結(jié)果是得不償失的。這也說明了最適合自動(dòng)化測(cè)試的項(xiàng)目都是那些需要進(jìn)行多次回歸測(cè)試的項(xiàng)目。對(duì)于那些變動(dòng)的域，唯一的辦法就是查詢系統(tǒng)的數(shù)據(jù)庫(kù)來獲得正確的基準(zhǔn)值。根據(jù)系統(tǒng)需求和上述分析，我們可以對(duì)數(shù)據(jù)驅(qū)動(dòng)的信息校驗(yàn)工具的各個(gè)模塊進(jìn)行進(jìn)一步的功能劃分，從而構(gòu)建出一個(gè)詳細(xì)的系統(tǒng)架構(gòu)圖。下圖中不僅描述了各個(gè)模塊之間的關(guān)系還包括了模塊與數(shù)據(jù)文件之間的關(guān)系。由于ui界面與報(bào)告和日志模塊功能點(diǎn)比較明顯，篇幅所限不在圖中描述。圖4-2. smart checker系統(tǒng)架構(gòu)圖4.3 系統(tǒng)模塊設(shè)計(jì)4.3.1 數(shù)據(jù)引擎（data engine）圖4-3. data engine 類圖databaseaccess 類是一個(gè)抽象類，它定義了從數(shù)據(jù)庫(kù)獲得特定域信息的公共接口。tags_databaseaccess，qats_databaseaccess，act_databaseaccess都是databaseaccess的子類，它們分別是針對(duì)tags，oats和act系統(tǒng)數(shù)據(jù)庫(kù)來實(shí)現(xiàn)的。因?yàn)檫@三者數(shù)據(jù)庫(kù)表結(jié)構(gòu)的差異很大，所以無(wú)法定義一個(gè)通用的查詢過程來實(shí)現(xiàn)對(duì)三個(gè)數(shù)據(jù)庫(kù)的查詢。serveraccess類提供了使用ssh協(xié)議從服務(wù)器上下載日志文件的功能。該類是對(duì)開源開發(fā)包的封裝。dataenginefac類是一個(gè)工廠化抽象類，定義了創(chuàng)建不同databaseaccess類的創(chuàng)建過程。它給用戶提供提供了統(tǒng)一的接口來構(gòu)建特定的databaseaccess類。為日后的功能上的擴(kuò)充提供了一個(gè)統(tǒng)一靈活的接口。4.3.2 數(shù)據(jù)管理器（data manager）數(shù)據(jù)管理器（data manager）模塊主要包括三個(gè)包：fieldconfig package，testcasegenerator package和indexgenerator package。fieldconfig package中主要實(shí)現(xiàn)了讀取裝載用戶配置信息和相應(yīng)功能模塊的功能。它內(nèi)部的類結(jié)構(gòu)層次圖如下：圖4-4. field config package類圖fieldloadermanager類主要負(fù)責(zé)對(duì)用戶定義的格式信息的解析和裝載。在裝載過程完成以后，它將產(chǎn)生一個(gè)fieldcfginfo類，該類記錄了多有用戶定義的格式信息。實(shí)際上該類是用戶定義的格式信息在smartchecker中的內(nèi)部數(shù)據(jù)表示，數(shù)據(jù)校驗(yàn)引擎就是直接從該類種獲得格式信息的。一個(gè)fieldcfginfo 類包含多個(gè)format類。format類是用戶定義的各種格式的表示，一個(gè)format類代表一種具體的格式。一個(gè)format類中包含多個(gè)fieldinfo類。fieldinfo類記錄了在一種格式中每個(gè)域所表示的信息和相應(yīng)的格式定義，如：是何種數(shù)據(jù)類型，長(zhǎng)度多少，在記錄中的位置是第幾位，以何種形式表示，是否是固定不變的，是否需要校驗(yàn)等。此外一個(gè)format類還包含一個(gè)spliterfactory。spliterfactory是一個(gè)抽象的工廠化類。它定義了產(chǎn)生stringspliter的接口。stringspliter類也是一個(gè)抽象類，定義的是如何對(duì)一條記錄進(jìn)行分解的方法，它將一條記錄按域分成一個(gè)數(shù)組。比如部分的tag，oats日志格式是用逗號(hào)或分號(hào)來作為域和域之間的分隔符的，那么針對(duì)這種格式就需要有一個(gè)特定的格式分解類symbolspliter。而其他的格式則使用確定每一個(gè)域在一條記錄中的起始和終結(jié)位置來解析，那么針對(duì)這樣的格式需要另一個(gè)解析類lengthspliter。圖4-5. field config package類圖由于每一個(gè)域的數(shù)據(jù)類型和格式定義上的差別，我們需要針對(duì)不同的數(shù)據(jù)類型和開發(fā)出不同的數(shù)據(jù)校驗(yàn)工具類。比如針對(duì)數(shù)值型的域，使用numericmethod類來校驗(yàn)，針對(duì)字符型的域使用charmethod類來校驗(yàn)，針對(duì)日期型的域，使用datemethod來校驗(yàn)（該類沒有在類圖中體現(xiàn)）。用戶也可以根據(jù)具體的需要編寫自己的校驗(yàn)類，然后在系統(tǒng)配置文件中進(jìn)行配置，由smartchecker在執(zhí)行校驗(yàn)任務(wù)時(shí)動(dòng)態(tài)裝載和使用。ckmethodcfgloadermanager類負(fù)責(zé)對(duì)這些校驗(yàn)方法類的裝載過程進(jìn)行管理和監(jiān)控。在裝載完成后，將會(huì)產(chǎn)生一個(gè)checkmethodbox類。checkmethodbox類提供了一個(gè)數(shù)據(jù)集合的功能。用戶配置的校驗(yàn)方法類在被實(shí)例化裝載進(jìn)內(nèi)存以后都被統(tǒng)一的存放在checkmethodbox中。當(dāng)校驗(yàn)引擎需要對(duì)某一特定的數(shù)據(jù)類型進(jìn)行校驗(yàn)的時(shí)候，會(huì)從中獲取相應(yīng)的校驗(yàn)方法類。從某種程度上說，checkmethodbox類扮演的是一個(gè)系統(tǒng)工具箱的角色。testcasegenerator package的主要作用是根據(jù)用戶提供的基準(zhǔn)文件（baseline file）基準(zhǔn)訂單號(hào)文件（baseline order id file）目標(biāo)訂單號(hào)文件（target order id file）以及從數(shù)據(jù)庫(kù)中查詢的得到的域的信息來構(gòu)建一個(gè)內(nèi)部數(shù)據(jù)表示。具體的類層次結(jié)構(gòu)圖如下：圖4-6 testcasegenerator package類圖fileinfloader類就是實(shí)現(xiàn)上述將多個(gè)外部基準(zhǔn)數(shù)據(jù)文件轉(zhuǎn)化成統(tǒng)一的內(nèi)部數(shù)據(jù)表示的功能。在轉(zhuǎn)化之前，系統(tǒng)首先裝載fieldconfigloader包中的fieldcfginfo類，并且由indexgenerator模塊對(duì)用戶提供的基準(zhǔn)文件創(chuàng)建一個(gè)數(shù)據(jù)索引以提高解析和轉(zhuǎn)化的效率。注意根據(jù)系統(tǒng)需求定義，用戶提供的基準(zhǔn)文件實(shí)際上就是一份日志文件，只不過該日志文件已經(jīng)經(jīng)過用戶的手工校驗(yàn)，可以保證數(shù)據(jù)的正確性而已。所以基準(zhǔn)文件的大小要大于或等于實(shí)際需要校驗(yàn)的日志文件。印此對(duì)該文件建立索引還是有必要的。此外，由于每次執(zhí)行測(cè)試用例所得到的訂單號(hào)都是會(huì)改變的，所以用戶需要額外地提供一個(gè)基準(zhǔn)訂單號(hào)文件和對(duì)應(yīng)的目標(biāo)訂單號(hào)文件來確保校驗(yàn)的正常執(zhí)行。這兩個(gè)文件中的信息將被fileinfloader轉(zhuǎn)化為tcorderid類作為數(shù)據(jù)的內(nèi)部表示。tcorderid類包含多個(gè)oidlist類。這主要是考慮到一個(gè)測(cè)試用例可能會(huì)包含多個(gè)訂單號(hào)的情況。indexgenerator package中的類實(shí)現(xiàn)了對(duì)一