转载声明：文章来源：https://blog.csdn.net/qq_54219272/article/details/122942139

一、概念
测试用例的基本概念：
测试用例（Test Case）是为了实施测试而向被测试的系统提供的一组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素 。
主要步骤：
测试环境——测试步骤——测试数据——预期结果
网易邮箱注册成功测试用例
标题：邮箱注册，邮箱输入项测试：
简单案例：

二、测试用例总体设计方案
基于需求的设计，RBT( Requirements-Based Testing)是基于需求的测试方法，会使测试更加有效，因为它使测试专注于质量问题产生的根源，即需求。
1、从整体角度设计分析测试用例：基于需求
用户需求——（整理出软件需求）产品设计文档（产品经理）——开发——测试——上线
（1）、验证需求的正确性和合理性
（2）、分析需求、细化需求、从需求中分解出测试项,根据测试项找出功能，进行测试用例的编写。
案列：

用户需求:
购买3000块钱以内的华为智能手机。
假如说：有一个活动秒杀 5999 为1块钱，这样也是发河价格的。
测试用例：
(1)合理
(2)分析：
价格：<=3000;
品牌：华为
手机类型：智能手机
手机基本功能：…
软件需求：
事件流
若用户未收到激活邮件，可在登录界面录入电子邮件及密码后，再次发送激活邮件。
每次发送的激活邮件，仅在发送邮件后起24小时之内有效，超过24小时后需重新发送激活邮件
测试用例：
1、用户收到邮件，不在此发送激活邮件；
用户收到邮件，再次录入电子邮件及密码，提示：已激活邮件；
用户未收到邮件，再次发送激活邮件；
2、24小时以内，有效
大于等于24小时，无效激活邮件
边界值：24小时点击激活,25小时重新发送邮件
容易忽略：24小时之内已经点击激活邮件，超过24小时又重新激活，将提示“系统已激活：。

测试激活邮寄的基本功能：
邮件能不能打开
邮件的格式，内容够是否正确；
邮件里面的激活链接是否正常；
这些是逻辑来测试用例。
1、等价类 ☆
等价类就是把输入划分成若干个等价类，从每一个等价类中取出一个测试用例，如果这个测试用例能够测试通过，那么我们就说这个测试用例代表的等价类测试通过。（衣柜分类衣服的例子）

通俗来讲，具有某种共同特征的数据集合进行划分！！

使用场景：测试用例无法穷举，我们无法一样测试。

有效等价类：符合程序规格说明的数据集合；

无效等价类：不符合软件需求规格说明的数据集合；

步骤：
1、明确需求。
2、确定有效等价类还是无效等价类
3、提取数据编写测试用例

案例一：
需求：验证qq账号的合法性
要求：6~8为自然数

案例一：

案例二（电话）：

需求：验证某城市电话号码的正确性
要求:
1.区号:空或者是三位数字
2.前缀码:非“O”且非“1”开头的三位数字
3.后缀码:四位数字

2、边界值 ☆
针对输入和输出的边界进行测试用例的设计。
案例：
购买3000元以内的华为只能手机
价格：<=3000,3001就不行
等价类：
有效等价类：小于3000
无效等价类：大于3000
边界值：2999 3000 3001

2.1 边界值法设计用例步骤
1、明确需求
2、确定有效和无效等价类
3、确定边界范围值
4、提取数据编写测试用例
案例一：

需求：通过边界值法验证标题长度的合法性
要求：标题大于0，小于等于30个字符

补充：边界范围节点：
1、上点，边界上的点
2、离点，举例边界上的点最近的点（刚好大于，刚好小于）遵循 开内闭外 原则
3、内点，范围内的点。

优化：

边界上的点：开内闭外。

3、判定表 ☆
解决多条件的依赖问题。
1、定义:是一种以表格形式表达多条件逻辑判断的工具。
2、组成：
条件桩：列出问题中的所有条件
动作桩：列出问题中可能采取的操作
条件项：列出条件对应的取值，所有可能条件下的真假值
动作项：列出条件项的、各种取值情况下应该采取的动作结果。

规则:
1、判定表中贯穿条件项和动作项的一列就是一条规则
2、假设有n个条件，每个条件的取值有两个(0,1)，全组合有2的n次方种规则

3、步骤：
1）、明确需求
2）、画出判定表
列出条件桩和动作桩
填写条件项，对条件进行全组合、根据条件项的组合确定动作项
简化、合并相似规则(有相同的动作)
3）、根据规则编写测试用例
4、案例一：

应用场景：
1、有多个输入条件，多个输出结果，输入条件之间有组合关系，输入条件和输出结果之间有依赖(制约)关系
2、判定表一般适用于条件组合数量较少的情况(比如4个条件以下)
3、提示:如果碰到项目中多条件组合大于4个相互依赖,可以使用
(正交表和因果图来实现)

