CN105224446B - 一种测试用例筛选方法及装置、服务器 - Google Patents

Abstract

本发明公开了一种测试用例筛选方法，该方法包括：获取与被测程序对应的配置文件；根据所述配置文件，获取基于用户请求信息得到的标准日志；从源测试用例库中获取用于测试所述被测程序的第一测试用例；根据所述第一测试用例生成第一测试请求信息；将所述第一测试请求信息发送至测试工具，并获取从所述测试工具输出的第一测试日志，其中所述测试工具能够调用所述被测程序；根据所述第一测试日志和所述标准日志，判断所述第一测试用例是否有效。本发明同时还公开了一种测试用例筛选装置和一种服务器。

Description

一种测试用例筛选方法及装置、服务器

技术领域

本发明涉及软件测试领域，尤其涉及一种测试用例筛选方法及装置、服务器。

背景技术

目前，越来越多的应用程序被开发和应用，极大的丰富和方便了人们的生活。通常情况下，所开发的应用程序在被正式投入应用之前，软件测试工程师需要对其进行测试，检测所开发的应用程序是否存在缺陷，以便在正式投入应用之前，依据测试结果对其进行不断改进，最终保证用户的使用体验，在这个过程中需要用到测试用例库。

程序设计工程师在编写被测程序时，会从代码库中查找相应的模块化代码，再将模块化代码进行组合，以实现被测程序所要完成的流程活动，其中模块化代码可理解为代码库中的分支。例如，在软件产品中的一些功能如校验逻辑类似的文本框、翻页组件、下拉选择框等公共功能；这些公共功能的实现就可以采用一些通用的模块化的代码。从某种程度上说，被测程序是这些代码库中分支基于设计需求的变化枚举中的其中之一，但由于设计需求变化快，因而分量的组装也非常灵活，从而导致用于测试被测程序的测试用例库难以提前准备好，因而在实际测试的过程中，经常使用源测试用例库，其中源测试用例库又称为基线测试用例库。

现有技术中，使用源测试用例库这种全分支覆盖的方式，具有用例冗余量大、耗时、成本高的缺点，因此，软件测试工程师为了减少冗余，会通过自身经验分析去除一些认为没有必要的测试用例(TC，Test Case)，从而实现对该被测程序的测试用例库的精简；这种人工经验判断的方式，虽然在一定程度上可以剔除一部分的冗余测试用例，但同时也不可控的会剔除一部分有效的测试用例，并且依赖于软件测试工程师的经验、对于需求的理解、及当时的状态，准确率不高。可见，如何针对多变的被测程序，对源测试用例库中的测试用例进行筛选成为亟需要解决的问题。

发明内容

有鉴于此，本发明实施例为解决现有技术中存在的问题而提供一种测试用例筛选方法及装置、服务器，能够快速自动化地对源测试用例库中的测试用例进行筛选，从而提高测试用例精准性，减少测试用例的冗余量，进而达到降低测试成本的目的。

本发明实施例的技术方案是这样实现的：

本发明实施例提供了一种测试用例筛选方法，所述方法包括：

获取与被测程序对应的配置文件；

根据所述配置文件，获取基于用户请求信息得到的标准日志；

从源测试用例库中获取用于测试所述被测程序的第一测试用例；

根据所述第一测试用例生成第一测试请求信息；

将所述第一测试请求信息发送至测试工具，获取从所述测试工具输出的第一测试日志，其中所述测试工具能够调用所述被测程序；

根据所述第一测试日志和所述标准日志，判断所述第一测试用例的有效性。

本发明实施例还提供了一种测试用例筛选装置，所述装置包括：第一获取单元、第二获取单元、第三获取单元、生成单元、第一发送单元、第四获取单元和判断单元；其中：

所述第一获取单元，用于获取与被测程序对应的配置文件；

所述第二获取单元，用于根据所述配置文件，获取基于用户请求信息得到的标准日志；

所述第三获取单元，用于从源测试用例库中获取用于测试所述被测程序的第一测试用例；

所述生成单元，用于根据所述第一测试用例生成第一测试请求信息；

所述第一发送单元，用于将所述第一测试请求信息发送至测试工具，其中所述测试工具能够调用所述被测程序；

所述第四获取单元，用于获取从所述测试工具输出的第一测试日志；

所述判断单元，用于根据所述第一测试日志和所述标准日志，判断所述第一测试用例的有效性。

本发明实施例还提供了一种服务器，所述服务器包括上述的测试用例筛选装置。

本发明的各实施例中，先获取与被测程序对应的配置文件；其次根据所述配置文件，获取基于用户请求信息得到的标准日志；再次从源测试用例库中获取用于测试所述被测程序的第一测试用例；然后根据所述第一测试用例生成第一测试请求信息；之后将所述第一测试请求信息发送至测试工具，并获取从所述测试工具输出的第一测试日志，其中所述测试工具能够调用所述被测程序；最后根据所述第一测试日志和所述标准日志，判断所述第一测试用例的有效性；如此，能够快速自动化地对源测试用例库中的测试用例进行筛选，从而提高测试用例精准性，减少测试用例的冗余量，进而达到降低测试成本的目的。

附图说明

图1-1为本发明实施例一提供的测试用例筛选方法的实现流程示意图一；

图1-2为本发明实施例一提供的测试用例筛选方法的实现流程示意图二；

图1-3为本发明实施例一提供的测试用例筛选方法的实现流程示意图三；

