如何编写有效测试用例

转载

如何编写有效测试用例

测试用例，是一份关于具体测试步骤的文档，它描述了测试的输入参数、条件及配置、预期的输出结果等，以判断被测软件的工做是否正常。

设计、书写和执行测试案例是测试活动中重要的组成部分，测试案例一般由测试案例管理系统或工具进行管理。

1、编写测试用例的原则

测试用例的重要性是毋庸置疑的，它是软件测试所有过程的核心，是测试执行环节的基本依据。测试用例编写应该遵循的原则：

1. 测试用例要达到最大覆盖软件系统的功能点。
2. 测试用例对测试功能点、测试条件、测试步骤、输入值和预期结果应该有准确的定义。
3. 测试用例的设计应包括各类类型的测试用例。在设计测试用例的时候，除了知足系统基本功能需求外，还应该考虑各类异常状况、边界状况和承受压力的能力等。
4. 测试用例的管理。使用测试用例管理系统对测试用例进行管理。

特性：

一个好的测试用例应该具备较高的发现某个还没有发现的错误的可能性，而一个成功的测试案例可以发现某个还没有发现的错误，一般一个好的测试案例有如下特性：

1. 具备高的发现错误的几率
2. 没有冗余测试和冗余的步骤
3. 测试是 “最佳类别”
4. 既不太简单也不太复杂
5. 案例是可重用和易于跟踪的
6. 确保系统可以知足功能需求

测试用例不可能设计得完美无缺，也不可能彻底知足软件需求的覆盖率，测试执行过程里确定会发现有些测试路径或数据在用例里没有体现，那么过后该将其补充到用例库里，以方便他人和后续版本的测试。

2、如何编写测试用例

测试用例的信息有不少，能够根据实际的状况进行增删，通常来讲一个优秀的测试用例应该包含如下信息：

1.产品相关信息

1. 软件产品或项目的名称
2. 软件产品或项目的版本
3. 功能模块名
4. 功能描述
5. 测试平台这些信息建议能够在测试案例手工选择。

2.基本记录信息

1. 测试用例入库者
2. 测试用例入库时间
3. 测试用例更新者
4. 测试用例更新时间

这些信息建议能够由测试案例自动生成。

3.测试用例的属性

1. 测试用例ID：测试用例的ID（由案例管理系统自动生成，方便跟踪管理）
2. 测试用例名称：测试用例的名称
3. 测试功能点：测试的功能检查点
4. 测试目的：该测试功能点的测试目的
5. 测试级别：主路径测试、烟雾测试、基本功能测试、详细功能测试。

测试级别进行说明：

• 主路径测试：对照需求中重要模块和功能的最主要功能路径，主路径测试为设计探针模块，快速检查程序的可测试性（可测试性还包括安装测试是否成功）的主要依据的测试案例
• 烟雾测试：对照需求中全部模块的主要功能路径，主路径测试案例为烟雾测试案例的子集，烟雾测试为作回归测试的主要依据的测试案例。
• 基本功能测试：对照需求和整体设计中全部模块和功能的基本功能路径，基本功能测试为测试软件产品的非重要级别模块，书写彻底的自动测试脚本的主要依据。
• 详细功能测试：对照整体设计中全部模块和功能的功能路径，测试各个模块及功能各个层次，各类类型。详细功能测试案例为对重点模块，易发生错误的模块的主要依据

6.测试类型：功能测试、边界测试、异常测试、性能测试、压力测试、兼容测试、安全测试、恢复测试、安装测试、界面测试、启动/中止 测试、文档测试、配置测试、可靠性测试、易用性测试、多语言测试。
7.预置条件：对测试的特殊条件或配置进行说明
8.测试步骤：详细描述测试过程，案例的操做步骤建议少于15个。
9.预期结果：预期的测试结果

实例说明

例如：假设目前测试中国移动互联短信网关是否能正确发送短信给中国联通互联网关，测试用例的设计以下：
（1）测试用例ID：TC000001
（2）测试用例名称：中国移动全球通手机用户成功发送短信给中国联通手机用户
（3）测试功能点：中国移动全球通手机用户成功短信给中国联通手机用户，中国联通网关返回成功的状态报告
（4）测试目的：
A、中国移动互联短信网关可否正确处理全球通用户发送给中国联通用户的短信；
B、中国移动互联短信网关可否正确处理中国联通互联短信网关返回成功的状态报告的状况。
（5）测试级别：基本功能测试
（6）测试类型：功能测试
（7）预置条件：各网关实体按照组网图中的关系链接好，各实体之间的链接和通讯正常。
（8）测试步骤：
A、中国移动全球通手机用户（13901000001）给中国联通手机用户（13001000001）发送MO短信，内容为“测试”，目的号码填为中国联通手机号码；
B、中国联通互联短信网关把短信下发给中国联通用户成功后，给中国移动互联短信网关返回一个标识成功的状态报告。
（9）预期结果：
A、中国联通手机用户（13001000001）接收到了短信，内容为“测试”，源号码为中国移动全球通的用户号码（13901000001）；
B、在中国移动互联短信网关上产生SMO话单，其中“短消息发送状态”填0（表示成功），“源手机号码”13001000001，“目的手机号码”为13001000001。

3、测试案例的模版

下面是一个完整的测试用例的模版：

四.测试用例设计过程

