Day2-测试设计

今天目标

  • 1.能对穷举场景设计测试点
    • 等价类划分法
  • 2.能对限定边界规则设计测试点
    • 边界值分析法
  • 3.能对多条件依赖关系进行设计测试点
    • 判定表法
  • 4.能对项目业务进行设计测试点
    • 场景法

一、解决穷举场景

1.1 等价类划分

image.png

重点:有效等价和单个无效等价各取一个即可
步骤:
    1.明确需求
    2.划分有效等价和无效等价
    3.设计数据编写用例

1.2 案例(城市电话验证)

城市电话:       
	1.区号:空或者三位数字        
	2.前缀码:非0且非1开头的三位数字
	3.后缀码:四位数字 

①明确需求
image-20220308222514923

②划分有效等价和无效等价
image-20220308222832487

③设计数据编写用例
image-20220308222858493

重点:
   1、正向用例:一条尽可能覆盖多条
   2、逆向用例:每一条数据,都是一条单独用例

1.3 总结(应用场景)

针对:需要有大量数据测试输入,但是没法穷举测试的地方。
	输入框
	下拉列表
	单选复选框
典型代表:页面的输入框类测试。

友情提示:完整的用例应该是等价类和边界值一块写。

二、解决边界限制问题

说明:使用边界值解决边界位数限制问题。

2.1 边界值说明

边界范围节点

  • 选取正好等于、刚好大于、刚好小于边界的值作为测试数据
    • 上点:边界上的点(正好等于) - 绿色
    • 离点:距离上点最近的点(刚好大于、刚好小于) - 黄色
    • 内点:范围内的点(区间范围内的数据)- 蓝色

image-20220308224837265

提示:
	1、有关范围限制,最多7条用例(暂时未优化)
	2、边界值能解决位数限制问题,但是不能解决类型问题(要结合等价类)

2.2 边界值法设计用例步骤

1、明确需求
2、确定有效和无效等价类
3、确定边界范围值
4、提取数据编写测试用例

2.3 案例1(电话号码)

1、明确需求

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

2、确定有效等价和无效等价(类型)

image-20220309150107659

3、确定数据边界

image-20220309150126605

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

image-20220309150149278

2.4 案例2(QQ号码)

1、明确需求

需求1:通过边界值法验证QQ号码的合法性		
需求2:6~10位自然数		                                

2、确定有效等价和无效等价(类型)

image-20220309152213977

3、确定数据边界

image-20220309152221669

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

image-20220309152230740

2.5 案例优化(开内闭外)

  • 结论:7个优化为5个点

  • 上点:必选(不考虑区间开闭)

  • 内点:必选(建议选择中间范围)

  • 离点:开内闭外(考虑开闭区间,开区间选择内部离点,闭区间选择外部离点)

    10<a<=20  -→  使用开闭区间表达:(10,20]
    开区间:不包含
    闭区间:包含
    
    开区间指的是区间边界的两个值不包括在内;(a,b)
    闭区间指的是区间边界的两个值包括在内。[a,b]
    半开半闭区问:开区间一边的边界值不包括在内而区间边的边界值包括在内。[a,b)、(a,b]
    

image-20220309152933346

  • 案例2优化

2.6 总结

强调:单个输入框,常用的方式 边界+等价类

面试题:最常用的用例设计方法有哪些? --等价类、边界值

在等价类的基础上针对有边界范围的测试数据输入的地方(重点关注边界)
常见词语描述:大小、尺寸、重量、最大、最小、至多、至少等修饰词语
典型代表:有边界范围的输入框类测试

三、解决多条件依赖关系问题

重点:使用判定表

3.1 判定表法的引用

  • 案例:验证“若用户欠费或者关机,则不允许主被叫”功能的测试
  • 说明:
    • 等价类边界值分析法主要关注单个输入类条件的测试
    • 并未考虑输入条件之间的各种组合、输入条件与输出结果之间有相互制约关系的测试。

