软件测试设计指南.docx
- 文档编号:8516909
- 上传时间:2023-01-31
- 格式:DOCX
- 页数:18
- 大小:31.62KB
软件测试设计指南.docx
《软件测试设计指南.docx》由会员分享,可在线阅读,更多相关《软件测试设计指南.docx(18页珍藏版)》请在冰豆网上搜索。
软件测试设计指南
测试设计指南
自2005年6月1日起正式生效
XXX公司
编制:
审批:
文档修改历史
日期
版本
作者
修改内容
评审号
变更控制号
发布日期
2005-6-13
01.00.000
测试设计指南
1摘要
本文档主要介绍测试设计,包括测试用例、测试数据设计的方法,提供参考。
测试脚本的设计在测试执行指南中描述。
2测试用例设计
2.1概述
要使最终用户对软件感到满意,最有力的举措就是对最终用户的期望加以明确阐述,以便对这些期望进行核实并确认其有效性。
测试用例反映了要核实的需求。
然而,核实这些需求可能通过不同的方式并由不同的测试员来实施。
例如,执行软件以便验证它的功能和性能,这项操作可能由某个测试员采用自动测试技术来实现;计算机系统的关机步骤可通过手工测试和观察来完成;不过,市场占有率和销售数据(以及产品需求),只能通过评测产品和竞争销售数据来完成。
既然可能无法(或不必负责)核实所有的需求,那么是否能为测试挑选最适合或最关键的需求则关系到项目的成败。
选中要核实的需求将是对成本、风险和对该需求进行核实的必要性这三者权衡考虑的结果。
确定测试用例之所以很重要,原因有以下几方面。
测试用例构成了设计和制定测试过程的基础。
测试的“深度”与测试用例的数量成比例。
由于每个测试用例反映不同的场景、条件或经由产品的事件流,因而,随着测试用例数量的增加,您对产品质量和测试流程也就越有信心。
判断测试是否完全的一个主要评测方法是基于需求的覆盖,而这又是以确定、实施和/或执行的测试用例的数量为依据的。
类似下面这样的说明:
“95%的关键测试用例已得以执行和验证”,远比“我们已完成95%的测试”更有意义。
测试工作量与测试用例的数量成比例。
根据全面且细化的测试用例,可以更准确地估计测试周期各连续阶段的时间安排。
测试设计和开发的类型以及所需的资源主要都受控于测试用例。
2.2测试用例分类
测试用例通常根据它们所关联关系的测试类型或测试需求来分类,而且将随类型和需求进行相应地改变。
最佳方案是为每个测试需求至少编制两个测试用例:
一个测试用例用于证明该需求已经满足,通常称作正面测试用例;
另一个测试用例反映某个无法接受、反常或意外的条件或数据,用于论证只有在所需条件下才能够满足该需求,这个测试用例称作负面测试用例。
测试用例已被确定用来执行测试目标中所有的产品需求行为,包括(视情况而定):
1)功能
2)数据确认
3)业务规则实施
4)测试目标工作流程或控制
5)数据流
6)对象状态
7)性能(包括工作量、配置和强度)
8)安全性/可访问性
9)兼容性
2.3测试用例组成
测试用例最基本的元素包括:
测试用例ID、测试优先级、被测试对象介绍、测试范围与目的、测试环境、测试步骤、输入测试数据、期望输出结果。
1)所有的测试用例名称和/或ID都与测试工件命名约定一致。
2)每个测试用例都应该权衡成本、风险和对该需求进行核实的必要性,确定其优先级,保证优先级高的测试用例得以执行和验证。
3)每个测试用例都应该对应特定的测试对象,例如同一个测试用例对不同版本的同一测试对象其预期结果都未必相同。
4)每个测试用例(或每组相关的测试用例)确定初始的测试目标状态。
5)测试环境描述测试用例运行所基于的软硬件环境条件。
6)测试步骤描述执行该测试用例的详细动作及操作序列。
7)测试输入数据描述在执行该测试用例时,由主角输入的与之交互的对象、字段和特定数据值(或生成的对象状态)。
8)预期结果描述执行该测试用例完毕后得到的状态或数据。
2.4功能测试用例
用于功能性测试的测试用例来源于测试目标的用例。
应该为每个用例场景编制测试用例。
用例场景要通过描述流经用例的路径来确定,这个流经过程要从用例开始到结束遍历其中所有基本流和备选流。
在确定功能性测试用例时,确保满足下列条件:
已经为每个用例场景确定了充足的正面和负面测试用例。
测试用例可以处理用例所实施的所有业务规则,确保对于业务规则,无论是在内部、外部还是在边界条件/值上都存在测试用例。
测试用例可以处理所有事件或动作排序(如在设计模型的序列图中确定的内容),还应能处理用户界面对象状态或条件。
测试用例可以处理为用例所指定的任何特殊需求,如最佳/最差性能,有时这些特殊需求会与用例执行过程中的最小/最大负载或数据容量组合在一起。
2.5性能测试用例
性能测试用例的主要输入是补充规约,补充规约中包含了非功能性需求。
为性能测试生成测试用例时,请使用下列指南:
对于补充规约内阐明性能标准的各条说明都应确保至少要确定一个测试用例。
性能标准通常表示为时间/事务、事务量/用户或百分数的形式。
对每个关键用例,都应确保至少要确定一个测试用例。
关键用例是在上述说明中和/或在测试计划文档中确定的、必须采用性能评测方法来评估的用例。
与功能性测试的测试用例类似,通常对于每个用例/需求都会存在不止一个测试用例。
常见的情况是:
存在一个低于性能阈值的测试用例、一个处于阈值上的测试用例,还有一个测试用例高于阈值。
除了以上性能标准以外,确保已确定影响响应时间的特定条件,包括:
数据库的大小-存在多少个记录?
工作量-同时执行操作的最终用户的数量和类型,以及要同时执行的事务的数量和类型
环境特征(硬件、网件以及软件配置)
将用于性能测试的测试用例记录在类似于功能测试所使用的矩阵中。
2.6安全性/访问控制测试用例
角色和用例一同说明系统外部用户与系统所执行的动作之间的交互,以便为特定主角生成测试结果。
复杂系统包含许多角色,所以我们编制测试用例时必须确保只有指定执行用例的角色可以进行此操作,这一点非常关键。
在基于角色类型的用例事件流存在差别时,尤其如此。
2.7配置测试用例
在典型的分布式系统中,允许存在许多种受支持的硬件和软件组合。
为了核实测试目标在不同的配置情况下(如不同的操作系统、浏览器或CPU的速度)能否正常工作或执行,应该对此进行测试。
此外,测试还应涵盖构件的组合,以便检测在不同构件的交互中产生的缺陷。
例如,确保由应用程序安装的DDL版本不会与另一个应用程序需要的相同DDL的版本发生冲突。
采用下列指南来生成用于配置测试的测试用例:
确保对每个关键配置,应至少存在一个测试用例可用于对其进行确定。
这是通过确定测试目标的环境所要求的硬件和软件配置以及确定这些配置的优先级来完成的。
应确保最先测试最常见的配置,包括:
打印机支持
网络连接-局域网和广域网
服务器配置-服务器驱动程序、服务器硬件
台式机和/或服务器上安装的其他软件
所有已安装软件的软件版本
确保对于每个可能有问题的配置至少存在一个测试用例。
这些配置可能包括:
具有最低性能的硬件。
历史上存在兼容性问题的共驻内存的软件。
通过最慢的LAN/WAN连接访问服务器的客户机。
资源不足(缓慢的CPU速度、最小的内存或分辨率,磁盘空间不足等等)
2.8安装测试用例
安装测试需要核实测试目标可以在所有可能的安装情况下安装。
安装情况可以指首次安装测试目标,或是在装有较早版本的机器上安装测试目标的某个较新的版本或工作版本。
安装测试还应确保在遇到异常情况时(如磁盘空间不足),测试目标的执行情况仍可接受。
测试用例应包含以下各种软件的安装情况:
分发介质,例如磁盘、CD-ROM或文件服务器。
首次安装。
完全安装。
自定义安装。
升级安装。
客户机服务器软件的安装程序具备一组特定的测试用例。
不同于基于主机的系统,服务器和客户机上的安装程序是有所不同的。
因而,安装测试应执行构成测试目标的所有构件的安装,包括客户机、中间层以及服务器,这一点至关重要。
2.9其他非功能性测试用例
理论上,应找到所有必需的输入来生成测试用例模型、设计模型以及补充规约工件的测试用例。
不过,如果此时您需要补充已有的输入,那也不足为奇。
示例如下:
操作测试(用以检验在某次故障发生后以及在下一次故障发生前“较长时间”内软件的运行情况)的测试用例。
对性能瓶颈、系统容量或测试目标的强度承受能力进行调查的测试用例。
大多数情况下,您可以通过先前所确定的测试用例生成的某些测试用例来构建其变体或聚合关系体,借此来查找测试用例。
2.10单元测试用例
单元测试要求既测试单元的内部结构同时还要测试其行为特征。
测试内部结构要求了解实施单元的方式,基于这种了解的测试被称为白盒测试。
对单元行为特征的测试侧重于从外部可观察的单元行为,而不需要了解或考虑其实施方式。
基于这种方法的测试称为黑盒测试。
基于这两种方法所生成的测试用例的说明如下。
2.10.1白盒测试
理论上,应通过代码测试每一条可能的路径。
在所有这些非常简单的单元内实现这样的目标是不切实际或几乎是不可能的。
作为最基本的测试,应将每个决定到决定路径(DD路径)测试至少一次,这样可确保将所有语句至少执行一次。
决定通常是指if语句,而DD路径是两个决定之间的路径。
要达到这种程度的测试覆盖,建议您在选择测试数据时应使每个决定都可以用每种可能的方法来评估。
为达到上述目标,测试用例应确保:
每个布尔表达式的求值结果为true和false。
例如,表达式(a<3)OR(b>4)的求值结果为true/false的四种组合
每一个无限循环至少要执行零次、一次和一次以上。
可使用代码覆盖工具来确定白盒测试未测试到的代码。
在进行白盒测试的同时应进行可靠性测试。
2.10.2黑盒测试
黑盒测试的目的是为了在不了解单元将如何实施指定行为的情况下,对指定行为进行验证。
黑盒测试侧重并依赖于单元的输入和输出。
等价类划分是一种用来减少所需测试数量的技术。
对于每一个操作都应确定参数和对象状态的等价类。
等价类是一组值的集合,对这组值来说,对象的行为应类似。
例如,一个集合可有三个等价类:
空、若干元素以及满。
可使用代码覆盖工具来确定白盒测试未测试到的代码。
在进行黑盒测试的同时应进行可靠性测试。
接下来的两个小节说明了如何通过选择特定参数的测试数据来确定测试用例。
2.10.2.1基于输入参数的测试用例
输入参数是由某个操作使用的参数。
对于以下每个输入条件,都应通过使用每个操作的输入参数来编制测试用例:
每个等价类的正常值。
每个等价类的边界值。
等价类之外的值。
非法值。
请记住要将对象状态视作输入参数。
例如:
如果在对集合这个对象测试添加操作,您必须使用集合内所有等价类的值来测试添加操作。
所有等价类的值指的是:
充满元素的集合、有若干元素的集合、以及空集合。
2.10.2.2基于输出参数的测试用例
输出参数是某个操作所改变的参数。
某个参数既可以是输入参数也可以是输出参数。
根据以下每个条件选择输入,以便获得输出。
每个等价类的正常值。
每个等价类的边界值。
等价类之外的值。
非法值。
请记住将对象状态视为输出参数。
例如,假设您对某个列表测试删除操作,您必须选择输入值以便执行操作之后,列表为充满状态、具有若干元素或为空(采用它的所有等价类的值进行测试)。
如果对象受状态控制(根据对象的状态产生不同的反应),您应利用状态矩阵,如下图所示:
用于测试的状态矩阵。
您可以在此矩阵的基础上测试激励和状态的所有组合。
2.11开发场所的产品验收测试用例
产品验收测试是部署软件前的最后测试操作。
验收测试的目标在于核实软件是否已经准备就绪,而且可以由最终用户按软件设计来执行功能和任务。
产品验收测试通常不仅涉及执行软件以确认其是否准备就绪,还涉及交付给客户的所有产品工件,如培训、文档和包装。
为软件工件生成测试用例是按上文中说明的方式实现的。
测试用例可与上面确定的测试用例(正式)或某个子集(非正式)相同或类似,这取决于产品验收测试的正式程度。
不管测试用例的深度如何,应该在实施和执行产品测试之前对测试用例和产品验收计划达成共识。
2.12回归测试用例
回归测试比较同一测试目标的两个工作版本或版本,并将差异确定为潜在缺陷。
据此可假定:
新版本应该象早先版本一样操作,并确保并未因为版本的变化而带来缺陷。
理想状态下,您可能希望一次迭代内的所有测试用例都能在后续迭代内使用。
应遵照下列指导原则来确定、设计并实施测试用例,这些测试用例可以最大限度地发挥回归测试和复用的价值,同时将维护的成本减至最低:
确保测试用例只确定关键的数据元素(创建/支持被测试的条件所需的数据元素)
确保每个测试用例都说明或代表一个唯一的输入集或事件序列,其结果是独特的测试目标行为
消除多余或等效的测试用例
将具有相同的测试目标初始状态和测试数据状态的测试用例组合到一起
3测试数据设计
3.1概述
测试数据是在测试中使用的实际值(集合)或执行测试需要的元素。
测试数据创建要测试的条件(作为输入或预先存在的数据),并且用于核实特定的用例或需求是否已经成功得到实施(将实际结果和预期结果相比较)。
在测试设计活动中,需要确定和描述两个重要的工件:
测试过程和测试用例。
如果没有测试数据,这两个工件将无法实施和执行。
它们只是对条件、场景和路径的一些说明,而没有具体的值用来简明地确定它们。
测试数据虽然本身不是一个工件,但是它对测试的成败产生重要的影响,所以一般我们认为它是测试用例的一个组成部分。
没有测试数据,将无法实施和执行测试,尤其当要求测试数据作为以下值时:
作为创建条件的输入
作为评估需求的输出结果
作为支持(作为测试的前置条件)
因此,确定这些值是一个重要的工作,并且这项工作在确定测试用例后完成。
确定实际的测试数据时,必须说明处理测试数据的四个属性:
深度-测试数据中数据的容量或数量
宽度-测试数据中数据的变化程度
范围-测试数据与测试目标的相关性
构架-测试数据的物理结构
上述每个特征都将在以下部分进行更详细的说明:
3.2深度
深度是在测试中所使用数据的容量或数量。
深度是一个需要考虑的重要事项,因为数据太少可能无法反映现实生活的条件,而数据太多将难以管理和维护。
理想条件下,测试应首先使用一个小的支持关键测试用例的数据集(通常为正面测试用例)。
随着测试过程中信心不断增强,应该增加测试数据,直到数据深度完全体现出部署环境(或适当可行的范围)为止。
测试数据深度与用作输入和用于支持测试(在预先存在的数据中)的测试数据相关。
3.3宽度
宽度是指测试数据值变化的程度。
创建更多的记录就可以增加测试数据的深度。
虽然这通常是一个好的解决方法,但是它无法解决我们期望在实际数据中看到的数据真实变化的问题。
如果在测试数据中没有这些变化,我们可能无法确定缺陷(毕竟,不是每次从ATM提取的款项都是50.00美元)。
因此,测试数据值应该反映在部署环境内找到的数据值,例如提取10.00美元或120.00美元。
另外,测试数据应该反映现实世界的信息,例如:
包括头衔、数值、标点符号和后缀的名字:
Dr.JamesBandlin、Ms.SusanSmith和Rev.JosephP.Mayers
JamesJohnsonIII、StevenWilshire3rd和CharlesJamesEllsworth,Esq.
EllenJones-Smythe、BrianP.Tellstor
带有多地址行的地址,例如:
6500BroadwayStreet
Suite175
1550Broadway
Floor17
Mailstop75A
真实相符的城市代码(和国家代码)和电话号码
Lexington,MA,USA+017816762400
Kista,Sweden+46856628200
Paris,France+33130120950
为获得足够的数据宽度,测试数据值既可以是物理方式表示的真实数据,也可以是统计方式表示的真实数据。
这两种方法都具有使用价值,推荐使用它们。
为创建利用物理方法表示部署数据的测试数据,需要确定部署数据库中每个数据元素所允许包含的值(或范围),并确保在每个数据元素中,测试数据至少有一个记录包含每一个允许值。
例如:
帐号(范围)
PIN号
(整数)
帐户余额
(十进制)
帐户类型
(字符串)
(S)081200000000到
081299999999
(C)082900000000到
082999999999
(X)079900000000到
079999999999
0000-9999
-999,999.99到999,999.99
S、C、X
记录1
081208370293
8493
-3,123.84
S
记录2
081264938355
3558
8,438.53
S
记录3
082974830462
0352
673.00
C
记录4
079948961893
4896
493,498.49
X
以上矩阵包含了可以用物理方法表示可接受数据值的记录的最小数量。
对于帐号,在以上三个范围中每一个范围都有一个记录,所有的PIN号都在指定的范围内,几个帐户余额各不相同,其中包括一个负余额,并且每一个不同的帐户类型都存在相关记录。
以上矩阵对应最小的数据,最佳方案是使用每个范围界限上以及该范围内的数据值。
物理表示法的一个优点是,测试数据在数量和可管理性上都有限制,重点及导向目标是可接受值。
它的缺点是实际的、现实世界的数据并不是完全随机的。
真实数据往往具有可能影响性能的统计曲线,在采用物理表示法时将不会观察到这些特征。
统计测试数据表示法是指反映了生产数据(在相同百分比下)统计抽样的测试数据。
例如,使用和以上相同的数据元素,如果我们分析该生产数据库,将发现以下事实:
总记录数:
294,031个
帐户类型为S的总数:
141,135个(占全部数量的48%)
帐户类型为C的总数:
144,075个(占全部数量的49%)
帐户类型为X的总数:
8,821个(占全部数量的3%)
帐号和PIN号均匀分布
基于统计抽样的测试数据包括294个记录(与上面提到的四项相比较):
测试数据(占生产的1%)
记录数
百分比
总记录数
294
100
帐号
(S)081200000000到
081299999999
141
48
帐号
(C)082900000000到
082999999999
144
49
帐号
(X)079900000000到
079999999999
9
3
以上矩阵只说明帐户类型。
为了开发最佳的基于统计表示法的测试数据,您最好要将重要的数据元素包括在内。
以上示例中,包括反映了实际帐户余额的重要数据元素。
统计表示法的一个缺点是可能无法反映可接受值的整个范围。
通常情况下,同时使用确定测试数据的两种方法,确保测试数据涵盖所有值并解决性能/填充问题。
测试数据宽度与用作输入的测试数据以及用于支持测试(在预先存在的数据中)的测试数据相关。
3.4范围
范围是测试数据与测试目标之间的关联关系,它和测试深度和测试宽度相关。
具有许多数据并不意味着其数据一定正确。
与处理测试数据的宽度一样,我们必须确保测试数据和测试目标相关,也就是说,需要有支持特定测试目标的测试数据。
例如,在以下矩阵中,最初的四个测试数据记录说明了每个数据元素的可接受值。
然而,用于评估帐户类型C和X负余额的记录却没有。
因此,尽管该测试数据正确地包含了一个负余额(有效的宽度),以下的数据在其范围内不足以支持采用每个帐户类型的负余额进行的任何测试。
扩展此数据以包括更多的记录,并将各个不同帐户类型的负余额包括在内,这些操作对于处理这类疏忽是很有必要的。
帐号(范围)
PIN号
(整数)
帐户余额
(十进制)
帐户类型
(字符串)
(S)081200000000到
081299999999
(C)082900000000到
082999999999
(X)079900000000到
079999999999
0000-9999
-999,999.99到999,999.99
S、C、X
记录1
081208370293
8493
-3,123.84
S
记录2
081264938355
3558
8,438.53
S
记录3
082974830462
0352
673.00
C
记录4
079948961893
4896
493,498.49
X
新记录1
082934914927
0352
-995,498.34
C
新记录2
079965789436
4896
-64,913.87
X
测试范围和用作输入的测试数据以及用于支持测试(在预先存在的数据中)的测试数据相关。
3.5构架
测试数据的物理结构仅与测试目标用于支持测试的任何预先存在的数据相关,例如某个应用程序的数据库或规则表。
测试执行不是一劳永逸的。
测试将需要在迭代中以及各个迭代之间重复执行。
为统一、有效、有把握地执行测试,测试数据应在测试执行前返回其初始状态。
在自动执行测试时,这一点尤其重要。
因此,为了确保测试的完整性、把握性和有效性,测试数据不受外部的任何影响,并且了解测试执行在开始、期间和结束阶段的状态,这两点异常重要。
为了达到测试目标,必须处理两个问题:
不稳定性/隔离-隔绝测试数据的外部影响
初始状态-了解数据的特定初始状态以及返回此状态的能力
这两个问题都将影响您管理测试数据库、设计测试模型以及与其他角色交互的方式。
3.5.1不稳定性/隔离
测试数据可能由于以下原因而变得不稳定:
外部的、与测试无关的影响修改了该数据
其他的测试角色不知道别人正在使用的数据
为维护测试的把握性和完整性,测试数据需要进行高度控制并与这些影响隔绝。
确保测试数据被隔绝的策略包括:
分离测试环境-每个测试角色有自己的测试环境,在物理上和其他角色分离。
测试员没有共享的内容,也就是说,他们有自己的测试目标和数据。
例如,每个测试角色都有自己的个人计算机就可以实现此策略。
分离测试数据基础实例-每个测试角色有自己的数据实
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 测试 设计 指南
![提示](https://static.bdocx.com/images/bang_tan.gif)