接口自动化测试设计！

一、接口测试基础

1.什么是接口测试？

接口测试是测试系统组件间接口的一种测试。
接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。
接口测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等。
从接口形式来看各种应用程序的API(最著名的Windows系统API)，硬件的驱动程序，数据库DAO层接口，及WebService 接口和Http Rest接口。
接口测试通常包括两类，底层模块之间的接口测试和上层服务接口测试。前者通常由开发工程师做单测覆盖，后者则通常由测试工程师测试保证。

2.接口测试原理？

通过测试程序或工具模拟客户端向服务器发送请求报文，服务器接收请求报文后做出处理，然后将应答报文返回给客户端，即客户端发送应答报文的过程（Request -> Response）

3.接口测试分类？

系统与系统之间的调用：银行会提供接口供电子商务网站调用，或者说支付宝会提供接口给百度外卖调用。
上层对下层服务的调用：如Service层会调用DAO层的接口，而应用层又会调用服务层提供的接口。
系统内的服务之间的调用：如注册用户时，先调用用户查询的服务，查看该用户是否已经注册

4.为什么接口测试？

测试金字塔概念由Mike Cohn提出，在《Succeeding with Agile》中做详细论述。核心观点：底层的单元测试应多于UI层的端到端测试。

1).UI：通常指 Web、App的测试；2).Service：一般针对接口、服务，如 HTTP、WebService 接口测试；3).Unit：包含比较多，如：Web应用的dao、service、model，controller的junit单元测试，javascript、css的前端单元测试，大部分应由开发做测试保证。

参考金字塔层次划分，不能层次的测试投入量是不同的，越上层比重应越小，以尽量低的测试成本防御不同类型的风险。金字塔分层测试的ROI则是倒金字塔，即 Unit > Service > UI。Service测试层于QA而言是重要一环，也是性价比相对较高的。总之，分层自动化测试是追求覆盖的传统自动化测试的一种修正，充分利用自动化测试的优点，规避自动化测试的缺点。

现在我也找了很多测试的朋友，做了一个分享技术的交流群，共享了很多我们收集的技术文档和视频教程。
如果你不想再体验自学时找不到资源，没人解答问题，坚持几天便放弃的感受
可以加入我们一起交流。而且还有很多在自动化，性能，安全，测试开发等等方面有一定建树的技术大牛
分享他们的经验，还会分享很多直播讲座和技术沙龙
可以免费学习！划重点！开源的！！！
qq群号：110685036

5.接口测试范围？

新增及改动接口的测试（接口的改动点，可通过代码及配置 diff 测试，圈定最小测试范围。服务端接口迭代过程，需测试接口依次增多。测试时间足够条件下，当然需要进行全回归测试。但时间较短，应考虑接口的重要性与优先级，优先对核心且调用频繁的接口测试。）新增及改动业务功能测试。接口的性能与安全测试（是否需要对接口实施性能和安全测试，取决于接口特点。一个对第三方电商平台提供支付功能的接口，如：支付宝接口，性能和安全测试是必须要例行化测试的。一个系统内部调用的获取列表页接口，性能和安全性考虑优先级相对不那么高。整体而言，从接口的业务特点，即流量大小、调用方式、服务架构、业务闭环的重要性等角度考虑。）

二、接口测试策略

检查：接口设计检查，通过接口文档定义对接口交互数据做有效性检查，整数型数据位数、浮点型数据精度、字符串数据范围值等，要求客户端传入的整数型、浮点型、字符串型数据及最大值和最小值都能作为服务端接口有效输入，确保服务端不会自动进行截断或四舍五入操作。(接口设计评审阶段即可进行)

接口依赖关系检查，通常用户的一个操作可能对应服务端调用多个接口完成，从业务操作角度来看，各种业务操作所涉及的多个接口之间调用进行测试。依赖关系检查，主要通过接口的输出值为另一接口的输入值来实现的，因此在进行接口测试之前，需要分析所测试接口的输入值是通过客户端还是其他接口输出来获取的，在设计测试用例时，加入接口的依赖关系说明以便于测试。

验证：接口输入/输出验证，服务端接口功能测试类似于单元测试，在设计测试用例时，侧重点在于接口模块输入/输出项的正确性验证，根据接服务端接口处理方式分类有多种：条件判断接口、数据查询接口、逻辑运算接口。

构造：接口测试过程，常常需要构造测试数据。通常是数据库插入，mock 接口，调用依赖接口，开发脚本工具批量等。

自动化：相对于UI层自动化测试，服务端接口的自动化测试更容易实施，较稳定且维护成本低。参考接口case的优先级做自动化覆盖，回归测试、线上监控等收益均较大。

1.接口测试关注点？

