软件测试用例篇(2)

需求分析---->需求有哪些功能---->根据需求来设计测试点---->根据测试点来设计测试用例

设计测试用例的前提是基于需求来进行设计测试用例,要严格的依据需求文档和产品规格说明书,根据需求来提炼出测试点,然后根据测试点来设计具体的测试用例这是概要测试用例

功能测试+界面测试+兼容性测试+安全测试+易用性测试+性能测试

软件测试|黑盒、白盒、灰盒测试的区别_只有黑盒测试没有白盒测试可以吗-CSDN博客

软件测试(测试用例)—写用例无压力_鸢也的博客-CSDN博客

针对有需求的案例来设计测试用例:邮箱注册,部分测试用例

https://zay1xofb7z6.feishu.cn/mindnotes/bmncnKD5Ak6GSZl3PRlWDgF9z3g#mindmap

针对有需求的案例来设计测试用例:邮箱注册,部分测试用例

加入说给定的软件需求就是:提示姓名长度是6-15位,那么此时就可以进行枚举6,7,8.....15,可以通过穷举法来设计测试用例,如果测试用例通过,那么认为该功能符合要求

需求分析---->需求有哪些功能---->根据需求来设计测试点---->根据测试点来设计测试用例

加入说给定的软件需求就是:提示姓名长度是6-15位,那么此时就可以进行枚举6,7,8.....15,可以通过穷举法来设计测试用例,如果测试用例通过,那么认为该功能符合

一)等价类:

分区分块来使用,使用比较少的测试用例来达到符合系统需求的测试覆盖,从等价类中抽取几个有代表性质的测试用例,那么就代表这几个测试用例所代表的等价类测试通过

分区分块来使用,使用比较少的测试用例来达到符合系统需求的测试覆盖,从等价类中抽取几个有代表性质的测试用例,那么就代表这几个测试用例所代表的等价类

就是假设说对于图书馆的书籍整理来说,图书馆的书藉摆放都是来分区域的,包括计算机专业书籍,机电专业书籍,会计专业书籍,从一个区域里面拿出来一本书,如果要证明这一片区域都是计算机区域,是否需要一本一本的去证明呢?不需要,只要说这个专栏里面只需要选入一本书,如果是计算机类的书籍,那么就直接选择

如何基于等价类来设计测试用例?
划分有效等价类和无效等价类+根据等价类来编写测试用例:

有效等价类:针对于产品规格说明书来说是有效且有意义的数据构成的集合

无效等价类:针对于产品规格说明书来说无效况且没有意义的数据组成的集合

场景需求:姓名长度是6-200位,那么如何进行设计测试用例?

对于软件来说,开发人员实现需求里面的要求,也要避免实现需求里面没有要求的,不符合需求要求的你实现了,那么就是一个BUG

1)划分有效等价类和无效等价类

有效等价类:6-200

无效等价类:(0-5)&(200~+OO)

无效等价类更考验同学们的一个发散性思维

2)根据等价类来编写测试用例:

练习:针对需求密码是6-20位的数字来设计无效等价类

长度:针对于长度设计无效等价类,数字长度大于6小于20

类型:数字+字符串+其他的类型

无效等价类:

1)只包含数字位数小于6或者是位数大于20

2)不仅仅位数小于6或者位数大于20,不只是包含数字,但是在正确范围之外又出现数字的其他符号

2)虽然位数大于6或者是位数小于20,但是不仅仅包含数字还含有其他符号,也就是在正确范围内有出现数字的其他符号;

有效等价类:对于程序的规格说明书是合理的,有意义的输入数据组成的集合,利用等价类验证程序是否实现了规格说明中所规定的功能和性能; 

无效等价类:根据需求说明书,不满足需求的集合;

1)对于我们上面说的if语句,有效等价类就是a>10的数据,无效等价类就是a<=10的数据

2)例如我想要去商店买水果,有效等价类是苹果,桃子和梨,无效等价类是饮料,米

if(a>10)
{
    printf("a大于10");
}
    b=a;
   printf("b等于a");
}
这时把a>10的数据归到一个等价类中
把所有小于10的数据归到一个等价类中
例如拿1和15举例子

