【正文】 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方向的。這樣就能夠方便的給用戶提供出錯(cuò)信息了。一條含有N個(gè)域的FIX記錄的時(shí)間復(fù)雜度是N*N。 LCS算法FIX協(xié)議的信息日志則比較特殊，它的域名直接在日志中出現(xiàn)，它使用類(lèi)似“field _name=value”這樣的格式進(jìn)行記錄。對(duì)于一條日志記錄，我們要檢驗(yàn)每個(gè)域。 8 由報(bào)告和日志模塊生成測(cè)試報(bào)告 校驗(yàn)過(guò)程 線性循環(huán)校驗(yàn)TAGS，ACT，OATS這些系統(tǒng)的數(shù)據(jù)信息有一個(gè)共同的特點(diǎn)，那就是每個(gè)域在一條記錄中所處的位置是固定的，即使該域的值為空，也會(huì)以一定的方式填補(bǔ)空位。該文件可以用XML這種目前比較流行的數(shù)據(jù)格式來(lái)存儲(chǔ)。當(dāng)需要驗(yàn)證新的功能點(diǎn)時(shí)，用戶可以自己根據(jù)實(shí)際需要擴(kuò)展部分接口實(shí)現(xiàn)自己的功能模塊。 系統(tǒng)工作流程1從應(yīng)用服務(wù)器上獲取需要的數(shù)據(jù)信息，從應(yīng)用數(shù)據(jù)庫(kù)中查詢(xún)必要的數(shù)據(jù)。 Log）模塊： 提供對(duì)系統(tǒng)簡(jiǎn)單的操作功能同時(shí)反饋少量的校驗(yàn)結(jié)果給用戶。校驗(yàn)引擎（Checking Engine）:這些數(shù)據(jù)會(huì)被校驗(yàn)引擎直接裝載，因此是校驗(yàn)引擎的直接數(shù)據(jù)驅(qū)動(dòng)。 存儲(chǔ)和管理測(cè)試數(shù)據(jù)文件，包括基準(zhǔn)數(shù)據(jù)信息文件，目標(biāo)數(shù)據(jù)信息文件等。根據(jù)不同系統(tǒng)的需求需要從系統(tǒng)服務(wù)器或數(shù)據(jù)庫(kù)中獲得不同的數(shù)據(jù)信息。這類(lèi)數(shù)據(jù)信息多由測(cè)試員提供，或是直接從數(shù)據(jù)庫(kù)中提取。它來(lái)源于實(shí)際的應(yīng)該用項(xiàng)目。如果針對(duì)一個(gè)功能點(diǎn)很多的項(xiàng)目，就可能要維護(hù)一個(gè)龐大的腳本庫(kù)。使得測(cè)試人員得以把精力放在測(cè)試用例的設(shè)計(jì)上來(lái)。就GUI 測(cè)試而言， 比較有名的framework 有SAFS(Software Automation Framework Support) ， 它的目標(biāo)是試圖建立一個(gè)與平臺(tái)和執(zhí)行工具無(wú)關(guān)的引擎， 目前支持的自動(dòng)化測(cè)試工具中包含Rational Robot。關(guān)鍵字驅(qū)動(dòng)真正實(shí)現(xiàn)了數(shù)據(jù)與腳本分離， 測(cè)試邏輯與測(cè)試腳本分離， 實(shí)現(xiàn)了測(cè)試的完全定制[7]。在關(guān)鍵字驅(qū)動(dòng)技術(shù)中， 假設(shè)測(cè)試者具有某些被測(cè)系統(tǒng)的知識(shí)， 所以不必告訴測(cè)試者如何進(jìn)行詳細(xì)的動(dòng)作， 只是說(shuō)明測(cè)試用例做什么， 而不是如何做。在一個(gè)關(guān)鍵字驅(qū)動(dòng)測(cè)試中，把待測(cè)應(yīng)用程序的功能和每個(gè)測(cè)試的執(zhí)行步驟一起寫(xiě)到一個(gè)表中[1]。 關(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ǔ)。然而，數(shù)據(jù)驅(qū)動(dòng)測(cè)試不同于表驅(qū)動(dòng)測(cè)試，盡管導(dǎo)航數(shù)據(jù)并不包含在表結(jié)構(gòu)中。在這個(gè)框架中，變量不僅被用來(lái)存放輸入值還被用來(lái)存放輸出的驗(yàn)證值。不同的是測(cè)試庫(kù)框架把待測(cè)應(yīng)用程序分解為過(guò)程和函數(shù)而不是腳本。在一個(gè)組件上方建立一個(gè)抽象層，使其在余下的應(yīng)用中隱藏起來(lái)，這是眾所周知的編程技巧。國(guó)內(nèi)外現(xiàn)有5種基本的軟件測(cè)試自動(dòng)化框架。所謂自動(dòng)化測(cè)試框架，是由一些假設(shè) 概念和為自動(dòng)化測(cè)試提供支持的實(shí)踐組成的集合。錄制回放工具最終被功能和靈活性更強(qiáng)的測(cè)試腳本工具代替但是．腳本工具也有自己的問(wèn)題。論文最后總結(jié)了論文的主要成果和可能的擴(kuò)展之處，并對(duì)擴(kuò)展問(wèn)題提出了可能實(shí)現(xiàn)的技術(shù)方案。此外，本章對(duì)用于數(shù)據(jù)轉(zhuǎn)化和存儲(chǔ)的XML技術(shù)也進(jìn)行了論述。比較了不同測(cè)試框架的特點(diǎn)和應(yīng)用環(huán)境。但是，由于pliance系統(tǒng)的日志文件的數(shù)據(jù)量過(guò)分龐大并且各個(gè)子系統(tǒng)的日志格式差別很大。因此，對(duì)于軟件測(cè)試自動(dòng)化進(jìn)行研究和探索是非常有價(jià)值的。自動(dòng)化回歸測(cè)試貫穿整個(gè)開(kāi)發(fā)過(guò)程的單元測(cè)試、集成測(cè)試和系統(tǒng)測(cè)試，并使用最大和最小發(fā)布版本的系統(tǒng)產(chǎn)品分別測(cè)試。工具是用于促進(jìn)測(cè)試過(guò)程的，工具能被用于實(shí)現(xiàn)一個(gè)過(guò)程并執(zhí)行測(cè)試過(guò)程的各種規(guī)范。有人就提出和公布了自動(dòng)化測(cè)試生命周期的方法學(xué)(Automated Test Lifecycle Methodology， ATLM )— 這是一種調(diào)整的結(jié)構(gòu)化方法學(xué)，能確保自動(dòng)化測(cè)試的成功實(shí)現(xiàn)[4]。但并非任何測(cè)試自動(dòng)化都可以起到預(yù)期效果， 只有好的自動(dòng)化測(cè)試體系才能揚(yáng)長(zhǎng)避短， 在質(zhì)量保障方面有所作為。 Log） 29 系統(tǒng)數(shù)據(jù)文件說(shuō)明 30 用戶輸入文件 30 系統(tǒng)配置文件 31 內(nèi)部數(shù)據(jù)文件 32 系統(tǒng)輸出文件 33 使用說(shuō)明 33 本章小結(jié) 37第5章 總結(jié)和展望 38 總結(jié) 38 問(wèn)題和擴(kuò)展 38參考文獻(xiàn) 39致謝 40第1章 　緒論 課題背景和意義軟件測(cè)試是在軟件開(kāi)發(fā)周期中必不可少的、最耗時(shí)的一部分。然后對(duì)提出的基于數(shù)據(jù)驅(qū)動(dòng)的文件信息自動(dòng)化校驗(yàn)框架進(jìn)行闡述。現(xiàn)有的自動(dòng)化測(cè)試工具主要偏重于實(shí)現(xiàn)前兩個(gè)方面的功能。數(shù)據(jù)驅(qū)動(dòng)的格式化信息自動(dòng)校驗(yàn)工具摘要軟件測(cè)試是軟件生命周期中的一個(gè)重要階段，是保證軟件質(zhì)量的關(guān)鍵因素之一。本文提出一個(gè)基于數(shù)據(jù)驅(qū)動(dòng)的文件信息自動(dòng)化校驗(yàn)框架。其中會(huì)對(duì)使用到的XML技術(shù)和LCS算法進(jìn)行研究。從測(cè)試手段來(lái)看，軟件測(cè)試分為手工測(cè)試和自動(dòng)化測(cè)試。 否則， 測(cè)試自動(dòng)化可能會(huì)由于其建立和維護(hù)等方面的負(fù)擔(dān)造成延誤工期、成本浪費(fèi)， 甚至最終被完全放棄[4]。它定義了一種四階段方法學(xué)；自動(dòng)化測(cè)試的決定；自動(dòng)化測(cè)試的介紹；測(cè)試計(jì)劃、設(shè)計(jì)和開(kāi)發(fā)；自動(dòng)化測(cè)試的執(zhí)行和管理軟件測(cè)試自動(dòng)化還有一個(gè)自動(dòng)化程度的問(wèn)題，畢竟，由于各方面因素的限制，完全的軟件測(cè)試自動(dòng)化是不可能的。在很多情況下，工具自帶的內(nèi)建程序可以被理解為過(guò)程。所有領(lǐng)域的自動(dòng)化水平應(yīng)該達(dá)到這樣一種程度，它能夠根據(jù)時(shí)間和成本適應(yīng)用戶的標(biāo)準(zhǔn)。Compliance系統(tǒng)是公司遵照美國(guó)證券交易制度所開(kāi)發(fā)的一個(gè)交易記錄匯報(bào)系統(tǒng)。因此根據(jù)軟件自動(dòng)化測(cè)試的相關(guān)知識(shí)和概念，我們分析后認(rèn)為完全有必要開(kāi)發(fā)一個(gè)日志文件的校驗(yàn)工具來(lái)對(duì)pliance系統(tǒng)的各種日志文件進(jìn)行統(tǒng)一的自動(dòng)化校驗(yàn)。論文第三章提出了數(shù)據(jù)校驗(yàn)框架的設(shè)計(jì)，框架分為數(shù)據(jù)引擎，數(shù)據(jù)管理器，校驗(yàn)引擎，報(bào)告日志生成器，UI五大模塊。在第四章里，我們介紹了基于數(shù)據(jù)校驗(yàn)框架所實(shí)現(xiàn)的自動(dòng)化測(cè)試工具——Smart Checker的設(shè)計(jì)和實(shí)現(xiàn)過(guò)程。第2章 　軟件自動(dòng)化測(cè)試框架的介紹 自動(dòng)化測(cè)試框架概述 自動(dòng)化測(cè)試在過(guò)去的2O年中已經(jīng)有了很大的發(fā)展。他們實(shí)現(xiàn)起來(lái)需要很強(qiáng)的開(kāi)發(fā)技術(shù)和經(jīng)驗(yàn)．同時(shí)．不確定它們是一定可以維護(hù)的。自動(dòng)化測(cè)試框架和應(yīng)用軟件開(kāi)發(fā)的框架有很多類(lèi)似的地方， 也很強(qiáng)調(diào)模塊化和分層的概念， 通過(guò)抽象出不同的層來(lái)降低耦合， 增加聚合。 模塊化測(cè)試框架模塊化測(cè)試腳本框架( Test Modularity Framework) 需要?jiǎng)?chuàng)建小而獨(dú)立的可以描述的模塊、片斷以及待測(cè)應(yīng)用程序的腳本[6]。這把應(yīng)用同組件中的修改隔離開(kāi)來(lái)，提供了程序設(shè)計(jì)的模塊化特性。這個(gè)框架需要?jiǎng)?chuàng)建描述模塊、片斷以及待測(cè)應(yīng)用程序的功能庫(kù)文件(例如SQABasic libraries，APIs，DLLs 等)[6] 。整個(gè)程序中， 測(cè)試腳本來(lái)讀取數(shù)值文件， 記載測(cè)試狀態(tài)和信息。在數(shù)據(jù)驅(qū)動(dòng)測(cè)試中， 數(shù)據(jù)文件中只包含測(cè)試數(shù)據(jù)。這個(gè)框架需要開(kāi)發(fā)數(shù)據(jù)表和關(guān)鍵字。這個(gè)測(cè)試框架可以通過(guò)很少的代碼來(lái)產(chǎn)生大量的測(cè)試用例。這樣在腳本中使用的是說(shuō)明性方法和描述性方法。使用模塊化的測(cè)試腳本組織測(cè)試， 因?yàn)樽詣?dòng)化測(cè)試就是編寫(xiě)測(cè)試腳本去測(cè)試被測(cè)試程序， 所以腳本開(kāi)發(fā)本身也與程序開(kāi)發(fā)一樣， 在此使用的其實(shí)就是應(yīng)用程序的一種開(kāi)發(fā)模式而已[2]。 混合測(cè)試自動(dòng)化框架最普遍的執(zhí)行框架是上面介紹的所有技術(shù)的一個(gè)結(jié)合，取其長(zhǎng)處，彌補(bǔ)其不足。但是這些測(cè)試工具主要都是針對(duì)網(wǎng)絡(luò)應(yīng)用和用戶界面測(cè)試而設(shè)計(jì)的，對(duì)于一些跨平臺(tái)的面向數(shù)據(jù)的應(yīng)用往往顯得力不從心。這樣給那些對(duì)測(cè)試工具或測(cè)試腳本庫(kù)并不非常熟悉的測(cè)試人員增加了上手的難度，無(wú)形中成為了軟件測(cè)試流程中的一個(gè)風(fēng)險(xiǎn)因素。主要是具體項(xiàng)目中和業(yè)務(wù)相關(guān)的數(shù)據(jù)信息。對(duì)于某些簡(jiǎn)單的業(yè)務(wù)邏輯則可能會(huì)根據(jù)需要編寫(xiě)一定的腳本作為校驗(yàn)的基準(zhǔn)。由于不同系統(tǒng)應(yīng)用的數(shù)據(jù)庫(kù)結(jié)構(gòu)，服務(wù)器層次差別很大，所以無(wú)法構(gòu)建一個(gè)通用的模塊來(lái)統(tǒng)一實(shí)現(xiàn)獲得數(shù)據(jù)的功能?？梢詫?shí)現(xiàn)模塊調(diào)用本地?cái)?shù)據(jù)庫(kù)來(lái)實(shí)現(xiàn)對(duì)數(shù)據(jù)文件的管理功能，也可以整合第三方測(cè)試管理工具來(lái)實(shí)現(xiàn)數(shù)據(jù)文件的管理功能。 主要負(fù)責(zé)對(duì)數(shù)據(jù)文件的校驗(yàn)工作?？紤]目前項(xiàng)目的實(shí)際需要只開(kāi)發(fā)出最常用的功能界面。 主要負(fù)責(zé)將校驗(yàn)結(jié)果以一定的格式寫(xiě)入到特定的文件中方便用戶定位問(wèn)題。 2用戶通過(guò)界面向系統(tǒng)提供配置信息3裝載用戶配置信息。這部分配置功能不一定要在用戶界面中提供。6從數(shù)據(jù)池中裝載內(nèi)部數(shù)據(jù)文件構(gòu)建成一個(gè)任務(wù)鏈表。對(duì)于這種域位置固定的格式，只需要采用線性循環(huán)檢驗(yàn)的方法就可以了。這種線性的循環(huán)檢驗(yàn)的方法能夠檢驗(yàn)到整個(gè)任務(wù)鏈表的所有數(shù)據(jù)，能夠提供用戶最詳細(xì)的校驗(yàn)信息。如果某個(gè)域的值為空，則該域不會(huì)出現(xiàn)在日志記錄中?？紤]到FIX協(xié)議中的域排列的先后順序還是可以確定的，因此我們采用LCS算法來(lái)比對(duì)基準(zhǔn)記錄和目標(biāo)記錄。原始的LCS算法：LCS問(wèn)題就是求兩個(gè)字串最長(zhǎng)公共子串的問(wèn)題。不難找到，紅色傾斜字體部分是最長(zhǎng)的匹配子串。下面是新的矩陣生成方式：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 1我們注意到在改進(jìn)的矩陣生成方式當(dāng)中，每生成一行，前面的那一行就已經(jīng)沒(méi)有用了。 for(i=0。 for(j=len11。 if(i= =0||j= =0) c[j]=1。 maxj=j。 }在SmartChecker中，我們只需要將原來(lái)LCS算法中的子串替換為field list就可以應(yīng)用于FIX日志記錄的校驗(yàn)過(guò)程中來(lái)了。根據(jù)對(duì)XML的研究，發(fā)現(xiàn)其可擴(kuò)展性，靈活性，自描述性。XML Schema是用一套預(yù)先規(guī)定的XML元素和屬性創(chuàng)建的，這些元素和屬性定義了文檔的結(jié)構(gòu)和內(nèi)容模式。DTD規(guī)范嚴(yán)格地定義了結(jié)構(gòu)，但只支持相對(duì)功能較弱的內(nèi)容類(lèi)型規(guī)范，而對(duì)強(qiáng)制性結(jié)構(gòu)化卻無(wú)計(jì)可施，XML Schema不僅可以讓你定義XML文檔的結(jié)構(gòu)而且還允許你約束文檔的內(nèi)容，這就不同于DTD了。作為W3C公布的一種跨平臺(tái)、與語(yǔ)言無(wú)關(guān)的接口規(guī)范，DOM提供了在不同環(huán)境和應(yīng)用中的標(biāo)準(zhǔn)程序接口，可以用任何語(yǔ)言實(shí)現(xiàn)。. 接口之間的關(guān)系以及互操作。其面向?qū)ο蟮奶匦?，使人們?cè)谔幚鞽ML解析相關(guān)的事務(wù)時(shí)節(jié)省大量精力，是一種符合代碼重用思想的強(qiáng)有力編程工具。 XpathXpath是另一種W3C標(biāo)準(zhǔn)，在XSLT樣式表中使用Xpath表達(dá)式來(lái)使得源XML文檔中的模板與對(duì)象(比如元素、屬性、處理指令、注釋和文本串)相關(guān)聯(lián)。 本章小結(jié)這一章主要對(duì)數(shù)據(jù)驅(qū)動(dòng)的信息自動(dòng)化框架的架構(gòu)進(jìn)行分析和設(shè)計(jì)。按照美國(guó)證券交易規(guī)則的規(guī)定，券商所做的每一筆場(chǎng)外交易都必須在一定的時(shí)間內(nèi)匯報(bào)給證券交易所，托管銀行和結(jié)算公司等金融機(jī)構(gòu)或監(jiān)管機(jī)構(gòu)。在以往的手工測(cè)試中，測(cè)試員需要對(duì)日志文件中的每條記錄根據(jù)測(cè)試用例和測(cè)試數(shù)據(jù)進(jìn)行檢驗(yàn)。一共是64個(gè)測(cè)試用例大約將近500條的記錄。因此需要開(kāi)發(fā)一個(gè)日志文件的校驗(yàn)工具來(lái)對(duì)pliance系統(tǒng)的各種日志文件進(jìn)行統(tǒng)一的自動(dòng)化校驗(yàn)。該工具參考現(xiàn)有的軟件測(cè)試自動(dòng)化框架模型的架構(gòu)，針對(duì)項(xiàng)目應(yīng)用的實(shí)際情況進(jìn)行開(kāi)發(fā)。即說(shuō)明哪個(gè)測(cè)試用例的結(jié)果是正確的，哪個(gè)是錯(cuò)誤的。 性能需求由于在實(shí)際的Compliance環(huán)境中，需要校驗(yàn)的數(shù)據(jù)文件通常比較大，通常在24M之間。目前主要是針對(duì)Compliance的各個(gè)子系統(tǒng)，包括TAGS，ACT，OATS。在用戶界面上，也額外地提供用戶直接從系統(tǒng)服務(wù)器和數(shù)據(jù)庫(kù)中直接獲取數(shù)據(jù)的功能?？梢园l(fā)現(xiàn)這些域主要分為兩類(lèi)：一類(lèi)我們稱(chēng)之為固定（fixed）的域。另一類(lèi)我們稱(chēng)之為變動(dòng)的域。對(duì)于這兩種不同類(lèi)型的域，必須采用兩種不同的方法來(lái)采集測(cè)試基準(zhǔn)數(shù)據(jù)（Base Line Data）。在對(duì)這份日志文件進(jìn)行簡(jiǎn)單的手工處理之后就直接作為用戶輸入的基準(zhǔn)文件（BaseLine file）。對(duì)于那些變動(dòng)的域，唯一的辦法就是查詢(xún)系統(tǒng)的數(shù)據(jù)庫(kù)來(lái)獲得正確的基準(zhǔn)值。圖42. Smart Checker系統(tǒng)架構(gòu)圖 系統(tǒng)模塊設(shè)計(jì) 數(shù)據(jù)引擎（Data Engine）圖43. Data engine 類(lèi)圖DataBaseAccess 類(lèi)是一個(gè)抽象類(lèi)，它定義了從數(shù)據(jù)庫(kù)獲得特定域信息的公共接口。該類(lèi)是對(duì)開(kāi)源開(kāi)發(fā)包的封裝。 數(shù)據(jù)管理器（Data Manager）數(shù)據(jù)管理器（Data Manager）模塊主要包括三個(gè)包：fieldConfig Package，testCaseGenerator package和indexGenerator package。實(shí)際上該類(lèi)是用戶定義的格式信息在SmartChecker中的內(nèi)部數(shù)據(jù)表示，數(shù)據(jù)校驗(yàn)引擎就是直接從該類(lèi)種獲得格式信息的。FieldInfo類(lèi)記錄了在一種格式中每個(gè)域所表示的信息和相應(yīng)的格式定義，如：是何種數(shù)據(jù)類(lèi)型，長(zhǎng)度多少，在記錄中的位置是第幾位，以何種形式表示，是否是固定不變的，是否需要校驗(yàn)等。StringSpliter類(lèi)也是一個(gè)抽象類(lèi)，定義的是如何對(duì)一條記錄進(jìn)行分解的方法，它將一條記錄按域分成一個(gè)數(shù)組。比如針對(duì)數(shù)值型的域，使用NumericMethod類(lèi)來(lái)校驗(yàn)，針對(duì)字符型的域使用CharMethod類(lèi)來(lái)校驗(yàn)，針對(duì)日期型的域，使用DateMethod來(lái)校驗(yàn)（該類(lèi)沒(méi)有在類(lèi)圖中體現(xiàn)）。CheckMethodBo