CN101196817A - 测试用例生成方法及*** - Google Patents

Abstract

本发明公开了一种测试用例生成方法，包括维护测试错误产生的原因信息，以及维护测试规格说明信息；匹配所述维护的原因信息和测试规格说明信息，生成测试用例。相应的本发明还提供了一种测试用例生成装置，包括第一维护装置，用于维护测试错误产生的原因信息，以及第二维护装置，用于维护测试规格说明信息；用例生成装置，用于匹配所述维护的原因信息和测试规格说明信息，生成测试用例。根据本发明方案生成的测试用例，能够更佳细节化的对不同产品进行测试，增强测试用例的通用性。

Description

测试用例生成方法及***

技术领域

本发明涉及计算机领域，尤其涉及一种测试用例生成方法及装置。

背景技术

任何一款产品在投入市场前都需要进行测试，而测试过程就需要有测试用例(test case)的参与。测试用例是指为特定目标而开发的一组测试输入、执行条件和预期结果，其目标可以是测试某个程序路径或核实是否满足某个特定的需求。也就是说，测试用例指导了测试的方向、定义了需要测试的范围、需要测试的内容以及预期的正确输出结果。

目前现有技术中存在两种测试方法：黑盒测试和白盒测试，其中黑盒测试(或者称为功能测试，或数据驱动测试)是指根据已知产品的功能设计规格对产品进行测试，以验证产品的每个功能是否符合要求；白盒测试(或者称为结构测试，或逻辑驱动测试)是指根据已知产品的内部工作过程对产品进行测试，以验证产品的每个内部操作是否符合设计规格要求，所有内部成分是否已经过检查。

在黑盒测试过程中，测试在软件的接口处进行，即把测试对象看作一个黑盒子，测试人员不考虑测试对象程序内部的逻辑结构和内部特性，只需依据程序的规格说明书，检查程序的功能是否符合规格说明书要求的功能即可。黑盒测试主要用于发现以下几类错误：

是否有错误或遗漏的功能；

在接口上输入能否正确的被接受、或者能否输出正确的结果；

是否有数据结构错误或外部信息(例如数据文件)访问错误；

性能上是否能够满足要求；

是否有初始化或终止性的错误等等。

在白盒测试过程中，需要对被测软件的细节进行细致的检查，即把测试对象看作一个打开的盒子，测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，以对程序所有逻辑路径进行测试(即通过在不同点检查程序的状态以确定实际状态是否与预期状态一致)。白盒测试主要用于对程序模块进行检查，比如：对程序模块所有独立的执行路径进行至少一遍测试；对所有的逻辑判定(取“真”与取“假”的两种情况)进行至少一遍测试；在循环的边界和运行的界限内，对循环体进行测试；以及测试内部数据结构的有效性等等。

在实际的测试过程中，经常会出现测试结果与预期结果不一致的现象，业界将这些不一致的现象称之为bug。根据bug产生原因的不同，可以将bug划分为测试用例内bug和测试用例外bug。其中测试用例外bug是指在测试过程中，除按照测试用例规定的检查外，有可能因为一些意外情况(比如端口的插拔、特定的温度湿度以及在与某个设备进行互联时等等)，暴露出被测试设备的一些问题，将这些意外情况称之为测试用例外bug。

如图1所示，为现有技术中当前测试对象测试用例的生成过程示意图，下面结合图1，说明现有技术中测试用例的生成过程，如下：

根据规格说明书生成当前测试对象的测试用例，该测试用例包括测试功能和测试内容；

根据上述生成的测试用例对当前测试对象进行测试；

在测试完成后，直接将测试过程中产生的测试用例外bug，添加到该测试对象的测试用例中。

由于现有技术中通常只按照规格说明书来生成测试用例，而没有考虑其他更细节、测试更需要的因素，因此使得测试结果比较粗况，不能满足根据需要使得测试结果更细致化的要求；进一步，由于现有技术将测试过程中产生的测试用例外bug直接应用到该测试对象的测试用例中，因此这种应用只针对该测量对象，而不会对其他的测试产品对象产生贡献。

发明内容

本发明提供一种测试用例生成方法及其***，以根据生成的测试用例能够更加细节化的对不同产品进行测试，增强测试用例的通用性。

