[论文]数据驱动的格式化信息自动校验工具.doc

本 科 生 毕 业 论 文（设计）题目 数据驱动的格式化信息自动校验工具 摘要软件测试是软件生命周期中的一个重要阶段，是保证软件质量的关键因素之一。软件自动化测试技术可以减少软件测试的开销，提高测试的效率和准确率。软件测试自动化可分为：测试脚本、测试数据的自动化生成，测试用例的自动化执行，测试结果的自动化采集和分析三个方面。现有的自动化测试工具主要偏重于实现前两个方面的功能。本文提出一个基于数据驱动的文件信息自动化校验框架。并在此框架基础上实现了一个符合Compliance项目实际的文本校验工具Smart Checker。本文首先对现有的软件测试自动化框架的特点进行分析和比较。然后对提出的基于数据驱动的文件信息自动化校验框架进行阐述。其中会对使用到的XML技术和LCS算法进行研究。最后在框架的基础上进一步对自动化数据校验工具Smart Checker的实现进行阐述。关键词软件测试 软件测试自动化框架 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 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 目录摘要IAbstractII第1章 绪论11.1 课题背景和意义11.2 论文所做的工作2第2章 软件自动化测试框架的介绍32.1 自动化测试框架概述32.2 模块化测试框架32.3 测试库框架42.4 数据驱动测试框架42.5 关键字驱动或标驱动测试框架42.6 混合测试自动化框架52.7 本章小结5第3章 数据驱动的信息自动化校验框架的设计和应用技术的研究73.1 总体架构分析和设计73.2 系统工作流程93.3 校验过程103.3.1 线性循环校验103.3.2 LCS算法113.4 XML技术的研究和应用143.4.1 XML简介143.4.2 Schema和DTD143.4.3 DOM153.4.4 XSL153.4.5 Xpath153.5 本章小结16第4章 Smart Checker的实现174.1 总体需求分析174.1.1 Compliance的介绍174.1.2 测试任务说明174.1.3 功能性需求184.1.4 性能需求184.1.5 移植性和扩展性需求184.1.6 输入和输出184.1.7 数据映射关系194.2 系统架构设计194.3 系统模块设计214.3.1 数据引擎（Data Engine）214.3.2 数据管理器（Data Manager）234.3.3 校验引擎（Checking Engine）284.3.4 报告、日志生成模块（Report & Log）294.4 系统数据文件说明304.4.1 用户输入文件304.4.2 系统配置文件314.4.3 内部数据文件324.4.4 系统输出文件334.5 使用说明334.6 本章小结37第5章 总结和展望385.1 总结385.2 问题和扩展38参考文献39致谢40第1章 绪论1.1 课题背景和意义软件测试是在软件开发周期中必不可少的、最耗时的一部分。从测试手段来看，软件测试分为手工测试和自动化测试。自动化测试可以减少或消除一些手工测试中的重复和烦琐， 节约测试所必需的时间和提高测试的一致性和可重复性， 提高产品质量并尽可能在软件生命周期的早期发现缺陷。正确、合理的实施测试自动化，能够快速、彻底的对软件进行测试， 从而提高软件质量， 节省经费， 缩短产品发布周期。但并非任何测试自动化都可以起到预期效果， 只有好的自动化测试体系才能扬长避短， 在质量保障方面有所作为; 否则， 测试自动化可能会由于其建立和维护等方面的负担造成延误工期、成本浪费， 甚至最终被完全放弃4。从本质上看，软件测试自动化就是将软件测试的手动测试用自动化测试工具代替。所以说软件测试自动化跟软件测试一样，也有它自己的生命周期。有人就提出和公布了自动化测试生命周期的方法学(Automated Test Lifecycle Methodology， ATLM ) 这是一种调整的结构化方法学，能确保自动化测试的成功实现4。它定义了一种四阶段方法学；自动化测试的决定；自动化测试的介绍；测试计划、设计和开发；自动化测试的执行和管理软件测试自动化还有一个自动化程度的问题，毕竟，由于各方面因素的限制，完全的软件测试自动化是不可能的。这是由测试过程和测试工具的本质特点所决定的。测试工具和测试过程是不相同的。工具是用于促进测试过程的，工具能被用于实现一个过程并执行测试过程的各种规范。在很多情况下，工具自带的内建程序可以被理解为过程。但是它往往是不完整的，不能正确反映过程。最好的软件测试工具是能够将它和测试需求达成一致，而且他们提供高度可定义的工作流程和跟踪报告能力，但这是不可能的，要达到这样的要求无异于再开发一个应用程序。自动化回归测试贯穿整个开发过程的单元测试、集成测试和系统测试，并使用最大和最小发布版本的系统产品分别测试。所有领域的自动化水平应该达到这样一种程度，它能够根据时间和成本适应用户的标准。实现的自动化程度越高，测试过程就越来越有效。同样，软件自动测试并不是万能的，并不能解决所有的问题，甚至自动化测试本身还存在这个方面的问题。因此，对于软件测试自动化进行研究和探索是非常有价值的。Compliance系统是公司遵照美国证券交易制度所开发的一个交易记录汇报系统。当前项目组的任务是对compliance各个子系统的日志文件进行校验。在以往的手工测试中，测试员需要对日志文件中的每条记录根据测试用例和测试数据进行检验。但是，由于compliance系统的日志文件的数据量过分庞大并且各个子系统的日志格式差别很大。因此根据软件自动化测试的相关知识和概念，我们分析后认为完全有必要开发一个日志文件的校验工具来对compliance系统的各种日志文件进行统一的自动化校验。1.2 论文所做的工作本文主要描述数据驱动的格式化信息自动化校验工具的设计过程和关键技术，包括自动化测试框架、数据校验框架，关键技术和系统实现四个部分进行研究和分析。论文第二章介绍了现有的软件自动化测试框架，介绍了模块化测试框架，测试库框架，数据驱动测试框架，关键字驱动测试框架和混合测试框架。比较了不同测试框架的特点和应用环境。论文第三章提出了数据校验框架的设计，框架分为数据引擎，数据管理器，校验引擎，报告日志生成器，UI五大模块。并且定义了各个模块的功能和交互关系和接口定义。同时也论述了在校验引擎中被使用到的数据比对算法线性循环比对算法和LCS算法。此外，本章对用于数据转化和存储的XML技术也进行了论述。在第四章里，我们介绍了基于数据校验框架所实现的自动化测试工具Smart Checker的设计和实现过程。包括系统需求的提取，软件架构的细化，软件模块的设计，数据文件的设计。详细介绍了主要的类的功能和交互关系。论文最后总结了论文的主要成果和可能的扩展之处，并对扩展问题提出了可能实现的技术方案。第2章 软件自动化测试框架的介绍2.1 自动化测试框架概述 自动化测试在过去的2O年中已经有了很大的发展。最初的测试工具只提供了简单的捕捉回放功能：记录并播放键盘按键，然后捕捉和比较屏幕。这些测试方法虽然最容易应用 但是几乎不可能维护。录制回放工具最终被功能和灵活性更强的测试脚本工具代替但是脚本工具也有自己的问题。他们实现起来需要很强的开发技术和经验同时不确定它们是一定可以维护的。更糟糕的是高度个性化的脚本工具技术加上没有什么文档记录最后的结果经常是重写包含成千上万行代码的脚本库成本开销巨大。后来，一种新的自动化测试产品 自动化测试框架出现了它可以减少实现和维护的成本使测试人员可以把精力集中在应用程序的测试用例设计上，而不是开发测试。所谓自动化测试框架，是由一些假设 概念和为自动化测试提供支持的实践组成的集合。自动化测试框架和应用软件开发的框架有很多类似的地方， 也很强调模块化和分层的概念， 通过抽象出不同的层来降低耦合， 增加聚合; 提高脚本开发效率， 方便维护， 增强稳定性。传统的结构化线形脚本已经无法满足上面的要求， 新一代的自动化测试框架提出无疑为自动化测试提供了解决问题的手段。国内外现有5种基本的软件测试自动化框架。2.2 模块化测试框架模块化测试脚本框架( Test Modularity Framework) 需要创建小而独立的可以描述的模块、片断以及待测应用程序的脚本6。这些树状结构的小脚本组合起来，就能组成能用于特定的测试用例的脚本。在这5种框架中，这个应该是最容易掌握和使用的。在一个组件上方建立一个抽象层，使其在余下的应用中隐藏起来，这是众所周知的编程技巧。这把应用同组件中的修改隔离开来，提供了程序设计的模块化特性。模块化测试脚本框架使用这一抽象或者封装的原理来提高自动测试组合的可维护性和可升级性。2.3 测试库框架测试库框架( Test Library Architecture) 与模块化测试脚本框架很类似，并且具有同样的优点。不同的是测试库框架把待测应用程序分解为过程和函数而不是脚本。这个框架需要创建描述模块、片断以及待测应用程序的功能库文件(例如SQABasic libraries，APIs，DLLs 等)6 。2.4 数据驱动测试框架数据驱动(Data - driven) 测试是一个框架。在这里测试的输入数据是从数据文件中读取( 数据池，ODBC 源，cvs 文件，excel 文件，DAO 对象，ADO 对象等) ，并且通过捕获工具生成或者手工生成的代码脚本被载入到变量中。在这个框架中，变量不仅被用来存放输入值还被用来存放输出的验证值。整个程序中， 测试脚本来读取数值文件， 记载测试状态和信息。这类似于表驱动测试。在表驱动测试中，它的测试用例是包含在数据文件而不是在脚本中， 对于数据而言， 脚本仅仅是一个“驱动器”，或者是一个传送机构。然而，数据驱动测试不同于表驱动测试，尽管导航数据并不包含在表结构中。在数据驱动测试中， 数据文件中只包含测试数据。这个框架意图减少你需要执行所有测试用例所需要的总的测试脚本数。数据驱动需要很少的代码来产生大量的测试用例， 这与表驱动极其类似1。2.5 关键字驱动或标驱动测试框架对于一个独立于应用的自动化框架， 关键字驱动( Keyword - driven) 测试和表驱动( Table - driven) 测试是可以互换的术语。这个框架需要开发数据表和关键字。这些数据表和关键字独立于执行它们的测试自动化工具并可以用来“驱动”待测应用程序和数据的测试脚本代码。关键字驱动测试看上去与手工测试用例很类似。在一个关键字驱动测试中，把待测应用程序的功能和每个测试的执行步骤一起写到一个表中1。这个测试框架可以通过很少的代码来产生大量的测试用例。同样的代码在用数据表来产生各个测试用例的同时被复用。关键字驱动(Keyword Driven， 有时也叫TableDriven) 是脚本技术的一种， 实际上是比较复杂的数据驱动技术的逻辑扩展， 将数据文件变成测试用例的描述， 用一系列关键字指定要执行的任务。在关键字驱动技术中， 假设测试者具有某些被测系统的知识， 所以不必告诉测试者如何进行详细的动作， 只是说明测试用例做什么， 而不是如何做。这样在脚本中使用的是说明性方法和描述性方法。描述性方法将被测软件的知识建立在测试自动化环境中， 这种知识包含在支持脚本中。关键字驱动脚本的数量不随测试用例的数量变化， 而仅随软件规模而增加。关键字驱动真正实现了数据与脚本分离， 测试逻辑与测试脚本分离， 实现了测试的完全定制7。使用模块化的测试脚本组织测试， 因为自动化测试就是编写测试脚本去测试被测试程序， 所以脚本开发本身也与程序开发一样， 在此使用的其实就是应用程序的一种开发模式而已2。关键字驱动技术是在数据驱动基础上发展起来的， 吸取了数据驱动中将可变部分和不可变部分分离以降低维护工作量的思想， 将测试逻辑同测试脚本也分离开来。这一方式倡导只用脚本实现驱动逻辑(这一块也常叫framework)， 而测试逻辑和测试数据都不放在脚本中(至少不与framework 放在同一处)。就GUI 测试而言， 比较有名的framework 有SAFS(Software Automation Framework Support) ， 它的目标是试图建立一个与平台和执行工具无关的引擎， 目前支持的自动化测试工具中包含Rational Robot。2.6 混合测试自动化框架最普遍的执行框架是上面介绍的所有技术的一个结合，取其长处，弥补其不足。这个混合测试框架是由大部分框架随着时间并经过若干项目演化而来的。2.7 本章小结基于上述5种基本框架产生的一些自动化测试工具（如Rational Robot ，Winrunner）都给实际的软件测试工作带来了很大的方便。使得测试人员得以把精力放在测试用例的设计上来。但是这些测试工具主要都是针对网络应用和用户界面测试而设计的，对于一些跨平台的面向数据的应用往往显得力不从心。并且为了追求更广泛的适用性，这些自动化测试工具在设计时，只是对一些公共的服务或功能提供了直接的测试手段。（如监控网络流量，抓取页面对象，捕获用户操作行为等）11因此，在使用这些工具对实际的项目进行测试时，必须用工具自带的脚本语言或工具包写测试脚本。如果针对一个功能点很多的项目，就可能要维护一个庞大的脚本库。这样给那些对测试工具或测试脚本库并不非常熟悉的测试人员增加了上手的难度，无形中成为了软件测试流程中的一个风险因素。第3章 数据驱动的信息自动化校验框架的设计和应用技术的研究3.1 总体架构分析和设计数据的校验必定有两类的数据信息：目标数据信息和基准数据信息。目标数据信息是要校验的数据信息。它来源于实际的应该用项目。主要是具体项目中和业务相关的数据信息。多以文件或数据库数据的形式存在。基准数据信息是一类模板信息， 这类信息已经预先经过一定的手段来确保其正确性，从而可以作为校验的一个基准。这类数据信息多由测试员提供，或是直接从数据库中提取。对于某些简单的业务逻辑则可能会根据需要编写一定的脚本作为校验的基准。因此可以对数据自动化校验框架进行如下的系统划分图3-1.数据自动化框架数据引擎（Data Engine）主要功能： · 从系统服务器上下载所需要校验的数据信息以文件的形式存储在本地。根据不同系统的需求需要从系统服务器或数据库中获得不同的数据信息。由于不同系统应用的数据库结构，服务器层次差别很大，所以无法构建一个通用的模块来统一实现获得数据的功能。但是可以定义通用的接口提供扩展能力。数据管理器（Data Manager）主要有三大功能：· 存储和管理测试数据文件，包括基准数据信息文件，目标数据信息文件等。可以实现模块调用本地数据库来实现对数据文件的管理功能，也可以整合第三方测试管理工具来实现数据文件的管理功能。· 对基准数据信息文件中的原始的基准数据信息进行加工转化处理来产生测试基准数据，这些基准数据以测试用例为单位进行组织，以统一的格式存储于持久数据存储多项中，这些转化后的数据被用作测试用例的内部数据表示。这些数据会被校验引擎直接装载，因此是校验引擎的直接数据驱动。· 根据用户配置装载相应的功能模块和格式信息。并将这些信息和模块提供给校验引擎。校验引擎（Checking Engine）:· 主要负责对数据文件的校验工作。在校验的过程中会考虑使用部分的数据比对的算法以提高数据校验的效率和准确率。用户界面（UI）:· 提供对系统简单的操作功能同时反馈少量的校验结果给用户。考虑目前项目的实际需要只开发出最常用的功能界面。对于用户配置等功能则需要用户直接通过编辑配置文件来实现。报告和日志（Report & Log）模块：· 主要负责将校验结果以一定的格式写入到特定的文件中方便用户定位问题。· 对系统的某些异常和错误进行日志的记录。3.2 系统工作流程图3-2.系统工作流程图1从应用服务器上获取需要的数据信息，从应用数据库中查询必要的数据。2用户通过界面向系统提供配置信息3装载用户配置信息。4根据用户的配置装载必要的校验功能模块。考虑到扩展性，系统必须允许用户配置特定的校验模块。当需要验证新的功能点时，用户可以自己根据实际需要扩展部分接口实现自己的功能模块。这部分配置功能不一定要在用户界面中提供。用户可以手工编辑系统配置文件来实现模块的“插拔”和替换。5将从数据库中查询到的数据信息和用户提供的基准文件中的信息进行合并在，转化成一个的内部数据文件。该文件可以用XML这种目前比较流行的数据格式来存储。6从数据池中装载内部数据文件构建成一个任务链表。任务链表由一系列测试用例数据组成，测试用例则分成一系列的用例记录（record）组成。7遍历任务链表，以任务链表中的数据为驱动校验指定的日志文件。8 由报告和日志模块生成测试报告3.3 校验过程3.3.1 线性循环校验TAGS，ACT，OATS这些系统的数据信息有一个共同的特点，那就是每个域在一条记录中所处的位置是固定的，即使该域的值为空，也会以一定的方式填补空位。对于这种域位置固定的格式，只需要采用线性循环检验的方法就可以了。图3-3. 线性循环校验法对于构建的任务链表，我们依次检验每一个测试用例。一个测试用例通常是由多条日志记录组成的，我们需要依次检验每一条的日志记录。对于一条日志记录，我们要检验每个域。这种线性的循环检验的方法能够检验到整个任务链表的所有数据，能够提供用户最详细的校验信息。此外该方法的时间复杂度为N。是最为理想的校验方法。3.3.2 LCS算法FIX协议的信息日志则比较特殊，它的域名直接在日志中出现，它使用类似“field _name=value”这样的格式进行记录。如果某个域的值为空，则该域不会出现在日志记录中。因此，在FIX信息日志中域的位置是不确定的。对于这种格式，如果采用线性循环的方式进行一对一的比对将会降低校验的效率。一条含有N个域的FIX记录的时间复杂度是N*N。考虑到FIX协议中的域排列的先后顺序还是可以确定的，因此我们采用LCS算法来比对基准记录和目标记录。LCS算法被用来寻找来确定两条记录间最长的公共子串。如果该子串与基准记录相同则可以确定目标记录是正确的，如果子串与基准记录不相同，则可以判定目标记录有错误，而同时子串记录的则是正确的域。这样就能够方便的给用户提供出错信息了。原始的LCS算法：LCS问题就是求两个字串最长公共子串的问题。最原始的解法就是用一个矩阵来记录两个字串中所有位置的两个字之间的匹配情况，若是匹配则为1，否则为0。然后求出对角线最长的1序列，其对应的位置就是最长匹配子串的位置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对角线序列又要花去一定的时间。通过改进矩阵的生成方式和设置标记变量，可以省去这部分时间。下面是新的矩阵生成方式：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 0 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当字符匹配的时候，我们并不是简单的给相应元素赋上1，而是赋上其左上角元素的值加一3。我们用两个标记变量来标记矩阵中值最大的元素的位置，在矩阵生成的过程中来判断当前生成的元素的值是不是最大的，据此来改变标记变量的值，那么到矩阵完成的时候，最长匹配子串的位置和长度就已经出来了。这样做速度比较快，但是花的空间太多。我们注意到在改进的矩阵生成方式当中，每生成一行，前面的那一行就已经没有用了。因此我们只需使用一维数组即可。基本的伪代码如下： len1=str1.length();   len2=str2.length();   for(i=0;i<len2;i+)                for(j=len1-1;j>=0;j-)                      if(str2i= =str1j)                            if(i= =0|j= =0)                 cj=1;               else                 cj=cj-1+1;                                           else cj=0;              if(cj>max)                                   max=cj;                   maxj=j;                                  在SmartChecker中，我们只需要将原来LCS算法中的子串替换为field list就可以应用于FIX日志记录的校验过程中来了。3.4 XML技术的研究和应用3.4.1 XML简介XML (eXtensible Markup Language可扩展标识语言)是由W3C(互联网联合组织)于1998年2月发布的标准11。同样是SGML的一个简化子集，它将SGML的丰富功能与HTML的易用性结合到Web的应用中，以一种开放的自我描述方式定义了数据结构，在描述数据内容的同时能突出对结构的描述，从而体现出数据之间的关系。这样所组织的数据对于应用程序和人类都是友好的、可操作的。根据对XML的研究，发现其可扩展性，灵活性，自描述性。虽然XML对于海量数据的处理立会带来性能上的负面影响，但是普通的数据校验工作的数据处理完全可以使用XML来完成。3.4.2 Schema和DTDXML只说明数据的结构而并不关心数据是如何具体描述的、数据是否正确。XML文档的强制性结构化需求是通过DTD(文档类型说明)或XML schema来实现的。XML Schema是用一套预先规定的XML元素和属性创建的，这些元素和属性定义了文档的结构和内容模式。相应的一套精巧的规则指定了每个Schema元素或者属性的合法用途。如果违反这些规则解析器就会拒绝解析你的Schema以及任何同它相联系的文档。使用DTD虽然在指定许可的元素、需要的元素以及给定XML文档中如何组织元素等方面给我们以较大的方便，但是，一旦你想针对特定元素施加数据类型就会遇到麻烦了。DTD规范严格地定义了结构，但只支持相对功能较弱的内容类型规范，而对强制性结构化却无计可施，XML Schema不仅可以让你定义XML文档的结构而且还允许你约束文档的内容，这就不同于DTD了。另外，一个XML Schema自身就是一个XML文档，其基于标签的语法比DTD中的特殊字符要清楚多了。所以XML Schema具有强制文档内容和结构的能力，它是XML世界中的一种不但重要而且强大的新标准3。3.4.3 DOMDocument Object Model(文档对象模型)简称为DOM，是对Web文档进行应用开发、编程的应用程序接口(APT)。作为W3C公布的一种跨平台、与语言无关的接口规范，DOM提供了在不同环境和应用中的标准程序接口，可以用任何语言实现。DOM采用对象模型和一系列的接口来描述XML文档的内容和结构，即利用对象把文档模型化8。这种对象模型实现的基本功能包括:. 描述文档表示和操作的接口;. 接口的行为和属性;. 接口之间的关系以及互操作。DOM对结构化的XML文档进行解析，文档中的指令、元素、实体、属性等所有内容个体都用对象模型表示，整个文档的逻辑结构类似一棵树，生成的对象模型就是树的节点，对象同时包含了方法和属性。其后对文档的所有操作都是在对象树上的进行。利用DOM，开发人员可以动态地创建XML文档，遍历结构，添加、修改、删除内容等等。其面向对象的特性，使人们在处理XML解析相关的事务时节省大量精力，是一种符合代码重用思想的强有力编程工具。3.4.4 XSLXSL也就是可扩展样式表语言(Extensible Stylesheet Language)。最开始，W3C准备创建一种样式表语言，称为可扩展样式表语言(XSL)，很快人们发现，在XML文档上操作的样式表语言需要两类主要的功能:也就是与表示和附加信息相关的功能，将数据转换为特定类型的结果树2。后来，XSL语言中用于表示(或者格式化方面)的部分被看作是格式化对象的XSL，或者简单的XSL-FO.数据转换是由用于转换的XSL处理的，也就是XSLT。3.4.5 XpathXpath是另一种W3C标准，在XSLT样式表中使用Xpath表达式来使得源XML文档中的模板与对象(比如元素、属性、处理指令、注释和文本串)相关联。当源树中的对象与特定的Xpath表达式匹配的时候，与这个对象相关联的模板将被实例化，并填入源文档中的数据，然后编写输出文档。Xpath表达式也可以表示数值和布尔运算符等数据类型9。所以，XDath也可以用来执行简单的计算。3.5 本章小结这一章主要对数据驱动的信息自动化框架的架构进行分析和设计。此外还介绍了为实现该架构所用到的主要技术。比如XML，LCS算法等。第4章 Smart Checker的实现4.1 总体需求分析4.1.1 Compliance的介绍Compliance一个针对美国证券交易规则开发的交易汇报系统。按照美国证券交易规则的规定，券商所做的每一笔场外交易都必须在一定的时间内汇报给证券交易所，托管银行和结算公司等金融机构或监管机构。Compliance系统由OATS，TAGS和ACT三个子系统组成，他们分别给NASD的OAT，TAGS和ACT监管系统进行报告。它们有各自的需求规定，具体的汇报规则都可以在纳斯达克的官方网站上找到。4.1.2 测试任务说明当前项目组的任务是对compliance各个子系统的日志文件进行校验。在以往的手工测试中，测试员需要对日志文件中的每条记录根据测试用例和测试数据进行检验。但是，由于compliance系统的日志文件的数据量过分庞大。就拿其中的TAGS系统的操作日志文件为例，该日志文件的每条记录都是对实际股票交易信息的记录，每条记录包含47个域。在QA环境下一个日志文件记录得的是测试员所有的测试步骤即模拟交易操作。一共是64个测试用例大约将近500条的记录。如果同时有多个测试员在Compliance系统的前端进行输入订单的操作，那么当天的日志文件记录将会达到上千条。如果在UAT环境下，那么每天的日志记录将会达到上万条。此外Compliance系统包含多个子系统，各个子系统的日志格式差别很大。因此需要开发一个日志文件的校验工具来对compliance系统的各种日志文件进行统一的自动化校验。当前的目标是开发出一个对具有一定信息格式的数据文件进行数据校验的自动化测试工具。该工具能够适用于绝大多数的数据文件校验工作。所以说只要用户只要根据实际的项目需求提供一份简单的信息格式说明文件，对某些特殊域的校验方法也只要编写简单的校验类即可实现自动化的数据校验。该工具参考现有的软件测试自动化框架模型的架构，针对项目应用的实际情况进行开发。4.1.3 功能性需求smart checker必须对被校验的信息文件的记录进行检验，在检验的过程中要对记录的每一个域的值，格式，长度都按照配置文件的定义进行验证，一旦发现不符合规范就要向用户报告。smart checker对于每次的测试任务都要给出两份测试报告。其中一份是对测试结果的概括性记录。即说明哪个测试用例的结果是正确的，哪个是错误的。这份概要性的记录可以不生成文档直接在UI上显示。另外一份测试报告则是对每一个测试用例的测试步骤的详细记录，所有校验过程的中间数据都将被记录在里面，这样使得用户可以快速深入地定位问题产生的原因。smart checker需要给用户提供一个简单方便的操作界面。4.1.4 性能需求由于在实际的Compliance环境中，需要校验的数据文件通常比较大，通常在2-4M之间。因此对数据文件的校验必须有一定的机制保证校验的效率。Smart Checker在校验文件的过程中应尽量少地占用系统资源，原则上不超过6M。4.1.5 移植性和扩展性需求Smart Checker 至少能在window 和Linux两大操作系统上运行。目前主要是针对Compliance的各个子系统，包括TAGS，ACT，OATS。但经过对这3个子系统的日志文件的格式分析，可以发现，这三个系统所包含的格式几乎可以涵盖一般的金融业务的信息日志的记录格式了。4.1.6 输入和输出用户在使用Smart Checker时需要提供一份基准文件（baseline file）作为校验的标准值，另外提供一份需要检验的目标文件（Target file）。由于在金融系统中每次交易的订单号是不固定的，所以必须额外的提供两份订单号文件（BaseLine_OID file 和 Target_OID file）分别用于标识在基准文件和目标文件中各个测试用例所对应的订单号，从而能够将两者的数据记录进行匹配实现数据的校验。在用户界面上，也额外地提供用户直接从系统服务器和数据库中直接获取数据的功能。4.1.7 数据映射关系针对Compliance系统的日志特点，我们将日志记录的域分为固定域和非固定域。固定域的基准值从用户提供的基准文件中获得，非固定域的基准值从数据库中查询获得。图4-1.数据映射图4.2 系统架构设计由于comgpliance系统的日志文件格式都是以一个个代表不同含义的数据域组成的，因此首先对这些域的特点进行分析。可以发现这些域主要分为两类：一类我们称之为固定（fixed）的域。即这些域的值是可以通过测试用例来确定的。我们可以根据测试用例文档中说明的测试步骤按照业务逻辑来直接确定这些域的值，比如：股票名称（Symbol），委托数量（Original_Quantity），委托价格（Price）等。只要测试用例不变，那每次执行测试用例所得到的日志记录中这些域的值都是固定不变。另一类我们称之为变动的域。即这些域的值是不可以通过测试用例来确定的。如委托时间（Order Tim