Web应用程序的回归测试方法和装置

技术领域

本申请涉及互联网领域，具体而言，涉及一种Web应用程序的回归测试方法和装置。

背景技术

敏捷开发是当今全球的软件行业最为流行的开发方式之一，越来越多的在各国软件企业 中推行。敏捷开发的一个重要的特征为：频繁交付新的软件版本。然而，这个特征带来了频 繁的测试，而且，不能保证新增加的功能不会影响到以前的功能，所以敏捷开发模式下会频 繁地进行回归测试，也就是，把以前的功能重新测试一遍。这样，导致了大量重复的测试工 作，也成为了敏捷开发在实践中遇到的最大的问题。

上述回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致 其他代码产生错误。自动回归测试将大幅降低系统测试、维护升级等阶段的成本。回归测试 作为软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重，软件开 发的各个阶段都会进行多次回归测试。在渐进和快速迭代开发中，新版本的连续发布使回归 测试进行的更加频繁，而在极限编程方法中，更是要求每天都进行若干次回归测试。

敏捷开发理念对测试工作的压力在于产生频繁的、高重复性的测试工作。目前，国际上 还没有很好的解决方案，通常的回归测试的方法为单元测试+自动化测试+人工测试+其它辅助 工具(如图片比对测试)，上述自动化测试包括：使用商业软件(例如，QuickTestProfessional (快速测试专业QTP)等))进行测试。

上述单元测试的机制是：为软件(每个)“最基本单元”编写一段测试代码。然后运行这 些测试代码，检查“检测点”的实际值与期望值是否一致。单元测试理念认为：每个“单元” 是正确的，整体就是正确的。单元测试是在软件开发过程中要进行的最低级别的测试活动， 在单元测试活动中，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。

上述QTP等商业软件的机制是：通过鼠标移动、键盘点击操作被测应用，即而得到相应 的测试脚本，对该脚本可以进行编辑和调试。在记录脚本的过程中可在插入“检测点”的同 时建立期望值。在执行的时候回放该测试脚本，然后检查“检测点”实际结果与期望结果是 否相同。

然而，即使使用上述的解决方案，仍然需要测试人员进行大量工作，效果还是不尽如人 意，特别是像互联网产品这种在线应用上，测试人员必须要再测，这是因为：

1)对于单元测试而言：需要编写测试代码，测试代码的覆盖率不会达到100％。通常覆 盖率越高，写的越深入，重构时面临修改的可能性也越大，这里，重构指的是在不改变软件 现有功能的基础上，通过调整程序代码改善软件的质量、性能，使其程序的设计模式和架构 更趋合理，提高软件的扩展性和维护性。因为重构后的单元不一定是重构前的单元。单元测 试也需要跟着“被重构”。另外，单元测试受制于外部数据源和开发人员的能力，因此单元测 试对重构后代码是否存在错误的检查能力是很有限的。

2)对于QTP等商业自动化测试软件而言：QTP等商业自动化测试软件特点在于可以检 查页面功能。但是就是这种特征，使得当页面功能有些改动，就需要重新录制脚本。功能变 了也要重新录制脚本。而且对于外部数据源的依赖更强，因为它不像单元测试可以Mock(制 造假的)数据，举个简单例子：当回放测试脚本时，数据库中的数据的测试数据和当初已经 完全不同了，甚至字段都不同了。实际使用时很有可能就放弃了对一些结果进行检测。第二 个问题，现在页面效果，越来越绚。商业软件很多时候并不能正确捕捉并回放页面事件。导 致整个测试都不能运行完。

所以针对于回归测试这种场景，商业软件的作用还赶不上单元测试。这些产品的优点在 于使用面比较宽，比较通用，但效果比较差。

3)对于图片比对测试而言：图片比对测试与本申请原理有许多相似之处，但作法却完全 不同，简单的说：用相同的输入请求两个版本的程序，让计算机自动比较两个程序返回的结 果页面是否相同，基本的方法是通过将结果页面直接变成图片然后用算法比对这两个图片是 否相同。

图片比对测试通常效果不好，原因是：很多功能不可能从外观上体现出来，比如页面上 一个超链接是有问题的，不是从外观上能发现的，只有点进去才知道，所以这种问题就测试 不出来。另一个问题，即便是页面外观是不同的，也不能认为是错误的。比如：一些网站上 有很多广告都是随机出现的。这样都会被当成“错误”测出来，这一定是不对的。

由上可知，现有的回归测试方法仍然需要大量的人工测试，从而增加了测试负担，降低 了测试速度。

发明内容

本申请的主要目的在于提供一种Web应用程序的回归测试方法和装置，以至少解决现有 技术中测试负担较大的问题。

根据本申请的一个方面，提供了一种Web应用程序的回归测试方法，其包括：获取第一 Web应用程序和第二Web应用程序中各功能对应的网页地址，其中，所述第一Web应用程序 和第二Web应用程序为同一Web应用程序的不同版本；在相同的测试环境下使用所述获取的 网页地址同时请求所述第一Web应用程序和第二Web应用程序；对所述第一Web应用程序响 应于所述请求返回的第一结果对象和所述第二Web应用程序响应于所述请求返回的第二结果 对象进行比较，得到比较结果。

根据本申请的另一方面，提供了一种Web应用程序的回归测试装置，其包括：获取单元， 用于获取第一Web应用程序和第二Web应用程序中各功能对应的网页地址，其中，所述第一 Web应用程序和第二Web应用程序为同一Web应用程序的不同版本；请求单元，用于在相同 的测试环境下使用所述获取的网页地址同时请求所述第一Web应用程序和第二Web应用程 序；比较单元，用于对所述第一Web应用程序响应于所述请求返回的第一结果对象和所述第 二Web应用程序响应于所述请求返回的第二结果对象进行比较，得到比较结果。

通过本申请的技术方案，能够达到以下有益效果：

1)通过在相同的测试环境下使用网页地址同时请求两个版本的Web应用程序，可以比对 出前后两个版本之间的差异，而这种差异可以体现出修改后的代码是否对Web应用程序的各 个功能产生影响，也就是说，根据比较的结果可以判断出两个版本的Web应用程序中的哪些 功能没有改变，哪些功能发生了改变，从而在后续测试中可以只针对发生了改变的功能进行 测试，而不需要对没有发生改变的功能进行测试，这样减少了测试次数和测试负担，提高了 测试速度；

2)通过在相同的测试环境下使用网页地址同时请求两个版本的Web应用程序，使得测试 基本不依赖具体测试数据，这样可以降低测试数据的维护成本；

3)本申请通过将Web应用程序响应于请求返回的结果对象中的所有属性(包括所有子属 性)转换为基本的数据类型再序列化到磁盘上，解决不同应用程序对象之间无法比对的问题；

