测试用例管理

1 测试用例概述

测试用例（Test Case）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。

测试用例构成了设计和制定测试过程的基础,测试的“深度”与测试用例的数量成正比例,随着测试用例数量的增加，您对产品质量和测试流程也就越有信心。测试用例是软件测试的核心,是软件测试的必须遵守的准则，更是软件测试质量稳定的根本保障。

如何以最少的人力、资源投入，在最短的时间内完成测试，发现软件系统的缺陷，保证软件的优良品质，则是软件公司探索和追求的目标。全面且细化的测试用例，不仅可以更准确地估计测试周期各连续阶段的时间安排，还能通过用例的覆盖率、通过率和执行测试用例的数量来有效评估软件质量和测试工作量。测试用例是测试工作的指导，所以做好测试用例管理和运维优化尤其重要。

2 测试用例设计

测试用例就是编写一组条件、输入，执行条件，预期结果并完成对特定需求或目标的测试，体现测试方案，方法，技术和策略的文档。测试种类繁多，针对不同类型的测试，测试用例的设计方式完全不同。如:性能测试的用例中需设计大量的测试运行场景，准备相应的性能指标供测试人员填写，并进行数据分析。

本章着重探讨的是功能测试中使用的测试用例，为避免混淆，方便叙述，后续未说明的测试用例均指功能测试的测试用例，有特殊需要之处将进行特别说明。

2.1 测试用例设计原则

测试用例设计应遵循以下原则：

1、全面性

➢ 用例中的测试点应保证至少覆盖需求规格说明书中的各项功能

➢ 应尽可能覆盖程序的各种路径 ➢ 应尽可能覆盖系统的各个业务

➢ 应考虑存在跨年、跨月的数据

➢ 应尽可能全面的考虑系统中各功能、业务的异常情况

2、正确性

➢ 用户输入的数据应与测试文档所记录的数据一致，预期结果应与测试数据发生的业务吻合

➢ 用户验证系统输入的实际数据应当满足需求规格说明书的需求

3、可操作性

➢ 测试用例中应写清测试的操作步骤，不同的操作步骤相对应的操作结果

4、规范性

➢ 所有测试案例的编写要求规范，对于所有被测的功能点，应用程序均应该按照需求说明书和相关技术规范中的给定形式，在规定的边界值范围内使用相应的工具、资源和数据执行其功能

5、符合正常业务惯例

➢ 测试数据应符合用户实际工作业务流程

➢ 兼顾各种业务变化的可能

➢ 要符合当前业务行业法律，法规

6、连贯性

➢ 对于系统业务流程来说，各个子系统之间是如何连接在一起，如果需要接口，各个子系统之间是否有正确的接口；如果是依靠页面链接，页面链接是否正确

➢ 对于模块业务流程来说，同级模块以及上下级模块是如何构成一个子系统，其内部功能接口是否连贯

7、仿真性

➢ 人名、地名、电话号码等应具有模拟功能，符合一般的命名惯例，不允许出现与知名人士、小说中人物名等雷同情况

8、容错性（健壮性）

➢ 程序能够接收正确数据输入并且产生正确（预期）的输出，输入非法数据（非法类型、不符合要求的数据、溢出数据等），程序应能给出提示并进行相应处理，尽量站在用户角度进行操作

2.2 测试用例设计规范

测试用例是测试的核心，整个测试环节以及测试结果分析均以测试用例为准，所以规范的测试用例能保证测试工作的正常开展。

2.2.1 测试用例命名规范

以功能模块和业务流程进行命名，一级目录使用个项目的顶级菜单名称来命名，二级目录使用顶级菜单下的二级菜单名称类命名，用具可根据名字判别该用例是测试那个模块的，各用例根据各用例的功能来命名，经理简介明了，同一目录下的用例名字字数最好相同。

2.2.2 测试用例编号规范

测试用例采用以下编号约定方式：

➢ 测试类型：用一个字母代表，F代表功能性测试，NF代表非功能性测试；

➢ 子系统：用一个字母代表，一般以测试子系统名称的第一个字母进行命名（大写），若测试子系统名称比较长，可进行简写，一般简拼不超过5个字母。

➢ 用例编号：用五位数字代表，从00001顺序编号。

2.2.3 模块功能测试用例划分

模块功能的测试用例在编写中采用树形目录来划分，树形目录按照模块功能来划分，第一级为系统名称，第二级为子系统名称，第三级为模块名称。当模块中有多个TAB页时，可列在第四级，目录最深为四级，若有更深层次的页面可提升到第四级中。 2.2.4 测试用例文档书写规范

1、测试用例模版

按常用测试用例模版，根据公司及项目需求设计出符合要求的统一标准的测试用例模版。

2、文档格式约束

文档模板：文档编制应严格依据本文档模板的格式要求。

引用描述格式：

➢ 《》

➢ 《》()

➢ 《》()

文字格式：

➢ Word样式，正文首行缩进

➢ 首行缩进2字符，宋体，小四，1.5倍行距，段前 0，段后 0

表格格式

➢ 列标题，Word样式，表格标题

➢ 列标题，首行缩进 无，居中，宋体，五号，单倍行距，段前 0，段后 0

➢ 列标题，重复标题行

➢ 表格正文，Word样式，表格正文 居左

➢ 表格正文，首行缩进 无，居左，宋体，五号，单倍行距，段前 0，段后 0

➢ 表格正文中的序号，Word样式，表格正文 居中

➢ 表格正文中的序号，首行缩进 无，居中，宋体，五号，单倍行距，段前 0，段后 0

图格式：

