软件测试 —— 用例设计2(边界值)

  在现实生活中,无论做什么,都会有一个“度”的概念。比如,我们知道在NBA总决赛的时候,很多运动员会特意在刚开始比赛不久就增加身体对抗去试探裁判员本场的尺度怎么样;还有MMA比赛的时候,一些有经验的运动员也会有意去吃对手一拳来试探下对手的力度怎么样。生活中有很多这种现象存在,清晰了这些度才能知道自己该如何做,即便是几岁的小朋友也是深谙此道的。而我们测试在对待系统的时候,更是要非常熟悉这些“度”在哪里。假设上篇文章里一样,如果三角形边长可以为无限大,那么我们去测试这个无限大,姑且不论测试方法,是否有意义呢?系统的存在永远是根据现实的需求出现的,而且很多时候,这个度是需要量化出来的,比如你ATM你单笔取钱的最大额度不能大于银行规定的单笔最大额,而不能超过你自己的存款额,这两个就是单笔取钱的度。

接下来进入正题,聊聊系统的度。就如“等价类”中说的,系统主要组成成分是函数,函数的三个关键是输入,逻辑运算和输出。系统的边界,也就由一些列的函数来构成。所以,边界值分析法是对等价类得到的用例的一个补充和细化。

  • 边界值分析法。

    在等价类取了任意值的基础上,再取最大值(max)、max-1、max+1、最小值(min)、min+1、min-1的用例。而且,我们不单单是需要考虑输入的边界,也需要考虑输出的边界。

  • 常见的边界。

    长度、大小、空间、速度、重量等用数字表示的量

    报表的前两行、最后两行

    分页的前两页、最后两页

    屏幕(边边角角的坐标)

    时间,时间上的边界,除了输入输出,还有一个容易忽略的点。比如今天上线,那今天之前的历史数据,和今天之后的新建的数据一般都经过了测试,而一些昨天计算好了存在数据库中,然后上线了之后再去显示的数据就有可能有问题。举个例子说,输入三边,点击一个按钮显示三角形的周长。实现逻辑是,输入三边之后,将计算的结果保存到周长这个字段中,然后点击按钮显示周长的时候直接读取这个值。新需求改成,显示周长的时候都要乘以0.8。那么昨天输入的三边计算好了之后,今天去查看就可能还是原来逻辑的结果。

    还有一些空间大小,比如上传功能,在文件为0,或者几个G的时候都需要仔细考虑下。

  在实现过程中,定义类型的时候,也需要考虑类型的范围。比如下面这个例子,单独拿出来大家都能马上看出来,这个会出现死循环,但是在一个大的项目过程中,往往不会这么简单。

byte i = 10;

while(i < 300){
	i += 10;
}

  

时间: 2024-10-13 20:14:19

软件测试 —— 用例设计2(边界值)的相关文章

软件测试 —— 用例设计3(其他)

错误推测方法: 一.    方法简介 1.         定义:基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法. 2.         错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 1)        例如, 输入数据和输出数据为0的情况:输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况.可选择这些情况下的例子作为测试用例. 2)        例如,前面例子中成绩报告的程序,采用错误推

《软件测试工程师》 14 用例设计方法-等价类

1. 等价类 # 定义:具有相同属性或方法的事物集合:这个集合中的个体所表现的特征与其他个体完全一致: 对于输入而言,某个个体被接受/拒绝,则个体所在集合中的所有个体都被接受/拒绝. #分类:有效等价类(合理.有意义):无效等价类:两者都是用来测试的:有效等价类要输入成功:无效等价类要输入失败,否则就是缺陷: 有效等价类和无效等价类是一对多的关系:一个有效等价类至少对应一个无效等价类. #划分规则:根据输入值长度划分:根据输入值的类型划分:针对输入值的每个规则划分类,一个规则对个一个或多个有效等

软件测试实战 - 测试用例设计方法