4)本申请通过限制遍历深度和检查类名等方式来控制属性遍历范围，从而解决了遍历比 较时容易失去控制，无法成功遍历的问题；

5)本申请在比较结果对象时对具有随机性特征的属性提供自定义的比较器，保证对被测 程序的高覆盖率；

6)本申请先将比较结果生成数据文件，然后再读取所述数据文件中的比较结果，按照不 同格式的报表格式使用所述比较结果来生成报表，这样，得到比较结果的测试过程和生成报 表的过程分离开，使得在需要生成不同的报表时，可以不需要重新进行测试过程，而直接根 据数据文件进行扩展，从而减少了测试次数，降低了测试时间，提高了测试的扩展性；

7)本申请在所述Web应用程序执行所请求的功能的过程中对Web应用程序进行拦截得 到结果对象，从而解决了现有技术中由于测试程序封闭运行而无法获取程序运行中的测试信 息的问题；此外，这种拦截方式可以结合上述的比较方式，以便高效率地完成自动化回归测 试。

当然，实施本申请的任一产品或方法并不一定需要同时达到以上所述的所有优点。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示 意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1是根据本申请实施例的Web应用程序的回归测试装置的一种优选的结构示意图；

图2是根据本申请实施例的Web应用程序的回归测试装置的另一种优选的结构示意图；

图3是根据本申请实施例的Web应用程序的回归测试方法的一种优选的流程图；

图4是根据本申请实施例的URL的一种优选的示意图；

图5是根据本申请实施例的URL的另一种优选的示意图；

图6是根据本申请实施例的Web应用程序的回归测试方法的另一种优选的流程图；

图7是根据本申请实施例的URL的又一种优选的示意图；

图8是根据本申请实施例的序列化结果对象的一种优选的示意图；

图9是根据本申请实施例的遍历比对的一种优选的示意图；

图10是根据本申请实施例的比对过程的一种优选的示意图；

图11是根据本申请实施例的输出结果的一种优选的示意图；

图12是根据本申请实施例的输出结果的另一种优选的示意图。

具体实施方式

下文中将参考附图并结合实施例来详细说明本申请。需要说明的是，在不冲突的情况下， 本申请中的实施例及实施例中的特征可以相互组合。

在描述本申请的各实施例的进一步细节之前，将参考图1来描述可用于实现本申请的原 理的一个合适的计算体系结构。在以下描述中，除非另外指明，否则将参考由一个或多个计 算机执行的动作和操作的符号表示来描述本申请的各实施例。由此，可以理解，有时被称为 计算机执行的这类动作和操作包括计算机的处理单元对以结构化形式表示数据的电信号的操 纵。这一操纵转换了数据或在计算机的存储器系统中的位置上维护它，这以本领域的技术人 员都理解的方式重配置或改变了计算机的操作。维护数据的数据结构是具有数据的格式所定 义的特定属性的存储器的物理位置。然而，尽管在上述上下文中描述本申请，但它并不意味 着限制性的，如本领域的技术人员所理解的，后文所描述的动作和操作的各方面也可用硬件 来实现。

转向附图，其中相同的参考标号指代相同的元素，本申请的原理被示为在一个合适的计 算环境中实现。以下描述基于所述的本申请的实施例，并且不应认为是关于此处未明确描述 的替换实施例而限制本申请。

图1示出了可用于这些设备的一个示例计算机体系结构的示意图。出于描述的目的，所 绘的体系结构仅为合适环境的一个示例，并非对本申请的使用范围或功能提出任何局限。也 不应将该计算系统解释为对图1所示的任一组件或其组合具有任何依赖或需求。

本申请的原理可以使用其它通用或专用计算或通信环境或配置来操作。适用于本申请的 众所周知的计算系统、环境和配置的示例包括但不限于，个人计算机、服务器，多处理器系 统、基于微处理的系统、小型机、大型计算机、以及包括任一上述系统或设备的分布式计算 环境。

在其最基本的配置中，图1中的Web应用程序的回归测试装置100可以位于服务器内。 服务器可以包括但不限于微处理器MCU或可编程逻辑器件FPGA等的处理装置、用于存储数 据的存储装置以及与客户端通信的传输装置。在本说明书和权利要求书中，“Web应用程序的 回归测试装置”也可以被定义为能够执行软件、固件或微码来实现功能的任何硬件组件或硬 件组件的组合。Web应用程序的回归测试装置100甚至可以是分布式的，以实现分布式功能。

如本申请所使用的，术语“子模块”、“模块”、“组件”或“单元”可以指在Web应用程 序的回归测试装置100上执行的软件对象或例程。此处所描述的不同组件、子模块、模块、 单元、引擎和服务可被实现为在Web应用程序的回归测试装置100上执行(例如，作为单独 的线程)的对象或进程。尽管此处所描述的系统和方法较佳地以软件来实现，但是硬件或软 件和硬件的组合的实现也是可能并被构想的。

实施例1

如图1所示，Web应用程序的回归测试装置100(或称为Context Tester)包括：获取单元 102，用于获取第一Web应用程序和第二Web应用程序中各功能对应的网页地址(URL，统 一资源定位符，就是在浏览器地址栏中输入的网址)，其中，第一Web应用程序和第二Web 应用程序为同一Web应用程序的不同版本；请求单元104，连接至获取单元102，用于在相同 的测试环境下使用获取的网页地址同时请求第一Web应用程序和第二Web应用程序；比较单 元106，连接至请求单元104，用于对第一Web应用程序响应于请求返回的第一结果对象和第 二Web应用程序响应于请求返回的第二结果对象进行比较，得到比较结果。

在本申请中，通过在相同的测试环境下使用网页地址同时请求两个版本的Web应用程序， 可以比对出前后两个版本之间的差异，而这种差异可以体现出修改后的代码是否对Web应用 程序的各个功能产生影响，也就是说，根据比较的结果可以判断出两个版本的Web应用程序 中的哪些功能没有改变，哪些功能发生了改变，从而在后续测试中可以只针对发生了改变的 功能进行测试，而不需要对没有发生改变的功能进行测试，这样减少了测试次数和测试负担， 提高了测试速度。

上述的结果对象指的是：Web应用程序在接受一个http请求并处理后，将执行相应功能 产生一系列执行结果，将执行结果整合在一个统一的对象中，该统一的对象在本申请中被称 作“结果对象”，其中，对象指的是具有唯一的标识符，对象包括属性(Properties)和方法 (Methods)，属性就是需要记忆的信息，方法就是对象能够提供的服务。

上述相同的测试环境包括：同一时间在同一台机器上使用同一个测试程序。这样，可以 避免机器环境的不同给两个Web应用程序的结果对象带来不必要的差异，从而给后面的对比 造成干扰。

