草帽路飞UU 发表于 2022-8-31 17:14:58

如何让你变成一位测试用例大师?

本帖最后由 草帽路飞UU 于 2022-8-31 17:16 编辑

一、概念

测试用例的基本概念:

测试用例(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、因素:52、水平数: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:使用了用例id2、标题:操作数据描述+预期+实际                测试数据结果描述+实际结果+预期                测试数据结果描述+实际结果+需求3、缺陷描述:操作步骤+数据
[*]正确示范:



缺陷标题实例:

1、测试数据描述+实际结果+预期:

不合格的4位qq验证合格(预期:不合格)
空密码登录成功(预期:登录失败,提示密码不可为空)
2、测试数据结果描述+预期+实际

验证4位qq不合格(实际:合格)
验证空密码登录不成功(实际:登录成功)
3、测试数据描述+实际结果+需求

不合格的4位qq验证合格(需求:6-10自然数)
空密码登录成功(需求:密码位6-12位数字+字母)

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




































页: [1]
查看完整版本: 如何让你变成一位测试用例大师?