很多播放器可以看，现在 Mac 上用 IINA，选项里，在窗口 - 检查器有

这个好玩，要是有 postwoman 版可以简单弄个可以服务端部署的

啧啧啧，竟然过了这么久了

其实很多 “大公司方案” 是组织成本太高只好那样做的

如果是为了接口测试用例，Nginx 日志差不多够了，这样不占服务器资源、不依赖运维发布体系
挑出一部分流量记录 Response 日志做断言也可以试试

用 Git 、自动化测试框架和报告管理手工用例

git 加 cucumber
git 加任何一个有 BDD 风格的测试框架

这不是必填的，不加这个参数就行，opendiffy/diffy 这个项目现在是 sn126 在维护，用他们的服务才需要这个

有影响的接口现在都没做啦

twitter/diffy 没法编译成功，有些依赖地址貌似是私有仓库。没仔细看其他有没有不一样

ffmpeg 算 psnr，ssim 都很方便，openCV 是要自己实现吗？

ffmpeg -i main.mp4 -i ref.mp4 -lavfi psnr="stats_file=psnr.log" -f null -
ffmpeg -i main.mp4 -i ref.mp4 -lavfi ssim="stats_file=ssim.log" -f null -

上周想搭 QoSTestFramework 没弄出来，各种报错

用例多了 Page Object 更好（实际能写很多的情况很少）
多人开发 Page Object 更好（实际很多人写的情况很少）
抽象成 Page Object 复用性可读性更好（实际抽象的很差复用性可读性很差）
UI 改动频繁 Page Object 修改起来更快（实际和全局搜索替换差不多）
……
即使需要更高的抽象了， Page Object 或者数据驱动也只是方向之一。
这和开发论坛上常见的轻量重量框架之争差不多，能清楚的了解场景，然后根据场景做合适的选择才是困难的地方。

好几年前开始学 UI 自动化的时候，到处都在教 Page Object ，就跟着这样写咯。后来听 SAP 的人分享端到端自动化，说他们有两万多的用例……

同时执行

代理还有这两个，不过写的挺舒服就没去尝试了
https://github.com/mitmproxy/mitmproxy/
https://github.com/snail007/goproxy

1. Browsermob，用自签名 HTTPS 证书的时候解析不了（没找到原因，也许我用的方法不对）
2. AnyProxy 有 UI 界面，手工测试、调试的时候可以用同样的工具、代理规则、准备好的测试模板数据
3. Browsermob 断点调试的时候，一个页面有 10 个请求，只想断其中一个请求，其余 9 个也会被断住，界面判断超时就几秒，这样享受不到断点的好处了。如果都要改代码重启，AnyProxy + 动态语言方便多了
4. 接口都是 JSON 的，JavaScript 处理 JSON 相比 Java 方便超级多
5. 接口都是 HTTP 的，JavaScript 处理 HTTP 相比 Java 方便超级多

之前用了 Browsermob ，不过后来放弃换 AnyProxy 了
Browsermob-proxy 验证埋点和下载功能

总觉得把信息放在公开的社区而不是圈子里 DevOps 才能有效

Ruby 在中文世界和英文世界是两个东西，第一次用 Capybara、Rspec 的时候真是惊艳
Cucumber、Pact、Rails 里的 Sandbox、环境设定、migration、还有各种和测试相关的设计，学的时候觉得视野开阔了很多

随便找个开源项目就可以，不一定要公司项目。
你要实践接口，就可以自己搭个 Testerhome 测呀
https://github.com/testerhome/homeland

我小透明啦~~再说哭给你看

那下一个问题就是，你是相信行政规定在 Word 里的流程，还是相信嵌在代码里被机器执行的流程

为啥 “发请求” 本质上也是 Mock（仿制品？），不是个普通的接口测试吗？

不说炒不炒概念，加上 “发请求” 这部分后，能不把 “联调或提测的时候才发现后端修改了接口定义没有通知前端”，这种情况变成 “后端修改接口定义的代码一提交，前端就知道了” 这种情况呢

那么请求是什么样子的呢？看不到猜不出来呀

倒不是想说这个，如果不是每次提交都跑一遍测试。
比如第 15 个提交引入了缺陷，第 50 次提交时开发发现了这个缺陷在第 51 次提交把它修复了，然后又发现第 20 到 25 次提交的代码是在错误的基础上开发的，所以用第 52 次提交重写了这部分。最后提测的时候跑测试，一切正常。
比如发生这种对话的时候，“这里功能怎么和以前不一样？”“你记错了吧，一直都是这样”
比如，开发没有提交过代码，第一次构建测试通过，第二次构建发现测试失败。发现构建策略是第三方库只限制大版本，小版本自动升级。如果小版本也限制死，就享受不到三方库升级带来的好处，比如重要的安全漏洞修复。

我觉得在选哪些场景做自动化的时候；需要在实现难度和测试效果之间取舍的时候；碰到那些 “这不是 Bug，是外部原因造成的” 情况时，判断到底是不是 “外部原因” 要不要采取措施。都很难很难。

找了个质量一般的产品，翻了一下提交历史。500 次提交里，修复缺陷的提交 102 个。可以归类为一个流程里第三次出现的缺陷，9 个。
如果在这个缺陷第二次出现的时候编写一条自动化用例，那这 500 次执行可以发现 9 个 bug。