本发明提供了一种测试用例生成方法，包括维护测试错误产生的原因信息，以及维护测试规格说明信息；匹配所述维护的原因信息和测试规格说明信息，生成测试用例。

其中所述维护测试错误产生的原因信息具体包括：在测试得到的测试错误产生的原因信息，不在维护的测试错误产生的原因信息之内时，将所述得到的测试错误输出；维护外界新输入的测试错误产生的原因信息，所述新输入的测试错误产生的原因信息为分析所述输出的测试错误得到的。

其中所述匹配原因信息和测试规格说明信息，生成测试用例具体包括：将至少一项原因信息分别与各项测试规格说明信息进行匹配；获取匹配得到的各个匹配项作为测试用例。

其中所述匹配原因信息和测试规格说明信息，生成测试用例具体包括针对至少一项原因信息执行：根据该原因信息中包含的关键字，将该原因信息分别与包含所述关键字的各项测试规格说明信息进行匹配；获取针对所述至少一项原因信息执行所述匹配处理后得到的各个匹配项，作为测试用例。

其中所述匹配原因信息和测试规格说明信息，生成测试用例具体包括针对至少一项原因信息执行：根据该原因信息中包含的比例参数，在所有测试规格说明信息项中选取对应比例的测试规格说明信息项；以及将该原因信息分别与所述选取出的各项测试规格说明信息进行匹配；获取针对所述至少一项原因信息执行所述匹配处理后得到的各个匹配项，作为测试用例。

其中所述匹配原因信息和测试规格说明信息，生成测试用例具体包括：在测试规格说明信息中随机选取一项测试规格说明信息；以及将至少一项原因信息分别与所述选取的测试规格说明信息项进行匹配；获取匹配得到的各个匹配项作为测试用例。

本发明还提供了一种测试用例生成***，包括第一维护装置，用于维护测试错误产生的原因信息，以及第二维护装置，用于维护测试规格说明信息；用例生成装置，用于匹配所述维护的原因信息和测试规格说明信息，生成测试用例。

较佳地，第一维护装置包括：用于维护预先设置的测试错误产生的原因信息的单元。

较佳地，第一维护装置还包括：用于判断测试得到的测试错误产生的原因信息，是否在预先设置的测试错误产生的原因信息之内的单元；用于在判断单元的判断结果为否时，将所述得到的测试错误输出的单元；用于维护新输入的测试错误产生的原因信息的单元，所述新输入的测试错误产生的原因信息为分析所述输出的测试错误得到的。

较佳地，所述用例生成装置包括：用于将至少一项原因信息分别与各项测试规格说明信息进行匹配的单元；用于获取匹配得到的各个匹配项作为测试用例的单元。

较佳地，所述用例生成装置包括：用于根据一个原因信息中包含的关键字，将该原因信息分别与包含所述关键字的各项测试规格说明信息进行匹配的单元；用于获取针对至少一项原因信息执行所述匹配处理后得到的各个匹配项，作为测试用例的单元。

较佳地，所述用例生成装置包括：用于根据一个原因信息中包含的比例参数，在所有测试规格说明信息项中选取对应比例的测试规格说明信息项的单元；用于将该原因信息分别与所述选取出的各项测试规格说明信息进行匹配的单元；用于获取针对至少一项原因信息执行所述匹配处理后得到的各个匹配项，作为测试用例的单元。

较佳地，所述用例生成装置包括：用于在测试规格说明信息中随机选取一项测试规格说明信息的单元；用于将至少一项原因信息分别与所述选取的测试规格说明信息项进行匹配的单元；用于获取匹配得到的各个匹配项作为测试用例的单元。

本发明实施例提出的测试用例生成方案，通过维护测试错误(即测试得到的bug)产生的原因信息，将维护的测试错误产生的原因信息和测试规格说明信息进行匹配，生成测试用例，可以使得生成的测试用例能够更佳细节化的对不同产品进行测试，增强了测试准确度及其测试用例的通用性。

附图说明

图1为现有技术中当前测试对象测试用例生成的结构框架图；

图2为本发明实施例中测试用例生成方法的流程图；

图3为本发明实施例中测试用例生成***的结构框架图；