图1-4为本发明实施例一中步骤S106的具体实现流程示意图；

图1-5为本发明实施例一中测试日志的示意图；

图1-6为本发明实施例一提供的测试用例筛选方法的实现流程示意图四；

图2为本发明实施例二提供的测试用例筛选方法的实现流程示意图；

图3为本发明实施例三提供的实现实施例一中步骤S102的具体实现流程示意图；

图4-1为本发明实施例四提供的一种与配置文件所描述的活动类似的活动的运营环境示意图；

图4-2为本发明实施例四提供的网游推广应用领域的运营环境示意图；

图5-1为本发明实施例五提供的测试测试用例的实现流程实体图；

图5-2为本发明实施例五提供的一种实现步骤S302至S304的系统结构示意图；

图6-1为本发明实施例六提供的测试用例筛选装置的组成结构示意图一；

图6-2为本发明实施例六提供的测试用例筛选装置的组成结构示意图二；

图6-3为本发明实施例六提供的测试用例筛选装置的组成结构示意图三；

图6-4为本发明实施例六提供的测试用例筛选装置的组成结构示意图四；

图7为本发明实施例七提供的测试用例筛选装置的组成结构示意图；

图8-1为本发明实施例八提供的服务器的组成结构示意图一；

图8-2为本发明实施例八提供的服务器的组成结构示意图二；

图8-3为本发明实施例八提供的服务器的组成结构示意图三；

图8-4为本发明实施例八提供的测试用例筛选系统的组成结构示意图四；

图9为本发明实施例九提供的一种应用于测试用例筛选装置的测试用例筛选方法的流程示意图。

具体实施方式

下面以游戏领域为例，来说明现有技术存在的问题。网络游戏产业发展到今天，使用游戏推广活动为游戏做宣传的推广模式已经被大多数的游戏玩家所接受。对于网络游戏而言，使用应用程序(以后简称应用)对网络游戏进行推广，已经成为目前主流的网络游戏运营模式。

用于对网络游戏进行推广活动的应用(以后简称网游推广应用)具有活动种类变化多、开发测试周期短、平台系统模块功能高复用及个性化灵活组装的业务特点，而网游推广应用的测试用例是基于网游推广活动开发平台系统(以后简称平台系统)的所有分支的全量来设计的，而每个网游推广应用只是这些分支基于需求的变化枚举，但由于需求变化快、组装灵活，所以无法快速提前准备好所有枚举的网游推广应用的个性用例。一般情况下使用两种方式：第一种为全分支覆盖的方式，该方式能够保障覆盖，但是具有耗时、成本高等缺点；第二种方式采用人工经验判断的方式，该方式虽然在一定程度上可以剔除一部分的冗余测试用例，但同时也不可控的会剔除一部分有效的测试用例，并且依赖于软件测试工程师的经验、对于需求的理解、及当时的状态，准确率不高。可见，如何针对多变的被测程序，对源测试用例库中的测试用例进行筛选成为亟需要解决的问题。

本发明的以下各实施例中，是基于这样一个事实即：程序设计工程师通过枚举代码库中的分支可以构建出很多软件产品，而正在开发的软件产品(即被测程序)只是代码库中分支枚举中的其中之一。其中，所述分支对应着通用的模块化的代码，通用体现在模块化代码的复用率和兼容性上，为了具有较好的复用率和兼容性，该模块化代码一般设计的非常完善，也就是说，好的复用率和兼容性是以代码的冗余为代价来换取的。软件设计领域为了提高软件产品的编写周期而采用模块化的代码，这些模块化代码所组合成的软件产品，实际上本身就是含有冗余代码的软件产品；如果对写冗余的代码进行反复测试，自然会比较耗时，从而延长发布周期。

已经发布的软件产品(即应用程序)经过用户使用，也就是说这些已经发布的软件产品是在真实的运营环境中经过众多用户的测试的，而且因为已经发布的软件产品与被测程序之间是存在一些共同的分支的，那么对于已经发布的软件产品的大多数用户请求信息是可以用来测试被测程序的，这是因为被测程序最终在发布以后，也是在运营环境中不断经过用户测试的，那么在对被测程序进行测试时，就可以调用用户的真实请求信息，以对测试用例是否有效做出判断；基于此，只要找出那些与被测程序有共同分支的软件产品，并将这些软件产品的真实运营环境中的用户请求信息用于测试被测程序。

真实运营环境中的用户请求信息用于测试被测程序时，从而可以产生一个基于用户的真实请求信息的日志(即包括覆盖状态的日志，又称为覆盖日志)；而源测试用例库中的每一测试用例用于测试被测程序的时候，也同样会产生一个日志；在本发明的各实施例中，通过将基于用户的真实请求信息得到的日志作为标准日志，来衡量测试用例的日志；也就是说，在本发明的各实施例中，将通过测试覆盖路径来衡量测试用例有效性；其中测试覆盖路径是指一项给定测试或一组测试对某个给定系统或构件的所有指定测试用例进行处理所达到的程度；而测试用例有效性是指，实际测试执行的测试覆盖路径，是否完全包含了客观用户会进入的所有代码路径。

更进一步地，当测试用例的日志中呈覆盖(covered)状态代码行包括在标准日志中呈未覆盖(uncovered)状态代码行中时，判断该测试用例无效，反之，该测试用例有效；如此，逐一判断测试用例库中的测试用例是否有效。由此可见，本发明实施例采用客观用户的历史行为最为标准，替代以人工经验

