CN110908906A - 一种回归测试方法及系统 - Google Patents

Abstract

本发明公开了一种回归测试方法及系统，将预设时间段内实际生产系统生成的所有的生产日志数据按照交易指令进行分组，将每组生产日志数据构成一个独立的测试用例，实现测试用例的自动收集，由于生产日志数据覆盖了实际生产系统已出现的全部业务场景和前置条件组合，因此可实现测试用例的全面覆盖；通过在模拟测试系统中为每个测试用例模拟与实际生产系统环境完全相同的生产系统仿真环境，并在该环境中执行相对应的测试用例对应的交易指令得到模拟输出结果，实现了每个测试用例均可根据一个测试指令在一个独立的生产系统仿真环境中执行操作，保证了各个测试指令之间的完全相互隔离，使得测试操作对环境的影响不会传递和累积，提高测试结果的可信度。

Description

一种回归测试方法及系统

技术领域

本发明涉及计算机技术领域，更具体的说，涉及一种回归测试方法及系统。

背景技术

当老旧系统功能迁移、系统重构，或是大型复杂业务系统的版本升级时，为确保新系统或新版本上线后运行稳定，原有业务功能不受影响，通常需要对新系统或新版本进行回归测试。回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。

然而，现有的回归测试方法主要存在两个问题：(1)人工构造测试用例，很难做到测试用例的全面覆盖，具体的：对于老旧系统和复杂业务系统，业务细节繁杂纷乱，文档普遍存在缺失、过时或者不够标准详尽的问题，因此人工梳理系统功能点和业务特性并生成测试用例，很难做到全面覆盖，通常只能由人工梳理出基本用例，再根据生产运行中遇到的问题慢慢补充完善。此外同一功能点在不同前置条件下，其行为表现可能完全不同，实际上测试用例中很大一部分工作都是在模拟各种前置条件的组合，然而从海量条件组合中，识别出实际业务过程可能出现的前置条件组合更加困难，因此测试用例通常只覆盖很少的前置条件。(2)测试环境难以保证，在实际应用中，每条测试指令都可能对测试环境和业务数据产生轻微影响，随着回归测试的不断进行，测试环境和业务数据会慢慢飘移，当测试和生产环境之间的差异积累到一定程度，后续测试操作就会受到测试环境的污染，导致测试结果分辨率下降，甚至完全淹没在环境差异引起的噪声中。

发明内容

有鉴于此，本发明公开一种回归测试方法及系统，以解决现有方案中人工构造测试用例，很难做到测试用例的全面覆盖，以及测试环境难以保证的问题。

一种回归测试方法，包括：

将预设时间段内实际生产系统生成的所有的生产日志数据按照交易指令进行分组，并将每组生产日志数据构成一个独立的测试用例，其中，所述交易指令具有唯一的交易流水号，每个所述测试用例中包括：执行相对应的交易指令所处的实际生产系统环境信息和执行相对应的交易指令得到的实际输出结果，所述实际生产系统环境信息包括：用户输入数据、被测系统接收的所述被测系统以外的系统发送的信息内容、交易指令执行过程中从数据库读取的内容，所述实际输出结果包括：系统回显数据、所述被测系统向所述被测系统以外的系统发送的信息内容和测试用例更新数据库记录的数据内容；

在模拟测试系统中，根据所述生产日志数据包含的所述实际生产系统环境，为每个所述测试用例模拟与所述实际生产系统环境完全相同的生产系统仿真环境，并在模拟得到的所述生产系统仿真环境中，执行相对应的测试用例对应的交易指令，得到模拟输出结果；

将同一交易指令对应的所述实际输出结果和所述模拟输出结果中的相同内容进行对比，实现对被测系统的回归测试。

一种回归测试系统，包括：

分组单元，用于将预设时间段内实际生产系统生成的所有的生产日志数据按照交易指令进行分组，并将每组生产日志数据构成一个独立的测试用例，其中，所述交易指令具有唯一的交易流水号，每个所述测试用例中包括：执行相对应的交易指令所处的实际生产系统环境信息和执行相对应的交易指令得到的实际输出结果，所述实际生产系统环境信息包括：用户输入数据、被测系统接收的所述被测系统以外的系统发送的信息内容、交易指令执行过程中从数据库读取的内容，所述实际输出结果包括：系统回显数据、所述被测系统向所述被测系统以外的系统发送的信息内容和测试用例更新数据库记录的数据内容；

模拟单元，用于在模拟测试系统中，根据所述生产日志数据包含的所述实际生产系统环境，为每个所述测试用例模拟与所述实际生产系统环境完全相同的生产系统仿真环境，并在模拟得到的所述生产系统仿真环境中，执行相对应的测试用例对应的交易指令，得到模拟输出结果；

对比单元，用于将同一交易指令对应的所述实际输出结果和所述模拟输出结果中的相同内容进行对比，实现对被测系统的回归测试。