3.2 判定表定义及组成部分

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

  • 组成:

    • 条件桩:列出问题中的所有条件,列出条件的次序无关紧要。

    • 动作桩:列出问题中可能采取的操作,操作的排列顺序没有约束。

    • 条件项:列出条件对应的取值,所有可能情况下的真假值。

    • 动作项:列出条件项的、各种取值情况下应该采取的动作结果。
      image-20220309154608223

  • 规则:

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

3.3 判定表设计用例步骤

1、明确需求
2、画出判定表
     1)列出条件桩和动作桩
     2)填写条件项,对条件进行全组合
     3)根据条件项的组合确定动作项
     4)简化、合并相似规则(有相同的动作)
3、根据规则编写测试用例

3.4 案例(订单)

1、明确需求

image-20220309162145446

2、画判定表

image-20220309162153321

3、提取数据编写用例

image-20220309162200668

3.5 案例(文件修改)

1、明确需求

规则1	输入第一列字符必须是A或B	
规则2	第二列字符必须是一个数字	
规则3	如果第一列字符不正确,则给出信息L	
规则4	如果第二列字符不正确,则给出信息M	
规则5	如果两列字符输入正确,则修改文件成功	

2、画判定表

image-20220309164451560

3、提取数据编写用例

image-20220309164512479

3.6 使用场景

  • 有多个输入条件,多个输出结果,输入条件之间有组合关系,输入条件和输出结果之间有依赖(制约)关系
  • 判定表一般适用于条件组合数量较少的情况(比如4个条件之下)
    • 大多数案例不会超过4个条件,如果超过,可能是业务设计出现问题
    • 4个条件以上可以使用正交测试法
提示:
	1、多条件之间有依赖关系,使用判定表来进行测试覆盖
	2、判定表一般适合4个以内条件依赖关系
	3、如果条件超过4个,就不适合覆盖所有条件,应采用正交测试法来解决

四、业务测试覆盖

重点:

​ 1、覆盖业务测试,需要使用流程图法

​ 2、先测试业务,再测试单功能、单模块、单页面

4.1 流程图

提示:业务用例是根据流程图来梳理的,需要先了解流程图

  • 使用标准图形和箭头来表达程序或业务的走向

    image-20220309170043950

  • 流程图对测试人员有什么作用?

    1、能够看懂流程图,设计业务用例

    2、当需求文档信息不全时,能根据需求,梳理出流程

  • 网页版工具:https://processon.com

  • Windows工具:visio

  • 其他工具:Excel

4.2 场景法

  • 说明:
    • 场景法也可叫流程图法,是用流程图描述用户的使用场景,然后通过覆盖流程路径来设计测试用例
  • 意义
    • 用户使用角度:用户平时使用的不是单个功能,而是多个功能组合起来进行使用
    • 测试人员角度:平时测试的都是单个功能点进行测试,容易忽略多个功能的组合测试
  • 适用场景
    • 根据实际的应用场景,来测试业务用例,可以使用场景法

4.3 案例(ATM)

  • 流程图

image-20220309180415339

1、开始 ->验证银行卡不成功->结束					
2、开始->验证银行卡成功->密码错误三次->结束					
3、开始->验证银行卡成功->密码成功->账户余额不足->结束					
4、开始->验证银行卡成功->密码成功->账户余额验证成功->取款金额不正确->结束					
5、开始->验证银行卡成功->密码成功->账户余额验证成功->取款金额正确->ATM机余额不足->结束					
6、开始->验证银行卡成功->密码成功->账户余额验证成功->取款金额正确->ATM机余额充足->取款成功->结束					
  • 用例

image-20220309180518013

4.4错误推荐法

应用场景:当项目用例都执行完毕,且BUG修复完成,离上线还有一段时间,在这段时间中可是使用错误推荐法复测主要业务或测试未覆盖的功能。

image-20220309185849613

posted @ 2022-03-09 14:34  cloudguest  阅读(62)  评论(1编辑  收藏  举报