为了回归。而且接口有个好处，定位问题简单，一出问题基本都是服务端的问题，而且肯定是和这个接口相关的代码，不用花时间再去抓包->分析（->撕逼）

第一页、中间页、最后一页，那么如何获取到的页数就是最后一页？让开发协助写获取最后一页的接口，测试来调用。

从reponse中是否包含指定内容开始。

扩展到数据库的校验

ADD/MOD（添加/修改）:

1. 字段边界值，最大最小字符，为空以及格式校验；
2. 重复提交相同的参数；
3. 权限校验；
4. 业务逻辑。

DEL:（删除）

1. 删除不存在的；
2. 删除无权限删除的；
3. 删除后再添加相同的；
4. 重复删除。

LST:（列表）

1. 为空时获取；
2. 数量大时获取；
3. 分页；
4. 获取无权限获取的。

通过测试参数的排列组合验证返回值/数据库变更是否符合预期，从而确定接口相关代码是否正确。

1. 简单（对于开发基础比较好的同学来说）；
2. 稳定（成功率高，很少出现ui自动化的各种状况）；
3. 效率（1个接口下的100条用例几秒可执行完成）；
4. 可信（ui自动化测试报告天天执行，一堆fail，由于各种环境问题、兼容等问题导致排查测试报错的原因较麻烦）；
5. 时间（用例编写时间短，相对来说复用性高）。

1. 开始编写前置条件、入参、返回参数、预期结果等测试相关的信息；
2. 运用工具去执行测试用例或者执行自己写的脚本；
3. 校验返回结果是否正确。

接口测试是功能测试不可或缺的一部分，抛开了前段的逻辑和限制对于服务器的功能进行了完整的测试，一个好的功能测试人员应该充分了解所测系统有多少个接口，接口的核心参数和响应，完成对接口代码的走读，接口有没有白名单，防刷，内部接口和外部接口等。

从接口测发起的测试弥补了界面测试的遗漏点，能将接口测试纳入功能测试的一部分，测试的完整性得到了很大的提高，界面测试起码遗漏了如下的信息：

1. 服务器端接口参数校验
2. 接口是否存在安全漏洞或者逻辑漏洞，实时性，防刷
3. 接口是否存在越权的可能

【第一步：看】

1. 看接口的请求参数构造是否合理；
2. 看所传参数有无敏感参数需要加密传输。比如说用户userid、password等数据如果不使用https进行通信，最好使用加密的方式进行传输，这也是业界通用的标准，并且入库也需是加密的；
3. 看所测服务的代码。第一看对于传入参数的校验部分，第二是看整体逻辑处理部分。举个例子，大家在测试过程中经过会遇到如图五所示，有多个必填或者选填项、输入条件特别多、每个输入条件都需要做校验。有些测试人员会对此类问题用正交的方式一项一项测试，这类效率太慢。个人认为效率最高的方式为对于接口参数的校验，以静态测试为主，review代码的过滤条件，页面控件实际输入测试为辅助。很多的输入界面，其中判空处理是必须的。开发代码中常用的一个判空函数是if（xxx.isempty（））。首先界面类查找是否有控件对象未使用该函数，若未使用肯定存在bug；其次即使使用这个函数也是有bug，该函数并未完全满足需求。这个函数漏掉了输入空格的情况,正确的做法是if（xxx.trimme().isempty（））。那么如果在全工程内，搜索isempty,对比发现bug，最后可以选择一个输入项进行测试，通过后所有输入控间判空测试均告完毕；
4. 看接口的返回体是否返回一些不必要的敏感信息，返回格式是否合理。

【第二步：改】

1. 请求体中参数的常规修改。常规修改就是通用的边界值方法，如极大值、极小值、极长值、null、空。未对这些值做校验的后果可大可小。小的方面仅仅是服务器throw一个统一的错误提示，如网络错误等。中等一点的为前端页面会返回如图六形式的内部错误，这种错误会泄露一些敏感信息。严重的后果可能就是影响现有或者后续业务，使得业务往不可控的方向进行；
2. 与业务强相关的参数修改；
3. 请求消息体中的字段修改。有些人习惯在cookie中传输大量的信息，也是值得关注的测试点。

1. 业务逻辑（业务逻辑覆盖）；
2. 响应结构；
3. 数据格式；
4. 数据正确性（依据来源：查数据库与服务器和接口返回值比较）。