从上述的技术方案可知，本发明公开了一种回归测试方法及系统，通过将预设时间段内实际生产系统生成的所有的生产日志数据按照交易指令进行分组，并将每组生产日志数据构成一个独立的测试用例，实现测试用例的自动收集，由于生产日志数据中覆盖了实际生产系统已出现过的全部业务场景和前置条件组合，因此，相对于人工构造测试用例而言，可以实现测试用例的全面覆盖；通过在模拟测试系统中，根据生产日志数据包含的测试用例执行相对应的交易指令所处的实际生产系统环境，为每个测试用例模拟与实际生产系统环境完全相同的生产系统仿真环境，并在该生产系统仿真环境中，执行相对应的测试用例对应的交易指令，得到模拟输出结果，实现了每个测试用例均可以根据一个测试指令在一个独立的生产系统仿真环境中执行操作，从而实现了各个测试指令之间的完全相互隔离，使得测试操作对环境的影响不会传递和累积，提高了测试结果的可信度。

附图说明

结合附图并参考以下具体实施方式，本公开各实施例的上述和其他特征、优点及方面将变得更加明显。贯穿附图中，相同或相似的附图标记表示相同或相似的元素。应当理解附图是示意性的，原件和元素不一定按照比例绘制。

图1为本发明实施例公开的一种回归测试方法流程图；

图2为本发明实施例公开的一种模拟测试系统的测试框架示意图；

图3为本发明实施例公开的一种模拟测试系统的技术架构图；

图4为本发明实施例公开的一种关联业务系统仿真模块的示意图；

图5为本发明实施例公开的一种数据库访问接口层示意图；

图6为本发明实施例公开的一种回归测试系统的结构示意图。

具体实施方式

下面将参照附图更详细地描述本公开的实施例。虽然附图中显示了本公开的某些实施例，然而应当理解的是，本公开可以通过各种形式来实现，而且不应该被解释为限于这里阐述的实施例，相反提供这些实施例是为了更加透彻和完整地理解本公开。应当理解的是，本公开的附图及实施例仅用于示例性作用，并非用于限制本公开的保护范围。

本发明实施例公开了一种回归测试方法及系统，通过将预设时间段内实际生产系统生成的所有的生产日志数据按照交易指令进行分组，并将每组生产日志数据构成一个独立的测试用例，实现测试用例的自动收集，由于生产日志数据中覆盖了实际生产系统已出现过的全部业务场景和前置条件组合，因此，相对于人工构造测试用例而言，可以实现测试用例的全面覆盖；通过在模拟测试系统中，根据生产日志数据包含的测试用例执行相对应的交易指令所处的实际生产系统环境，为每个测试用例模拟与实际生产系统环境完全相同的生产系统仿真环境，并在该生产系统仿真环境中，执行相对应的测试用例对应的交易指令，得到模拟输出结果，实现了每个测试用例均可以根据一个测试指令在一个独立的生产系统仿真环境中执行操作，从而实现了各个测试指令之间的完全相互隔离，使得测试操作对环境的影响不会传递和累积，提高了测试结果的可信度。

参见图1，本发明一实施例公开的一种回归测试方法流程图，该方法包括步骤：

步骤S101、将预设时间段内实际生产系统生成的所有的生产日志数据按照交易指令进行分组，并将每组生产日志数据构成一个独立的测试用例。

其中，每个所述测试用例中包括：执行相对应的交易指令所处的实际生产系统环境信息和执行相对应的交易指令得到的实际输出结果，所述实际生产系统环境信息包括：用户输入数据、被测系统接收的所述被测系统以外的系统发送的信息内容、交易指令执行过程中从数据库读取的内容，所述实际输出结果包括：系统回显数据、所述被测系统向所述被测系统以外的系统发送的信息内容和测试用例更新数据库记录的数据内容。

交易指令包括用户输入数据，读写数据库内容，被测系统与被测系统以外的系统之间的交换信息，以及系统回显数据。在实际应用中，系统给每个交易指令分配唯一的交易流水号，每个交易指令具有唯一的交易流水号，每条生产日志数据中都包含该交易流水号，同一交易的生成日志数据中交易流水号都相同。

大型业务系统通常具有日志功能，通过该日志功能进行系统监测预警、问题排查、统计分析等工作。本发明使用生产日志数据构造测试用例并作为比较基准，因此完备的生产日志数据是实现本发明技术方案的前提。

生产日志数据除了记录用户输入数据、系统回显数据，被测系统与被测系统以外的系统之间的信息交换外，还需要记录数据库每次写操作的具体内容和提交时间，以及读操作的数据表名、记录号和提交时间。其中，当数据库本身的日志保存了数据库每次写操作的具体内容和提交时间，以及读操作的数据表名、记录号和提交时间时，生产日志数据将无需记录数据库每次的写操作和读操作的相关信息，在使用生产日志数据时，可以直接从数据库中获取。

此外，生产日志数据还需要记录系统公共配置和状态参数数据库每次更新的内容和时间。

根据生产日志数据构造测试用例的过程如下：

将所述预设时间段内所有的生产日志数据中，包含同一交易流水号的生产日志数据划分为一组，并将每组生产日志数据构成一个独立的测试用例。

