一、测试用例组成
（一）测试用例的组成
- 用例编号，模块，测试点（测试标题），优先级，前提条件，测试步骤，期望结构，实际结果
- 并不是每一项都必须，有些是必须要有的，比如说测试点，测试步骤，预期结果
- 用例编号一般是模块名加数字的方式表示，如果在平台管理用例，那用例编号是自动生成的，用例编号是唯一的。
（二）优先级
- 优先级表示用例的重要程度
- 为什么设置优先级
在有限的测试资源和时间的情况下，发现最严重的错误，有时候时间很紧张，人力紧张，无法执行全部的用例，怎么保证产品的质量，先去执行优先级高的用例，保障了这些，基本功能就保证了。
测试用例根据重要性分成一定的等级
P0： 是最最核心的功能测试用例，比如冒烟用例，确定这个版本是不是可测，如果P0级别的用例执行不通过，那其他的测试用例都不用去测，直接把这个版本打回去给开发修改，改好后重新提测
P1：是高优先级别的，是保证功能是稳定的，基本的功能测试
P2：是中优先级别的，更全面的去验证功能的各个方面，比如边界测试，异常测试，网络测试，中断测试，容错性，UI测试等
P3：是低优先级的，不会常常被执行，大版本可能会执行一次，小版本就不执行了。比如说性能测试，压力测试，兼容性，安全测试，可用性等
（三）测试用例设计工具：思维导图、excel
二、设计测试用例
（一）黑盒测试方法论------等价类，边界值，因果图法，判定表，场景法
1.等价类划分法
等价类划分原则：
等价类设计步骤：
原则：一条测试用例尽可能多的覆盖有效等价类。对于无效等价类，每一个无效等价类，都必须有一条用例去覆盖他。
等价类划分法的优缺点：
优点：覆盖完全，取值不盲目
缺点：产生的用例多，会有无效的测试用例
2.边界值
边界值确定:
选取数据的时候，要考虑数据的类型和精度。如果边界上的点，上点是实数，精确度是0.01，这个时候离点就是上点加减0.01
边界点划分规则:
用边界值修改前后的用例（1~100内数字的加减）
3.因果图法
概念
因果图法是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法。
适用场景
适用于检查程序输入条件的各种组合情况
因果图法基本步骤
因果图法举例
4.判定表法
因果图和判定表是好朋友，可以 结合着用。
判定表的组成
判定表设计步骤
判定表举例
1.确定条件桩
2.确定动作桩
3.判定表分析
4.得出初始判定表
5.对判定表进行简化
1.abc不构成三角形，c1不成立，c2, c3, c4这三个条件是否成立没有意义，所以前面8个规则可以简化为1个规则
2.对于结果不可能的情况也可以不考虑
3.简化后剩6个规则，对这6个规则设计用例
6.设计测试用例
5.场景法
我们不能只关注一个部件的等价类，边界值，我们也需要关注功能，业务流程有没有实现。验证方法就会用到场景法
优点：适合有业务流程的
缺点：没有验证单个功能点，单个功能点需要用到等价类，边界值
场景法用例设计步骤
场景法案例： 淘宝购物
1.画流程图
2.确定基本流
3.确定备选流
4.构造场景
5.生成测试用例
测试步骤一步一步写清楚，用序号，达到不明白业务的人根据步骤可以完成操作
6.错误推断法
指利用直觉和经验猜测出出错的可能类型，有针对性的列举出程序中所有可能的错误和容易发生错误的情况
（二）选择设计用例的方法（黑盒）
- 任何情况下，都需要采用等价类划分法，将无限测试变成有限测试
- 在规定了数据范围的情况下，必须采用边界值分析法
- 如果需要关注它的主要功能和业务流程、业务逻辑是否正确实现， 考虑使用场景法
- 如果含有输入条件的组合情况，考虑选用因果图和判定表法
- 采用错误推断法再追加测试用例
（三）白盒测试方法
1.白盒测试的度量
根据待测产品的内部实现细节来设计测试用例
白盒测试的执行手段是可以涵盖单元测试、集成测试
使用代码覆盖率作为白盒测试的主要度量指标
2.代码覆盖率常见概念
语句覆盖：每行代码都要覆盖至少一次
判定覆盖：判定表达式的真假至少覆盖一次
判定/条件覆盖：判定覆盖与条件覆盖都必须覆盖
条件组合覆盖：判定表达式中的所有条件组合都需要覆盖
分支覆盖：控制流中的每条边都要被覆盖一次
路径覆盖：所有的路径都要尽量覆盖
指令覆盖：一行代码会被编译为多条指令，尽可能的覆盖所有指令
方法覆盖：每个方法至少要被覆盖一次
类覆盖：每个类至少被覆盖一次
3.覆盖率统计的工具
emma
cobertura
jacoco
4.插桩原理
对jvm的字节码插桩
基于block插桩
计算覆盖的代码块
5.流程覆盖
利用代码执行流代表流程
流程覆盖用路径覆盖率表达
对流程进行裁剪获得一个适合业务的小规模的业务子集
流程覆盖率=测试经过的路径/业务子集路径
6.精准化测试
代码调用链与黑盒测试用例的关联
根据代码变更自动分析影响范围
黑盒测试过程中借助代码流程覆盖数据指导探索式测试
利用线上数据推导有效测试用例
代码流程分析与覆盖率统计
三、测试用例编写
（一）测试用例编写步骤
第一步：划分功能模块
可以使用思维导图，把大功能里面小的功能点拆分出来，然后每个小功能点里的元素细节可以继续拆分出来，
第二步：正向功能验证
相当于冒烟测试
第三步：单个功能项验证
拆分页面功能，元素。 等价类，边界值
第四步：功能之间交互验证
验证场景用例
第五步：隐形需求
（二）实战演示
1.需求分析
2.编写用例
四、测试用例的粒度
- 测试用例可以写的很简单，也可以写的很复杂
- 最简单的测试用例是测试的纲要，仅仅指出要测试的内容
- 测试用例写的过于简单，则可能失去了测试用例的意义
- 测试用例写得过于复杂或详细，会带来两个问题:
- 效率问题
- 维护成本问题
粒度选择原则：
1、遵守公司对于测试粒度的要求，看一下前辈、公司同事对粒度的选择
2、要在场景覆盖完整的情况下，尽可能精简用例
五、测试用例评审
- 测试用例的本身的描述是否清晰，是否存在二义性
- 测试用例内容是否正确，是否与需求目标相一致
- 测试用例的期望结果是否确定、唯一
- 测试用例是否覆盖了所有的需求
- 测试用例是否具有可执行性
- 是否从用户层面来设计用户使用场景和业务流程的测试用例
- 场景测试用例是否覆盖最复杂的业务流程
- 用例设计是否包含了正面、反面的用例
六、经典面试题：
（一）测试用例设计思路
1.面试购物车测试用例设计思路
前言
关于测试用例设计是做测试的同学必须要具备的技能。不管是出去面试，还是在平常的工作当中，可以熟练设计测试用例基本是对测试人员的一个基本要求。
比如在面试中我们被问到给你一个购物车界面，你怎么测试这样一个问题。应该咱们回答呢？
测试用例设计思路
购物车设计测试用例是非常经典的一个面试题。一般在面试中回答测试用例设计的问题时，可以遵循以下的思路
对于购物车来说也是同样的思路。
需求分析
首先第一步要做的就是需求分析。不管是在什么场景中，都应该明确需求之后，再开始进行测试用例的设计。
在面试中，这一步可以体现为与面试官聊一聊需求的细节。
重点需要把 3 个方向的内容确认清楚：
1.确认测试范围
2.确认功能点
3.确认功能流程
使用思维导图的形式来梳理
下面就按照上面思路来梳理购物车的测试点。
界面测试
界面显示正常
界面布局合理美观
文案展示正确
功能测试
测试功能可以从这几个方面去考虑
具体的测试点比较多，请直接查看完整的思维导图。
易用性测试
快捷键功能是否支持
提示信息
操作引导
商品展示排序合理
兼容性测试
不同的产品在考虑兼容性测试的时候，方案是不一样的。
Web 产品的兼容需要重点考虑
- 浏览器
- 操作系统
- 分辨率
App 产品的兼容需要重点考虑
- 平台
- 厂商
- 设备型号
- 操作系统
- 分辨率
对于兼容性测试来说，需要保证在这些硬件环境中，产品的界面展示正确，功能可以正常使用。
性能测试
界面元素多次快速操作
响应时间
并发量
CPU
内存
App：耗电量、流量、压力测试
安全性测试
账号限制：登录超时、账号互踢
敏感信息加密传输
漏洞扫描
总结
在面试中被问到了购物车如何设计测试用例的时候，按照这样的思路来回答就可以了。
具体的测试点总结在以下思维导图
（二）你用过哪些用例设计方法？
考察点
测试基本理论
黑盒测试方法
技术点
常见黑盒测试方法
常见黑盒测试方法
等价类划分法：把用户所有可能输入的数据，划分成了若干子集，然后从每一个子集当中选取少数具有代表性的数据作为测试用例
边界值分析法：针对各种边界情况设计用例
因果图法：利用图解法分析输入的各种组合情况，从而设计测试用例
判定表法：直接编写判定表设计测试用例
场景分析法：模拟用户操作软件时的场景，主要用于测试系统的业务流程
错误推断法：指利用直觉和经验猜测出出错的可能类型，有针对性的列举出程序中所有可能的错误和容易发生错误的情况
答案总结
问题：你用过哪些用例设计方法？
我在测试用例设计过程中比较常用的测试方法有等价类划分法、边界值分析法、因果图法、判定表法、场景分析法、错误推断法等等: