CN101174240A

CN101174240A - 一种软件测试管理方法及其***

Info

Publication number: CN101174240A
Application number: CNA200610138061XA
Authority: CN
Inventors: 成洁; 朱勃豪; 黄芬
Original assignee: BEIJING BEIYANG ELECTRONIC TECHNOLOGY Co Ltd; Sunplus Technology Co Ltd
Current assignee: BEIJING SUNPLUS-EHUE TECHNOLOGY CO., LTD.; Sunplus Technology Co Ltd
Priority date: 2006-11-03
Filing date: 2006-11-03
Publication date: 2008-05-07
Anticipated expiration: 2026-11-03
Also published as: CN101174240B

Abstract

本发明公开了一种软件测试管理方法，该方法包括：A.根据输入的配置项，获取测试程序文件或已有文本用例；B.根据所述配置项和所述测试程序文件或已有文本用例，获取测试用例。该方法能够根据用户需要，从已有的测试程序文件或已有文本用例中提取所需的测试用例，并存入测试用例库中，从而方便的实现了测试用例的管理，提高了测试人员的工作效率。本发明还提供了一种软件测试管理***，该***可以较为方便、灵活的实现对测试用例的管理，提高测试人员工作效率。

Description

一种软件测试管理方法及其***

技术领域

本发明涉及软件测试技术领域，具体涉及一种软件测试管理方法及其***。

背景技术

软件测试是软件开发完成后，对软件的正确性、可靠性和稳定性进行验证的环节。在现有的API函数级别的测试流程中，测试设计人员首先要向设计编写API函数的程序员了解API函数的功能，再根据API函数的功能编写测试用例方案，之后测试执行人员根据这个测试用例方案在诸如汇编、C、C++、VC、JAVA等编译环境中编写对应的测试程序，最后根据测试程序的执行结果判断被测API函数是否存在缺陷。可见，现有的测试过程是一个先进行测试用例方案的设计，再根据测试用例方案编写对应测试程序的过程。针对不同的测试用例方案，要求测试执行人员重新编写对应的测试程序。如果测试执行人员在测试过程中增加或修改了测试程序，则需要测试设计人员根据测试程序的修改，在测试用例方案对应的地方增加或修改相应的测试用例描述。对应过程比较耗时，不能从测试程序中提取出测试用例，作为测试用例方案，影响了测试执行效率。在有些情况下，有些测试用例还可以被重用，因此希望将编写好的测试用例提取并保存下来，当需要时可以获取并使用，用以提高测试软件的效率。

DOXYGEN工具提供了一种从源文件注释中提取出对应文档的功能，可以生成XML，HTML，RTF，PDF等文档格式。并可以根据配置提取出源文件中的数据结构及相应的关系图。提取出的文档可以作为测试用例方案。但此工具并不能提供根据用户的配置灵活提取测试用例的功能，也不具备测试用例管理的功能。

为了实现对测试用例的管理，申请号为CN200410086041.3的中国专利申请公开了一种基于脚本解释工具的自动化软件测试***，用来对测试案例进行有效的管理，解决测试案例重用问题。该专利申请的测试案例类似于上述测试用例。该专利申请采用测试总控单元通过人机界面接收用户的操作指令信息，并控制测试案例处理单元从测试案例库中读取测试案例的初始数据，经用户的编辑操作之后，以文本的形式保存测试案例脚本，并将其路径保存在测试案例库中。该专利申请能够自动根据用户指令从测试案例库中提取测试案例，并生成测试案例脚本。但是其缺点在于，该***不能从测试程序文件中直接提取测试案例，所提取的测试案例是用户事先编写完成并存放在测试案例库中的，因此需要向测试案例库添加测试案例时，需要用户先编写好测试案例，再存入测试案例库，该新的测试案例才能够被使用。因此，对软件测试管理***进行管理时，工作效率不高，且不能够从测试程序中直接提取测试用例。

可见，如何对测试用例既进行灵活的提取，又进行方便的管理，是一个亟待解决的问题。

发明内容

有鉴于此，本发明的第一个主要目的在于提供一种软件测试管理方法，可以方便、灵活的获取测试用例，实现对测试用例的管理，提高测试人员测试软件的工作效率。

本发明第二个主要目的在于提供一种软件测试管理***，可以方便、灵活的获取测试用例，实现对测试用例的管理，提高测试人员测试软件的工作效率。

为达到上述发明目的的第一个方面，本发明提供了一种软件测试管理方法，该方法包括：

A、根据输入的配置项，获取测试程序文件或已有文本用例；

B、根据所述配置项和所述测试程序文件或已有文本用例，获取测试用例。

该方法进一步包括：C、将所述步骤B获取的测试用例导入数据库。

当根据测试程序文件提取测试用例时，所述配置项为提取测试用例配置项；

所述步骤A为：根据输入的提取测试用例配置项，生成配置文件；并根据该配置文件获取测试程序文件；

所述步骤B为：根据所述配置文件和所述测试程序文件，获取测试用例。

所述步骤C进一步包括，将根据所述配置文件获取的所述测试用例的项目信息导入所述数据库。

当采用数据库测试用例生成测试框架时，该方法进一步包括：

D、根据输入的生成测试框架配置项，生成第二配置文件；根据所述生成测试框架配置项，从所述数据库中获取符合生成测试框架配置项要求的测试用例及其项目信息，并形成测试用例文件；

E、根据所述第二配置文件和所述测试用例文件，生成测试程序框架。

当根据已有文本用例生成测试程序框架时，所述配置项为生成测试框架配置项；

所述步骤A为：根据输入的所述生成测试框架配置项，生成第二配置文件；并根据所述生成测试框架配置项获取已有文本用例；