其中，测试用例实体是一段文本文档，该文本文档可以称为用例脚本。

测试用例是模拟测试系统用于创建测试用例对象的脚本数据。日志处理工具以天为单位分析生产日志数据，将来自同一用户账号的交易记录保存在一个独立的文件中。

每个测试用例还会将交易更新的数据记录内容和更新时间戳写入快照数据库。

当所有的测试用例生成后，对测试用例文件进行第二轮扫描，根据测试用例读取数据库表操作项中的记录号和提交时间戳，在快照数据库中找到数据记录的更新点，将更新点位置的快照数据库记录索引号标记到用例读操作项上。例如交易A在时刻B读数据库表C中的记录D，在快照数据库中检索记录D的每次更新时间点，发现记录D在交易A读取时间点之前最后一次写操作的索引号为E，就把E写入交易A读取记录E的索引项。以便之后测试用例执行前，先将索引E对应的记录D内容复制到测试系统。

为方便理解，下面提供一个典型的测试用例，如下：文件ac1001.txt表示测试用例为来自用户账号ac1001产生的日志；BDRD$后面的参数表示测试用例执行前需要从快照数据库读取索引号为11223344的CTR表记录，并复制到被测系统CTR表中PH1234号记录中，query MSG$后面的参数表示被测系统向INV系统发送信息，内容为SRQ xxxxxxxx，该项将作为比较基准，reply MSG$后面的信息表示模拟测试系统收到被测系统发来的query信息后，模拟INV系统向其发送回复信息的内容。

如果测试用例与多个外部系统进行信息交换，可能存在多组query/reply，此时，按实际信息交互时序，以递增序号标记各条信息，例如query MSG$2#SEAT#ASR xxxxxxx，具体如下：

[节选自文件ac1001.txt]

input timeStamp$11:12:23”345

input txn$SS CA1234Y23JULPEKSHANN1

DBRD$1#CTR#PH1234#SNAP-CTR-11223344

query MSG$1#INV#SRQ xxxxxxxx

reply MSG$1#INV#SRR xxxxxxxx

。。。。

步骤S102、在模拟测试系统中，根据所述生产日志数据包含的所述实际生产系统环境，为每个所述测试用例模拟与所述实际生产系统环境完全相同的生产系统仿真环境，并在模拟得到的所述生产系统仿真环境中，执行相对应的测试用例对应的交易指令，得到模拟输出结果。

其中，所述在模拟测试系统中，根据所述生产日志数据包含的所述实际生产系统环境，为每个所述测试用例模拟与所述实际生产系统环境完全相同的生产系统仿真环境，具体可以包括：

在所述模拟测试系统中，每次所述测试用例读取数据库操作前，将待读取的记录内容替换为所述测试用例在实际生产系统执行之前，所述测试用例以外的测试用例最近一次更新的数据内容；

模拟所述测试用例中的用户输入数据；

在所述测试用例执行期间，每次所述测试用例等待接收被测系统以外的系统发送的信息内容时，按照所述测试用例在实际生产系统中接收的所述被测系统以外的系统发送的相同信息内容和时序进行模拟发送。

需要说明的是，为每个测试用例模拟与实际生产系统环境完全相同的生产系统仿真环境的信息都保持在测试用例的用例脚本中。

本发明实现的关键为：在测试用例执行前和操作中，为每个测试用例模拟出与实际生产系统环境完全相同的生产系统仿真环境，以确保测试用例与对应的生产交易间的行为可比较。

测试用例的构造是基于生产日志数据，生产日志数据中包含交易指令接触到的生产系统环境，例如从数据库中读出的记录，收到来自外部关联系统的信息等。当测试用例在测试系统中执行时，如果测试用例接触到的测试环境和生产环境相同，就达到完全模拟的效果。

具体的，在每次测试用例读数据库操作前，将待读取的记录内容替换为上次生产日志数据中保存的记录内容。具体操作为：根据测试用例脚本中该数据记录在快照数据库中的索引号，将快照数据库中的记录拷贝到测试数据库中待读取的记录上。同样，每次测试用例需要和外部系统交互时，并没有真的与外部系统进行信息交换，而是模仿生产日志中信息交换数据，给用例发相同内容的信息。

参见图2，本发明一实施例公开的一种模拟测试系统的测试框架示意图，测试框架分为两部分，上层是模拟测试系统，下层是被测系统；

其中，模拟测试系统用于为每个测试用例模拟出生产系统环境，并控制测试用例在预设时间点执行。

模拟测试系统包括：模拟测试服务、快照数据库、更新记录数据库、测试用例和生产数据文件以及测试结果保存文件。其中，快照数据库用于保存生产系统数据库记录的每次的更新信息。更新记录数据库用于保存测试用例执行后的数据记录更新情况。

被测系统包括：业务服务器和数据库。