入参数据：每个接口入参的默认值、异常类型、非空交易。参数是否有默认值，若没有，接口逻辑是如何处理的；参数必须输入值，若不输入或输入错误，接口如何返回；接口报错，服务端和客户端是否都做了容错处理。
出参返回：接口返回数据是否正确。
页码页数的异常值：接口有翻页时，如：第一页有数据，翻到第二页。第二页的数据是否与第一页重复，第二页接口是否报错，页码、页数，传很大的值，接口是否报错。
数据库增删改查，如对某接口post请求后，对列表页接口刷新请求，新数据是否与post数据一致。典型case，发布评论，post请求后是否返回评论数据，若无则检查是否缓存未写入数据库导致。
参数个数：入参支持多个值时，考虑传值个数多的情况，接口是否报错，接口应返回友好提示。
参数类型：输入参数类型必须校验，输出参数必须正确。即是int类型的，不能返回string类型。
排序：列表页接口应考虑排序值，升降序、时间排序等是否正确。
版本兼容：接口的改动（增加、减少字段）需要兼容老版本。
参数联动性：校验返回的多个参数的实际结果是否符合需求，如：返回一个商户的列表，总数字段和列表数据是否一致。
业务：从业务中来，到业务中去。接口测试是对业务逻辑的测试覆盖，对业务架构的理解。

2.接口测试Case设计？

Case参考点：输入参数测试，功能测试，逻辑测试，异常情况。

设计思路：a)优先级-针对所有接口，外部接口 > 系统内部核心接口 > 系统内部非核心接口。

b)优先级-针对单接口，正向用例 > 逆向用例（通常情况，非绝对)；前置条件 > 默认参数 > 参数必填 > 参数关联 > 参数类型限制 > 参数数据范围限制。

Case覆盖：主流程 -> 分支流程 -> 异常流程。

三、接口自动化演进

接口自动化演进，通常是从手动测试 -> 工具测试 -> 代码测试 -> 平台服务化演进。

手动：从客户端的业务场景测试去覆盖服务层接口，借助Fillder、Charles、FireBug等工具抓包分析。优点：简单，模拟真实业务场景；缺点：接口逻辑覆盖不够，异常和输入校验不足，重复繁琐，回归成本高。

工具：使用PostMan，HttpRequest，Jmeter, SoapUI 等工具做接口测试。优点：容易保证接口逻辑覆盖，便于异常和输入校验，提高回归效率；缺点：缺乏自定义灵活性，接口依赖处理繁琐，不便自动化工程化。

代码：选择如，Java + Httpclient，Python + Requests, PHP + Requests/cURL/HTTPFul，搭建接口自动化框架，开发接口自动化case。优点：灵活性好，扩展性强，逻辑覆盖容易，异常和输入校验充分，回归效率高；缺点：存在一定学习成本，框架及case脚本需持续维护。

平台：通用的接口自动化测试平台，简而言之满足接口自动化测试的Web平台，如：Numen。优点：通用性强，上手快，一键式，配套服务全等；缺点：业务契合度，灵活性，维护成本，API扩展等。

1.接口测试工具？

代理抓包工具
Fillder, http://www.telerik.com/fiddler
Charles, https://www.charlesproxy.com/
Wireshark, https://www.wireshark.org/

调试工具
Firebug(Firefox), https://addons.mozilla.org/en-US/firefox/addon/firebug/
DevTools(Chrome), https://github.com/CN-Chrome-DevTools/CN-Chrome-DevTools

Json&Url encode工具
json在线解析,格式验证, http://json.cn/
json压缩转义, http://www.sojson.com/yasuo.html
jsonview插件(Chrome), https://chrome.google.com/webstore/detail/jsonview/chklaanhfefbnpoihckbnefhakgolnmc?hl=zh-cn
url encode工具, http://tool.chinaz.com/Tools/URLEncode.aspx

测试工具
PostMan, https://chrome.google.com/webstore/detail/postman/
SoapUI, https://www.soapui.org/
Jmeter, http://jmeter.apache.org/

2.接口自动化框架设计？

接口自动化测试框架设计关键点，其实可以用Driven、Organize、Support、CI概括。

Driven：Data Driven(数据驱动)，接口测试关注输入、输出及各种异常数据，归根结底其实就是做数据测试。如何设计合理的参数化实现，降低测试数据维护成本，是自动化框架设计的重要内容。KeyWord Driven(关键字驱动，即封装)，将测试过程中公共过程、通用步骤尽量封装为通用函数，其中分别为业务、过程common 函数。合理的封装函数设计，将使得自动化脚本简洁化、一致性，可维护性高。

Organize：组织。考虑两个维度，如何管理组织自动化工程？如何组织自动化case？以Java语言举例，接口自动化case较少只有几个，创建一个普通java工程项目，在 main方法中，罗列写出case实现即可。无可厚非，这是一种简单实现。但随着接口数量增加，接口case越来越多，这种方式的维护成本越来越高，冗余越来越重。我们需要考虑将自动化工程化而不是脚本化，即做工程管理，如使用maven管理工程，配置各类jar包依赖，定义测试等。测试case使用单测工具管理组织，如：junit/TestNG，有什么好处？定义了case的执行顺序，通用丰富的assert验证，结果统计收集等。

Support：接口自动化测试不只是模拟一个请求发送及响应解析的过程，做为框架需考虑的远不只这些。如：json数据的比对，数据库增删改查操作，接口的数据mock构造，md5值校验，url的unicode/encode，report，email等等。

CI：自动化框架搭建了，自动化case工程化了。选择什么方式调度，什么时候执行。IDE 手动调度执行，bat/sh？CI 是一种高效的机制，每次代码编译打包部署，都应该触发CI的自动化执行，自动化框架需要考虑CI的集成。