软件测试用例的设计
上一篇 / 下一篇 2007-05-09 08:55:50 / 个人分类：我的BIOG
作者：王静兰
转载者：孙小勇
摘 要
一个项目最终呈现在用户面前的质量，与测试执行的程度与力度是密不可分的。测试用例设计的基本目的，是确定一组最有可能发现某个错误或者某类错误的一组测试数据。测试用例构成了设计和制定测试过程的基础，因此测试用例的质量在一定程度上决定了测试工作有效程度。一个好的测试用例使得测试工作的效果事半功倍，并且能尽早的发现一些隐藏的BUG，测试用例的设计是软件开发中的重中之重。
关键词：软件测试，测试用例，TESTCASE，用例设计
A test case is a series of tests used to determine whether one particular thing works properly. Often that means trying the same operation over and over again with little in the procedure.
A test case is a document that describes an input, action, or event and an expected response, to determine if a feature of an application is working correctly. A test case should contain particulars such as test case identifier, test case name, objective, test conditions/setup, input data requirements, steps, and expected results.
1 引言
1.1 测试用例在软件产品中的作用和意义
软件产品化之后给人们日常生活和工作带来了极大的便利。同样的，也使人们对软件产品的质量重视上升到了更进一步的高度。随着软件危机的不断出现以及人们对于软件更进一步的认识，测试的地位得到了前所未有的提高，并且人们意识到：测试开始的时间越早，软件的缺陷将越早被发现，带来整个软件开发中的成本也下降越多。软件测试是发现软件中缺陷的主要手段和唯一有效的方法。软件质量的重视度越高，软件测试工作在软件开发过程中就越重要。
完全覆盖测试又要求测试工作的力度和深度以及每一种现实中可能发生的操作都要保证正确，很多人觉得这个似乎是矛盾的。软件测试中永远不可能做到穷举测试，又想使得测试工作的效率达到最高，那么该如何兼顾工作量和效率的问题，往往成为测试工作中的瓶颈问题所在。如何测试，用什么方式来测试，在什么环境和什么样的条件下进行测试，测试的工作量和如何避免重复的测试，等等各种应该考虑的因素在测试工作中如何协调和同步，在测试用例中应该充分描述这些问题。
因此，软件测试工作中处于重中之重的测试用例的设计要求也随之上升到了更高的层次。测试用例不但构成了设计和制定测试过程的基础，而且测试的深度与测试用例的数量成正比。一般来讲，判断测试是否完全的一个主要评测方法是基于需求的覆盖，而这个又是以确定、实施和（或）执行的测试用例的数量为依据的；测试工作量与测试用例的数量成比例；测试设计和开发的类型以及所需的资源主要都受控于测试用例。这些使得测试用例在整个的软件开发过程中处于更加重要的地位。
1.2 测试用例的定义
测试用例是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。
Robert V.Binder是这样描述的，测试实例：输入、执行条件，及为一个特殊目标所开发的预期结果的集合。一个定义IUT（被测实现，即被测代码）及其环境、测试输入或条件，及预期结果的测试前状态的表示或实现。
1.3 测试用例应该包含的要素
首先测试用例应该包含软件或者项目名称、所服务的范围、背景、作者、编写时间等文档类信息；根据测试用例的定义和目的，测试用例的内容应该有：标题和用例编号、版本号、修改记录，针对目标和假设前提/可能发现的错误，输入数据/代码，测试步骤，预期输出和错误发现方法。
1.4 测试用例中需要注意的问题
每个测试用例清楚地阐述了正在进行评估的用例、用例场景、测试目标或条件的有关说明。每个测试用例都描述了预期结果和评估该结果的方法。
对于每个测试需求，在测试用例中需要考虑在正面测试和负面测试的条件下的测试，或者通过确定两个测试用例来实现，一个测试用例代表预期的条件，它可用于核实行为是否正确或符合预期（正面测试）。另一个测试用例代表不可接受的、异常的或意外的条件，它可用于核实测试需求是否未以非预期方式执行（负面测试）。
在一般情况下，对于测试的每个需求来说，至少要有一个正面测试用例和为数较多的负面测试用例，以此来检查在异常情况下系统能否正常处理，或者用户进行了错误的操作时的友好提示等等。
测试用例已被确定用来执行测试目标中所有的产品需求行为，包括（视情况而定）：功能、数据确认、业务规则实施、测试目标工作流程或控制、数据流、对象状态、性能（包括工作量、配置和强度）、安全性/可访问性、兼容性。每个测试用例都说明或者/代表一个唯一的输入集或事件顺序，它能够产生唯一的测试目标行为，复审那些产生相同行为的测试用例并判定它们是否等同，即它们是否都执行测试目标中的路径。
每个测试用例（或每组相关的测试用例）确定初始的测试目标状态和测试数据状态。测试用例名称和/或ID与测试工件命名约定一致。
2 测试用例的设计方法概述
根据测试的方法分为黑盒测试和白盒测试，相应的测试用例的设计方法也可以分为针对黑盒测试的用例设计和针对白盒测试的用例设计。
至今提出的测试用例设计方法有许多，下面简要的介绍一些比较重要的、常用的方法。
2.1 白盒测试的测试用例设计方法
2.1.1逻辑覆盖
逻辑覆盖包括：语句覆盖、判定覆盖、条件覆盖、判定－条件覆盖、条件组合覆盖、路径覆盖，各自的定义简略描述如下：
语句覆盖就是设计若干个测试用例，运行被测程序，使得每一可执行语句至少执行一次。
判定覆盖就是设计若干个测试用例，运行被测程序，使得程序中每个判断的取真分支和取假分支至少经历一次。
条件覆盖就是设计若干个测试用例，运行被测程序，使得程序中每个判断的每个条件的可能取值至少执行一次。
判定－条件覆盖就是设计足够的测试用例，使得判断中每个条件的所有可能取值至少执行一次，每个判断中的每个分支至少执行一次。
条件组合覆盖就是设计足够的测试用例，运行被测程序，使得每个判断的所有可能的条件取值组合至少执行一次。
路径测试就是设计足够的测试用例，覆盖程序中所有可能的路径。
2.1.2基本路径测试
基本路径测试方法把覆盖的路径数压缩到一定限度内，程序中的循环体最多只执行一次。
它是在程序控制流图的基础上，分析控制构造的环路复杂性，导出基本可执行路径集合，设计测试用例的方法。设计出的测试用例要保证在测试中，程序的每一个可执行语句至少要执行一次。
2.2 黑盒测试的测试用例设计方法
2.2.1等价划分
所谓等价类划分是指一套被选择的值，这些值分别代表了许多众多的可能输入值，程序对其处理的方式都是一样的。
等价类划分的方法作为继边界值分析方法之后补充的测试用力设计试用的一种方法。划分等价类、确定测试用例
等价类划分是一种典型的黑盒测试方法，使用这一方法时，完全不考虑程序的内部结构，只依据程序的规格说明来设计测试用例。
等价类划分方法把所有可能的输入数据，即程序的输入域划分成若干部分，然后从每一部分中选取少数有代表性的数据做为测试用例
等价类的划分有两种不同的情况：
有效等价类：是指对于程序的规格说明来说，是合理的，有意义的输入数据构成的集合。
无效等价类：是指对于程序的规格说明来说，是不合理的，无意义的输入数据构成的集合。
在设计测试用例时，要同时考虑有效等价类和无效等价类的设计。
2.2.2边界值分析
在设计测试用例确定输入和输出参数时，大多数情况下都是用边界值分析方法，采用边界值分析设计的测试用例发现程序错误能力最强。
边界值分析也是一种黑盒测试方法，是对等价类划分方法的补充。
人们从长期的测试工作经验得知，大量的错误是发生在输入或输出范围的边界上，而不是在输入范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。
2.2.3错误推测法
人们也可以靠经验和直觉推测程序中可能存在的各种错误，从而有针对性地编写检查这些错误的例子。这就是错误推测法。
错误推测法的基本想法是：列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据它们选择测试用例。
2.2.4因果图
如果程序的功能说明中含有输入条件的组合情况，则一开始就可以选用因果图法。如果在测试时必须考虑输入条件的各种组合，可使用一种适合于描述对于多种条件的组合，相应产生多个动作的形式来设计测试用例，这就需要利用因果图。
因果图方法最终生成的就是判定表。它适合于检查程序输入条件的各种组合情况。
3 测试用例的评审及维护
3.1测试用例的评审
测试用例在设计之后需要经过评审，需要评审的内容如下：
用例是否完整？是否每一个需求都有其对应的测试用例来验证？
是否每一个设计元素都有其对应的测试用例来验证？
事件顺序，能否产生唯一的测试目标行为？
是否每隔测试用例都阐述了预期结果？
是否每个测试用例（或每组相关的测试用例）都确定了初始的测试目标状态和测试数据状态？
测试用例是否包含了所有单一的边界？
测试用例是否包含了所有的业务数据流？
是否所有的测试用例名称，ID都与测试工件命名约定一致？
测试用例评审时需要参加的人员：项目经理，系统分析员，测试设计员，测试员
相关阅读:
- 2007.4.28新决定 (sunxy5291, 2007-4-28)
- 软件测试的常识 (sunxy5291, 2007-5-08)
