一种测试加载方法及装置与流程

本申请涉及计算机技术领域，尤其涉及一种测试加载方法及装置。

背景技术：

随着网络(web)技术的广泛应用，针对web服务器的各种自动化测试技术也是飞速发展，越来越多的项目团队为了减少人力成本和缩短项目开发周期都开始在项目的开发过程中引入自动化测试工作，但由于不同领域web服务器的差异性、产品质量的不规范性和自动化测试框架的成本等问题，导致在实际项目开发过程中进行的自动化测试经常无疾而终。

目前流行的自动化测试框架的设计重点都在固定测试技术的二次封装开发，在这种设计方式中，每个测试用例中的测试技术都是固定的，现有的自动化测试中是不能针对每个测试用例灵活切换测试技术的。为了实现针对不同测试技术的测试，需要编写不同的测试用例。

显然，现有的自动化测试技术中，测试的灵活性较低，实现测试的成本较高。

技术实现要素：

本申请实施例提供一种测试加载方法及装置，用以解决现有的自动化测试技术中，测试的灵活性较低，实现测试的成本较高的问题。

本申请实施例提供的一种测试加载方法，包括：

确定待执行的测试任务对应的测试版本信息、用例文件信息和测试技术；

根据所述测试版本信息和用例文件信息，加载用例文件；

根据加载的所述用例文件中指定的业务功能、所述测试技术、以及所述测试版本信息，加载实现所述业务功能的测试脚本以及测试数据。

可选地，所述方法还包括：

在每个测试版本下，自动生成用例文件、测试脚本、和测试数据的管理目录，不同的测试版本对应不同的用例文件、测试脚本、和测试数据。

可选地，所述方法还包括：

在生成一个新的测试版本后，在该测试版本的业务功能模块中自动添加预设的多种测试技术各自对应的业务功能管理目录以及初始化文件，并在不同的测试技术的业务功能管理目录下分别添加实现各个业务功能的测试脚本。

可选地，所述方法还包括：

在生成一个新的测试版本后，在该测试版本的测试数据模块中自动添加预设的多种测试技术各自对应的测试数据管理目录以及测试数据的初始化文件，并在不同的测试技术的测试数据管理目录下分别添加与每个业务功能的测试脚本相关联的测试数据。

可选地，根据所述测试版本信息和用例文件信息，加载用例文件，包括：

在所述测试版本信息所指示的测试版本下，查找所述用例文件信息所指示的用例文件；

若查找失败，则获取所述测试版本信息的依赖版本信息；在所述依赖版本信息所指示的测试版本下，查找所述用例文件信息所指示的用例文件；重复该步骤，直到查找到所述用例文件，则加载该用例文件。

可选地，根据加载的所述用例文件中指定的业务功能、所述测试技术、以及所述测试版本信息，加载实现所述业务功能的测试脚本以及测试数据，包括：

根据加载的所述用例文件中指定的业务功能和所述测试技术，在所述测试版本信息指示的测试版本下，查找在所述测试技术下实现所述业务功能的测试脚本，以及所述测试数据；

若查找失败，则获取所述测试版本信息的依赖版本信息；在所述依赖版本信息所指示的测试版本下，查找在所述测试技术下实现所述业务功能的测试脚本以及所述测试数据；重复该步骤，直到查找到实现所述业务功能的测试脚本以及所述测试数据，则加载实现所述业务功能的测试脚本以及测试数据。

可选地，加载所述测试数据，包括：

根据预先定义的与所述测试脚本对应的各种参数类型，随机生成执行所述测试脚本时需要使用的测试数据；和/或，

加载用户预先输入的测试数据。

可选地，所述确定待执行的测试任务对应的测试版本信息、用例文件信息和测试技术，包括：

确定用户选择的测试版本信息、用例文件信息和测试技术。

可选地，所述确定待执行的测试任务对应的测试版本信息、用例文件信息和测试技术，包括：

在之前针对所述测试版本信息指示的测试版本执行测试任务时所使用的用例文件中，选择出线性无关的用例文件；

根据选择的每个用例文件的权重和支持的测试技术，将各个用例文件按照用户指定的或者预设的全正交组合方式进行组合；所述全正交组合方式是指对于多个用例文件进行不同的排序组合；

基于所述测试版本信息、进行组合后的用例文件、以及组合后的用例文件支持的测试技术，生成所述待执行的测试任务。