其中，被测系统与外界的唯一联系为模拟测试系统，或者说模拟测试系统为被测系统虚拟出整个外部环境，该外部环境包括：虚拟出的外部系统和用户，外部系统如图2中所示的虚拟系统1、虚拟系统2、虚拟系统3、…、虚拟系统n，用户为：虚拟终端用户。

在测试操作执行前，根据测试用例的执行时间以及读取的数据库记录号，模拟测试系统查找到测试用例读取数据记录时间点之前，该数据记录最后一次写操作的内容，并将记录内容写入被测系统的数据库中，以供测试用例读取；同样的，根据测试用例执行时间，可以提前设置正确的系统公共配置和状态参数；另外，还要将各关联业务系统的访问地址都设置到模拟测试系统上，这样被测系统向关联业务系统发送信息都定向到模拟测试系统。

测试用例执行过程中，模拟测试系统接收到被测系统发送的信息，此时不检查信息内容是否正确，而是保存该信息并直接回复对应业务系统的回复信息，使测试操作能够继续执行。同时，模拟测试系统保存所有测试用例发送的信息，以及交易最终的输出数据(即系统回显)。

测试用例执行结束后，模拟测试系统读取并保存被测系统对数据库和公共配置状态的更新内容。

参见图3，本发明一实施例公开的一种模拟测试系统的技术架构图，模拟测试系统和被测系统均连接至服务总线上，模拟测试系统包括五个模块，分别为：关联业务系统仿真模块、数据库访问接口层、测试用例对象池、同步与监控模块、以及中央控制单元。

其中：

(1)关联业务系统仿真模块与服务总线连接，为被测系统构造虚拟的外部业务系统，用于支持包含外部信息交互过程的测试用例的正常执行。

其中，所有的虚拟外部业务系统的服务地址都设置为模拟测试系统的IP和端口组合，并将被测系统与外部关联业务系统的信息交互都重定向到模拟测试系统上。

如图4所示的关联业务系统仿真模块的示意图，关联业务系统仿真模块由连接协议封装层、MQ读取线程池和MQ写入线程池组成。为了便于控制测试用例的分步执行，连接协议封装层将所有系统间同步调用和异步调用统一封装为一组MQ队列，被测系统向关联业务系统发送的信息被转到相应的MQ队列中；MQ读取线程池和MQ写入线程池各有一个线程，读线程轮询各MQ，将MQ中信息提交给中央控制单元处理，写线程接收中央控制单元提交的信息，并写到MQ中。其中，连接协议封装层设置有：系统1同步接口1、系统2异步接口，未知系统自由接口等等。

(2)所述数据库访问接口层是用于封装数据库读写操作的异步访问接口。

如图5所示的数据库访问接口层示意图，数据库访问接口层包括：数据库本体、数据库连接池和数据库服务接口线程池。为提高数据记录复制效率，模拟测试系统的生产快照数据和测试结果数据都以独立表形式放在被测系统的数据库中；数据库连接池使用Tomcat jdbc pool，数据库服务接口线程池接收中央控制单元提交的数据记录复制请求，通过数据库连接池操作数据库表。数据库层完成数据记录复制后，将执行结果回复给中央控制单元，中央控制单元收到回复后，继续执行测试操作。

(3)测试用例对象池用于维护预设数量的测试用例对象。

回归测试可能需要执行上百万测试用例，为避免测试用例对象频繁创建销毁的开销，以及调度和监控测试用例的需要，使用测试用例对象池维护预设数量的测试用例对象。

测试用例对象池由集合类型ArrayList对象、各种索引指针、及一组用例对象加载、读写和处理方法组成。测试用例对象包含状态字段，用例对象状态在empty–ready–testing–cleaning之间循环。一组索引指针标记用例池中各类待处理对象的位置，线程安全的对象读写和处理方法维护各自的索引或指针。

(4)同步与监控模块

同步与监控模块与所述测试用例对象池连接，用于在模拟所述实际生产系统的生产系统仿真环境中，检查同一用户账号或读写同一数据记录的测试用例在被测试系统中存在的资源冲突问题；由于测试用例被拆分为多个异步操作环节，需要同步器循环检查测试用例对象池各测试用例对象的当前状态，清理执行时间超过预设时间值的测试用例；同步器还负责回收占用的系统资源，统计测试用例的执行情况，此外同步控制也是测试用例能够乱序执行的前提。同步器由同步控制表、相应的同步控制包以及后台定时检查任务组成。同步控制表是线程安全的集合类型ConcurrentHashMap对象，其K值为数据记录所在表名和key值，测试用例由ready状态切换到testing状态前，要先在同步控制表中注册数据记录的key值，测试结束后释放；同步器还保证来自同一用户账号的测试用例脚本总是加载到同一个用例对象上，也就是同一账号同一时刻在用例池中最多只有一个用例。定时任务循环检查所有用例对象，每次检查用例对象的操作时间戳，如果用例状态长时间没有操作，同步器提交重试或清理用例对象并报错。

(5)中央控制单元分别与所述关联业务系统仿真模块、所述数据库访问接口层和所述测试用例对象池连接，用于预先准备局部测试环境并控制测试用例的分步执行。