来猜测用户行为构建、筛选用例，进而减少误删，提升准确性。

下面结合附图和具体实施例对本发明的技术方案进一步详细阐述。

实施例一

本发明实施例提供一种测试用例筛选方法，如图1-1所示，该方法包括：

步骤S101，获取与被测程序对应的配置文件；

这里，其中所述被测程序用于实现某一目标任务，所述配置文件用于描述所述目标任务；

这里，所述被测程序是指为了达到某一目标任务而设计的程序，该被测程序是待发布的软件产品或者软件产品中的一部分；

例如，针对一款益智应用，如国际象棋(chess)的软件产品，为了能在更多的用户间进行推广和共享交互，用户单人使用该益智应用、或多人联网交互一起使用该益智应用，可以对该益智应用提供一种策略，以提高用户的使用体验。比如，该策略为只要用户注册账户，即可获取额外的信息(区别于该益智应用在用户单人使用时或者多人联网交互时会用到的应用基本信息，比如选哪个棋子，走几步等等)，如果是打游戏的场景，所述额外的信息即为游戏玩家获赠的游戏币。

由于上述策略的实现要以一种网络软件产品的形式体现，那么就要为该策略的实现设计对应的应用程序，从上述例子可以看出，所述目标任务即为实现该策略，而被测程序是指为该策略的实现所设计的所述应用程序。

步骤S102，根据所述配置文件，获取基于用户请求信息得到的标准日志；

步骤S103，从源测试用例库中获取用于测试所述被测程序的第一测试用例；

这里，测试用例库是指用于存放测试用例的仓库；而源测试用例库是指包括针对所有的用于测试可用于编写程序的分支的测试用例库，对于某一编写好的待测试程序，该待测试程序只是代码库中分支枚举的其中之一，而对于该待测试程序的测试用例库，只是源测试用例库中测试用例枚举的其中之一。

其中，测试用例是指对一项特定的软件产品(即被测程序)进行测试任务的描述，体现测试方案、方法、技术和策略；测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实软件产品是否满足某个特定的设计需求。下面给出测试用例的一种类结构，如表1所示，该种测试用例的类结构包括5部分，分别描述测试用例的名称、代码行覆盖日志包路径、测试脚本路径、执行步骤、预期结果。

表1

编号	测试用例的类结构
		1	测试用例的名称
2	代码行覆盖日志包路径
		3	测试脚本路径
4	执行步骤
		5	预期结果

这里，所述第一测试用例只是源测试用例库中的任意一个测试用例，这里的第一，只是用于区别另一测试用例，并没有特别指定的含义；相应地，下文中的第一测试请求信息、第一代码行等中的“第一”均是为了与第一测试用例进行对应。

步骤S104，根据所述第一测试用例生成第一测试请求信息；

这里，测试请求信息中可以直接携带测试脚本，如自动化测试脚本，该自动化脚本可以通过测试用例类结构中的自动化脚本路径来获取，测试请求信息也可以携带有测试脚本路径以及测试脚本运行过程中所需的相关数据等信息；当所述测试请求信息中携带的是测试脚本路径时，该测试脚本路径可以是本地的路径，也可以是网络地址；本地是指测试工具所运行的服务器，这里所述测试工具所运行的服务器可以是个人计算机、工控机等具有计算能力的设备。

步骤S105，将所述第一测试请求信息发送至测试工具，并获取从所述测试工具输出的第一测试日志，其中所述测试工具能够调用所述被测程序；

这里，测试工具根据测试请求信息携带的测试脚本路径获取测试脚本；然后运行所述测试脚本和被测程序，以便对被测试程序进行测试。在测试过程中，测试脚本可以发出相应的测试指令使被测程序执行预定的操作，并且在运行过程中输出测试日志。

步骤S106，根据所述第一测试日志和所述标准日志，判断所述第一测试用例的有效性。

基于上述图1-1所示的实施例，如图1-2所示，在步骤S106之后，该方法还包括步骤S107：判断所述第一测试用例有效时，将所述第一测试用例存储于针对所述被测程序的目标测试用例库中。

这里，所述步骤S107中还可以包括：将所述第一测试用例标记为有效的步骤。具体地，可以建立一张测试用例的名称与测试用例的有效性之间的关系表，其中，测试用例的名称即为测试用例类结构中的名称，测试用例的有效性即有效或者无效。本领域技术人员也可以根据各种现有技术来实现，本步骤将所述第一测试用例标记为有效，这里不再赘述。

基于上述图1-1所示的实施例，如图1-3所示，在步骤S106之后，该方法还包括步骤S108：判断所述第一测试用例无效时，将所述第一测试用例标记为无效，且不将所述第一测试用例存储于目标测试用例库中。

这里，步骤S108中将所述第一测试用例标记为无效，可以参见上述步骤S107中的描述，这里不再赘述。

这里，如图1-4所示，步骤S106包括：

步骤S161，确定所述第一测试日志中所有呈覆盖状态的第一代码行；

这里，日志(Log)中的覆盖状态即covered状态，对应地，日志中还存在未覆盖状态即uncovered状态，这里，所述日志包括测试日志和标准日志。

步骤S162，判断所述第一代码行是否位于所述标准日志中呈未覆盖状态的代码行中，如果是，判断所述第一测试用例无效；否则，判断所述第一测试用例有效。

这里，标准日志来源于真实用户请求信息集(又称用户请求包)回放的测试环境中，这里的真实表示是从运营环境中获取的用户请求信息。