所述步骤B为：根据所述生成测试框架配置项和所述已有文本用例，获取测试用例及其项目信息；

该方法进一步包括：

根据所述测试用例及其项目信息形成测试用例文件；

根据所述第二配置文件和所述测试用例文件，生成测试程序框架。

较佳的，本发明的软件测试管理方法进一步包括：根据输入的管理信息，对所述数据库中的测试用例进行管理。

为实现上述发明目的的第二个方面，本发明提供了一种软件测试管理***，该***包括：图形用户界面GUI、管理模块和文件导入模块；

所述GUI，用于将用户输入的配置项输出给管理模块；

所述管理模块，用于根据所述配置项获取测试程序文件或已有文本用例；再根据所述配置文件和所述测试程序文件或已有文本用例，获取测试用例；

所述文件导入模块，用于将所述管理模块选取的测试程序文件或已有文本用例，通过所述GUI导入所述管理模块。

较佳的，该***进一步包括数据库，用于存储从所述管理模块获取的测试用例。

所述管理模块包括提取测试用例模块，用于根据提取测试用例配置项生成配置文件，并根据该配置文件获取测试程序文件；再根据所述配置文件和所述测试程序文件，获取测试用例；根据所述配置文件获取项目信息；将获取的所述测试用例和所述项目信息导入到数据库。

所述管理模块进一步包括数据库管理模块，用于根据用户通过GUI输入的管理信息，对所述数据库中的信息进行管理；还用于将所述管理模块根据所述配置文件和所述已有文本用例获取的测试用例及其项目信息导入所述数据库。

该***进一步包括文件生成模块；所述管理模块进一步包括生成测试框架模块；

所述生成测试框架模块，用于根据用户输入的生成测试框架配置项生成第二配置文件；根据所述生成测试框架配置项从所述数据库获取测试用例及其项目信息，形成测试用例文件；将所述第二配置文件和所述测试用例文件输出给所述文件生成模块；

所述文件生成模块，用于根据所述第二配置文件和所述测试用例文件生成测试框架。

与现有技术相比，本发明所提供的软件测试管理方法及其***，可以根据用户输入的提取测试用例配置项，从已有的测试程序文件或已有文本用例中提取所需的测试用例。此时，可以将测试用例存入测试用例数据库中，从而方便的实现了测试用例的添加，提高了测试人员的工作效率；其次，用户还可以通过GUI操作，对测试用例数据库中的测试用例进行修改，删除，查找等操作，从而实现了对测试用例的管理，便于更为有效的利用测试用例数据库中的测试用例。另外，本发明根据用户输入的生成测试框架配置项，从测试用例数据库或者已有文本用例中获取所需测试用例，生成测试用例与测试函数一一对应的测试程序框架，测试人员只需在测试程序框架的测试程序文件中填写测试函数即可完成测试程序的编写，且生成的测试程序文件分类存放于不同目录下，方便测试人员查找和编写程序使用。

附图说明

图1为本发明软件测试管理***的***组成框图。

图2为本发明提取测试用例方法流程图。

图3为图2步骤207将文件集合中的测试用例写入XML文件的方法流程图。

图4为本发明读取配置文件的方法流程图。

图5为本发明生成测试程序框架的实施例一的方法流程图。

图6本发发明生成测试程序框架的实施例二的方法流程图。

图7为本发明测试程序框架写入源文件的方法流程图

具体实施方式

为使本发明的目的、技术方案和优点更加清楚明白，下面结合实施例和附图，对本发明进一步详细说明。

本发明的核心思想为软件测试管理***根据输入的配置项，获取测试程序文件或已有文本用例；并根据该配置项内容和获取的测试程序文件或已有文本用例，获取测试用例。

图1为本发明软件测试管理***的***组成框图。如图1所示，该软件测试管理***包括文件导入模块110、图形用户界面(GUI)120、管理模块130、测试用例数据库140和文件生成模块150。

其中，文件导入模块110，用于向GUI120输入待提取测试程序文件或者已有文本用例。其中，待提取测试程序文件是已经编写好的测试程序文件，该待提取测试程序文件根据项目名，测试类别分别被保存在不同的目录下。测试程序文件的内容包括以注释形式存在的测试ID、测试目的、测试描述、预期结果和测试时间等测试用例内容，以及对应于该测试用例的测试函数。一个测试程序文件可能包含一个或一个以上的测试用例；其中，已有文本用例为文本形式的测试用例。

GUI120，用于向用户提供操作界面。该GUI包括输入界面121和输出界面122。软件测试管理***通过输入界面121获取文件导入模块110中的待提取测试程序文件或者已有文本用例；用户通过该输入界面121输入提取测试用例配置项给管理模块130。该提取测试用例配置项是对所要提取的测试用例的条件限定。用户通过输出界面122输入生成测试框架配置项给管理模块130。该生成测试框架配置项是对所要生成测试框架内容的条件限定。

文件生成模块150，用于根据从管理模块130获取的配置文件和测试用例生成测试框架配置项，或根据从管理模块130获取的测试用例，生成新文本用例。

管理模块130，包括提取测试用例模块131，用于根据上述用户输入的提取测试用例配置项对待提取测试程序文件进行提取测试用例，并将提取的测试用例导入测试用例数据库140中。

管理模块130还包括数据库管理模块132，用于将输入界面121接收的已有文本用例导入到测试用例数据库140中；该数据库管理模块132可以对测试用例数据库140中的测试用例进行增加、删除、修改和查找的管理操作；此外，该模块根据用户在输出界面122输入的生成文本用例配置项，从测试用例数据库140中获取测试用例，并在文件生成模块150中生成新文本用例，并进行浏览打印。