在开始执行测试，获取单元102从URL库中取出一个URL数据，如图4所示。然后， 请求单元104模拟浏览器用这个URL对第一Web应用程序和第二Web应用程序进行请求。 目的就是要通过模拟浏览器请求，来让第一Web应用程序和第二Web应用程序执行被测功能。 优选的，可以通过在服务器的相同存储空间中先后存储两个版本的Web应用程序来实现使用 一个URL数据来请求两个Web应用程序的方案。当然，这只是一个示例，本申请不仅限于此， 也可以将两个版本的Web应用程序存储在服务器的两个不同存储空间中，这样两个版本的 Web应用程序对应于两个不同的URL，请求单元104在模拟浏览器请求时，从URL库中获取 上述两个不同的URL，然后使用这两个URL同时对两个Web应用程序进行请求。

上述模拟的技术可以由HttpUnit开源技术来实现，HttpUnit是专门用到web测试的开源 技术，其可以模拟浏览器的功能如：post和get用户请求，模拟浏览器登录系统，执行javascript 等。

两个Web应用程序处理请求后，各自会产生一个输出的结果对象，然后比较单元106收 集这两个结果对象，并且比对它们的区别，然后输出成报告。

当一个URL的结果对比结束之后，再从URL库再取出第二个URL，如图5所示。这时 通过第二个URL开始了第二个测试用例。这样用一个一个URL来测试，直到最后一个URL 都执行完。这里，测试用例为测试而编制的一组数据，包括：输入条件、预期结果。

Web应用程序的所有功能，就是通过一个一个URL的组成的。一个用户对一个网站页面 进行了一次点击，其实就是一次发向网站的URL的请求，网站接到请求后，执行程序，把结 果送回给用户的浏览器，用户就看到了想看的内容。这样一个一个点击“打开”了网站所有 功能，本申请模拟了这样的点击行为，并查检输出结果，较以前的那个程序是否有变化，就 得出了是否有错误产生。

举例而言，本申请的URL库中收集了一段时间用户真正访问所形成的请求数据，去掉重 复URL后，大约4000多个，基本涵盖了这个Web应用程序的所有功能，每一个URL就是一 个测试用例，人工测试时能测到4000个测试用例几乎是不可能的。此外，像QTP这种商业测 试因为要录制和维护测试脚本，测到这么多的测试用例也是不可能的。可见，通过图1所示 的装置所执行的回归测试较其他方案有非常高的“被测代码覆盖率”。

此外，在时间方面，4000多个URL(用例)用时一个多小时，而人工要达到同样的工作量 按5分钟一个计算，需要41个工作日，可见，按照本申请的回归测试，可以大大地节省测试 时间。进一步，这些真实的URL是来自线上和测试日志的，是几乎不需要单独维护的，这样 也降低了测试用例的维护成本。

下面通过表格来对比本申请Context Tester与单元试测和QTP等商业自动化测试软件针对 于回归测试的能力。

表1

以上可以看到：本申请(ContextTester)的表现远远超过单元测试和商业软件。

不同版本的Web应用程序的结果对象属于不同的内存空间，不能直接比对。对此，本申 请提供了一种较优的比较单元，其将不同版本的Web应用程序的结果对象序列化到本地硬盘 (或序列化到其他存储设备上)，再统一加载到同一个内存空间中。优选的，本申请中使用到 的序列化技术可以包括Java Serializable、xml、json等。此外，该较优的比较单元还采用了拦 截技术来获取结果对象。

具体而言，该较优的比较单元106包括：依次连接的拦截模块(或称为拦截器)1061、 序列化模块1062和加载模块1063。

在对第一Web应用程序响应于请求返回的第一结果对象和第二Web应用程序响应于请求 返回的第二结果对象进行比较的过程，拦截模块1061在第一Web应用程序执行所请求的功能 的过程中对第一Web应用程序进行拦截得到第一结果对象，在第二Web应用程序执行所请求 的功能的过程中对第二Web应用程序进行拦截得到第二结果对象；序列化模块1062将第一结 果对象的属性和第二结果对象的属性进行序列化，其中，序列化指的是将对象状态转换为可 保持或传输的格式的过程；加载模块1063将序列化后的第一结果对象的属性和第二结果对象 的属性加载到同一内存空间中进行比较。

上述序列化过程将不同版本的Web应用程序的结果对象中的所有属性、子属性都写到存 储设备上，以便能够在后续将结果对象加载到同一个内存空间中进行比较，从而解决了现有 技术中无法直接比对不同版本的Web应用程序的结果对象的问题。

本发明中各个实施例中的响应是指：针对于请求执行相应程序并返回结果，简单的说就 是返回结果。

此外，上述比较单元106中的拦截模块1061(拦截器)的作用是获取被测程序和以前版 本程序的结果对象。在本申请中，拦截器可以使用AOP(Aspect Oriented Programming，面向 切面(方向)编程)技术，找到应用程序最后的出口代码处，在两个应用程序的同一个代码 位置进行拦截，以便获取两个版本的Web应用程序的结果对象，其中，AOP技术是通过预编 译方式和运行期动态代理实现在不修改源代码的情况下给程序动态统一添加功能的一种技 术。通过上述的拦截方式，可以解决现有技术中由于测试程序封闭运行而无法获取程序运行 中的测试信息的问题。

在本申请中，有些时候两个版本的Web应用程序的结果对象差异属于正常情况，这是因 为两个版本的Web应用程序的功能是具有随机性特征的功能，通常情况，这种Web应用程序 的功能约占Web应用程序的功能的5％，比如网站上的同一个页面，每次进入的时候都显示的 是不同广告，这是程序正常功能，所以当比对到涉及诸如广告数据的属性时，若按照正常的 比对方式就会提示两个Web应用程序的结果对象的相关属性不同，从而造成误报。

为了解决这种问题，本申请还提供了一种较优的加载模块，这种加载模块可以根据不同 的结果对象的属性来选择不同的比较方式(或者也可以视为选择不同的比较器)。

具体而言，加载模块1063包括：相互连接的第一判断子模块和比较子模块。

在将序列化后的第一结果对象的属性和第二结果对象的属性加载到同一内存空间中进行 比较的过程中，第一判断子模块判断序列化后的第一结果对象的属性和第二结果对象的属性 是否为具有随机性特征的属性，若序列化后的第一结果对象的属性和第二结果对象的属性为 具有随机性特征的属性，则判断出第一结果对象的属性和第二结果对象的属性不具有差异； 比较子模块在序列化后的第一结果对象的属性和第二结果对象的属性不为具有随机性特征的 属性时，比较第一结果对象的属性和第二结果对象的属性是否存在差异。

也就是说，本申请中的，加载模块1063可以包括默认比较器和扩展比较器。其中，当判 断出是不具有随机性特征的属性，则选择默认比较器来比较第一结果对象的属性和第二结果 对象的属性是否存在差异；若判断出是具有随机性特征的属性，则选择扩展比较器，在选择 扩展比较器的情况下，一般判断出第一结果对象的属性和第二结果对象的属性不具有差异， 而只进行常规的基本信息判断。

