软件功能测试用例的设计过程及实践

摘要：该文介绍了软件功能测试用例的设计过程在RMDB系统中的实践，并对测试用例进行评审和追踪，从而提高功能测试用例的设计效率。

关键词：测试用例；评审；追踪

中图分类号：TP311文献标识码：A文章编号：1009-3044(2008)32-1131-04

The Process of Design and Practice for Software Functional Test Case

YU Jiu-jiu

(Anhui Wenda Information and Technology College,Hefei 231201,China)

Abstract: The article introduces the process of design software functional test case and practice on RMDB system, reviewing and tracing test case, and improve the efficiency on functional test case design.

Key words: test case; review; trace

1 前言

软件测试用例就是设计一种情况，软件程序在这种情况下，希望能够正常运行并且达到程序事先所设计的执行结果。测试用例由测试输入数据和预期的输出结果两部分组成。软件测试用例的设计和执行是软件测试工作的核心，也是工作量最大的任务之一，良好的测试用例设计过程能够提高测试用例的设计质量，便于跟踪测试用例的执行结果，自动生成测试用例覆盖率报告。测试用例可以用数据库、Word 、Excel 、XML 等格式进行管理，市面亦有成熟的商业软件工具和开源工具等。对于一般中小软件企业，使用文档来管理测试用例是较为方便、经济的途径。

2 软件功能测试用例的设计

软件功能测试是对软件系统最基本的一类测试，功能测试用例即指软件产品在交付于用户前对其是否达到事先所定义的用户需求规格说明书上说指定的产品功能要求进行测试的测试用例。它是站在用户角度上，也是较重要的一类测试用例。

2.1 设计原理

测试用例由测试输入数据和预期的输出结果两部分组成。在设计测试用例的输入条件中应包括合理的输入条件和不合理的输入条件。人们往往倾向于过多地考虑合法的和期望的输入条件，以检查程序知否做了它应该做的事情，而忽视了不合法的和预想不到的输入条件。如果开发出的软件遇到非法情况不能做出适当的反应，会导致软件的失效。用不合理的输入条件测试程序时，会比合理的输入条件进行测试能发现更多的错误。所以就软件功能测试而言，测试用例设计要从4个方面考虑：

1) 系统功能是否符合需求说明；

2) 系统功能是否完善；

3) 系统功能是否有作用；

4) 系统功能是否无错误。

2.2 设计方法

测试用例的设计和编制是软件测试活动中最重要的。测试用例是测试工作的指导，是软件测试的必须遵守的准则。更是软件测试质量稳定的根本保障。

测试用例设计的目的就是将系统需求具体化，提取测试需求，通过可测试的方法对每个功能点进行描述。测试用例设计的好坏直接关系到测试质量的高低。用最少的测试用例覆盖最全的功能点是测试用例设计的目标。

在测试用例的设计过程中，应用一个有效的测试用例模板对用例的管理，测试的执行具有十分重要的作用。

2.3 功能测试用例组成要素

1) 用例场景：描述该测试用例所验证的需求用例。通常一个需求用例与多个测试用例对应。对每个需求用例，有时可能需要两个或多个测试用例与其对应。一个测试用例描述正常工作流情况，另一个或多个描述异常处理工作流。通常异常工作流的测试用例往往是正常工作流测试用例的几倍。

2) 测试用例序号：每个测试用例都有一个惟一的序列号，用于标识。

3) 测试用例描述：对测试内容的简单描述，让阅读者能够很快对这个测试用例有个大概的了解。

4) 前置条件：描述执行该测试用例需要满足什么条件。

5) 步骤：实现测试用例的各个操作。

6) 预期结果：每个测试步骤执行之后的预期结果，是建议需求验证是否被通过的标准。预期结果不是在测试执行当中才被考虑的，应该在测试用例设计阶段由需求分析推导而得。

7) 注释：填写测试中应当注意的问题或者说明。注释不是必须填写的列，而其他列则是必须要填写的。

8) 真实结果：每一个版本对应真实结果的一列。这一列里填写测试的真实结果（通过/失败/不可测/跳过）。如果测试用例执行失败，需要填写失败的详细结果，以及对应的缺陷号。(注：真实结果也可以在相应的测试报告中填写)