中央控制单元首先调用测试用例对象池的加载方法，批量读取测试用例文件，生成测试用例对象并写入测试用例对象池；然后启动中央控制单元的工作线程池，读取测试用例对象，通过同步器检查并等待冲突解决后，通过数据库层为测试用例复制数据记录，通过关联业务系统仿真模块执行用户输入，接收被测系统的请求信息，向被测系统发送模拟回复信息，接收系统回显，最后通过数据库层复制测试用例更新后的数据记录。当测试用例执行完成，中央控制单元继续读取下一测试用例，如此反复直到所有测试用例执行完毕。

步骤S103、将同一交易指令对应的所述实际输出结果和所述模拟输出结果中的相同内容进行对比，实现对被测系统的回归测试。

比较内容包括但不限于如下内容：

·用户输入数据和系统回显数据；

·被测系统与被测系统以外的系统之间的信息交换内容；

·测试用例更新数据库记录的数据内容。

测试用例执行情况的检查项包括:

·应用逻辑执行异常、超时等；

·发送信息到错误的外部系统；

·发送信息格式或信息内容错；

·更新数据库记录的内容错；

·交易生成的用户回显内容错。

综上可知，本发明公开的回归测试方法，通过将预设时间段内实际生产系统生成的所有的生产日志数据按照交易指令进行分组，并将每组生产日志数据构成一个独立的测试用例，实现测试用例的自动收集，由于生产日志数据中覆盖了实际生产系统已出现过的全部业务场景和前置条件组合，因此，相对于人工构造测试用例而言，可以实现测试用例的全面覆盖；通过在模拟测试系统中，根据生产日志数据包含的测试用例执行相对应的交易指令所处的实际生产系统环境，为每个测试用例模拟与实际生产系统环境完全相同的生产系统仿真环境，并在该生产系统仿真环境中，执行相对应的测试用例对应的交易指令，得到模拟输出结果，实现了每个测试用例均可以根据一个测试指令在一个独立的生产系统仿真环境中执行操作，从而实现了各个测试指令之间的完全相互隔离，使得测试操作对环境的影响不会传递和累积，提高了测试结果的可信度。

另外，对于每个测试用例，系统可以自动比较同一交易指令在实际生产系统中的实际输出结果和在模拟系统中的模拟输出结果，且测试用例允许乱序执行，能够通过合理的指令编排进一步提高测试效率。并且，测试用例无需额外操作即可反复多次执行，极大方便了问题重现和分析调试工作。

需要特别说明的是，上述方法实施例中，附图中的流程图和框图，图示了按照本公开各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，该模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

与上述方法实施例相对应，本发明还公开了一种回归测试系统。

参见图6，本发明一实施例公开的一种回归测试的结构示意图，该系统包括：

分组单元201，用于将预设时间段内实际生产系统生成的所有的生产日志数据按照交易指令进行分组，并将每组生产日志数据构成一个独立的测试用例。

其中，所述交易指令具有唯一的交易流水号，每个所述测试用例中包括：执行相对应的交易指令所处的实际生产系统环境信息和执行相对应的交易指令得到的实际输出结果，所述实际生产系统环境信息包括：用户输入数据、被测系统接收的所述被测系统以外的系统发送的信息内容、交易指令执行过程中从数据库读取的内容，所述实际输出结果包括：系统回显数据、所述被测系统向所述被测系统以外的系统发送的信息内容和测试用例更新数据库记录的数据内容。

交易指令包括用户输入数据，读写数据库内容，被测系统与被测系统以外的系统之间的交换信息，以及系统回显数据。在实际应用中，系统给每个交易指令分配唯一的交易流水号，每个交易指令具有唯一的交易流水号，每条生产日志数据中都包含该交易流水号，同一交易的生成日志数据中交易流水号都相同。

因此，分组单元201具体用于：

将所述预设时间段内所有的生产日志数据中，包含同一交易流水号的生产日志数据划分为一组，并将每组生产日志数据构成一个独立的测试用例。

大型业务系统通常具有日志功能，通过该日志功能进行系统监测预警、问题排查、统计分析等工作。本发明使用生产日志数据构造测试用例并作为比较基准，因此完备的生产日志数据是实现本发明技术方案的前提。

生产日志数据除了记录用户输入数据、系统回显数据，被测系统与被测系统以外的系统之间的信息交换外，还需要记录数据库每次写操作的具体内容和提交时间，以及读操作的数据表名、记录号和提交时间。其中，当数据库本身的日志保存了数据库每次写操作的具体内容和提交时间，以及读操作的数据表名、记录号和提交时间时，生产日志数据将无需记录数据库每次的写操作和读操作的相关信息，在使用生产日志数据时，可以直接从数据库中获取。

此外，生产日志数据还需要记录系统公共配置和状态参数数据库每次更新的内容和时间。

根据生产日志数据构造测试用例的过程如下：

将所述预设时间段内所有的生产日志数据中，包含同一交易流水号的生产日志数据划分为一组，并将每组生产日志数据构成一个独立的测试用例。