优选的，上述默认比较器可以包括：Collection比较器，Map比较器，Bean比较器，URL 比较器。扩展比较器是主要针对于具有随机性特征的属性、使用者自己编写的比较器。

第一判断子模块可以视为比较器控制组件，作用一个总的控制器，在遍历到一个属性前 由它来控制由哪个比较器来遍历，这里，遍历是指沿着某条搜索路线，依次对树中每个结点 均做一次且仅做一次访问。可以设定的选择规则是：优先使用扩展比较器来比对，没有扩展 比较器的属性，按属性类型找到相应的默认比较器比较。通过比较器比较出的差异，然后输 出。

通过上述的比较方式，可以减少由于错误比较而导致的输出结果不正确的问题。

进一步，在本申请中，比较的结果对象的属性的结构一般为网状结构，其中，有些属性 属于无用的属性，如果对这些无用的属性进行比对的话，则增加了比对时间，甚至当比对的 属性为第三方类(不是本公司开发的类)的属性时，甚至可能出现环状关联造成死循环，即 使没有出现死循环，也会很耗时。

为了解决上述问题，本申请还提供了一种较优的比较单元，其在将结果对象进行序列化 之前对结果对象中无用的属性进行过滤，解决了现有技术中存在的比较时间较长，还可能出 现死循环的问题。

具体的，比较单元106包括：过滤模块1064，该过滤模块1064在将第一结果对象的属性 和第二结果对象的属性进行序列化之前，对第一结果对象的属性和第二结果对象的属性进行 过滤，过滤掉无用的属性。在过滤掉无用的属性之后，序列化模块1062将除无用的属性之外 的第一结果对象的属性和第二结果对象的属性进行序列化。这样，基本保证结果对象要序列 化到硬盘上的属性都是保存结果数据的、有用的属性。

为了选择出无用的属性，本申请还提供一种优选的过滤模块1064，其包括：判断子模块， 用于通过以下步骤判断无用的属性：若属性的深度超过预定阈值，则判断该属性为无用的属 性；或者若属性为预定的集合类型中的属性，则判断该属性为无用的属性；或者若属性的类 名不为预定集合中的类名，则判断该属性为无用的属性。

由于Web应用程序的所有功能的对象都保存在了“结果对象”中，为了保证不会遗漏， 本申请还提供一种优选的加载模块，其用于对结果对象的属性进行遍历比较。

具体而言，加载模块1063包括：第二判断子模块和输出子模块。

在将序列化后的第一结果对象的属性和第二结果对象的属性加载到同一内存空间中进行 比较的过程中，第二判断子模块，用于将所述第一结果对象和所述第二结果对象加载到测试 程序的内存中，遍历判断序列化后的第一结果对象的属性和第二结果对象的属性之间是否存 在差异；输出子模块，用于在序列化后的第一结果对象的属性和第二结果对象的属性之间存 在差异时，输出指示第一结果对象的属性和第二结果对象的属性之间存在差异的信息。

通过上述遍历过程，保证了结果对象的所有属性都得到比对，使得测试具有很高的覆盖 率，避免了人工进行重复测试。

Web应用程序的回归测试装置100还包括：第一生成单元108，用于在对第一Web应用 程序响应于请求返回的第一结果对象和第二Web应用程序响应于请求返回的第二结果对象进 行比较之后，将比较结果生成数据文件；第二生成单元110，用于读取数据文件中的比较结果， 按照不同格式的报表格式使用比较结果来生成报表。

本申请先将比较结果生成数据文件，然后再读取所述数据文件中的比较结果，按照不同 格式的报表格式使用所述比较结果来生成报表，这样，得到比较结果的测试过程和生成报表 的过程分离开，使得在需要生成不同的报表时，可以不需要重新进行测试过程，而直接根据 生成的数据文件进行扩展，从而减少了测试次数，降低了测试时间，提高了测试的扩展性。

实施例2

如图2所示，本申请提供一种Web应用程序的回归测试装置20，其设置于服务器10中。

Web应用程序的回归测试装置20包括以下部件：URL收集器201、结果对象收集器202、 报表插件203、测试单元204以及URL资源库207，上述各个部件的连接关系如图2所示。

URL收集器201用于对Web应用程序的线上日志101和测试日志102进行收集；URL资 源库207用于存储URL收集器201收集到的URL资源；结果对象收集器202用于同时收集 两个不同版本的Web应用程序的结果对象；测试单元204用于对结果对象进行遍历比对，并 输出差异数据；报表插件203用于将测试单元204产生的差异数据转换为最终报告。

下面将结合附图进一步描述上述各个部件的具体结构。

URL收集器201包括：GET数据收集组件2011、POST数据收集组件2012。在本申请中， “GET”还是“POST”将与被测应用程序使用的协议有关。

结果对象收集器202包括：应用拦截器2020，Http请求模拟组件2021、过滤器2022、属 性转换器2023和序列化装置2024。

在收集结果对象的过程中，Http请求模拟组件2021负责同时请求两个不同版本的Web应 用程序，让它们同时运行相同功能。例如，在开始执行测试，Http请求模拟组件2021从URL 库中取出一个URL数据，如图4所示。然后，请求单元104模拟浏览器用这个URL对两个 不同版本的Web应用程序进行请求，目的就是要通过模拟浏览器请求，来让两个不同版本的 Web应用程序执行被测功能，产生结果对象。这里需要说明的是，上述同时请求是在相同的 测试环境下进行的，优选的，上述相同的测试环境包括：同一时间在同一台机器上使用同一 个测试程序。这样，可以避免机器环境的不同给两个Web应用程序的结果对象带来不必要的 差异，从而给后面的对比造成干扰。

然后，应用拦截器2020负责把产生的结果对象，拦截下来，也就是，把两个不同版本的 Web应用程序响应于上述请求执行相应被测功能得到的结果对象的数据收集到测试程序中， 便于后续进行结果对象的比对。在本申请中，应用拦截器2020可以使用AOP(Aspect Oriented Programming，面向切面(方向)编程)技术，找到应用程序最后的出口代码处，在两个应用 程序的同一个代码位置进行拦截，以便获取两个版本的Web应用程序的结果对象，其中，AOP 技术是通过预编译方式和运行期动态代理实现在不修改源代码的情况下给程序动态统一添加 功能的一种技术。通过上述的拦截方式，可以解决现有技术中由于测试程序封闭运行而无法 获取程序运行中的测试信息的问题。