一.测试分析 测试需求来源 开发需求DR:协议标准需求PR:用户需求UR:案例库需求LR:竞争需求CR:继承需求SR: 2. 测试项分析步骤 a. 为分析的测试项编号:b. 注明来源:开发文档/法律条款/案例库编号c. 整合测试项:删除合并重复测试项:大的测试项分解为测试子项:d. 分析测试项之间的关系: 3. 测试分析方法 a. 质量模型分析法:功能测试项.效率测试项.可靠性.易用性.可维护性.可移植性:b. 用户场景分析法:游客.普通用户.VIP用户.管理员用户等,不同角色权限不同,测试点也

基于需求文档(PRD)的功能用例设计

上一篇我讲了在项目运行过程中,用例是需要动态更新的.接下来我将结合实例(移动app)讲解在不同的阶段如何设计用例. 需求文档(PRD)主要讲述app的某个模块有什么功能,每一项功能的页面展示.页面操作有哪些,不同操作之间的关系是什么.基于PRD的用例设计是使用黑盒测试方法,而我平时主要使用了等价类划分.边界值分析法.状态转换测试.场景测试,操作实践时偏好于将模块分成页面展现.页面操作.接口.异常流,在每一个子项里运用黑盒测试方法进行设计. 以移动app的登录为例,大致需求如下图: 一.验证登录弹

用例设计

1.支付用例: 金额框填写校验:只能是数字/小数点两位/金额为空/边界值校验:大于小于等于负数 支付方式:余额(余额不足)/第三方支付:密码填写错误/未安装第三方支付app→跳转或者提示/转账汇款:填写银行卡,信用卡的校验/支付方式空时提交 其他:部分支付/补缴支付/重复支付(避免:未返回前不能再次点击支付loading) 安全:修改支付金额或者支付方式后(charles),后台和第三方的需要校验并且返回/重要的参数传参时需要加密/取消支付/重复支付/支付时订单已取消 网速:限速测试→订单支付状

Java设计模式中的单例设计

/** * 单例设计模式 * 应用场合:只需要一个对象的 * 作用:保证整个应用程序中某个实例有且只有一个 * 类型有:饿汉模式.懒汉模式 * 下面的例子是一个饿汉模式的例子 */ class SingleDemo { // 1.将构造方法私有化,不允许外部直接创建使用 private SingleDemo() {} // 2.创建类的唯一实例,使用private static修饰 private static SingleDemo instance = new SingleDemo(); //

不得不说--自动化测试元素定位与用例设计

关于自动化测试,经常被问到元素的定位 与 如何设计用例. 很多时间我也帮不了你解决实际的问题,只能从个人脚本谈谈如何看待这些问题. 不得不说之元素定位 虽然,本章写了十几篇文章来讲元素的定位与操作,对于碰到的一些常见功能,如何通过技巧来定位它们,但是在实际的自动化脚本开发中,不管是新手还是具有一定经验的老手,我们面临最多的问题仍然是元素的定位问题. 有时间元素定位非常简单,例如,我们只要知道这个元素有的id和name 就可以轻松的来定位到它:有时间元素的定位却非常的令人非常头疼,尽管我们用尽了所

Spring容器-ApplicationContext的单例设计

Spring容器-ApplicationContext的单例设计 每次通过new创建一个ApplicationContext容器,都会执行refresh方法,看源代码了解到这个refresh方法会重新加载配置文件,并且这个创建的容器对象持有一个所有singleton类型bean的map集合,从而实现单例,而且这个map对象的生命周期和容器对象的生命周期是一样的 如果我们每次都通过new一个容器对象,那么每次都要重新加载配置文件,都要重新生成这个singleton bean的集合,这样所谓的单例就

接口测试原理、流程及用例设计

接口测试的原理是模拟客户端向服务器发送报文请求,服务器接收请求报文后对相应的报文做处理并向客户端返回应答,客户端接收应答的一个过程. 接口测试流程: 模拟客户端连接服务器(服务器提供的端口是否可访问) ↓ 客户端发送报文请求 ↓ 服务器端接收请求并做处理 ↓ 检查返回的预期结果并与实际结果对比 ↓ 结束 接口测试用例设计: 接口测试的主要测试对象是接口,但随着系统复杂度越来越高,接口越来越多,完全覆盖所有接口是很难的一件事情,且实际过程中任意内部接口的变动都可能导致我们测试用例的不可用. 所以通