软件测试用例的设计

作者：王静兰

摘  要

一个项目最终呈现在用户面前的质量，与测试执行的程度与力度是密不可分的。测试用例设计的基本目的，是确定一组最有可能发现某个错误或者某类错误的一组测试数据。测试用例构成了设计和制定测试过程的基础，因此测试用例的质量在一定程度上决定了测试工作有效程度。一个好的测试用例使得测试工作的效果事半功倍，并且能尽早的发现一些隐藏的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都与测试工件命名约定一致？

测试用例评审时需要参加的人员：项目经理，系统分析员，测试设计员，测试员

3.2  用例库的更新维护

随着软件项目的开发，用例库的数据随着项目的进展动态变化也是需要维护的，主要包括：不合适用例的修改、冗余用例的删除、测试用例的增加，并对进行的操作在备注中署名修改者以及修改时间和改动原因。

4  测试用例实例

该测试案例是以一个B/S结构的登录功能点位被测对象, 该测试用例为黑盒测试用例。假设用户使用的浏览器为IE6.0 SP4。

功能描述如下：

1.    用户在地址栏输入相应地址，要求显示登录界面；

2.    输入用户名和密码，登录，系统自动校验，并给出相应提示信息；

3.    如果用户名或者密码任一信息未输入，登录后系统给出相应提示信息；

4.    连续3次未通过验证时，自动关闭IE。

图4-1登录界面

表4-1 登录界面测试用例

 参考文献：

[1] 郑人杰，殷人昆，陶永雷，实用软件工程（第二版），清华大学出版社，2001.10

[2] 杨文龙，姚淑珍，吴芸，软件工程；电子工业出版社，1997.11

[3] Robert V.Binder 著，华庆一，王斌君，陈莉 译，人民邮电出版社，2001.4

———————————————————————————–

[作者简介]

姓名：王静兰，女，2002年毕业于西安电子科技大学，计算机信息管理专业。

研究方向：软件测试管理

Email：peaceblue2001@163.com    

业余爱好：听音乐、爬山

漫谈软件性能测试技术

1. 引言

2. 软件质量

3. 软件性能测试技术

3.1 性能评测

3.2 负载测试

3.3 强度测试

4. 结束语

感悟测试驱动开发

1. 心灵震憾

2. 认清测试驱动开发

3. 实践测试驱动开发

 

  

 
　　编译之后，再次执行java junit.awtui.TestRunnertestQueue， 你将再次看到成功的绿色。

4. 一些遗憾

ClearQuest体系结构分析

1、数据层

1.1 SR数据库

1.2．R数据库

2、功能层

2.1．Maintenance Tool

2.2．Desinger

2.3．Web服务器

3、表示层

3.1．Web端访问

3.2．客户端访问

4、其他工具

4.1．Export Tool、Import Tool

4.2．Create Rational ClearQuest Evaluation Databases

4.3．ISQL、Sybase Cetral

点评性能测试工具OpenSTA.

（NameServer是安装OpenSTA的同时被安装的，正常运行时，可以在Windows任务栏的右侧看到图标 ,如果没有正常运行或者被停止了，图标显示为 。）

    检查OpenSTA NameServer状态为运行中，即图标为 ，

    下面，介绍如何在OpenSTA的测试脚本中引入变量，并给变量赋不同值的过程。网络应用系统一般都会有一个登陆网页，需要用户输入正确的用户名称和密码，经过系统验证后，用户才能进入该应用系统。在使用OpenSTA录制测试脚本时，输入的用户名称和密码将被OpenSTA记录在脚本中，录制完成后，可以在脚本文件中发现如下语句：

 这里“mike”、“ekim”就是录制脚本时登陆系统所输入的用户名称和密码。

（说明：OpenSTA测试脚本分三个部分, Environment、Definition、Code）

2、同时，在脚本的Definition 部分增加变量MY_USERNAME、MY_PASSWORD的定义：

CHARACTER*512 MY_USERNAME, LOCAL

    CHARACTER*512 MY_PASSWORD, LOCAL 

（注意，这两个变量范围是LOCAL型）

3、在发送登陆请求的语句“PRIMARY POST URI"http://demosite.opensta.org/gsg-v1 HTTP/1.0"ON 2…….”之前, 添加下列语句：

