测试用例|软件测试(测试用例)—写用例无压力

软件测试——用例篇
文章目录

  • 软件测试——用例篇
    • 一、概念
    • 二、测试用例总体设计方案
      • 1、等价类 ☆
      • 2、边界值 ☆
        • 2.1 边界值法设计用例步骤
      • 3、判定表 ☆
      • 4、因果图
      • 5、场景设计法 ☆
      • 6、错误猜测法
      • 7、正交排列
      • 三、实际操作中注意的点
        • 3.1测试用例的注意点
    • 四、缺陷介绍
      • 1、缺陷的判定标准
      • 2、缺陷产生的原因:
      • 3、软件缺陷的核心内容
      • 4、缺陷类型
      • 5、缺陷编写
        • 5.1缺陷练习

一、概念 测试用例的基本概念:
测试用例(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位数字+字母)
以上三个模板都是可以套用的。
? 以上就是软件测试用例的全部方法,重点掌握等价类,边界值,判定表,场景设计法,因为这四个是实际运用的多的,因果图和正交排列可以看看,知道下概念,写测试用例的时候尤其注意标题,标题可能影响你测试用例的好还,缺陷用例也是一样。铁汁们,觉得笔者写的不错的可以点个赞哟?,收藏关注呗,你们支持就是我写博客最大的动力!!!!

    推荐阅读