输入用户名(必填项):字符类型A-Z,不区分大小写,长度是6-15位任何长度(6和15就是边界)

1)有效等价类:A-Z,a-z,大小写混合,大于等于6位,小于等于15位;

2)无效等价类:汉字,特殊符号#,?(),!,数字,空格,字母和前面符号的混合,小于6位,大于15位;

二)边界值法:考虑边界值和次边界值

2.1)定义:边界值是对等价类的补充,边界值分析法就是对输入或者输出的边界值进行测试的一种黑盒的测试方法,通常边界值分析法是对等价类划分法的补充,这种情况下其测试用例来自于等价类的边界;

2.2)特点:针对输入输出的边界进行测试用例的设计,因为边界是一种特别出现错误的地方,是一种黑盒测试方法,通常测试边界值和次边界值;

2.3)需求:活动截止日期是7.14,变量是datetime;

if(datetime<7.15 00.00.00)

if(datetime<=7.14 23.59.59)

2.4)边界值法就可以这么写,这就是边界值的重要性;

2.5)1的边界值是0和2,-1的边界值就是-2和0

时间:7月14号00:00:00 23:59:58,7月15日00:00:00 0:0:0

1)for循环(int i=0;i<arr1.length();i++),因为往往会出现问题,买一个小于3000元的智能手机,3000就是一个边界点;邮件小于24小时有效,24小时就是一个边界点,我们可以对23小时59分进行测试,和24小时01分开始测试;

2)还有6-15位,那么就要对5,6 ,7和14位,15位,16位边界点进行测试;

3)设计测试用例的时候,会把等价类和边界值结合在一起用于进行测试用例的设计;

活动截止日期是7:18号也就是截止到7:19 00:00:00

边界值:7.19 00:00:00不能参加此活动

次边界值:7.18 23:59:59 7.19 00:00:01

三)判定表:确认输入输出条件+确认输入输出条件之间的关系+画判定表+根据判定表来编写测试用例,它是一种表达逻辑关系的表

使用场景:需要考虑输入之间的组合关系,不同的组合关系对应的输出结果不同

我认为因果图法画判定表很多余,而且因果图实际上在设计测试用例的时候并没有多大意义

第一步因为在通过判定表设计测试用例的时候

前提也是要找出输入条件和输出条件之间的关系

第二步就是根据输入条件和输出条件找出它们之间的一个对应关系,因果图也是找这样的一个输入和输出之间的关系

只是多了一步前提是画因果图,将因果图转化成判定表,多此一举,分析完输入和输出的关系直接就可以画判定表了,不需要画因果图,直接画判定表即可

1)定义:逻辑图,当输入有多个,并且不同的输入的组合对应着不同的输出结果,可以用因果图法来分析这个输入和输出之间的逻辑关系,来设计测试用例,有效地防止漏测;

使用场景:需要进行考虑输入之间的组合关系,不同的组合关系对应的输出结果不同;

输入有多个,不同的输入组合有不同的输出,为了防止漏测,就要用因果图来设计测试用例

2)需求:淘宝618活动,订单已经提交,订单总金额大于300元或者订单有红包,则认为该订单属于有优惠的订单,否则认为此订单没有优惠的订单

3)判定表设计测试用例的步骤:

1)确认输入条件和输出条件

2)找到输入条件和输出条件之间的关系

3)画判定表

4)根据判定表来编写测试用例

一)确认输入输出条件

输入条件:

1)是否提交订单?输入:提交订单,没有提交订单;

2)订单金额是否大于300?输入:金额大于300元或者小于等于300元

3)是否有红包?输入:订单有红包,订单无红包

输出条件:

输出(订单类型):有优惠,没有优惠

二)确认输入输出条件之间的关系,标记对应的字母方便进行组合,两两组合或者是三个三个组合

A:提交订单,B:没有提交订单

C:金额大于300元,D:金额小于300元

E:订单有红包,F:订单没有红包

因为所有的情况都要包含A或者B,根据排列组合,划分除了以下几种情况:

ADE,ADF,ACE,ACF,BCE,BCF

