本发明涉及通信
技术领域：
：，尤其涉及一种自动回归测试方法及装置。
背景技术：
：：回归测试是软件测试的一种，是指对计算机程序中的部分代码修改后，重新对该计算机程序进行测试，以确保修改没有引入新的错误或者导致计算机程序其他未修改部分的代码产生错误。回归测试分为手动测试和自动测试。手动回归测试需要测试人员手工执行每一个测试案例，是重复性较多的活动，容易造成测试人员厌倦和疲劳。自动回归测试是测试人员编写测试案例或者测试脚本之后，由计算机自动执行完成。目前的自动回归测试方法，需要针对每一个测试案例编写对应的测试代码，不同的测试数据就需要编写不同的测试案例，因此在对目标程序进行测试时，通常需要很大数量测试案例，测试人员仍然需要手动编写很多的测试代码，耗费大量的时间和人力、测试效率低下，而且测试代码数量过多、测试代码的管理和维护困难。技术实现要素：本发明提供一种自动回归测试方法及装置，用以解决现有的自动回归测试方法中，测试人员仍然需要手动编写很多的测试代码，耗费大量的时间和人力、测试效率低下，而且测试代码数量过多、测试代码的管理和维护困难的问题。本发明的一个方面是提供一种自动回归测试方法，包括：获取测试任务对应的配置文件，所述配置文件记录有完成所述测试任务需执行的所有测试案例的相关信息；根据所述配置文件中的各所述测试案例的相关信息，执行各所述测试案例，得到各所述测试案例的执行结果；将各所述测试案例的执行结果与对应的预期结果进行比对，得到测试结果。本发明的另一个方面是提供一种自动回归测试装置，包括：获取模块，用于获取测试任务对应的配置文件，所述配置文件记录有完成所述测试任务需执行的所有测试案例的相关信息；执行模块，用于根据所述配置文件中的各所述测试案例的相关信息，执行各所述测试案例，得到各所述测试案例的执行结果；比对模块，用于将各所述测试案例的执行结果与对应的预期结果进行比对，得到测试结果。本发明提供的自动回归测试方法及装置，通过配置文件记录各测试案例的相关信息，在接收到测试任务时，获取测试任务对应的配置文件，根据所述配置文件中的各所述测试案例的相关信息执行各所述测试案例，得到各所述测试案例的执行结果；将各所述测试案例的执行结果与对应的预期结果进行比对，得到测试结果，在实现自动回归测试的同时，无需测试人员编写测试代码，测试案例的所有功能通过配置文件完成，配置文件数量少、便于维护，大大提交了自动回归测试的效率。附图说明此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本发明的实施例，并与说明书一起用于解释本发明的原理。图1为本发明实施例一提供的自动回归测试方法流程图；图2为本发明实施例二提供的自动回归测试方法流程图；图3为本发明实施例三提供的自动回归测试装置的结构示意图；图4为本发明实施例四提供的自动回归测试装置的结构示意图。通过上述附图，已示出本发明明确的实施例，后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本发明构思的范围，而是通过参考特定实施例为本领域技术人员说明本发明的概念。具体实施方式这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本发明相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本发明的一些方面相一致的装置和方法的例子。首先对本发明所涉及的名词进行解释：代码：是指程序员用开发工具所支持的语言写出来的源文件，是一组由字符、符号或信号码元以离散形式表示信息的明确的规则体系。测试案例(testcase)：也就是测试用例，指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。测试案例可以包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试代码等。多个：指两个及以上。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本发明的实施例进行描述。实施例一图1为本发明实施例一提供的自动回归测试方法流程图。本发明实施例针对现有的自动回归测试方法中，测试人员仍然需要手动编写很多的测试代码，耗费大量的时间和人力、测试效率低下，而且测试代码数量过多、测试代码的管理和维护困难的问题，提供了自动回归测试方法。如图1，该方法具体步骤如下：步骤s101、获取测试任务对应的配置文件，配置文件记录有完成测试任务需执行的所有测试案例的相关信息。其中，测试案例的相关信息至少包括：案例标识、待测试程序信息、数据源配置信息、输入数据、预期结果、以及执行结果位置信息。该步骤中，在接收到测试任务时，获取测试任务对应的配置文件。本实施例中，配置文件根据记录信息的不同可以分为5类：全局配置文件、案例配置文件、步骤配置文件和数据配置文件等。每一类型的配置文件可以有一个或者多个。每个类型的配置文件可以对应于多个测试案例，记录多个测试案例的相关信息。例如，一个案例配置文件可以对应于多个测试案例，一个步骤配置文件可以对应于多个测试案例的多个步骤，一个数据配置文件可以记录多个测试案例的输入数据和预期输出结果。在实际应用中，为了便于维护，可以根据测试案例对应的功能、类型等将测试案例进行分类，将同一类测试案例的相关信息记录到同一组配置文件中，从而在减少配置文件数量的同时，便于测试案例的维护。在进行自动回归测试之前，测试人员制定测试任务，根据测试任务完成配置文件的设计和编写，经过验证后的配置文件可以应用在回归测试中。配置文件记录了完成测试任务需执行的所有测试案例的相关信息，从而无需编写程序代码。若需要修改测试案例的输入数据时，只需修改输入数据所在的配置文件即可。步骤s102、根据配置文件中的各测试案例的相关信息，执行各测试案例，得到各测试案例的执行结果。本实施例中，测试案例的执行结果包括：返回结果和数据库修改结果。预期结果包括预期输出结果和预期修改结果。预设输出结果是指各测试案例的返回值的预期值；预期修改结果是指各测试案例执行过程中数据源中被修改的数据的预期值。通过配置文件记录所有测试案例的相关信息，该步骤中，根据配置文件记录的测试案例的相关信息执行各测试案例，得到各测试案例的执行结果。步骤s103、将各测试案例的执行结果与对应的预期结果进行比对，得到测试结果。其中，测试结果可以包括：每个测试案例是否测试通过、以及未通过的测试案例的错误信息等。在测试过程中，若测试案例的执行结果与对应的预期结果一致，则该测试案例测试通过；若测试案例的执行结果与对应的预期结果不一致，则该测试案例测试不通过。本发明实施例通过配置文件记录各测试案例的相关信息，在接收到测试任务时，获取测试任务对应的配置文件，根据配置文件中的各测试案例的相关信息执行各测试案例，得到各测试案例的执行结果；将各测试案例的执行结果与对应的预期结果进行比对，得到测试结果，在实现自动回归测试的同时，无需测试人员编写测试代码，测试案例的所有功能通过配置文件完成，配置文件数量少、便于维护，大大提交了自动回归测试的效率。实施例二图2为本发明实施例二提供的自动回归测试方法流程图。在上述实施例一的基础上，本实施例中，配置文件包括第一配置文件、第二配置文件、第三配置文件、第四配置文件和第五配置文件。第一配置文件中还记录了目标数据存放位置；根据配置文件中的各测试案例的相关信息，执行各测试案例，得到各测试案例的执行结果之前，还包括：确定第一配置文件中记录的目标数据存放位置是否存储有数据；若目标数据存放位置未存储数据，则从完备数据库中获取目标数据，并将目标数据存储到目标数据存放位置。如图2所示，该方法具体步骤如下：步骤s201、获取测试任务对应的获取第一配置文件、第二配置文件、第三配置文件、第四配置文件和第五配置文件。本实施例中，根据配置的内容不同，配置文件分为第一配置文件、第二配置文件、第三配置文件、第四配置文件和第五配置文件五种。其中，第一配置文件、第二配置文件、第三配置文件和第五配置文件可以是xml文件，第四配置文件可以是json格式文件。接下来对每一中配置文件进行详细说明：(1)第一配置文件用于记录全局配置信息，全局配置信息至少包括各测试案例对应的执行结果位置信息和数据源配置信息。本实施例中，第一配置文件可以是xml文件，例如可以命名为applicationcontext.xml。在测试案例的执行过程中，需要预先配置全局的配置信息，第一配置文件中记录了全局变量或者在测试过程中需要使用到的工具对象等全局配置信息。第一配置文件是全局配置文件，可以包括：json数据解析器、测试案例执行结果的保存位置、是否忽略执行过程中遇到的错误、数据源配置以及测试执行过程中需要使用到的工具对象等信息。对全局配置信息的修改，会所有测试案例的执行造成影响，因此将这部分信息抽离，单独维护，对于配置文件的维护更加方便。(2)第二配置文件用于记录各测试案例的基础信息，基础信息至少包括：案例标识和至少一个执行路径标识。本实施例中，第二配置文件可以是xml文件，例如可以命名为cases.xml。第二配置文件定义了各个测试案例的执行路径。第二配置文件可以通过预先配置的spring框架进行解析。例如，第二配置文件可以包括以下形式的内容：其中，<cases></cases>标签中记录一个或者多个测试案例的基础信息。用一组<case></case>标签所包括的内容表示一个case节点，每一个case节点对应于一个测试案例，用于记录一个测试案例的基础信息，也即是，每个case节点定义了一个测试案例。另外，一个测试案例的定义中，除了step节点之外，还可以包括测试案例的案例标识、案例描述、编写人等信息。其中案例标识是全局唯一的，可以用于唯一标识一个测试案例。用一组<step></step>标签所包括的内容表示一个step节点。每一个step节点对应于一个执行路径，step节点的name属性值为对应的执行路径标识，通过执行路径标识与第三配置文件中的一个执行路径的待测试程序信息相对应。也即是，每个step节点定义了一个执行路径。在执行测试案例时，按照从上到下的顺序依次执行每一个执行路径，调用每一个执行路径对应的待测试程序。待测试程序可以是java方法或者webservice服务。(3)第三配置文件用于记录每个执行路径标识对应的待测试程序信息，待测试程序信息至少包括：对应的执行路径标识、待测试程序的调用接口、以及待测试程序所需访问的数据源中的目标数据信息，目标数据信息包括：数据表的表名、数据路由信息和数据查询信息。其中，数据源是通常是指待测试程序所需访问的数据库，待测试程序通常可以为java方法或者webservice服务。本实施例中，第三配置文件可以是xml文件，例如可以命名为step.xml。第三配置文件文件定义了执行路径中需要执行的待测试程序以及需要测试的待测试程序执行过程中所需访问的数据源的目标数据信息。第三配置文件可以通过预先配置的spring框架进行解析。例如，第三配置文件可以包括以下形式的内容：其中，一组<bean></bean>标签所包括的内容表示一个bean对象，一组<property></property>标签所包括的内容表示一个property对象。最外层的一组<bean></bean>标签定义的bean对象对应于第二配置文件中的一个执行路径的待测试程序信息。该bean对象的id属性值是其对应的执行路径的执行路径标识，与(2)中的一个step节点中的name属性值对应。第三配置文件的待测试程序信息中还包括执行路径需要执行的待测试程序的调用接口。以待测试程序为java方法为例，该bean对象中可以用两个property对象分别给出该java方法的类名和方法名，通过类名和方法名即可调用该java方法。若待测试程序为webservice服务，也可以通过property对象直接给出服务的调用接口，例如，可以采用以下方式：其中，classname属性值是java方法的类名或者是webservice服务的名字，如果classname属性值是java方法的类名，那么methodname属性值对应的是需要执行的java方法名，如果classname属性值是webservice名字，那么methodname属性值必须是execute。本实施例中，通过待测试程序的调用接口就可以在执行测试案例的时候确定需要测试的待测试程序。另外，由于待测试程序执行过程中可能会修改数据源中的数据，待测试程序在执行过程中所访问的数据源中的目标数据也是需要校验的，因此，第三配置文件记录的每个执行路径标识对应的待测试程序信息还包括待测试程序所需访问的数据源中的目标数据信息。其中，目标数据信息是指待测试程序执行过程中需要访问的目标数据表的信息，具体包括目标数据表的表名、数据路由信息和数据查询信息。需要校验的数据源中目标数据信息可以记录在第三配置文件中name属性值为“tables”的一个property对象中，该property对象中可以记录多个目标数据信息。name属性值为“tables”的property对象中可以用一个bean对象对应于数据源中的一个目标数据表的信息。其中的每一个bean对象分别与第四配置文件中记录的一个目标数据信息的数据表结构信息相对应。目标数据表的信息的bean对象中name属性值为“tablename”的property对象记录了目标数据表的表名；name属性值为“subject”的property对象记录了目标数据表的数据查询信息，例如可以是sql语句中where子句信息；name属性值为“route”的property对象记录了目标数据表的数据路由信息。其中的每一个bean对象分别通过目标数据表的表名和数据路由信息，与第四配置文件中记录的一个目标数据信息的数据表结构信息相对应。本发明实施例中，通过第三配置文件记录的目标数据表的表名、数据路由信息和数据查询信息，在待测试程序执行完之后，从对应的目标数据库表中获取需要校验的数据。需要说明的是，本实施例中的数据路由信息可以用于支持数据库分库分表的结构，若不存在分库和分表则可以不不包括数据路由信息。(4)第四配置文件用于记录与第三配置文件中的目标数据信息对应的数据表结构信息，数据表结构信息至少包括：数据表的表名、数据路由信息以及数据表的测试字段。本实施例中，第四配置文件可以是xml文件，例如可以命名为table.xml。第四配置文件配置了需要测试的目标数据信息对应的数据库表的结构信息，包括了表名、需要测试的测试字段等信息。第四配置文件可以通过预先配置的spring框架进行解析。例如，第四配置文件可以包括以下形式的内容：其中，目标数据信息是指待测试程序执行过程中需要访问的目标数据表的信息，具体包括目标数据表的表名、数据路由信息和数据查询信息。list节点中的每一个bean对象对应于一个目标数据表的数据表结构信息，name属性值为“tablename”的property对象记录了目标数据表的表名；name属性值为“route”的property对象记录了目标数据表的数据路由信息，name属性值为“查询字段”的property对象记录了目标数据表的测试字段。list节点中的每一个bean对象通过目标数据表的表名与第三配置文件中的目标数据信息对应，也即是第四配置文件中的list节点中的每一个bean对象与第三配置文件中name属性值为“tables”的property对象中的一个bean对象相互对应。本实施例中，根据第三配置文件记录的待测试程序所需访问的数据源中的目标数据信息、和第四配置文件中记录的与第三配置文件中的目标数据信息对应的数据表结构信息，就可以确定执行各测试案例所需要访问数据源中的目标数据，从而可以确定需要测试数据源中的哪些数据。(5)第五配置文件用于记录各测试案例对应的测试数据信息，测试数据信息至少包括：对应的案例标识、输入数据和预期输出结果。本实施例中，测试案例的执行结果包括：返回结果和数据库修改结果。预期结果包括预期输出结果和预期修改结果。预设输出结果是指各测试案例的返回值的预期值；预期修改结果是指各测试案例执行过程中数据源中被修改的数据的预期值。本实施例中，第五配置文件可以是json格式的文件，例如可以命名test_data.json。第五配置文件配置了每一个测试案例的测试输入数据，在执行路径相同的情况下，可以只修改本文件中的测试输入数据，就可以形成新的测试案例。第五配置文件可以由预先配置的json解析器进行解析。测试案例的每一个执行路径都有对应的输入数据，在本发明中，测试案例的输入数据是通过json定义的。例如，第五配置文件可以包括以下形式的内容：其中，测试数据信息还可以包括：测试数据标识、是否已完成、测试数据的相关描述信息、编写人、编写时间等等信息。测试数据标识：用于唯一标识一个测试数据信息的测试数据标识。测试数据的相关描述信息：用于描述测试数据中的每个数值表示的含义、所起的作用等等。是否已完成：用于表示该测试数据是否已经完成，在进行自动回归测试时，要求所有的测试数据必须都是完成状态。例如，可以用“n”表示测试数据未完成，用“y”表示测试数据已完成。可选地，在进行自动回归测试之前，可以检验测试任务对应的所有测试案例对应的测试数据是否均处于已完成状态，如果有未完成的测试数据，输出错误提示信息，并拒绝执行测试。“data”:[]表示一个data数据块，用于记录一个测试数据信息，通过案例标识与一个测试案例相对应。“steps”:[]表示一个steps数据块，data数据块中包括steps数据块。由于每个执行路径对应的待测试程序的输入数据是指输入参数值，可以是常量值、变量值，也可以是前面程序的输出结果。在测试案例的执行过程中，每一个输入数据对应一个测试案例的上下文，对于steps数据块中的数据都会被放入测试案例的上下文中。在输入数据中可以使用“#{xxx}”引用测试案例上下文中的数据。steps数据块中由input语句块和output语句块两部分组成。其中，input语句块用于记录待测试程序的输入数据，例如可以是一个或者多个java方法和/或webservice服务的输入数据。在“第一数据块”数据块的input语句块中设置常量和/或变量的参数值。另外，测试案例的输入数据在一些情况下，可能需要调用外部方法，比如调用某一个对象的方法生成输入数据，在steps数据块中，可以使用“${xx.yy}”调用外部方法，其中xx表示的是类名或者对象名，yy表示方法名。如果xx是类名，那么yy必须对应于静态方法。output语句块用于记录待测试程序的预设结果。如果测试案例没有返回值，则此处可以不记录。步骤s202、第一配置文件中还记录了目标数据存放位置，确定第一配置文件中记录的目标数据存放位置是否存储有数据。在实际应用，执行测试案例会对数据源中的数据做出一些修改，对于修改后的数据有可能造成测试案例无法自动重复执行，此时需要对数据库中数据修改后才可以重复执行，造成无法进行自动回归测试。本实施例中，为了保证自动回归测试过程中能够实现测试案例的自动重复执行，在第一配置文件中还包括：目标数据存放位置。在根据配置文件中的各测试案例的相关信息，执行各测试案例之前，通过该步骤先确定第一配置文件中记录的目标数据存放位置是否存储有数据；如果目标数据存放位置没有存储数据，则确定无法执行测试案例，执行后续步骤从完备数据库中获取目标数据，并将目标数据存储到目标数据存放位置；如果目标数据存放位置存储有数据，则跳过步骤s203直接执行步骤s204，根据配置文件中的各测试案例的相关信息，执行各测试案例，得到各测试案例的执行结果。步骤s203、若目标数据存放位置未存储数据，则从完备数据库中获取目标数据，并将目标数据存储到目标数据存放位置。其中，完备数据库和目标数据的相关信息可以记录在第一配置文件中，以便于根据完备数据库和目标数据的相关信息从完备数据库中获取目标数据，并将目标数据存储到目标数据存放位置。例如，第一配置文件可以包括以下形式的内容：其中，name属性值为“datasource”的property对象的value值表示需要获取的目标数据所在的完备数据库对象。name属性值为“tables”的property对象的value值指的是目标数据对应的各数据表的表名。name属性值为“xmlpath”的property对象的value值指的是目标数据存储位置，也即是执行测试案例时所需访问的目标数据表的文件所在的存储位置。本实施例中，在执行测试案例前，会通过步骤s202首先查看name属性值为“xmlpath”的property对象的value值指定的存储位置是否含有数据，如果没有对应数据，就从name属性值为“datasource”的property对象的value值指向的完备数据库中，将name属性值为“tables”的property对象的value值指定的数据表对应的数据存储到name属性值为“xmlpath”的property对象的value值指定的存储位置。可选地，如果name属性值为“xmlpath”的property对象的value值指定的存储位置中已经含有相关数据，那么将该存储位置中的数据还原到name属性值为“datasource”的property对象的value值指向的完备数据库中，以确保案例重复执行、且每次执行后的执行结果都是相同的。可选地，数据库表中的数据可以采用xml文件的形式表示。可选地，在步骤s204根据配置文件中的各测试案例的相关信息，执行各测试案例之前，还包括：校验所有的配置文件，若校验出错，则输出配置文件校验出错信息，以使测试人员对配置文件进行修改；若校验成功，则执行后续步骤，根据配置文件中的各测试案例的相关信息，执行各测试案例。步骤s204、根据配置文件中的各测试案例的相关信息，执行各测试案例，得到各测试案例的执行结果。具体地，根据配置文件中的各测试案例的相关信息，执行各测试案例，得到各测试案例的执行结果，具体包括：根据第一配置文件中记录的数据源配置信息连接数据源，以使各测试案例对应的各待测试程序运行时访问数据源中的目标数据；根据第二配置文件记录的各测试案例的基础信息、与各测试案例对应的第三配置文件记录的待测试程序所需访问的数据源中的目标数据信息、第四配置文件中记录的与第三配置文件中的目标数据信息对应的数据表结构信息，确定各测试案例所需访问的数据源中的目标数据；根据第五配置文件中记录的与各测试案例对应的测试数据信息中的输入数据、以及各测试案例对应的第三配置文件中的待测试程序的调用接口，运行各待测试程序，并将各待测试程序的运行结果输出到第一配置文件中记录的执行结果位置信息对应的位置。步骤s205、将各测试案例的执行结果与对应的预期结果进行比对，得到测试结果。其中，测试结果可以包括：每个测试案例是否测试通过、以及未通过的测试案例的错误信息等。本实施例中，测试案例的执行结果包括：返回结果和数据库修改结果。预期结果包括预期输出结果和预期修改结果。预设输出结果是指各测试案例的返回值的预期值；预期修改结果是指各测试案例执行过程中数据源中被修改的数据的预期值。该步骤中，将测试案例的执行结果与对应的预期结果进行比对包括：将测试案例的返回结果与预期输出结果比对，将数据库修改结果与预期修改结果比对，若所有比对均一致，则确定该测试案例测试通过；若存在任一执行结果和预期结果不一致，则确定该测试案例测试不通过；记录测试案例是否通过。可选地，若测试案例测试不通过，可以记录测试案例执行中的错误信息，以便于测试人员分析测试案例不通过的原因。步骤s206、根据测试结果生成测试报告。本实施例中，在得到测试结果之后，还可以根据测试结果生成测试报告，以便于测试人员查看测试结果、或者将测试结果导出或者打印。可选地，还可以对各测试案例的测试结果进行统计，例如，统计出测试通过的测试案例数量、测试未通过的测试案例数量、测试通过的测试案例所占比例等待，还可以将统计结果添加到测试报告中。本发明实施例通过根据配置内容的不同设置不同类型的配置文件，将不同类型的配置信息放入不同的配置文件中，根据配置文件中的各测试案例的相关信息执行各测试案例，得到各测试案例的执行结果，将各测试案例的执行结果与对应的预期结果进行比对，得到测试结果，在实现自动回归测试的同时，无需测试人员编写测试代码，测试案例的所有功能通过配置文件完成，配置文件数量少、便于维护，大大提交了自动回归测试的效率。实施例三图3为本发明实施例三提供的自动回归测试装置的结构示意图。本发明实施例提供的自动回归测试装置可以执行自动回归测试方法实施例提供的处理流程。如图3所示，该装置30包括：获取模块301、执行模块302和比对模块303。具体地，获取模块301用于获取测试任务对应的配置文件，配置文件记录有完成测试任务需执行的所有测试案例的相关信息。其中，测试案例的相关信息至少包括：案例标识、待测试程序信息、数据源配置信息、输入数据、预期结果、以及执行结果位置信息。执行模块302用于根据配置文件中的各测试案例的相关信息，执行各测试案例，得到各测试案例的执行结果。比对模块303用于将各测试案例的执行结果与对应的预期结果进行比对，得到测试结果。本发明实施例提供的装置可以具体用于执行上述实施例……所提供的方法实施例，具体功能此处不再赘述。本发明实施例通过配置文件记录各测试案例的相关信息，在接收到测试任务时，获取测试任务对应的配置文件，根据配置文件中的各测试案例的相关信息执行各测试案例，得到各测试案例的执行结果；将各测试案例的执行结果与对应的预期结果进行比对，得到测试结果，在实现自动回归测试的同时，无需测试人员编写测试代码，测试案例的所有功能通过配置文件完成，配置文件数量少、便于维护，大大提交了自动回归测试的效率。实施例四图4为本发明实施例四提供的自动回归测试装置的结构示意图。在上述实施例三的基础上，本实施例中，测试案例的相关信息至少包括：案例标识、待测试程序信息、数据源配置信息、输入数据、预期结果、以及执行结果位置信息。获取模块301还用于获取第一配置文件、第二配置文件、第三配置文件、第四配置文件和第五配置文件。第一配置文件、第二配置文件、第三配置文件和第五配置文件均是xml文件，第四配置文件是json格式文件。第一配置文件用于记录全局配置信息，全局配置信息至少包括各测试案例对应的执行结果位置信息和数据源配置信息。第二配置文件用于记录各测试案例的基础信息，基础信息至少包括：案例标识和至少一个执行路径标识。第三配置文件用于记录每个执行路径标识对应的待测试程序信息，待测试程序信息至少包括：对应的执行路径标识、待测试程序的调用接口、以及待测试程序所需访问的数据源中的目标数据信息，目标数据信息包括：数据表的表名、数据路由信息和数据查询信息。第四配置文件用于记录与第三配置文件中的目标数据信息对应的数据表结构信息，数据表结构信息至少包括：数据表的表名、数据路由信息以及数据表的测试字段。第五配置文件用于记录各测试案例对应的测试数据信息，测试数据信息至少包括：对应的案例标识、输入数据和预期输出结果，预期输出结果为预期结果的一部分。可选地，执行模块302包括：连接子模块、确定子模块和执行子模块。其中，连接子模块用于根据第一配置文件中记录的数据源配置信息连接数据源，以使各测试案例对应的各待测试程序运行时访问数据源中的目标数据。确定子模块用于根据第二配置文件记录的各测试案例的基础信息、与各测试案例对应的第三配置文件记录的待测试程序所需访问的数据源中的目标数据信息、第四配置文件中记录的与第三配置文件中的目标数据信息对应的数据表结构信息，确定各测试案例所需访问的数据源中的目标数据。执行子模块用于根据第五配置文件中记录的与各测试案例对应的测试数据信息中的输入数据、以及各测试案例对应的第三配置文件中的待测试程序的调用接口，运行各待测试程序，并将各待测试程序的运行结果输出到第一配置文件中记录的执行结果位置信息对应的位置。本实施例中，如图4所示，该装置30还包括：数据校验模块304。数据校验模块304用于：确定第一配置文件中记录的目标数据存放位置是否存储有数据；若目标数据存放位置未存储数据，则从完备数据库中获取目标数据，并将目标数据存储到目标数据存放位置。本发明实施例提供的装置可以具体用于执行上述实施例二所提供的方法实施例，具体功能此处不再赘述。本发明实施例通过根据配置内容的不同设置不同类型的配置文件，将不同类型的配置信息放入不同的配置文件中，根据配置文件中的各测试案例的相关信息执行各测试案例，得到各测试案例的执行结果，将各测试案例的执行结果与对应的预期结果进行比对，得到测试结果，在实现自动回归测试的同时，无需测试人员编写测试代码，测试案例的所有功能通过配置文件完成，配置文件数量少、便于维护，大大提交了自动回归测试的效率。在本发明所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。上述以软件功能单元的形式实现的集成的单元，可以存储在一个计算机可读取存储介质中。上述软件功能单元存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本发明各个实施例所述方法的部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(read-onlymemory，rom)、随机存取存储器(randomaccessmemory，ram)、磁碟或者光盘等各种可以存储程序代码的介质。本领域技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。上述描述的装置的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本发明的其它实施方案。本发明旨在涵盖本发明的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本发明的一般性原理并包括本发明未公开的本
技术领域：
：中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本发明的真正范围和精神由下面的权利要求书指出。应当理解的是，本发明并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本发明的范围仅由所附的权利要求书来限制。当前第1页12当前第1页12