接口测试自动化------开始实现一

接口一般是由协议组成，协议规定了传输数据结构
常用的协议就是HTTP/HTTPS协议

目前大部分移动端与服务端之间都是通过 HTTP 协议进行数据交互的
一般都是以json字符串的格式来传输数据

HTTP协议有5种操作方法 get,post,put,delete,patch
一般经常用到的就是get，post

从项目的立项开始，就应该规定接口的规范和传输协议，
后端根据接口规范进行开发，
前端根据接口规范可以自己mock数据，来开发页面
测试可以根据接口规范来些测试用例

所以，接口文档一般是贯彻整个项目的生命周期的。
很不幸的是国内的公司很少有重视接口文档的习惯，
要不然就是根本没有接口文档，全靠自己人的口口相传，对接口的设计也非常不严谨，真的很，坑人。/(ㄒoㄒ)/~~

很不幸，我现在就遇到了这样的问题，简直就是红军时代，什么都没有，全靠自己，据说，开发老大那里有一份接口文档，但是，鬼知道里面有没有进行维护和更新。

可怜的是，就这样的情况下，公司还要求实现自己的接口自动化平台。

没办法，拿人钱财给人消灾，硬着头皮上了。

我个人做事情风格是，喜欢打有准备的战争。所以要做接口自动化，首先，我需要解决好接口文档的问题，所以，我打算，自己抓包提取出接口传输，然后，自己维护所需要的接口文档。
这样的话，我就需要一个利器，可以快速帮助我完成接口的提取同时也可以便捷的进行后期的接口维护，经过多放比较，考虑到实际情况，我采用了DOClever来维护和管理我需要的接口文档，它整体的页面看起来很清爽，同时，支持可视化配置，可生成文档，对接口数据包容心高，可以协调合作，在线调试，这些是它的优点，把它用在接口文档的维护和管理是完全足够的。
可视化的编辑作为接口文档使用是挺好的，但是，用在自动化这样需要对接口不断的参数变化的话，就不太适用了，而且，我们接口会有很多，那么接口测试的用例就会更多了，

所以，我们需要一款可以快速做到接口测试的工具，经过多方比较，我决定选用HttpRunner这个框架，原名ApiTestEngine。
这是一款面向 HTTP(S) 协议的通用测试框架，只需编写维护一份 YAML/JSON 脚本，即可实现自动化测试、性能测试、线上监控、持续集成等多种测试需求。看起来挺方便的吧，因为我懒呀。。。再着这个框架是基于python开发的，我自己对python也较为熟悉些。

而且，我非常认同开发者关于分成的理念，还有har2case小工具也很不错，可以吧HAR格式直接转换为json的测试用例。大大提升了工作效率。

采用YAML/JSON格式编写维护测试用例，优势还是很明显的：

• 相比于表格形式，具有更加强大的灵活性和更丰富的信息承载能力；

• 相比于代码形式，减少了不必要的编程语言语法重复，并最大化地统一了用例描述形式，提高了用例的可维护性。

非常符合我心目中中的框架，使用Jmeter来做接口测试就很有可能需要使用excel来维护脚本，很烦/(ㄒoㄒ)/~~
使用testng来做接口测试，就需要写很多重复的代码，整体看起来很臃肿，不爽。/(ㄒoㄒ)/~~

使用json来维护，我就很开心了，因为前后端都是采用json来传输数据的，同时，json也比较好理解。

关于分成的概念，我是这样理解的，我们现在所有接触的业务应该说都是场景，而这样的场景是由很多组件构成的，组件可以理解为不同的页面模块，而页面模块的数据是由后端的接口获得的，所以，我们进行接口测试，尽量也做到组件化。

以下为引用

例如，在某个项目中存在三个测试场景：

• 场景A：注册新账号（API_1/2）、登录新注册的账号（API_3/4/5）、查看登录状态（API_6）；

• 场景B：登录已有账号（API_3/4/5）、注销登录（API_7/8）；

• 场景C：注销登录（API_7/8）、查看登录状态（API_6）、注册新账号（API_1/2）。

按照常规的接口测试用例编写方式，我们需要创建3个场景文件，然后在各个文件中分别描述三个测试场景相关的接口信息。示意图如下所示。

image.png

在本例中，接口（API_1/2/6）在场景A和场景C中都进行了定义；接口（API_3/4/5）在场景A和场景B中都进行了定义；接口（API_7/8）在场景B和场景C中都进行了定义。可以预见，当测试场景增多以后，接口定义描述的维护就会变得非常困难和繁琐。

接口的分层定义描述

那要如何进行优化呢？

其实也很简单，在编程语言中，如果出现重复代码块，我们通常会将其封装为类或方法，然后在需要时进行调用，以此来消除重复。同样地，我们也可以将项目的API进行统一定义，里面包含API的请求和预期响应描述，然后在测试场景中进行引用即可。

示意图如下所示。

image.png

仅仅把单独的接口提取出来是不足以应对测试的需求的

虽然我们已经将接口的定义描述抽离出来，避免了重复的定义；但是在实际业务场景中，某些功能（例如登录、注销）会在多个场景中重复出现，而该功能又涉及到多个接口的组合调用，这同样也会出现大量的重复。

接口的模块化封装

玩过积木的同学可能就会想到，我们也可以将系统的常用功能封装为模块（suite），只需要在模块中定义一次，然后就可以在测试场景中重复进行引用，从而避免了模块功能的重复描述。

image.png

具体引用了：https://testerhome.com/topics/11356

总结

市面上有太多的轮子了，有时候，并不需要，我们去重复造轮子，就算我们去造轮子可能也没有大神们原来的轮子好用，在不是必须要自己单独造轮子的时候，我更加倾向于，使用市面上的开源工具，他们的存在是非常优秀的，我们可以充分发挥这些工具的优势利用在我们现有的项目中，可以通过发现问题，然后，共同进步。

关于接口测试，我还在尝试更多的可能性，每走过一步都希望可以记录下来，过段时间，回过头来看看自己到底是进步了，还是走错了路，只有去尝试才能发现问题，现在我是使用DOClever来管理和调试接口和文档，使用HttpRunner来做接口自动化，Jenkis来做持续CI，部署的话，还在考虑中，当然代码管理使用的是Git