图4为本发明实施例测试用例生成方法在本发明测试用例生成***中的实施过程示意图。

具体实施方式

本发明实施例的设计思想是：维护bug产生的原因信息，通过匹配维护的原因信息和测试规格说明信息，生成测试用例，以提高测试用例的测试覆盖率，并更佳细节、准确的对不同产品进行测试。

本发明实施例较佳的适用于黑盒测试的测试用例设计，并且适用于一切具有共性的产品或产品线。

下面对本发明技术方案的实现原理、具体实施方式及其对应能够达到的有益效果进行详细的阐述。

参阅图2所示，为本发明实施例中测试用例生成方法的流程图，其中处理过程如下：

步骤1，维护测试错误产生的原因信息；

步骤2，维护测试规格说明信息；

步骤3，匹配上述维护的测试错误产生的原因信息和测试规格说明信息，生成对应的测试用例。

参阅图3所示，为本发明实施例中测试用例生成***的结构框架图，包括第一维护装置10，用于维护测试错误产生的原因信息，第二维护装置20，用于维护测试规格说明信息；用例生成装置30，用于匹配第一维护装置10维护的原因信息和第二维护装置20维护的测试规格说明信息，生成测试用例。

其中测试用例生成***可以通过客户端/服务器(C-S，Client/Server)架构软件来实现，如图4所示，为本发明实施例测试用例生成方法在本发明测试用例生成***中的实施过程示意图，图4中示出的bug产生的原因信息维护装置即为上述的第一维护装置，此外上述的第二维护装置可以置于用例生成装置中，也可以单独设置，图4中以将第二维护装置置于用例生成装置中为例来说明，因此第二维护装置在该图中未示出。其中用例生成装置可以置于客户端，即可以将用例生成装置安装在各个测试工程师的工作PC上，测试工程师通过在PC上运行用例生成装置，该运行的用例生成装置就会自动将bug产生的原因信息维护装置中维护的原因信息下载，并与测试规格说明信息进行对应匹配，来生成用于对产品进行测试的测试用例，如果第二维护装置单独设置，则还要从第二维护装置中下载测试规格说明信息。

其中bug产生的原因信息维护装置维护的原因信息包括在测试之前预先设置的bug产生原因信息，进而还可以包括从外界新接收的bug产生原因信息，此外还可以为在测试过程中测试得到的bug不在预先设置的原因信息之列时，将测试得到的bug输出，由外界测试工程师根据输出的bug分析得到的新的bug产生原因信息。由此可见，随着测试的不断进行，维护的bug产生原因信息在不断增加，从而使得生成用于对后续产品进行测试的测试用例覆盖面越来越大，对产品的测试准确度越来越高。

下面详细阐述bug产生的原因信息维护装置的具体工作过程：

本装置内部可以预先维护一个“TestClear”数据结构，根据测试工程师的人为经验，可以预先在这个数据结构中写入各类常见的bug产生原因信息，即在程序首次投入使用前，在“TestClear”数据结构中已经定义好了若干常见的bug产生原因信息。例如，TestClear中已经写入的bug产生原因信息可以如下表1所示：

表1：TestClear中已经写入的bug产生原因信息表

物理端口类型
	CPU与内存
输入报文条件
	逻辑接口属性
路由属性
	与设置顺序相关的操作过程
功能使用限制专项
	与其他模块的关系
极限值因素
	性能因素(时间/CPU、内存利用率)
与其他厂商的互通性
	资源竞争与共享
特殊客户的特殊需求
	异常操作与异常数据
既插既用性

在对产品进行测试的过程中，该装置导入测试产生的全部Bug，如果一个bug的产生原因在上述列表之列，则将该bug归类到“用例内bug”；如果一个bug的产生原因不在上述列表之列，则将该bug归类到“用例外bug”：

将统计出的“用例外bug”，按照严重程度、出现的频率等指标进行优先级排队，并将排队后的结果呈现给测试工程师。

测试工程师可以根据呈现的结果信息，对各个“用例外bug”进行分析，总结出共性原因信息，形成新的bug产生原因信息，并将形成的新原因信息添加到上述TestClear数据结构中；其中对于无法整理出共性原因信息的bug，也可以将之分别添加到上述TestClear数据结构中。