然后，过滤器2022对应用拦截器2020拦截下来的结果对象中的属性进行过滤，也就是 去掉结果对象中无用的属性。这样，基本保证结果对象要序列化到硬盘上的属性都是保存结 果数据的、有用的属性。为了选择出无用的属性，过滤器2022可以包括：判断子模块，用于 通过以下步骤判断无用的属性：若属性的深度超过预定阈值，则判断该属性为无用的属性； 或者若属性不为预定的集合类型中的属性，则判断该属性为无用的属性；或者若属性的类名 为预定集合中的类名，则判断该属性为无用的属性。

在过滤器2022过滤结果对象中无用的属性之后，属性转换器2023将过滤器2022过滤后 的结果对象转换成可以写到硬盘上的对象，为序列化做准备。

然后，序列化装置2024将属性转换器2023形成的可以序列化的结果对象序列化到硬盘 上。因为有两个不同版本的Web应用程序，所以序列化装置2024会产生两个序列化的产物， 即，图2所示的“以前程序输出的结果对象205”和“待测试程序输出的结果对象206”。

上述序列化过程将不同版本的Web应用程序的结果对象中的所有属性、子属性都写到存 储设备上，以便能够在后续将结果对象加载到同一个内存空间中进行比较，从而解决了现有 技术中无法直接比对不同版本的Web应用程序的结果对象的问题。

进一步，为了进行结果对象的比较，测试单元204包括：比较器控制组件2041、默认比 较器2042、自定义比较器(或称扩展比较器)2043以及过滤器2044。它们联合起来对结果 对象进行遍历比对，并输出差异数据。

默认比较器2042和自定义比较器2043，都是负责作具体的属性对比工作的。因为对象中 的属性比较规则不同，所以比较器不是一个，选择哪一个比较器由比较器控制组件2041负责 管理。

例如，当比较器控制组件2041判断出是不具有随机性特征的属性时，选择默认比较器2042 来比较结果对象的属性之间是否存在差异；若比较器控制组件2041判断出是具有随机性特征 的属性，则选择自定义比较器2043，在选择自定义比较器2043的情况下，一般判断出两个结 果对象的属性之间不具有差异，而只进行常规的基本信息判断。

过滤器2044负责对默认比较器2042和自定义比较器2043的输出结果进行过滤。

报表插件203包括自定义排序组件2032、过滤器2031以及自定义汇总组件2033。它们 联合起来将测试单元204产生的差异数据转换为最后的报告。其中，自定义排序组件2032负 责报告数据的排序工作；过滤器2031负责过滤掉不是真正错误或重复的数据；自定义汇总组 件2033负责将数据进行按错误按类型分类、汇总等。增加报表的可阅读性。

为了输出报表，报表插件203还采取了一种将差异数据文件和报表文件进行分开生成的 方式，具体而言，报表插件203先将测试单元204产生的比较结果(例如，差异数据)生成 数据文件，然后再读取所述数据文件中的比较结果，按照不同格式的报表格式使用所述比较 结果来生成报表，这样，得到比较结果的测试过程和生成报表的过程分离开，使得在需要生 成不同的报表时，可以不需要重新进行测试过程，而直接根据生成的数据文件进行扩展，从 而减少了测试次数，降低了测试时间，提高了测试的扩展性。

实施例3

在图1-图2所示的计算系统的基础上，本申请还提供了一种Web应用程序的回归测试方 法。如图3所示，Web应用程序的回归测试方法包括以下步骤：

S302，获取第一Web应用程序和第二Web应用程序中各功能对应的网页地址，其中，第 一Web应用程序和第二Web应用程序为同一Web应用程序的不同版本；可以由但不限于图1 所示的获取单元102来执行S302；

S304，在相同的测试环境下使用获取的网页地址同时请求第一Web应用程序和第二Web 应用程序，例如，使用网页地址A来请求第一Web应用程序，以及使用网页地址B来请求第 二Web应用程序，或者，使用网页地址C同时请求第一Web应用程序和第二Web应用程序； 可以由但不限于图1所示的请求单元104来执行S304；

S306，对第一Web应用程序响应于请求返回的第一结果对象和第二Web应用程序响应于 请求返回的第二结果对象进行比较，得到比较结果；可以由但不限于图1所示的比较单元106 来执行S306。

在本申请中，通过在相同的测试环境下使用网页地址同时请求两个版本的Web应用程序， 可以比对出前后两个版本之间的差异，而这种差异可以体现出修改后的代码是否对Web应用 程序的各个功能产生影响，也就是说，根据比较的结果可以判断出两个版本的Web应用程序 中的哪些功能没有改变，哪些功能发生了改变，从而在后续测试中可以只针对发生了改变的 功能进行测试，而不需要对没有发生改变的功能进行测试，这样减少了测试次数和测试负担， 提高了测试速度。

上述相同的测试环境包括：同一时间在同一台机器上使用同一个测试程序。这样，可以 避免机器环境的不同给两个Web应用程序的结果对象带来不必要的差异，从而给后面的对比 造成干扰。

在开始执行测试时，获取单元102从URL库中取出一个URL数据，如图4所示。然后， 请求单元104模拟浏览器用这个URL对第一Web应用程序和第二Web应用程序进行请求。 目的就是要通过模拟浏览器请求，来让第一Web应用程序和第二Web应用程序执行被测功能。

两个Web应用程序处理请求后，各自会产生一个输出的结果对象，然后比较单元106收 集这两个结果对象，并且比对它们的区别，然后输出成报告。

当一个URL的结果对比结束之后，再从URL库再取出第二个URL，如图5所示。这时 通过第二个URL开始了第二个测试用例。这样用一个一个URL来测试，直到最后一个URL 都执行完。

Web应用程序的所有功能，就是通过一个一个URL的组成的。一个用户对一个网站页面 进行了一次点击，其实就是一次发向网站的URL的请求，网站接到请求后，执行程序，把结 果送回给用户的浏览器，用户就看到了想看的内容。这样一个一个点击“打开”了网站所有 功能，本申请模拟了这样的点击行为，并查检输出结果，较以前的那个程序是否有变化，就 得出了是否有错误产生。

不同版本的Web应用程序的结果对象属于不同的内存空间，不能直接比对。对此，本申 请提供了一种较优的比较步骤，其将不同版本的Web应用程序的结果对象序列化到本地硬盘 (或序列化到其他存储设备上)，再统一加载到同一个内存空间中。优选的，本申请中使用到 的序列化技术可以包括Java Serializable、xml、json等。此外，上述较优的比较步骤还采用了 拦截技术来获取结果对象。

具体而言，对第一Web应用程序响应于请求返回的第一结果对象和第二Web应用程序响 应于请求返回的第二结果对象进行比较的步骤包括：在第一Web应用程序执行所请求的功能 的过程中对第一Web应用程序进行拦截得到第一结果对象，在第二Web应用程序执行所请求 的功能的过程中对第二Web应用程序进行拦截得到第二结果对象；将第一结果对象的属性和 第二结果对象的属性进行序列化；将序列化后的第一结果对象的属性和第二结果对象的属性 加载到同一内存空间中进行比较。

