17测试用例设计-STMT

软件测试方法和技术-Ch.14测试用例的设计本章要解决的问题为什么我们要使用测试用例?测试用例有哪些基本元素组成?测试用例编写和设计时需要遵循哪些基本的原则?白盒测试用例和黑盒测试用例设计的基本方法测试用例设计，组织和测试过程组织之间的关系和实践过程。跟踪和维护测试用例。第14章软件测试用例的设计测试用例概述测试用例组织和维护白盒测试用例设计方法黑盒测试用例设计方法测试用例的组织和跟踪14.1测试用例的概述测试用例是测试执行的最小实体，是为特定的目的而设计的一组测试输入、执行条件和预期的结果。简单地说，测试用例就是一个文档，描述输入、动作、或者时间和一个期望的结果，其目的是确定应用程序的某个特性是否正常的工作，并且达到程序所设计的结果。1.测试用例的重要性如何以最少的人力、资源投入，在最短的时间内完成测试，发现软件系统的缺陷，保证软件的优良品质，则是软件公司探索和追求的目标。软件测试是有组织性、步骤性和计划性的，为了能将软件测试的行为转换为可管理的、具体量化的模式，需要创建和维护测试用例测试用例是测试工作的指导，是软件测试的必须遵守的准则，更是软件测试质量稳定的根本保障2.测试用例的作用有效性避免测试的盲目性可维护性可复用性可评估性可管理性3.测试用例设计书写标准标志符（Identification）测试项（Test

Items）测试环境要求输入标准（Input

Criteria）输出标准（Output

Criteria）测试用例之间的关联4.测试用例的组成元素与范例标识符：由测试设计过程说明和测试程序说明引用的唯一标识符测试项：描述被测试的详细特性、代码模块等，应该比测试设计说明中所列出的特性更加具体。如果测试设计说明说“计算器程序的加法功能”，那么测试用例说明会说“加法运算的上限溢出处理”。它还要提供产品说明书的引用信息或者测试用例所依据的其他设计文档4.测试用例的组成元素与范例输入说明：该说明列举送到软件执行测试用例的所有输入内容或者条件输出说明：描述进行测试用例预期的结果环境要求：执行测试用例所必需的硬件、软件、测试工具、人员等特殊要求：用例之间的依赖性Example示例5.为什么需要测试用例

在开始实施测试之前设计好测试用例，避免盲目测试并提高测试效率，减少测试的不完全性；

测试用例的使用令软件测试的实施重点突出、目的明确；

根据测试用例的多少和执行难度，估算测试工作量，便于测试项目的时间和资源管理与跟踪；减少回归测试的复杂程度5.为什么需要测试用例

在软件版本更新后只需修正少量的测试用例便可展开测试工作，降低工作强度、缩短项目周期；

功能模块的测试用例的通用化和复用化则会使软件测试易于开展，并随着测试用例的不断细化其效率也不断攀升；

根据测试用例的操作步骤和执行结果，可以方便地书写软件测试缺陷报告5.为什么需要测试用例可以根据测试用例的执行等级，实施不同级别的测试；为分析软件缺陷和程序模块质量提供依据；便于大型软件测试项目外包测试指导基础；·

总结：软件测试是有组织性、步骤性和计划性的，为了能将软件测试的行为转换为可管理的、具体量化的模式，需要创建和维护测试用例。6.良好测试用例的特征可以最大程度地找出软件隐藏的缺陷可以最高效率的找出软件缺陷可以最大程度地满足测试覆盖要求既不过分复杂、也不能过分简单6.良好测试用例的特征使软件缺陷的表现可以清楚的判定测试用例包含期望的正确的结果待查的输出结果或文件必须尽量简单明了不包含重复的测试用例测试用例内容清晰、格式一致、分类组织7.测试用例设计原则测试用例的代表性：能够代表并覆盖各种合理的和不合理的、合法的和非法的、边界的和越界的以及极限的输入数据、操作和环境设置等。测试结果的可判定性：即测试执行结果的正确性是可判定的，每一个测试用例都应有相应的期望结果。测试结果的可再现性：即对同样的测试用例，系统的执行结果应当是相同的。测试用例设计考虑因素具有代表性、典型性寻求系统设计、功能设计的弱点测试用例需要考虑到正确的输入，也需要考虑错误的或者异常的输入，以及需要分析怎样使得这样的错误或者异常能够发生考虑用户实际的诸多使用场景示例示例1：P.313示例2:P.3158.单个测试用例的质量要求具有可操作性具备所需的各项信息各项信息描述准确、清楚测试目标针对性强验证点完备，而且没有太多的验证点没有太多的操作步骤，例如不超过7步符合正常业务惯例。9.整体测试用例的质量要求覆盖率。依据特定的测试目标的要求，尽可能覆盖所有的测试范围、功能特性和代码。易用性。测试用例的设计思路清晰、组织结构层次合理，测试用例操作的连贯性好，使单个模块的测试用例执行顺畅。易维护性。应该以很少的时间来完成测试测试用例的维护工作，包括添加、修改和删除测试用例。易用性和易读性，也有助于易维护性。粒度适中。既能覆盖各个特定的场景，保证测试的效率；又能处理好不同数据输入的测试要求，提高测试用例的可维护性。14.2测试用例组织和维护测试用例的属性测试套件及其构成方法跟踪测试用例维护测试用例测试用例的覆盖率14.2.1测试用例的属性一些属性说明□目标性，包括功能性、性能、容错性、数据迁移等各方面的测试用例；□所属的范围，属于哪一个组件或模块□关联性，和软件产品特性相联系□阶段性，属于单元测试、集成测试、系统测试、验收测试中的某一个阶段□时效性，不同的版本所适用的测试用例可能不相同14.2.2

