一、概念：
测试用例：为了实施测试而向被测试的系统提供的一组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素。
主要步骤：
测试环境（预置条件）-测试步骤-测试数据-预期结果（测试说明）
示例：
1、邮箱注册成功测试用例
标题：邮箱注册，邮箱输入项测试：
二、总体设计方案
基于设计需求的设计，RBT（Resquirements-Based Testing）基于需求的测试方法
用户需求-（整理出软件需求）产品设计文档（产品经理）-开发-测试-上线
（1）、验证需求的正确性
（2）、分析需求、细化需求、从需求中分解出测试项，根据测试项找出功能，进行测试用例的编写。
1、等价类
概念：
把输入划分成若干个等价类，从每个等价类中取出一个测试用例，如果这个测试用例能够测试通过，那么我们说这个测试用例代表的等价类测试通过。
使用场景：测试用例无法穷举（数据类：比如手机号码是否合规，所有的手机号码无法穷举），我们无法一样测试
- 有效等价类：符合程序规格说明的数据集合
- 无效等价类：不符合程序规格说明的数据集合
步骤：
- 明确需求
- 确定有效等价类还是无效等价类
- 提取数据编写测试用例
2、边界值
概念：
针对输入和输出的边界进行测试用例的设计
步骤：
- 明确需求
- 确定有效和无效等价类
- 确定边界值范围
- 提取数据编写测试用例
案例：
购买3000元以内的手机
等价类：
有效：小于3k
无效：大于3K
所以边界值：2999，3000，3001
补充：
- 上点：边界上的点
- 离点：距离边界上的点最近的点（刚好大于或者小于）遵循开内闭外原则
- 内点：范围内的点
3、判定表
概念:
- 解决多条件的依赖问题。
- 一种表格形式表达多条件逻辑判断的工具
- 组成：
- 条件桩：列出问题的所以条件
- 动作桩：列出问题可能采取的操作
- 条件项：列出条件对应的取值，所有可能条件下的真假值
- 动作项：列出条件项的各种取值情况下应该采取的动作结果。
步骤：
- 明确需求
- 画出判定表
-
- 列出条件桩和动作桩
- 填写条件项，对条件项进行安全组合、根据条件项的组合确定动作项
- 简化、合并相似规则（相同的动作）
- 根据规则编写测试用例
应用场景：
1、有多个输入条件，多个输出结果，输入条件之间有组合关系，输入条件和输出结果之间有依赖(制约)关系
2、判定表一般适用于条件组合数量较少的情况(比如4个条件以下)
3、提示:如果碰到项目中多条件组合大于4个相互依赖,可以使用
(正交表和因果图来实现)
4、因果图
当输入很多，并且不同的输入组合对应不同的输出，这个时候用的因果法来分析不同输入组合和输出之间的对应关系。（逻辑图）
步骤：
- 分析出所有的输入和输出
- 找出输入和输出之间的关系
- 画出因果图
- 画出判定图
- 把判定图转换成测试用例
案例：淘宝618活动，订单满300，或者有红包，测试提交订单后享受优惠。
1、分析输入和输出
输入：订单金额>300,<300,=300，有红包，无红包，提交订单
输出：享受优惠，不享受优惠
2、对应关系
- 订单已提交，金额>=300,无红包，享受优惠
- 订单已提交，金额>=300，有红包，享受优惠
- 订单已提交，金额<300，有红包，享受优惠
- 订单已提交，金额<300，无红包，不享受优惠
- 订单未提交，无优惠。
3、因果图：
4、判定图：
5、场景设计法
现在的软件几乎都是用事件触发来控制流程，事件触发时的情景形成场景，同一个事件不同的触发顺序和处理结果就形成的事件流，这个方法可以比较生动来描绘出事件触发时的场景，有利于测试的用例设计。
典型的应用是是用业务流把各个孤立的功能点串起来，为测试人员建立整体业务感觉，从而避免陷入功能细节忽视业务流程要点的错误倾向.
案例：
ATM机取款场景
功能点：插卡——输入密码——输入钱数——取款（主要功能，核心流程）
具体功能点：
（1）、插卡：插反，插错卡（饭卡，会员卡，不是本行卡），注销，消磁，冻结，有不良记录的卡
（2）、输入密码：密码错误，密码输入正确，密码三次错误，第一次密码错第二次密码对，前两次密码错第三次密码对
（3）、输入钱数：钱数<=银行卡余额，输入钱数>=银行卡余额，输入的不是整百，ATM机余额不足，超过每日取款限额，超过每次取款最大上限，超过每次取款最大次数。
（4）、取款：确认取款钱数后，ATM机吐出对应钱数；ATM机吐钞规则，操作超时，长时间不吐钱；
（5）、其他：ATM机断网，断电，出现故障；超时，所有的操作如果超时，那么会出现吞卡（安全机制）
每个具体功能点都是可以写测试用例的。
如：1、插卡插反：第二次重新插入正确插入，仍可以正常取钱；卡冻结/注销，无法正常取钱；
2、输入三次密码错误，账户冻结，无法取款；前两次密码错第三次密码对，仍可以正常取钱
- 测试用例：
6、错误猜测法
根据测试人员的直觉，知识，经验，判断软件的那一块有问题，专门争对性的设计测试用例，适合作为一种补充设计用例的方法。
比如：
验证码的大小写不区分
空格搜索，把输入的搜索信息前后空格忽略。
7、正交排列
研究多因素多水平的一种方法，根据正交性选出最优的水平组合进行实验，用实验结果来分析这个测试用例的结果。（选择最优的结果）
- 因素：输入的变量
- 水平：因素的取值
- 因素数：变量的个数
- 水平数：变量取值的最大个数；
正交表的性质：
- 每一列不同数据出现的次数一样多
- 任意两列数据组合出现的次数一样多
用例设计步骤：
- 找出所有的输入变量（因素），确定因素数
- 确定变量的取值，确定水平数
- 确定正交表的行和列
- 根据正交表的性质去填写正交表
- 把正交表的每一行对应写成一个测试用例
- 补充你认为重要的但是没有体现在正交表中的测试用例；
案例：姓名，邮箱，密码，确认密码，验证码（输入和不输入）——不用正交表要列出2^5=32情况
1、因素：5
2、水平数：2（输入和不输入）
3、行：（水平数-1）*因素数+1=6
列：因素数：5
填写正交表
测试用例：
（1）、姓名输入，邮箱不输入，密码输入，确认密码输入，验证码不输入；
（2）、姓名输入，邮箱输入，密码不输入，确认密码不输入，验证码输入；
（3）、姓名输入，邮箱输入，密码输入，确认密码不输入，验证码不输入；
（4）、姓名不输入，邮箱不输入，密码不输入，确认密码输入，验证码输入；
（5）、姓名输不不入，邮箱输入，密码输入，确认密码输入，验证码输入；
（6）、姓名不输入，邮箱输入，密码不输入，确认密码不输入，验证码不输入；
三、实际操作中注意的点
3.1、测试用例注意点：
- 用例标题：预期结果（测试点）
- 验证码测试点：为空，正确，错误，过期
- 前置条件和测试步骤：
-
- 测试步骤是执行前置条件后执行的
- 要么前置条件写得多
- 要么测试步骤写得多
合规的测试用例：
四、缺陷介绍
软件使用中任何问题都为缺陷，bug
- 判定标准：
-
- 软件为了实现需求（规格）说明书中明确要求的功能---少了功能
- 软件出现了需求（规格）说明书中致命不应该出现 的错误---功能错误
- 软件实现的功能超出需求（规格）说明书指明的范围---多功能
- 软件未实现需求（规格）说明书中虽然未明确指明但应该实现的要求----隐形功能错误
- 测试人员认为软件难以理解，不易使用，运行缓慢，用户体验不好---不宜使用
- 缺陷产生原因:
-
3. 缺陷核心内容
- 缺陷类型
-
- 功能错误
- 界面（ui）错误，兼容性（前后端）
- 数据，易用性，改进建议，架构
-
- 如何区分前端bug还是后端bug
- 如果是界面和兼容性问题---前端问题
- 如果是功能错误，需要抓包，查看请求和响应
- 什么是抓包
-
- 缺陷编写
-
- 缺陷报告示例：
-
- 缺陷跟踪流程