管理模块130还包括生成测试框架模块133，用于根据用户在输出界面122输入的生成测试框架配置项从测试用例数据库140中获取测试用例，并把根据该生成测试框架配置项生成的配置文件和根据该生成测试框架配置项获取的测试用例通过输出界面122输出给文件生成模块150。

测试用例数据库140，用于存储测试用例。如果直接采用管理模块130获取的已有文本用例中的测试用例生成测试程序框架，则该软件测试管理***也可以不包括测试用例数据库140。

该软件测试管理***中，GUI120为管理模块130和文件导入模块110之间、管理模块130和文件生成模块150之间提供一个信息传输接口。管理模块130也可以直接与文件导入模块110和文件生成模块150相连，直接从文件导入模块110获取待提取测试程序文件或者已有文本用例，以及直接向文件生成模块输出用于生成测试程序框架的测试用例及其相关信息。

本发明的软件测试管理***，将从测试程序文件提取的测试用例存储在测试用例数据库140中。为了方便查找和管理测试用例，测试用例数据库140中还存储有与测试用例相关的项目信息。该项目信息来自用户输入的提取测试用例配置项。以下提取测试用例方法实施例中，提取并存入测试用例数据库的不仅有测试用例还有其项目信息。

图2为本发明提取测试用例方法流程图。该方法的具体步骤如下：

步骤201，用户通过输入界面121输入提取测试用例配置项。

本步骤中，用户需要输入的提取测试用例配置项包括以下几项内容：

项目名和项目成员：这两项内容由用户输入，用以在将测试用例写入测试用例数据库时，作为写入的信息。

项目时间：表示本次提取测试用例的时间。例如2006.10.24。

项目描述：表示对本次提取测试用例目的的描述。例如：该项目用于演示(This project is used for demo)。

测试分类：表示本次需要提取何种测试分类的测试用例。该测试类别包括功能测试，性能测试，压力测试、兼容性测试、一致性测试等测试分类。每种分类的测试程序文件都存储在对应的文件夹中。本实施例采用文件名来区分待提取测试程序文件的测试类型。例如功能测试的文件名以F作为前缀，性能测试的文件名以P作为前缀，压力测试的文件名以S作为前缀，兼容性测试的文件名以C作为前缀。该配置项可以选择一个或一个以上的分类，如果不选择则默认为选择了所有的测试分类。

待提取文件类型：表示需要从何种文件类型的待提取测试程序文件中提取测试用例。测试程序文件的类型根据采用的编译环境不同而有所不同，可以包括汇编、C、C++、VC、JAVA等类型的文件。可以采用文件的扩展名来区分文件类型，文件的扩展名可以为.c、.asm、.java等。该配置项可以选择一个或一个以上的类型，如果不选择则默认为选择了所有的文件类型。

待提取文件路径：表示待提取测试程序文件所在的路径，提取测试用例模块131可以根据该路径找到待提取测试程序文件。

注释标识：表示需提取的测试用例所采用的注释符号。可以选择“/*@...@*/”，则提取测试用例时，会提取“/*@...@*/”符号中的内容。该注释标识可以选用其它标志符号，例如“/*§...§*/”等。

显示样式：表示提取出的测试用例采用何种显示样式。本实施例指定扩展标识语言(XML)格式作为指定显示样式，因此从测试程序文件中提取的测试用例先写入XML文件，再利用perl脚本工具将XML文件中的内容导入测试用例数据库。本实施例中，脚本的解释工具采用perl脚本工具，perl脚本工具用于将某种形式的文件内容读取到变量中，以便使用该变量进行某些操作，或者将该变量写入某些文件。本实施例读取配置文件内容，读取XML格式的测试用例文件信息，生成XML格式的测试用例文件，并将该文件导入测试用例数据库中，都采用perl脚本工具。采用perl脚本工具是为了对本发明进行更好的说明，但不局限于此，可以使用能够和数据库挂接的其它语言。

连接数据库信息：表示提取出的测试用例所要保存的指定测试用例数据库，该连接数据库信息包括所要连接测试用例数据库的数据库名称，数据库地址，数据库端口，账户，密码信息。

以上各配置项中，待提取文件路径、待提取文件类型、注释标识为基本信息；项目名、项目成员、项目时间、项目描述、测试分类为项目信息；连接数据库信息为数据库信息。

本实施例中，用户输入项目名为G2000，项目成员为alen，项目时间为2006.10.24，项目描述为This project is used for demo，测试分类为功能测试和性能测试(Function，Performance)，待提取文件路径为./G2000，待提取文件类型为.c，注释标识为/*@...@*/，显示样式为XML，连接数据库信息的数据库名称为MySQL，数据库地址为10.1.1.1，数据库端口为1021，账户为test，密码为test。

步骤202，管理模块130根据提取测试用例配置项形成配置文件。

本步骤中，根据提取测试用例配置项形成配置文件，是将提取测试用例配置项写入配置文件的过程，具体方法是：将提取测试用例配置项每个字段的内容存储到对应的变量中，将该些变量的变量名及其变量值逐行写入到配置文件中。此时配置文件包括：基本信息、项目信息、数据库信息等。该配置文件的内容是以节的方式记录的，本实施例中，节以“[]”作为标志，后接该节内的变量名及其变量值。