本申请实施例提供的一种测试加载装置，包括：

确定模块，用于确定待执行的测试任务对应的测试版本信息、用例文件信息和测试技术；

加载模块，用于根据所述测试版本信息和用例文件信息，加载用例文件；根据加载的所述用例文件中指定的业务功能、所述测试技术、以及所述测试版本信息，加载实现所述业务功能的测试脚本以及测试数据。

可选地，所述装置还包括：

生成模块，用于在每个测试版本下，自动生成用例文件、测试脚本、和测试数据的管理目录，不同的测试版本对应不同的用例文件、测试脚本、和测试数据。

可选地，所述生成模块还用于：

在生成一个新的测试版本后，在该测试版本的业务功能模块中自动添加预设的多种测试技术各自对应的业务功能管理目录以及初始化文件，并在不同的测试技术的业务功能管理目录下分别添加实现各个业务功能的测试脚本。

可选地，所述生成模块还用于：

在生成一个新的测试版本后，在该测试版本的测试数据模块中自动添加预设的多种测试技术各自对应的测试数据管理目录以及测试数据的初始化文件，并在不同的测试技术的测试数据管理目录下分别添加与每个业务功能的测试脚本相关联的测试数据。

可选地，所述加载模块具体用于：

在所述测试版本信息所指示的测试版本下，查找所述用例文件信息所指示的用例文件；

若查找失败，则获取所述测试版本信息的依赖版本信息；在所述依赖版本信息所指示的测试版本下，查找所述用例文件信息所指示的用例文件；重复该步骤，直到查找到所述用例文件，则加载该用例文件。

可选地，所述加载模块具体用于：

根据加载的所述用例文件中指定的业务功能和所述测试技术，在所述测试版本信息指示的测试版本下，查找在所述测试技术下实现所述业务功能的测试脚本，以及所述测试数据；

若查找失败，则获取所述测试版本信息的依赖版本信息；在所述依赖版本信息所指示的测试版本下，查找在所述测试技术下实现所述业务功能的测试脚本以及所述测试数据；重复该步骤，直到查找到实现所述业务功能的测试脚本以及所述测试数据，则加载实现所述业务功能的测试脚本以及测试数据。

可选地，所述加载模块还用于：

根据预先定义的与所述测试脚本对应的各种参数类型，随机生成执行所述测试脚本时需要使用的测试数据；和/或，

加载用户预先输入的测试数据。

可选地，所述确定模块具体用于：

确定用户选择的测试版本信息、用例文件信息和测试技术。

可选地，所述确定模块具体用于：

在之前针对所述测试版本信息指示的测试版本执行测试任务时所使用的用例文件中，选择出线性无关的用例文件；

根据选择的每个用例文件的权重和支持的测试技术，将各个用例文件按照用户指定的或者预设的全正交组合方式进行组合；所述全正交组合方式是指对多个用例文件进行不同的排序组合；

基于所述测试版本信息、进行组合后的用例文件、以及组合后的用例文件支持的测试技术，生成所述待执行的测试任务。

本申请实施例中，并没有预先设计好每个用例文件所采用的测试技术，而是可以单独配置用例文件信息和测试技术，在加载用例文件后，根据配置的测试技术，再临时加载在该测试技术中实现用例文件中指定的业务功能的测试脚本及测试数据。从而可以灵活切换测试技术，增加测试的灵活性，降低测试成本。

附图说明

图1为本申请实施例提供的测试加载方法流程图；

图2为本申请实施例二提供的一测试加载方法流程图；

图3为本申请实施例提供的自动化测试框架；

图4为本申请实施例提供的测试加载装置结构图。

具体实施方式

本申请实施例中，并没有预先设计好每个用例文件所采用的测试技术，而是可以单独配置用例文件信息和测试技术，在加载用例文件后，根据配置的测试技术，再临时加载在该测试技术下实现用例文件中指定的业务功能的测试脚本及测试数据。从而可以灵活切换测试技术，增加测试的灵活性，降低测试成本。

另外，在本申请优选的实施方式中，系统可以为用户自动生成测试数据，无需用户提供全部的测试数据，不但降低了测试数据维护的成本，也降低了用户输入数据的复杂度。