BDE,BDF,AC,AD,AE,AF,B,A,非ABC

订单已提交,没有红包,订单大于300,有优惠

订单已提交,有红包,金额大于300,有优惠

订单已提交,有红包,订单小于300,有优惠

订单已提交,没红包,订单没有大于300,没有优惠

订单未提交,没有红包,订单大于300,没有优惠

订单未提交,有红包,金额大于300,没有优惠

订单未提交,有红包,订单小于300,没有优惠

订单未提交,没红包,订单没有大于300,没有优惠

红包和金额组成了四种情况:

1)订单没有提交,金额大于300,有红包,没有优惠

2)订单没有提交,金额大于300,没有红包,没有优惠

3)订单没有进行提交,金额小于300,有红包,没有优惠

4)订单没有提交,金额小于300,没有红包没有优惠

三)画判定表:画判定表,使用飞书新建表格,符合条件使用Y表示,不符合条件使用N来表示

四)根据判定表来编写测试用例

进行组合情况:

四)正交表

定义:针对输入条件进行排列组合,研究多水平,多因素的一种测试用例的设计方法

因素数:输入的条件的个数

水平数:输入的条件对应的取值,不是输出结果

多因素:输入类型的种类,比如说订单已提交,有红包,金额大于300
多水平:对于每一种输入的取值,因素的取值,例如订单已经提交,订单没有进行提交,金额大于300,金额小于300,有红包,没有红包

正交表的性质:想让我们设计正交表非常难,呜呜呜,但是有一个专门生成正交表的工具

1)每一列中,不同的数字出现的次数相等,每一列数字出现的次数是相等的,例如在两水平正交表中,任何一列都有数码"1"与"2",且任何一列中它们出现的次数是相等的,如在三水平正交表中,任何一列都有"1"、"2"、"3",且在任一列的出现数均相等

2)任意两列的数字的排列次数齐全况且均衡,假设第一列和第三列进行组合,第一列中的第一行和第三列第一行组合成了ac,又发现第一列的第四行和第三列的第四行又组成了ac,这里的组合是存在先后顺序的,从左向右看,这样子ac组合就出现了两次;那么假设说如果第一列的第二行和第三列的第二行组成的字母组合是bc,那么必定第一列的第N行和第三列的第N行的组成序列是bc,也一定出现两次;

 正交表设计测试用例的方法:

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

1)  找出因素数和水平数

2)确定每一个因素的水平

3)根据因素数和水平数确定正交标的行和列

4)根据正交表的性质去填充正交表里面的数据

5)根据正交表的每一行设计测试用例,正交表里面的填写的值都是水平数

6)补充正交表里面没有的,但是你认为比较关键的测试用例

例子:平台支持邮箱注册功能 

第一种方案:手动设定正交表

例如说邮箱注册,在这种情况下只考虑填写和不填写两种情况

填写姓名,邮箱,密码,确认密码,验证码

一)找出因素书和水平数

因素:姓名,邮箱,密码,确认密码,验证码

水平:填写,不填写

针对所有的因素,只有相同的两种取值,就是填写和不填写

二)确定行和列

行=(水平数-1)*因素数+1;

列=因素数

因素数:5

水平数:2

列=因素数=5,行=(水平数-1)*因素数+1=6

为了验证注册的这5个必填项分别在填写和不填写各种情况下的表现,只要这里面有不填写的项,就都会注册失败

三)画正交表:

四)根据正交表编写测试用例

根据这个正交表此时就可以写测试用例了,测试用例为等等等

1)姓名输入,邮箱不输入,密码输入,确认密码输入,验证码不输入,注册失败

2)姓名输入,邮箱输入,密码不输入,密码不输入,验证码不输入,注册失败

五)补充测试用例

除此之外还要考虑姓名,邮箱,密码,确认密码,验证码全部输入;

姓名,密码,邮箱,确认密码,验证码全部不进行输入;

推荐第二种方案:工具设计正交表

1)找到因素数和水平数

2)使用allparis工具来生成正交表

3)根据正交表来填写测试用例

4)补充测试用例

一)找到因素数和水平数

因素数:姓名,电子邮箱,密码,确认密码,验证码