3 软件功能测试用例的设计过程在RMDB系统中的实践

3.1RMDB系统简介

RMDB系统是某信息公司用来进行人力资源管理和项目分配的数据库系统，主要用来对当前公司所从事的信息项目进行合理的人员分配，同时管理每个员工的工作信息，个人信息及所在部门的人员行政关系等。该系统还具有对各种类型的员工的工作量进行合理分配并时刻追踪员工的工作绩效等功能。

RMDB系统的功能架构图如图1所示。

3.2 功能测试用例（版本）计划的制定

在功能测试执行之前，需要制定版本的功能测试计划，对即将进入的测试过程和测试内容进行计划。版本测试计划中最难的就是决定选择哪些功能测试用例，以什么样的顺序来执行，以及预测执行这些测试用例所需要的时间。在实际的项目过程中，由于时间的限制，我们往往无法对系统的每一个版本进行完全的功能测试和回归测试。因此在有限的时间内选择怎样的测试用例集合执行能，能够减少因为缩减测试用例而带来的风险，在测试计划里显得非常重要。

对于测试测试用例需求复杂度的分析是进行测试执行时间预测的第一步。测试需求的复杂度取决于下列因素：

1) 包含功能验证点的数目；

2) 测试用例里测试步骤的数目；

3) 执行该测试用例所需环境设置的复杂度。

除了这些因素之外，还需要综合考虑其他系统因素。通过测试复杂度的分析，我们可以得出一张测试需求复杂度的表。每一个测试用例的复杂度被标记为

‘High’，‘Middle’，‘Low’中的一种。

图2是RMDB系统中某功能主模块部分测试用例的测试复杂度分析。

测试用例是在对测试任务进行安排时划分的最小单位。根据测试经验对每一个复杂度的测试用例预测一个时间长度。然后可以考虑用MS－ Project对任务进行分配。在分配任务的过程中，需要考虑测试用例之间的依赖性和关联性，以及测试人员的可用时间（也考虑到一些测试人员可能同时工作在几个项目上）。

3.3 建立好缺陷分析及预防的系统化流程工作

在测试过程中，需要常常思考怎样更好地利用以前的测试数据，对今后测试计划和开发计划起指导作用。其中对缺陷根本原因的分析，能够帮助项目管理人员掌握缺陷集中的区域，明晰缺陷发展趋势，了解缺陷产生的主要原因，以便有针对性地提出遏制缺陷发生的措施，降低缺陷数量，降低测试成本。在今后的测试工作中，测试人员与开发人员一起，建立起一个缺陷分析和预防的流程。

在测试过程中我们针对系统缺陷分析表对系统当前的缺陷状态和数目进行分析和统计，如果系统某些模块缺陷数目过多，或者严重级别的缺陷数目剧增，我们有必要对这些缺陷进行根本原因的分析。通过分析，可以了解缺陷原因的分布。我们所制定的RMDB系统缺陷分析表如图3所示。

3.4 RMDB系统功能测试用例的设计及实施

测试用例的设计和编制是软件测试活动中最重要的。测试用例是测试工作的指导，是软件测试的必须遵守的准则。更是软件测试质量稳定的根本保障。

测试用例设计的目的就是将系统需求具体化，提取测试需求，通过可测试的方法对每个功能点进行描述。测试用例设计的好坏直接关系到测试质量的高低。用最少的测试用例覆盖最全的功能点是测试用例设计的目标。

在测试用例的设计过程中，应用一个有效的测试用例模板对用例的管理，测试的执行具有十分重要的作用。以RMDB测试中的某功能测试用例模板为例。

测试数据工作表中存放每一个测试用例所需要用到的测试数据。同一个测试用例有可能用到不同的数据组合，但是测试步骤是相同的。

测试用例包总结工作表（图4）中对各个测试周期里以测试包为单位的测试用例执行结果进行统计。通过测试包总结工作表，可以看出每一个测试周期里成功/失败的测试用例数目，计划和实际实行的测试用例数目，以及错误报告的统计情况。这些数据是我们对某个测试周期的测试结果进行统计的依据。如图5所示。

3.5 测试用例在软件测试中的作用

1) 指导测试的实施

