基于数据库的Web应用的测试研究

楠族开心果

引言
    Internet技术在全球范围内极大限度地实现了各种网络资源的共享，因此在短时间内获得了广泛的普及，也促进了Web应用的快速发展。由于大部分应用软件是基于数据库开发的，这使得基于数据库的Web应用程序在应用软件中占据了越来越大的比重，相关的测试也得到了越来越多的重视和研究。与传统的应用软件相比．基于数据库的Web应用有很多独特的地方。其中对测试有影响的方面主要有以下几点：其一．用户数量巨大，并要求能提供对Web资源的跨平台全局访问，需要有处理并发事务的能力．因而需要进行多用户的性能测试。其二，Web应用具有分布式、动态性、多平台、交互式、超文本等特点且运行环境异构、自治，要求针对其特性分别选择测试方法。为降低测试成本，提高测试效率，需要一定的辅助工具以提高测试执行的自动化水平。其三，基于数据库的Web应用一般采用多层体系结构进行开发，因此需要对测试结果进行综合分析，以确定系统功能或性能问题存在的具体位置。本文在分析基于数据库的Web应用的测试模型的基础上，提出了一种测试方案和相应的实现方法，较好地实现了多层体系结构的基于数据库的Web应用的功能和性能测试。
    1 Web应用测试模型
    我们可以把Web看成一个使用方便、接受全局访问、具有图形化界面的大的数据库的前端。
    当软件的错误和性能问题最终暴露于客户机浏览器时，其产生的原因可能存在于包括客户机浏览器在内的各层当中。因此，要对其建立明确的功能和性能测试模型，以确定缺陷产生的位置并加以修复或进行改进。
    1．1功能测试模型
    从面向对象的观点来看，Web应用很直观地与类有对应关系(如超链接对应关联关系。页面对应类，页面的脚本对应类的操作，脚本中的页面所属的变量对应类的属性等)，因此，目前提出的Web功能测试的模型基本上都是基于面向对象思想而建立的。这里，使用D．C．Kung和C．一H．Liu等提出的Web应用行为模型中的页面导航图和对象状态图来描述页面间的导航和依赖行为。

定义1：页面导航图PND=(P，HL，，qo，F)，是一个有限状态自动机，P：所有页面的集合；舭：所有超链接的集合；：转移函数，3o=PxHL一>P；q0：起始页，q0∈P；F：终止页集合，F为P的子集。
    在有限状态自动机PND中，每一个状态表示一个页面，状态之间的变换表示超链接，并用对应的URL来标识．从而可以形式化地描述页面问的导航关系。之后，将这个图改写成一棵树，根节点为口。，每个节点的子节点为其通过超链接可以到达的页面．从而从根节点到每个叶子节点之间的路径就是测试路径。
    定义2：对象状态图OSD=(S，，6，q，q，)，也是一个有限状态自动机，S：状态空间；：Web页面的集合；g：初始状态；q：终结状态：6：变迁函数，6=．s×一>S，也可以将其表示为一个三元组<S。，d，>，其含义为：当系统处于状态SⅡ时，运行页面d会使系统的状态变为S。
    1．2-眭能测试模型
    响应时间是最终用户评价Web应用的主要指标，因此性能测试主要是确定在可接受的响应时间内，系统能够承受的并发用户的数量。性能问题的原因可能发生在Web服务器．应用服务器，数据库服务器或客户机浏览器等．考虑到问题发生的几率和分析的难度，以下对Web层和数据库层的性能模型进行分析。
    定义3：Web层性能6：FxLxE一>，这是一个映射的关系，其中，F为系统中需要进行性能测试的功能的集合，为可供选择的工作负载的集合，E为系统实际运行的环境，为对应的系统响应时间。F中的元素可以认为是运行定义1和2中的有限自动机所生成的树的路径。从应用角度来看，L中的元素可以围绕“并发用户数”这一Web应用的核心工作负载来进行定义，比如最大并发用户数，每类并发用户数所占的百分比等。E是由系统实际运行环境的各要素组成的．这里只考虑对e6应用的性能有重要影响的客户机浏览器、网络和服务器3个因素。
    由于数据库产品在发布前均经过了严格的功能和性能测试，因此我们一般不需要考虑数据库产品本身的性能问题．而只需要从e6应用的后台数据库的设计和配置方面考虑性能问题。数据库层的性能瓶颈往往来自于数据库设计的底层，以下对可能引发数据库瓶颈的典型原因进行一般性的分析。反规范化的考虑。逻辑数据模型是数据的理想蓝图，往往把符合第三范式(3NF)作为满足规范化数据库设计的依据，但是，物理数据模型才是对数据的现实的实现。规范化只关注数据的意义，而没有考虑对于访问数据的应用程序的性能需求。规范化设计引发的性能问题的常见例子是连接(join)操作。通常，规范化过程最终将相关的信息放入不同的表中。于是应用程序需要从多个这样的表中访问数据。关系数据库为SQL语句提供了从一个以上的表中访问信息的能力，这是通过连接多个表来完成的。由于需要为所有关联的表中的记录建立笛卡尔乘积，连接操作可能要消耗大量的资源和时间。因此，在逻辑数据库设计过程中。可以规范化数据模型，然后再加入一定程度的反规范化．作为性能凋优的一种选择优化索引。增加索引的数量可以显著提高数据库查询的效率。但是索引数量的增加势必会引起数据库更新时占用的系统开销。因此，只有在权衡两者的基础上为数据库表建立恰当的索引，才可以提高访问数据的Weh应用程序的性能。一般地，在系统资源满足的情况下，可以为查询语句中包含在WHERE和ORDERBY子句中的列建立索引。