1. 基础配置，如域名，环境配置等，单独文件配置，方便不同环境测试，脚本维护；
2. 明确接口实现什么样的功能，实际需要什么样的功能。是否一致；
3. 接口测试数据太多，用数据驱动模式更有层次，且易维护；
4. 要众多用例中选出冒烟测试用例及可用于性能测试的用例；
5. 先单接口测试，在多接口测试；
6. 测试完成后，需要清理脏数据。

1. 基于配置实现接口测试的自动化，免代码开发；
2. 丰富的断言能力支持，返回值校验，数据库比对校验；
3. 比较好的支持流程控制；
4. 比较完善的结果监听；
5. 和Jenkins易于集成，集成后支持接口性能趋势的查看能力；
6. 非标准协议或者对接方有特殊安全处理的情况可以使用JavaSample的方式处理。

类似于功能测试，需求讨论--评审需求—确定需求—产出接口定义—根据需求文档及接口定义设计测试用例（测试用例主要从业务场景，功能以及异常测试几个方面考虑）—评审用例—执行测试。

个人觉得此在于团队开发的流程，团队之间的沟通和测试人员的警觉性。

在开发阶段，需求的变更是一件极为频繁和正常的事情，对于此点团队中的任何一个人都应该正确的心态来面对，团队需要规范的开发流程，良好的沟通方式，测试人员更需要及时跟进软件进度，和开发人员并进齐行，同时，测试与开发需要相对独立的工作环境，总结而言为知己知彼，亦敌亦友。

通过测试程序模拟客户端向服务器发送请求报文，服务器接收请求报文后对相应的报文做出处理然后再把应答报文发送给客户端，客户端接收应答报文这一过程（request→response）

1. 新增接口的测试；
2. 新增业务功能接口测试；
3. 整个服务器的接口测试，所需测试接口一次增多，在测试时间足够的条件下，当然需要对所有接口进行测试用例的设计，如果测试较短的情况下，则应该首先根据用户的典型操作对测试接口进行优先级划分，对调用平凡接口需要优先进行测试。

1. 接口设计检查（整数型数据位数、浮点型数据精度、字符串数据范围值)
2. 接口依赖关系检查
3. 接口输入/输出验证

• 条件判断接口

条件判断的验证：要对判断条件进行验证，则需要知道接口是根据哪些输入项来进行判断的

异常数据的响应：对于密码重置接口，用户ID不存在、不合法，邮箱输入格式错误、用户邮箱信息不存在或未激活就是测试时需要考虑的异常场景，设计这类输入值，并且检查接口返回的响应码，响应码的正确才能保证客户端根据异常情况来显示相应的提示信息。

• 数据查询接口：

除了像条件判断接口之外根据请求参数设计合法/不合法/正常/异常测试值之外，还需要结合数据库来对查询结果进行验证。

是否根据正确的关联数据表进行查询；

验证查询结果是否从数据表中正确项中获取，涉及到多表联合查询时，不同表中的相同项设计不同测试数据来进行验证；

修改查询结果在数据表中对应项中的数据，使其为空值或客户端相应项的范围值的最大和最小值，查看接口输出是否正确。

• 逻辑运算接口

对接口测试而言，持续集成自动化是核心内容，通过自动化的手段我们才能做到低成本高收益。目前我们已经实现了接口自动化，主要应用于回归阶段，后续还需要加强自动化的程度，包括但不限于下面的内容：

1. 流程方面：在回归阶段加强接口异常场景的覆盖度，并逐步向系统测试，冒烟测试阶段延伸，最终达到全流程自动化；
2. 结果展示：更加丰富的结果展示、趋势分析，质量统计和分析等；
3. 问题定位：报错信息、日志更精准，方便问题复现与定位；
4. 结果校验：加强自动化校验能力，如数据库信息校验；
5. 代码覆盖率：不断尝试由目前的黑盒向白盒下探，提高代码覆盖率；
6. 性能需求：完善性能测试体系，通过自动化的手段监控接口性能指标是否正常。

1. 业务功能覆盖是否完整；
2. 业务规则覆盖是否完整；
3. 参数验证是否达到要求（边界、业务规则）；
4. 接口异常场景覆盖是否完整；
5. 接口覆盖率是否达到要求；
6. 代码覆盖率是否达到要求；
7. 性能指标是否满足要求；
8. 安全指标是否满足要求。