ACQUIRE MUTEX "LOGIN"

   NEXT USERNAME

   NEXT PASSWORD

   SET MY_USERNAME = USERNAME

   SET MY_PASSWORD = PASSWORD

RELEASE MUTEX "LOGIN"

其中：

AQUIRE MUTEX命令 的含义是： 将变量USERNAME 和PASSWORD 设置为用户名称和密码这两个变量选择值序列中的第一个值，并设置为local 形式，避免其他虚拟用户使用这个值；

REPORT  "USER ", MY_USERNAME

这样在测试执行完成后，Test Report Log中就可以看到打印出来的登陆用户名称。（是不是很简单？大家可以来试试）

作者在自己的测试脚本中进行实验，设置虚拟用户为3个，在登陆请求语句之后增加Report语句，以下是测试结束后Test Report Log信息

图1-8 测试结果

这里，“admin”、“sjcj”、“data”是被测试系统的三个用户名称。

----------------------------------------------------------------------------------------------

软件测试自动化实践

    首先为什么需要软件测试自动化？通过我这几年在微软的工作，可以感觉到一点，应该说自动测试，可以定义软件系统。从理论上来说应该是功能定义软件系统，软件系统是怎么工作的是从功能规格上来看的。但是你要是没有一套可以自动测试的测试程序存在，就没有办法验证我这个软件系统，就是修改了一点点，这个软件系统是不是和前面的软件系统一模一样，你没有办法验证，只有有一套自动系统，才能验证软件系统是不是还在原来的状态上。我觉得自动测试是非常重要的一个东西，微软一个软件系统如果没有跟着一套自动系统的话，这个软件系统基本上没有生命力，也没有办法进行更新，其他的各式各样的服务也没有办法进行。
    代码的复杂性也是不能小看的。现在测试一个代码时，所有的覆盖也是不可能的事情，每一个if…else…或switch语句就会把情况增加一倍，许多异常处理代码正常使用中不会碰到。许多与时序，死锁，资源冲突，多线程有关的错误很难捕捉到。除此之外，我们每一个版本又各自带SP与QFE，每个SP进 行组合，可以得到一个天文数字，如果没有一个自动测试系统的话，要测试整个产品，在所有不同的情况下进行工作的话，几乎是一个不可能的事情。你要是有一套自动测试系统，对未来 会有一种事半功倍的效果。
    微软内部有各种不同的测试，首先开发团队有自己的DRT或者Check－in Suites。不需要重装机器，要求速度快，对结果汇报要求简单，100％通过就行，所以不需要很强的分析的能力。与开发团队的关系近，在他们的源代码控制系统中。测试团队有测试的Lab BVT，所有的测试者都是在一起的，BVT的要求是需要重新安装机器，可以排除其他老的因素在上面的干扰。要求速度快，只运行0级测试，BVT也是在每天的构建结束以后自动运行BVT，结果汇报要求也是比较简单，一般来说需要100％，如果不是100％总是要找问题，前天的结果，大前天的结果应该都是100％。与测试团队的关系近，在测试团队的源代码控制系统中，由每日产品编译系统自动触发，全自动运行。
    还有自己常规的Lab Pass也需要重装机器，模拟最终用户的使用形式。需要使用每日编译结果，规模大，测试数多，环境要求也复杂，在这时候我们就会把整个刚才我讲的测试者引进来，一天可能需要测试不同版本，或者不同语言版等。对测试结果汇报与问题要求很高，因为这时候所有测试必须百分之百的通过，可能前天有这么一个问题，今天这个问题重新出现，是不是就可以忽略了呢？如果这个报告结果工具不能干这个事，每天必须要重新做。由测试团队根据需要产生。测试团队的个人Private Pass，由测试个人根据需要产生，不一定需要重装机器，对测试结果汇报要求很高，与测试团队的关系近，在测试团队的源代码控制系统中。
    一个具体自动化测试系统分析。微软内部有很多套自动化测试系统，比如OASys，是Office用的系统，还有Maddog，Bruce等等。这些系统演化到最后，总体结构大同小异。如果大家自主开发一套新的自动化测试系统，我估计大概十年以后结果就是这样的。以OASys系统为例，有Web服务器，是前台的Web UI。SQL Server后台服务器，有控制程序，客户机程序，客户程序就是在机器上装一个小的程序，一些结果报告与分析的程序，有文件服务器，存放每天的构建的结果，每次结果的Log file等等，除此之外所有的测试都是在机器池中进行，一系列差不多一样的机器，在一个测试里随时调用某一群或者某一些，或者某一个机器进行使用。

   具体模块的功能:
   文件服务器是存放每日的结果，存放每一个Run的logfile。比如你需要安装什么东西，需要什么样的后台背景。
   SQL Server存放有关的Setup参数，存放所有与测试有关的参数，存放所有Client机器的情况，是什么样的机器，多少内存，系统时间是什么，现在在干什么等等 ，所有机器的情况都存在这里；还存放所有Run Pass的总体结果，运行数，通过率，运行机器名等……
    Web服务器是Web前台，等于说是一个Web配置。测试团队使用后台服务器的入口，好处就是只需要IE就可以运行，零安装，易集中更新。可以查询并修改所有存放在SQL Server中的参数，可以产生、查询并触发Lab Run，可以查询Lab Run进展状况，总体结果等。 还可以查询并调整客户机的状态，所安装的OS，程序等。
    机器池是几十台一样或比较接近的轻型机器，拥有操作系统或文件系统的镜像程序，可以进行自我更新。
    控制器程序，从SQL Server中读取工作数据，产生工作脚本，并把工作按客户机参数分配给客户机运行，当运行结束时，从Client得到结果并更新SQL Server，分为机房控制器与个人控制器等。Lab controller主要用于控制Lab里的Machine Pool，Private controller主要用于控制Office里的测试团队成员个人的机器。控制器程序应具有动态分配任务的功能，控制器程序应具有Load Balance的功能，控制器程序应能根据Lab Run的优先级与机器资源最优化的分配工作。比如说你有一个自动测试，一个自动化测试每次在Run的时候并不是只有一个测试，同时进行的可能有三到四个同时进行，有的Lab Run会进展的很慢，有些优先级很高。动态分配的功能是非常重要的，根据你的Lab Run的优先级，决定给你分配多少资源进行运行，这是非常重要的系统。还需要多少时间也是一个比较重要的功能，如果你有以前的数据，比如上次Lab Run以后，就知道每一个测试需要Run多少时间，把总体时间加起来，可以看到在今天的构建上还剩下多少时间。
    客户机程序。这个程序是一个非常小，非常轻型的程序，是运行在各个小的Client上面的，几乎是零安装，就是一个小程序，非常轻巧，因为他几乎不依靠于任何模块，可在裸机上运行，在微软里所有的模块都可能是需要测试的模块，如果客户机上运行的程序需要ADO这个东西，我们就需要测试这个ADO。可以用于完成控制器交给的任务并记录全过程，非常稳定，不会死机，并能截取大部分的异常情况。可以截屏，TimeOut，所有的系统都是在Lab自动运行的，全部是一些机器，没有人的。自动化运行系统很快，等于说一天24小时不停的进行。
    结果报告与分析程序，安装于测试团队成员的主机上。查询数据库并显示所要Run的状态，通过率，还需要时间等。进行简单的运行操控，如重新运行，指定主机运行等。最主要的是自动分析运行的结果文件，比较不同之处，列出改进与恶化的Test Case。刚才我讲的每天可能有成千成万的结果需要分析，成千成万的结果可能有很大一块早就已经分析过了，不想重新看这些结果，就要进行比较。各种各样的情况都能读出来，和存入的结果进行比较，得出新的需要分析的措施，你已经看过这些措施就不用管它了。这个程序分析完错误以后，可以输入失败错误的原因。提供结果文件的链接，Bug DataBase的链接，提供进一步分析结果的工具。记录Test Case失败的原因，并可直接输入与跟踪Bug号，当结果分析完毕，可记入为基准结果，以便于未来运行结果的比较。
    我们是怎样使用这一套系统的。首先一个测试经理得到一个测试的任务，比如说Windows 2000的任务，他可以把这个任务告诉一个人，这个人应该是测试团队的成员(LRF)担任，这个人干的活每次根据这些东西产生一些Run，要知道这个Run进入什么状态，是不是很成功等等，协助整个Run能够很平和的进行。这个人测试团队也不是有很多人愿意干这个活，大家就轮流干这个事情。LRF根据需求在Web UI用模板产生相应的Run，填入OS要求，语言要求，运行优先级，应完成时间等，把这些东西都输入进去。这个Run被控制器程序得到，得到以后就根据优先级，完成时间，可用机房机器数，合乎要求的机器数，测试总量等来分配任务。机房客户机得到任务，清理自己，安装要求的程序与模块，从文件服务器拷贝测试运行程序，执行测试并拷回结果。
    LRF通过Web UI跟踪Lab Run进展，检查有无重大问题，检查运行进展能否按时完成并作及时的调整，当Lab Run接近尾声，email测试团队验证各自结果。可以说测试者本身一般不会监测Lab Run进行。测试团队成员收到email打开我们刚才讲的结果报告与分析程序，最主要是新的错误，新的错误比如说是Bug，产生一个很小的Code，重现这个错误。
    测试程序的问题，测试程序本身Code上的问题，你要修改你的测试程序等等。如果是对于客户机安装的问题，一天整个系统每台不同的机器都是一个问题，比如今天XP统统都通过了，比较简单。最后测试经理对所有的结果汇总，也是在结果报告程序进行的，大家把成果分析完以后，测试经理自动产生一张总报表，会通过这个数据决定我们这个产品怎么办，不光是在最后汇总的时候用。
    做一个很快的回顾，对于一套测试自动化系统来说，对一个成熟的测试团队来说是非常重要的东西。如果一个测试团队如果没有一个完整的测试系统来说，没有办法进行一个测试。一个新开发的测试自动化系统，尽量通用化。我们的测试系统，什么都能做，可以看他系统设计的模块，并不是为了测试什么东西而设计，可以测试任何东西，所以Office这么大一个产品，里面任何东西都是在测试系统上测试，测试系统需求非常简单。对自动化测试本身来说，是非常简单的一个东西，什么都不知道，只知道产生一个结果，运行结果拷回去就完了。还有一些控制，控制我刚才讲的动态分配资源的问题。如果你要是机器数不够，这就是自动化测试控制，但是要测试什么东西，完全是由测试人员自己决定，所有自动的脚本都是自己编的，你就是存到文件服务器上就行了。每个测试自动化系统每一板块各有侧重，不必大而全。从测试自动化系统整个来说，一开始的前期投入可能大一些，大家可以看到，你要建立整套测试自动化系统，每个系统想方设法自动化、模块化，刚开始投入非常多，长远来说是很有利的。如果手工测试的话，后台那么多不同的应用程序，有各种不同XP的情况，不同语言的情况下，如果都用手工来做几乎不可以想象。如果有测试自动化系统，只要开发一次自动化以后，所有其他的机器都是自动运行的，不用再管他了。所以他对鼓舞整个团队的士气是非常重要的。一个测试者一天的工作，对测试结果来说非常简单，只要看一下每天的新的情况就完了，其他的事情都不用管。自动化测试对后期软件维护来说也是非常重要的。自动测试系统是什么都能测试，不管干什么都可以测试，针对你产品所有的测试自动化起来，如果只有一个版本可能是不行的，微软所有的产品Office已经有十二个版本了，这么多的版本程序来说，如果没有自动测试是难以想象的。如果有自动测试就可以同步测试使用，这样就可以达到事半功倍的效果，很快可以验证，可以避免重复劳动。自动测试定义软件系统，如果一个软件系统没有自动测试的话，后期维护，下一版本的发行都是难以想象的一件事情。

软件测试过程的持续完善

2．完善测试过程策略

2.1． 双效合一，不断进步

2.2． 结队编程，提前测试

2.3． 善于总结，提高效率

３．结论

软件测试组织与方法

1. 软件生存周期

2. 测试的过程与方法

2.1、 测试的目的

2.2、测试的过程

2.3．测试方法分析

3. 测试人员组织

3.1、沟通能力

3.2、技术能力

3.3、自信心

3.4、外交能力

3.5、幽默感

3.6、很强的记忆力

3.7、怀疑精神

3.8、自我督促

3.9、洞察力