水平数:填写和不填写

第一行填写因素数下面全部填写水平数

二)使用allpairs工具生成正交表,不再使用计算行和列的方式

2.1)下载pairs压缩包进行解压缩,解压缩生成正常的文件夹之后,打开文件看到了allpairs.exe文件

2.2)在飞书里面或者是excel表格里面列出所有的因素数和水平数

 2.3)在这个文件夹目录下面新创建一个文本文档txt,把在excel表格中的因素数和水平数进行复制粘贴

 

2.4)直接点击ctrl+s保存,将文件保存

2.5)打开控制台,直接进行运行

2.5.1)先切换到D盘

2.5.2)切换到pairs目录

2.5.3)执行exe文件,命令里面指明源文件和最终要生成的文件

注意:使用allpairs生成的正交表和实际的正交表有出路,但是仍然是不会影响到使用allpairs来设计测试用例,也就是说会有遗漏的测试用例;

三)根据正交表编写测试用例

总结:如何使用allpairs工具生成正交表?

1)确认因素数和水平数

2)把因素数和水平数写入到excel表格中直接进行复制excel中的内容,什么也不要加比如空格

2)找到allpairs文件夹路径,新建文本将因素数和水平数粘贴到文本中

3)打开cmd,cd到allpairs文件夹路径底下,找到allpairs.exe,在cmd上执行命令,找到allpairs.exe源文件>目标文件,目标文件就是生成的正交表

4)根据生成的正交表编写测试用例

5)直接补充测试用例

四)场景设计法:根据需求来设计测试用例

很多软件不同的场景,是基于不同的事件来进行触发的,不同事件的触发,导致场景走向不同的事件流,可以把不同的功能点串起来当成一个场景,不同的功能点有着不同的输出,不同的输出导致不同的测试场景

主要分为基本事件流和多个备用事件流

基本事件流:最基本的流程

备用事件流:除了基本事件流以外一些其他的情况

想想一下在这个过程中其他的一些可能的操作是什么

总结:找出场景中的每一个功能点,根据每一个功能点的正常的和异常的情况去设计测试用例

以ATM机取款为例:

插卡----->选择语言---->输入密码----->选择取款业务----->输入取款金额------->出钞------>吐卡
1)插卡

1.1)卡插反了,提示请重新插入卡
1.2)卡插错了,插入一些饭卡,会员卡,公交卡,其他无法识别的银行卡

1.3)卡无效,卡的磁片消磁,损坏,提示该银行卡无效,注销卡;

1.4)卡号冻结,账户锁死

1.5)断电断网

1.6)一张卡也不插

2)选择语言

选择英语不能显示是中文,选择中文不能显示英语

3)输入密码

密码输入正确

密码输入错误

1)密码输入共有三次机会,密码第一次输入错误,第二次输入正确,可以取钱

2)密码前两次输入错误,第三次输入正确,可以取钱

3)三次都输入错误,吞卡/账户锁定

4)密码是否加密

5)输入框是否支持不同字符输入

6)密码输入框是否支持删除

7)什么密码也不输入

4)选择取款业务

1)充值服务

2)存款服务

3)转账服务

5)取款金额

输入小于取款钱数,输入等于取款钱数,输入大于取款钱数

5.1)输入钱数小于等于银行卡总金额,输入钱数大于银行卡金额(系统提示)

5.2)输入的不足整百,不是整百的倍数,选择超过5W的金额,选择刚好是5W的金额,选择小于5W的金额

5.3)超过每日取款限额

5.4)超过每日取款最大次数

5.4)ATM机没钱(输入余额小于银行卡余额)

5.5)取款时,确认取款钱数后,ATM机会吐出相应的钱数

5.6)比如说长时间不取吞出来的钱,ATM机会自动把吐出来的钱收回到ATM机里面

5.7)不输入直接按下取钱按钮

5.8)长时间不操作看看是否超时

6)等待出钞

6.1)机器计算故障:机器故障导致不出钞,少出钞,多出钞票

6.2)机器停电,ATM机断电,断网,出现故障

6.3)当用户的所有操作都超时,就会出现吞卡,这是一种安全机制;

