全程软件测试（一一五）：编写测试用例—读书笔记

一、 测试用例的定义和内容

1 测试用例的定义

对一项特定的软件产品进行测试任务的描述，指定输入，预期结果和一组测试项的执行条件的文档。

体现测试方案、方法、技术和策略；

内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等。

2 测试用例的元素

测试用例必须给出测试测试目标、测试对象、测试环境要求、输入数据和操作步骤，概括为 5W1H。

测试目标：Why——为什么而测？功能、性能、可用性、容错性、兼容性、安全性等。

测试对象：What——测什么？被测试的项目，如对象、函数、类、菜单、按钮、表格、接口、整个系统等。

测试环境：Where——在哪里测？测试用例运行时所处的环境，包括系统的配置和设定等要求，也包括操作系统、浏览器、通讯协议等单机或 络环境。

测试前提：When——什么时候可是测？测试用例运行时所处的前提或条件限制。

输入数据：Which——那些数据？在操作时，系统所接受的各种可变化的数据，如数字、字符、文件等。

操作步骤：How——如何测？执行软件和程序的先后次序步骤等。如打开对话框、点击按钮等。

二、 为什么需要测试用例

测试用例是测试人员在测试过程中的重要参考依据。

测试用例可以帮助实施有效的测试，所有被执行的测试都是有意义的，不要执行毫无意义的测试操作。

良好的测试用例不断地被重复使用，使得测试过程事半功倍。

在软件产品的开发过程中，开发人员不断的推出新的版本，测试人员需要对原有功能进行多次的回归测试，即使在一个版本中，也要进行 2～3 次的回归测试。这些回归测试，就要求能重复使用测试用例。

测试用例是一个知识积累的过程。

测试用例是一个知识传递的过程，能保持一致、稳定的测试质量

从项目管理的角度来说，测试用例的通过率是检验代码质量保证效果最主要的指标之一。

测试用例也可以作为评估测试人员进度、工作量以及跟踪/管理测试的工作效率的主要因素，从而更加合理地做出测试安排或调整。

三、 测试用例的写作说明

1 测试用例的模板/格式

2 测试用例的写作说明

2.1 用例编 /序

简单、唯一。

2.2 用例说明

也称测试点、检查点、测试概述、用例概述、测试说明；

用一句话对测试用例进行概述；

可以总结测试目的；

可以用疑问句表示；

可以用“检查、验证、测试”等字眼（如验证 QQ 默认安装）；

最好看到这句话就能知道如何测试；

尽量唯一（决策表可能会有重复的测试说明）；

用例执行多轮时，越往后执行可能越快，如果用例写得好，直接看概述就行。

2.3 初始条件

也称预置条件、前提条件；

初始条件要是一个状态，而且是静态的，如管理员已登录后台；

初始条件是第一步操作步骤之前的状态，不能太远，不用从头写到尾

很多项目中不写预置条件。

2.4 操作步骤

若对数据要求高，需要把数据分离出来；

步骤要都有序 ；

每一步用分 分开，最后用一个句 ；

每一步必须换行；

参数前加冒 （如用户名：admin）；

涉及按钮界面用【】、“”等成对符 间隔；

功能的详细用例步骤 4-6 步左右；

最后一步一定是个动作，不能写结果。

2.5 预期结果

是一个状态；

如果参考文档中有描述，原封不动的抄过来；如果文档中没有具体要求，则点要一致，可以有几个点，如 QQ 默认安装，应能启动、默认选项匹配等。

2.6 用例状态

通过、失败、阻塞、未执行、搁置、无效用例…

初始条件达不到时，一般用例状态设置为阻塞。

看如何执行用例，执行完关心什么来定。

2.7 优先级

用例的执行顺序。

3 案例

四、 测试用例的评审和管理

1 保证测试用例质量的方法

首先，要对用户需求、服务质量要求、产品特性有深刻且全面的理解

其次，采取正确、恰当的方法进行用例设计；

再者，按照测试用例的标准格式或规范的模板来书写测试用例；

最后，对测试用例的检查、评审，也是提高测试用例质量的主要且有效的手段。

2 测试用例的优先级

2.1 优先级的分类

2.2 如何设置测试用例的优先级

考虑成本、时间、人员等因素，兼顾测试的充分性和效率。

考虑用例的关联性。

考虑用例的干扰性。

3 测试用例评审要点

根据检查单或检查表（Check List）进行评审。

用例质量：遗漏用例、冗余用例、不清晰用例、错误用例、不可测用例等。

确定用例的优先级。

规划服务器和客户机。

用例的分工执行与人员安排。

记录评审过程，记录测试环境规划。

4 测试用例的维护

4.1 原因

通常情况下，测试用例需要更新，可能有以下几种原因：

先前的测试用例设计不全面或者不够准确。随着测试的深入和对产品规格说明书的深入研究，对某些功能、特性、逻辑等的理解越来越清楚、深刻

所发现的严重的软件缺陷没有被目前的测试用例所覆盖。

编写的测试用例不规范或者语句错误。

新的版本中有新功能的需求或者原有功能的增强而需要发生改动。

旧的测试用例已经不再适用，需要删除。

4.2 测试用例管理工具

Excel

Bugfree

ZenTao

ALM/QC

…

五、 用例设计与编写方法总结

1 通过测试

主要用于验证系统和它陈述的需求一致，确认软件至少能做什么，一般通过分析需求说明书来设计测试用例。

2 失败测试

纯粹为了破坏软件而设计和执行的测试案例，也称迫使出错测试。主要用于证明“一个系统不会做不需要它做的事情”。

3 随机测试

也称即兴测试（ad hoc testing），是指临时准备的、即兴的 Bug 搜索测试过程。

如果让一百万只猴子在一百万只键盘上敲一百万年，它们最终就可能写出莎士比亚话剧等巨著。

缺点：

1、无法度量随机测试的实际覆盖率。

2、许多测试都是冗余的。

3、测试数据因为是随机的，重复测试是不可能的。

4 应用群集效应

找到的软件缺陷越多，说明那里的软件缺陷越多，若在测试中发现大量的上边界条件缺陷，则在测试时应注重上边界。

程序员倾向于修复 告出来的问题，要保证除此之外可能存在的其他问题不会出现。

5 探索性测试

5.1 含义

是一种测试思维技术。

探索性测试是一种精致的、有思想的过程。

探索性测试强调测试设计和测试执行的同时性。

测试人员通过测试来不断学习被测系统，同时把学习到的关于软件系统的更多信息

通过综合的整理和分析，创造出更多关于测试的主意。

测试设计，测试执行，测试日志的记录似乎是无关紧要的工作。

测试人员必须根据测试章程在规定的时间内完成。

5.2 适合场合

没有或只有少量的有价值的文档；

常用于在时间压力下；

为补充合适的、正式和形式化测试。

6 如何选择用例设计与编写方法

先使用大纲法拆分功能；

在使用场景法、决策表设计测试用例。

如果程序的功能说明中含有输入条件的组合情况，则应在一开始就选用决策表法。

用等价类划分方法、边界值分析方法、错误猜测法补充测试用例。

执行测试时进行探索性测试或随机测试。

执行完测试用例后进行随机测试。