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

一、概念

测试用例的基本概念

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

主要步骤

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

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

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

简单案例

image-20220109225709851

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

基于需求的设计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为自然数

案例一

image-20220213174357895

案例二电话

需求验证某城市电话号码的正确性
要求:
1.区号:空或者是三位数字
2.前缀码:非“O”且非“1”开头的三位数字
3.后缀码:四位数字

image-20220214181555209

2、边界值 ☆

针对输入和输出的边界进行测试用例的设计。

案例

购买3000元以内的华为只能手机

价格<=3000, 3001就不行

等价类

有效等价类小于3000

无效等价类大于3000

边界值2999 3000 3001

2.1 边界值法设计用例步骤

1、明确需求

2、确定有效和无效等价类

3、确定边界范围值

4、提取数据编写测试用例

案例一

需求通过边界值法验证标题长度的合法性
要求标题大于0小于等于30个字符

image-20220214201754883

补充边界范围节点

1、上点边界上的点

2、离点举例边界上的点最近的点刚好大于刚好小于遵循 开内闭外 原则

3、内点范围内的点。

  • 优化

边界上的点开内闭外。

3、判定表 ☆

解决多条件的依赖问题。

1、定义:是一种以表格形式表达多条件逻辑判断的工具。

2、组成

  • 条件桩列出问题中的所有条件
  • 动作桩列出问题中可能采取的操作
  • 条件项列出条件对应的取值所有可能条件下的真假值
  • 动作项列出条件项的、各种取值情况下应该采取的动作结果。

规则:
1、判定表中贯穿条件项和动作项的一列就是一条规则
2、假设有n个条件每个条件的取值有两个(0,1)全组合有2的n次方种规则

3、步骤

​ 1、明确需求

​ 2、画出判定表

  • 列出条件桩和动作桩
  • 填写条件项对条件进行全组合3)、根据条件项的组合确定动作项
  • 简化、合并相似规则(有相同的动作)

​ 3、根据规则编写测试用例

4、案列一

image-20220215111953335

应用场景
1、有多个输入条件多个输出结果输入条件之间有组合关系输入条件和输出结果之间有依赖(制约)关系
2、判定表一般适用于条件组合数量较少的情况(比如4个条件以下)
3、提示:如果碰到项目中多条件组合大于4个相互依赖,可以使用
(正交表和因果图来实现)

4、因果图

输入很多并且不同的输入组合对应这不同的输出这个时候用因果图法来分析不同输入组合和输出之间的对应关系。相当于逻辑图

逻辑关系恒等 与 或 非

image-20220110195249867

因果图法设计测试用例的步骤

1、分析出所有的输入和输出

2、找出输出和输出之间的关系

3、画因果图

4、画判定图

5、把判定表转换成测试用例

案例淘宝618活动订单满300或者有红包测提交订单后享受优惠。

1、输入和输出

输入金额<300金额>300, 金额==300有红包无红包提交订单

输出享受优惠不享受优惠

2、输入和输出之间的关系

  • 订单已提交金额大于等于300 无红包享受优惠
  • 订单已提交金额大于等于300 有红包享受优惠
  • 订单已提交金额小于300有红包享受优惠
  • 订单已提交金额小于300无红包无优惠
  • 订单没有提交无优惠

3、画因果图

image-20220110201624623

4、根据因果图画判定表。

image-20220110205150297

5、场景设计法 ☆

现在的软件几乎都是用事件触发来控制流程的事件触发时的情景便形成了场景而同一事件不同的触发顺序和处理结果就形成事件流。该方法可以比较生动地描绘出事件触发时的情景有利于测试设计者设计测试用例是测试
用例更容易理解和执行。

典型的应用是是用业务流把各个孤立的功能点串起来为测试人员建立整体业务感觉从而避免陷入功能细节忽视业务流程要点的错误倾向.

  • 案例

ATM机取款场景

功能点插卡——输入密码——输入钱数——取款主要功能核心流程

具体功能点

1、插卡插反插错卡饭卡会员卡不是本行卡注销消磁冻结有不良记录的卡

2、输入密码密码错误密码输入正确密码三次错误第一次密码错第二次密码对前两次密码错第三次密码对

3、输入钱数钱数<=银行卡余额输入钱数>=银行卡余额输入的不是整百ATM机余额不足超过每日取款限额超过每次取款最大上限超过每次取款最大次数。

4、取款确认取款钱数后ATM机吐出对应钱数ATM机吐钞规则操作超时长时间不吐钱

5、其他ATM机断网断电出现故障超时所有的操作如果超时那么会出现吞卡安全机制

