接口和协议

接口和协议

软件开发的两种结构

C/S（Client/Server）：客户端----服务器结构

CS的优缺点

能充分发挥客户端PC的处理能力，很多工作可以在客户端处理后再提交给服务器，所以CS客户端响应速度快。
操作界面漂亮、形式多样，可以充分满足客户自身的个性化要求。 C/S结构的管理信息系统具有较强的事务处理能力，能实现复杂的业务流程。
安全性能可以很容易保证，C/S一般面向相对固定的用户群，程序更加注重流程，它可以对权限进行多层次校验，提供了更安全的存取模式，对信息安全的控制能力很强。一般高度机密的信息系统采用C/S结构适宜。
需要专门的客户端安装程序，分布功能弱，针对点多面广且不具备网络条件的用户群体，不能够实现快速部署安装和配置。
兼容性差，对于不同的开发工具，具有较大的局限性。若采用不同工具，需要重新改写程序。
开发、维护成本较高，需要具有一定专业水准的技术人员才能完成，发生一次升级，则所有客户端的程序都需要改变。。
用户群固定。由于程序需要安装才可使用，因此不适合面向一些不可知的用户

B/S（Browser/Server）：浏览器----服务器结构

BS的优缺点
优点：

●分布性强，客户端零维护。只要有网络、浏览器，可以随时随地进行查询、浏览等业务处理。
　　●业务扩展简单方便，通过增加网页即可增加服务器功能。 　　●维护简单方便，只需要改变网页，即可实现所有用户的同步更新。
　　●开发简单，共享性强。

缺点：

个性化特点明显降低，无法实现具有个性化的功能要求。 　　
　　●在跨浏览器上，BS架构不尽如人意。
　　●客户端服务器端的交互是请求-响应模式，通常动态刷新页面，响应速度明显降低（Ajax可以一定程度上解决这个问题）。
　　●在速度和安全性上需要花费巨大的设计成本。
　　●功能弱化，难以实现传统模式下的特殊功能要求。

BS与CS优缺点对比

CS响应速度快，安全性强，用户体验好，一般应用于局域网中，但是开发维护成本高；BS可以实现跨平台，客户端零维护，但是个性化能力低，响应速度较慢。所以有些单位日常办公应用BS，在实际生产中使用CS结构。

Http协议

HTTP协议是Hyper Text Transfer Protocol（超文本传输协议）的缩写,是用于从万维网（WWW:World Wide
Web ）服务器传输超文本到本地浏览器的传送协议。

HTTP1.0和HTTP1.1的区别

一个WEB站点每天可能要接收到上百万的用户请求，为了提高系统的效率，HTTP1.0规定浏览器与服务器只保持短暂的连接，浏览器的每次请求都需要与服务器建立一个TCP连接，服务器完成请求处理后立即断开TCP连接，服务器不跟踪每个客户也不记录过去的请求。
HTTP 1.1支持持久连接，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟

http请求

客户端连上服务器后，向服务器请求某个web资源，称之为客户端向服务器发送了一个HTTP请求。

http请求方式

请求方式： HTTP1.0定义了三种请求方法： GET, POST 和 HEAD方法。 HTTP1.1新增了五种请求方法：OPTIONS,
PUT, DELETE, TRACE 和 CONNECT 方法。 GET 请求指定的页面信息，并返回实体主体。 HEAD
类似于get请求，只不过返回的响应中没有具体的内容，用于获取报头 POST
向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST请求可能会导致新的资源的建立和/或已有资源的修改。
PUT 从客户端向服务器传送的数据取代指定的文档的内容。 DELETE 请求服务器删除指定的页面。 CONNECT
HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。 OPTIONS 允许客户端查看服务器的性能。 TRACE
回显服务器收到的请求，主要用于测试或诊断。

Get与post请求的区别

1、GET将参数放在URL中。而POST将数据放在BODY中。 　　
　　2、GET的URL会有长度上的限制，而POST的数据则可以非常大。
　　3、POST相比GET更安全，因为数据在地址栏上不可见。 　　
　　4、一般get请求用来获取数据，post请求用来发送数据。

http请求—消息头Request

客户端发送一个HTTP请求到服务器的请求消息包括以下格式：
请求行（requestline）、请求头部（header）、空行和请求数据四个部分组成。
请求行以一个方法符号开头，以空格分开，后面跟着请求的URI和协议的版本。