另外，本申请实施例可以存储不同测试版本下的用例文件、测试脚本及测试数据，在执行测试任务时根据测试版本自动加载用例文件、测试脚本及测试数据，解决了用例文件和测试脚本、测试数据之间的管理兼容性问题，使得用例文件和测试脚本、测试数据的管理更加规范，降低了开发和维护的难度。另外，若测试时在指定的测试版本下查找不到相应的用例文件/测试脚本/测试数据，在可以在该测试版本的依赖版本中查找，提高了用例文件/测试脚本/测试数据的复用性。

进一步地，本申请实施例还提供了一种探索测试的思想，除了在用户的指示下，根据用户选择的测试版本号、用例文件信息和测试技术进行测试外，还可以在系统空闲时，基于用户之前测试时所使用的用例文件，将线性无关的用例文件基于其权重和支持的测试技术进行随机组合，执行自动化探索测试，从而可以自动发现问题，提供业务场景测试的覆盖度。

下面结合说明书附图对本申请实施例作进一步详细描述。

实施例一

本申请实施例引入了版本控制和管理流程，在每个测试版本下，自动生成用例文件、测试脚本、和测试数据的管理目录，不同的测试版本对应不同的用例文件、测试脚本、和测试数据。

在生成一个新的测试版本后，在该测试版本的业务功能模块中自动添加预设的多种测试技术各自对应的业务功能管理目录以及初始化文件。这样，生成的多种测试技术在版本中相互独立并处于并列关系，可达到灵活添加测试技术的目的。另外，在不同的测试技术的业务功能管理目录下分别添加实现各个业务功能的测试脚本。这样，可以针对同一种业务功能灵活切换测试技术。

另外，在生成一个新的测试版本后，在该测试版本的测试数据模块中自动添加预设的多种测试技术各自对应的测试数据管理目录以及测试数据的初始化文件，并在不同的测试技术的测试数据管理目录下分别添加与每个业务功能的测试脚本相关联的测试数据。这样，可以实现针对与测试脚本对应的测试数据的灵活查找及维护。

如图1所示，为本申请实施例一提供的测试加载方法流程图，包括以下步骤：

S101：确定待执行的测试任务对应的测试版本号(也即测试版本信息，本申请实施例以测试版本信息为测试版本号为例进行介绍)、用例文件信息(比如用例名称)和测试技术。

在具体实施中，用户可以指定测试版本号、如果指定的测试任务中包含多个用例文件的测试，则可以指定用例文件的执行顺序，还可以指定测试技术。

作为一种可选的实施方式，测试服务器可以在没有用户指示的情况下，执行自动化探索测试：在之前针对所述测试版本信息指示的测试版本执行测试任务时所使用的用例文件中，选择出线性无关的用例文件；根据选择的每个用例文件的权重和支持的测试技术，将各个用例文件按照用户指定的或者预设的全正交组合方式进行组合；所述全正交组合方式是指对于多个用例文件进行不同的排序组合(这里，不同的组合之间可能包含不同的用例文件，也可能包含的用例文件相同，但执行顺序不同，比如用例文件A-用例文件B，和用例文件B-用例文件A为两种不同的组合方式，其对应的用例文件相同，但执行顺序不同，另外，用例文件A-用例文件B-用例文件C，和用例文件A-用例文件B由于包含的用例文件不同，也自然是两种不同的组合方式)；基于所述测试版本信息、进行组合后的用例文件、以及组合后的用例文件支持的测试技术，生成所述待执行的测试任务。

这里，系统自动统计用例文件执行次数，权重大的用例文件在随机组合时候会增加被执行的次数。测试技术可以有四种，分别为在用户界面(User Interface，UI)层进行验证测试、在网页(web)接口进行验证测试，在服务器后台接口进行验证测试、以及在后台接口进行覆盖性测试。

通过上述自动化探索测试，可以将输入的组合后的用例文件和当前最新的测试版本按照用例执行流程进行7(每周)×24小时(每天)的不间断测试，最终输出执行失败的用例报告。

S102：根据所述测试版本号和用例文件信息，加载用例文件。

基于本申请实施例引入版本控制和管理流程，在具体实施中，可以在所述测试版本号所对应的测试版本下，查找所述用例文件信息所指示的用例文件；若查找失败，则获取所述测试版本号所指示的测试版本的依赖版本号；在所述依赖版本号所指示的测试版本下，查找所述用例文件信息所指示的用例文件；重复该步骤，直到查找到所述用例文件，则加载该用例文件。

这里，若查找用例文件失败或者执行完当前的用例文件，则可以执行下一个用例文件，直到完成整个测试任务。