楠族开心果

1．3测试方案
    需要建立一套规范化、易操作、可扩展的测试流程来指导基于数据库的Web应用的功能和性能的测试。在现有研究成果的基础上，建立如图2所示的测试方案。该方案中使用的自动化测试工具有MercuryInteractive公司的QTP(QuickTestProfessiona1)和Segue公司的Silk系列工具，它们都提供了脚本录制和较为丰富的配置功能，还有F．Ricca等提出的一种辅助测试工具ReWeb，使用它可以生成Web应用的功能模型。
    2测试实现技术和方法
    上述方案曾在某酒店预订系统中实际应用．该系统同时为全球范围内的近5000家酒店和每天超过10万的用户提供酒店预订服务。系统运行的软件环境为：Windows2000AdvancedServer．IIS6．0，数据库采用Oracle9i，Web页面使用CodeFu．sion开发。在测试中，分别选择了QTP，LoadRunner和TestDirector作为功能测试、性能测试和测试管理的工具。以下阐述方案在该应用中使用的重要技术和方法。
    功能测试设计。同一些Web应用类似，该软件规模较大，页面间调用关系较复杂，并且开发了多个在该业务领域使用广泛的数据平台的接口，因此在测试设计中遇到的一个较大的问题是如何保证测试用例完整覆盖了软件需求。在此过程中，使用生成动态行为模型并验证测试路径的方法较好地解决了该问题。首先识别主要的测试路径并实际执行．然后使用ReWeb工具生成该系统当前的页面导航图、状态转换图和相应的路径树，得到各页面的导航关系和调用的先后次序，根据业务逻辑分析实际存在的对页面的操作，并比较已存在的测试路径，从而识别出需要新增的测试路径并生成相应的测试用例。然后，经过几次迭代，测试路径较好地实现了对行为模型的覆盖，从而提高了对软件需求的覆盖程度和测试的质量。此外．由于工具本身不可能对软件功能之间的业务逻辑关系进行分析，因此这种方式可能会造成测试用例数量较多，在测试用例设计过程中又使用了组合测试技术(如图4)来解决这一问题。组合测试技术结合等价类划分、边界值分析等方法，保证了测试用例的质量．同时又减少了测试用例的数目，尤其是适用于具有多个参数并且参数问的相互作用会影响系统状态的功能在测试生命周期的各里程碑处，使用以下两个指标对基于需求的测试覆盖程度和基于代码的测试覆盖程度进行了度量。基于需求的测试覆盖=)／RJT'。其中表示用测试路径或测试用例表示的测试需求的规模，P，e，s分别表示已计划的，已实施的和已成功的，彤是测试需求的总数(RequirementforTest)。

基于代码的测试覆盖=I~／Tnic，其中．，是用代码语句，代码路径、代码分支等表示的测试覆盖的代码规模，Tnic(Totalnumberofitemsinthecode)是代码的总规模。统计证明，使用上述方法后的这两项指标均明显优于使用前。
    功能测试执行。在自动化测试脚本执行过程中．为加强对Bug统一的跟踪和管理，提高测试效率，对MercuryInteractive公司的TD和QTP两种工具进行了集成安装，这样，在脚本回放过程中，如果在某检查点发现了实际值和预期值不一致的情况，QTP会自动将该信息作为一个缺陷记录到TD，测试人员只需要到TD中查看登记缺陷的情况就可以对测试执行情况有清楚的了解，提高了测试执行的效率和测试管理的水平。测试数据度量分析。测试结束后，可以通过QTP和LoadRunner提供的测试报告查看功能和性能测试结果。并且可以通过TD来分析缺陷数据。但是，在此基础上，仍然需要进一步对测试结果进行定量分析，具体过程如图5所示。在本应用中，测试过程中对测试数据进行了较详细的统计和分析，为后续类似产品的测试规模、测试工作量、质量标准等数据估算工作提供了很有价值的依据和参考。应用结果证明．该方案较好地完成了测试用例设计、自动化的功能测试、性能测试、测试结果分析等任务。为该产品满足功能和性能需求并提供了保障。
    3结束语
    基于数据库的Web应用将成为应用软件的主流．本文分析了适合该类应用的测试模型，提出了一个包括测试需求分析、测试用例生成、功能和性能测试执行、测试结果分析的测试方案．并详细描述了实现该方案的重要技术和方法。未来的研究工作主要集中在如何快速准确地确定