第一部分：请求行，第一行明了是post请求，以及http1.1版本。
第二部分：请求头部，第二行至第六行。
第三部分：空行，第七行的空行。
第四部分：请求数据，第八行。

http响应

2.8. http响应 服务器接收并处理客户端发过来的请求后会返回一个HTTP的响应消息 HTTP响应也由四个部分组成，分别是：
状态行、消息报头、空行和响应正文。

第一部分：状态行，由HTTP协议版本号， 状态码， 状态消息 三部分组成。
第一行为状态行，（HTTP/1.1）表明HTTP版本为1.1版本，状态码为200，状态消息为（ok）
第二部分：消息报头，用来说明客户端要使用的一些附加信息 第二行和第三行为消息报头，
Date:生成响应的日期和时间；Content-Type:指定了MIME类型的HTML(text/html),编码类型是UTF-8
第三部分：空行，消息报头后面的空行是必须的 第四部分：响应正文，服务器返回给客户端的文本信息。 空行后面的html部分为响应正文。

http响应—常见响应头

Location: http://www.it315.org/index.jsp -表示重定向的地址，该头和302的状态码一起使用
Server:apache tomcat —表示服务器的类型 Content-Encoding:
gzip – 表示服务器发送给浏览器的数据压缩类型 Content-Length: 80
–表示服务器发送给浏览器的数据长度 Content-Language: zh-cn --表示服务器支持的语言 Content-Type: text/html; charset=GB2312 --表示服务器发送给浏览器的数据类型及内容编码
Last-Modified: Tue, 11 Jul 2000 18:23:51 GMT --表示服务器资源的最后修改时间 Refresh:
1;url=http://www.it315.org --表示定时刷新 Content-Disposition:
attachment; filename=aaa.zip --表示告诉浏览器以下载方式打开资源（下载文件时用到）
Transfer-Encoding: chunked Set-Cookie:SS=Q0=5Lb_nQ; path=/search
–表示服务器发送给浏览器的cookie信息（会话管理用到） Expires: -1 --表示通知浏览器不进行缓存 Cache-Control: no-cache Pragma: no-cache Connection: close/Keep-Alive --表示服务器和浏览器的连接状态。close：关闭连接 keep-alive:保存连接

HTTP之状态码

状态代码有三位数字组成，第一个数字定义了响应的类别，共分五种类别: 1xx：指示信息–表示请求已接收，继续处理
2xx：成功–表示请求已被成功接收、理解、接受 3xx：重定向–要完成请求必须进行更进一步的操作
4xx：客户端错误–请求有语法错误或请求无法实现 5xx：服务器端错误–服务器未能实现合法的请求

常见状态码：

200 OK //客户端请求成功 400 Bad Request
//客户端请求有语法错误，不能被服务器所理解 401 Unauthorized
//请求未经授权，这个状态代码必须和WWW-Authenticate报头域一起使用 403 Forbidden
//服务器收到请求，但是拒绝提供服务 404 Not Found
//请求资源不存在，eg：输入了错误的URL 500 Internal Server Error //服务器发生不可预期的错误
503 Server Unavailable //服务器当前不能处理客户端的请求，一段时间后可能恢复正常

保存会话的两种技术

Cookie

其实Cookie就是一个键和一个值构成的，随着服务器端的响应发送给客户端浏览器。然后客户端浏览器会把Cookie保存起来，当下一次再访问服务器时把Cookie再发送给服务器。
Cookie是由服务器创建，然后通过响应发送给客户端的一个键值对。客户端会保存Cookie，并会标注出Cookie的来源（哪个服务器的Cookie）。当客户端向服务器发出请求时会把所有这个服务器Cookie包含在请求中发送给服务器，这样服务器就可以识别客户端了！

Session

在WEB开发中，服务器可以为每个用户浏览器创建一个会话对象（session对象）

Session和Cookie的主要区别在于：

Cookie是把数据保存在浏览器端的内存中 Session把数据保存在服务器端的内存中 cookie与session的联系：
当服务器端生成一个session时就会向客户端发送一个cookie保存在客户端，这个cookie保存的是session的sessionId。。这样才能保证客户端发起请求后客户端已经登录的用户能够与服务器端成千上万的session中准确匹配到已经保存了该用户信息的session，同时也能够确保不同页面之间传值时的正确匹配。

接口测试