S103：根据加载的所述用例文件中指定的业务功能、所述测试技术、以及所述测试版本号，加载实现所述业务功能的测试脚本(也称功能关键字)以及测试数据。

基于本申请实施例引入版本控制和管理流程，在具体实施中，可以根据加载的用例文件中指定的业务功能和所述测试技术，在所述测试版本号对应的测试版本下，查找在所述测试技术下实现所述业务功能的测试脚本，以及所述测试数据；若查找失败，则获取所述测试版本号的依赖版本号；在所述依赖版本号所对应的测试版本下，查找在所述测试技术下实现所述业务功能的测试脚本以及所述测试数据；重复该步骤，直到查找到实现所述业务功能的测试脚本以及所述测试数据，则加载实现所述业务功能的测试脚本以及测试数据。

这里，系统中存储有每种测试版本下的测试脚本和测试数据，同样的测试脚本和测试数据可以在不同的测试版本之间复用。可以预先设置好每种测试版本的依赖版本(比如升级后的版本依赖于升级前的版本)，当在当前测试版本下查找不到相应的测试脚本和测试数据时，可以在其依赖版本中进行查找。

在上述步骤中，测试数据可以是用户预先输入的，也可以是系统根据开发人员预先定义的参数类型(与测试脚本对应)自动生成的，还可以是两者的结合。具体地，可以根据预先定义的与所述测试脚本对应的各种参数类型，随机生成执行所述测试脚本时需要使用的测试数据；和/或，加载用户预先输入的测试数据。也即，本申请实施例可以根据业务功能参数和参数的类型、数量自动生成测试数据；并可以加载用户配置的测试数据，通过用户配置的测试数据改变测试脚本的运行流向。

最后，可以基于加载的所述测试脚本和测试数据，执行测试运行流程，得到测试结果。

下面通过一个细化的实施例对本申请思想作进一步说明。

实施例二

如图2所示，为本申请实施例二提供的测试加载方法流程图，包括：

S201：确定待执行的测试任务对应的测试版本号、用例文件信息和测试技术，将该测试版本号作为当前版本号，执行下述步骤。

S202：根据所述用例文件信息中指示的多个用例文件之间的执行顺序，判断是否存在未执行的用例文件。

S203：若存在，则选择一个未执行的用例文件，执行下述步骤S205。

S204：若不存在，则测试任务执行完成。此时可以生成测试报告，还可以通过邮件发送测试报告给用户。

S205：在当前版本号对应的测试版本下，查找选择的用例文件；

S206：若查找成功，则加载查找到的用例文件，并进入S208。

S207：若查找失败，则获取当前版本号的依赖版本号，若获取成功，则将该依赖版本号作为当前版本号，返回S205，若获取失败，则当前用例文件执行失败，返回S202。

S208：将待执行的测试任务对应的测试版本号作为当前版本号，执行下述S209。

S209：根据加载的用例文件中指定的业务功能和确定的测试技术，在当前版本号对应的测试版本下，查找在所述测试技术下实现所述业务功能的测试脚本以及所述测试数据。

S210：若查找失败，则获取当前版本号的依赖版本号，若获取成功，则将该依赖版本号作为当前版本号，返回S209，若获取失败，则当前用例文件执行失败，返回S202。

S211：若查找成功，则加载所述测试脚本以及所述测试数据，执行测试运行流程。

下面从底层技术实现上对本申请思想作进一步介绍。如图3所示，为本申请实施例提供的自动化测试框架，可以分为以下几个部分：

公共基础库模块、业务测试分层模块、用例管理模块、测试数据管理模块、加载器模块、版本管理模块和自动化探索测试模块。这里，对业务功能、测试用例、测试数据通过编码实现后可以称为功能关键字(测试脚本)、用例关键字和测试数据关键字。

上述公共基础库模块主要是对通用的测试技术、测试工具再次开发后的功能的管理；业务测试分层模块主要是对业务功能经过编码实现的功能关键字的管理；用例管理模块主要是对产品用例进行管理；测试数据管理模块主要是对业务功能所需要的测试数据的管理；加载器模块主要是管理功能关键字、用例关键字、测试数据关键字的运行流程；版本管理模块主要是对产品版本规范的定义和管理；自动化探索测试模块主要是在业务流程层面对产品进行探索测试达到自动发现产品问题的目的。