其中，基本信息以[General]的节表示，包括：待提取文件路径(Path)、待提取文件类型/文件扩展名(File Extension)、注释标识(CommentMark)等变量名及其变量值；项目信息以[Project]的节表示，包括：项目名(ProjectName)、项目成员(ProjectMember)、关键字(Keyword)、测试类别(Type)等变量名及其变量值；数据库信息以[DB]的节表示，包括：数据库名称(DBName)、数据库地址(DBAddress)、数据库端口(DBPort)、账户(DBAccount)、密码(DBCode)等变量名及其变量值。上述每条信息是分别逐行写入配置文件的。其中，关键字可以有一个以上，本实施例中有两个，分别对应项目时间(Keyword1)和项目描述(Keyword2)，该关键字可以根据需要添加；根据用户输入的配置项，文件扩展名和测试类别可以有一个以上，本实施例中文件扩展名有一个，即.c；由于用户选择了两个测试类别，因此测试类别在配置文件中有两个，即Type1和Type2。

本实施例中，形成的配置文件如下所示

[General]

Path＝./G2000

File Extension＝.c

CommentMark＝/*@...@*/

[Project]

ProjectName＝G2000

ProjectMember＝″alen″

Keyword1＝2006.10.24

Keyword2＝This project is used for demo

Type1＝Function

Type2＝Performance

[DB]

DBName＝MySQL

DBAddress＝10.1.1.1

DBPort＝1021

DBAccount＝test

DBCode＝test

步骤203，采用perl脚本读取配置文件。

本步骤中，提取测试用例模块131采用perl脚本工具逐行读取在步骤202中形成的配置文件，将读取出的配置文件数据存放于perl脚本工具的配置信息变量中，等待调用。以下所述的根据配置文件中的信息执行的操作，实际上是根据相应的配置信息变量执行的。

步骤204，查询指定目录及其子目录下的文件。

本步骤中，采用perl脚本语言提供的模块函数，查询配置文件中待提取文件路径所指定的目录及其目录下的待提取测试程序文件。本实施例中查询目录为./G2000下测试程序文件，由于测试程序文件按照测试分类存放于分类子目录下，因此perl脚本工具根据配置文件中提供的Type信息，查询功能测试测试目录和性能测试目录下的所有测试程序文件。

步骤205，判断是否查询到符合条件的文件。如果查询到，则执行步骤206；否则，执行步骤209，结束本流程。

本步骤中，符合条件的文件是指符合File Extension要求，以及符合Type要求的待提取测试用例文件。本实施例中，提取测试用例模块131判断功能测试和性能测试子目录中是否有File Extension为.c的测试程序文件。

步骤206，将查询出的文件集合保存。

本步骤中，将查询出的符合条件的测试程序文件所在路径及文件名保存到一个文件集合，即，以一个数据结构来保存这些测试程序文件的路径及文件名。

步骤207，根据配置文件，将文件集合中符合条件的测试用例提取出来，并写入XML文件。

本步骤中，符合条件的测试用例是指测试用例的注释标识与用户配置的注释标识相匹配的测试用例。这些测试用例可以导入测试用例数据库140，以实现对测试用例的管理，并且可以在需要时导出使用。将文件集合中符合条件的测试用例导入数据库140，需要先将测试用例从测试程序文件中提取出来，并写入XML文件。生成的XML文件为XML格式的测试用例文件，包括项目信息和从测试程序文件中提取出的测试用例。其中，项目信息是配置文件中的项目信息。XML文件中每个测试用例均以文件名(file name)作为开始标识，后面依次写入测试用例的测试ID，测试目的，测试描述，预期结果和测试时间；同一测试分类的测试用例写在一起，以分类名称(typename)作为开始标识。该XML文件中可能有多个测试分类，每一个测试分类中可能有多个测试用例。本实施例中，形成的XML文件的内容如下所示：

<？xml version＝″1.0″encoding＝″gb2312″？>

<project projectname＝″G2000″ projectmember＝″alem，joe，mark″

keyword1＝″2006.10.24″keyword2＝″This project is used for demo″>

<测试ID>

F_A

</测试ID>

<测试目的>

验证C可编译

</测试目的>

<测试描述>

在屏幕上打印Hello world

</测试描述>

<预期结果>

屏幕上出现Hello world

</预期结果>

<测试时间>

2006.10.24

</测试时间>

</file>

</type>

<测试ID>

P_A

</测试ID>

<测试目的>

再次验证C可编译

</测试目的>

<测试描述>

在屏幕上打印Hello world-again

</测试描述>

<预期结果>

屏幕上出现Hello world-again

</预期结果>

<测试时间>

2006.10.24

</测试时间>

</file>

</type>

</project>

以上XML文件中，第一行为相关的版本信息。XML文件的每一信息段的结束均以</>表示，根据不同信息段</>填入不同的内容。上述XML文件中提取了路径/G2000/Function/下的文件F_A.c中的测试用例(假设该文件中只有一个符合注释标识测试用例)，该用例在待提取测试程序文件F_A.c中的起始行的行号为line＝“001”表示。如果写入XML文件有多个测试用例，再如上述XML文件中还提取了路径/G2000/Performance/下的文件P_A.c中的测试用例(假设该文件只有一个符合注释标识测试用例)，该用例在待提取测试程序文件P_A.c中的起始行的行号为line＝“012”表示。

步骤208，将XML文件导入测试用例数据库。

本步骤中，测试用例数据库是由配置文件中数据库信息指定的，并根据该数据库信息创建测试用例数据库连接。该测试用例数据库包含测试用例表和项目信息表。将XML文件导入测试用例数据库的过程为，perl脚本工具读取XML文件内容，将XML文件中的项目名、项目成员、项目时间、项目描述写入项目信息表的相应字段中，并将XML文件中的各测试用例都写入测试用例表的相应字段中，测试用例表的字段包括项目名、测试分类、测试ID、测试目的、测试描述、预期结果、测试时间。为了进一步方便用户使用该测试用例表对测试用例进行管理，使得测试用例库反应更多的信息，该测试用例表中还可以包括文件名(Filename)和测试用例行号(line)字段。文件名和测试用例行号也都是从上述XML文件中得到的。本实施例中，将XML文件导入测试用例数据库后形成的测试用例表如表1所示，项目信息表如表2所示：

