前言
之前的介绍内容,关于Mock只是简单的介绍了用法,具体如何与我们的测试代码结合还没有提到。今天内容主要介绍Unittest这个贯穿所有内容的关键知识点。虽然内容简单,如果有疑问一定在初期都查阅相关资料解决。避免以后代码量上来后,回来补课
一、简介
unittest库是python自带集成好的库,不需要我们pip安装,或许你也听过或者看过其他诸如:pytest的测试框架。诚然这些框架或多或少都有比unittest更优秀更简洁的地方,但是初学中,依然建议大家从unittest入手,之后向其他框架转移。
这里,我们不再像其他库简介一样从理论和定义出发----“unittest中最核心的部分是:TestFixture、TestCase、TestSuite、TestRunner”,很枯燥也容易第一时间劝退新人,我们直接上代码,从实际的问题出发。然后回归定义,从而巩固知识点。
二、初次尝试
我们回想下,之前的脚本代码都是什么样的形式。 我们是不是为了验证我们的脚本内容,无论去尝试写比较low的flask代码,还是写mock,都有一个相同的逻辑做支撑----“通过获取到的数据,对数据进行判断\验证。以此验证我们的脚本是否正确(日后验证我们接口是否正确)” 那么我们再想一下,之前的代码如何做到的验证\判断呢?我们是不是通过打印出请求结果值,然后通过打印出来的数据对比我们之前设计好的无论服务器代码也好,还是mock代码也好,它们数据是否一致来验证\判断。
好,理清这个逻辑后,我们看向下面两段代码 server.py
@app.route("/get", methods=['GET'])
def get_fun():
data = json.dumps({
"username": "了不起的QA",
"password": "11111"
},ensure_ascii=False)
return data
以上,是我们之前flask框架的代码,我们截取其中一部分作为演示内容。然后运行server脚本。 如图,启动后我们查看以下代码 requests.py
import requests
url = "http://127.0.0.1:5000/get"
res = requests.get(url)
print(res.text)
尝试下运行结果 很显然,这就是我们之前引入各种小知识点时用的例子。结合我们刚才总结的逻辑支撑,如今的代码好像不能做到我们心中能验证数据内容的样子。那么我们稍微改装下,让它符合我们心中所想。 requests.py
import requests
url = "http://127.0.0.1:5000/get"
res = requests.get(url).json()
if res["username"] == "了不起的QA":
print("接口测试成功")
else:
print("接口测试失败")
我们把代码做了修改,之前只是获取数据,打印出来,人工肉眼去看数据正确与否显然是不行的,我们加入判断语句来帮助完成数据验证的部分。上面的代码里,我们去请求本地的get接口,获取到返回值后,判断数据中“username”是否是“了不起的QA”。如果是,接口成功,否则失败。
至此,我们的之前总结的逻辑支撑,看起来已经实现了。但是有没有想过这样是不是有些麻烦,还很愚蠢。如果我面对的成百上千的接口,我是不是要写如此多的请求代码,我如果面对的是一个接口数据需要多重的断言内容,是不是要写更多的if…else…代码块?
当这些问题被思考的时候,我们今天的主角unittest就登场了。
直接上代码
import unittest
import requests
class RequestsTest(unittest.TestCase):
def test_request_username(self):
url = "http://127.0.0.1:5000/get"
res = requests.get(url).json()
self.assertEqual("了不起的QA", res["username"])
if __name__ == "__main__":
unittest.main()
先尝试运行代码,我们再来分析代码内容 直接显示了“OK”。
三、代码解析
看的出来,要使用unittest首先引包必不可少 其二,我们定义的class类需要继承unittest.TestCase。不要问为什么,甲鱼的屁股–龟腚(规定) 其三,我们之前的逻辑代码里,用if的判断语句,现在变成了assertEqual。 其四,执行方法是unittest.main()而不是我们想当然的先初始化RequestsTest对象,然后调用test_request_username()方法
接下来我们开始正式介绍unittest用法 基于我们上述的总结。还需要补充:unittest使用时,test方法都必须是test开头才能被执行。 那么,我们进一步分析。
理论上来说,我们一个test方法,应该只验证一种情况,当然也需要根据自身业务情况自己决定。比如我们公司项目内,只验证errorCode是不行的,还需要辅助errorMsg验证。那么就在一个test方法里,写入两个assert断言就行
这里要说明的是,类似于每次的请求,或者每次test都在做的处理,我们可以放入setup这个方法中来统一在每次执行test方法前,统一执行。
- test结束后,对于一些变量,或者初始值发生变化的,怎么复原呢?
类似于每次的请求结束后,或者每次test结束后数据复原等处理,我们可以放入teardown这个方法中来统一在每次执行test方法后,统一执行。
或许我们有太多的问题得不到解答,或许还是有一些想不通的地方。我们本篇文章主要通过一些逻辑支撑引出unittest初步实践。下篇,我们会更加详细的介绍unittest用法,此时有太多的疑惑,太多的不解,可以尝试查看相关资料。或者等下篇更新。
基于此,我们的接口测试自动化内容的前期准备已经完成。之后,我们就结合现在学习的内容,实践里一步一步完成接口自动化
|