上述序列化过程将不同版本的Web应用程序的结果对象中的所有属性、子属性都写到存 储设备上，以便能够在后续将结果对象加载到同一个内存空间中进行比较，从而解决了现有 技术中无法直接比对不同版本的Web应用程序的结果对象的问题。

此外，上述拦截步骤的作用是获取被测程序和以前版本程序的结果对象。在本申请中， 拦截器可以使用AOP(Aspect Oriented Programming，面向切面(方向)编程)技术，找到应 用程序最后的出口代码处，在两个应用程序的同一个代码位置进行拦截，以便获取两个版本 的Web应用程序的结果对象，其中，AOP技术是通过预编译方式和运行期动态代理实现在不 修改源代码的情况下给程序动态统一添加功能的一种技术。通过上述的拦截方式，可以解决 现有技术中由于测试程序封闭运行而无法获取程序运行中的测试信息的问题。

在本申请中，有些时候两个版本的Web应用程序的结果对象差异属于正常情况，这是因 为两个版本的Web应用程序的功能是具有随机性特征的功能，通常情况，这种Web应用程序 的功能约占Web应用程序的功能的5％，比如网站上的同一个页面，每次进入的时候都显示的 是不同广告，这是程序正常功能，所以当比对到涉及诸如广告数据的属性时，若按照正常的 比对方式就会提示两个Web应用程序的结果对象的相关属性不同，从而造成误报。

为了解决这种问题，本申请还提供了一种较优的加载步骤，这种加载步骤可以根据不同 的结果对象的属性来选择不同的比较方式(或者也可以视为选择不同的比较器)。

具体而言，将序列化后的第一结果对象的属性和第二结果对象的属性加载到同一内存空 间中进行比较的过程包括：判断序列化后的第一结果对象的属性和第二结果对象的属性是否 为具有随机性特征的属性；若不具有，则比较第一结果对象的属性和第二结果对象的属性是 否存在差异；若具有，则判断出第一结果对象的属性和第二结果对象的属性不具有差异。通 过上述的加载方式，可以减少由于错误比较而导致的输出结果不正确的问题。

进一步，在本申请中，比较的结果对象的属性的结构一般为网状结构，其中，有些属性 属于无用的属性，如果对这些无用的属性进行比对的话，则增加了比对时间，甚至当比对的 属性为第三方类(不是本公司开发的类)的属性时，甚至可能出现环状关联造成死循环，即 使没有出现死循环，也会很耗时。

为了解决上述问题，本申请还提供了一种较优的过滤步骤，其在将结果对象进行序列化 之前对结果对象中无用的属性进行过滤，解决了现有技术中存在的比较时间较长，还可能出 现死循环的问题。

具体而言，在将第一结果对象的属性和第二结果对象的属性进行序列化之前，Web应用 程序的回归测试方法还包括：对第一结果对象的属性和第二结果对象的属性进行过滤，过滤 掉无用的属性；将除无用的属性之外的第一结果对象的属性和第二结果对象的属性进行序列 化。

优选的，可以通过以下步骤判断无用的属性：若属性的深度超过预定阈值，则判断该属 性为无用的属性；或者若属性为预定的集合类型中的属性，则判断该属性为无用的属性；或 者若属性的类名不为预定集合中的类名，则判断该属性为无用的属性。

将序列化后的第一结果对象的属性和第二结果对象的属性加载到同一内存空间中进行比 较的过程包括：将所述第一结果对象和所述第二结果对象加载到测试程序的内存中；遍历判 断序列化后的第一结果对象的属性和第二结果对象的属性之间是否存在差异；若存在差异， 则输出指示第一结果对象的属性和第二结果对象的属性之间存在差异的信息。通过上述遍历 过程，保证了结果对象的所有属性都得到比对，使得测试具有很高的覆盖率，避免了人工进 行重复测试。

在对第一Web应用程序响应于请求返回的第一结果对象和第二Web应用程序响应于请求 返回的第二结果对象进行比较之后，还包括：将比较结果生成数据文件；读取数据文件中的 比较结果，按照不同格式的报表格式使用比较结果来生成报表。本申请先将比较结果生成数 据文件，然后再读取所述数据文件中的比较结果，按照不同格式的报表格式使用所述比较结 果来生成报表，这样，得到比较结果的测试过程和生成报表的过程分离开，使得在需要生成 不同的报表时，可以不需要重新进行测试过程，而直接根据生成的数据文件进行扩展，从而 减少了测试次数，降低了测试时间，提高了测试的扩展性。

实施例4

本实施例将结合附图来详细描述具体的回归测试方法。

示例1

比如一个人来到机场通过安检准备乘飞机，但是由于特殊原因，他必须离开机场一段时 间去作一件事情，当他返回机场时，必须再作安检。为了节约再作安检的人工成本，我们可 以设计这样的一个流程：当第一次进行安检时，旅客将自己所带所有物品放入到一个大箱子 中，安检人员将这个大箱子中的所有物品全部拿出来检查一下看是否有违禁物品。然后将这 些物品再放入一个特殊的设备中，设备将这些物品的信息全部扫描并记录下来(假设有这样 的设备)。然后旅客再度返回机场再作安检的时候，安检系统再重复一次刚才的扫描然后与前 一次的进行比较，只要是没有新的物品出现就认为可以通过安检。

示例总结：

1)因为上一次是人工检查通过了的。这一次只要是相同于上一次的，我们就可以认为， 这一次也通过了。

2)像这样“特殊的设备“在现实生活中是不存在的，但是在对于计算机内部的数据来说， 作这种检查是可以作到的。

3)旅客将自己所带所有物品放入到一个大箱子中：意味着所有物品都会检查到，表明这 种检查具有高覆盖率。

4)在上例中第二次物品只要有区别，如增加一样物品，就可以被发现。这表明这种检查 具有高敏感度。虽然增加的物品不一定是有问题的，但是，高敏感度毕竟可以带来不遗漏的 特性，才能形成检查的自动化

5)试想一下如果某个方案不能保证将所有的物品都能检查到，或不能保证有问题一定能 发现，那就需要人工再重复检查一次，因为我们不知道哪些可能被漏掉，所以人的工作量并 没有随着使用这种工具而减少，工具只能是人工的辅助。相反，例子中的方案具有高覆盖率 和高敏感度，所以在第二次检查物品时就可以采用自动检查，人工作为工具的辅助。这样的 工具才可以大幅度替代人工。

6)只是在某种场合才能发挥作用。如上例只能在第二次检查时才会能发挥作用，但对于 计算机系统来说，这种二次检查场合占比非常高，在当今流行的敏捷开发过程中尤其高，所 以本申请中的回归测试方案符合发展的趋势。

