把 fiddler 抓包数据解析，自动生成 yaml 格式的用例，能提高用例编写效率，不过还是要去手动做下参数化

这个我就帮不了你了，就像 7 楼说的，先学下 python 基础

self.request.session.headers.update(headers)

在拿到 access_token 那一步的后边加：
self.session.headers.update(headers)

session.headers.update() 更新请求头

跟我这这边的状态很相似呢，目前自动化有一定规模了，在考虑测试左移右移的事，但是很尴尬的一点是左移单元测试搞不过开发，右移线上监控搞不过运维

mark 一下

直接写代码吧，excel 封装用例无法满足复杂场景的使用需求

两个列表都 sort 再对比

不用这么麻烦吧，底层如果是用 requests.post 的话，json=data 传递 json 数据，data=data 传递 form 表单数据

这个有链接么？想看下怎么通用化

看下是不是格式传错了，body 是要 form 表单还是 json 格式的

中文或者 unicode 应该不影响啊；中文变成 Unicode 的原因是 json.dumps 默认会将中文转成 Unicode，json.dumps(data, ensure_ascii=False) 这样可以保持中文

可以，收藏了

只罚不奖就是流氓

可能是安全键盘不让录屏的问题，关掉安全键盘试下

所以 30 以后就要考虑副业了

测试是重点，开发是辅助手段

1、数据采样问题，假如一个接口提供三个场景的查询，线上采样回来的数据能不能覆盖这几个场景。
2、diff 降噪是要过滤掉不一致的数据，这里面的数据跟哪些场景相关也不太清楚
回放完一轮之后，能得到的数据是去掉环境差异后前后不一致的数据，对于覆盖了什么说不清楚；而且现在只能回放 get 请求，局限性太大，只能作为接口自动化的补充，实施成本也不小

说下两点感受吧
1、线上流量采样，采样出来的数据分布是什么样的，有没有代表性
2、diff 降噪，降噪过滤掉的数据是不是不重要的，不需要关心
这个对于输入和输出的都没有明确的预期，感觉就是一把梭哈，能跑出来啥是啥

期待大佬分享实际落地的效果，上次 mtsc 大会上酷乐家的分享，他们在 repeater 之外做了很多东西，目前个人感觉流量录制回放还有点蛮干的味道

用例与驱动层隔离，接口，web 和 app 统一封装成驱动层，再往上封装业务关键字

那么问题来了，是要开发写单元测试还是测试写单元测试？

用例之间最好不要相互关联，可以把 A 封装成一个公共方法

http 接口这部分数据可以考虑放到 yapi 或者 eoLinker 这样的接口管理平台上，可以调试接口，自动化通过 open api 拉接口数据