c语言sscanf函数的用法是什么
452
2023-02-05
本文目录一览:
api的接口模式包括用户接口和程序接口两种接口类型。
用户接口:操作系统专门为用户提供了“用户与操作系统的接口” ,通常称为用户接口。该接口支持用户与 OS 之间进行交互,即由用户向 OS 请求提供特定的服务,而系统则把服务的结果返回给用户。
程序接口:操作系统向编程人员提供了“程序与操作系统的接口” ,简称程序接口,又称应用程序接口 API。 该接口是为程序员在编程时使用的,系统和应用程序通过这个接口,可在执行中访问系统中的资源和取得 OS 的服务。
它也是程序能取得操作系统服务的唯一途径。大多数操作系统的程序接口是由一组系统调用(system call)组成,每一个系统调用都是一个能完成特定功能的子程序。
API(Application Programming Interface,应用程序接口)是一些预先定义的接口(如函数、HTTP接口),或指软件系统不同组成部分衔接的约定。
用来提供应用程序与开发人员基于某软件或硬件得以访问的一组例程,而又无需访问源码,或理解内部工作机制的细节。
基于互联网的应用正变得越来越普及,在这个过程中,有更多的站点将自身的资源开放给开发者来调用。
对外提供的API 调用使得站点之间的内容关联性更强,同时这些开放的平台也为用户、开发者和中小网站带来了更大的价值。
一些刚开始写接口文档的服务端同学,很容易按着代码的思路去编写接口文档,这让客户端同学或者是服务对接方技术人员经常吐槽,看不懂接口文档。这篇文章提供一个常规接口文档的编写方法,给大家参考。
推荐使用的是docway 写接口文档,方便保存和共享,支持导出PDF MARKDOWN,支持团队项目管理。
一、请求参数
1. 请求方法
GET
用于获取数据
POST
用于更新数据,可与PUT互换,语义上PUT支持幂等
PUT
用于新增数据,可与POST互换,语义上PUT支持幂等
DELETE
用于删除数据
其他
其他的请求方法在一般的接口中很少使用。如:PATCH HEAD OPTIONS
2. URL
url表示了接口的请求路径。路径中可以包含参数,称为地址参数,如**/user/{id}**,其中id作为一个参数。
3. HTTP Header
HTTP Header用于此次请求的基础信息,在接口文档中以K-V方式展示,其中Content-Type则是一个非常必要的header,它描述的请求体的数据类型。
常用的content-type:
application/x-www-form-urlencoded
请求参数使用“”符号连接。
application/json
内容为json格式
application/xml
内容为xml格式
multipart/form-data
内容为多个数据组成,有分隔符隔开
4. HTTP Body
描述http body,依赖于body中具体的数据类型。如果body中的数据是对象类型。则需要描述对象中字段的名称、类型、长度、不能为空、默认值、说明。以表格的方式来表达最好。
示例:
二、响应参数
1. 响应 HTTP Body
响应body同请求body一样,需要描述请清除数据的类型。
另外,如果服务会根据不同的http status code 返回不同的数据结构, 也需要针对不同的http status code对内容进行描述。
三、接口说明
说明接口的应用场景,特别的注意点,比如,接口是否幂等、处理是同步方式还是异步方式等。
四、示例
上个示例(重点都用红笔圈出来,记牢了):
五、接口工具
推荐使用的是http://docway.net(以前叫小幺鸡) 写接口文档,方便保存和共享,支持导出PDF MARKDOWN,支持团队项目管理。
Java语言提供了一种强大的注释形式:文档注释。可以将源代码里的文档注释提取成一份系统的API文档。我们在开发中定义类、方法时可以先添加文档注释,然后使用javadoc工具来生成自己的API文档。
文档注释以斜线后紧跟两个星号(/**)开始,以星号后紧跟一个斜线(*/)作为结尾,中间部分全部都是文档注释,会被提取到API文档中。
自行搜索一下javadoc即可,示例如下:
/**
* 类描述
*
* @author 作者
* @version 版本
*/
public class DemoClass {
/**
* 内部属性:name
*/
private String name;
/**
* Setter方法
* @return name
*/
public String getName() {
return name;
}
/**
* Getter方法
* @param name
*/
public void setName(String name) {
this.name = name;
}
}
在日常测试工作中,经常会有api接口的测试,除了正向流程的测试之外,我们经常还需要覆盖一些异常情况。
例如:
事实上,我们组的接口测试demo框架中,在dataprovider中也经常能够看到诸如下面的例子。
此处是看看接口在传入非期望值的时候,能不能够很好的处理类似请求。
除此以外,还有一些和业务场景强相关的值类型,比如网络测试的时候,我们会关心cidr的格式;计费测试的时候,又特别关注数字的类型。
一方面,给每个接口增加类似的异常接口测试相对比较无趣;另一方面,我们作为人,考虑问题,不管是开发还是测试,都难免挂一漏万,有一些边边角角的case没能考虑到。
既然如此,我们能否统一抽象出来一种接口异常测试的框架, 自动 注入各种类型的异常,然后将凡是服务没有捕获的,抛出trace, exception 的,记录下请求的payload,为后续验证覆盖提供支撑。
主要使用了模糊测试技术(fuzz testing, fuzzing)。其核心思想是自动或半自动的生成随机数据输入到一个程序中,并监视程序异常,如崩溃,断言(assertion)失败,以发现可能的程序错误,比如内存泄漏。(摘抄之维基百科)
简单的模糊测试随机输入数据,而更加高效的模糊测试,需要理解对象结构或者协议。通过向数据内容,结构,消息,序列中引入一些异常,来人为的构造聪明的模糊测试。
如果你持续关注文件系统或内核技术,你一定注意过这样一篇文章:Fuzzing filesystem with AFL。Vegard Nossum 和 Quentin Casasnovas 在 2016 年将用户态的 Fuzzing 工具 AFL(American Fuzzing Lop)迁移到内核态,并针对文件系统进行了测试。
结果是相当惊人的。Btrfs,作为 SLES(SUSE Linux Enterprise Server)的默认文件系统,仅在测试中坚持了 5 秒钟就挂了。而 ext4 坚持时间最长,但也仅有 2 个小时而已。( https://zhuanlan.zhihu.com/p/28828826 )
所以基于此,在api接口测试中引入模糊测试理论上也是可行的,而且是有效的。
经过一番调研和搜索之后,发现了以下这个项目在接口fuzz测试中,有比较好的上手体验。
我对 PyJFAPI 稍微进行了一些修改,包括日志记录,以及异常判断的地方,只记录服务器返回500错误的情况等。
首先需要准本一个请求的模板。
这里是一个 post请求,定义了一些请求头和请求体。星号之间的请求json体,为异常注入点。
它会自动分析你的json格式,生成各种 payload。理论上来说,你只需要给它提供一份接口的scheme就行(要是所有接口都可以从Swagger直接导出那就很方便了)。
运行:
返回
我们可以手工请求一下这些导致异常的payload。
实例1:
事实上,我们本来已经对这个cidr参数进行了一些异常值的测试。包括:
等等。可以发现,还是有部分特殊情形没有考虑到。
实例2
我把程序构造的部分异常打印出来,可以看到类型还是很丰富的。
pjfapi.py 脚本本身使用方法很简单。 -h 看下help为命令行参数的基本说明。
本文简要的介绍了fuzz测试技术,以及将其应用到api接口测试中的实现,给出了一个具体的fuzz接口测试例子。它不一定能够完全替代掉人工的接口异常,但是可以作为一个很好的补充。
版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。
发表评论
暂时没有评论,来抢沙发吧~