爱测未来开发-巧用模板引擎编写基于参数配置文件的HTTP接口测试工具

        

最近接到一个需求，希望提供一款基于读取用户配置参数文件的，使用方法灵活的HTTP接口测试工具。

        大体的需求有如下，用户希望能通过一个简单的txt配置文件，控制整个http接口业务的流程调用，循环调用，参数检查，以及接口测试报表输出。也许这时候有人会说，现在有那么多的接口测试工具框架为什么要单独实现一个。对于这个问题，我只想说一句：资源是有限的，而需求是无尽的。。。

        在考虑如何设计这个工具的架构时，我一度设计了三个大版本，直到第三个才较为满意被用户接受，简单聊聊前两个版本的架构思想以及为什么它们不被接受。

        在设计第一个版本的时候，我是这样想的，我提供框架，让测试者对具体业务按照我的框架模式再封一层，测试拿到我的工具时候先要去自己针对业务封装成自己动 一个测试模块，然后我的工具负责加载这个模块。这个方案很快被否决了，客户说我的业务无穷无尽，难倒每个都得去自己封一下吗？我思考了下觉得有道理，便开始谋划第二个版本，第二个版本呢，不需要测试人员对http接口再做一层封装，但是要求测试人员以代码的方式定义一个业务测试流程，就是说http测试发包这个方法我全部封好函数让你可以调用，但是业务逻辑你必须通过代码，继承我的一个BaseHandler类来定义整个测试流程。我满心欢喜的将这个思路传递给客户，无奈的是依然否决，给出的理由是用户对象是不会写代码的用户，这一下可真要考验我设计的能力了。

        后来我冷静地思考和分析了一下，用户的刚需其实就是想通过快速而方便的编写某一个配置文件，通过这个配置文件控制整个http接口测试流程，这是他们最主要的需求，那么我就没必要考虑暴露给他们什么工具接口给他们，只需要考虑工具最终的使用方式是通过配置来实现。

        于是我想到了开源模板引擎JinJa2(http://docs.jinkan.org/docs/jinja2/)。

        我们在web开发的时候像python的django，以及js中的angularjs等各大语言都有模板引擎的概念，web后台在通过给模板依据模板变量传递值，最终渲染成HTML文件供浏览器加载，这是个很棒的概念。有人肯定用过自动化运维工具Ansible,Ansible中就使用了我下面要说的 一个模板引擎：JinJa2

        于是我设计了如下的一种HTTP接口测试配置文件格式：

这个配置的每一有效行都基本都符合一个大的规则：提供HTTP发包的一些必要的参数，比如method，url，post/get的参数pathquery等，另外也提供了一些灵活的方式来做一些处理，比如像图中exp后面的这种{{}}包络的 我们都知道他是模板变量，模板变量带| 这种叫做过滤器，因此像这里的save("uuid")会在请求发包拿到响应的时候，将响应中的uid保存到key: uuid里，供下一行http发包请求使用。这种需求很常见，比如我们一般都是第一步拿授权，第二步http调用一般都要带上这个授权，而通过这种配置的方式，就不需要测试人员写一点点代码，只需要他会这样写配置就可以了。

        这里可能有人会比较关心save工作原理，我这里描述一下，save在这里是一个Jinja2模板的中的一个自定义过滤器，名称是我自定义的叫 save，目的就是为了保存http接口响应中的一些参数值（这里是uid）到一个key（这里key是uuid）下，再后面的调用时，我可以直接通过key拿到这个值。

        我的HTTP接口发包是通过requests库发出去的，大家做python开发的都应该知道这个库，非常方便的http发包库，一般用做爬虫。那么在 save自定义过滤器实现中，我会根据配置中，比如上图配置调用了save并传递了"uid"，和"uuid"两个参数，那么在这一行请求构造中，我会向request请求中注册hook函数，并且带上这两个参数，这个hook函数真正实现了save核心功能，解析响应保存参数。

        配置文件中的save过滤 还有下面的g 过滤器，expect过滤器(如图)都是按照jinja2中的自定义过滤器方法编写的，如果后面有更复杂的需求，我们可以增加过滤器，从而达到扩展http接口测试工具的目的。比如图中的expect过滤器，这个过滤器会接受一个期望值，如果这一步http调用返回的某个结果不符合这个期望，那么expect过滤器会在报表中记录，接口测试完成形成统一报表，十分灵活。

公众号：itest_forever

CSDN:http://blog.csdn.net/itest_2016

QQ群：274166295（爱测未来2群）、610934609（爱测未来3群）