本实施例中的回归测试方法的基本作法是：用同样的程序环境同样的程序配置，在同一 台机器上运行“以前的”和“待测”的两个不同版本的web应用程序，然后在同台机器上用 一个测试程序，在同一时间访问这两个不同的应用程序。在95％的功能下他们返回的结果是 相同的。我们就对两个结果的比对检查。另外，会有一小部分有“随机性特征”的功能是不 同的，本实施例开发了扩展插件对“随机性特征”的功能进行必要的检查。整个过程与示例 1中两次扫描比对旅客的物品较相似。

通过上述的回归测试方法，可以接近99％的对程序错误的高敏感度和高覆盖率。本申请 用于Web应用程序的回归测试方法与单元测试和QTP等商业软件相比，有以下四个明显的优 势：1.几乎不用维护；2.对错误的高敏感度；3.测试的高覆盖率；4.高人工替代率。

本申请的应用就像一个大的方法(function)一样，有要统一的输入和输出模式，互联网应 用通常都是通过http协议接受用户请求，这是天然的“同一”入口。现在大多web框架都通 过O bject-Graph Navigation Language(OGNL)取值渲染页面，这又是天然的“同一”出口。剩 下的，像数据库中添加数据这样的功能，要让他们并入一个统一的出口并不困难。就像使用 单元测试一样，我们也要适当改造我们的程序，来增加“可测试性”，让测试程序更好的为我 们工作。提供的统一的Web“出口”设计，其实早已存在了，比如JSP技术中的pageContext 内置对象等，只不过有些应用的还没有充分利用到它们而已。

示例2：

假设在一次大规模的架构级别的重构，主要作了两个方面改修：一个是将应用程序的继 承关系作了调整，另一个：修改了很多方法的参数(因为原来这些参数不合理)。整个应用程序 在结构和细节上都有不小的变化。这样必须进行整个应用的回归测试，工作量大概为12人日 (一个人12天的工作量)。

基于上述假设，如图6所示，本实施例中的回归测试方法包括以下步骤：

步骤S602：收集URL

获取线上访问日志数据，使用图1中的“Get数据收集组件”，去掉没有用的数据，只留 下我们需要的URL信息，这些信息每一行就是我们在浏览器地址栏上写的一个URL串，线 上日志数据如图7所示。

如果是post方法的http请求，需要在人工测试时用本申请的“post数据收集组件”收集 下取访问数据即可。

步骤S604：搭建测试环境

在本申请中，需要一台机器，所有的相关程序都部署这台机器上，包括：Context tester(本 申请的回归测试程序)，待测试的程序，以前版本程序。

部署在同一台机器上的目的是：避免机器环境的不同给的两个程序结果带来不必要的差 异。而给后面的对比造成干扰。

部署应用拦截器组件：应用拦截器的作用是获取被测程序和以前版本程序的结果对象。 拦截器使用AOP技术，找到应用程序最后的出口代码处，在两个应用程序的同一个代码位置 进行拦截。获取他们的结果结果对象。

步骤S606：用程序模拟浏览器对两个Web应用程序同时进行请求

开始执行测试，本申请从URL库中，取出一个URL数据。如图4所示。这个URL从 URL库中取出，图2中“Http请求模拟组件”模拟浏览器用这个URL对web应用的请求。 目的就是要通过模拟浏览器请求，来让程序执行被测功能。

两个Web应用程序处理请求后，各自会产生一个输出的结果对象，本申请优选实施例的 核心任务就是要收集这两个结果对象，并且比对它们的区别，然后输出成报告。详细对比和 输出过程在下一步骤进行介绍。

当一个URL的结果对比结束之后，再从URL库再取出第二个URL，如图5所示。这时 通过第二个URL我们开始了第二个测试用例。这样用一个一个URL来测试，直到最后一个 URL都执行完。

我们的web应用程序的所有功能，就是通过一个一个URL的组成的。一个用户对一个网 站页面进行了一次点击，其实就是一次发向网站的URL的请求，网站接到请求后，执行程序， 把结果送回给用户的浏览器，用户就看到了想看的内容。这样一个一个点击“打开”了网站 所有功能，我们模拟了这样的点击行为，并查检输出结果，较以前的那个程序是否有变化， 就得出了是否有错误产生。

本实施例中的回归测试方法的重点之一就是：对两个Web应用程序同时请求。

Web应用程序通常要连接数据库，查数据。“同一时间请求“有很大的优越性，因为它使 测试基本不依赖，也无需维护具体的测试数据，从而降低测试成本。这是其它测试工具无法 比拟的。举个例子：一个人同一时间用两个浏览器点开同一个网站的同一个页面，所看到的 内容除广告外应该是一样的，原因是没有“时间差”，网站数据来不及变化。我们就是利用这 种“数据来不及变化”特征来达到不依赖，不维护测数据的目的。象QTP等商业软件的是先 录制测试脚本然后去测试，一定有“时间差”，通常要准备一份测试数据，来保证录制脚本时 和执行测试时用的是相同的数据，不这么作就不知道测试出的问题是不是由数据不同导致的。

步骤S608：获得两个Web应用程序的结果对象

从上步通过模拟浏览器的请求，两个应用会执行相同的功能，然后将结果保存在一个对 象中，工具会使用AOP技术进行拦截，捕获结果对象，然后下一步对它们进行比对。

这时，可能存在以下问题：不同Web应用程序的对象属于不同的内存空间，从而导致不 能直接比对；另一方面，对象内部结构可能如网状结构，这样Web应用程序的对象可能会通 过网状结构关联到第三方类的属性。甚至出现环状关联造成死循环。即使没有出现死循环， 也会很耗时。就拿示例2的测试中我们就遍历了几千个这样的对象，如果每次遍历时间长一 点，累积起来也是个不短的时间。

对于第1个问题，本申请的实施例采用如下解决方案：将两个转换过的Web应用程序的 结果对象，序列化到本地硬盘。具体而言，先将对象的属性、子属性全部转换为可序列化的 Map，Collection，String int这些简单类型进行保存。这样作的目的就是保证对象的属性、子属性 都是可序列化的。然后，可以由图2中的“结果对象收集器202”再统一加载进来，从而实 现了由不同的内存空间到同一个内存空间，这样就可以实现结果对象的比对。

对于第2个问题，本申请的实施例采用“可扩展的过滤器“方案：可扩展的过滤器简单 的说，就是可以根据不同的被测Web应用程序，编写一个组件将不需要的属性过滤掉。具体 原理是，遍历一个属性前先调用过滤器组件，让该过滤器组件识别这个属性是否需要，不需 要的话，这个属性和它所关联的属性都不再遍历了。这样基本保证我们的对象要序列化到硬 盘上的属性都是保存结果数据的、有用的属性。

具体的，可以通过以下步骤来判断哪些属性属于无用的属性：