测试用例主要适用于集成测试、系统测试和回归测试。在实施测试时测试用例作为测试的标准，测试人员一定要按照测试用例严格按用例项目和测试步骤逐一实施测试。并对测试情况记录在测试用例管理软件中，以便自动生成测试结果文档。

根据测试用例的测试等级，集成测试应测试那些用例，系统测试和回归测试又该测试那些用例，在设计测试用例时都已作明确规定，实施测试时测试人员不能随意作变动。

2) 规划测试数据的准备

在我们的实践中测试数据是与测试用例分离的。按照测试用例配套准备一组或若干组测试原始数据，以及标准测试结果。尤其象测试报表之类数据集的正确性，按照测试用例规划准备测试数据是十分必须的。

3) 评估测试结果的度量基准

完成测试实施后需要对测试结果进行评估，并且编制测试报告。判断软件测试是否完成、衡量测试质量需要一些量化的结果。例：测试覆盖率是多少、测试合格率是多少、重要测试合格率是多少，等等。以前统计基准是软件模块或功能点，显得过于粗糙。采用测试用例作度量基准更加准确、有效。

4) 分析缺陷的标准

通过收集缺陷，对比测试用例和缺陷数据库，分析确证是漏测还是缺陷复现。漏测反映了测试用例的不完善，应立即补充相应测试用例，最终达到逐步完善软件质量。而已有相应测试用例，则反映实施测试或变更处理存在问题。

4 测试用例的评审和追踪

4.1 测试用例的评审

RMDB系统的需求用例业务逻辑较复杂，在迭代开发的过程中随着新功能的添加而涉及到与局域网内多个数据应用系统的交互。在开发的过程中，测试人员是根据需求用例和业务背景知识设计测试用例的。系统功能测试用例的设计基本上是在开发详细设计之前完成。由于系统测试用例是系统需求可测试的描述，开发人员在进行代码开发的过程中结合测试步骤的流程，对代码设计和开发十分有帮助。

由于测试用例在项目中成为需求的一部分，需要采取一定的流程对测试用例进行评审，以保证测试用例的正确性。测试用例是软件测试的准则，但它并不是一经编制完成就成为准则。测试用例在设计编写过程中要组织同级互查。完成编写后应组织专家评审，需获得通过才可以使用。评审委员会可由项目负责人、测试、编程、分析设计等有关人员组成，也可邀请客户代表参加。通常评审测试用例的衡量标准有：

1) 准确：测试用例符合用例描述中所需测试的内容

2) 概要：包括必须的测试步骤

3) 可重复，容易理解：测试用例是一个可重复的实验。不同的测试人员进行测试可以得出相同的测试结果。如果仅仅只有设计者知道怎么执行，那么这就不是一个好的测试用例。

4) 合适：测试用例在相应的测试环境下具有可执行性，而不应依赖于测试人员的个人技能和经验

5) 可跟踪：在执行每一轮的测试中，需要追踪共执行了多少测试用例，执行的测试用例中通过的，未通过的及未使用的占多少，未使用的原因是什么。为以后的测试用例更新做准备。

6) 可恢复：测试用例执行后，测试环境需要恢复到测试前的状态。如果对系统进行恢复测试，需要说明如何使系统回到正常状态。

在评审会议中，会议主持者负责控制评审的进度和时间，通过评审，把需要澄清和改进的问题记录下来，由测试用例的设计者会后进行修改，修改完成后的测试用例需要提交再次评审，直到所有的用例通过评审为止。

最后，测试用例在形成文档后也还需要不断完善。主要来自三方面的缘故：第一、在测试过程中发现设计测试用例时考虑不周，需要完善；第二、在软件交付使用后反馈的软件功能性缺陷，而缺陷又是因测试用例存在漏洞造成；第三、软件自身的新增功能以及软件版本的更新，测试用例也必须配套修改更新。

一般小的修改完善可在原测试用例文档上修改，但文档要有更改记录。软件的版本升级更新，测试用例一般也应随之编制升级更新版本。

4.2 测试用例的追踪

因为测试用例具有易组织性，可评估性和管理性，在测试用例执行过程中，实现测试用例执行过程的跟踪可以有效地将测试过程量化。例如，执行一轮测试中，共执行了多少测试用例，哪些成功的预测到缺陷，那些没有，等等。当然，这只是一个相对过程，测试人员的工作量不应仅仅凭借测试用例的执行情况来判定，但至少每轮测试后通过对实现所设计的测试用例的追踪可以判断当前软件测试的质量，并对测试的有效性进行评估。

