测试流程第三个环节：设计测试用例：怎么测<------>测试需求的提取：测什么
5、测试用例
-
描述：测试用例(TestCase)：是一份关于【具体测试步骤】的文档，是为了达到最佳的测试效果或高效揭露软件中潜藏的bug，精心设计少量且具有代表性的测试场景和测试数据。
-
测试用例=测试场景=测试步骤+测试数据+预期结果
-
分析：测试用例就是设计一种情况，软件在该情况下是可以正常运行，且能够达到预期结果的。如果软件在该情况下不能正常运行，或未达到预期结果，就证明发现了bug，需要提交给开发进行确认和修复。修复完成后，再用同一条用例进行验证，确保已修复完成。
-
测试用例的编写
测试用例编号 测试项 依赖用例 测试步骤 测试数据 预期结果 测试结果 测试人 备注 -
测试用例编号：给设计好的每一个测试用例生成唯一的序列号 0001-9999
参考写法：TestCase_项目名称 _模块名称 _子模块名称 _功能名称 _测试类型 _0001
注意：名称可以简写，比如汉语拼音的首字母；当换了新的功能或新的模块，编号要重新生成；
测试类型：功能测试 Function，性能测试 Performance，界面测试 UI
-
测试项/测试用例标题
思路：关联本条测试用例设计的目的，一句话做概述，描述这一条用例是做什么的
写法：具体的角度+验证功能
例：测试需求：密码：6-18位------>设计用例：验证6位长度密码的注册操作
密码：小于6位------>设计用例：验证5位长度密码的注册操作
密码：大小写字母，数字----->设计用例：验证纯大写字母注册操作 验证纯小写字母注册操作 验证纯数字注册操作 验证字母+数字组合注册操作....
参考话术：验证XXXX的操作 XXXX情况下的验证 XXXX操作的验证
-
依赖用例：可选可写的
概述：指的是当前用例的设计，需要用到其它用例的支持，就把关联的用例编号写到该位置
例：针对信贷系统后台：用户管理模块设计用例------>依赖于前台成功注册用户用例
-
测试步骤：最核心的部分
概述：根据测试项，整理出详细的操作步骤(测试过程)，简单清晰明了
例：验证直角三角形判定
测试步骤：
①输入第一条边：3
②输入第二条边：4
③输入第三条边：5
④点击提交按钮
备注：好的测试步骤，任何一个人都是可以执行的，也不会有任何的歧义
-
测试数据/输入数据
概述：指的是测试步骤中用到的数据
-
预期结果
概述：指的是按照测试步骤和测试数据操作完成后，应该会出现的结果
例：预期结果：提示"直角三角形"
-
测试结果
概述：写的是实际结果和预期结果对比后产生的结果值：
通过（成功）：实际结果和预期结果一致
不通过（失败）：实际结果和预期结果不一致
阻塞：因为一些其它的原因（不是本公司所能解决的），导致当前用例无法执行
-
测试人：写的是执行测试用例人员名字
注意：测试结果和测试人一定是执行测试后，才来进行填写的内容！！！
-
备注：可选可写的
概述：做一些额外的补充说明，比如执行用例时，所需要的硬件，软件，网络环境... 谷歌浏览器10.0
-
-
测试用例的作用
① 有效性：执行测试重要参考
②可复用性：良好的测试用例可以重复使用
①易组织性：再小的项目也会有大量的用例，用例也是随着版本的更新不断完善
④可评估性：用例通过率是检查代码质量的参考标准
⑤可管理性：测试用例的设计也是检查测试工作效率的标准
⑥测试用例的设计对于测试需求的覆盖率：一定是100%
6、黑盒测试用例设计方法
-
提供方法的选择：
- 测试数据：等价类划分法，边界值分析法
- 测试步骤：因果图法，判定表法，正交实验法，场景法，功能图法
-
测试数据的选择：
-
等价类划分法：划分数据区间
思想：依据【需求】，将程序的输入域，划分成若干个部分，从每个部分中再选取【少量且具有代表性】的数据，作为测试用例(测试数据)，选取的数据就代表了该整体。
-
等价类划分法分类：
有效等价类 ：依据需求，划分出来【有意义，合理的数据】构成的集合区间
例：163邮箱：手机号快速注册：密码：8-16位长度构成的密码数据都是有效的----->有效等价类 数据类型：大小写字母，数字构成的数据----->有效
无效等价类 ：依据需求，划分出来【无意义，不合理的数据】构成的集合区间
例：163邮箱：手机号快速注册：密码：长度：两个无效等价类：小于8位的数据 大于16位的数据 数据类型：特殊符号构成的数据----->无效
-
等价类划分原则（了解）
①按照【区间】来划分：如果输入项中规定了【取值范围】或【值的个数】，划分出：一个有效等价类和两个无效等价类
例：成绩输入框：规则：[0,100]分数----->有效：0<=成绩<=100 无效：成绩<0 成绩>100 身份证号码输入框：规则：18位------>有效：18位 无效：大于18位 小于18位
②按照【数值】来划分：如果输入项中规定了n个值，每个值都必须测试，划分出：n个有效，一个无效
例：某一所大学的福利：如果学校中教师的身份：教授，副教授，院长，系主任，都可以得到一套房子
四个有效：教授身份的人构成的集合区间，副教授身份的人构成的集合区间，院长身份的人构成的集合区间，系主任身份的人构成的集合区间
一个无效：除了上述四个身份以外的人构成的集合区间
③按照【数据集合】来划分：如果输入项中规定了输入值的集合，划分出：一个有效，一个无效
例：名字需求：首个字符必须是字母
一个有效：以字母开头的数据构成的集合区间
一个无效：不以字母开头的数据构成的集合区间
④按照【规则】来划分：如果输入项中规定了必须要遵守规则的情况下，划分出：一个有效(满足规则的所有数据)，若干个无效(从不同角度违反规则)
例：需求：校内电话拨打外线号码以9开头
有效：9开头+外线号码
无效：非9+外线号码 9+非外线号码 非9+非外线号码
⑤其它情况：
（1）如果输入项是一个布尔量，划分出：一个有效，一个无效
（2）在已知划分好的等价类基础上，有些情况还可以继续进一步划分出更小的等价类
例：名字需求：一个无效：不以字母开头----->以数字开头的所有数据 无效，以特殊符号开头的所有数据 无效......
-
等价类划分法设计测试用例（分析思路）
①建立等价类表：梳理思路，划分出每一个输入项的有效等价类，无效等价类
输入条件 有效等价类 无效等价类 ②给划分出来的每一个等价类生成一个唯一的编号
③==设计一条用例，尽可能多的覆盖有效等价类（能用一条用例完成的，就不考虑第二条），直到把所有的有效等价类全部覆盖完成。==
④==设计一条用例，只覆盖一个无效等价类==
注意：当以某一个输入项进行违反规则设计测试用例时，其他的输入项均看成是满足/符合规则
-
回顾
-
测试需求："测什么"
-
测试用例："怎么测"
-
黑盒测试：
测试数据选择：等价类边界值法
测试步骤设计：因果图判定表法 场景法 正交实验法 功能图法
等价类划分法：思想：输入项----->划分集合区间：有效等价类：有意义，合理 无效等价类：无意义，不合理
-
边界值分析法
-
前提：成绩判定 ：[90,100] 优秀，[70,90) 良好，[60,70) 及格，[0,60) 不及格
if(grade>=90 && grade<=100){
alert("优秀")
}
-
概述：大量的测试工作经验告诉我们，大部分的错误往往发生在边界（并不是程序的内部），针对边界设计用例，能够发现更多的缺陷。边界值法是对等价类法的补充：通过等价类划分区间，结合边界值选取测试数据(边界数据)
-
边界：指的是输入或输出范围中，恰好处于边界，刚刚超越边界，边界以下的
-
边界值法设计用例（分析思路）：
①确定好边界的情况：输入项或输出的边界
②选取边界数据作为测试数据：刚刚等于，刚刚大于，刚刚小于的边界值
-
边界值分析法原则（了解）
①如果输入项规定了【取值范围】：则取刚达到的，刚超越（大于+小于）
例：成绩输入项：需求：0<=成绩<=100 测试数据：0 100 101 -1
价格输入项：[1.0,10.0] 测试数据：1.0 10.0 10.1 0.9
价格输入项：[1.00,10.00] 测试数据：1.00 10.00 0.99 10.01
②如果输入项规定了【值的个数】，则取最大个数值，最小个数值，比最大值大一，比最小值小一
例：一个文件（数据表）能够接收1-255条记录：测试数据：1 255 256 0
③1和2中的原则，也可以用于输出结果的判定
例：软件查询功能：至少每次会显示1条查询结果，最多不超过20条查询结果，测试数据：1 20 0 21
④如果是输入或输出是一个有序序列，测试数据：序列中的第一个元素，序列中最后一个元素
例：三部电梯：一部：1-4楼，二部：1-9楼，三部：1,4,6楼，怎么测？
⑤分析需求规格说明书，找出其它可能存在的边界条件：次边界值：隐藏的边界值
例：月份输入框：1-12 MySQL：数据类型：字段名 tinyint -128到127
小总结：等价类划分法用于测试数据的区间划分，划分完成后就可以借助于边界值分析法，选取具体的测试数据：测试数据=等价类+边界值
-
-
测试用例评审
- 目的：可以让用例的结构更加清楚，覆盖用户场景更加全面(设计不合理，遗漏的找出来)，也是提高用例设计水平方式之一
- 参与人员：测试部门相关人员，公司其它人员，客户（第三方）
7、黑盒测试用例设计方法（二）
针对测试步骤的设计方法
1、因果图法
-
思想：适用于【多种输入条件的组合】，设计测试用例，根据输入项的组合情况，以及约束关系，输出条件的因果关系，分析出可能会产生的组合场景，进行用例设计。
-
因果图法分析过程
①根据需求说明书，找出原因(条件)和结果之间的关系，画出因果图
原因和结果关系：
恒等：只要有条件a，一定会有结果b
非：只要有条件a，一定不会有结果b
或：abc三个条件只要满足其中一个，就会有结果d
与：abc三个条件必须同时满足，才会有结果d
②根据需求说明书，给因果图加上约束条件
（1）原因和原因之间的约束条件：
互斥E：abc三个条件，最多成立一个
包含I：abc三个条件，至少成立一个
唯一O：abc三个条件，有且只能成立一个
要求R：a条件的操作，要求b条件必须保持一致
（2）结果和结果之间的约束条件
屏蔽M：只要有结果a，就会屏蔽结果b
③根据因果图，转换出判定表（在表中整理出因果关系）
④判定表中每一个列，都是一条测试用例
小总结：因果图判定表法套路：根据需求说明----->分析因果关系----->画出因果图----->生成判定表----->根据表中的每一个列设计测试用例
2、判定表法
-
概述："判定表驱动法"，用来分析多个条件下，执行不同的组合操作情况------>分析工具：找出原因和结果（因为有些需求是比较明确，我们可以直接跳过因果图，利用判定表分析）
-
判定表组成
条件桩：指的是所有的输入条件（原因)
条件项：指的是每一个输入条件的取值
动作桩：指的是所有的输出结果
动作项：指的是所有输出结果的取值
规则：表中的每一个列，一个规则就是一条测试用例
-
判定表法设计用例：
①假如有n个条件，且每一个条件只有两个取值（0或1），那么故有2n个规则
②确定条件桩和动作桩：列出所有的输入条件和输出结果（问题和结果）
③分别填写条件项和动作项，生成初始化的判定表
④简化、合并、去重相似的规则或相同的动作(简化后的判定表是大家至少要设计的测试场景，不能再少了)
小总结：不管是因果图，还是判定表，最终的目的：实现不同条件之间的组合，产生不同结果的验证操作（因果图判定表法）
回顾
测试数据：等价类边界值法
测试步骤：因果图判定表法：功能：多条件组合情况
3、场景法(功能+业务)
-
概述：模拟用户使用软件时的操作场景（在不同的场景下来测试系统软件），主要测试系统的业务流程（毕竟一个软件的功能相当于是一个业务流程的体现）
-
场景法分析过程
-
场景法一般是由基本流和备选流组成：软件功能操作时，对应的各种{正确+错误}场景
基本流：指的是从执行程序开始，到程序执行结束，整个过程是【没有任何错误的场景】，将软件运行的流程正确的分析和表达出来。
备选流：指的是在基本流的基础上，会发生的【各种错误情况】所生成的场景。
例：ATM取款机：取钱功能：
基本流：正确的操作流程：插卡-------输入密码------选择取钱功能------输入取款金额-----确认出钱------退卡
备选流：各种错误情况：备选流一：密码输错三次，锁卡，备选流二：卡里余额不足，备选流三：取款机器没钱......
-
场景法在设计测试用例时，都是来源于【基本流和备选流之间组成的不同组合】生成的测试场景，一个场景就是一条测试用例
注意：一个完整的软件，基本流是固定的，因为基本流是功能业务最明确的体现，所以基本流是一个正确的操作流程或业务流程，没有任何其他错误的情况。备选流是在基本流的操作过程中出现的其他流程和分支（错误）
-
场景法用例设计：
-
确定基本流和备选流
例：根据案例描述，能够确定一个基本流和四个备选流
-
根据基本流和备选流的组合生成场景
例：根据上述案例，生成的场景有：
场景一：基本流
场景二：基本流+备选流1
场景三：基本流+备选流1+备选流2
场景四：基本流+备选流3
场景五：基本流+备选流3+备选流1
场景六：基本流+备选流3+备选流1+备选流2
场景七：基本流+备选流3+备选流4
场景八：基本流+备选流4
-
针对每一个场景设计测试用例（一个场景是一条用例）
-
如果有相似的场景，记得去重
案例分析2：
用户进入一个在线购物网站进行购物，选购物品后，进行在线购买，这是需要使用账号登录，登录成功后，进行付钱交易，交易成功后，生成订购单，完成整个购物过程。
根据上述需求，结合场景法设计测试用例(购物功能)
（1）确定基本流和备选流
基本流：进入购物网站-----选择物品------登录账号------付钱------生成订购单
备选流：
备选流一：账号不存在
备选流二：账号密码错误
备选流三：卡里余额不足
备选流四：卡里没钱
（2）根据基本流和备选流生成场景
场景一(购物成功)：基本流
场景二(账号不存在)：基本流+备选流1
场景三(账号密码错误)：基本流+备选流2
场景四(卡里余额不足)：基本流+备选流3
场景五(卡里没钱)：基本流+备选流4
（3）根据每一个场景设计测试用例
-
-
-
错误推测法
思想：是一种【基于经验和直觉】的测试方法，来推测程序中所有可能存在错误的地方，从而更有针对性的设计测试用例：列出程序中所有会存在或出现错误的特殊情况
例：针对计算器的除法功能：设计用例：关注一下：除数为0的情况验证
- 探索性测试
思想：测试人员一边学习和了解软件系统的特性，一边进行测试工作的开展，学习和测试是同步进行，从而了解软件更多的相关信息，从而设计测试用例。
4、正交实验法
-
概述：利用【正交表】对实验进行整体分析，设计、综合比较，实现通过【最少的实验次数找到较好的生产条件】，以达到最优的效果。从大量的实验中，选取具有代表性的实验点，放入到正交表，进行数据分析和实验的实施。
-
思想(设计测试用例分析)：
-
在实验中，把影响实验结果的量称为实验因素/因子，简称"因素/因子"
解析：在测试中，把影响测试结果的量称为"因素"----->输入项/输入条件
-
在实验中，每个因素所处的不同状态或状况，被称为因素的水平，简称"水平"----->因素的取值
解析：在测试中，水平相当于是每个输入项的取值
-
利用正交设计助手，生成正交表
备注：根据因素和水平的个数，选择合适的正交表：L4_2_3：会创建一个3因素2水平的正交表，生成4次实验：L实验次数_水平个数 _因素个数；如果没有合适的正交表，就选择稍大一点的
-
正交表中生成的每一个实验，就是一条测试用例
例：做实验：Word内容进行排版操作，请根据正交实验法，设计测试用例
第一步：找出影响word内容排版的因素有哪些？
字体大小 字体颜色 字体样式
第二步：确定每个因素的取值(选取一下每个因素的不同状态)
字体大小：水平：12 18 36
字体颜色：黑色 绿色 紫色
字体样式：水平：宋体 黑体 楷体
补充：3因素3水平：有3个因素点，每个因素点是有3个取值； 4因素5水平：有4个因素点，每个因素点是有5个取值
-
-
正交表特性：
-
表中每个列的值出现的次数是一样的，保证每个因素的水平值参与实验几率是一致的
-
表中任意两列横向组成的数据对，出现的次数是一样的，保证因素和水平的组合参与实验的概率也是一致的
-
-
典型的应用场景：软件中【设置模块】的测试用例
练习：利用正交实验助手，完成下列需求的实验生成
5、测试大纲法和Monkey测试
-
测试大纲法
思想：主要用于多个窗口，以及每个窗口之间包含的多种操作，这些窗口操作之间又存在一定的联系，为了更清楚窗口与窗口之间的关系，可以借助于测试大纲法。为了列清楚各种测试条件之间的关系，把过程转化成大纲的形式来进行描述。（弄清楚上一步操作和下一步之间的联系，上一个窗口和下一个窗口之间的关系）
应用场景：测试安装、卸载的功能操作；测试窗口之间的跳转关系；它也是着眼于需求的一种测试方法：梳理清楚需求之间的关系
-
Monkey测试：它是一种没有书面测试用例的测试方法，需要通过一系列的Monkey命令来完成测试，整个测试过程充满随机性。它更偏向于测试程序的稳定性，进行压力测试的一种手段。
缺点：测试过程往往不真实，会有较多的冗余（重复）的操作，测试的覆盖率很难达标。
6、测试用例设计方法综合选择策略(重点掌握)
- 针对任何有输入项数据的选择操作，必须等价类边界值法。
- 如果程序的功能说明中含有输入条件的组合情况，则一开始就要考虑因果图判定表法。
- 对于业务流程清晰的系统软件，可以利用场景法贯穿整个测试流程。
- 对于参数配置类的软件功能，可以利用正交实验法选择较少的参数组合达到最佳的测试效果。
- 利用错误推测法，再追加一些测试用例
- 如果用例的设计没有达到测试需求的全面覆盖，需要再补充足够多的测试用例
回顾
场景法：基本流（正确，没有任何错误场景）+备选流（各种错误的场景）
正交实验法：因素+水平
错误推测法：经验+直觉
探索性测试：学习和了解软件特性+测试工作
测试大纲法：安装，卸载功能测试，窗口与窗口之间跳转
Monkey测试：自动化测试
重点：测试用例设计方法综合选择策略