这里，日志包括标准日志和测试日志的结构均为被测程序的整体源码，日志与被测程序的整体源码所不同的是，如图1-5所示，日志上还有覆盖标注，这里的标注包括两种状态即覆盖状态和未覆盖状态，其中：

在标准日志中，所有用户请求信息集合经过的代码行，即覆盖的代码行都会被标示为covered状态，而未经过的代码行即未覆盖的代码行则被标注为uncovered状态。在标准日志中，covered状态的视为有效路径，而uncovered状态视为无效路径；

在测试日志中，测试用例经过的代码行被标示为covered状态，则视为已覆盖路径，而uncovered状态视为无覆盖路径。

本发明实施例中，基于图1-3或1-4所示的实施例，如图1-6所示，在步骤S107或步骤S108之后，该方法还包括：

步骤S109，从源测试用例库中获取第二测试用例；

步骤S110，根据所述第二测试用例生成第二测试请求信息；

步骤S111，根据所述第二测试请求信息发送至所述测试工具，并获取从所述测试工具输出的第二测试日志；

步骤S112，根据所述第二测试日志和所述标准日志，判断所述第二测试用例的有效性；

步骤S113，依此类推，判断源测试用例库中剩余的其它测试用例的有效性，形成针对所述测试程序的目标测试用例库。

其中，步骤S112，包括：

步骤SQ1，确定所述第二测试日志中所有呈覆盖状态的第二代码行；

步骤SQ2，判断所述第二代码行是否位于标准日志中呈未覆盖状态的代码行中，如果是，判断所述第二测试用例无效；否则，判断所述第二测试用例有效。

需要说明的是，本发明实施例中的步骤S101至S113，并不是严格上的先后顺序关系，例如步骤S101与步骤S102之间是有先后关系的，而步骤S101与步骤S103是没有先后关系的，也就是说步骤S101和步骤S103还可以是并列的关系。

本发明实施例中，先获取与被测程序对应的配置文件；其次根据所述配置文件，获取基于用户请求信息得到的标准日志；再次从源测试用例库中获取用于测试所述被测程序的第一测试用例；然后根据所述第一测试用例生成第一测试请求信息；之后将所述第一测试请求信息发送至测试工具，并获取从所述测试工具输出的第一测试日志，其中所述测试工具能够调用所述被测程序；最后根据所述第一测试日志和所述标准日志，判断所述第一测试用例是否有效；如此，能够快速自动化地对源测试用例库中的测试用例进行筛选，从而提高测试用例精准性，减少测试用例的冗余量，进而达到降低成本的目的。

实施例二

基于上述的实施例一，本发明实施例为了持续地对源测试用例库中的测试用例进行判断，如图2所示，本发明实施例提供的测试用例筛选方法包括：

步骤S201，获取与被测程序对应的配置文件；

这里，所述被测程序用于实现某一目标任务，所述配置文件用于描述所述目标任务；

步骤S202，根据所述配置文件，获取基于用户请求信息得到的标准日志；

步骤S203，从源测试用例库中获取用于测试所述被测程序的测试用例；

步骤S204，根据该测试用例生成测试请求信息；

步骤S205，将该测试请求信息发送至测试工具，并获取从所述测试工具输出的测试日志；

这里，所述测试工具能够调用所述被测程序；

步骤S206，根据所述测试日志和所述标准日志，判断测试用例是否有效；如果是，进入步骤S207；否则，进入步骤S208；

步骤S207，将测试用例保存于针对被测程序的目标测试用例库中，进入步骤S209；

步骤S208，将测试用例标记为无效，且不将测试用例保存于目标测试用例库中；进入步骤S209；

步骤S209，判断源测试用例库中是否存在还未进行判断的测试用例，如果是，返回步骤S203；否则，结束。

实施例三

基于上述的实施例一，本发明实施例三提供一种实现上述实施例一中步骤S102的方式，如图3所示，包括以下步骤：

步骤S301，确定描述所述配置文件的结构体，根据所述结构体确定任务集；

这里，配置文件包括以下内容：目标任务标识(ID)、目标任务名称、目标任务状态、服务部门、客户类型、活动类型、目标任务开始时间、目标任务结束时间、目标任务地址等。其中目标任务状态用状态值0和1来表示，其中0表示目标任务当前无效、1表示目标任务当前有效；目标任务地址为被测程序发布的统一资源定位符(URL，Uniform ResourceLocator)。本领域的技术人员可以采用各种现有技术方式并根据目标任务的具体内容来实现配置文件，这里不再赘述。

这里，所述任务集的配置文件与所述被测程序对应的配置文件的结构体一样，参数不同。

步骤S302，从运营环境中获取所述任务集的用户请求信息集；

这里，根据配置文件而确定的任务集的用户请求信息集合，该任务集所实现的活动与配置文件所描述的活动类似，这里的类似活动是指配置文件的结构体一样，而具体参数不同。从运营环境拷贝真实用户的所有用户请求信息集，并全量录制拷贝成文件包，存储至测试工具所运行的服务器的路径下。

步骤S303，将所述用户请求信息集发送至所述测试工具；

步骤S304，接收所述测试工具输出的标准日志并存储所述标准日志；

这里，所述测试工具接收所述用户请求信息集，然后调用被测程序，生成标准日志。

步骤S305，读取所述标准日志。

实施例四

