编 写：袁 亮
时 间：2017-01-16
说 明：postman 实现API自动化测试
一. 实现目的
- 接口开发调试工具
- 自动化测试
- 接口用例团队内共享
- 降低接口文档编写成本
二. 实现流程
-
团队使用同一份文档
测试文档存入代码仓库
使用前从代码仓库拉取导入
修改完之后，重新导出，并更新代码仓库
ps:后续为了降低代码层级，可以将API分成很多个collection，前期先合并成同一个 -
使用工具产生文档
postman：界面gui模式
newman：服务端cli模式
三. postman产生文档
- 通用层实现 在collection上做
- 所有接口都先放在同一个collection，后期根据模块拆分
方便在同一个collection上实现一些通用逻辑 - 环境变量支持
appid: 10101
appsecret: 8e2160ec2b07f1faca9055be530bf09d
host: http://api.shop.ci123.com/
maxtime: 300 - pre-request中实现签名
- tests中实现统一的校验
http状态码 200
返回json，并且需要包含state和mess字段
接口超时时间
签名出错
- 所有接口都先放在同一个collection，后期根据模块拆分
- 目录层级规范
- 根据模块不同，创建不同的文件夹
- gui展示的原因，目录层级最多3层
- 每一个接口，都是一个文件夹 (所以实质上除了collection只有2层目录)
- 最底层的文件夹下，所有请求都是同一个接口的不同用例
- 具体实例实现
- url地址
{{host}}/Item/getSkuByItemId?appid={{appid}} - post参数增加两行
expire {{expire}}
mdstr {{mdstr}}
ps:因为request只读的原因，不能追加，只能在每个地方都写一次这个 - 填入其他请求参数，构造每一种apiReturn的情况
一个用例只实现一个对应apiReturn，这个return可能有多种情况，放在examples里 - 每个用例，必须增加tests，来告知是否通过
除了最终成功的那个请求，其他请求的tests主要就是校验state状态码即可 - 执行成功的用例校验
写请求：一般是校验对应的id是否正确，比如订单id，商品id等
读请求：解析对应的json数据格式，是否包含什么样的字段等等
ps:后续谁有空可以看下，是否可以自己定义模板，现在看到的那些模板只能选择使用，不能自己创建
- url地址
- 开发调试规范
- 从代码仓库把文档导入到postman
- 接口编写过程中，使用这个来进行调试，所有情况必须测到
有多少个state返回，就最少有多少个接口用例 - 接口全部写完之后，必须通过runner来确保所有用例全部跑通
不要出现改到后面，前面的跑过的用例又跑不了 - 写完之后，把postman里的数据导出到git仓库中
四、自动化测试 todo
- 安装newman环境
- 定时或者在git的钩子里设置
- 拉取对应的文档，执行测试
- 测试结果入库
- 展示报警
工作台展示
邮件、短信报警
五、postman常用操作
- 设置
皮肤设置
返回值解析设置：json auto的时候，没有自动识别是json - 环境变量设置与使用
- 数据导入导出
collection导入导出
整体导入导出 - 复制修改
用例复制，文件夹复制等 - examples使用
可以配合做mock server - runner使用
- console控制台调试
- 搜索
- API文档发布
免费版有限制，可以大概看看 - 官方文档，可以快速看一遍
- 错误提示
特别是全局变量中的 - runner里执行的时候，一定要注意request的是要保存里的，不然更改了是无效的
send本身是直接起效 - ctrl + s保存修改
- Codeception