python 基于unittest写接口自动化脚本

一、项目介绍

unittest用例管理、提供执行器、扩展可能性。
其实不用unittest思路也是一样的。

1. 测试用例与执行结果

1. 遵循unittest格式
2. 定义一个合法参数集，用例种去deepcopy这个值进行修改
3. 编写Tool类来实现参数化。

2. 项目目录

common
  --api #接口封装类
  --request_api 请求类封装
  --response 响应类封装
  --db #mysql redis等操作方法
  --log #日志
  --opt #定制化操作，登录等操作
  --tool #生成随机数据、假数据、查验证码、修改数据等操作
  
config
	--domain #存放请求域名
	--setting #存放各项配置
	
request
    --... #按项目分类存放各种接口的信息

testcase
    --... #按项目分类存放各种测试数据

二、核心代码

1. request_api.py

定义一个api类，存放请求响应断言等等信息，使用request库进行请求

2. tool.py

参数化来源，数据不想写死，就调用这里的方法来生成

3. 某个接口的request文件

4. 某个接口的testcase文件

三、报告

1. Web报告

目前还没实现，只是用日志方式存下了请求会话。
报告的话，设想的还是和之前的文章一样，用markdown + mkdocs实现

四、后言

1. 生产力还是花瓶？

之所以一开始没写报告是因为时间很紧，而我发现我也不需要去看报告。编写完就执行，bugfix后就回归，都是能实时看到结果的。不得不说这个系统帮了我大忙，上线后需求又改了。仅改了下断言花了十分钟就全面回归了这个版本的测试用例。

2. 扩展

目前还没有报告模块、邮件通知模块。因为当时时间很紧，新公司现有框架不满足老业务的数据生成，就用python来实现了。

3. 感悟

有公司规划的接口测试1.0 2.0 3.0来实现接口测试的普及，加上Web页面，加上各种组件来维护用例。包括我前面写的读ini来执行用例，我觉得还是性价比太低。

我认为更好的UI界面，重复的造轮子并不能解决现在测试现有的痛点。我原来是喜欢用JMeter实现接口测试的，而现在的接口原来越复杂，请求与响应的json格式多达三四层。JMeter就不太适用了。写用例所用到的代码能力其实并不高。写用例最重要的不是工具，还是编写者的思路。

而专门组建团队花时间来写用于回归的测试用例，在我看来性价比也不高。跟随项目版本，每个测试都参与编写接口测试用例才是最有效率、有效果的方式。