#5.7 -- 通用接口用例设计

1)通过性验证:接口的冒烟测试,按照接口文档上的参数,正常传入,是否可以返回正确的结果。

2)参数组合:现在有一个操作商品的接口,有个字段type,传1的时候代表修改商品,商品id、商品名称、价格有一个是必传的,type传2的时候是删除商品,商品id是必传的,这样的,就要测参数组合了,type传1的时候,只传商品名称能不能修改成功,id、名称、价格都传的时候能不能修改成功。

3)接口安全:

1、绕过验证,比如说购买了一个商品,它的价格是300元,那我在提交订单时候,我把这个商品的价格改成3元,后端有没有做验证,更狠点,我把钱改成-3,是不是我的余额还要增加?

2、绕过身份授权,比如说修改商品信息接口,那必须得是卖家才能修改,那我传一个普通用户,能不能修改成功,我传一个其他的卖家能不能修改成功

3、参数是否加密,比如说我登陆的接口,用户名和密码是不是加密,如果不加密的话,别人拦截到你的请求,就能获取到你的信息了,加密规则是否容易破解。

4、密码安全规则,密码的复杂程度校验

4)异常验证:

异常的,也就是我不按照你接口文档上的要求输入参数,来验证接口对异常情况的校验。比如必填的参数不填,输入整数类型的,传入字符串类型,长度是10的,传11,总之就是你说怎么来,我就不怎么来,其实也就这三种,必传非必传、参数类型、入参长度

5)根据业务逻辑来设计用例:

根据业务逻辑来设计的话,就是根据自己系统的业务来设计用例,这个每个公司的业务不一样,就得具体的看自己公司的业务了,其实这也和功能测试设计用例是一样的。

举个例子,拿bbs来说,bbs的需求是这样的:

1、登录失败5次,就需要等待15分钟之后再登录

2、新注册的用户需要过了实习期才能发帖

3、删除帖子扣除积分

4、......

像这样的就要把这些测试点列出来,然后再去造数据测试对应的测试点。

时间: 2024-12-23 06:41:40

#5.7 -- 通用接口用例设计的相关文章

接口用例设计

1.通过性测试(正向用例) 保证这个接口功能是好的,正常传入,是否可以返回正确结果 2.参数组合 多个参数的时候 3.接口安全 1.绕过验证,比如说购买了一个商品,它的价格是300元,那我在提交订单时候,我把这个商品的价格改成3元,后端有没有做验证,更狠点,我把钱改成-3,是不是我的余额还要增加? 2.绕过身份授权,比如说修改商品信息接口,那必须得是卖家才能修改,那我传一个普通用户,能不能修改成功,我传一个其他的卖家能不能修改成功 3.参数是否加密,比如说我登陆的接口,用户名和密码是不是加密,如

接口测试概述:概念、目的、流程、工具、技能以及接口用例设计

一.什么是接口测试 二.接口测试流程 三.接口测试目的 四.接口测试用例设计 五.接口测试内容 六.接口测试工具 七.接口测试需要掌握的知识

python基础--接口与归一化设计、封装、异常、网络编程

1 接口与归一化设计 1.1 归一化概念: 归一化的好处: 1.归一化让使用者无需关心对象的类是什么,只需要知道这些对象都具备某些功能就可以了,这极大降低了使用者的使用难度. 2.归一化使得高层的外部使用者可以不加区分的处理所有接口兼容的对象集合 继承的两种用途 一:继承基类的方法,并且做出自己改变或者扩展(代码重用):实践中,继承的这种用途意义并不很大,甚至常常是有害的.因为它使得子类与基类出现强耦合. 二:声明某个子类兼容于某基类,定义一个接口类(模仿java的Interface),接口类中

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

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

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

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

《Effective Objective-C 2.0》—(第15-22条)—接口与API设计、深拷贝、浅拷贝

第15条:用前缀避免命名空间冲突 Objective-C没有其他语言内置的命名空间(namespace)机制.如果发生命名冲突程序连接时候,出现以下错误: duplicate symbol _OBJC_METACLASS_$_EOCTheClass in: build/something.o build/something_else.o duplicate symbol _OBJC_CLASS_$_EOCTheClass in: build/something.o build/something

基于技术方案的用例设计

上一篇介绍了基于需求文档的用例设计,主要是运用了黑盒测试的用例设计方法.之前提到用例在整个项目过程中是动态更新,逐步完善的,经过了需求评审的用例编写后,项目会进行技术方案评审,评审结束后,需要基于技术方案对用例进行一次补充完善. 我仍然以登录为例,由于每个开发设计的方案不同,在此列一个大致的通用方案,基于该方案做用例设计,精髓会了,其他的融会贯通. 登录成功的时序图如下: 登录失败的时序图如下: 分析时序图,步骤比较清晰,客户端的主要工作分为几部分: 1.绘制登录界面(UILabel.UIBut

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

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

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

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