具体地，(1)公共基础库主要分为两种，第一种是对通用技术或工具进行二次开发后的功能，可适用于任何产品。第二种是针对产品的特点进行抽象封装的公共函数库，这样可以增加脚本的复用性和可维护性。第一种是单独存储，被制作为安装包的形式，可安装在任何测试机器；第二种被放在和产品相关的节点中，供相关产品使用。

(2)业务测试分层模块负责对多个测试分层的功能关键字基础库和功能关键字加载器进行管理。这里，不同的测试分层对应不同的测试技术，这里默认有四种测试技术，分别为分别为在用户界面(User Interface，UI)层进行验证测试、在网页(web)接口进行验证测试，在服务器后台接口进行验证测试、以及在后台接口进行覆盖性测试，分别存储在Module/web、Module/webinterface、Module/devinterface和Module/integrate节点中。具体地，Module/web:该节点用于保存在UI层进行验证测试的功能关键字，Module/webinterface:该节点用于保存在web接口进行验证测试的功能关键字，Module/devinterface节点用于保存在服务器后台接口进行验证测试的功能关键字，Module/integrate该节点用于保存在后台接口进行覆盖性测试的功能关键字。

在具体实现时，上述四种测试技术可以有各自的功能关键字加载器和功能关键字基础库；每种测试技术的功能关键字基础库都保存了和产品功能息息相关的功能关键字，也即测试脚本。每一个功能关键字为一个文件，方便使用者快速查找和关键字维护。

每种测试技术的功能关键字加载器，主要用于查询和执行用户指定的功能关键字，独立于版本而存在，上述框架默认提供的四种测试技术的加载器分别为：UI层功能加载器(PageLoader)、web接口层功能加载器(PostLoader)、后台接口层功能加载器(InterfaceIoader)和集成测试层加载器(IntergrateLoader)。这四种加载器的加载方式一致，每个加载器都提供open函数，open定义为：open(name，*kwags)；其中name表示功能关键字的相对路径；每种加载器会根据name的值、测试版本号和测试技术查询并执行对应的功能关键字；其中测试版本号是在用例开始执行的时候设置，加载器在执行功能关键字的时候读取测试版本号。

本申请的多种测试技术处于并列位置，可以根据实际项目的需要自定义添加测试技术，可以灵活的采用不同的测试技术对同一业务功能进行测试，只需要在相应的测试技术中去实现功能关键字即可，多种测试技术配合使用可以使自动化测试更加的真实可靠。

(3)加载器模块由多种类型的加载器组成，其中功能关键字加载器(kwloader)由上述业务测试分层模块负责管理，测试数据关键字加载器(DataLoader)由测试数据管理模块负责管理，用例关键字加载器(caseloader)由用例管理模块负责管理，分别用于查询和执行指定的功能关键字、测试数据关键字和用例关键字。其中功能关键字加载器包含框架默认提供的四种不同测试技术的加载器，分别为UI层功能加载器(PageLoader)、web接口层功能加载器(PostLoader)、后台接口层功能加载器(InterfaceIoader)和集成测试层加载器(IntergrateLoader)。测试数据关键字加载器包含框架默认提供的四种不同的测试数据的加载器，分别为：UI层参数加载器(WebDataLoader)、web接口层参数加载器(PostDataLoader)、后台接口层参数加载器(InterfaceDataLoader)和集成测试层参数加载器(IntergrateDataloader)。

(4)用例管理模块负责对所有版本的用例文件和用例关键字加载器(CaseLoader)进行管理；主要分为用例加载器、用例关键字基础库、用例结果和用例报告三个模块。用例关键字加载器主要用于查询和执行用例关键字，独立于版本而存在；用例关键字基础库主要保存和业务相关的用例文件；用例结果和报告主要是保存并展示用例执行结果，执行报告有html和txt格式，报告记录了每个用例执行结果；测试结果有执行成功、执行失败、执行异常以及用例执行中需要的一些附件信息等。用例关键字加载器提供Run函数，Run(name,*kwags)；其中name表示用例关键字的相对路径；每种加载器会根据name的值、用户指定的测试版本号、测试技术查询并执行对应的用例关键字。

(5)测试数据管理模块负责对所有版本的测试数据关键字和测试数据关键字加载器(DataLoader)进行管理。主要分为测试数据关键字加载器管理模块、数据生成器、测试数据关键字基础库三个模块。

