一、概念
测试用例的基本概念:
测试用例(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位数字+字母)
以上三个模板都是可以套用的。
总结:
感谢每一个认真阅读我文章的人!!!
作为一位过来人也是希望大家少走一些弯路,如果你不想再体验一次学习时找不到资料,没人解答问题,坚持几天便放弃的感受的话,在这里我给大家分享一些自动化测试的学习资源,希望能给你前进的路上带来帮助。
软件测试面试文档
我们学习必然是为了找到高薪的工作,下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料,并且有字节大佬给出了权威的解答,刷完这一套面试资料相信大家都能找到满意的工作。
视频文档获取方式:
这份文档和视频资料,对于想从事【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴我走过了最艰难的路程,希望也能帮助到你!以上均可以分享,点下方小卡片即可自行领取。