追踪测试用例的形式一般有以下几种:

1) 记忆：凭借个人的记忆力来追踪测试用例，方法是不可取的。

2) 书面文档：使用书面文档记录测试用例，主要使用列表的形式。但作为组织和搜索数据分析时，这种方法是很局限的。

3) 电子表格：通过表格中列出的测试用例的跟踪细节，可以直观的砍刀测试状态以及分析合同及测试用例的通过与否，它与软件缺陷相关联。这为测试中有效管理和分析测试过程以及软件的质量提供了有效的量化依据。

4) 自定义数据库：通过自己定义的数据库来跟踪测试用例的执行和覆盖率，并通过自己编写的工具生成相关报表，分析图等。当然，这种方法所花费的成本是最高的。

根据RMDB系统实际测试环境的现状，我们所采用的是电子表格形式对每一轮测试后的测试用例进行追踪。所用的测试用例覆盖缺陷追踪统计表模板主要由以下几部分组成，分别是测试轮数，被测模块号，模块名，模块测试状态，缺陷号，未覆盖标识，覆盖标识（执行的用例号，为被执行的用例号），覆盖缺陷率。

1) 测试轮数：表明这是第几轮测试的统计表。

2) 被测模块号：每个被测模块都有一个惟一的序列号，用于标识。

3) 模块名：每个被测模块都有一个惟一的模块名，用于标识。

4) 模块测试状态：指该模块内是否发现缺陷（无论是哪一种缺陷），一般用Pass/Fail 标识。

5) 缺陷号：指在某一模块中所发现的一或多个缺陷序列号，每个缺陷序列号唯一，用于标识。

6) 未覆盖标识：指该缺陷未被事先设计的测试用例所覆盖到（预测到），标明相应的缺陷序列号。

7) 覆盖标识（执行的用例号）：指该缺陷被事先设计的测试用例表中所覆盖到（预测到），并且该缺陷发生的结果与测试用例表中反映的一致。标明相应的测试用例序列号。

8) 覆盖标识（未执行的用例号）：指该缺陷被虽然被事先设计的测试用例表中所覆盖到（预测到），但是该缺陷发生的结果与测试用例表中反映的不一致。标明相应的测试用例序列。

9) 覆盖缺陷率：统计此轮测试后，事先设计的测试用例表中成功的覆盖到（预测到）实际所发现缺陷的比率。（一般来说，若这个比率应不低于60%，则说明事先所设计的 测试用例是有效的。）

图6为RMDB系统在某一轮测试结束后测试用例评审时的跟踪统计工作表模版。

在每一轮测试工作结束后，测试人员要花一定时间对已发现的缺陷情况并结合已有的测试用例做测试用例的更新工作（若用户对系统的某些功能方面提出了新的需求，也是要进行相应测试用例更新操作）。这样一方面为下一轮的测试做好准备，另一方面可以有效的对测试用例进行科学化管理，从而提高测试用例的设计效率。

5 结束语

基于现代化软件开发规律，软件在其生命周期中会频繁地被修改和不断推出新的版本，修改后的或者新版本的软件会添加一些新的功能或者在软件功能上产生某些变化。随着软件的不断完善，软件的某些功能发生了演变，原有的测试用例可能会失去针对性和有效性，而另一些测试用例可能会变得过时，还有一些测试用例将完全不能运行。为了保证测试用例库中测试用例的有效性，还需要对测试用例进行维护。同时，被修改的或新增添的软件功能，仅仅通过重新运行以前的测试用例并不足以揭示其中的问题，有必要增加新的测试用例来测试这些新的功能或特征。因此，测试用例的维护工作还应包括开发新测试用例，这些新的测试用例用来测试软件的新特征或者覆盖现有测试用例无法覆盖的软件功能或特征。

参考文献：

[1] 朱少明.软件测试方法和技术[M].北京:清华大学出版社,2005.

[2] 郑人杰.计算机软件测试技术[M].北京:清华大学出版社,1995.

[3] Black R.测试流程管理[M].北京:北京大学出版社,2001.