前言：探索的阶段

至少到目前来说，总算是把接口测试走上正轨。要知道，在一个测试酱油的创业公司，你要引入一个测试技术，无非是困难的，申请一个测试服务器可以申请半年。当然最重要的是一直是一个人战斗，公司没有任何人给你指导，只能自己上网查、看、实践，过程是比较无助。

前期：
项目前期，接口都是比较简单，基本上都是一个请求、一个响应，也没有过多的接口关联以及逻辑校验，这时候我用的是jmeter来实现自动化，图形界面入门简单，使用快速，顺带也把压测基础学了一遍，也和后台同学一起测了一下接口瓶颈。

局限性：
随着项目发展，接口越来越复杂，在年后加入了社区后，jmeter无法满足需求，因为jemetr只能应付一些固定模式的请求，一些复杂的需求无法应付，比如消息提醒接口，你需要构造出各种消息类型的数据准备，使用jemeter虽然可以做，但是极其繁琐，复用性也差，在返回值校验的时候重复代码多，耦合性低，在写了30多条的时候突然发现左侧的目录已经乱七八糟了，瞬间兴致全无。

基于语言编写的框架
无奈，为了解决这些痛点，只能自己实现了，基于语言的方案可以用python+unittest或者java+testng实现，最后选择了python，主要原因是因为方便和发现了一个requests库(笑)。这个框架是为了解决jemeter局限性的特点的，下面来列一下：
1.可维护性要好
2.可读性要强
3.可以复用代码，增强易用性
4.更好的接口关联和测试数据准备
5.更好看的测试报告
6. … …

回顾，接口应该测什么

虽然前面有文章写过，但是知识总是不断更新的，这里结合项目阶段性汇总一下：

1.组合参数的验证。比如版本更新接口，你需要测试不用传入不同应用的字段。同时组合参数包括有、无、存在、不存在这几种固有的情况

2.逻辑数据的校验。这个你需要根据客户端实际使用的关键字段来作为参考，可以封装一个方法判断某个字段是不为空、必须存在的断言方法。同时可以校验返回内容是否符合预期，比如一个接口，需要列出我关注的人，结果返回关注我的人，这就很尴尬了

3.业务逻辑校验
这是新加的，前两个主要校验的是单个接口或者层级不多的关联接口，这个校验的是用户实际可能发生的行为逻辑，比如：我注册一个帐号–发布某个作品–删除某个作品这种复杂的业务行为，这个我认为也是有必要加入的，1、2点如果作为单元测试的话，那么这个就是集成测试了

instaAPI

框架图

都有中文解释了，应该没啥问题，报告用的是网上搜来的HtmlReportRunner，就是unittest的美化报告，等以后牛逼了，咱们自己解析自己生成报告。

3个重要的Base基类

接下来介绍frame目录里面3个base基类：

BaseTestCase，unittest.TestCase的子类，unittest.TestCase是python单元测试必须要继承的父类，我们继承这个玩意的目的是可以更具具体项目的接口数据格式定制一些断言方法，如图截取的部分内容：

BaseRequest，基于requests包装的一层对象，这个是通用的http一般方法。ApiRequest继承这个父类，ApiRequest是BaseRequest的再次封装，可以在这一层对接口加密，进行数据的进一步处理，比如我图中截取的是给BaseRequest增加了后台同学规定的必要的请求头，以此类推。

BaseResponse，接口返回一般是code和data，ApiResponse继承，在init需要编写项目返回格式的解析方式，提供字段和get方法取得数据。

apiProvider，通过api的方式准备测试数据，当然也可以通过sql操作，但是不建议。

最后是报告，htmltestrunner，python + unittest主流都用这个生成报告，简单实用。