其中，测试用例实体是一段文本文档，该文本文档可以称为用例脚本。

测试用例是模拟测试系统创建测试用例对象的脚本数据。日志处理工具以天为单位分析生产日志数据，将来自同一用户账号的交易记录保存在一个独立的文件中。

模拟单元202，用于在模拟测试系统中，根据所述生产日志数据包含的所述实际生产系统环境，为每个所述测试用例模拟与所述实际生产系统环境完全相同的生产系统仿真环境，并在模拟得到的所述生产系统仿真环境中，执行相对应的测试用例对应的交易指令，得到模拟输出结果；

模拟单元202具体可以用于：

在所述模拟测试系统中，每次所述测试用例读取数据库操作前，将待读取的记录内容替换为所述测试用例在实际生产系统执行之前，所述测试用例以外的测试用例最近一次更新的数据内容；

模拟所述测试用例中的用户输入数据；

在所述测试用例执行期间，每次所述测试用例等待接收被测系统以外的系统发送的信息内容时，按照所述测试用例在实际生产系统中接收的所述被测系统以外的系统发送的相同信息内容和时序进行模拟发送。

需要说明的是，为每个测试用例模拟与实际生产系统环境完全相同的生产系统仿真环境的信息都保持在测试用例的用例脚本中。

本发明实现的关键为：在测试用例执行前和操作中，为每个测试用例模拟出与实际生产系统环境完全相同的生产系统仿真环境，以确保测试用例与对应的生产交易间的行为可比较。

测试用例的构造是基于生产日志数据，生产日志数据中包含交易指令接触到的生产系统环境，例如从数据库中读出的记录，收到来自外部关联系统的信息等。当测试用例在测试系统中执行时，如果测试用例接触到的测试环境和生产环境相同，就达到完全模拟的效果。

具体的，在每次测试用例读数据库操作前，将待读取的记录内容替换为上次生产日志数据中保存的记录内容。具体操作为：根据测试用例脚本中该数据记录在快照数据库中的索引号，将快照数据库中的记录拷贝到测试数据库中待读取的记录上。同样，每次测试用例需要和外部系统交互时，并没有真的与外部系统进行信息交换，而是模仿生产日志中信息交换数据，给用例发相同内容的信息。

参见图2，本发明一实施例公开的一种模拟测试系统的测试框架示意图，测试框架分为两部分，上层是模拟测试系统，下层是被测系统；

其中，模拟测试系统用于为每个测试用例模拟出生产系统环境，并控制测试用例在预设时间点执行。

模拟测试系统包括：模拟测试服务、快照数据库、更新记录数据库、测试用例和生产数据文件以及测试结果保存文件。其中，快照数据库用于保存生产系统数据库记录的每次的更新信息。更新记录数据库用于保存测试用例执行后的数据记录更新情况。

被测系统包括：业务服务器和数据库。

其中，被测系统与外界的唯一联系为模拟测试系统，或者说模拟测试系统为被测系统虚拟出整个外部环境，该外部环境包括：虚拟出的外部系统和用户，外部系统如图2中所示的虚拟系统1、虚拟系统2、虚拟系统3、…、虚拟系统n，用户为：虚拟终端用户。

在测试操作执行前，根据测试用例的执行时间以及读取的数据库记录号，模拟测试系统查找到测试用例读取数据记录时间点之前，该数据记录最后一次写操作的内容，并将记录内容写入被测系统的数据库中，以供测试用例读取；同样的，根据测试用例执行时间，可以提前设置正确的系统公共配置和状态参数；另外，还要将各关联业务系统的访问地址都设置到模拟测试系统上，这样被测系统向关联业务系统发送信息都重定向到模拟测试系统。

测试用例执行过程中，模拟测试系统接收到被测系统发送的信息，此时不检查信息内容是否正确，而是保存该信息并直接回复对应业务系统的回复信息，使测试操作能够继续执行。同时，模拟测试系统保存所有测试用例发送的信息，以及交易最终的输出数据(即系统回显)。

测试用例执行结束后，模拟测试系统读取并保存被测系统对数据库和公共配置状态的更新内容。

需要说明的是，模拟测试系统包括五个模块，分别为：关联业务系统仿真模块、数据库访问接口层、测试用例对象池、同步与监控模块、以及中央控制单元。五个模块的具体工作原理请参见图3和方法实施例对应部分，此处不再赘述。

对比单元203，用于将同一交易指令对应的所述实际输出结果和所述模拟输出结果中的相同内容进行对比，实现对被测系统的回归测试。

比较内容包括但不限于如下内容：

·用户输入数据和系统回显数据；

·被测系统与被测系统以外的系统之间的信息交换内容；

·测试用例更新数据库记录的数据内容。

测试用例执行情况的检查项包括:

·应用逻辑执行异常、超时等；

·发送信息到错误的外部系统；

·发送信息格式或信息内容错；

·更新数据库记录的内容错；

·交易生成的用户回显内容错。

