一、前言

这篇文章呢主要是想讲实战方面的内容，本文主要会讲解接口测试中的一些接口概念，流程等方面的问答，同时还会介绍一下即将要进行测试的项目，这里呢我就不多说废话了，直接进入主题吧。

二、接口概念

接口测试：接口测试是测试系统组件间接口的一种测试，主要用于测试系统与外部其他系统之间的接口，以及系统内部各个子模块之间的接口。 – 百度百科

接口原理：模拟客户端向服务器发送请求报文，服务器接收请求报文后对相应的报文做判断并将最终结果返回至客户端，客户端再次接收返回结果并应答的过程。

检查重点：测试的重点是检查接口参数传递、接口功能实现、输出结果的正确性，以及对各类异常情况容错处理的完整性与合理性。

接口类型：内部接口及外部接口，内部接口为程序开发的接口，方法之间或模块之间的调用，外部接口为外部接入调用接口，例如王者荣耀的微信登录、支付宝的支付功能等，均是外部接口。

接口分类：webservice接口及http api接口，webService接口使用soap协议传输，通过http进行传输，是HTTP POST专用版本之一，遵循一种特殊的xml消息格式（请求及返回均为xml），http api接口使用http协议，通过路径来区分调用的方法，通过key-value请求，返回报文通常为json。

接口本质：接口的本质上是一个公开的函数类，进行数据传输的发送与接收，可以理解成一条通道，在发送get或post请求方式时，实际上就是从通道进行发送、在由服务器从通道返回数据。

测试范围：接口功能、接口性能、接口稳定性以及接口安全性等。

三、项目简介

该项目是一个Web管理后台，有基础信息、用户操作、邮件管理、订单管理等多个模块，在项目实战中，尽可能以最简单、最高效的方式讲解到最深层次的内容，让大家能够充分理解该项目，以及如何使用实战所讲解的内容应用到自己公司或是私人项目当中。

该项目拥有一份详细的接口文档，文档中包括对应的请求头、请求体、请求方式、请求参数、成功示例反馈等内容，包括全后台的所有模块，均拥有对应详细的接口信息，在实践过程中，笔者会根据具体情况截图、梳理、汇总，如下只展示其中一个接口作为示例

四、自动化测试流程讲解

4.1 全自动化测试流程

我们搭建框架很显然是为了进行自动化测试的，包括但不限于接口自动化、Web自动化、App自动化，UI自动化测试等等方式，有一部分和功能测试会比较相似，各个公司上可能也会存在差异，但大体不变，现在来介绍下自动化测试的流程：

"""

第一步：需求评审 -- 自动化测试同功能测试，第一步都需要进行需求评审，评审期间熟悉需求，找到需求缺陷，以此为需求分析做好铺垫
第二步：需求分析 -- 需求分析阶段主要是自动化测试人员单独对需求进行分析，进行需求拆解，详细理解需求，为测试用例的设计做好铺垫
第三步：接口文档 -- 熟悉需求后知道大概要负责的内容，在接口自动化测试阶段就需要了解接口文档，有哪些参数，请求头、请求体、请求方式、请求参数等
                如果公司没有接口文档，通常去找开发询问，让开发给一份文档，如果还是无果，需要自己通过抓包的方式获取接口并梳理成文档
第四步：测试计划 -- 大致梳理你个人的测试计划，用例设计需要的时间，什么时候设计，预计什么时候能够测试通过，哪个环节是否采用自动化技术
                考虑测试的优先级等，如果你是对应的测试负责，还需要考虑任务的人力分配等问题
第五步：计划评审 -- 当你梳理出一个计划后，还要与小组成员进行确认讨论，查看计划是否存在文档，是否有可改进的地方，关于小组成员是否对此有一些疑问
第六步：测试用例 -- 熟悉需求和接口文档后且拥有了测试计划，那么就到了测试用例的设计环节，设计接口自动化的测试用例
第七步：用例评审 -- 接口测试用例设计完成后进入用例评审阶段，确认测试用例中是否有遗漏，是否不规范，是否便于自动化的读取、使用等
第八步：用例执行 -- 通过接口自动化测试用例来进行代码的编写及梳理，在此期间可以搭建测试框架或在此之前已经拥有了一个框架执行即可
第九步：测试报告 -- 当执行完成测试用例后，即可输出对应的测试报告结论，同业务，包括质量情况、问题分布，
第十步：集成部署 -- 当测试框架搭建完成后并且能够顺利的执行测试用例，产出对应的测试报告时，考虑进行集成部署，通过定时任务，按周或按月冒烟执行

"""

4.2 测试金字塔

测试金字塔主要分为三个阶段，最底层是单元测试/组件测试，也就是代码相关的检查测试，但因国内敏捷开发以及测试能力的限制，故此在大多数的公司测试并不会进行单元测试，往往在此阶段是由开发进行自测完成。

金字塔的中间层是API方面的测试，也就是接口相关的测试，接口测试没有单元测试更加专业，但可以发现手工测试中无法发现的异常和问题。

最上层是用户界面上的测试，也可以理解为手工测试，手工测试仅能发现一些表层次问题，但大多数的需求仅通过表层的功能测试也能够防止绝大多数问题的产生，也是非常重要的一环，越靠近上层的测试，越能够接近业务层面的内容，也能够明显的反映出真实的需求。

不仅如此，越靠近金字塔的底端测试方式效率更高、缺陷更容易被定位、测试成本更低，而越靠近金字塔的顶端，则修复效率越慢，成本更高且缺陷更不容易被定位，这也是为什么测试需要尽早介入的原因。

4.3 什么样的项目适合进行自动化测试？

我们知道自动化测试能够提升工作效率，虽说如此，但什么情况下都适合做自动化吗？显然并不是的，只有符合下列条件的情况下，笔者认为更适合做自动化测试：

"""
符合下列条件，更适合做自动化测试工作：
1、需求文档，不会频繁变更需求 -- 在不变更需求的情况下，功能模块相对稳定，脚本编写后无需花费大量的时间修改及维护
2、研发和测试周期长，需要频繁进行回归测试、冒烟测试 -- 例如每周的模块进行冒烟测试，频繁的出现某一个运营活动
3、需要在多种平台上重复运行多个测试场景
4、某些测试项目的测试内容通过功能测试无法实现，或功能测试非常耗时
5、被测系统的开发较为规范，能够保证系统的可行性
"""