软件测试管理方法（四）——软件测试用例设计与管理

0.测试用例

测试用例（Test Case）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。其本质是从测试角度对被测对象的功能和各种特性的细节展开。测试用例=输入(数据+步骤)+输出+执行条件(环境等)

输入：包括输入数据以及操作步骤。数据尽量模拟用户输入，操作步骤要清晰简洁。执行条件：指测试用例执行的特定环境和前提条件。预期结果(输出)：在指定的输入和执行条件下的预期结果。注意：预期结果并不只是程序的可见行为。

测试用例举例：

测试用例编号	测试项目	测试标题	重要级别	预置条件	输入	执行步骤	预期输出
ZCGL-ST-SRS001-001	登录功能测试	登录界面文字正确性验证	低	登录页面正常显示	打开登录页面	打开登录页面	界面显示文字和按钮文字显示正确

将软件测试活动进一步转化为可实施、可管理的行为，跟踪测试需求，避免测试遗漏，提升测试的复用率(不同人，同一项目，同类项目)。

1.用例设计

测试方法有黑盒测试和白盒测试两大类，每类又有不同的测试用例设计方法：

黑盒测试被称为功能测试或数据驱动测试。在测试时，把被测程序视为一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下进行。黑盒测试用例设计方法包括等价类划分法、边界值分析法、错误推测法、因果图法、判定表法等。

等价类划分法：把所有可能的输入数据，即程序的输入域划分为若干部分（子集），然后从每一个子集中选取少数具有代表性的数据作为测试用例。

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

因果图法：一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况。

决策表(判定表)法：决策表法适用于分析和表达多逻辑条件下执行不同操作的情况，它能够将复杂的问题按照各种可能的情况全部列举出来，简明并避免遗漏。因此，利用决策表能够设计出完整的测试用例集合。

错误推测法：基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法。

白盒测试也称结构测试或逻辑驱动测试，是针对被测单元内部是如何进行工作的测试。它根据程序的控制结构设计测试用例，主要用于软件或程序验证。白盒测试又有静态测试和动态测试之分。

静态测试主要是指代码走查和分析。静态方法是指不运行被测程序本身，仅通过分析或检查项目的需求文档、设计文档、源程序的语法、结构、过程、接口等来检查程序的正确性。对需求规格说明书、软件设计说明书、源程序做结构分析、流程图分析来发现错误。静态方法通过程序静态特性的分析，找出欠缺和可疑之处，例如不匹配的参数、不适当的循环嵌套和分支嵌套等。

动态测试主要是对代码的运行测试，包含多种覆盖方法：

1.语句覆盖：要求设计足够多的测试用例，使得程序中每条语句至少被执行一次。

2.判定覆盖(分支覆盖)：它要求设计足够多的测试用例， 使得程序中每个判定至少有一次为真值，有一次为假值，即：程序中的每个分支至少执行一次。每个判断的取真、取假至少执行一次。

3.条件覆盖：要求设计足够多的测试用例，使得判定中的每个条件获得各种可能的结果，即每个条件至少有一次为真值，有一次为假值。

4.判定/条件覆盖：设计足够多的测试用例，使得判定中每个条件的所有可能结果至少出现一次，每个判定本身所有可能结果也至少出现一次。

5.组合覆盖：要求设计足够多的测试用例，使得每个判定中条件结果的所有可能组合至少出现一次。

6.路径覆盖：设计足够的测试用例，覆盖程序中所有可能的路径。

2.设计原则

测试用例具有代表性、可判定性、可再现性、有效性。

3.用例评审

测试用例的设计主要根据测试需求，设计出的测试用例要按照规范的模式描述出来。测试用例的设计和编写是测试过程中的重要工作之一。根据测试需求编写测试用例

编写测试用例，首先要明确测试用例的属性。测试用例的属性有很多，除了最基本的前提条件，测试环境，输入数据，执行步骤，预期结果之外，为了管理方便还包括测试用例的编号、标题、所测需求、执行方式等。不同工具测试用例的属性大同小异，每个团队要根据自己的实际需要确定要使用的测试用例属性。

根据测试需求编写测试用例涉及：测试用例步骤描述的详细程度、测试用例的属性、提供测试用例编写的模板

