- 什么是测试用例
-
测试用例的定义
设计一个情况，软件程序在这种情况下，必须能够正常运行并达到程序所设计的预期结果
- 测试用例模板和包含的内容
| 测试用例编号 | 测试项 | 依赖用例 | 测试步骤 | 输入数据 | 预期结果 | 测试结果 | 测试人 | 备注 |
· 标识符（用例编号）：一般- TestCase_项目名称_模块名称_功能名称_001
· 测试项：测试用例的测试目的。
· 依赖用例：一般功能流程上，下游功能测试依赖于上有功能测试的用例。
· 测试步骤：用最朴实的语言，写出来软件的操作步骤，要尽量详细。
· 测试数据：单独整合测试数据，必须和测试步骤中的数据保持一致。
· 预期结果：准确！对象的准确、内容的准确。原则上每一个操作，都有一个结果。在重要的步骤后，设定预期结果。
· 测试结果：要求在测试执行完成后添加，没有执行保持为空。通过/失败、Pass/Failed
· 测试人：测试的执行人。
· 备注：为了测试用例正常执行而做的特殊准备。
-
设计测试用例的作用
- 有效性：测试用例是测试人员测试过程中的重要参考依据
- 可复用性：良好的测试用例具有重复使用的功能，使得测试过程是效率提高
- 易组织下：不管大小项目也依旧能用的上
- 可评估性：从项目的管理角度来说，测试用例的通过率是检验代码质量的保证
- 可管理性：可作为工作效率的标准
- 测试用例编写注意事项
- 不要设计“穷举测试用例”
- 在详细测试用例与有效测试时间中找到平衡点
- 好的测试用例应该多关注“反向测试问题”
- 测试用例库应该不断更新和维护
- 测试用例可以复用，但要注意数据有效性与环境变化
- 测试用例是设计出来的，不是写出来的
- 多去学习经验丰富的测试工程师所设计的测试用例
- 针对不同需求类型和测试对象，灵活采用不同的测试用例设计方法
- 黑盒测试用例设计方法（一）
-
黑盒测试用例设计方法概述
-
等价类划分法
- 划分原理
- 把程序的输入域划分成若干部分，然后从每个部分中选取少数代表性数据作为测试用例
- 每一类的代表性数据在测试中的作用等价于这一类的其他值，如果某一类中的一个例子发现了错误，这一等价类中的其他例子也能发现同样的错误
- 反之，如果某一类中的一个例子没有发现错误，则这一类的其他例子也不会查出错误
- 确定等价类的原则
- 在输入条件规定了取值范围或值的个数的情况下，可以确立一个有效等价类和两个无效等价类
- 在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下，可以确立一个有效等价类和一个无效等价类
- 在输入条件是一个布尔量的情况下，可确定一个有效等价类和一个无效等价类
- 在规定了输入数据的一组值（n个），并且程序要对每一个输入值分别处理的情况下，可确立n个有效等价类和一个无效等价类
- 在规定了输入数据必须遵守的规则的情况下，可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）
- 在确知已划分的等价类中，各元素在程序处理中的方式不同的情况下，则应再将该等价类进一步地划分为更小等价类
- 等价类划分法
- 划分等价类和列出等价类表
- 有效等价类
- 无效等价类
- 确定测试用例
- 为每个等价类规定一个惟一的编号
- 设计一个新的测试用例，使其尽可能多地覆盖升为覆盖的有效等价类。重复这一步，最后使得所有有效等价类均被测试用例所覆盖
- 设计一个新的测试用例，使其只覆盖一个无效等价类。重复这一步使所有无效等价类均被覆盖。
- 划分等价类和列出等价类表
- 测试用例中的问题
- 用例按照测试分类：功能(Function)、界面(UI)、性能(Performance)、安全(Security)、接口(Interface)
- 测试项是必须确定的！
- 身份证号业务知识：最后一位是效验码（机密）：0~9，Ⅹ
- 测试项一般只写一个测试目的。测试目的必须是明确的，不能一次测试多个点。
- 依赖用例：下游的用例依赖上游的用例（已经存在的测试用例），用例依赖可以跨越模块
- 测试步骤，表明操作的对象和方式，数据
- 测试数据，没有数据空着不写。
- 测试结果：不执行就不写
- 用例中不需要显示正向或反向
- 等价类划分，不要出现重复的情况，也不要出现缺失的输入部分
- 划分原理
-
边界值分析法
- 如果输入条件规定了值的范围，则应取刚打到这个范围的边界的值，以及刚刚超越这个范围边界的值作为测试输入数据
- 如果输入条件规定了值的个数，则用最大个数、最小个数、比最小个数少1、比最大个数多1的数作为测试数据
- 分析规格说明，找出其他可能的边界条件
- 如果程序的规格说明给出的输入域或者输出域是有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例
- 如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构边界上的值作为测试用例
· 三角形判定
- 等价类划分
| 有效等价类 | 无效等价类 | |||
| 不能组成三角形 | 两边之和小于第三边 | 1 2 4 | 小于等于0 | 0 |
| 两边之和等于第三边 | 1 2 3 | 小数 | 3.5 | |
| 能组成三角形 | 直角三角形 | 3 4 5 | 字母 | abc |
| 等腰三角形 | 12 12 10 | 标点符号 | ！ | |
| 等边三角形 | 25 25 25 | 汉字 | 你好 | |
| 钝角三角形 | 3 4 6 | |||
| 锐角三角形 | 5 12 11 | |||
- 边界值分析
黑盒角度 白盒 边界值 边长最大能是多少？ web程序，文本框输入内容的长度 找开发/需求 看代码 数据库中该数据的类型 JS进行脚本判断 数据类型的长度范围/取值范围 - 测试用例设计
| 测试用例编号 | 测试项 | 依赖用例 | 测试步骤 | 输入数据 | 预期结果 | 测试结果 | 测试人 | 备份 |
| Test_Case_DBXPD _SBXPD_open_0001 | 打开多边形判断程序 | 1.使用谷歌浏览器打开判断程序页面 | 打开判断程序首页，并且显示选择多边形的形状 | |||||
| Test_Case_DBXPD _SBXPD_select_0002 | 打开三角形判断页面 | 1.在首页中 点击 单选按钮 三角形 | 打开三角形的判断页面，有三角形的示例图，还有三个本文狂供输入数据 | |||||
| Test_Case_DBXPD _SBXPD_panduan_0003 | 两边之和小于第三边 | 1.第一条边长输入：1 2.第二条边长输入：2 3.第三条边长输入：4 4.点击【提交】按钮 | 1 2 4 | 弹窗提示：不能构成三角形 | ||||
| Test_Case_DBXPD _SBXPD_panduan_0004 | 两边之和等于第三边 | 1.第一条边长输入：1 2.第二条边长输入：2 3.第三条边长输入：3 4.点击【提交】按钮 | 1 2 3 | 弹窗提示：不能构成三角形 | ||||
| Test_Case_DBXPD _SBXPD_panduan_0005 | 三条边组成直角三角形 | 1.第一条边长输入：3 2.第二条边长输入：4 3.第三条边长输入：5 4.点击【提交】按钮 | 3 4 5 | 弹窗提示：直角三角形 | ||||
| Test_Case_DBXPD _SBXPD_panduan_0010 | 一条边长输入为0 | 1.第一条边长输入：0 2.第二条边长输入：0 3.第三条边长输入：5 4.点击【提交】按钮 | 0 0 5 | 弹窗提示：边长输入错误 |
- 黑盒测试用例设计方法（二）
-
因果图法
-
-
什么是因果
- 因果图法是一种适用于描述对于多种输入条件组合的测试方法
- 根据输入条件的组合、约束关系和输出条件的因果关系，分析输入条件的各种组合情况，从而设计测试用例的方法
- 适合于检查程序输入条件设计的各种组合情况
-
-
-
因果图的符号
-
第一步： 根据功能说明书中规定的原因和结果之间的关系画因果图
原因和结果的关系 | |
| 恒等 | 原因A成立，结果B一定成立 |
| 非 | 原因A成立，结果B一定不成立 |
| 或 | 原因A、B、C三者只要有一个成立，结果D一定成立 |
| 与 | 原因A、B、C都成立时，结果C才会出现 |
第二步：根据功能说明书在因果图上加上约束条件
其中 互斥、包含、唯一、要求：对原因的约束；屏蔽：对结果的约束。
原因之间的约束（原因成立为1，不成立为0） | |
| 互斥 | 表示不同时为1，即abc至多只有一个1。A+B+C≤1 |
| 包含 | 表示至少有一个1，即abc中不同时为1。1≤A+B+C≤3 |
| 唯一 | 表示abc中有且仅有一个1。A+B+C==1 |
| 要求 | 表示若a=1，则b必须为1。即不可能 a=1且b=0。A成立要求B一定成立 |
| 屏蔽 | 表示若a=1，则b必须为0。A结果出现，B结果一定不出现。 |
-
-
因果图使用实例
-
| 案例：自助售货机卖啤酒和惩治，处理单价5角；投五角硬币，按下按钮，出饮料；投1元，按下按钮，出饮料，找零5角。 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
分析原因和结果： | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 画出原因和结果关系（部分）：
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 按照需求描述原因、结果间的关系：
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 因果图使用中的局限性： 当原因和结果很多的时候，它们之间的关系连线就会很多，导致因果图的可读性变差。因此用作局部的小功能（原因和结果不是很多的时候）分析。 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 列出所有原因和结果的列表。设计初步的测试用例步骤
因果图的优势：能够发现设计中存在的不足 经过分析发现： 1. 只选择饮料，没有投币的时候，软件没有任何结果 2. 只投币，没有选择饮料的时候，软件没有任何结果 3. 不能把软件的缺陷设计成测试用例。 |
-
判定表法
-
判定表驱动法
- 条件桩(Condition Stub)：列出了问题的所有条件。通常认为列出的条件的次序无关紧要
- 动作桩(Action Stub)：列出了问题规定可能采取的操作。这些操作的排列顺序没有约束
- 条件项(Condition Entry)：列出针对它所列条件的取值。在所有可能情况下的真价值
- 动作项(Action Entry)：列出在条件项的各种取值情况况下应该采取的动作
-
应用场合 主要适用于多条件的内容组合与结果分析 组成 由条件项、动作项、条件桩、动作桩四部分组成 使用的条件 所有的条件桩在表中的位置和顺序互相不影响 所有的动作桩的顺序不会因为条件顺序的变化而产生不同 -
建立判定表的步骤
-
第一步：确定规则的个数
假如有n个条件，每个条件有两个取值（0，1），则有2n中规则
第二步：列出所有的条件桩和动作桩
- 填入条件项
- 填入动作项，制定初始判定表
第三步：简化，合并相似规则或者相同动作
| 识别出操作条件（原因），和对应动作（结果） |
| 分析条件的条件项（组合数量）：如果有n个条件，每个条件又成立和不成立两种情况，那么最后一共会有2^n个数量 |
| 简化和优化结果，排除一些不可能存在的情况 |
· 判定表法实例
| 案例：订购单的检查
| ||||||||||||||||||||||||||||||
| 1.分析条件和动作
| ||||||||||||||||||||||||||||||
| 2.写入条件桩、动作桩、条件项、动作项：
| ||||||||||||||||||||||||||||||
| 3. 对判定表进行简化和优化（对其中不合理或者重复的进行取舍） 不管金额的高低，只要未过期，机会发送批准单和提货单。（在测试时间不充分的情况下，可以选二者中的一个情况进行测试）
| ||||||||||||||||||||||||||||||
| 4. 将判定表中的每一列（条件项和对应的动作项）作为测试用例的数据和操作以及对应的预期结果。 |
· 适合使用判定表设计测试用例的条件
- 规格说明以判定表的形式给出，或很容易转换成判定表
- 条件的排列顺序不影响执行哪些操作
- 规则的排列顺序不影响执行哪些曹祖
· - 当某一规则的条件已经满足，并确定要执行的操作后，不必检验别的规则
- 如果某一规则要执行多个操作，这些操作的执行顺序无关紧要
-
场景法
-
场景法基本原理
- 现在的软件几乎都是用事件触发来控制流程的。测试时，可以生动地描绘出事件触发时地场景，有利于设计测试用例，同时使测试用例更容易理解和执行
- 基本流：软件功能按照正确的时间流实现的一条正确
流程。通常一个业务仅存在一个基本流，且基本流仅有一个起点和一个终点 - 备选流：除了基本流之外的各支流，包含多种不同的情况
- -
- 场景列表
- 场景1 基本流
- 场景2 基本流 备选流1
- 场景3 基本流 备选流1 备选流2
- 场景4 基本流 备选流3
- ···
-
设计用例的步骤
- 根据说明，描述出程序的基本流和各项备选流
- 根据基本流和各项备选流生成不同的场景
- 对每一个场景生成相应的测试用例
- 对生成的所有测试用例重新复审，去掉多余的测试用例
- 测试用例确定后，对每一个测试用例确定测试数据值
-
场景法适用于解决业务流程清晰的系统或功能
-
场景法设计案例
-
| 案例：ATM取款机的取款流程 |
| 基本流：插卡-输入密码-···-出钞-取卡 备选流： 1 卡片不是银行卡；2 卡片不是银联的卡；3 密码输错一次；4 密码输错两次第三次输入正确；5 密码输错三次，冻结账号或者吞卡；6 选择存款服务；7 选择查询服务；8 选择转账服务；9 选择修改密码服务；10 选择取款金额；11 选择其他金额；12 账户余额；13 ATM机没钱了；14 账户取款金额达到取款机的当日取款上线；15 账户取款金额达到账户当日取款上限； |
| 场景设计： 场景1： 基本流 场景2： 基本流 备选流5 场景3： 基本流 备选流2 备选流4 ··· |
| 设计测试用例： 每一个场景，都是一个测试用例。 以场景3为例：设计步骤 假定ATM只能识别银联卡，（用一个万事达卡先进行插入） 1.插卡（先用万事达卡） 2.换卡（银联卡），再进行插卡 3.输入密码（第一次输入错误） 4.再次输入密码（第二次输入错误） 5.第三次输入密码（输入正确） 6.选择服务-取款 7.选择取款金额-500 8.等待出钞 9.取卡 |
| 为用例的步骤设计数据 |
- 黑盒测试用例设计方法（三）
-
正交实验法
-
正交法原理介绍
-
正交实验法就是利用排列整齐的表-正交表来对试验进行整体设计、综合比较、统计分析，实现通过少数的试验次数找到较好的生产条件，以达到最好的效果。
这种试验设计法是从大量的试验点中挑选适量的具有代表性的点，利用已经造好的表格-正交表来安排试验并进行数据分析的方法。
（原本用于工业生产的数据组合与实验室的数据挑选）
数学原理——《线性代数》《概率论》《数理统计》
核心概念：1.影响实验结果的——实验因素（因子）、因素
2.每一个因素的不同取值（状况）— 水平
eg.字的显示效果：字体、字号、颜色、称为因素；
字体选择时可以选择宋体、楷体、微软雅黑、隶书等，称为水平，(212)
字号选择时可以选择···，称为水平，(100)
颜色选择时可以选择···，称为水平，(256)
测试字的显示效果将会有：212*100*256
3.正交表特点：每列中，同一数字（水平）出现的次数相等；
任意两列组成的数字对（水平对）出现次数相等。
基本思想：
| 在一项实验中，把影响试验因素的量称为试验因素(因子)，简称因素。 在实验过程中，每一个因素可以处于不同的状态或状况，把因素所处的状态或者状况称为因素的水平，简称水平。 |
| 每列中不同数字出现的次数相等。这一特点表明每个因素的每个水平与其他因素的每个水平参与实验的几率是完全相同的，能有效地比较实验结果并找出最优的实验条件。 |
| 在任意2列其横向组成的数字对中，每种数字对出现的次数相等。这个特点保证了实验点均匀地分散在因素与水平的完全组合之中。 |
-
-
正交实验法实现步骤
- 分析所有对结果有影响的因素。从多个角度和方式进行分析（不要放过文本框、按钮等需求中体积或者没有提及）
- 分析每个因素的水平数量，充分利用等价类、边界值（需求中说明和未说明的都）
- 选择正交集。只有特定的因素数和水平数的组合才有对应的正交表。所以在现实中用到的时候，找最贴近的正交集（正交表的因素数和水平数一般要大于实际的因素数和水平数）
n：实验次数，也是通过正交实验法设计的测试用例个数；
m：水平数，任何单个因素能够取得的值最大数，即要测试功能点的输入值；
k：因素的数量，正交表中列得个数，即要测试的功能点。
之间无数学关系
金适合用于每一个因素的水平数都相同的正交表
-
· 实际案例：
| 案例：有一个工业产品，其生产工艺收到操作方式、温度、洗涤时间三个因素的影响，并且每个因素都有三种可能的取值，具体如下，请设计实验组合。
|
| 完全排列组合：3*3*3=27 |
| 使用小工具完成正交实验的设计：（L9_3_4：三水平，四因素，9次实验）
|
-
功能图法
-
功能图法原理介绍
- 又叫做状态迁移图；
- 来源：在遇到有事务流或者由于某种条件成立导致状态改变的软件时，如何进行测试用例的设计就比较麻烦；
- 状态迁移图法的目标：设计足够多的测试用例达到对系统状态的覆盖、状态-条件组合的覆盖以及状态迁移路径的覆盖；
- 以操作系统的进程调度算法为例：
-
功能图法分析过程
- 功能图法步骤：
- 组合任意可能的状态组合，写出相应的测试用例
- 直到再没有任何新状态产生，列出所有的状态，生成状态表
- 循环执行上一步
- 为上一步产生的所有新状态，分别加所有可能的输入（只加1次）
- 在“空闲”状态上加所有可能的输入（只加1次）
- 把软件的打开的初始状态，定义为“空闲”状态
- 列出所有可能的输入事件，以ip N的方式命名
-
案例：以QQ登录界面为例，说明功能的变迁
1. 识别出可以进行的操作：
IP1：输入账号
IP2：输入密码
IP3：点击登录
IP4：点击关闭按钮
2. 定义QQ登陆界面为 空闲 状态； 3. 第一轮分析后产生新的状态。
4. 针对新的状态进行分析（第二轮分析）
5.针对新的状态进行分析（第三轮分析）
虽然得到了一个全新的界面（状态），但是和空闲状态发生了“隔断”，因此将其视为空闲状态的结束。可以结束分析过程
6.将状态变化过程列表化，准备设计测试用例
状态名/序号 A d 空闲 1 1 1 1 QQ号已输入 2 2 密码已输入 2 QQ号、密码已输入 3 QQ主界面 4 退出 2 3 3 设计用例的时候：
- A列：从QQ的登录界面，直接点击关闭按钮，QQ登录退出；
- D列：从QQ的登录界面，先输入QQ号（状态变为QQ号已输入)；再输入密码(状态变为QQ号、密码已输入)，点击登录(状态变为QQ主界面)
- 功能图法步骤：
-
-
其他用例设计方法
-
测试大纲法
- 特点：着眼于需求。进行详细的需求分析，将其转化为思维导图（树形结构）；
- 无需用例设计。一般从根节点开始分析，到叶节点为止。这样的一条路径就是一条测试用例；
- 一般用于快速的测试和过程记录。用例一般用于候补。
-
探索性测试法
- 基于经验和直觉
- 是计划内测试用例设计的补充
- 需要申城测试用例
-
猴子测试法（随意测试、随便测试）
- 没有测试用例（无意识的行为）往往不太真实
- 不能达到一定的覆盖率
- 许多测试都是冗余的
- 需要使用同样的随机数才能重建测试，想要重复操作，极其困难。
-
-
用例设计方法综合选择
- 首先进行等价类划分
- 在任何情况下都必须使用边界值分析方法
- 如果程序的功能说明中含有输入条件的组合情况，则一开始就可选用因果图法和判定表驱动法
- 对于参数配置类的软件，要用正交实验法选择较少的组合方式达到最佳效果
- 状态迁移图法也是很好的测试用例设计方法，可以通过不同时期条件的有效性设计不同的测试数据
- 对于业务流清晰的系统，可以利用场景法贯穿整个测试案例过程
- 可以用错误推测法追加一些测试用例
- 对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度，如果没有达到要求的覆盖标准，应当再补充足够的测试用例
| 首先明确用例设计方法都有哪些： 等价类划分法；边界值分析法；因果图法；判定表法；场景法；正交实验法；状态迁移图法（功能图法） ！！用例设计方法的使用不是孤立存在的，而是存在于项目中 |
| 案例：教育APP
在启动页中有如下需求 1.读取版本更新信息 - 匹配当前APP与线上需要更新的APP版本是否一致； 2. 读取APP数据： - 获取学科、作业、提问等数据； 3. 读取用户信息： - 未登录用户，不用获取 - 已登录用户，验证是否登录过期 |
| 用例设计方法：采用场景法进行设计。 设计场景： 1.APP的安装版本比最新版要低，启动就需要进行版本检测，并进行提示。 2.APP安装版本与最新版一致，默认检测过程成功。 3.APP启动检测用户登录状态，如果登录过期或者未登录，启动完成后直接跳转登录界面。 4.APP启动检测用户登录状态，如果登录信息有效，启动完成后直接跳转首页界面。 |
| 2. 在登录界面，看需求。
|
| 用例设计方法：等价类划分法和边界值分析法、因果图法。 等价类划分法： 1.手机号的有效性（手机号包含各种不合法字符） 2.验证码包含各种不符合需求的字符 边界值分析法： 1.手机号超过/不足长度限制； 2.验证码超过/不足长度限制； 3.验证码有效期为30分钟，所以超过30分钟后使用验证码，就是边界值的使用； 4.弹窗提示1s消失；超过或者不足的测试都是边界值的应用。 因果图法： 1.提交数据时，APP网络中断，有网络异常的提示； 2.提交数据时，服务器崩溃或者无法提供正常服务，有服务器报错提示或者等待提示； 3.提交数据时，手机号不符合要求（不存在），有手机号错误的提示； 4.提交数据时，验证码输入不是收到的验证码、超时，有验证码错误的提示。 |
| 3.课程内容界面，需求如图所示
|
| 用例设计方法：场景法、等价类划分、边界值分析法 场景法： 1.该课程今日有作业 有提问的内容展示;老师发布作业的时候 学生提问 2.该课程今日有作业 无提问的内容展示;老师发布作业的时候 学生没提问 3.该课程今日无作业 有提问的内容展示;老师没发布作业的时候 学生提问 4.该课程今日无作业 无提问的内容展示;老师没发布作业的时候 学生没提问 等价类划分法、边界值分析法： 1.日期的显示。是都出现2017年2月有29天的现象？ 2.日期的显示。是否出现2017年2月1日和2017年1月31天重复或相隔一天 |
总结！所有测试用例的设计方法，没有独立使用的。都是融合在一起使用，往往在一个软件的界面中，都可以使用好几种测试用例的设计方法。 |
1864
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