项目名	测试分类	测试ID	文件名	行号	测试目的	测试描述	预期结果	测试时间
项目名	测试分类	测试ID	文件名	行号	测试目的	测试描述	预期结果	测试时间	G2000	Function	F_A	./G2000/Function/F_A.c	001	验证C可编译	在屏幕上打印Helloworld	在屏幕上打印Helloworld	2006.10.24
G2000	Performance	P_A	./G2000/Performance/P_A.c	012	再次验证C可编译	在屏幕上打印Helloworld-again	在屏幕上打印Helloworld-again	2006.10.24	G2000	Function	F_A	./G2000/Function/F_A.c	001	验证C可编译	在屏幕上打印Helloworld	在屏幕上打印Helloworld	2006.10.24

表1

项目名	项目成员	项目时间(Keyword1)	项目描述(Keyword2)	other
项目名	项目成员	项目时间(Keyword1)	项目描述(Keyword2)	other	G2000	alen	2006.10.24	This project is used for demo

表2

需要使用测试用例数据库存储的测试用例时，可以通过输入界面121利用测试ID字段精确查询测试用例，或者利用测试用例表中的“测试描述”字段或项目信息表中“项目描述”字段、“项目成员”字段进行模糊查询。用户还可以通过GUI操作，通过对测试用例表和项目信息表中内容的管理实现对测试用例数据库中的各字段信息进行增加、删除或修改。

步骤209，结束本流程。

在提取测试用例过程中，步骤207是将符合条件的测试用例逐一写入XML文件的过程。如图3所示，形成XML文件的步骤如下：

步骤2071，将项目信息写入XML文件。

本步骤中，将配置文件中项目信息的项目名、项目成员、项目时间、项目描述写入XML文件中，这些信息是用户输入提取测试用例配置项时输入的，用于在将XML文件导入测试用例数据库时填入项目信息表。

步骤2072，判断文件集合中的测试程序文件是否已经全部处理完毕，如果没有处理完毕，则循环执行步骤2073～2077，直到文件集合中的文件全部处理完毕；如果文件集合的文件处理完毕，则执行步骤208，将写入到XML文件中的测试用例导入测试用例数据库140。

本步骤中，采用遍历整个存储文件路径及文件名的数据结构来判断文件集合中的文件是否全部处理完毕。在遍历时按照测试分类遍历。本实施例中，按照Type1，Type2的顺序对文件集合中的文件进行遍历。Type1表示功能测试，因此首先处理文件集合中功能测试的测试程序文件，测试程序文件的文件名的前缀标识出了该测试程序文件的类型。

步骤2073，打开当前文件，匹配注释内容。

本步骤中，遍历到一个测试程序文件后，将该测试程序文件打开，采用perl脚本工具逐行读取并查找与注释标识相匹配的注释符号，如“/*@...@*/”。

步骤2074，判断步骤2073是否匹配到符合的注释。如果当前测试程序文件没有符合的注释，则执行步骤2075，处理下一个测试程序文件，并返回步骤2072；若匹配到符合条件的注释，执行步骤2076。

步骤2076，提取出测试用例，写入XML文件。

本步骤中，利用perl脚本工具提供的正则表达式提取所查找到符合条件的注释内容，即测试用例，并放入临时变量中，然后把该临时变量中的测试用例写入XML文件中。本步骤中提取出的测试用例写入文件的格式还可以是HTML、RFT、TXT等格式文件。文件的格式是根据用户输入的显示样式决定的。本实施例中，写入XML文件的测试用例内容包括测试ID、测试目的、测试描述、预期结果和测试时间等。

步骤2077，判断当前文件是否处理完毕。若没有处理完毕，则重复执行步骤2074、2076、2077，直到当前打开的文件处理完毕，执行步骤2075，处理下一个文件，并转入步骤2072。

在提取测试用例过程中，步骤203采用perl脚本语言取逐行读取配置文件。参见图4，读取配置文件方法的具体步骤如下：

步骤300，打开配置文件。

步骤301，采用perl脚本工具读取一行该配置文件中的内容。

步骤302，判断读取的内容是否为“节”标志开始。本实施例是以“[]”为节标志，但也不限于此，可以是其它类型的标志符号，例如“{}”等。如果该行内容是节标志开始，则执行步骤306，将节名称即“[]”中的内容读入配置信息变量；如果不是节标志开始，则执行步骤303进一步判断该读取的内容是否为变量名；若不是变量名则返回步骤301再读入一行内容；否则，执行步骤304、305，读入变量名，并对该变量名赋值。

步骤307，判断配置文件是否结束。若没有结束，返回步骤301再读入一行；否则执行步骤308，关闭配置文件。

步骤309，配置文件所有数据存放在配置信息变量中等待下一步调用。

步骤310，读取配置文件结束。

以上提取测试用例方法的实施例，是对待提取的测试程序文件进行提取测试用例。还可以从已有文本用例中提取测试用例。已有文本用例的文件包括测试用例及其项目信息。其内容类似于上述从测试程序文件提取测试用例XML文件的内容。因此在图2的步骤201中可以将文件导入模块110中已有文本用例，通过输入界面121导入管理模块130。管理模块130中的数据库管理模块132将已有文本用例加入到测试用例数据库140中，并根据已有文本用例中测试用例在测试用例表中建立字段，根据已有文本用例中项目信息在项目信息表中建立字段。数据库管理模块132还通过GUI向用户提供的可视化的数据库管理界面，用户可以通过界面操作输入管理信息，以添加的方式增加字段及其数据，或者重新编辑数据库字段，例如测试用例库中的项目名和测试分类字段。

