少走很多弯路

“基于此点，2023 年笔者对 CRM 模块开发了大量接口和 UI 的自动化用例来覆盖尽可能的业务场景，回头想来，这个兜底的动作是非常有效的。”

有没有啥数据支撑，正愁不知道咋吹，参考一下

大佬，就是收集用户访问的 api 比例，比如一天有 100 访问了网站，需要统计这 100 人分别访问了啥 api，然后他们之间的比例如何，然后做性能测试时就按照这个访问比例去发起压测

"不只适用于单个接口的测试，同样适用于多个接口组成的完整的业务逻辑的测试，这往往是接口自动化测试更应该做到的"

真没见过谁的接口自动化测试是只能做单个接口的，还有，定义了 yaml 还得在写一个 test 类型的代码，一个接口写两次。。。。

大佬牛逼

UI 自动化能阻止就阻止，阻止不了就加入.

真实践行了打不过就加入的原则，哈哈

楼主转了告诉我，我也转

感觉你的同事们你对你都很好啊

rpa 只会更强大

接口变了的话，没什么好办法，只能跟着变

这种思想真不知道说是祸害人还是激励人。

诚然有人一直优秀，缔造和平世界，带领人类走向火星，可为什么就不能有些螺丝钉呢？难道这个世界不需要螺丝钉的存在吗？或者说不允许螺丝钉的存在？甘愿做螺丝钉的人就那么 “有缺陷” 和犯过 “那么多错”？

bucuo

分布式每台开 40 线程试试

adb shell am instrument -w io.appium.uiautomator2.server.test/androidx.test.runner.AndroidJUnitRunner

执行了之后会一直在后台保持？碰到就给你点掉？

测试环境去了呗

抓哇的怎么说

🐟哥

var options = new EdgeOptions();
options.AddArgument("--disable-features=msHubApps");

或者 send_keys Shift + Ctrl + /

每个类型选一种？

adb？

那就使用公司的账号，公司没有的话，那就自己单独重新注册一个，专门来处理公司的业务

我感觉怪怪的，假如 test1 是调用了其他的服务，第一轮测试时 test1 正常，但是第二轮测试时 test1 调用了的服务修改了，然后因为第一轮测了 test1，所以第二轮就不测 test1 了，两个报告一合并，那总体的报告会显示 test1 覆盖了，但是其实第二轮根本没测 test1，如果第二轮测了 test1 就可以发现与其他服务交互时发生的问题

怪不得，打开页面一多就这样。。。

为啥。。。。

可能在面试了