其中，数据生成器负责按照开发人员指定的与功能关键字相适应的数据类型随机产生相对应的数据。测试数据关键字基础库保存了功能关键字所需要的测试数据；测试数据的结构的也是由功能关键字的结构所决定。相同业务如果使用不同的测试技术，所需要的测试数据就不同，比如同一个业务功能在UI层测试需要的测试数据和在后台接口进行测试所需要的测试数据完全不同；测试数据也按照测试分层分为四种，分别保存子啊TestData/web、TestData/webinterface、TestData/devinterface和TestData/integrate节点下，其中TestData/web节点用于保存在UI层进行验证测试的功能关键字所需要的测试数据；TestData/webinterface节点用于保存在web接口进行验证测试的功能关键字所需要的测试数据；TestData/devinterface节点用于保存在服务器后台进行接口测试的功能关键字所需要的测试数据；TestData/integrate节点用于保存在后台接口进行覆盖性测试的功能关键字所需要的测试数据。

在具体实施中，每一个测试数据关键字是对用户输入数据按照功能关键字所需要的输入标准规范生成的一份有效完整的测试数据，需要保证功能关键字可以正常运行。具体地，根据功能关键字确定测试数据关键字所在的测试分层，基于该测试分层，确定满足功能关键字需要的参数名称、参数数量，以及参数类型；基于这些参数信息可以自动生成测试数据。

测试数据关键字加载器包含框架默认提供的四种不同的测试数据的加载器，分别为：UI层测试数据加载器(WebDataLoader)、web接口层测试数据加载器(PostDataLoader)、后台接口层测试数据加载器(InterfaceDataLoader)和集成测试层测试数据加载器(intergrateDataloader)。这三种加载器的加载方式一致，都提供genetate函数，genetate定义为：Genetate(name,*kwags)；其中name表示测试数据关键字的相对路径，每种加载器会根据name的值、用户指定的版本和测试技术查询并执行对应的测试数据关键字。

在具体实施中，对于同一个业务功能的测试技术需要切换的场景，只需要切换测试数据加载器即可。以func这种业务功能在UI层和WEB接口层进行测试的测试数据funcdata为例，在具体实现时，可以首先在TestData/web结构下添加测试数据关键字funcdata(*parameter)；在TestData/webinterface结构下添加测试数据关键字funcdata(*parameter)；在编写测试用例的时候直接调用测试数据关键字，不需要指明使用什么样的测试技术，在执行测试用例的时候指定测试技术，由加载器动态的去执行指定的测试技术中的测试数据关键字。在这种机制下，测试数据关键字和功能关键字一一对应，方便测试数据的查找和维护；测试数据关键字中不仅可以包括用户输入的测试数据，也可以包括自动随机生成的有效数据，解决了常用自动化测试框架中测试数据全部来自用户，数据源单一且固定的问题，同时大大减少了前期的配置工作量，另外，随机生成有效数据不仅保证了业务功能的验证测试，也实现了人力所不能做到的覆盖探索测试的效果。

(6)版本管理模块主要是对产品版本的定义、配置和多版本之间的关系进行管理；每个版本在架构中处于并列关系，每个版本都包含四个库，分别是：公共基础库(lib)、功能关键字基础库(module)、用例关键字基础库(case)、测试数据关键字基础库(testdata)；框架为这四个库各自都提供了一个基类库，这四个基类库中保存了每个版本中的关键字加载器功能和经过二次开发的通用测试功能，和产品版本相关的业务功能都保存在对应的版本中；每发布一个版本，就可以在框架中添加一个版本节点，节点的名称和产品版本号保持一致，添加版本节点后会自动生成lib、module、case、testdata节点，module和testdata节点下面会自动生成对应四种测试技术的节点。

另外，在每个版本中还有一个该版本向后依赖的版本配置pre_verdion参数；该参数默认为空；pre_verdion的值代表该版本的上一个版本，测试用例执行过程中，如果没有在该版本找到相应的用例文件/功能关键字/测试数据时，会继续在pre_verdion指定的版本查询需要加载的用例文件/功能关键字/测试数据。当在该版本加载用例文件或关键字失败且这个pre_verdion参数为空时，系统即停止对用例文件或关键字的查询。添加新版本时，会自动设置该参数的值。当功能关键字在不同版本发生变化后，只需要在新的版本进行重写即可，不需要在依赖版本进行修改，这样很好的解决了关键字的版本兼容性问题，可以同时在不同版本之间进行测试验证；当功能关键字在不同版本没有发生变化，在新的版本中就不用重写关键字功能，只需要设置向后依赖版本即可；关键字执行的时候回根据pre_version的值去查找关键字。