API接口是Application Programming
Interface的简称，是一些预先定义的函数，包括接口地址、传入参数和返回参数。

、
接口的分类：

1.webservice接口 2.http api接口 webService接口是走soap协议通过http传输，请求报文和返回报文都是xml格式的，我们在测试的时候都用通过工具才能进行调用，测试。
http
api接口是走http协议，通过路径来区分调用的方法，请求报文都是key-value形式的，返回报文一般都是json串，有get和post等方法，这也是最常用的两种请求方式。

接口测试的重要性

1.越底层发现bug，它的修复成本是越低的。
2.前端随便变，接口测好了，后端不用变，前后端是两拨人开发的。
3.检查系统的安全性、稳定性，前端传参不可信，比如京东购物，前端价格不可能传入-1元，但是通过接口可以传入-1元。
4.如今的系统复杂度不断上升，传统的测试方法成本急剧增加且测试效率大幅下降，接口测试可以提供这种情况下的解决方案。
5. 接口测试相对容易实现自动化持续集成，且相对UI自动化也比较稳定，可以减少人工回归测试人力成本与时间，缩短测试周期，支持后端快速发版需求。接口持续集成是为什么能低成本高收益的根源。
6. 现在很多系统前后端架构是分离的，从安全层面来说： (1)、只依赖前端进行限制已经完全不能满足系统的安全要求（绕过前面实在太容易）， 需要后端同样进行控制，在这种情况下就需要从接口层面进行验证。
(2)、前后端传输、日志打印等信息是否加密传输也是需要验证的，特别是涉及到用户的隐私信息，如身份证，银行卡等。

接口测试用例编写

接口测试用例编写要点

测试每个参数类型不合法的情况 测试每个参数取值范围不合法的情况 测试参数为空的情况 测试参数前后台定义的一致性
测试每个参数的上下限（这里容易出致命的BUG，如果程序处理不当，可能导致崩溃）
测试每个参数取值不合理的情况（包括取的值不属于自己，取值在这阶段不会出现，取值超出了自己所拥有的数量或者范围）
如果两个请求有严格的先后顺序，需要测试调转顺序的情况 自己和自己的交易、聊天等操作（这种特别容易遗漏）
1）、通用接口用例设计
　　①、通过性验证：首先肯定要保证这个接口功能是好使的，也就是正常的通过性测试，按照接口文档上的参数，正常传入，是否可以返回正确的结果。
　　②、参数组合：现在有一个操作商品的接口，有个字段type，传1的时候代表修改商品，商品id、商品名称、价格有一个是必传的，type传2的时候是删除商品，商品id是必传的，这样就要测参数组合了，type传1的时候，只传商品名称能不能修改成功，id、名称、价格都传的时候能不能修改成功。
　　③、接口安全：
　　1、绕过验证，比如说购买了一个商品，它的价格是300元，那我在提交订单时候，我把这个商品的价格改成3元，后端有没有做验证，更狠点，我把钱改成-3，是不是我的余额还要增加？
　　2、绕过身份授权，比如说修改商品信息接口，那必须得是卖家才能修改，那我传一个普通用户，能不能修改成功，我传一个其他的卖家能不能修改成功
　　3、参数是否加密，比如说我登陆的接口，用户名和密码是不是加密，如果不加密的话，别人拦截到你的请求，就能获取到你的信息了，加密规则是否容易破解。
　　4、密码安全规则，密码的复杂程度校验
　　④、异常验证：
　　所谓异常验证，也就是我不按照你接口文档上的要求输入参数，来验证接口对异常情况的校验。比如说必填的参数不填，输入整数类型的，传入字符串类型，长度是10的，传11，总之就是你说怎么来，我就不怎么来，其实也就这三种，必传非必传、参数类型、入参长度。
　　2）、根据业务逻辑来设计用例
　　根据业务逻辑来设计的话，就是根据自己系统的业务来设计用例，这个每个公司的业务不一样，就得具体的看自己公司的业务了，其实这也和功能测试设计用例是　　一样的。

接口文档

我们做接口测试，需要开发提供接口文档。最重要的有一下几点：
1.被测接口的地址
2. 接口参数，以及各个参数的说明
3. 必要的http头与http体 ( http头是可以自定义的，可以用来校验是否是自己人访问 )
4. 接口返回什么值，以及各个返回值的说明
5. 接口是干什么的

接口测试json