传统的QA自动化测试通常是基于GUI的，比如使用Selenium，模拟用户在界面上操作。但GUI测试的开发、维护成本和运行的稳定性一直是测试界的老大难问题。投入大量的人力物力开发、维护、运行，却得不到相应的回报，令许多同行头痛不已。不过端对端(end to end)测试确实是QA/测试团队的重点工作之一，是绕不过的坎，怎么破？今天就分享一下基于API（HTTP层面）的自动化测试，姑且叫它“半端对端 (semi end to end)”吧。其实我认为它已经接近95%端对端了，为什么这样说？

 

假设有一个测试用例：

 

第1步：输入数据1

第2步：输入数据2

第3步：输入数据3

第4步：校验前面输入的数据

第5步：输入数据5

...

第n步：保存

第n+1步：输入查询条件

第n+2步：查询刚才保存的记录

第n+3步：校验查询结果

 

GUI的自动化测试通常会完全模拟上面所有步骤，每一步都要识别相应要操作的界面元素，进行输入点击等操作，或者从界面上抠出数据，进行校验。运行过程中任何一步的某个元素定位不到，或者任何原因的操作失败都会导致整个测试中断。

那么在API层面怎么做上面的测试呢？

 

第1步：发送上面第n步的“保存”操作的HTTP，得到response，并记录里面返回的ID等有用信息。可以直接跳过前面所有步骤是因为，保存时所发送的HTTP请求里面已经包含了所有前面输入的并且经过校验的有效数据。

第2步：发送上面第n+2步的查询操作的HTTP请求，得到response，并校验里面的结果

 

对，就这么简单。理论上跟GUI上的测试效果是接近的，除了一些纯界面上的逻辑（这些通常并不是我们的回归测试重点，起码在我所经历的项目中）。最大的好处是完全不碰界面，极大的消除了操作GUI所带来的开发、维护成本和运行的不稳定性。也许你有很多疑问，没关系，接着看完也许就有了解答。

 

实践当中可以进行HTTP测试的库选择很多，大多数编程语言都有现成的HTTP库可以使用，比如python、java等。这里使用现在流行的node.js进行讲解。原因很简单，大家知道HTTP是无状态的，多个HTTP请求之间通常没有互相依赖，大多数情况下没有必要让测试一个个的跑完一个再跑另一个，所以自然就想到让多个HTTP请求并行测试，可以极大的提高效率减少测试时间。node.js的最强项就是非阻塞的异步I/O，是理想的测试HTTP的平台。这里使用了一个第三方的HTTP客户端superagent，大家可以从npm下载，到它的github页面查看API文档。

 

原理

这种API测试的核心原理是，首先保存一个离线的期望结果，然后调用HTTP请求，把实时返回的response与期望结果进行对比，可进行文本对比，或者JSON对比，大多数REST服务返回的都是JSON格式数据。

听起来似乎很多工具比如SoapUI也可以做到啊，为什么要自己开发呢，原因就是对于企业系统或者任何较大规模的系统来讲需要批量测试成百上千甚至几千个web service，不同的service需要灵活定制对结果的处理并校验，生成、发送测试报告，定期运行，甚至与运维工具进行集成等等，第三方工具没有这么大的灵活性。

 

从某种程度上讲API测试也很像性能测试，不过我们比性能测试更加关心对返回结果的校验。

 

下面是主要工作流程的详细解释：

 

 

录制HTTP：

首先，上面提到的期望结果从哪里来？你可以自己动手写出来保存到一个文件里面，但是对于回归测试来讲这样太原始，在一些企业级应用里面HTTP不管request还是response数据都大的惊人（很多需要进行压缩），数据结构也很复杂，几乎不可能纯手工进行定制。回归测试通常需要进行大量API测试，一个个手写期望结果也不科学。所以最好的办法就是使用工具进行HTTP录制。可以用的工具很多，但其中最强大的非Fiddler莫属。Fiddler的设置这里不详述，大家可以自行谷歌。

 

Fiddler设置好了以后（主要是把浏览器的代理指向它，并且打开Decode选项，如下图），就可以在界面上把测试用例手动操作一遍，Fiddler就会完整无缺的把所有的HTTP的request和reponse录制下来，当然可以设置一些过滤条件，把那些下载js, css脚本的，下载图片的http滤掉，只保留纯粹的与服务器进行数据交换的服务，这才是我们要测试的东西。把录到的所有http的request和response保存为文本文件。

 

 

保存好的http文本是标准的http协议的格式包括header, body等部分。

 

解析HTTP文本：