基于上述的各实施例，来说明本发明实施例三中的运营环境。图4-1示出一种与配置文件所描述的活动类似的活动的运营环境示意图，在线服务系统410包括解析服务器411和若干个模块化服务器412，每一所述模块化服务器412用于实现不同的功能。用户请求信息经过解析服务器411的解析后，根据各模块化服务器412所具有的不同功能将解析结果发送给对应的模块化服务器412，这样用户请求信息将依次经过模块化服务器412的传输控制协议(TCP，Transmission Control Protocol)层、网络之间互连的协议(IP，InternetProtocol)层和数据链路(Data Link)层，从而将响应结果反馈给用户。

下面以游戏场景下的应用为例，来说明本实施例四中图4-1所示的运营环境，以已发布的网游应用在推广时的真实运营环境为例，如图4-2所示，网游应用的真实运营环境包括由用户组成的用户集合420和用于服务用户集合420的在线服务系统430，其中：

用户集合420包括用户421、用户422和用户423，其中用户421参加游戏A时所提供的策略可以为游戏A的每日抽奖活动，用户422参加游戏B的推广活动即游戏B的报名抽奖活动，而用户423参加发微博送好礼活动。

在线服务系统430包括解析服务器431和模块化服务器，其中模块化服务器包括抽奖模块432、报名模块433、微博模块434和其它模块435；在图4-2中，抽奖模块432为典型的通用复用模块即，该抽奖模块432同时服务多个枚举的网游推广应用，对于每个枚举的网游推广应用来说，它的分支是不同且不断更新的，而整个源测试用例库的中的测试用例都执行，则会有非常多的冗余用例。

其中，解析服务器431，用于接收并解析用户的用户请求信息，得到解析结果，然后根据解析结果将对应地分发给模块如432至435。

现以用户422参加的游戏B的推广活动为例，来说明运营环境的工作流程。用户422参加游戏B的报名抽奖活动，通过终端如个人计算机、平板电脑、手机等发送用户请求信息，该用户请求信息表明用户422要参加报名抽奖活动，解析服务器431接收用户发送的用户请求信息，然后解析发现，该用户422的用户请求信息是与抽奖模块432和报名模块433是关联的，因此将用户请求信息发送给抽奖模块432和报名模块433，然后抽奖模块432根据用户422的用户请求信息判断用户422是否中奖，而报名模块433对用户422的报名进行记录，然后由抽奖模块432和报名模块433将结果反馈给用户422。

实施例五

下面将提供一种本发明实施例三中的步骤S302至S304的系统结构；先介绍一下测试工具，如图5-1所示，从源测试用例库510中取出一个测试用例，然后根据该测试用例生成测试请求信息511，并输入到测试工具512中，然后测试工具512能够调用被测程序，最后生成日志513。

需要说明的是测试工具安装在测试服务器514上，而输出的日志513、以及源测试用例库510都可以位于测试服务器514上，当然也可以不位于测试服务器514上。

下面提供一种实现步骤S302至S304的系统结构，如图5-2所示，通过在各在线服务系统410中增加一个拷贝管理服务器413，该拷贝管理服务器413用于从模块化服务器412中拷贝真实用户的所有请求信息集，并全量录制拷贝成文件包，存储至测试服务器514的路径下。然后测试工具512调用用户请求信息集和被测程序，然后输出日志513，该日志513将作为标准日志。

需要说明的是，将用户请求信息集输入到测试工具512中，该过程可以理解为是对用户请求信息的回放过程，回放过程是根据用户请求信息对用户的登录态进行了复现，这里回放目的只是为了以用户请求信息作为输入参数，从而能从输出日志中获得实际覆盖代码的路径分支。在具体的实施过程中，本领域技术人员可以在测试环境中构建登陆态验证的模拟桩，以实现上述回放过程。

实施例六

基于上述的实施例一至五，本发明实施例提供一种测试用例筛选装置，图6-1为本发明实施例六测试用例筛选装置的组成结构示意图一，如图6-1所示，该装置包括第一获取单元601、第二获取单元602、第三获取单元603、生成单元604、第一发送单元605、第四获取单元606和判断单元607，其中：

所述第一获取单601，用于获取与被测程序对应的配置文件，其中所述被测程序用于实现某一目标任务，所述配置文件用于描述所述目标任务；

这里，所述被测程序是指为了达到某一目标任务而设计的程序，该被测程序是待发布的软件产品或者软件产品中的一部分。

所述第二获取单元602，用于根据所述配置文件，获取基于用户请求信息得到的标准日志；

所述第三获取单元603，用于从源测试用例库中获取用于测试所述被测程序的第一测试用例；

这里，测试用例库是指用于存放测试用例的仓库；而源测试用例库是指包括针对所有的用于测试可用于编写程序的分支的测试用例库，对于某一编写好的待测试程序，该待测试程序只是代码库中分支枚举的其中之一，而对于该待测试程序的测试用例库，只是源测试用例库中测试用例枚举的其中之一。

这里，所述第一测试用例只是源测试用例库中的任意一个测试用例，这里的第一，只是用于区别另一测试用例，并没有特别指定的含义；相应地，下文中的第一测试请求信息、第一代码行等中的“第一”均是为了与第一测试用例进行对应。

所述生成单元604，用于根据所述第一测试用例生成第一测试请求信息；

这里，测试请求信息中可以直接携带测试脚本，如自动化测试脚本；测试请求信息也可以携带有测试脚本路径以及测试脚本运行过程中所需的相关数据等信息；当所述测试请求信息中携带的是测试脚本路径时，该测试脚本路径可以是本地的路径，也可以是网络地址；本地是指测试工具所运行的服务器，这里所述测试工具所运行的服务器可以是个人计算机、工控机等具有计算能力的设备。

