软件测试——用例篇

一、概念

测试用例的基本概念：

测试用例（Test Case）是为了实施测试而向被测试的系统提供的一组集合，这组集合包含：测试环境、操作步骤、测试数据、预期结果等要素 。

主要步骤：

测试环境——测试步骤——测试数据——预期结果

网易邮箱注册成功测试用例

标题：邮箱注册，邮箱输入项测试：

简单案例：

二、测试用例总体设计方案

基于需求的设计，RBT( Requirements-Based Testing)是基于需求的测试方法，会使测试更加有效，因为 它使测试专注于质量问题产生的根源，即需求。

1、从整体角度设计分析测试用例：基于需求

用户需求——（整理出软件需求）产品设计文档（产品经理）——开发——测试——上线

（1）、验证需求的正确性和合理性

（2）、分析需求、细化需求、从需求中分解出测试项 ,根据测试项找出功能，进行测试用例的编写。

案列：

用户需求:
购买3000块钱以内的华为智能手机 。

假如说：有一个活动秒杀 5999 为1块钱，这样也是发河价格的。

测试用例：

(1)合理

(2)分析：

价格：<=3000;

品牌：华为

手机类型：智能手机

手机基本功能：…

软件需求：
事件流

1. 若用户未收到激活邮件，可在登录界面录入电子邮件及密码后，再次发送激活邮件 。
2. 每次发送的激活邮件，仅在发送邮件后起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)、根据条件项的组合确定动作项
• 简化、合并相似规则(有相同的动作)

​ 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位数字+字母）

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

---

​ 以上就是软件测试用例的全部方法，重点掌握等价类，边界值，判定表，场景设计法，因为这四个是实际运用的多的，因果图和正交排列可以看看，知道下概念，写测试用例的时候尤其注意标题，标题可能影响你测试用例的好还，缺陷用例也是一样。铁汁们，觉得笔者写的不错的可以点个赞哟❤🧡💛💚💙💜🤎🖤🤍💟，收藏关注呗，你们支持就是我写博客最大的动力！！！！