4、因果图
当输入很多，并且不同的输入组合对应这不同的输出，这个时候用因果图法来分析不同输入组合和输出之间的对应关系。（相当于逻辑图）
逻辑关系：恒等 与 或 非

因果图法设计测试用例的步骤：
1、分析出所有的输入和输出；
2、找出输出和输出之间的关系；
3、画因果图；
4、画判定图；
5、把判定表转换成测试用例；

案例：淘宝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、错误猜测法
根据测试人员的直觉，知识，经验，判断软件的那一块有问题，专门针对性的设计测试用例，适合作为一种补充设计测试用例的方法
如：1、验证码大小写不区分；
2、空格搜索，把输入的搜索信息前后空格忽略；
7、正交排列
研究多因素多水平的一种方法，根据正交性选出最优的水平组合进行实验，用实验的结果来分析这个测试用例的结果。（选择最优的组合）
因素：输入的变量；
水平：因素的取值；
因素数：变量的个数；
水平数：变量取值的最大个数；

正交表的性质:

1、每一列不同数据出现的次数一样多；
2、任意两列各数据组合出现的次数一样多；

正交表设计测试用例的步骤：
1、找出所有的输入变量（因素），确定因素数；
2、确定变量的取值，确定水平数；
3、确定正交表的行和列；
4、根据正交表的性质去填写正交表
5、把正交表的每一行对应写成一个测试用例；
6、补充你认为重要的但没有体现在正交表中的测试用例；

例子：姓名，邮箱，密码，确认密码，验证码（输入和不输入）——不用正交表要列出2^5=32情况
1、因素：5
2、水平数：2（输入和不输入）
3、行：（水平数-1）*因素数+1=6
列：因素数：5
4、填写正交表

5、测试用例：
（1）、姓名输入，邮箱不输入，密码输入，确认密码输入，验证码不输入；
（2）、姓名输入，邮箱输入，密码不输入，确认密码不输入，验证码输入；
（3）、姓名输入，邮箱输入，密码输入，确认密码不输入，验证码不输入；
（4）、姓名不输入，邮箱不输入，密码不输入，确认密码输入，验证码输入；
（5）、姓名输不不入，邮箱输入，密码输入，确认密码输入，验证码输入；
（6）、姓名不输入，邮箱输入，密码不输入，确认密码不输入，验证码不输入；
三、实际操作中注意的点
3.1测试用例的注意点

作用：方便评审，方便执行
1、用例标题：预期结果（测试点）
2、验证码测试点：为空，正确，错误，过期
3、前置条件和测试步骤，测试步骤是按前置条件后进行的，要么前置条件写的多，要么测试步骤写的多。

合格测试用例标题：

四、缺陷介绍

软件中使用中任何问题都为缺陷，简称：bug

1、缺陷的判定标准
软件为实现需求（规格）说明书中明确要求的功能—少功能
软件出现了需求（规格）说明书中致命不应该出现的错误—功能错误
软件实现的功能超出需求（规格）说明书指明的范围—多功能（例：理发店）
软件未实现需求（规格）说明书中虽然为明确指明但应该实现的要求—隐形功能错误（例：手机点餐，显示有哪些菜）
测试人员认为软件难以理解，不易使用，运行缓慢，用户体验不好—不易使用
2、缺陷产生的原因：

是软件就有缺陷！！！！！！

3、软件缺陷的核心内容

4、缺陷类型
功能错误
界面（Ui）错误，兼容性（前端）
数据，易用性，改进建议，架构

1、如何区分是前端bug还是后端bug
1）、如果是界面和兼容性问题——前端问题
2）、如果是功能错误，需要 抓包 查看请求和响应！

扩展：什么是抓包

5、缺陷编写
1、缺陷报告示例：

2、缺陷的跟踪流程

面试题：发现bug后，首先会怎么办？ ——确认bug可复现。

5.1缺陷练习

错误示范：

1、缺陷Id：使用了用例id
2、标题：操作数据描述+预期+实际
		测试数据结果描述+实际结果+预期
		测试数据结果描述+实际结果+需求
3、缺陷描述：操作步骤+数据

正确示范：

缺陷标题实例：
1、测试数据描述+实际结果+预期：
不合格的4位qq验证合格（预期：不合格）
空密码登录成功（预期：登录失败，提示密码不可为空）
2、测试数据结果描述+预期+实际
验证4位qq不合格（实际：合格）
验证空密码登录不成功（实际：登录成功）
3、测试数据描述+实际结果+需求
不合格的4位qq验证合格（需求：6-10自然数）
空密码登录成功（需求：密码位6-12位数字+字母）

以上三个模板都是可以套用的。