所述第一发送单元605，用于将所述第一测试请求信息发送至测试工具，其中所述测试工具能够调用所述被测程序；

这里，测试工具根据测试请求信息携带的测试脚本路径获取测试脚本；然后运行所述测试脚本和被测程序，以便对被测试程序进行测试。在测试过程中，测试脚本可以发出相应的测试指令使被测程序执行预定的操作，并且在运行过程中输出测试日志。

所述第四获取单元606，用于获取从所述测试工具输出的第一测试日志；

所述判断单元607，用于根据所述第一测试日志和所述标准日志，判断所述第一测试用例的有效性。

本发明实施例中，所述第三获取单元，还用于从所述源测试用例库中获取第二测试用例；

所述生成单元，还用于根据所述第二测试用例生成第二测试请求信息；

所述第一发送单元，还用于根据所述第二测试请求信息发送至所述测试工具；

所述第四获取单元，还用于获取从所述测试工具输出的第二测试日志；

所述判断单元，还用于根据所述第二测试日志和所述标准日志，判断所述第二测试用例的有效性；

所述第三获取单元、所述发送单元、所述生成单元、所述第四获取单元和所述判断单元，依此类推实现判断源测试用例库中剩余的其它测试用例的有效性，形成针对所述测试程序的目标测试用例库。

基于上述图6-1所示的实施例，如图6-2所示，该装置还包括第一存储单元608，用于判断所述第一测试用例有效时，将所述第一测试用例存储于针对所述被测程序的目标测试用例库中。

基于上述图6-1所示的实施例，如图6-3所示，该装置还包括标记单元609，用于判断所述第一测试用例无效时，将所述第一测试用例标记为无效，且不将所述第一测试用例存储于目标测试用例库中。

基于上述图6-1所示的实施例，如图6-4所示，所述判断单元607包括第二确定模块671和判断模块672，其中：

所述第二确定模块671，用于确定所述第一测试日志中所有呈覆盖状态的第一代码行；

所述判断模块672，用于判断所述第一代码行是否位于所述标准日志中呈未覆盖状态的代码行中，如果是，判断所述第一测试用例无效；否则，判断所述第一测试用例有效。

实施例七

基于上述的实施例六，本发明实施例提供一种测试用例筛选装置，如图7所示，该装置包括第一获取单元701、第二获取单元702、第三获取单元703、生成单元704、第一发送单元705、第四获取单元706和判断单元707，其中第二获取单元702包括第一确定模块721、获取模块722、发送模块723,、接收模块723和读取模块724，其中：

所述第一获取单701，用于获取与被测程序对应的配置文件，其中所述被测程序用于实现某一目标任务，所述配置文件用于描述所述目标任务；

所述第一确定模块721，用于确定描述所述配置文件的结构体，根据所述结构体确定任务集；

所述获取模块722，用于从运营环境中获取所述任务集的用户请求信息集；

所述发送模块723，用于将所述用户请求信息集发送至所述测试工具；

所述接收模块724，用于接收所述测试工具输出的标准日志并进行存储；

所述读取模块724，用于读取所述标准日志；

所述第三获取单元703，用于从源测试用例库中获取用于测试所述被测程序的第一测试用例；

所述生成单元704，用于根据所述第一测试用例生成第一测试请求信息；

所述第一发送单元705，用于将所述第一测试请求信息发送至测试工具，其中所述测试工具能够调用所述被测程序；

所述第四获取单元706，用于获取从所述测试工具输出的第一测试日志；

所述判断单元707，用于根据所述第一测试日志和所述标准日志，判断所述第一测试用例的有效性。

这里，所述任务集的配置文件与所述测试程序对应的配置文件的结构体一样，参数不同。

本发明实施例中，所述判断单元包括第二确定模块和判断模块，其中：

所述第二确定模块，用于确定所述第一测试日志中所有呈覆盖covered状态的第一代码行；

所述判断模块，用于判断所述第一代码行是否位于所述第一标准日志中呈未覆盖状态的代码行中，如果是，判断所述第一测试用例无效；否则，判断所述第一测试用例有效。

本发明实施例中，该装置还包括第一存储单元，用于判断所述第一测试用例有效时，将所述第一测试用例存储于针对所述被测程序的目标测试用例库中。

本发明实施例中，该装置还包括标记单元，用于判断所述第一测试用例无效时，将所述第一测试用例标记为无效，且不将所述第一测试用例存储于目标测试用例库中。

实施例八

基于上述的实施例六和实施例七，本发明实施例还提供一种服务器800，如图8-1所示，所述服务器800包括测试用例筛选装置820，测试用例筛选装置820为上述实施例六和实施例七所提供的任意一种测试用例筛选装置。

基于上述的实施例六和实施例七，本发明实施例还提供一种服务器，如图8-2所示，所述服务器800包括测试用例筛选装置820和测试工具810，其中测试用例筛选装置820为上述实施例六和实施例七所提供的任意一种装置。

如图8-3所示，测试工具810包括接收单元811、测试单元812和第二发送单元813，其中：

接收单元811，用于接收上述测试用例筛选装置820中第一发送单元605发送的第一测试请求信息；

测试单元812，用于根据接收单元811接收的第一测试请求信息，调用被测程序对所述第一测试请求信息进行处理，得到第一测试日志；

