软件测试（测试用例攻略）—写用例无压力

测试用例的基本概念：

测试用例（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)、根据条件项的组合确定动作项
• 简化、合并相似规则(有相同的动作)

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

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

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