本发明的提取测试用例方法可以根据用户输入的提取测试用例配置项，从测试程序文件中提取出测试用例，并保存在测试用例数据库中。需要时，用户只需从数据库管理界面中输入所需的测试用例的配置项，即可浏览打印所需的测试用例。如果只输入了项目名就可得到该项目所有测试用例，即测试用例方案。简化了测试人员先进行测试用例方案设计，再进行测试用例编写的过程。而是可以先进行测试程序文件的编写，再通过提取测试用例的方法从测试程序文件中提取出测试用例，并形成测试用例方案。用户输入的提取测试用例配置项包括注释标识，因此本发明可以从不同类型的文件中，提取不同注释风格的测试用例，增加了提取测试用例的灵活性。用户还可以通过GUI的操作，从测试用例数据库中获取测试用例，并对测试用例进行添加、修改或删除等管理操作。

本发明的软件测试管理***还提供生成测试程序框架方法。生成测试程序框架是通过用户输入的生成测试框架配置项从已有的测试用例中提取符合条件的测试用例，并写入测试程序文件，同时在每一个测试用例后面，写入该测试用例对应的测试函数框架。生成的测试程序框架自动分类保存，不同测试类别的测试程序保存在不同的目录下，方便测试人员查找和编写测试程序。

生成测试程序框架的所采用的测试用例可以来自测试用例数据库，也可以来自已有文本用例。当测试用例来自已有文本用例时，根据生成测试用例框架配置向将从外部导入的已有文本用例，直接用于生成测试程序框架。测试程序框架的生成主要由管理模块中的生成测试框架模块133和文件生成模块150完成，生成测试框架模块133主要完成根据生成测试框架配置项获取相应的测试用例文件及配置文件；文件生成模块150主要完成根据测试用例文件及配置文件生成测试程序框架。以下就举两个实施例来说明本发明生成测试程序框架的方法。首先以获取测试用例数据库中的测试用例生成测试程序框架的方法作为实施例一，参见图5，该实施例生成测试程序框架的具体步骤如下：

步骤400，在输出界面输入生成测试框架配置项。

本步骤中，用户输入的生成测试框架配置项包括基本配置项和扩展配置项。基本配置项又包括项目信息、测试用例内容、测试程序语言、注释风格、连接数据库信息以及指定的生成测试文件路径。扩展配置项包括：函数名称、函数返回值、函数参数等函数信息。

其中，项目信息包括项目名、项目成员、测试分类、项目时间、项目描述等其它项目信息，该些项目信息可以从项目信息表中获取，用户在输入时可以通过输出界面选取。测试用例内容包括测试ID、测试目的、测试描述、预期结果等内容，该些测试用例内容可以从测试用例表中获取，用户在输入时可以通过输出界面选取。项目信息和测试用例内容的字段均可以用来作为匹配测试用例的字段。

测试程序语言，表示生成测试程序框架的编程语言，例如c，c++等。

注释标识，表示生成的测试程序框架中测试用例采用何种注释风格。

连接数据库信息，表示所要获取测试用例的测试用例数据库的相关信息。

指定的生成测试文件路径，表示生成的测试程序框架所要保存的路径。

扩展配置项，表示测试用例所对应的测试函数的框架内容。

用户不必要输入所有的配置项，例如想获取某个项目所有测试分类的测试程序文件时，则可以不设置测试分类项。如果不想限制测试用例的具体功能，可以不设置测试用例内容。

本实施例中，设用户输入项目名为G2000，测试分类为Function，注释标示为“/*@...@*/”，连接数据库信息的数据库名称为MySQL，数据库地址为10.1.1.1，数据库端口为1021，账户为test，密码为test，测试程序语言为c语言，指定的生成测试文件路径为./G。函数名称不输入，即默认为对应测试用例的测试ID，函数返回值(Return Value)为void，函数参数(Parameter)为void。其它配置项都不填。因此利用G2000项目中功能测试的测试用例生成测试程序框架。并确定了生成测试程序框架的语言为c语言，生成的测试程序框架保存在./G路径下。

步骤401，根据生成测试框架配置项形成配置文件。

本步骤中，生成测试框架模块130将基本配置项的项目名、测试程序语言，测试分类，注释标识，以及扩展配置项的函数返回值、函数参数写入配置文件。配置文件的信息用于在生成测试程序框架时，建立工程目录和测试分类子目录，以及确定测试程序语言和测试用例的注释风格。

步骤402，生成测试框架模块130用perl脚本工具读取配置文件。读取配置文件的过程与图4所示读取配置文件过程相同。此时配置文件中的信息被读取到配置信息变量中，等待调用。以下所述的根据配置文件中的信息执行的操作，实际上是根据相应的配置信息变量执行的。

步骤411、412，根据生成测试框架配置项获取测试用例数据库的测试用例，并从测试用例数据库导出。

本步骤中，生成测试框架模块130根据生成测试框架配置项中的数据库信息建立测试用例数据库连接，根据生成测试框架配置项其它内容匹配测试用例数据库中的测试用例，获取符合条件的测试用例，并从测试用例数据库中导出。

本实施例中，符合条件的测试用例为，MySQL数据库中，项目G2000下测试分类为功能测试的测试用例。假设生成测试框架模块133从测试用例数据库中查找到一个符合条件的测试用例，如表1所示的测试ID为F_A的测试用例。