后续可以参照添加了新原因信息后的TestClear条目，和产品规格说明书信息，生成新的测试用例，用于对下一产品进行测试，因此随着测试的不断进行，由于TestClear条目越来越多，因此生成的测试用例越来越详细，对后续产品的测试就越来越准确。

其中对bug产生的原因信息，可以分为以下几类：

1、一定路径的、复杂的、反复操作后，出现功能失效

定义：这种特定的操作可能是不断添加删除的过程，或者是命令的不同参数直接的切换，又或者是关联功能的变化。这些操作变化的过程，有可能导致某个命令输入后无效，甚至带来交换机的异常死机。

2、某个功能在与其他功能关联使用时出现问题

定义：多个功能同时使用时，因为共享CPU、内存、介质而产生资源的争抢或者共用，而产生问题。

3、端口类型覆盖率不足

定义：没有覆盖被测试产品的全部物理端口类型和逻辑端口类型。

4、结果判断不足

定义：对某个测试过程的结果判断上，存在片面、失真的问题，比如在一定温度条件下报文能够转发，却没有判断报文转发的速率或者是转发出来的报文内容。

5、输入报文的覆盖率不足

定义：没有考虑到可能的数据通信产品的各种类型的输入报文。

6、CLI未达到全部的覆盖

定义：没有覆盖到目前已经实现的全部命令。

7、指标未达到全部的覆盖

定义：未满足规格说明书。

本装置还可以将添加新的原因信息后的TestClear条目信息，变换成以.jpg、.xls、.csv、.txt、.xml等形式的文件，输出到中心服务器。

除了使用上述给出的TestClear数据结构之外，本发明实施例还可以使用其他数据结构来承载各类bug产生的原因信息。

下面再详细阐述用例生成装置的具体工作过程：

该装置可以与bug产生的原因信息维护装置交换信息，将bug产生的原因信息维护装置处理后的TestClear条目信息作为自身的输入，与测试规格说明书一起，匹配出用于下一产品测试的测试用例。

其中用于维护测试规格说明信息的第二维护装置可以主动接收外界输入的测试规格说明信息，也可以使用导入.xls文件的形式，从一个文件中导入测试规格说明信息，还可以从存储有测试规格说明信息的服务器中下载测试规格说明信息。

用例生成装置可以自动从bug产生的原因信息维护装置中下载最新的TestClear条目文件，选择TestClear条目中的对应条目项，去匹配测试规格说明信息中的对应条目项，以生成满足新产品测试要求的测试用例。

其中基于最新的TestClear条目和测试规格说明信息，可以采用下述的各种方式来生成新的测试用例：

方式一：将至少一项TestClear条目信息分别与各项测试规格说明信息进行匹配；获取匹配得到的各个匹配项作为测试用例。即强制要求某些项TestClear条目必须分别与任何一项测试规格说明信息进行匹配，这里可将这些项TestClear条目定义为“S级”条目。比如说测试规格说明信息有5项，TestClear条目中存在3项“S级”条目，那么根据这种方式可以匹配出5×3＝15项，进而可以将匹配出的这15项作为新生成的测试用例。

方式二：针对至少一项TestClear条目信息分别执行：根据该TestClear条目信息中包含的关键字，将该TestClear条目信息分别与包含所述关键字的各项测试规格说明信息进行匹配；获取针对至少一项原因信息执行上述匹配处理后得到的各个匹配项，作为测试用例。即根据某些TestClear条目中包含的“keyword”信息，只能将该些TestClear条目和包含有对应“key word”的某些测试规格说明信息进行匹配，这里可以将该些TestClear条目定义为“L级”条目。

例如：以TestClear条目为“不同类型的CPU处理能力”为例，该条目在处理大数据量的时候表现尤其明显，对整个设备的性能带来很多影响。于是，可以定义该条目中的关键字包括：key1＝性能，key2＝率(指比率、概率等程度描述)，key3＝程度。当测试规格说明信息描述到这些关键字时，就会自动被判断为需要与“不同类型的CPU处理能力”项匹配。

