前言
之前第一次做接口自动化, 整体采用的模型是线性测试, 即: 每个测试脚本都是完整且独立的, 相互之前没有什么强依赖, 所有的测试数据都是写在脚本中的, 长期下来开发和维护成本都很高, 后来公司也慢慢弃用了.
后来慢慢了解了一些其他模型:
模块化驱动
把重复的操作当做独立的公共模块, 当用例需要调用相关模块时被调用, 大大的减少了代码量, 整体也很简洁, 降低了开发和维护成本, 提高了效率
数据驱动
实现数据和脚本的分离, 用数据去驱动脚本的执行, 根据数据的变化生成不同的结果, 增强了脚本的复用性, 理想情况下做到不修改代码, 只修改数据 (不过这应该很难)
关键字驱动
在数据的基础上, 用关键字去驱动, 生成对应的结果
整体框架及流程图
最终结合自身情况, 暂时选择了数据驱动 + 模块化驱动的模式
主要流程如下:
流程图. png
所有的用例都用 Excel 来管理, 理想情况是不修改任何代码, 只修改 Excel 来驱动相应的测试, 产生不同的结果.
表格中的用例暂时由如下部分组成:
执行前. png
执行后. png
用例编码, 名称等自己定义
url 地址及对应的接口地址
请求方式根据对应的方式发请求
是否执行: 1 执行, 0 不执行
请求头和请求参数
sql 校验, 同是否执行: 1 执行 ,0 不执行
执行 sql, 需要 sql 校验时, 执行的 sql
预计结果, 预计执行的 sql 的结果, 主要用于结果判断
断言对象, 主要用来和 content 做正则匹配
状态码和内容是实际返回的值
结果分为 pass,fail,not execute(未执行)
代码整体结构如下:
主要结构. png
其中:
common 文件夹, 主要用来存放公共的文件及配置文件
getexceldata.py setexceldata.py 用来读取和写入 Excel 数据
connect_DB check_db 主要是数据库相关, connect 连接, check 用来校验执行的 sql 和预期结果是否一致
readconfig.py 主要用来读取配置文件 config.ini
check_all 主要用来校验结果, 采用三重校验: 1.status-code 2.sql 执行的结果 3.content 与预期结果正则匹配
result 文件, 主要用来存放测试结果
testcase 文件夹, 主要用来测试用例, 目前采用的是一个模块一个用例
testdata 文件夹, 主要用来存放测试数据, 如: 管理用例的 Excel 文件夹
test_runner.py 用来执行所有的测试用例
整体框架如上, 核心代码部分下一次说.
需要了解的一点小技能
在这之前需要一些其他的小技能, 方便我们进行编写用例:
使用 python 读取 Excel 表格
我用的是 xlrd 这个库, 如果不想深入学习的话, 只需要了解几个常用的 api:
alldata=xlrd.open_workbook(file)
sheet = alldata.sheet_by_name(name)
nrows = sheet.nrows ---- 读取行数
value = sheet.cell(rows,cols).value ---- 读取执行单元的值
使用 python 往旧的 Excel 表格中写数据 (即有数据的表格)
同样只用到了简单的 api
oldWb=xlrd.open_workbook(file,formatting_info=True)
newWb = copy(oldWb)
newWs = newWb.get_sheet(sheetnum)
newWs.write(rows,cols,statuscode)
newWb.save(file)
使用 python 连接数据库
我司用的是 psg 数据, 其他的 sql 等操作方法应该差不多, 都是连接 -- 执行 sql-- 输出结果的流程, 主要 api 如下:
self.conn = psycopg2.connect(host= host ,
user=user,
port=port,
password=password,
database=db,
)
cusor = self.conn.cursor()
cusor.execute(sql)
rows = cusor.fetchall()
for row in rows:
print row[0]
简单的正则表达式
用来检验某个字段是否包含在接口返回的 content 中
来源: http://www.jianshu.com/p/dc1aafcf8c31