每个具体功能点都是可以写测试用例的。

如1、插卡插反第二次重新插入正确插入仍可以正常取钱卡冻结/注销无法正常取钱

​ 2、输入三次密码错误账户冻结无法取款前两次密码错第三次密码对仍可以正常取钱

  • 测试用例

image-20220215121219113

6、错误猜测法

根据测试人员的直觉知识经验判断软件的那一块有问题专门针对性的设计测试用例适合作为一种补充设计测试用例的方法。

如1、验证码大小写不区分

​ 2、空格搜索把输入的搜索信息前后空格忽略

7、正交排列

研究多因素多水平的一种方法根据正交性选出最优的水平组合进行实验用实验的结果来分析这个测试用例的结果。选择最优的组合

因素输入的变量

水平因素的取值

因素数变量的个数

水平数变量取值的最大个数

正交表的性质:

1、每一列不同数据出现的次数一样多

2、任意两列各数据组合出现的次数一样多

image-20220110221335796

正交表设计测试用例的步骤

1、找出所有的输入变量因素确定因素数

2、确定变量的取值确定水平数

3、确定正交表的行和列

4、根据正交表的性质去填写正交表

5、把正交表的每一行对应写成一个测试用例

6、补充你认为重要的但没有体现在正交表中的测试用例

例子姓名邮箱密码确认密码验证码输入和不输入——不用正交表要列出2^5=32情况

1、因素5

2、水平数2输入和不输入

3、行水平数-1*因素数+1=6

​ 列因素数5

4、填写正交表

image-20220110223037980

5、测试用例

1、姓名输入邮箱不输入密码输入确认密码输入验证码不输入

2、姓名输入邮箱输入密码不输入确认密码不输入验证码输入

3、姓名输入邮箱输入密码输入确认密码不输入验证码不输入

4、姓名不输入邮箱不输入密码不输入确认密码输入验证码输入

5、姓名输不不入邮箱输入密码输入确认密码输入验证码输入

6、姓名不输入邮箱输入密码不输入确认密码不输入验证码不输入

三、实际操作中注意的点

3.1测试用例的注意点

image-20220212211347313

作用方便评审方便执行
1、用例标题预期结果测试点
2、验证码测试点为空正确错误过期
3、前置条件和测试步骤测试步骤是按前置条件后进行的要么前置条件写的多要么测试步骤写的多。

合格测试用例标题

image-20220212212136181

四、缺陷介绍

软件中使用中任何问题都为缺陷简称bug

1、缺陷的判定标准

  • 软件为实现需求规格说明书中明确要求的功能 — 少功能
  • 软件出现了需求规格说明书中致命不应该出现的错误 —功能错误
  • 软件实现的功能超出需求规格说明书指明的范围 —多功能 例理发店
  • 软件未实现需求规格说明书中虽然为明确指明但应该实现的要求—隐形功能错误 例手机点餐显示有哪些菜
  • 测试人员认为软件难以理解不易使用运行缓慢用户体验不好 —不易使用

2、缺陷产生的原因

image-20220212152748622

是软件就有缺陷

3、软件缺陷的核心内容

image-20220212160436183

image-20220212161010041

4、缺陷类型

  • 功能错误
  • 界面Ui错误 兼容性 前端
  • 数据易用性改进建议架构
1、如何区分是前端bug还是后端bug
1、如果是界面和兼容性问题——前端问题
2、如果是功能错误需要 抓包 查看请求和响应
  • 扩展什么是抓包

image-20220213163149180

5、缺陷编写

1、缺陷报告示例

image-20220212202318168

2、缺陷的跟踪流程

image-20220212203125572

面试题发现bug后首先会怎么办 ——确认bug可复现。

5.1缺陷练习

错误示范

image-20220212212231694

1、缺陷Id使用了用例id
2、标题操作数据描述+预期+实际
		测试数据结果描述+实际结果+预期
		测试数据结果描述+实际结果+需求
3、缺陷描述操作步骤+数据
  • 正确示范

image-20220215123649487

缺陷标题实例

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

  • 不合格的4位qq验证合格预期不合格
  • 空密码登录成功预期登录失败提示密码不可为空

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

  • 验证4位qq不合格实际合格
  • 验证空密码登录不成功实际登录成功

3、测试数据描述+实际结果+需求

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

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


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

阿里云国内75折 回扣 微信号:monov8
阿里云国际,腾讯云国际,低至75折。AWS 93折 免费开户实名账号 代冲值 优惠多多 微信号:monov8 飞机:@monov6