第二发送单元813，用于将所述第一测试日志发送给上述测试用例筛选装置820中的第一获取单元606。

本发明实施例中，接收单元811，还用于接收上述测试用例筛选装置中第一发送单元存储模块发送的用户请求信息集；

对应地，测试单元812，还用于根据接收单元811接收的用户请求信息集，调用被测程序对所述第一测试请求信息进行处理，得到标准日志；

对应地，第二发送单元813，用于将所述标准日志发送给上述测试用例筛选装置中的接收模块。

这里，在图8-3所示的实施例中，仅以图6-1中的测试用例筛选装置为例，本领域的技术人员应该理解，在图8-3中测试用例筛选装置820可以是上述实施例六和七中任一中测试用例筛选装置，这里不再赘述。

基于上述的实施例六和实施例七，本发明实施例提供一种测试用例筛选系统，如图8-4所示，该系统包括第一服务器830和第二服务器840，其中：

第一服务器830包括测试用例筛选装置820，测试用例筛选装置820为上述实施例六和实施例七所提供的任意一种测试用例筛选装置；

第二服务器840包括测试工具810。

实施例九

基于上述的各实施例，本发明实施例提供一种应用于上述测试用例筛选装置的测试用例筛选方法，如图9所示，该方法应用于测试用例筛选装置，该装置包括源测试用例库901、测试用例筛选装置902和测试工具903，其中，该装置可以通过一个服务器、或两个服务器、或三个服务器来实现；例如，当采用一个服务器时，所述源测试用例库901、测试用例筛选装置902和测试工具903可以位于同一个服务器上；当采用三个服务器时，例如，测试用例筛选装置902位于第一服务器上，而测试工具903位于第二服务器上，源测试用例库902位于第三服务器上；如图9所示，该方法包括第一阶段910、第二阶段920和第三阶段930，其中：

第一阶段910用于获取标准日志；

第二阶段920用于获取测试日志；

第三阶段930用于匹配标准日志和测试日志，判断所述第一测试用例的有效性，其中：

第一阶段910包括步骤S911至S918，具体如下：

步骤S911，测试用例筛选装置902获取与被测程序对应的配置文件；

这里，所述被测程序用于实现某一目标任务，所述配置文件用于描述所述目标任务；

步骤S912，测试用例筛选装置902确定描述所述配置文件的结构体，根据所述结构体确定任务集；

步骤S913，测试用例筛选装置902从运营环境中获取所述任务集的用户请求信息集；

步骤S914，测试用例筛选装置902将所述用户请求信息集发送至所述测试工具；

步骤S915，测试工具903接收测试用例筛选装置820发送的用户请求信息集，调用被测程序对用户请求信息集进行处理，得到标准日志；

步骤S916，测试工具903将所述标准日志发送给测试用例筛选装置902；

步骤S917，测试用例筛选装置902接收所述测试工具输出的标准日志并进行存储；

步骤S918，测试用例筛选装置902读取所述标准日志。

第二阶段920包括步骤S921至S925，具体如下：

步骤S921，测试用例筛选装置902从源测试用例库中获取用于测试所述被测程序的第一测试用例；

步骤S922，测试用例筛选装置902根据所述第一测试用例生成第一测试请求信息；

步骤S923，测试用例筛选装置902将所述第一测试请求信息发送至测试工具930；

步骤S924，测试工具903接收测试用例筛选装置902发送的第一测试请求信息，调用被测程序对用户请求信息集进行处理，得到第一测试日志；

步骤S925，测试工具903将所述第一测试日志发送给测试用例筛选装置902；

第三阶段930，包括步骤S931，具体如下：

步骤S931，根据所述第一测试日志和所述标准日志，判断所述第一测试用例的有效性。

需要说明的是，本实施例中的第二阶段920和第三阶段930是循环的，也就是说，在第三阶段930判断第一测试用例的有效性后；该方法回到第二阶段920，第二阶段920继续从源测试用例库中获取第二测试用例，直到第三阶段930判断第二测试用例的有效性；依此类推，判断源测试用例库中剩余的其它测试用例的有效性，形成针对所述测试程序的目标测试用例库。

在本申请所提供的几个实施例中，应该理解到，所揭露的方法和装置，可以通过其它的方式实现。以上所描述的设备实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，如：多个单元可以结合，或可以进一步进行划分，甚至有一些特征可以忽略，或有些步骤可以不执行。另外，所显示或讨论的各组成部分相互之间的耦合、或直接耦合、或通信连接可以是通过一些接口、设备或单元的间接耦合或通信连接，可以是电性的、或其它形式的。

上述作为分离部件说明的单元可以是、或也可以不是物理上分开的，作为单元显示的部件可以是、或也可以不是物理单元；既可以位于一个地方，也可以分布到多个服务设备上；可以根据实际的需要选择其中的部分或全部单元来实现本实施例方案的目的。

另外，在本发明各实施例中的各功能单元可以全部集成在一个处理单元中，也可以是各单元分别单独作为一个单元，也可以两个或两个以上单元集成在一个单元中；上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：移动存储设备、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

或者，本发明上述集成的单元如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明实施例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机、服务器、或者网络设备等)执行本发明各个实施例所述方法的全部或部分。而前述的存储介质包括：移动存储设备、ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以所述权利要求的保护范围为准。

Claims (15)

1.一种测试用例筛选方法，其特征在于，所述方法包括：

获取与被测程序对应的配置文件；

根据所述配置文件，获取基于用户请求信息得到的标准日志；

