接口测试之接口diff方法实现
一、HAR文件录制 fiddler可以将一系列HTTP请求打包检出存储成HAR（Http Archive）文件。这个HAR文件是个JSON结构，其中entries下存储着具体每个HTTP请求的信息，包括请求体、请求方法、请求头、返回结果等。我们用手机连接电脑fiddler，然后操作客户端，这样录制下来的接口请求完全是从用户角度进行操作的，所以一定程度上也是基于用户行为的线上接口的稳定性验证。录制过程很简单，在fiddler中选中要验证的接口请求（或者全选），点击File->Export Sessions->selected sessions或者All sessions： 然后选择默认HTTP ARCHIVE V1.2，点击Next起个名字保存可以。 这时候我们可以打开这个HAR文件看看这里面都是什么，可以用Notepad++或者直接拖动HAR文件到fiddler中，查看JSON数据。 具体的HAR文件规范请参考：http://weizhifeng.net/har-12-spec-chinese-edtion.html。 这里有个tip，如果录制的HAR文件发现某个接口的response中文本内容没有被完整保存下来，而是显式”数据太大“。这时候要在录制前增加一步fiddler的配置，在fiddler界面的左下角黑色命令行处输入about:config，按下回车。 在右边出现的配置表中增加一项fiddler.importexport.httparchivejson.maxtextbodylength配置，可设置为10000或者更大的数字： 添加完成后重启fiddler，再录制HAR文件，能看到HTTP请求的响应主体完整的文本信息了。 还有一个tip一定要注意，是在录制HAR文件之前，一定要把fiddler菜单栏的Decode选中，否则获得的responseContent中的内容可不是base64解码这么简单的事情了，保存下来的东西不知道是个什么鬼。Decode选中是这样的状态，Decode外面有一层蓝色的框框，不选中的话是没有外面的框框的： 二、HAR文件处理、HTTP信息存储 对HAR文件的处理，首先要把其中的HTTP的关键信息存储起来。也是需要一个单独的类来保存HTTP信息。这里定义了一个HttpInfo类，其中包括的成员变量有：url、请求方法（GET还是POST）、用户使用的设备、响应主体、响应主体编码方式、POST请求数据格式、POST请求数据主体。成员函数则是各个成员变量对应的set和get方法。 如何将HAR文件的HTTP的这些信息存储起来呢？这里我写了一个单独的方法来完成这件事情。该方法实现的概要逻辑为： public List<HttpInfo> HttpInfoSave(){ /*读取resources中的HAR文件*/ /*HAR文件只有一行，这一行以String类型存储至HttpArchive变量中*/ /*拆解HttpArchive这个JSON结构体*/ for(i = 0：HttpArchive中entry的数目){ /*获得这条HTTP请求*/ /*保存请求的url、用户使用的设备信息、请求方法（GET还是POST）*/ /*保存响应的文本信息*/ /*保存相应的文本编码信息*/ /*保存POST请求的数据格式信息以及请求主体信息*/ } /*返回HttpInfo的列表*/ } 三、用户登陆 之所以要把用户登录单独进行处理，这是因为如果用户在未登陆的情况下或者使用过期的cookie情况下，有些接口可能返回401请求失败。所以我们要把登录请求单独拿出来进行正确的用户登录，才能保证后续的http请求都正常。云阅读这边的用户登录是https请求，客户端传给服务器的包括用户名以及md5编码过的用户密码（客户端肯定不会拿用户的密码原文给服务器，会将密码进行不可逆的md5编码）。登录成功后要从响应中拿回set-cookie字段保存至全局变量中，便于后面请求时设置请求头。这里用了一个单独的方法来完成这件事情： public void login() throws HttpException， IOException{ HttpClient client = new HttpClient(); PostMethod post = new PostMethod("login url"); JSONObject js = new JSONObject(); js.element("username"， "[hzsuixiang01@163.com](mailto:hzsuixiang01@163.com)"); js.element("accountType"， "0"); js.element("auth"， "d554e66e583c8946ad81ba52f6ea468d"); post.setRequestBody(js.toString()); int status = client.executeMethod(post); System.out.println(status+post.getResponseBodyAsString()); Header[] header = post.getResponseHeaders(); cookies[0] = header[6].getValue(); //已知返回两个Set-Cookie字段，都要保存下来 cookies[1] = header[7].getValue();} 四、按序执行HTTP请求 前面已经把HAR文件的HTTP请求都分析剥离且保存起来了，而且用户已经登录，Cookie字段也已经确定。接下来是按序执行HAR文件中的HTTP请求了。这里基本没有什么难点，按照正常的HTTPClient模拟请求的方法来做可以。需要注意的一点是，当某个请求的encoding-type为base64的时候，要把响应文本内容进行base64解码，这样输出的内容是可读的了，便于后续判断。核心代码如下： for(int i = 0;i<HttpInfoList.size();i++){ HttpInfo HttpInfo = HttpInfoList.get(i); if(HttpInfo.getMethod().equals("GET")){ System.out.println("/********************开始处理第"+i+"条请求了哦*******************************/"); HttpClient client = new HttpClient(); GetMethod get = new GetMethod(HttpInfo.getUrl()); get.addRequestHeader("X-User-Agent"，HttpInfo.getUserAgent()); get.addRequestHeader("Cookie"， cookies[0]); get.addRequestHeader("Cookie"， cookies[1]); int status = client.executeMethod(get); System.out.println(get.getResponseBodyAsString()); if(HttpInfo.getEncoding().equals("base64")){ byte[] content = Base64.decodeBase64(HttpInfo.getResponseContent()); String contentString = new String(content); System.out.println(contentString); } else{ System.out.println(HttpInfo.getResponseContent()); System.out.println(HttpInfo.getResponseContent().equals(get.getResponseBodyAsString())); } }else{ System.out.println("/********************开始处理第"+i+"条请求了哦*******************************/"); MyClient myClient = new MyClient(); if(HttpInfoList.get(i).getMimeType().equals("application/x-[www-form-urlencoded]{ System.out.println("primitive result: "+HttpInfoList.get(i).getResponseContent()); myClient.doPostWithDataPair(HttpInfoList.get(i).getUrl()， cookies， HttpInfoList.get(i).getParamsPair()); } else{ System.out.println("primitive result: "+HttpInfoList.get(i).getResponseContent()); myClient.doPostWithDataJson(HttpInfoList.get(i).getUrl()， cookies， HttpInfoList.get(i).getParamsJson()); } } } 五、DIFF结果判定 按序执行的HTTP请求的response要与HAR文件中保存的诸请求的response做比较，判定该接口是否出了问题。判定的内容包括：请求响应码是否一致、响应主体是否相同。