方式三：针对至少一项TestClear条目信息执行：根据该TestClear条目信息中包含的比例参数，在所有测试规格说明信息项中选取对应比例的测试规格说明信息项；以及将该TestClear条目信息分别与选取出的各项测试规格说明信息进行匹配；获取针对上述至少一项TestClear条目信息执行匹配处理后得到的各个匹配项，作为测试用例。即某些项TestClear条目中会包含一个比例参数信息，根据该比例参数，用例生成装置会在所有测试规格说明信息项中选取对应比例的测试规格说明信息项，分别和包含该比例参数的TestClear条目进行匹配，这里可以将该些TestClear条目定义为“R级”条目。

例如，以TestClear条目为“温度”为例，设置该条目中包含的比例参数为5％，就是需要从全部的测试规格说明信息中选取5％的内容(比如全部的测试规格说明信息为20条，则只需选择一条就满足条件)，对之在不同的温度环境下进行测试。

方式四：在测试规格说明信息中随机选取一项测试规格说明信息，以及将至少一项TestClear条目信息分别与上述选取的测试规格说明信息项进行匹配；获取匹配得到的各个匹配项作为测试用例。这种方式比较适用于特殊用户的需求。

上述四种匹配方式在具体测试过程中，可以选取其中一种或几种进行组合使用。

下面将列举一个实施例来对本发明测试用例生成方案进行更佳详尽的阐述。该实施例以对一个增加了QINQ功能的软件项目进行测试为例，来说明按照本发明方案生成测试用例的过程，其中QINQ功能主要是为拓展VLAN的数量空间而产生的，它通过在原有的802.1Q报文的基础上又增加一层802.1Q标签来实现，使的VLAN的数量增加到4K×4K个。

该软件项目的测试规格说明书信息如下表2所示：

支持uplink口的配置与删除
	支持自定义供应商tpid值
支持用户tag优先级的复制
	配置了qinq的情况下吞吐率需要达到100％

按照现有技术的测试用例生成方案，仅需根据上述这个测试规格说明书信息，逐条的对QINQ功能本身进行测试用例设计，完成测试后输出新版本的软件。这样，仅有在QINQ功能本身单独使用的情况下，该功能才能够得到保证。

按照本发明测试用例生成方案，假如在上一次OSPF测试项目中发现两个用例以外bug，一个是OSPF与RIP共用时，产生互相的影响，这个称之为bugA；另外一个bug，是在OSPF协议运行时，与其他厂商的设备之间出现不能互通的情况，这个称之为bugB。

Bug产生的原因信息维护装置在OSPF测试完成后，将测试得到的全部bug导入，逐个进行分类，发现bugA和bugB无法整理到预先已经定义的TestClear条目中，于是将这两个bug分类到“用例外bug”，并将统计得到这两个“用例外bug”通知给测试工程师。

测试工程师收到通知后，进行分析处理，发现这两个bug的引入是一种新的条件和新的环境，于是分别进行定义原因信息，定义索引值index分别为7、8，具体定义如下：

7——bugA——与路由协议的关系

8——bugB——与其他厂商的互联互通

这样，TestClear中新增的原因条目为：

(1)测试与其他路由协议的关系，并设置该条目为L级别，且该条目中定义关键字key1＝路由、key2＝IP报文转发、key3＝承载；

(2)是否支持与其他厂商的互联互通，并设置该条目为O级别。

上述整理后的结果将直接作用于生成对新的产品、或新的项目进行测试的测试用例的产生过程；这样可以实现通过不断的对测试用例外bug的分析与整理，将多次反复出现的用例外Bug作用于对后续产品、项目测试用例的生成，从而大大提高了测试用例的覆盖率。

假定预先已经在TestClear数据结构里边设置了以下几个条目：

条目	级别	关键字	比例参数
				针对不同的模块类型	S级
包括不同的端口类型	L级	key1＝配置，key＝2添加，key3＝删除
				考虑不同CPU的类型因素	L级	key1＝性能，key2＝率，key3＝程度
测试变化的温度范围	R级		10％
				确认满足了特殊用户要求	O级

用例生成装置对该软件的测试规格说明书信息进行处理，在TestClear数据结构中有了上述7、8这两个新增条目后，与测试规格说明书信息结合，生成测试用例的过程具体如下：

第一步，根据原始规格说明书信息和新增条目，生成测试用例如下：

