接口测试的康庄大道
Posted 点融黑帮
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了接口测试的康庄大道相关的知识，希望对你有一定的参考价值。
小吐槽
接口测试其实对很多人来说并不陌生甚至熟悉，不过在聊正文前跟大家先吐个槽。
其实接口可以很简单，像这样：
或者像这样：
没错，接口测试可以这样简简单单，那么问题来了，为什么还要写接口测试的框架呢？
像上面所有的例子只是简单看看接口是否启动而已，但事实上真正要测接口其“用例量”是非常多的，当面对上百上千的用例时还能用这种“原始”的方式来测试吗？
如果你的回答：“是”，那我劝你就不用往下看了 ——> 传送门退出。
OK，看到这里小伙伴们回答应该都是“否”吧，下面我将正式开始讲讲我的接口测试实践之路了。
我所使用（设计）的接口测试框架的基础脑图，如下：
相信有些朋友已经发现了，没错这个框架是用Python写的。Python的各种好相信用过的人都深有体会了，这里就不再赘述。
下面将根据这个脑图细细道来。
一、 首先basic_service_entity是所有interface_entity的父类，它为子类提供了4个主要功能：
1） _set_data_pattern (tip override)
就是为了提醒使用者在定义的子类的时候，一定要覆盖这个内部方法。为什么要覆盖这个方法？因为在实践中经常会发现，接口的参数会根据具体业务的不同其组合也不同。
比如：
在情况A下只能通过流水号查询；
在情况B下可以通过外部ID和内部ID查询但不能通过流水号查询。
这时就需要在判断了对吧，因此将这些业务参数的组织统一放到这个方法中，进行统一处理。
2） __getattr__(response handle)
这个反射特殊方法，相信用过python都应该知道吧，没用过同学也可以百度下。通过这个特殊方法，我们可以很方便的将取出response的内容，比如在response内容为{“code”:”3000”, “message”: “ok”} 那我可以这样 entity.code entity.message 很方便把值取出。怎么实现？其实很简单，对于json的返回值做一个取相对位置的json解析模块就行了。大家也看到了，除了json外还有xml和rpc，思路其实是一样的，最终都是通过反射将想要的值方便的取出。
3） basic_interface_verify
这个方法主要集中了业务的response基本验证raise自定义异常类。这个自定义异常类很重要，但我们要进行错误验证时就能精确try except自定义异常进行错误验证，甚至能在一些不稳定点进行“重试”都会依赖这些自定义异常。
4） send_request
最终将组织好的request发送出去。大家可以看到不仅仅是http还有soap和rpc都是通过这个方法的调度发送出去的，也就是说basic_service_entity并不会实现发送request的功能，而是调度发送request的实现。
二、 父类介绍完了，下面介绍下子类吧。从图中可以看到子类其实很简单，因为大部分功能都被父类做掉了，所以子类基本就是Ctrl-c Ctrl-v的活啦。
1） __init__处理实例化一些基本参数如：url这类参数。并将参数处理传给父类__init__就是super().__init__
2） 子类的重点，_set_data_pattern就是如刚刚在父类中介绍的一样，根据具体这个接口业务组织参数的pattern而不是data。
为什么是pattern？其实在实际测试中我们并希望将每个参数都做赋值，我们只需赋值一些业务关键点的参数，所以在这个方法中我只是组织了pattern最终的data是可以通过“外部”传入的也可以不传 。这点很关键。
一般来说我将一个接口定义成一个entity子类模块，所以entity子类会有很多，也就是interface_entity * N
三、 图中interface_entity * N和main_api有联系，那main_api是做什么的呢？
其实main_api就是这些松散的interface_entity集合到一起组成“黑箱”对“外”提供使用。这个对“外”就是指提供给unit test或robot framework这些测试运行框架最终实现“用例自动化”
四、 最后大家可以看到就是DB验证这块了，我在图中画了3个节点，DB_assertion、ORM、DB_factory。
这3者关系很简单：底层就是ORM，通过DB_factory动态创建session，最后在DB_assertion中组织DB验证点同时提供给unit test或robot framework使用。
目前来说DB验证这块设计还是很弱的，有点不好意思拿出来讲，不过呢，在接口测试中DB验证还是很重要的，所以必须拿出来晒晒让大家见笑了。
这次主要讲的还是这套接口测试框架的“架子”并没有实现的代码，写作初衷是通过这次分享起一个抛砖引玉之用，将我这些年来实践总结下来的经验和思想与大家做一次探讨，请大家轻喷哦！
我会在下次分享逐步的详细介绍其中的具体实现，欢迎关注。
以上是关于接口测试的康庄大道的主要内容，如果未能解决你的问题，请参考以下文章