在实际项目测试过程中，用例文件和测试脚本的生命周期和项目的版本息息相关，用例文件和关键字的实现技术可以按照版本的需求进行灵活修改，不仅增加了测试技术选择的灵活性，也大大降低了为兼容多个版本的需要，对功能关键字进行技术开发和维护的成本。

(7)自动化测试探索模块主要是基于业务流程进行探索测试发现问题bug；该模块获取测试过程中开发的独立线性无关的用例关键字，对这些用例关键字进行随机挑选组合，并在产品最新版本上进行不间断的连跑，将执行失败的组合通知相关开发人员，由开发人员排查是否为产品问题。

在探索测试时，不同用例中的功能关键字所需要的测试数据不能是固定的，这就需要在没有人工输入的情况下，测试数据模块可以自动生成能够使功能关键字正常运转的有效数据，这样才能保证探索测试模块中不仅是业务流程组合不同，同时每一次执行相同的业务功能输入的测试数据也不同。

基于同一发明构思，本申请实施例中还提供了一种与测试加载方法对应的测试加载装置，由于该装置解决问题的原理与本申请实施例的测试加载方法相似，因此该装置的实施可以参见方法的实施，重复之处不再赘述。

如图4所示，为本申请实施例提供的测试加载装置结构图，包括：

确定模块401，用于确定待执行的测试任务对应的测试版本信息、用例文件信息和测试技术；

加载模块402，用于根据测试版本信息和用例文件信息，加载用例文件；

根据加载的用例文件中指定的业务功能、测试技术、以及测试版本信息，加载实现所述业务功能的测试脚本以及测试数据。

可选地，所述装置还包括：

生成模块403，用于在每个测试版本下，自动生成用例文件、测试脚本、和测试数据的管理目录，不同的测试版本对应不同的用例文件、测试脚本、和测试数据。

可选地，生成模块403还用于：

在生成一个新的测试版本后，在该测试版本的业务功能模块中自动添加预设的多种测试技术各自对应的业务功能管理目录以及初始化文件，并在不同的测试技术的业务功能管理目录下分别添加实现各个业务功能的测试脚本。

可选地，生成模块403还用于：

在生成一个新的测试版本后，在该测试版本的测试数据模块中自动添加预设的多种测试技术各自对应的测试数据管理目录以及测试数据的初始化文件，并在不同的测试技术的测试数据管理目录下分别添加与每个业务功能的测试脚本相关联的测试数据。

可选地，加载模块402具体用于：

在所述测试版本信息所指示的测试版本下，查找所述用例文件信息所指示的用例文件；若查找失败，则获取所述测试版本信息的依赖版本信息；在所述依赖版本信息所指示的测试版本下，查找所述用例文件信息所指示的用例文件；重复该步骤，直到查找到所述用例文件，则加载该用例文件。

可选地，加载模块402具体用于：

根据加载的所述用例文件中指定的业务功能和所述测试技术，在所述测试版本信息指示的测试版本下，查找在所述测试技术中实现所述业务功能的测试脚本，以及所述测试数据；若查找失败，则获取所述测试版本信息的依赖版本信息；在所述依赖版本信息所指示的测试版本下，查找在所述测试技术中实现所述业务功能的测试脚本以及所述测试数据；重复该步骤，直到查找到实现所述业务功能的测试脚本以及所述测试数据，则加载实现所述业务功能的测试脚本以及测试数据。

可选地，加载模块402还用于：

根据预先定义的与所述测试脚本对应的各种参数类型，随机生成执行所述测试脚本时需要使用的测试数据；和/或，

加载用户预先输入的测试数据。

可选地，确定模块401具体用于：

确定用户选择的测试版本信息、用例文件信息和测试技术。

可选地，确定模块401具体用于：

在之前针对所述测试版本信息指示的测试版本执行测试任务时所使用的用例文件中，选择出线性无关的用例文件；

根据选择的每个用例文件的权重和支持的测试技术，将各个用例文件按照用户指定的或者预设的全正交组合方式进行组合；所述全正交组合方式是指对于多个用例文件进行不同的排序组合；

基于所述测试版本信息、进行组合后的用例文件、以及组合后的用例文件支持的测试技术，生成所述待执行的测试任务。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、装置(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。

显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。