步骤413，将导出的测试用例形成测试用例文件。该测试用例文件的格式是XML格式，该格式是根据用户输入配置项选择XML显示样式确定的。测试用例文件的格式还可以是HTML、RTF、TXT等文件格式。采用XML格式形成测试用例文件后，需要用对应的脚本工具读取该文件，这里采用perl脚本工具。

本实施例中，根据步骤412查找出的测试ID为F_A的测试用例生成XML文件，该XML文件如下所示：

<？xml version＝″1.0″encoding＝″gb2312″？>

<project projectname＝″G2000″projectmember＝″alen″keyword1＝″2006.10.24″

keyword2＝″This project is used for demo″>

<测试ID>

F_A

</测试ID>

<测试目的>

验证C可编译

</测试目的>

<测试描述>

在屏幕上打印Hello world

</测试描述>

<预期结果>

屏幕上出现Hello world

</预期结果>

<测试时间>

2006.10.24

</测试时间>

</pattern>

</type>

</project>

其中，在形成XML文件过程中，先写入项目信息，再将测试用例按照测试分类写入不同的段中。测试分类的段以分类名称(type name)为开始标识，每个测试用例以用例编号(pattern line)作为开始标识。每一段的结束均以</>作为结束标识，不同的段</>的内容不同。

步骤420，根据配置文件和XML文件，生成测试程序框架，并写入源文件。

本步骤中，采用perl脚本工具将XML文件中的内容读入测试用例变量，以便与配置信息变量的内容匹配，生成测试程序框架。写测试程序框架时，先根据配置文件的内容在指定路径下建立工程目录及测试分类子目录，并在测试分类子目录中建立测试程序文件，建立的文件类型由用户选择的测试程序语言确定，文件名由测试ID确定。随后，打开测试程序文件，根据注释风格将从测试用例数据库提取的测试用例以注释形式写入该测试程序文件中，并将该测试用例对应的函数框架填入每个测试用例后面。这样就形成了测试程序的源文件。当从测试用例导出的测试用例均写入到对应的测试程序文件后，便结束生成测试程序框架。

步骤430，将测试程序框架的源文件输出。这样测试人员即可根据生成的测试框架中的测试用例进行编程测试。

下面以获取外部数据生成测试程序框架的方法作为实施例二，参见图6，该实施例生成测试程序框架的具体步骤如下：

步骤500，通过输出界面直接选择文件导入模块中的已有文本用例，同时用户输入要生成测试框架配置项。该配置项的具体内容与图5步骤400中输入的配置项相同。输入的已有文本用例文件格式可以是XML、HTML、RTF或TXT等格式文件。

步骤501，根据生成测试框架配置项形成配置文件。

步骤502，采用perl脚本工具读取该配置文件。读取过程与图4所示读取配置文件过程相同。

步骤511，通过文件导入模块110获取已有文本用例，形成外部数据。

本步骤中，根据生成测试框架配置获取符合要求的已有文本用例。该已有文本用例中包含了测试用例及其项目信息。根据生成测试框架配置中对用例内容的限定从获取的已有文本用例中将测试用例及其项目信息提取出来，形成外部数据。如果没有对用例内容的限定，则将获取的所有已有文本用例的测试用例及其项目信息提取出来，形成外部数据。然后将该外部数据导入生成测试框架模块133进行处理。即，对该外部数据进行查询、增加、删除或修改等操作。此时，获取的已有文本用例可以以XML、HTML、RTF或TXT等文件格式存在。

步骤512，将上述处理后的外部数据形成外部文件，即测试用例文件。该外部文件可以以XML、HTML、RTF或TXT等文件格式存在。同时，该外部文件还可以直接导入测试用例数据库140中进行管理。本实施例，外部文件以XML格式存在，其格式与根据测试用例数据库的测试用例形成XML文件的格式相同。

步骤520，根据配置文件和XML格式的外部文件，生成测试程序框架，并写入源文件。

步骤530，将源文件输出。这样测试人员即可根据生成的测试框架中的测试用例进行编程测试。

生成测试框架模块133生成测试程序框架后，要写入源文件，测试人员才能采用该源文件编程和测试。图7为本发明测试程序框架写入源文件的方法流程图，该方法包括以下步骤：

步骤600，读入数据。该数据包括，步骤614中根据生成测试框架配置项获取的配置文件内容，步骤615中从测试用例数据库获取的测试用例及其项目信息，或者步骤616从已有文本用例获取的测试用例及其项目信息。

步骤601，根据配置文件中基本配置项的指定路径以及项目名，在该路径下以项目名建立工程目录。

步骤602，根据测试分类在工程目录下建立测试分类子目录。该测试分类子目录将测试程序文件分为功能测试文件、性能测试文件、压力测试文件、兼容性测试文件等。

步骤603，根据测试用例在各个测试分类子目录下建立测试程序文件。文件名为该测试用例的测试ID。

步骤604，将步骤602建立的测试分类子目录打开。

步骤605，将步骤603建立的测试程序文件打开。

步骤606，以注释形式在测试程序中填入测试用例。本实施例中为“/*@...@*/”。

步骤607～609，按顺序填入函数入口、函数体开始和函数体结束标志。其中函数体开始的形式如“Retumvalue functionname(parameter)”。

步骤610，判断写入当前测试程序文件的测试用例内容是否结束。如果没有结束，则返回步骤606再次执行步骤606～610，再写入一个测试用例；否则，执行步骤611，判断该测试分类子目录下的测试程序文件是否遍历。如果没有，则执行步骤605～611，打开当前测试分类子目录下的另一个测试程序文件，写入测试用例和测试函数框架；否则执行步骤612，判断该工程目录下的测试分类子目录是否遍历，如果没有，则执行步骤604～612，在当前工程目录下打开另一个测试分类子目录，对该目录下的各测试程序文件写入相应测试用例和测试程序框架；否则执行步骤613，结束本流程。