支持uplink口的配置与删除
	支持自定义供应商tpid值的配置
通道承载IP报文
	配置了qinq的情况下吞吐率需要达到100％

第二步，将新增条目后的TestClear(即上述表1)和上述第一步中生成的测试用例进行匹配。

其中，首先使用原始TestClear中的S级项目(针对不同的模块类型)，分别和上述第一步中生成的各条测试用例进行匹配，得到如下测试用例：

支持uplink口的配置与删除，针对不同的模块类型

支持自定义供应商tpid值，针对不同的模块类型
	支持用户tag优先级的复制，针对不同的模块类型
配置了qinq的情况下吞吐率需要达到100％，针对不同的模块类型

再次，使用原始TestClear中的L级项目(包括不同的端口类型)，和上述第一步中生成的测试用例中的对应项目进行匹配，得到如下测试用例：

支持uplink口的配置与删除，包括不同类型的端口
	支持自定义供应商tpid值的配置，包括不同类型的端口

使用原始TestClear中的L级项目(考虑不同CPU的类型因素)，和上述第一步中生成的测试用例中的对应项目进行匹配，得到如下测试用例：

配置了qinq的情况下吞吐率需要达到100％，考虑到不同CPU的类型因素

以及，使用原始TestClear中的R级项目(测试变化的温度范围)，和上述第一步中生成的测试用例中的对应项目进行匹配，得到如下测试用例：

支持uplink口的配置与删除，测试变化的温度范围

最后，使用原始TestClear中的O(确认满足特殊用户要求)，和上述第一步中生成的测试用例中的对应项目进行匹配，得到如下测试用例：

QINQ的功能，确认满足特殊用户要求

第三步，使用上述TestClear中新增的原因条目(与路由协议的关系)——L级，和上述第一步中生成的测试用例中的对应项目进行匹配，得到如下测试用例：

通道承载IP报文，与路由协议的关系

使用上述Testclear中新增的原因条目(与其他厂商的互联互通)——O级，和上述第一步中生成的测试用例中的对应项目进行匹配，得到如下测试用例：

QINQ的功能，是否支持与其他厂商的互联互通

将上述各步中得到的测试用例汇总，得到最终的测试用例如下：

	备注说明
		支持uplink口的配置与删除	根据规格说明书生成
支持自定义供应商tpid值的配置
		通道承载IP报文
配置了qinq的情况下吞吐率需要达到100％
		通道承载IP报文，与路由协议的关系	根据由其他模块的bug整理，而新产生的条目匹配
QINQ的功能，是否支持与其他厂商的互联互通
		支持uplink口的配置与删除，针对不同的模块类型	根据原有条目匹配
支持自定义供应商tpid值，针对不同的模块类型
		支持用户tag优先级的复制，针对不同的模块类型
配置了qinq的情况下吞吐率需要达到100％，针对不同的模块类型
		支持uplink口的配置与删除，包括不同类型的端口
支持自定义供应商tpid值的配置，包括不同类型的端口
	配置了qinq的情况下吞吐率需要达到100％，考虑到不同CPU的类型因素
支持uplink口的配置与删除，测试变化的温度范围
	QINQ的功能，确认满足特殊用户要求

用例生成装置进而可以将上面这个case表格最终输出给测试工程师，作为测试的指导和依据。

从上面这个简单的例子可以看出，基于本发明提出的测试用例生成方案来生成测试用例，相比现有技术仅基于最初的规格说明书来生成测试用例，生成的数量规模上可以扩展三倍。并且，相比现有技术仅基于最初的规格说明书来生成测试用例，基于本发明方案生成的测试用例将更加符合实际网络环境的测试，可以实现对多协议、多报文类型、多操作方式的测试，从而增强了测试用例对不同产品的通用性。

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

Claims (16)

1.一种测试用例生成方法，其特征在于，包括：

维护测试错误产生的原因信息，以及

维护测试规格说明信息；

匹配所述维护的原因信息和测试规格说明信息，生成测试用例。

2.如权利要求1所述的方法，其特征在于，所述维护测试错误产生的原因信息具体包括：维护预先设置的测试错误产生的原因信息。

3.如权利要求2所述的方法，其特征在于，所述维护测试错误产生的原因信息具体还包括：维护在测试过程中，新输入的测试错误产生的原因信息。