对一个全新的产品来讲，首先须要了解的是产品需求文档和产品模块之间的关系。而后须要从需求文档中书写与全部需求相对应的主路径测试案例和烟雾测试案例， 这个时候也同时会包括必定的基本路径测试案例甚至是详细测试案例。在这个时候，由于对产品没有直接的使用感觉，书写测试案例要考虑面广而不要太过精细。继 续阅读产品功能定义文档，将全部的功能定义直接对应写相关的测试案例，这个时候，最好可以对程序的自己有必定的接触，加深对程序的了解，以便写出更好，更 全面的测试案例。最后，在实际测试中，还须要不断扩充，修改之前的测试案例，获得完整的基本功能测试案例和详细测试案例。若是对于一个已有必定或大部分案 例的产品来讲，无论测试者是否自己熟悉这个产品，其主要的任务就是阅读，检查需求及相关的变动，而后对原有的案例进行理解，扩充和修改。这就是案例的重用 /复用。设计测试案例的时候，须要有清晰的测试思路，对要测试什么，按照什么顺序测试，覆盖哪些需求作到心中有数。测试用例编写者不只要掌握软件测试的技 术和流程，并且要对被测软件的设计、功能规格说明、用户试用场景以及程序/模块的结构都有比较透彻的理解。

测试用例设计通常包括如下几个步骤：
一、测试需求分析从软件需求文档中，找出待测试软件/模块的需求，经过本身的分析、理解，整理成为测试需求，清楚被测试对象具备哪些功能。测试需求的特色是：包含软件需求，具备可测试性。

测试需求应该在软件需求基础上进行概括、分类或细分，方便测试用例设计。测试用例中的测试集与测试需求的关系是多对一的关系，即一个或多个测试用例集对应一个测试需求。
二、业务流程分析软件测试，不单纯是基于功能的黑盒测试，还须要对软件的内部处理逻辑进行测试。为了避免遗漏测试点，须要清楚的了解软件产品的业务流程。建 议在作复杂的测试用例设计前，先画出软件的业务流程。若是设计文档中已经有业务流程设计，能够从测试角度对现有流程进行补充。若是没法从设计中获得业务流 程，测试工程师应经过阅读设计文档，与开发人员交流，最终画出业务流程图。业务流程图能够帮助理解软件的处理逻辑和数据流向，从而指导测试用例的设计。

从业务流程上，应获得如下信息：

A、主流程是什么
B、条件备选流程是什么
C、数据流向是什么
D、关键的判断条件是什么
三、测试用例设计
完成了测试需求分析和软件流程分析后，开始着手设计测试用例。测试用例设计的类型包括功能测试，边

界测试，异常测试，性能测试，压力测试等。在用例设计中，除了功能测试用例外，应尽可能考虑边界、异

常、性能的状况，以便发现更多的隐藏问题。

黑盒测试的测试用例设计方法有：等价类划分、边界值划分、因果图分析和错误猜想，白盒测试的测试用

例设计方法有：语句覆盖、断定覆盖、条件覆盖、断定/条件覆盖、多重条件覆盖。在这里主要讨论黑盒测

试。在设计测试用例的时候可使用软件测试用例设计方法，结合前面的需求分析和软件流程分析进行设

计：

功能测试：测试某个功能是否知足需求的定义，功能是否正确，完备。

适合的技术：由业务需求和设计说明导出的功能测试、等价类划分

边界测试：对某个功能的边界状况进行测试。

适合的技术：边界值划分

异常测试：对某些功能来讲，其边界状况没法简单的了解或某些操做不彻底是正确的但又是可能发生的，

相似这样的状况须要书写相关的异常测试。

适合的技术：由业务需求和设计说明导出的特殊业务流程、错误猜想法、边界值分析、内部边界值测试、

性能测试：检查系统是否知足在需求中所规定达到的性能，性能主要包括了解程序的内外部性能因素。内部性能因素包括测试环境的配置，系统资源使用情况；外部因素包括响应时间，吞吐量等。

适合的技术：业务需求和设计说明导出的测试

压力测试：压力测试又称强度测试，主要是检查系统运行环境在极限状况下软件运行的能力，好比说给一个至关大的负荷或网络流量给应用软件兼容测试：测试软件产品在不一样的平台，不一样的工具，相同工具的不一样版本下功能的兼容性。

四、测试用例评审

测试用例设计完成后，为了确认测试过程和方法是否正确，是否有遗漏的测试点，须要进行测试用例的评审。

测试用例评审通常是由测试leader安排，参加的人员包括：测试用例设计者、测试leader、项目经理、开发工程师、其它相关开发测试工程师。测试用例评审完毕，测试工程师根据评审结果，对测试用例进行修改，并记录修改日志。

五、测试用例更新完善

测试用例编写完成以后须要不断完善，软件产品新增功能或更新需求后，测试用例必须配套修改更新；在测试过程当中发现设计测试用例时考虑不周，须要对测试用例 进行修改完善；在软件交付使用后客户反馈的软件缺陷，而缺陷又是因测试用例存在漏洞形成，也须要对测试用例进行完善。通常小的修改完善可在原测试用例文档 上修改，但文档要有更改记录。软件的版本升级更新，测试用例通常也应随之编制升级更新版本。测试用例是“活”的，在软件的生命周期中不断更新与完善。