本实施例中，由于从测试用例数据库查询到符合条件的测试用例只有一个，在生成测试程序框架时，在指定路径./G下，建立工程目录/G2000，在该工程子目录下建立功能测试分类子目录/Function，在该功能测试子目录下建立文件名为F_A.c的测试程序文件，该测试程序的内容，如下所示：

/*@

\测试ID F_A

\测试目的验证C可编译

\测试描述在屏幕上打印Hello world

\预期结果屏幕上出现Hello world

\测试时间2006.10.24

@*/

void F_A(void)

{

}

可见，生成测试程序框架时，测试程序与测试用例一一对应。在使用时，用户只需要在F_A函数中填入程序编码即可，有利于测试编码人员提高工作效率。

由以上所述可以看出，本发明所提供的程序测试管理***，可以根据用户需要，从已有的测试程序文件中提取所需格式测试用例方案，提高测试人员的工作效率；其次，用户还可以通过GUI操作，对测试用例数据库中的测试用例进行管理。另外，本发明可以根据用户需要生成测试程序框架，生成的测试程序文件分类存放与不同目录下，且测试程序文件中测试用例与测试程序一一对应，方便测试人员编写程序使用。

综上所述，以上仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims

1.一种软件测试管理方法，其特征在于，该方法包括：

A、根据输入的配置项，获取测试程序文件或已有文本用例；

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

C、将所述步骤B获取的测试用例导入数据库。

3.根据权利要求2所述的方法，其特征在于，当根据测试程序文件提取测试用例时，所述配置项为提取测试用例配置项；该方法具体包括：

4.根据权利要求3所述的方法，其特征在于，所述步骤C进一步包括，根据所述配置文件将获取的所述测试用例的项目信息导入所述数据库。

5.根据权利要求4所述的方法，其特征在于，该方法进一步包括：

6.根据权利要求3所述的方法，其特征在于，

步骤A所述根据该配置文件获取测试程序文件为：根据所述配置文件中的待提取文件路径、待提取文件类型和测试分类，从指定路径中获取指定文件类型，指定测试分类的测试程序文件；

步骤A所述根据该配置文件获取测试程序文件之后，进一步包括：将获取的所述测试程序文件的文件路径和文件名保存在文件集合中；

步骤B所述获取测试用例为：遍历所述文件集合中所有测试程序文件，根据所述配置文件中的注释标识，从所述测试程序文件中提取测试用例。

7.根据权利要求6所述的方法，其特征在于，所述测试分类表示所述测试文件中的测试用例用于何种类型的测试，该测试分类为性能测试，或功能测试，或压力测试，或兼容性测试，或一致性测试。

8.根据权利要求4所述的方法，其特征在于，所述数据库包括测试用例表和项目信息表；

步骤C所述将获取的测试用例和项目信息导入数据库为：将所述测试用例写入所述测试用例表，将所述项目信息写入所述项目信息表。

9.根据权利要求1所述的方法，其特征在于，当根据已有文本用例生成测试程序框架时，所述配置项为生成测试框架配置项；

该方法进一步包括：

根据所述测试用例及其项目信息形成测试用例文件；

10.根据权利要求9所述的方法，其特征在于，

步骤B所述获取测试用例及其项目信息之后进一步包括：对所述测试用例进行添加、删除或者修改处理。

11.根据权利要求5或9所述的方法，其特征在于，所述根据所述第二配置文件和所述测试用例文件，生成测试程序框架包括：

根据所述第二配置文件中的项目名，在指定路径下建立工程目录；

根据所述第二配置文件中的测试分类，在所述工程子目录下建立测试分类子目录；

根据所述测试用例文件在各个测试分类子目录下，建立测试程序文件；

根据所述第二配置文件和所述测试用例文件向所述测试程序文件填入测试用例和测试函数框架。

12.根据权利要求11所述的方法，其特征在于，向所述测试程序文件填入测试用例和测试函数框架包括：

根据所述第二配置文件中的注释标识，向所述测试程序文件中以注释形式填入测试用例；

根据所述第二配置文件中的函数返回值和函数参数，向所述测试程序文件中填入与所述测试用例对应的空函数。

13.根据权利要求2所述的方法，其特征在于，该方法进一步包括：

根据输入的管理信息，对所述数据库中的测试用例进行管理。

14.一种软件测试管理***，其特征在于，该***包括：图形用户界面GUI、管理模块和文件导入模块；

所述GUI，用于将用户输入的配置项输出给管理模块；

15.根据权利要求14所述的***，其特征在于，该***进一步包括数据库，用于存储从所述管理模块获取的测试用例。

16.根据权利要求15所述的***，其特征在于，所述管理模块包括提取测试用例模块，用于根据提取测试用例配置项生成配置文件，并根据该配置文件获取测试程序文件；再根据所述配置文件和所述测试程序文件，获取测试用例；根据所述配置文件获取项目信息；将获取的所述测试用例和所述项目信息导入到数据库。

17.根据权利要求16所述的***，其特征在于，所述管理模块进一步包括数据库管理模块，用于根据用户通过GUI输入的管理信息，对所述数据库中的信息进行管理；还用于将所述管理模块根据所述配置文件和所述已有文本用例获取的测试用例及其项目信息导入所述数据库。

18.根据权利要求16所述的***，其特征在于，该***进一步包括文件生成模块；所述管理模块进一步包括生成测试框架模块；

19.根据权利要求16所述的***，其特征在于，所述数据库包括测试用例表和项目信息表；

所述测试用例表，用于存储从管理模块获取的所述测试用例；

所述项目信息表，用于存储从管理模块获取的所述项目信息。