1)属性深度过深视为无用。

属性关联的深度越深，越不可能是被测试应用保存数据的地方。所以在示例2中测试中 我们的过滤器限制了属性深度为10。在往后的关联不会再去遍历。

2)不是使用者开发的，又不属于集合类型的属性，深视为无用(当然Java的自己类库中 的类是除外的)。

因为保存数据的类，通常都是自定义的java类，由开发人员编写，通过类的包名可以获 知，有些情况是用到了第三方类库的类，应是集合类型的数据结构类，如一些特殊的Map和 List。

3)属性的类名属于预定集合中的类名，则该属性为无用的属性

因为属性的类名定义是有命名规范的，通过类名就知道这些属性不可能是用来保存数据 的。如：XXService，XXUtils，XXHelper，XXBroker等。这些一定都不是用来保存数据的类。

因为过滤器组件是根据不同Web应用程序编写的，所以使用本申请的Web应用程序可以 自己来设计自己的过滤器。

上述过程如图8所示。

步骤S610：遍历比对两个Web应用程序的结果对象

步骤S608将两个Web应用程序的结果对象已经序列化到测试服务器(如图2的服务器 10)的硬盘上。在步骤S610中，把它们从硬盘上加载到测试装置(如图2的测试装置20)的 内存当中进行比对。

如图10所示，这个遍历比对过程简单的说就是比对两个对象的属性及子属性是否相同。 相当于示例1中的旅客两次安检，机器自动扫描对比所带的箱子中的物品的行为差不多。程 序也一个一个找出里边的东西进行对比。

然而，有些时候两个程序的结果差异是正常的，因为有些是随机特征的功能，约占我们 web应用程序功能5％，比如我们网站上的同一个页面，每次进入的时候都显示的是不同广告， 这是程序正常功能，所以当比对到涉及广告数据的属性时就会提示两个web应用程序相关属 性不同。造成误报。

为了解决这种问题，本申请提供了如图9所示“可扩展比较器”，使得在使用本申请的技 术方案时，若遇到这种带有“随机性特征”的属性时，根据可能的“随机性特征“的规则设 计专门针对于这个属性的比较器，进行必要的检查。

如图9所示，比较器控制组件，作用一个总的控制器，在遍历到一个属性前由它来控制 由哪个比较器来遍历。规则是：优先使用扩展比较器来比对，没有扩展比较器的属性，按属 性类型找到相应的默认比较器比较。通过比较器比较出的差异，然后输出。

上述测试过程可以带来以下技术效果：

1)高覆盖率

由于将所有功能结果都保存在了“结果对象”中，保证不会遗漏。这些结果都对应了功 能，检查了所有的结果，就是检查了所有的功能。

2)高敏感度

如果待测程序有误错存在，那么“结果对象”中一定会保存有这个功能的结果对象，这 个结果对象一定会区别与以前的程序的结果对象，那么就一定会被检查出来，从而使得本申 请具有高敏感度。

虽然以前的程序结果可能也会有错误，但是以前程序的是一个已经发布了的程序。是企 业现有能力，所能达到的最高质量水平。所以与之作比较测试，带给我们的就是最高的敏感 度。

3)高人工替代率

在以往的工具中因为测试错误发现率达不到要求，有很多问题都测不出来，所以要进行 人工测试，因为并不知道工具测试会究竟会遗漏哪些地方，所以人工的测试范围和工具测试 的范围基本是一样的，人的工作没有随之减少，只不过是人与工具共同工作，起到了更容易 发现错误的作用。

但是本申请有高覆盖率和高敏感度特点，使得错误发现率高于人工测试，再进行人工测 试已没有意义，人的工作量只在于阅读测试报告，去掉误报的错误，发现真正的错误，自然 工作量就比人亲自去测试少了很多。

步骤S612：输出对比结果

将对比结果输出到一个文件或数据库中，在执行示例2测试时，把结果输出到了一个文 件。

此时，遇到了另外一个问题：输出内容很多。这是由于我们重构的幅度很大，加之本申 请的高敏感性，带来的。例如：有些属性是在原来的程序中用不到的垃圾属性，在重构中将 其请除，形成的差异。由于一个错误产生的查询结果不同，产生很多间接的差异结果。

为了解决这个问题，我们通过实现“可扩展的输出过滤器”来实现对输出结果的过滤， 以减少不必要的输出。例如：在示例2中的测试中过滤器中作了如下操作：忽略用不到的垃 圾属性的输出；查询结果完全不同的，只输出查询结果记录的id，不再输出具体细节。查询 结果基本相同的，再输出细节区别。

步骤S614：生成测试报告

这一步要作的事情是将上步生成的结果数据文件，但是这些数据不是我们所要看的数据。 我们通过可扩展的“报表插件”的设计来让使用者根据不同的应用来现实自己的报表规则， 可以实现过滤，排序，分类汇总，以及其它处理。来让使用者自己定义什么样的数据是他们 想要看到的。从而解决这种由于测试敏感度高而带来的的生成数据量大的问题。

这样作的好处举个例子来说：我们在示例2中的测试过程中，用时1小时40分钟，生成 报告插件运行时间不到1秒。如果要对报告的数据结构不满意，可以调整测试报告插件的设 置，重新生成报告，这个调整的只需一秒就生成了新的报告。但如果测试过程与生成报告过 程不分离，要重来一次还得1小时40分钟。

下面是示例2的测试过程后生成的测试报告：我们生成的这个报告是经过按属性位置汇 总的XML格式的报告，用IE打开如图11所示。

如图11所示，<Path>描述的是属性在结果对象中的位置。展开部分代表：这种区别都在 哪个URL中出现过。except value：是指以前程序的运行结果的值是什么。current value：是指待 测程序运行结果的值是什么。

如上图11显示的，两个Web应用程序的context.ctr product ids这个属性值是不同的。

这个属性保存了“搜索功能”的查询结果id，这个属性值不同，说明两个应用程序在同样的 搜索条件下，搜索结果是不同的，这样我们就发现了一个重要的错误。

如上图12显示两个web应用程序的context.listView.leftSortBy这个属性值不同。差别非 常小，仅是待测程序多出了一个“-”。这个属性是保存页面上的“排序按钮”的URL的。这 显然是待测应用程序的”生成URL”功能出现了问题。

本申请的回归测试方法和装置优选适用范围是：Web应用程序的、非页面功能的回归测 试。

显然，本领域的技术人员应该明白，上述的本申请的各模块或各步骤可以用通用的计算 装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上， 可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置 中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步 骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个 集成电路模块来实现。这样，本申请不限制于任何特定的硬件和软件结合。

以上所述仅为本申请的优选实施例而已，并不用于限制本申请，对于本领域的技术人员 来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等 同替换、改进等，均应包含在本申请的保护范围之内。