测试用例设计方法

本文详细介绍了测试用例设计的各种方法,包括边界值分析、判定表法、场景设计和错误猜测法。边界值分析强调边界值的重要性,判定表法适用于多逻辑条件组合的情况,场景设计关注业务流程,错误猜测法基于经验和直觉找寻潜在错误。测试用例设计旨在提高测试效率,确保软件质量。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

测试用例设计方法

1、边界值方法
边界值分析法——边界点

关于边界点,可以分为上点、内点和离点

上点:就是边界上的点,不管它是开区间还是闭区间,就是说,如果该点是封闭的,那 上点就在值域范围内,如果该点是开放的, 那上点就不在值域范围外
内点:就是在值域范围内的任意一个点
离点:就是离上点最近的一个点,如果边界 是封闭的,那离点就是值域范围外离上点最 近的点,如果边界是开放的,那离点就是域 范围内离上点最近的点
2、利用边界值作为测试数据的原则
①如果输入(输出)规定了值的范围,则应该以该范围的边界值及边界附近的值作为测试数据;如 一个文本输入区域允许输入1个到255个字符,那么输入0个、1个、255个字符和256个字符做为边 界条件值。
② 如果输入(输出)条件规定了值的个数,则用最大个数,最小个数,比最小个数少一,比最大个 数多一的数作为测试数据;如超市打折,买3件相同商品打7折,则2件、3件、4件商品做为边界条 件值。
③将规则1和2应用于输出条件,即设计测试用例使输出值达到边界值及其左右的值;如某程序的规 格说明要求计算出“每月保险金扣除额为0至1165.25元”,其边界值可取0.00及1165.24、还可取 0.01及1165.26等。
④如果需求规格说明书中提到的输入或输出是一个有序的集合,应该注意选取有序集合的第一个和 最后一个元素作为测试数据;如下拉列表中可以对5个行政区域进行选择,可以选择第一个和最后 一个。
⑤如果程序中使用了一个内部数据结构,则应当选择这个内部数据结构的边界上的值作为测试数据; 如对16-bit 的整数而言 32767 和 -32768 是边界。
⑥分析规格说明,找出其它可能的边界条件

3、内部边界值分析
在测试用例设计过程中,某些边界值条件是不需要呈现给用户的,或者说用户是很难注意到的,但同时确实属于检验范畴内的边界条件,称为内部边界值条件或子边界值条件

内部边界值条件主要有下面几种:
数值的边界值检验
字符的边界值检验
其它边界值检验

4、场景设计
现在的软件几乎都是用事件触发来控制流程的

用户一系列的操作事件触发时的情景形成了场景

而同一事件不同的触发顺序和处理结果就形成了事件流

设计方法
• 通过运用场景来对系统的功能点或业务流程的描述,从而提高测试效果。
• 场景法一般包含基本流和备用流,从一个流程开始,通过描述经过的路径来确的过程,经过遍历所有的基本流和备用流来完成整个场景。

场景测试用例生成
• 基本流(直黑线表示):是经过用例的最简单的路径,软件功能按照正确的事件流实现的一 条正确流程
• 备选流或异常流(彩线表示):出现故障或缺陷的过程,一个备选流可能从基本流开始,在 某个特定条件下执行,然后重新加入基本流中 (如备选流1和3);也可能起源于另一个备选 流(如备选流2),或者终止用例而不再重新加 入到某个流(如备选流2和4)

基本流和备选流的识别原则
• 一个业务只存在一个基本流
• 基本流只有一个起点,一个终点
• 基本流是主流程,备选流是分支流程
• 备选流的终点,可以是一个流程的出口,也可以回到基本流,还可以汇入其它的备选流
• 备选流汇合时,谁汇合到谁,取决于该流程出现的可能性大小,小的汇入大的
• 如果在流程图中出现了两个不相上下的基本流,一般需要分成两个两个业务看待

场景法的设计步骤及应用场合
设计步骤

• 根据需求说明,描述出程序的基本流及各条备选流
• 根据基本流和备选流生成不同的场景
• 对每个场景生产相应的测试用例
• 重新复审一遍所有测试用例,去掉部分多余的以及实际业务当中不太可能发生的,测试用例确定后,对每一个测试用例确定测试数据值

应用场合

• 基于场景的测试一般是在SIT/UAT阶段,在功能测试之后进行。测试场景是基于用户需求分析设计得出的,站在用户角度描述用户与系统的各种交互;所以功能测试关注的 重点是系统功能特征(各种正常和异常分支),场景测试关注的是业务流程、业务场 景或事务,关注的重点不同,分析设计的方法也有差异

5、判定表法

• 在所有的黑盒测试方法中,基于判定表(也称决策表)的测试是最为严格、最有逻辑性的测试方法。
• 判定表的概念:判定表是分析和表达多逻辑条件下执行不同操作的情况的工具。
• 判定表的优点:能够将复杂的问题按照各种可能的情况全部列举出来,简明并避免遗漏。因此,利用判定表能够设计出完整的测试用例集合。
• 在一些数据处理问题当中,某些操作的实施依赖于多个逻辑条件的组合,即:针对不同逻辑条件的组合值,分别执行不同的操作。判定表很适合于处理这类问题。