需要说明的是，描述于本公开实施例中所涉及到的单元可以通过软件的方式实现，也可以通过硬件的方式来实现。其中，单元的名称在某种情况下并不构成对该单元本身的限定，例如，第一获取单元还可以被描述为“获取至少两个网际协议地址的单元”。

综上可知，本发明公开的回归测试系统，通过将预设时间段内实际生产系统生成的所有的生产日志数据按照交易指令进行分组，并将每组生产日志数据构成一个独立的测试用例，实现测试用例的自动收集，由于生产日志数据中覆盖了实际生产系统已出现过的全部业务场景和前置条件组合，因此，相对于人工构造测试用例而言，可以实现测试用例的全面覆盖；通过在模拟测试系统中，根据生产日志数据包含的测试用例执行相对应的交易指令所处的实际生产系统环境，为每个测试用例模拟与实际生产系统环境完全相同的生产系统仿真环境，并在该生产系统仿真环境中，执行相对应的测试用例对应的交易指令，得到模拟输出结果，实现了每个测试用例均可以根据一个测试指令在一个独立的生产系统仿真环境中执行操作，从而实现了各个测试指令之间的完全相互隔离，使得测试操作对环境的影响不会传递和累积，提高了测试结果的可信度。

另外，对于每个测试用例，系统可以自动比较同一交易指令在实际生产系统中的实际输出结果和在模拟系统中的模拟输出结果，且测试用例允许乱序执行，能够通过合理的指令编排进一步提高测试效率。并且，测试用例无需额外操作即可反复多次执行，极大方便了问题重现和分析调试工作。

需要说明的是，系统实施例中各组成部分的工作原理，请参见方法实施例对应部分，此处不再赘述。

最后，尽管已经采用特定于结构特征和/或方法逻辑动作的语言描述了本主题，但是应当理解所附权利要求书中所限定的主题未必局限于上面描述的特定特征或动作。相反，上面所描述的特定特征和动作仅仅是实现权利要求书的示例形式。

虽然在上面论述中包含了若干具体实现细节，但是这些不应当被解释为对本公开的范围的限制。在单独的实施例的上下文中描述的某些特征还可以组合地实现在单个实施例中。相反地，在单个实施例的上下文中描述的各种特征也可以单独地或以任何合适的子组合的方式实现在多个实施例中。

以上描述仅为本公开的较佳实施例以及对所运用技术原理的说明。本领域技术人员应当理解，本公开中所涉及的公开范围，并不限于上述技术特征的特定组合而成的技术方案，同时也应涵盖在不脱离上述公开构思的情况下，由上述技术特征或其等同特征进行任意组合而形成的其它技术方案。例如上述特征与本公开中公开的(但不限于)具有类似功能的技术特征进行互相替换而形成的技术方案。

Claims (11)

1.一种回归测试方法，其特征在于，包括：

将预设时间段内实际生产系统生成的所有的生产日志数据按照交易指令进行分组，并将每组生产日志数据构成一个独立的测试用例，其中，所述交易指令具有唯一的交易流水号，每个所述测试用例中包括：执行相对应的交易指令所处的实际生产系统环境信息和执行相对应的交易指令得到的实际输出结果，所述实际生产系统环境信息包括：用户输入数据、被测系统接收的所述被测系统以外的系统发送的信息内容、交易指令执行过程中从数据库读取的内容，所述实际输出结果包括：系统回显数据、所述被测系统向所述被测系统以外的系统发送的信息内容和测试用例更新数据库记录的数据内容；

在模拟测试系统中，根据所述生产日志数据包含的所述实际生产系统环境，为每个所述测试用例模拟与所述实际生产系统环境完全相同的生产系统仿真环境，并在模拟得到的所述生产系统仿真环境中，执行相对应的测试用例对应的交易指令，得到模拟输出结果；

将同一交易指令对应的所述实际输出结果和所述模拟输出结果中的相同内容进行对比，实现对被测系统的回归测试。

2.根据权利要求1所述的回归测试方法，其特征在于，所述将预设时间段内的所有的生产日志数据按照交易指令进行分组，并将每组生产日志数据构成一个独立的测试用例，具体包括：

将所述预设时间段内所有的生产日志数据中，包含同一交易流水号的生产日志数据划分为一组，并将每组生产日志数据构成一个独立的测试用例。

3.根据权利要求1所述的回归测试方法，其特征在于，同一交易指令对应的所述实际输出结果和所述模拟输出结果的比对内容包括：

系统回显数据；

被测系统向所述被测系统以外的系统发送的信息内容；

测试用例更新数据库记录的数据内容。

4.根据权利要求1所述的回归测试方法，其特征在于，所述模拟测试系统位于测试框架的上层，所述测试框架的下层为被测系统，所述模拟测试系统用于为每个所述测试用例模拟生产系统环境，并控制所述测试用例在预设时间点执行。

5.根据权利要求4所述的回归测试方法，其特征在于，所述模拟测试系统包括：关联业务系统仿真模块、数据库访问接口层、测试用例对象池、同步与监控模块、以及中央控制单元；