从源测试用例库中获取用于测试所述被测程序的第一测试用例；

根据所述第一测试用例生成第一测试请求信息；

将所述第一测试请求信息发送至测试工具，获取从所述测试工具输出的第一测试日志，其中所述测试工具能够调用所述被测程序；

根据所述第一测试日志和所述标准日志，判断所述第一测试用例的有效性。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：

从源测试用例库中获取第二测试用例；

根据所述第二测试用例生成第二测试请求信息；

根据所述第二测试请求信息发送至所述测试工具，并获取从所述测试工具输出的第二测试日志；

根据所述第二测试日志和所述标准日志，判断所述第二测试用例的有效性；

依此类推，判断源测试用例库中剩余的其它测试用例的有效性，形成针对所述测试程序的目标测试用例库。

3.根据权利要求1所述的方法，其特征在于，判断所述第一测试用例的有效性之后，所述方法还包括：

判断所述第一测试用例有效时，将所述第一测试用例存储于针对所述被测程序的目标测试用例库中。

4.根据权利要求1所述的方法，其特征在于，判断所述第一测试用例的有效性之后，所述方法还包括：

判断所述第一测试用例无效时，将所述第一测试用例标记为无效，且不将所述第一测试用例存储于目标测试用例库中。

5.根据权利要求1至4任一项所述的方法，其特征在于，所述根据所述配置文件，获取基于用户请求信息得到的标准日志，包括：

确定描述所述配置文件的结构体，根据所述结构体确定任务集；

从运营环境中获取所述任务集的用户请求信息集；

将所述用户请求信息集发送至所述测试工具；

接收所述测试工具输出的标准日志并存储所述标准日志；

读取所述标准日志。

6.根据权利要求5所述的方法，其特征在于，所述任务集的配置文件与所述被测程序对应的配置文件的结构体一样，参数不同。

7.根据权利要求1至4任一项所述的方法，其特征在于，所述根据所述第一测试日志和所述标准日志，判断所述第一测试用例的有效性，包括：

确定所述第一测试日志中所有呈覆盖状态的第一代码行；

判断所述第一代码行是否位于所述标准日志中呈未覆盖状态的代码行中，如果是，则判断所述第一测试用例无效；否则，判断所述第一测试用例有效。

8.一种测试用例筛选装置，其特征在于，所述装置包括：第一获取单元、第二获取单元、第三获取单元、生成单元、第一发送单元、第四获取单元和判断单元；其中：

所述第一获取单元，用于获取与被测程序对应的配置文件；

所述第二获取单元，用于根据所述配置文件，获取基于用户请求信息得到的标准日志；

所述第三获取单元，用于从源测试用例库中获取用于测试所述被测程序的第一测试用例；

所述生成单元，用于根据所述第一测试用例生成第一测试请求信息；

所述第一发送单元，用于将所述第一测试请求信息发送至测试工具，其中所述测试工具能够调用所述被测程序；

所述第四获取单元，用于获取从所述测试工具输出的第一测试日志；

所述判断单元，用于根据所述第一测试日志和所述标准日志，判断所述第一测试用例的有效性。

9.根据权利要求8所述的装置，其特征在于，所述第三获取单元，还用于从所述源测试用例库中获取第二测试用例；

所述生成单元，还用于根据所述第二测试用例生成第二测试请求信息；

所述第一发送单元，还用于根据所述第二测试请求信息发送至所述测试工具；

所述第四获取单元，还用于获取从所述测试工具输出的第二测试日志；

所述判断单元，还用于根据所述第二测试日志和所述标准日志，判断所述第二测试用例的有效性；

所述第三获取单元、所述发送单元、所述生成单元、所述第四获取单元和所述判断单元，依此类推，实现判断源测试用例库中剩余的其它测试用例的有效性，形成针对所述测试程序的目标测试用例库。

10.根据权利要求8所述的装置，其特征在于，所述装置还包括第一存储单元，用于判断所述第一测试用例有效时，将所述第一测试用例存储于针对所述被测程序的目标测试用例库中。

11.根据权利要求8所述的装置，其特征在于，所述装置还包括标记单元，用于判断所述第一测试用例无效时，将所述第一测试用例标记为无效，且不将所述第一测试用例存储于目标测试用例库中。

12.根据权利要求8至11任一项所述的装置，其特征在于，所述第二获取单元还包括第一确定模块、获取模块、发送模块、接收模块和读取模块，其中：

所述第一确定模块，用于确定描述所述配置文件的结构体，根据所述结构体确定任务集；

所述获取模块，用于从运营环境中获取所述任务集的用户请求信息集；

所述发送模块，用于将所述用户请求信息集发送至所述测试工具；

所述接收模块，用于接收所述测试工具输出的标准日志，并进行存储；

所述读取模块，用于读取所述标准日志。

13.根据权利要求12所述的装置，其特征在于，所述任务集的配置文件与所述被测程序对应的配置文件的结构体一样，参数不同。

14.根据权利要求8至11任一项所述的装置，其特征在于，所述判断单元包括第二确定模块和判断模块，其中：

所述第二确定模块，用于确定所述第一测试日志中所有呈覆盖状态的第一代码行；

所述判断模块，用于判断所述第一代码行是否位于所述标准日志中呈未覆盖状态的代码行中，如果是，判断所述第一测试用例无效；否则，判断所述第一测试用例有效。

15.一种服务器，其特征在于，所述服务器包括上述8至14任一项所述的测试用例筛选装置。