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

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