编号	属性	属性描述
1	用例编号	一般为需求编号后紧跟001，002……
2	标题(测试目的)	对测试用例的描述，测试用例标题应该清楚表达测试用例的用途。比如 “ 测试用户登录时输入错误密码时，软件的响应情况 ”。
3	预置条件	测试的前提条件，比如先用管理员登录。
4	测试环境	测试的软件、硬件以及网络环境。
5	输入数据	描述测试用例的输入数据
6	执行步骤	测试用例的执行步骤
7	预期结果	测试用例的预期结果
8	附件	辅助附件文档，比如要输入的文档、图片等
9	对应的脚本[可选]	测试执行时的脚本
10	优先级	用例的优先级，一般核心功能或基础功能涉及的用例为高优先级
11	涉及到的需求	用例能测试到的需求点
12	实施类型	自动化、手工、半自动化
13	测试类型	UI测试、功能测试、接口测试、性能测试、兼容性测试、文档测试等
14	参考信息	需要参考的需求文档，相关标准等。
15	创建人	测试用例的创建者
16	创建日期	测试用例创建的日期
17	历史记录	测试用例修改的历史记录
	备注	其他说明

4.详略把握

在编写测试用例时会面临一个问题，测试用例步骤描述得详细程度要如何把握？理想的情况应该是测试用例详细记录所有的操作步骤，使一个没有接触过系统的人员也能执行该测试用例。描述过于详细：会大大增加测试用例的编写和维护时间，一旦测试环境、需求、设计或者实现发生了变化，测试用例都需要及时进行更新。过于简单：除了用例的编写者没有人能够看明白并执行。最终目的：只要能交代清楚，达到沟通的目的就可以了。

编写测试用例可以通过Excel、Word或者专门的测试管理软件；测试流程中应该定义测试用例的编写模板以及测试用例编写指南；如果团队没有专门的测试流程，则在测试计划中应该约定测试用例的编写模板以确保整个团队的测试用例格式统一。

测试用例设计完毕后，最好能够增加评审环节；参与人：需求人员、测试人员、开发人员；可能发现：错误、遗漏、冗余、不充分；

评审并不容易开展：测试用例数量比较多，内容比较细致，评审起来要花费的时间也比较多，以及对评审的重视不够往往不能达到预期的效果；只评审核心模块测试用例、将评审时间加入工作计划中；只评审测试要点

5.组织维护

组织方式应该方便跟踪、分配和管理：按照功能模块组织：将属于某模块的功能测试用例、性能测试用例、兼容性测试用例等一起编号、管理。按照测试类型组织：将所有功能模块的性能测试、兼容性测试分别编号、管理。实际项目中也可以依靠对测试用例的编号去管理。

测试用例完成后不是一成不变，不是一劳永逸。需要不断更新和维护，逐步完善：需求发生变化－维护用例与需求之间关系、设计发生变化－维护用例与设计之间的关系、发现测试遗漏、发现设计错误

6.执行管理

建立测试任务，为测试任务指定测试用例集合：设置测试任务的基本信息(开始结束时间、人员)、设置任务的汇报周期以及异常处理、为任务指定测试用例集、管理测试项的状态、管理测试执行的日期和时间。

7.统计分析

可以通过分析统计参数观察测试的效率、合理性：自动化比例、功能测试和非功能测试用例比例、测试通过率、正面和反面测试用例的比例、各模块测试用例分布

测试用例的自动化比例：自动化测试比例是评估测试自动化程度的重要指标，一般在进行测试计划时要考虑是否可以提升测试自动化程度。测试用例自动化率=自动化测试用例数量/测试用例总数量。

功能测试和非功能测试的比例：为了避免只关注功能测试而忽略非功能测试，该比例值可以标识对非功能测试的关注，如果比例过高则用例的设计可能存在不合理性。有时也会用非功能测试用例占总测试用例的比例来评估对非功能测试的关注。功能测试与非功能测试比例=功能测试的测试用例数量/非功能测试的测试用例总数量

测试用例通过率：测试执行完毕后，测试用例通过率是评估被测对象质量的重要指标，一般这个指标要在90%以上。测试用例通过率=测试通过的测试用例数量/总测试用例数量

正面测试用例与反面测试用例的比例：通过这一比例可以评估测试用例设计的完备性，如果比例过高则说明反面测试用例可能考虑不充分。

各模块测试用例分布：对各功能模块测试用例分布进行统计，可以根据经验和模块规模大小评估测试用例数量的合理性，一般可以通过表格、柱状图或饼状图来进行分析。

8.管理工具

Excel/word：适合小型项目；专门的测试用例管理工具：一般集成在测试管理工具和项目管理工具中；支持的功能：用例的录入、更新；用例的统计分析；用例的执行和结果记录