测试套件及其构成方法

建立合适的、可扩展的测试用例框架，从而借助这个框架能有效地组织众多的测试用例，包括对测试用例的分类、清晰的层次结构等实例测试用例套件

测试套件是由一系列测试用例并与之关联的测试环境组合而构成的集合，已满足测试执行的特定要求。通过测试套件，将服务于同一个测试目标、特定阶段性测试目标或某一运行环境下的一系列测试用例有机地组合起来按程序功能模块组织按测试用例的类型组织按测试用例的优先级组织测试类型与测试用例设计易用性测试配置测试压力测试文档测试国际化测试测试用例1测试用例2测试用例3测试用例1测试用例2测试用例3联机帮助测试软件更新测试根据测试类型设计

根据程序功能模块设计功能测试

回归测试

安装/卸载测试

联机注册测试文件操作测试测试用例1测试用例2测试用例3测试用例1测试用例2测试用例3数据备份测试测试用界例面的测组试织和测试过程的关系测试用例的组织和测试过程的关系测试套件应用场合

只是部分功能模块发生了变化，就可以创建由这些改动模块的测试用例构成的测试套件

在修改的模块中，也不需要选择所有的测试用例，针对不同的优先级创建不同的测试套件测试执行的第一阶段可以创建一个特定平台上的测试套件有必要为自动化测试、手工测试分别建立测试套件。

还可以建立和测试人员相对应的、不同平台或不同模块的测试套件

回归测试中，可以先运行曾经发现缺陷的测试用例，然后再运行从来没有发现的缺陷的测试用例14.2.3跟踪测试用例用例执行的跟踪:

跟上进度？测试人员每天能执行多少个测试用例？“通过、未通过以及未测试的”各占多少？不能被执行的原因是什么？测试用例覆盖率的跟踪14.2.3维护测试用例测试用例的维护是持续改进的过程测试用例维护流程示例14.2.5

测试用例的覆盖率测试用例本身：发现缺陷后补充的测试用例数/总的测试用例数需求、功能点覆盖率代码覆盖率14.3白盒测试用例设计方法什么是白盒测试

白盒测试也称为结构测试，把程序看作一个透明的盒子，测试程序的代码书写结构和逻辑问题白盒测试用例的设计方法

逻辑覆盖：以程序的内部逻辑结构为基础，分为语句覆盖、判定覆盖、判定-条件覆盖、条件组合覆盖等

基本路径测试：在程序控制流程的基础上，分析控制构造的环路复杂性，导出基本可执行路径集合，从而设计测试用例。白盒测试用例注意事项由于测试路径可能非常多，由于时间和资源问题，选出足够多的路径测试由于深入到程序编码，通常开发人员协助测试人员书写白盒测试用例14.4黑盒测试用例的设计方法测试内容模块中是否有功能遗漏或者逻辑错误模块接口是否存在问题是否有数据结构错误或者外部信息访问错误性能上是否满足要求14.4黑盒测试用例的设计方法分类：等价类划分法边界值分析法错误推测法因果图法功能图法1.等价类测试用例设计方法定义在分析需求规格说明的基础上划分等价类，列出等价类表。将程序可能的输入数据分成若干个子集，从每个子集选取一个代表性的数据作为测试用例，等价类是某个输入域的子集，在该子集中每个输入数据的作用是等效的。2.边界值测试用例设计方法Boundary-value

