可以看看各招聘贴，一般是要求 java 和 python 的占多数，说明这两种语言是比较普遍的。

微信支付这种原生类的支付方式一般是需要调用到微信 app 里的一些逻辑或者是秘钥之类的，这样会比直接通过接口安全些

发现点击《专栏文章》后的分页错了

是的，笔误，已经改过来了

也就是说实际上两个地方在做多进程并发：
1、 用例的并发执行。实现方式就是例子里的 pool.map(run_case, case_id_list)

2、selenium 服务节点上的并发执行，这是 selenium Server 自带的

我是根据每个用例的类型，在初始化的时候指定对应的 driver 类型（例如 chrome、Firefox）。每一个用例都发到 selenium Server 上，它会自动分配到对应的节点浏览器。

至于并发，参考我这篇文章的例子，所有用例组成一个数据队列，按指定的进程数量进行并发执行即可。

https://testerhome.com/topics/15534
可以参考之前分享的实现方式

selenium grid 是支持一台服务器上并发多个进程的

语法问题啊，sendkeys("需要输入的字符串内容")

你的 sendkeys (111) 传的是 int 类型，所以报错了

我猜测你们的系统应该是提供一个接口给广告方调用的（或者反过来，广告方提供接口通知到你们系统）， 可以问下开发具体的实现方式，用最符合生产环境情况的方式模拟数据。
例如获取到系统对外的接口，按接口定义的格式发送数据，模拟广告方的通知。

当然还有其他的方式，例如直接插入数据到数据库，等等，具体方式就看系统具体的实现逻辑了。
总之还是建议了解清楚这块的业务需求和实现。

改成 png 格式会保险点

不能自己主动去搜吗？ 你这帖子下方就自动关联了一个几乎一模一样的问题：

https://testerhome.com/topics/11739

如果项目经验丰富，可以根据系统已有的功能界面分析、猜测需求。
例如如果是个购物网站，就大概知道会有哪些流程，如商品管理、订单管理、支付功能等。

广告方的数据格式肯定是知道的吧，不然你们开发怎么进行适配和保存？

人工干预、广告方插入： 这些是线上环境才会做的吧？ 如果是测试环境就可以模拟啊
而且这些运营、广告方的操作，也需要包含在测试范围里吧？

这个排序应该是后台实现的，根据后台的算法逻辑制造对应的数据，测试对应的排序结果是否符合预期就可以了。
例如按点击数排，就制造对应数量不同的点击数数据
数据应该都是可以模拟的，不清楚不能模拟的理由是什么？

APP 的服务端和 WEB 的服务端没有太大差别。 大概会有以下这些：

1. 对外接口： APP、WEB 都是通过接口和服务端进行通信的。 其中接口一般包括查询性的接口（例如查询商品列表、查询订单列表）和功能性的接口（例如登录、支付、注册）。
2. 内部逻辑：服务端接口收到客户端（包括 app、web 等）的请求后，都会触发各自的一些业务逻辑。
3. 定时任务：服务端可能会有一些定时任务对数据进行一些批量处理。
4. 对外系统接口：服务端可能会和一些外部的系统进行一些业务处理。例如第三方支付服务，服务端需要到对应的第三方支付后台进行验证、查询等。

还要看具体的场景组织是不是一样，例如接口调用顺序、参数设置、thinktime 设置等等
当然还要看你执行的工具是不是同一个

要开发者账号吧

‘这个文案怎么没有发现’
‘这个丑陋的设计怎么没有发现？‘

我觉得得看这两句话是对谁、在什么场合说的， 从引号的内容里看还好吧，没有针对测试。

“改了之后还是不行” 把改完之后的代码和新的报错发上来看看吧， 不然也不知道你改得对不对，报错还是不是老的错

贴图错乱了吧？

你这是在回避我的问题。

1、99% 表示目前许多人搞的 UI 自动化已无效率意义、属于浪费时间、浪费测试资源的事情；

-- 我就问你 99% 的数据是怎么来的， 数据如果是真的，就请严禁列出； 数据是自己瞎编的，就早点承认。

2、玩过 QQ 音乐、美团、京东这样的 APP，录制回放成功率与自己优化录制脚本、自己 UI 自动化的经验有关；

-- 玩过代表实际项目经验吗？ 录制回放成功率和经验有关， 手动写脚本同样和经验有关，有什么冲突？

其他的 3-6 点， 都不是你说的这套东西创新出来的，而是现在大部分框架都有的功能。 你所指的淘汰 99% 技能，其实只有一个录制和手动写脚本的区别。

如果你认为录制就代表 UI 自动化的 99% ， 那就没什么好讨论的了。

忍不住想问几个问题：

1. 题主既然很少做 UI 自动化，是从什么方面得到 99% 、 95% 这样的数据呢（实际项目统计？ 问卷调查？ 实际测评对比？）？ 还是只是来个吸人眼球的标题？
2. 一天时间内完成一个 APP 的所有一级、二级、三级入口的覆盖： 请问这个 APP 的体量有多大？ 页面入口总共有多少？ 一共有多少个用例？ 录制回放成功率多高？ 后续执行稳定性如何？ 和完全手动编写的脚本或者用例，这几方面的对比又如何？
3. 一个项目做 UI 自动化， 框架搭建和维护（用例管理、失败重试、报告生成、数据存储维护等）和脚本用例的设计、编写/录制、更新维护、失败用例分析和 bug 确认， 这些工作分别占多少的比例？ 这里面分别有多少是属于你所说的 UI 自动化技能，其中又有哪 99% 是会被淘汰的， 哪 1% 是不被淘汰的？

如果有实践，请拿出数据来说服和警醒广大无法理解的人，谢谢！

随着各种开源框架的发展，自动化测试的入门门槛确实是在降低。
但是 “99% 的 UI 自动化技能转瞬即可淘汰” 这标题也太危言耸听了吧。 怎么定义 99% ？ 怎么定义 “转瞬” ？

其实自动化测试也就是一个如何使用工具的问题， 工具发展越来越先进和智能，但不代表工具就能完全替代工具使用者啊， 应该是继续使用先进的工具来做更深层次、更高目标的事情。

举个例子，现在的摄影技术越来越先进，各种器材黑科技层出不穷，随便一台智能手机的摄像头就能吊打几年前的卡片机。但也没见 99% 的摄影师都被淘汰了啊，相反先进便捷的相机为摄影行业提供了更多的可能。