所述关联业务系统仿真模块与服务总线连接，为被测系统构造虚拟的外部业务系统，用于支持包含外部信息交互过程的测试用例的正常执行；

所述数据库访问接口层是用于封装数据库读写操作的异步访问接口；

所述测试用例对象池用于维护预设数量的测试用例对象；

所述同步与监控模块与所述测试用例对象池连接，用于在模拟所述实际生产系统的生产系统仿真环境中，检查同一用户账号或读写同一数据记录的测试用例在被测试系统中存在的资源冲突问题，清理所述测试用例对象池中执行时间超过预设时间值的测试用例，回收占用的系统资源，统计测试用例的执行情况；

所述中央控制单元分别与所述关联业务系统仿真模块、所述数据库访问接口层和所述测试用例对象池连接，用于预先准备所述局部测试环境并控制测试用例的分步执行。

6.根据权利要求1所述的回归测试方法，其特征在于，所述在模拟测试系统中，根据所述生产日志数据包含的所述实际生产系统环境，为每个所述测试用例模拟与所述实际生产系统环境完全相同的生产系统仿真环境，具体包括：

在所述模拟测试系统中，每次所述测试用例读取数据库操作前，将待读取的记录内容替换为所述测试用例在实际生产系统执行之前，所述测试用例以外的测试用例最近一次更新的数据内容；

模拟所述测试用例中的用户输入数据；

在所述测试用例执行期间，每次所述测试用例等待接收被测系统以外的系统发送的信息内容时，按照所述测试用例在实际生产系统中接收的所述被测系统以外的系统发送的相同信息内容和时序进行模拟发送。

7.一种回归测试系统，其特征在于，包括：

分组单元，用于将预设时间段内实际生产系统生成的所有的生产日志数据按照交易指令进行分组，并将每组生产日志数据构成一个独立的测试用例，其中，所述交易指令具有唯一的交易流水号，每个所述测试用例中包括：执行相对应的交易指令所处的实际生产系统环境信息和执行相对应的交易指令得到的实际输出结果，所述实际生产系统环境信息包括：用户输入数据、被测系统接收的所述被测系统以外的系统发送的信息内容、交易指令执行过程中从数据库读取的内容，所述实际输出结果包括：系统回显数据、所述被测系统向所述被测系统以外的系统发送的信息内容和测试用例更新数据库记录的数据内容；

模拟单元，用于在模拟测试系统中，根据所述生产日志数据包含的所述实际生产系统环境，为每个所述测试用例模拟与所述实际生产系统环境完全相同的生产系统仿真环境，并在模拟得到的所述生产系统仿真环境中，执行相对应的测试用例对应的交易指令，得到模拟输出结果；

对比单元，用于将同一交易指令对应的所述实际输出结果和所述模拟输出结果中的相同内容进行对比，实现对被测系统的回归测试。

8.根据权利要求7所述的回归测试系统，其特征在于，所述分组单元具体用于：

将所述预设时间段内所有的生产日志数据中，包含同一交易流水号的生产日志数据划分为一组，并将每组生产日志数据构成一个独立的测试用例。

9.根据权利要求7所述的回归测试系统，其特征在于，所述模拟测试系统位于测试框架的上层，所述测试框架的下层为被测系统，所述模拟测试系统用于为每个所述测试用例模拟生产系统环境，并控制所述测试用例在预设时间点执行。

10.根据权利要求9所述的回归测试系统，其特征在于，所述模拟测试系统包括：关联业务系统仿真模块、数据库访问接口层、测试用例对象池、同步与监控模块、以及中央控制单元；

所述关联业务系统仿真模块与服务总线连接，为被测系统构造虚拟的外部业务系统，用于支持包含外部信息交互过程的测试用例的正常执行；

所述数据库访问接口层是用于封装数据库读写操作的异步访问接口；

所述测试用例对象池用于维护预设数量的测试用例对象；

所述同步与监控模块与所述测试用例对象池连接，用于在模拟所述实际生产系统的生产系统仿真环境中，检查同一用户账号或读写同一数据记录的测试用例在被测试系统中存在的资源冲突问题，清理所述测试用例对象池中执行时间超过预设时间值的测试用例，回收占用的系统资源，统计测试用例的执行情况；

所述中央控制单元分别与所述关联业务系统仿真模块、所述数据库访问接口层和所述测试用例对象池连接，用于预先准备所述局部测试环境并控制测试用例的分步执行。

11.根据权利要求7所述的回归测试系统，其特征在于，所述模拟单元具体用于：

在所述模拟测试系统中，每次所述测试用例读取数据库操作前，将待读取的记录内容替换为所述测试用例在实际生产系统执行之前，所述测试用例以外的测试用例最近一次更新的数据内容；

模拟所述测试用例中的用户输入数据；

在所述测试用例执行期间，每次所述测试用例等待接收被测系统以外的系统发送的信息内容时，按照所述测试用例在实际生产系统中接收的所述被测系统以外的系统发送的相同信息内容和时序进行模拟发送。

Images