测试用例的概念
测试用例(test case),也叫测试案例,是为了达到一个最佳的测试效果或者高效的发现软件中的隐藏错误(缺陷)而精心设计的包括场景步骤和数据。
通用的定义:是关于一个功能验证时候的步骤和数据的文档,她描述了输入参数、条件和配置、预期的输出结果,用以验证软件的某个功能是否正确的文档。
测试用例的重要性
- 构成测试设计和执行和执行测试过程的基础
- 测试用例的复用性使得测试活动更加容易展开
- 软件质量的度量依据,测试实施的质量保证
- 基于需求的覆盖,保证测试需求的覆盖率100%。
测试用例的作用
- 有效性:测试用例是测试人员测试过程中的重要依据。
- 可复用性:良好的测试用例具有重复使用的功能,使得测试过程
事半功倍,提高测试效率。 - 易组织性:即使是小的项目,也可能会有几千甚至更多的测试用
例,测试用例可能在数月甚至几年的测试过程中被创建和使用。 - 可评估性:从测试的项目管理角度来说,测试用例的通过率是检
验代码质量的保证。 - 可管理性:测试用例也可以作为检验测试人员进度、工作量以及
跟踪/管理测试人员的工作效率的标准。
测试用例模板
测试用例的设计方法
黑盒测试方法
白盒测试方法
灰盒测试方法
附:业务流测试、本地化测试、单元测试、静态测试等
黑盒测试常见方法
黑盒测试概述
把被测对象看作是一个黑盒子,我们不关心程序内部的实现结构和处理过程,测试者仅需要根据需求给出输入(测试用例中测试步骤和数据),拿着实际运行输出(实际结果)与预期(来自需求的)是否一致,如果一致说明该用例对应的功能点是正常的,否则是错的
黑盒测试又成为功能测试,也叫数据驱动测试。
- 设计功能需求输入条件集合,实现对需求的覆盖(测试需求–来自用户需求、业务需求、系统需求等)
- 在软件的接口处进行的测试(GUI接口),主要针对软件界面和功能测试
- 用户的角度,针对输入和输出的一致性进行验证的过程
黑盒测试的作用
- 功能实现不正确或者功能遗漏(测试依据是需求,而在测试执行的时候才会有被测软件出现)
- 界面错误(黑盒测试是在GUI界面上进行输入、输出的验证工作)
- 输入和输出错误(比如需求重要某文本框可以输入11位的数字,但是软件中只能输入10位)
- 数据库错误或者外部访问错误
- 初始化或终止错误
黑盒测试的方法
等价类划分方法
1、等价类的概率
依据需求将程序的输入域划分为若干个部分,从每一个部分选取有限的几个代表性数据作为测试用例的数据,这几个代表性数据等同于该部分的其他数据。
等价类就细分为有效的等价类和无效的等价类:
- 有效等价类:需求中规定的符合需求的、有意义的、合理的数据的集合
- 需求中定义的不合理的、无意义的,或者隐藏的无意义的数据的集合
2、等价类的划分原则
-
**按照区间划分:如果输入的条件是一个范围或者是值的个数情况,可以划分出1个有效类和两个无效等价类
-
按照数值划分:如果给定有限的N个值,可以划分N个有效等价类和一个无效等价类
-
按照数值的结合划分:如果给定的是输入值得集合,划分一个有效等价类和1个无效等价类
-
按照设定规则进行划分:在输入数据遵守规则下,可以划分1个有效等价类和多个无效等价类
-
如果数据是布尔值:则可以划分出一个无效一个有效**
-
例:11位的数字组成的手机号码
-
11位数字,1开头
-
11位数字,非1开头
-
10位数字,1开头
-
10位数字,非1开头
-
11位非数字,1开头
-
11位非数字,非1开头
-
10位非数字,1开头
-
10位非数字,非1开头
等价类划分的 步骤
确定等价类后,建立等价类表,列出所有的等价类
输入条件 | 有效等价类 | 编号 | 无效等价类 | 编号 |
---|---|---|---|---|
11位 | 11位 | 1 | 非11位 | 7 |
数字 | 数字 | 2 | 字母 | 8 |
数字 | 数字 | 2 | 特殊字符 | 9 |
数字 | 数字 | 2 | 汉字 | 10 |
手机号码 | 第一位是1 | 3 | 第一位非1 | 11 |
手机号码 | 第二位不能为1 | 4 | 第二位能为1 | 12 |
手机号码 | 第二位不能为2 | 5 | 第二位能为2 | 13 |
手机号码 | 第二位不能为0 | 6 | 第二位能为 | 14 |
从已列出的等价类表中按以下原则设计测试用例数据:(补全)
- 为每个等价类规定一个唯一的编号;
- 设计一个新的测试用例,使其尽可能多地覆盖尚未覆盖的有效等价类,重复这一步,最后使得所有有效等价类均被测试用例所覆盖;
- 设计一个新的测试用例,使其只覆盖一个无效等价类,重复这一步使所有无效等价类均被覆盖。
测试用例数据 覆盖等价类
18621984010 1、2、3、4、5、6
1862198401 7、2、3、4、5、6
18a21984010 8、1、3、4、5、6
边界值分析法
1、边界值分析简介:
- 长期的测试工作经验告诉我们,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例,可以查出更多的错误。
- 通常边界值分析法是作为对等价类划分法的补充,这种情况下,其测试用例来自等价类的边界。
- 所谓边界,是指输入和输出等价类中那些恰好处于边界、或超过边界、或在边界以下的状态。
2、边界值分析的步骤: - 首先确定边界情况。通常输入和输出等价类的边界,就是应着重测试的边界情况。
- 然后选取边界数据做为测试数据。测试数据应该刚好等于、刚刚小于和刚刚大于边界值,而不是取等价类中的典型值或任意值作为测试数据。
3、边界值分析原则: - 1、如果输入条件规定了值的范围,则取刚达到这个范围的边界的值,以及刚刚超越这个范围边界的值作为测试输入数据。 例:输入值的范围是 -1.0~1.0,则可选取-1.0、 1.0、 -1.1和1.1作为输入数据。
- 2、如果输入条件规定了值的个数,则用最大个数,最小个数,比最小个数少一,比最大个数多一的数作为测试数据。
例:一个输入文件应包括1~255个记录,则需设计测试用例测试1、255、0、256。 - 3、将规则1)和2)应用于输出条件,即设计测试用例使输出值达到边界值及其左右的值。例:一程序属于情报检索系统,要求每次“最少显示1条、最多显示4条情报摘要”,则需设计测试用例测试1和4,以及0和5。
- 4、如果程序的输入或输出是一个有序序列(例如顺序的文件、线性列表或表格),则应特别注意该序列的第一个和最后一个元素。
- 5、分析规格说明,找出其他可能的边界条件。
因果图方法
产生背景:等价类法、边界值法分析着重考虑输入条件,未考虑输入条件之间的关系。
含义:是一种利用图解法分析输入的各种组合情况,从而设计测试用例的方法,该方法充分考虑了输入情
况的各种组合及输入条件之间的相互制约关系。
适用范围:适合检查程序输入条件的各种组合情况。
因果图的使用步骤
- 分析软件规格说明描述:原因、结果、标识符
- 分析软件规格说明描述中的语义:找出逻辑关系
- 由于语法或环境限制,有些原因与原因之间,原因与结果之间
的组合情况不可能出现,添加必要的约束条件 - 把因果图转换成判定表
- 把判定表的每一列拿出来作为依据,设计测试用例
案例分析
第一列字符必须是A或B,第二列字符必须是一个数字,在此情况下进行文件的修改,但如果第一列字符不正确,则给出信息L;如果第二列字符不是数字,则给出信息M。
找出原因和结果
原因:
C1——第一列字符是A
C2——第一列字符是B
C3——第二列字符是一数字
结果:
E1——给出信息L
E2——修改文件
E3——给出信息M
因果图优点:
1、因果图能够帮助我们按照一定步骤,高效的选择测试用例,设计多个输入条件组合用例,防止遗漏。
2、因果图分析还能为我们指出,软件规格说明描述中存在的问题。
因果图缺点:
1、输入条件与输出结果的因果关系,有时难以从软件需求规格说明书得到。
2、加入N个条件,每个条件都有真和假两种取值,这就大大增加了测试用例的数目,不便于维护。
场景法
概念:场景法就是模拟用户操作软件时的场景,主要用于测试系统的业务流程。用例场景来测试需求是指模拟特定场景边界发生的事情,通过事件来触发某个动作的发生,观察事件的最终结果,从而用来发现需求中存在的问题。
用例场景:
是通过描述流经用例路径来确定的过程。这个流经过程要从用例开始到结束遍历其中所有的基本流和备选流。
基本流:采用直黑线表示,是经过用例的最简单的路径。(无任何错,程序从开始直到执行到结束)
备选流:采用不同颜色表示,一个备选流可能从基本流开始,在某个特定条件下执行,然后重新加入基本流中,
也可以起源于另一个备选流,或终止用例,不在加入基本流中。(各种错误情况)
场景法使用步骤
- 确定基本流和备选流
- 根据基本流和备用流确定场景
- 对每一个场景生成测试用例
- 去重复之后设计测试数据
案例分析:
用户进入一个在线购物网站进行购物,选购物品后,进行在线购买,这时需要使用账号登录,登录成功后,进行付钱交易,交易成功后,生成订购单,完成整个购物过程。
第一步:确定基本流和备选流
基本流:进入在线购物网站—>选择物品—>登录账号—>付款—>生成订单;
备选流1:账户不存在;
备选流2:账户密码错误;
备选流3:用户账户余额不足;
备选流4:用户账户没钱。
第二步:根据基本流和备用流确定场景
场景1(成功购物):基本流;
场景2(账户不存在):基本流 备选流1;
场景3(账户密码错误):基本流 备选流2;
场景4(账户余额不足):基本流 备选流3;
场景5(账户没钱):基本流 备选流4。
第四步:设计测试用例
错误推导法
含义:
错误推测法是一种基于经验和直觉推测程序中所有可能存在的各种错误,从而有针对性的设计测试用例的方法。
基本思想:
错误推测方法的基本思想是列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例。
例:
在单元测试时曾列出的许多在模块中常见的错误
以前产品测试中曾经发现的错误
输入数据和输出数据为0的情况
输入表格为空格或输入表格只有一行的情况
探索性测试
探索性测试是一种测试思维技术:
➢ 探索性测试(ET)是敏捷世界里的一种重要测试方法,它是一种经过深思熟虑的测试方式,没有测试脚本,可
以使你的测试超出各种明显已经测试过的场景;
➢ 探索性测试的最大特色是在对测试对象进行测试的同时学习测试对象并设计测试,在测试过程中运用获得的关于测试对象的信息设计新的更好的测试,典型过程如下图:
一边熟悉学习测试对象,针对性的设计更好的测试用例
测试方法的选择
一个好的测试策略和测试方法将给整个测试工作带来事半功倍的效果,以下是各种测试方法选择的
综合策略,可在实际应用过程中参考:
- 首先进行等价类划分,包括输入条件和输出条件等价划分,将无限测试变成有限测试,这是减少工作量和提高工作效率的最有效方法;
- 在任何情况下都必须使用边界值分析方法。经验表明用这种方法设计出测试用例发现程序错误的能力最强;
- 对照程序逻辑,检查已设计出的测试用例的逻辑覆盖程度,如果没有达到要求的覆盖标准,应当再补充足够的用例;
- 如果程序的功能说明中含有输入条件的组合情况,则应在一开始就选用因果图;
- 如要关注它的主要功能和业务流程是否正确实现,这就需要使用场景法来完成测试;
- 使用错误推测技术增加更多的测试用例。
测试用例设计
为什么设计测试用例?
是测试工作的指导
是软件测试必须遵守的准则
更是软件测试质量稳定的根本保障
测试用例原则:
- 基于测试需求
- 基于测试方法
- 兼顾测试充分性和效率
- 测试用例代表性
- 测试结果的可判定性
- 测试执行可再现性
测试用例的内容
- 正确性测试
- 容错性(健壮性)测试
- 完整(安全)性测试
- 接口测试
- 数据库测试
- 边界值测试
- 压力测试
- 等价划分测试
- 错误推测
- 效率
- 可理解(操作)性测试
- 可移植性测试
- 回归测试
- 比较测试
测试用例的特点
测试用例的组成要素基本相同:
• 一般包括测试用例编号、测试用例目的、测试用例前置条件、操作步骤、预期结果等内容,根据各个行业及公司的要求,内容有增有减。
测试用例的设计方法基本一致:
• 大多数白盒测试用例设计包含了路径覆盖或是最基本的语句覆盖法;而大多数黑盒测试用例均包含到边界值、等价类、场景法的相关内容(经常潜意识使用)。
测试用例的要素
测试用例的word模板
测试用例注意事项
- 操作是否符合用户习惯
- 各种选项可用或禁用是否合理
- 某些相似操作能否成通用模块
测试用例设计步骤
测试需求:
电话:长度必须为11位,位数不符合时提示“电话必须为11位”。不能为空,否则提示“电话不能为空”。必须由数字组成,第一位必须为1,第二位可以为3、4、5、7、8,后面九位任意,输入错误时提示“手机号不合法, 请重新输入”。
测试用例设计步骤
Step1 需求分析:
有效等价类:
长度必须是11位:
不能为空:
必须由数字组成:
第一位必须为1:
第二位可以为3、4、5、7、8
无效等价类:
长度小于11位,
长度大于11位
为空
由非数字(汉字、字母、特殊字符)
第一位不为1(0,2)
第二位是0、1、2、6、9
跟步骤写测试用例表
测试用例评审
测试用例的评审能够使用例的结构更清晰,覆盖的用户场景更全面;对于测试工程师来说也是一个快速提高用例设计能力的过程。
参与评审人员:
- 部门评审,测试部门全体成员参与的评审。
- 公司评审,这里包括了项目经理、需求分析人员、架构设计人员、运维人员、开发人员和测试人员。
- 客户评审,包括了客户方的开发人员和测试人员。这种情况在外包公司比较常见。
测试用例误区
- 能发现到目前为止没有发现的缺陷的用例是好的用例
- 测试输入数据设计方法等同于测试用例设计方法
- 强调测试用例设计得越详细越好
- 追求测试用例设计“一步到位”
- 测试用例不应该包含实际数据
- 让测试新人设计测试用例