判定表通常由以下4部分组成:
• 条件桩——列出问题的所有条件,通常认为列出得条件的次序无关紧要
• 条件项——针对条件桩给出的条件列出所有可能的取值,在所有可能情况下的真假值
• 动作桩——列出问题规定的可能采取的操作,这些操作的排列顺序没有约束
• 动作项——指出在条件项的各组取值情况下应采取的动作

构造判定表的5个步骤:
(1)列出所有的条件桩和动作桩。
(2)确定规则的个数。
有n个条件的判定表有2n个规则(每个条件取真、假值)。
(3)填入条件项。
(4)填入动作项,得到初始判定表。
(5)简化判定表,合并相似规则。
• 若表中有两条以上规则具有相同的动作,并且在条件项之间存在极为相似的关系,便可以合并。
• 合并后的条件项用符号“-”表示,说明执行的动作与该条件的取值无关,称为无关条件

6、错误猜测法
•错误猜测是基于经验和直觉推测程序中所有可能存在的各种错误,从而有针对性地设计测试用例的方法。需要测试人员具备的技术
•有关被测系统的知识,如设计方法或实现技术
•有关的早期测试阶段的结果的知识
•测试类似或相关系统的经验
•典型错误的知识
•通用的测试经验规则

测试用例

概念:是为某个特殊目标而编制 的一组测试输入、执行条件以及预期结果,以便测试某个程序路径或核实是否满足某个特定需求

目的:解决要测什么、怎么测和如何衡量的问题

测试用例是软件测试的核心

如何以最少的人力、资源投入,在最短的时 间内完成测试,发现软件系统的缺陷,保证软件的优良品质,则是软件公司探索和追求的目标

重要性

有效性:测试用例是测试人员测试过程中的重要参考依据,准确的测试用例的计划、执行和跟踪是测试的有效性的有力证明

可复用性 :设计良好的测试用例可以重复执行,能节约时间,提高测试效率

易组织性 :清晰详细的测试用例能够便于测试执行的开展

可评估性 :测试用例的通过率是检验代码质量的保证

可管理性 :测试用例也可以作为检验测试人员进度、工作量以及跟踪管理测试人员工作效率的因素

特征

  • 最有可能抓住错误的
    不是重复的、多余的
    一组相似测试用例中最有效的
    既不是太简单,也不是太复杂
    模板可以根据所测对象的不同对模板内容进行调整

优缺点

优点

  • 便于梳理需求
    验证产品的需求是否合理
    监督产品对需求做出更加详细的设计
    记录产品的设计细节,保障以后的查阅
    加深测试人员对产品的认识和印象
    反映测试进度
    帮助发现拓展测试范围,扩大测试覆盖面,发现软件中潜藏的缺陷
    方便回归测试,复查bug是否还会出现
    为紧急情况下的测试提供参考信息
    培训新人,提高新人测试效率,节省对新人的指导时间

用途

核实需求:每一个需求点都会设计测试用例

评估结果:对产品进行评估,对测试完成情况进行评价

准确回归:快速正确的进行版本重复测试

防止遗漏:使软件测试的实施重点突出、目的明确,确保需求功能不被遗漏

提高效率:避免盲目测试

缩短周期:版本更新和升级时,只需修正少部分测试用例,资源复用

设计测试用例的基本准则

测试用例的代表性
测试结果的可判定性
测试结果的可再现性

设计测试用例的着眼点

根据产品规格,测试基本功能
考虑设计一般用户(非专业人员)的使用方案
与系统其他组成部分的配合(如移动网络和wifi,测试中考虑对设备的共享)
好的测试用例集能花费最小的代价(人力、物力、财力、时间)做最好的测试

测试用例设计书写标准

1.用例标题——惟一标识每一个测试用例

2 测试项——准确的描述所需要测试的项及其特征

3.输入步骤和数据—执行测试用例的输入需求(这些输入可能包括数据、文件或者操作)

4 .预期结果——按照指定的环境和输入标准得到的期望输出结果

5.测试用例之间的关联—标识该测试用例与其它的测试(或其它测试用例)之间的依赖关系

测试用例的更新与维护

  • 需要更新和维护的原因

    功能变化

    需要不断完善,是个循序渐进的过程

    通过测试实践检验测试用例并添加、修改、删除测试用例

    测试用例要经过正式、有效的评审

    利用工具(配置管理系统)来维护测试用例

如何选择测试方法

在任何情况下都必须使用边界值分析方法
用等价类划分方法补充一些测试用例
涉及到业务流程的软件,应采用场景法
用错误猜测法再追加一些测试用例
如果程序的功能说明中含有输入条件的组合情况,则应在一开始就选用判定表法
如果程序某功能适合自动测试,可以采用自动测试以及随机测试

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值