接口测试篇

1. get和post的区别

        1. get 是向服务器发送一条查看类型的请求，请求的参数放在URL里，安全系数低，发送的数据有长度限制，请求可被浏览器缓存，幂等（多次执行不会对服务器产生副作用）
        2. post 是提交数据的请求，请求的参数是放在body里，安全系数高，发送的数据没有长度限制，请求不被浏览器缓存，不幂等（多次执行可能对服务器产生副作用，如创建多个资源）

2. Cookie和Session的区别

        1. Cookie存储在用户的本地浏览器，相对不太安全，大小通常有限制，可以设置一个过期时间或在浏览器关闭后自动删除

        2. Session存储在服务器端，相对安全，大小通常没有严格限制，生命周期由服务器管理（通常在用户打开浏览器窗口时创建，用户关闭浏览器或会话超时时销毁）

3. http和https的区别

        1. http是明文传输，https是加密传输
        2. http是需要CA证书，一般要收费
        3. http端口是80，https端口是443

4. 常见状态码    

• 200 OK：客户端请求成功
• 400 Bad Request：客户端请求有语法错误，不能被服务器所理解
• 401 Unauthorize：请求未经授权
• 403 Forbidden：服务器收到请求，但是拒绝提供服务
• 404 Not Found：请求资源不存在，例如输入了错误的URL
• 500 Internal Server Error：服务器发生了内部错误
• 502 Bad Gateway：服务器网关错误
• 503 Server Unavailable：服务器当前不能处理客户端的请求，一段时间后可能恢复正常

5. 如何区分前端还是后端bug

        1. 样式问题，找前端定位
        2. 非样式问题，使用F12，看Network-->Response，看返回的数据是否是预期数据。若数据没错，则前端问题，若数据有错或获取不到数据，先看请求参数，有可能是前端传参错误，若参数没问题就是后端逻辑错误。

6. 接口规范文档有哪些内容

        1. 请求地址：URL参数
        2. 请求头：headers
        3. 请求方式：get/post/delete/put等
        4. 接口路径
        5. 入参
        6. 返回值

7. 给一个接口，怎么测试？

        1. 拿到接口规范文档，争对文档进行用例设计。
        2. 根据设计好的用例准备测试数据。如果没有API文档，需要抓包来获取发送请求的一些参数和数据。
        3. 对接口测试，分为单接口的和流程性的。
        4. 如果需要对一个接口进行大量数据覆盖，就需要对每个接口进行数据驱动测试，来完全覆盖该接口的功能或异常。
        5. 每个接口测试完毕，如果接口和接口之间存在业务关联，需要处理上下游关系，形成接口串联。
        6. 可以做断言，验证状态码或者返回值是否与预期相同。

8. 接口测试用例设计

1. 接口测试流程

需求研讨--需求评审--场景设计--数据准备--执行

2. 分析接口文档中的元素

接口名称、接口地址、支持格式、请求方式、请求参数（名称、类型、取值范围、是否必填）、返回参数（返回码、返回值信息、返回json串信息）

3. 接口用例设计方法

3.1. 单接口功能 

1. 功能是否正常
2. 功能是否按照接口文档实现
3. 正常场景
4. 异常场景        

3.2. 业务场景功能

接口和接口之间存在业务关联，需要处理上下游关系，比如上一个接口的返回值是下一个接口的入参

3.3. 异常测试

（1）参数异常：参数为空、多、少参数、错误参数

（2）覆盖所有的必选参数，组合可选参数，参数有、无或为null，参数的顺序、个数、类型

（3）参数类型数值大小、输入的数值的范围，参数字串长短，参数包含特殊字符

（4）数据异常：数据为空、长度不一致、错误数据

3.4. 性能

并发数、响应时长等

3.5. 安全性

敏感数据是否加密等

9. 常用的接口测试用例覆盖方法

1. 必需参数覆盖：对于接口的参数，接口文档一般都会说明哪些儿是必需的，哪儿是非必需的。对于必需的参数，一定要测试传参数和不传参数接口是否报错？
2. 必需的参数各种情况覆盖：传非法的字符，特殊的字符，空值，超过边界的参数是否报错？错误信息是否正确？
3. 非必需参数覆盖：一般接口对于非必需参数都不会做非正常性传值的判断，所以要测试合法的参数值 ，接口返回的内容是否正确。如果有接口文档说明对非必需参数做了非正常的验证的话，也要对其进行验证。
4. 参数的组合覆盖：有些儿参数需要相互配合着才起作用，如“offset”和“count”组合起来进行翻页，这个时候要组合起来进行测试。
5. 业务逻辑相关的覆盖：

10. 接口测试的设计思路

（1）是否满足前提条件

有些接口需要满足前置条件，才可成功获取数据。常见的，需要登陆Token。
逆向用例：针对不满足前置条件(假设为n个条件)，设计0~n条用例

（2）是否携带默认值参数

正向用例：带默认值的参数都不填写、不传参，必填参数都填写正确且存在的“常规”值

（3）业务规则、功能需求

根据实际情况，结合接口参数说明，可能需要设计n条正向用例和逆向用例 

（4）参数是否必填

针对每个必填参数，都设计1条参数值为空的逆向用例

（5）参数之间是否存在关联

逆向用例：有些参数彼此之间存在相互制约的关系

（6）参数数据类型限制

逆向用例：针对每个参数都设计1条参数值类型不符的逆向用例

（7）参数数据类型自身的数据范围值限制

正向用例：针对所有参数，设计1条每个参数的参数值在数据范围内为最大值的正向用例
逆向用例：针对每个参数(假设n个)，设计n条每个参数的参数值都超出数据范围最大值的逆向用例
逆向用例：针对每个参数(假设n个)，设计n条每个参数的参数值都小于数据范围最小值的逆向用例

11. 接口测试返回结果的比较

（1）首先比较返回码

（2）然后比较返回值的完整性，key和value

12. 接口测试的接口优先级

（1）针对所有接口

1. 暴露在外面的接口，因为通常该接口会给第三方调用
2. 供系统内部调用的核心功能接口
3. 供系统内部调用非核心功能接口

（2）针对单个接口

1. 正向用例优先测试,逆向用例次之
2. 正向用例优先测试,逆向用例次之

13. 接口测试之断言

（1）断言：postman在发送请求后，需要对返回的结果做判断，验证是否符合预期

（2）断言常用的四种方法：

value是什么格式，校验的字段就得是格式，比如济南必须带双引号；返回结果必须与接口文档一致的测试，body中可以去掉单引号

（3）在Test Result查看结果

14. postman接口之间增加等待时长使用场景

1.接口调试时，响应超时时间设置的太短导致接口调用超时
2.获取当前时间，但是服务器时间响应时间较慢
3.上一个接口未请求完成，下一个接口需要使用上一个接口的参数

方法1：所有项目集合全局添加等待

Menu--File--Settings中设置

        

方法2： 在Pre-request Script中增加设置等待时长

setTimeout(function() {},[number]);

setTimeout(function(){},5000);     增加5s等待时长

15. B/S架构与C/S架构的区别

• b/s架构即 浏览器/服务器架构，使用http协议通讯
• c/s架构即 客户端/服务器架构，使用tcp/ip协议通讯