接口自动化的手脚架

为何需要手脚架

就我在项目中遇到的情况。愿意写接口文档的开发人员，可谓少之又少。大多数不是沉默以对，就是认为这本身是属于测试的工作，不应该摊到开发身上。但是如果要人工去一个个收集这些接口参数或者维护这些接口的变化，实际还是很难做到的，工作量不小。在团队大部分测试人员的技术没达到的情况下，更是无从开展。于是手脚架的作用就显示出来了。

华山一条路？

其实这个问题，有很多种解法。从技术上来讲

1. 说服开发，引入swagger框架swaggerUI官网
2. 用postman/fildder收集后，再手工转成接口自动化的代码或者相关文件
3. 自己动手写一个代理，浏览器配置上这个代理，代理自动录制转换

我们先来看看各自的优劣：

评估点	swagger UI	postman/fiddler	全新的代理jar
技术难度	easy	easy	medium
使用效果	great	good	unknow
维护难度	easy	simple	unneccessary
需要投入资源	开发测试都要	测试	测试/测试开发

---

结论是使用postman/fiddler更加容易推行

postman或者fiddler的使用。网上一抓一大把的攻略。这里不再赘述。
这篇文章要解决的问题就是，如何快速获取到要测试的接口，即接口测试的手脚架。

postman或者fiddler都是一样的。这里只以postman为例子说明手脚架的思路。会包括部分核心代码

1、获取json文件的schema
postman可以录制chrome的请求，然后我们单独抽取，存放到colletion里边。

然后选择导出（share collections）。即可dowload下来一个json文件。
下来就是好东西了。有一个轮子大家不知道用过没有，就是json自动转成javabean。

链接在此：在线json转javabean

package跟class的名字都可以自己定义。真是想不到。。这个轮子是在我写这篇博客的时候发现的。
我当时的做法，是人肉解析这个json的schema，然后手写各种的javabean。囧。。

anyway，无论你用的是fiddler或者postman，还是chrome的F12里边的save得到的HAR文件。本质上
这些都是一些json格式的文本文件。只要能得到对应的对象接下来就好办了。

2、转换文件到java实体对象

这里包括两段核心的代码。一个是读取文件。这个百度一搜很多，这里不贴出来，ctrl c+ctrl v就好。

还有一个核心其实也挺简单。就是阿里提供的轮子：fastjson包。

下边是我转换的一段示例。

     /*
     *  @author:retinder
     * generate the json file from postman collection
     */
    public boolean generateJsonFile(String filePath,String targetPath) {
        String temp="";
        JSONObject json=new JSONObject();
        collection j = JSON.parseObject(readFileByLines(filePath),
                collection.class);
        for (collectionRequest request : j.getRequests()) {
            json.clear();
            createFile(targetPath, request.getName().replace("\\", ""));
            for (collectionData data : request.getData()) {
                json.put(data.getKey(), data.getValue());
            }
            try {
                writeFile(targetPath+File.separator+request.getName().replace("\\", ""), json.toJSONString(), false);
            } catch (Exception e) {
                // TODO: handle exception
                e.printStackTrace();
            }
        }
        return false;
    }

看到没，特别简单。就是这么一段代码。就可以按照collection自定义的名字，得到每个接口的参数的json文件了。因为我后边自己写的http请求接口的框架，很大一部分是基于文件的。所以我直接转成文件。
如果是基于数据库或者excel或者其他方式持久化的。这里边的逻辑自己改造一下就可以了。

3、更进一步
核心的步骤跟代码就是上面这样。是不是特别简单。这样做下来。你可以很迅速得到一个基本覆盖完全整个业务系统的一堆接口。
当然如果还要做详细的接口检查断言。这个还是需要熟悉业务，然后自己组织整个接口测试的顺序的。

postman的collection只有请求，是不包括返回的，如果是使用fiddler或者chrome的HAR文件。
是有reponse对象的。根据那个解析出来的东西，我们可以自动生成json schema的预期还可以指定
一些基本常见字段的检查规则。比如在下边这段

 {
       status:"0",
       message:"success",
       xxxx:[{
                   id:"0",
                   name:"man"
       },{
                   id:"1",
                   name:"woman"
       }
       ]
       }

基本上每个接口都有status，那么就可以对status做检查。还有就是接口改动的话，要判断schema的改变。
那么就可以一下子得到两个最基本的检查了。

接口参数化

上边的代码其实可以再改造一下，就支持参数的默认，还有自动更改（需要接口测试框架的支持）

后边有空再补充一下接口测试框架的设计跟组织。好吧。又挖了一个坑。慢慢填吧。