analysis程序的很多错误发生在输入或输出范围的边界上，因此针对各种边界情况设置测试用例，可以发现不少程序缺陷。边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。边界值测试用例设计方法.与等价划分的区别边界值分析不是从某等价类中随便挑一个作为代表，而是使这个等价类的每个边界都要作为测试条件。边界值分析不仅考虑输入条件，还要考虑输出空间产生的测试情况。Sin(x)3.错误推测法测试用例设计基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性地设计测试用例。错误推测方法的基本思想：列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例。错误推测法测试用例设计当软件要求输入时(比如在文本框中),不是没有输入正确的信息，而是根本没有输入任何内容，单单按了Enter键；输入数据和输出数据为0的情况；输入表格为空格或输入表格只有一行。这些都是容易发生错误的情况。可选择这些情况下的例子作为测试用例。4.判定表当需要描述的加工由一组操作组成，是否执行某些操作又取决于一组条件时，用判定表写加工逻辑将比较合适。5.因果图法测试用例设计Cause-Effect

Graphing定义：是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它

适合于检查程序输入条件的各种组合情况。6.场景设计方法现在的软件几乎都是由事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件

不同的触发顺序和处理结果形成事件流。这种

在软件设计方面的思想也可被引入到软件测试

中，生动的描绘出事件触发时的情景，有利于

测试设计者设计测试用例，同时测试用例也更

容易的得到理解和执行。提出这种测试思想的是Rational公司，在

RUP2000中文版当中有其详尽的解释和应用，用例场景贯穿其中。设计测试用例的策略选择

测试用例的设计方法不是单独存在的，具体到每个测试项目里都会用到多种方法，每种类型的软件有各自的特点，每种测试用例设计的方法也有各自的特点，针对不同软件如何利用这些黑盒方法是非常重要的。

在实际测试中，往往是综合使用各种方法才能有效提高测试效率和测试覆盖度，这就需要认真掌握这些方法的原理，积累更多的测试经验，以有效提高测试水平。

首先进行等价类划分，包括输入条件和输出条件的等价划分，将无限测试变成有限测试，这是减少工作量和提高测试效率的最有效方法。

在任何情况下都必须使用边界值分析方法。经验表明用这种方法设计出测试用例发现程序错误的能力最强。

对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度。如果没有达到要求的覆盖标准，应当再补充足够的测试用例。

对于业务流清晰的系统，可以利用场景法贯穿整个测试案例过程，在案例中综合使用各种测试方法。测试用例设计工具设计依据：软件需求文档软件设计文档通用设计工具：Microsoft

WordMicrosoft

ExcelMicrosoft

Access设计工具专用：IBM

Rational

TestManager

Mercury

InteractiveTestDirector常见问题：软件文档不全或没有文档

没有完成编码就开始设计测试用例测试用例的组成元素与范例测试用例编号ID测试用例标题测试的模块测试输入条件期望的输出结果其它说明ID类型标题测试步骤期望的结果说明001登录输入正确密码用户在登录界面输入正确的密码后，按回车键程序提示登录成功002登录输入错误密码用户在登录界面输入错误的密码后，按回车键程序提示输入密码错误，请重新输入003登录不输入的空密码用户在登录界面没有输入任何密码使密码为空后，按回车键程序提示用户没有输入密码，请输入程序应该告知用

户没有输入密码，而不是密码错误案例研究2：测试用户登录对话框的功能测试场景：在各种输入条件下，测试程序的登录对话框功能。用户名和密码的规则如下：用户名长度为6至10位（含6位和10位）用户名由字符（a-z、A-Z）和数字（0-9）组成不能为空、空格和特殊字符密码规则同用户名规则案例研究2：登录对话框的功能（续1）确定输入数据的情形：操作步骤预期结果输入正确的用户名和口令（均为6位），点击[OK]按钮进入系统输入正确的用户名和口令（均为10位），点击[OK]按钮进入系统输入正确的用户名和口令（均为6至8位之间），……进入系统用户名为空，……提示输入用户名不能进入系统用户名为空格，……提示无效用户名不能进入系统用户名小于6位，……提示用户名太短不能进入系统……………………案例研究2：登录对话框的功能（续2）确定具体的输入数据：“用户名”“口令”“预期结果”说明“user10”“pass10”进入系统正确的用户名和口令(6位)“user789”“pass789”进入系统正确的用户名和口令(7-9位)“user000010”“pass000010”进入系统正确的用户名和口令(10位)“”“pass”提示输入用户名不能进入系统用户名为空“空格”“pass”提示无效用户名不能进入系统用户名为空格“user”“userpass”提示用户名太短不能进入系统用户名小于6位“user0000011”“userpass”提示用户名太长不能进入系统用户名大于10位………………………………………………14.5测试用例的执行与跟踪执行与跟踪测试用例前，首先要好搭建测试环境，并定义测试用例的执行顺序，然后就可以执行与跟踪测试用例了。测试用例执行过程中，搭建测试环境是第一步。测试环境搭建之后，根据定义的测试用例执行顺序，可逐个执行测试用例。测试用例执行中应该注意以下几个问题：(1)全方位的观察测试用例执行结果(2)加强测试过程记录(3)及时确认发现的问题(4)与开发人员良好的沟通(5)及时更新测试用例(6)提交一份优秀的问题报告单