httprunner框架历程介绍（一）

因需求要搞一些测试自动化，但苦于自己本身没有接触过测试的自动化，无从下手很是头疼。近期从朋友那里了解到了httprunner这个框架，就翻阅了部分资料惊奇的是在网上发现了httprunner框架的原生作者和他整理的一些文章（包括框架的起源命名，作者的灵感到实现的过程以及功能迭代），感觉还不错！
因此对这个框架做了一些简单的总结整理

一.起源
这个框架的乳名是ApiTestEngine，本身只是一个接口自动化测试框架。后来随着框架功能的逐步强大，这个名字已经不能很好地涵盖他强大的功能了，于是更名为httprunner

二.思想
其实，不管是何种业务类型或者技术架构的系统接口，我们在对其进行测试的时候都需要以下几步：
发起接口请求（Request）
解析接口响应（Parse Response）
校验测试结果（Validation）

三.测试用例中各个字段表示的意思：
1.request模块：
表示请求，里面包括url headers method
2.extractors
extractors这样一个结果提取器，只要返回结果是JSON类型，就可以将其中的任意字段进行提取，并保存到一个变量中，方便后续接口请求进行引用。

3.response
表示返回结果

4.function_binds模块：
为了实现自动生成md5等的一些经常变化的值，减少劳动力，所以在测试用例中引入function_binds模块，就可以将函数定义与函数名称绑定了
函数用lambda写成表达式存到测试用例中，使用eval对测试用例中的字符串函数表达式执行（但是这种方法局限性太大，简单的是可以实现，复杂的就不好实现了，容易形成重复性代码）
后期做了修改，如下import_module_functions模块

5.import_module_functions模块
用来指定函数所对应的路径 里面可填写多个模块的路径。而测试用例中所有需要使用的函数，都定义在对应路径的模块中。

6.requires模块：
为了实现各种包的引入，例如生成随机数的时候需要引入random库
罗列出当前测试用例所有需要引用的库，然