automation 可能可以帮助发现这类问题，但是也不一定。根子上还是需要解决过多的共同依赖。

最近项目改了架构，所有的 ID 都没有了，没错，是木有了。
自动识别的前提是改动不多。

完全做测试工作，手工性能自动化安全不管哪一样，左移右移，都只能提出问题，并没有解决问题。

如果不可或缺，说明公司认为提出问题本身不可取代。

[W3C] Encountered internal error running command: Error: Cannot start the 'tv.danmaku.bili' application. Visit https://github.com/appium/appium/blob/master/docs/en/writing-running-appium/android/activity-startup.md for troubleshooting. Original error: Activity name '.ui.splash.SplashActivity' used to start the app doesn't exist or cannot be launched! Make sure it exists and is a launchable activity

找不到 activity，用 weditor 看看这个 activity 啥回事

locust 不熟悉，如果请求量大，可以考虑先用 curl 请求一次，存在文件里，start 读文件到 global 里面，然后每次调用。

ffmpeg 你值得拥有

你可以认为 mock 就是 后台服务，里面挂载服务程序，不过挂的服务不做生产逻辑，做定制的 rule 逻辑或者转发给真实服务，在获得结果后再转回给请求者。
没啥神奇的魔术

真是瞎说。。。。
开发一般某些领域深厚，测试宽广，各有千秋。

版本比较工具，各种数据库或 nosql 或接口或配置数据操作工具，api 测试的数据制造、驱动和校验工具，发消息，mock 工具，日志分析工具

iframe 可以理解为一个 page

use log please

先任意的点，再取消，算出特性指标？？

跑到这个命令所在的目录下执行应该 ok，然后把路径 export 出来

先发 api 找到符合对应条件的订单，再用 ui 操作比较方便。

多了机会学习很多开发的东西，丧失机会学习很多测试的东西。
所以过一段时间测试集中化，过一段时间项目化比较好。
个人觉得项目化的时间占 2/3 比较好，技术可以通过项目分享做。

恭喜楼主啊

很赞，提个建议，是否可以支持配置 route 到真实 server，这样可以支持真实 respond 和 mock respond 的切换。

做成可配置的？天用秒来代替。一天当成几天用。

db 和 es 校验的比较全面，而且可以确认存储，避免缓存影响等，接口校验比较快速，而且面向用户。

各有不同应用，无需每个 case 都用 db es，但是应该某些 case 覆盖到 db es 的。

这样做有个问题，浏览器当前的 DOM 和 保存的 DOM 有可能不一致，累计下来可能相差越来越大。

用带 json 的数据库哈，主要字段和其它字段分开来

把完整的报错文字贴上来，感觉第一行 /bin/bash 了，所以 os 找不到 shell 文件的位置？

这种问题，总归要是耗时间，耗精力，多学习，多合作的才是高逼格。
楼主确实做的不错，不过在后面两点不涉及，可以换个 case 说说

说明目的，有个原子操作的高效操作视频，其它无所谓，增加覆盖率吧。

可以做那个写 codeless 工具的测试，不可以做那个用 codeless 的测试