7)吐卡

7.1)忘记取卡,肯定要吞卡,防止卡丢了,这是一种保护机制

7.2)正常吐卡

7.3)不吐卡

编写测试用例:基本事件流+异常事件流

基本事件流:

卡成功插入进ATM机,选择合适的语言,密码输入正确,输入小于银行卡余额的钱数,取钱成功,退卡出卡

备用事件流:

1)插入银行卡,第一次输入密码输入错误,第二次输入密码正确,选择取款业务,输入小于银行卡余额的钱数,取钱成功,退卡出卡

2)插入银行卡,第一次输入密码输入错误,第二次输入密码错误,第三次输入正确,选择取款业务,输入小于银行卡余额的钱数,取钱成功,退卡出卡

五)错误猜测法:这是根据测试人员的直觉,知识,经验,判断软件的哪一块有问题,找哪一个功能模块有问题,专门针对性的设计测试用例,依赖于测试人员的个人经验和积累

验证码大小写是否进行区分?把输入的搜索信息的前后空格忽略

依赖于测试人员的个人工作经验和积累

测试人员可以用其他设计测试用例的方法设计需求的测试用例,用错误猜测法作为一种补充的方式,这个方法最后再用,一旦有遗漏的测试面,线上就会出现问题

MYSQL+Redis

  • 2
    点赞
  • 13
    收藏
    觉得还不错? 一键收藏
  • 2
    评论
测试阶段 3 测试用例的分类 3 文本框需求 4 字段为特殊代码校验: 4 文本框为数值型 4 文本框为日期型 5 文本框为时间型 6 密码框 返回目录 6 单选按钮 7 组合列框/下拉列 7 数码框(up-down)控件 8 搜索框填充域测试 8 复选框 9 滚动条 9 通过测试: 返回目录 9 失败测试: 10 登陆 10 添加 10 删除 10 查询 返回目录 11 翻页控件 12 树控件的测试外观操作返回目录 12 命令按钮 返回目录 13 一、各种控件在窗体中混和使用时的测试 13 选项卡 返回目录 14 默认焦点 14 TAB顺序 14 快捷键/热键 14 上传文件的测试 14 下载文件的测试 15 【安全性测试】 16 功能测试 v返回目录 16 兼容性测试 17 【性能测试】 17 邮箱输入框字段校验测试 18 验证码输入框字段校验测试 18 替换测试大体相同. 返回目录 19 插入文件 19 链接文件 19 插入对象 19 编辑操作 19 界面测试【UI】 20 窗体 20 标题栏 21 文字 21 控件 21 图片 22 窗口在任务栏上的系统菜单 22 提示对话框测试要点: 23 菜单 23 特殊属性 24 其他 24 新增功能 24 修改功能 24 删除功能 25 查询功能 25 权限检查 26 提示功能检查 26 并发功能 27 导出功能 28 导入功能 28 多币别测试 29 打印功能 29 日志检查 29 导航相关检查 30 返回功能检查 30 重置检查 30 PDF测试 30 发送邮件 31 扫描枪 31 安装测试 31 卸载测试 32 更新 33 键盘操作 33 快捷键支持 34 测试驱动程序设计 34 【易用性测试】 35 导航 功能导航 主要功能的导航是否在明显位置 35 菜单 采用“常用--主要--次要--工具--帮助”的位置排列 35 工具栏 相同或相近功能的工具栏放在一起 36 索引 索引的排列顺序要主次有分 36 按钮 按钮大小基本相近,忌用太长的名称,免得占用过多的界面位置 36 快捷键 常用功能要支持快捷键 36 帮助和支持 获取帮助 操作时要提供及时调用系统帮助的功能 36 通用类 系统业务流程需要易于用户理解 37 错误处理 错误规避 37 错误提示 37 一致性 37 与Windows等标准一致 37 内部操作一致 38 反馈信息 38 工作提示 38 功能提示 38 功能性 38 完备性 38 便捷功能 39 控制 可控性 39 视觉清晰 39 布局 39 资源 39 字体 39 颜色 40 语言 文字达 40 专项测试角度:push测试(推送测试)、交互模式: 40

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值