背景概述：
今天登陆公司的管理后台，进行部门成员的工时审核工作，由于最近时间比较忙，积攒了好几天的工时没有审核。因为部门成员大家工作都很认真，所以审核都是通过。点击”通过“了几个待审核工时后，发现因为管理后台页面交互的问题，这样审核的效率非常低。
现在审核一个工时的流程是：
1. 加载列表页：程序调用api请求XXX成员待审核工时列表（页面方法写死每次请求20条）；（手动点击1次，api请求1次）
2. 点击单条的审核按钮，弹出审核弹窗：程序调用api获取此条审核信息的详情内容；（手动点击1次，api请求1次）
3. 点击审核通过按钮：程序调用api发送通过审核的请求；（api请求1次）
4. 等待审核通过请求的回调，页面弹出确认提示窗，点击「确定」按钮，关闭弹窗，返回审核列表页；（手动点击1次）
5. 审核列表页自动刷新；（api请求1次）
6. 继续下一个工时的审核操作。
这样可以看到，审核一条工时，需要手动点击3次，api请求3次。十几个人的工时，几天的录入信息，这样的重复工作要点击N久。
作为一个偷懒的程序猿，看到重复度这么高的低效工作，怎么能忍ヽ(｀⌒′)?
解决思路：
1. 通过浏览器开发者工具，获取到相关api请求的请求参数信息；
2. 使用Postman模拟发送api请求，完成相关操作。
API参数分析：
通过工具查看，审核通过工时的API请求只需要3个请求参数：
id: 1, // 必填参数，某条待审核工时的id
appr_status: 1, // 必填参数，审核是否通过的状态标识： appr_status=1代表通过
remark: "备注信息" // 可选参数， 备注信息
其中remark可选参数不需填写，appr_status参数恒定为1（即审核通过状态），id从审核列表api接口可获取到。
核心方法
通过使用Postman的global全局变量把获取审核列表API中获取到的审核工时id传递给审核工时API调用。
实现流程：
1. 在Postman创建一个集合Collection
2. 在Collection中创建获取审核列表API
3. 在Collection中创建审核工时API
4. 在获取审核列表API请求的test方法中处理获取的响应数据，设置全局的工时id数组 ids
5. 在审核工时API请求的test方法中处理获取 ids下一个工时id
6. 运行一下，看看效果
7. 感觉一次一次点审核工时API接口的send按钮还是慢，下面选择更快捷的方式，及Runner，具体操作如下。
8. 1秒搞定收工！！！
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
