unittest/pytest+requests+htmltestrunner/allure怎样封装requests库去开发高效稳定的测试代码？

如果觉得文章对您提升有所帮助，请帮忙点赞、收藏、转发、留言提升下热度让更多人看到，关注随意，仅依赖平台的推广流量太有限了，谢谢大家！

对于接口自动化框架的实现方案，网上有太多讨论的文章，大体上都是趋向于两类，一类是用例组织工具unittest/pytest/nose，一类是测试报告htmltestrunner/allure/beartifulreport，用例组织工具这块作者会告诉你pytest、unittest、nose是如何组织测试用例的、有哪些好用的功能、pytest的断言如何优于unittest等等话题，测试报告这块呢基本上都是allure吊打其它测试报告工具，如何的美观、功能强大、插件丰富等，但是很少有作者会发文章告诉你如何去封装requests库，怎样封装科学合理，兼容性强、拓展性强等等，其实我也有疑问，这是为什么呢？requests作为接口发送的接口库，理应是最应该讨论的点啊，后来我在任职的公司看到一些投入生产使用的框架对requests封装的源码后，慢慢有了答案，基本上在设计上都存在或多或少的缺陷，遇到最离谱的是连单点登录(sso)和http协议都没搞清楚也在开发接口自动化框架，肉眼可见的设计缺陷和可预知的bug，时刻忙着自己写bug自己改，而这还是来自某个名为某的的大厂投入生产对接了10+子系统的解决方案。在这个框架上不仅开发的测试代码非常难看，并且基本上只能实现非常简单的场景测试代码开发，比如说查询，而那些涉及多个接口工作的复杂业务场景，真正能够带来价值的测试代码在这样的框架上根本开发不出来。那么这样的requests封装设计有什么意义呢？

不可否认的是，二次开发requests库确实需要很强的能力，而且是综合的，扎实的理论知识、接口测试业务功能设计能力、程序结构设计能力、源码开发能力缺一不可。这里简单的提几句不做深入拓展，因为拓展开来某一项里的某一点也有很多内容。首先扎实的理论知识，这个不必多说吧，网络、http(s)协议、requests使用等。接口测试业务能力这块，就是需要将接口测试的业务功能设计的合理、规范，方便开发集成到源码中去，不能出现功能设计上的耦合。程序结构设计能力需要你运用面向对象的思维将程序的结构设计的合理，拓展性强，新增新的功能或修改功能不能影响已有的测试代码工作，同样也不能出现代码功能上的耦合，一个宗旨：requests库二次封装的效果就是，只做和http(s)协议相关的事情，其它任何功能都不应该出现在requests库二次封装的里面。源码开发能力要求代码实现的质量了，可读性强，可维护性强，便于其它人理解或在此基础上开发。

接下来我们从源码上剖析：