➢ Word样式，图居中 2.2.5 通用检查项

通用检查项列出一些包括页面功能、易用性、合理性等方面的内容，适合公司所有项目，供测试人员测试时参考。

2.3 测试用例设计方法

黑盒测试的目的是检查功能是否实现或遗漏，交互界面是否出错，数据库读取，更新操作是否出错，性能和特性是否得到满足。黑盒测试设计方法有等价类划分、边界值分析、因果图、判定表分析法、错误推测等方法，具体描述如下：

1、等价类划分法

把所有可能的输入数据（有效的和无效的）,即程序的输入域划分成若干部分（子集）,然后从每一个子集中选取少数具有代表性的数据作为测试用例。该方法是一种重要的,常用的黑盒测试用例设计方法。

2、边界值分析法

对输入或输出的边界值进行分析测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。

3、因果图法：

就是利用图解法分析软件输入(原因)的各种组合和输出条件(结果)之间的关系，以设计测试用例的方法。因果图法适合于检查程序输入条件的多种情况的组合，并最终生成判定表，来获得对应的测试用例。

4、判定表分析法

判定表是分析和表达多逻辑输入条件下系统执行不同操作的情况的工具。它能够将复杂的逻辑问题和多种条件组合的情况按照各种可能的情况全部列举出来，简明并避免遗漏。因此，利用判定表能够设计出完整的测试用例集合。

5、错误推测法

推测法主要依赖经验和直觉推测程序中所有可能存在和容易发生错误的特殊情况，来作出简单的判断甚至是猜测，给出可能存在缺陷的条件、场景等，从而有针对性的设计测试用例的方法。

6、状态迁移法 许多需求用状态机的方式来描述，状态机的测试主要关注在测试状态转移的正确性上。对于一个有限状态机，通过测试验证其在给定的条件内是否能够产生需要的状态变化，有没有不可达的状态和非法的状态，可能不可能产生非法的状态转移等。

7、流程分析法

将软件系统的某个流程看成路径，用路径分析的方法来设计测试用例。根据流程的顺序依次进行组合，使得流程的各个分支都能走到。

8、正交实验设计法

正交试验设计发是从大量的试验点中挑选出适量的、有代表性的点，应用依据伽罗瓦理论导出的“正交表”，合理的安排实验的一种科学的实验设计方法。

9、异常分析法

系统异常分析法就是针对系统有可能存在的异常操作、软硬件缺陷引起的故障进行分析，依此实际测试用例。主要针对系统的容错能力、故障恢复能力进行测试。

10、接口间测试

测试各个模块相互间的协调和通信情况，数据输入输出的一致性和正确性。

11、数据库测试

依据数据库设计规范对软件系统的数据库结构、数据表及其之间的数据调用关系进行测试。

12、可理解（易操作）性

理解和使用该系统的难易程度（界面友好性）。

13、可移植性

在不同操作系统及硬件配置情况下的运行性。

2.4 测试用例包含内容

测试用例是测试人员执行测试时的重要参照标准。因此，测试用例必需使测试人员能够明确理解，并能够依据测试用例的描述执行测试。为此，一个设计良好的测试用例应当包括如下几个关键字段：

1、用例编号(testcaseIndex)，一个软件项目可能拥有数量庞大的测试用例。应根据项目设计一个良好的用例编号体系，那么通过用例编号，便可对测试用例进行快速定位，查询时事半功倍。

2、用例名称(testCaseName)，用例名称的编写应使用最精简的文字，描绘出用例的全貌。编写良好的用例名称如同书籍的目录，能够帮助阅读者整理思路，定位用例。

3、前置条件(precondition)，复杂工作流软件自动化测试方法的研究第二章软件测试理论与技术基础前置条件指测试执行者在执行测试用例的操作步骤前，必须完成的准备工作。常见的前置条件有:系统的配置、权限的设置、数据的准备、输入条件限制、前置工序的执行等。

4、测试步骤 (Teststep)，测试用例中，每个操作均可设计为一个步骤。一个测试用例由一个或多个测试步骤组成。常见可将测试步骤分为正常步骤和容错步骤。正常步骤指普通用户为了实现正常功能，进行的普遍的、正确的、系统期待的操作。正常步骤描述的操作通常在需求文档中会有明确的说明，也是程序需要实现的主要功能。容错步骤指用户有意或无意进行的一些错误的、甚至于有破坏性的操作。对此类错误操作，系统应有足够的容忍性，进行一些友好的提示、阻止或处理，而不是产生异常。

需求文档中，通常会对正常步骤进行明确定义。因此，正常步骤是严谨的，甚至是唯一的，编写者的发挥空间非常狭小。容错流程恰恰相反。一个思维活跃、经验丰富的测试人员在编写容错步骤时，能够考虑到各类不同的容错步骤，其编写出的测试用例也是全面、广泛而又犀利的。容错流程的编写深度与广度能够很好的反映编写者的技术实力。综上，一个编写良好的测试用例中应该包括两部分内容：描述准确的正常步骤，以及广泛深入的容错步骤。

5、步骤描述(Deseription)，步骤描述是测试步骤的主体，是测试人员执行测试时的重要阅读对象。因此，测试步骤必须表述详细，描述清晰，用语必须规范、严谨而又客观。最基本的要求是能够使其他人理解，并能正确的执行编写者期望的操作。

6、期望结果(〔 xpeetedRests)，期望结果是执行测试时，测试者所进行比对的标尺，是一个测试步骤是否通过的标准答案。期望结果必须要保证其正确性。错误的期望结果带来的后果是严重的，不在此赘述。