4.如权利要求3所述的方法，其特征在于，所述维护测试错误产生的原因信息具体还包括：

在测试得到的测试错误产生的原因信息，不在维护的测试错误产生的原因信息之内时，将所述得到的测试错误输出；

维护新输入的测试错误产生的原因信息，所述新输入的测试错误产生的原因信息为分析所述输出的测试错误得到的。

5.如权利要求4所述的方法，其特征在于，将所述得到的测试错误输出具体包括：

将所述得到的测试错误按照预设规则进行排序；以及

将排序后的测试错误输出。

6.如权利要求1所述的方法，其特征在于，所述匹配原因信息和测试规格说明信息，生成测试用例具体包括：

将至少一项原因信息分别与各项测试规格说明信息进行匹配；

获取匹配得到的各个匹配项作为测试用例。

7.如权利要求1所述的方法，其特征在于，所述匹配原因信息和测试规格说明信息，生成测试用例具体包括针对至少一项原因信息执行：

根据该原因信息中包含的关键字，将该原因信息分别与包含所述关键字的各项测试规格说明信息进行匹配；以及

获取针对所述至少一项原因信息执行所述匹配处理后得到的各个匹配项，作为测试用例。

8.如权利要求1所述的方法，其特征在于，所述匹配原因信息和测试规格说明信息，生成测试用例具体包括针对至少一项原因信息执行：

根据该原因信息中包含的比例参数，在所有测试规格说明信息项中选取对应比例的测试规格说明信息项；

将该原因信息分别与所述选取出的各项测试规格说明信息进行匹配；以及

获取针对所述至少一项原因信息执行所述匹配处理后得到的各个匹配项，作为测试用例。

9.如权利要求1所述的方法，其特征在于，所述匹配原因信息和测试规格说明信息，生成测试用例具体包括：

在测试规格说明信息中随机选取一项测试规格说明信息；

将至少一项原因信息分别与所述选取的测试规格说明信息项进行匹配；以及

获取匹配得到的各个匹配项作为测试用例。

10.一种测试用例生成***，其特征在于，包括：

第一维护装置，用于维护测试错误产生的原因信息，以及

第二维护装置，用于维护测试规格说明信息；

用例生成装置，用于匹配所述维护的原因信息和测试规格说明信息，生成测试用例。

11.如权利要求10所述的***，其特征在于，所述第一维护装置包括：用于维护预先设置的测试错误产生的原因信息的单元。

12.如权利要求11所述的***，其特征在于，所述第一维护装置还包括：

用于判断测试得到的测试错误产生的原因信息，是否在预先设置的测试错误产生的原因信息之内的单元；

用于在判断单元的判断结果为否时，将所述得到的测试错误输出的单元；

用于维护新输入的测试错误产生的原因信息的单元，所述新输入的测试错误产生的原因信息为分析所述输出的测试错误得到的。

13.如权利要求10所述的***，其特征在于，所述用例生成装置包括：

用于将至少一项原因信息分别与各项测试规格说明信息进行匹配的单元；

用于获取匹配得到的各个匹配项作为测试用例的单元。

14.如权利要求10所述的***，其特征在于，所述用例生成装置包括：

用于根据一个原因信息中包含的关键字，将该原因信息分别与包含所述关键字的各项测试规格说明信息进行匹配的单元；

用于获取针对至少一项原因信息执行所述匹配处理后得到的各个匹配项，作为测试用例的单元。

15.如权利要求10所述的***，其特征在于，所述用例生成装置包括：

用于根据一个原因信息中包含的比例参数，在所有测试规格说明信息项中选取对应比例的测试规格说明信息项的单元；

用于将该原因信息分别与所述选取出的各项测试规格说明信息进行匹配的单元；

用于获取针对至少一项原因信息执行所述匹配处理后得到的各个匹配项，作为测试用例的单元。

16.如权利要求10所述的***，其特征在于，所述用例生成装置包括：

用于在测试规格说明信息中随机选取一项测试规格说明信息的单元；

用于将至少一项原因信息分别与所述选取的测试规格说明信息项进行匹配的单元；

用于获取匹配得到的各个匹配项作为测试用例的单元。

Images