第一种 diff image 的方案我们也在使用，主要是针对那些相对来说比较固定，以及包含各种图标或者图片，不容易判断元素是否存在错位情况或者颜色错误的页面，比如登录页，设置页等。
第二种场景，在某些元素因为某些特别奇怪的原因导致各种奇怪问题，比如 webview 页面元素突然无法识别，某些元素明明能定位到，但是点击却没有反应等问题，我们也尝试过这种这种方式去做。PS：这种用图片来定位元素的方式其实早在 qtp 时代就已经支持了。

iOS 17 都马上要更新了

匿名用户你好（错以为我已经屏蔽的匿名区又出来了）

请重点说说 2

Xdist 好像可以设置不同的 group，你查一下

用例的质量和作者的表达能力关系很大，碰到很多历史的用例，得花很长时间才知道到底是想测什么点和场景；而且本身对测试用例的产出就缺少一个质量把控的过程，很少有人会认真地去 review，也不会有什么 bug 被人发现出来。

Python 或者 pytest ➕appium 完全没问题呀，网上也好多资料

弱弱问一句：标题的 selenium 和内容的性能测试有啥关系？

吐槽归吐槽，尝试给你一些建议：

1.自动化测试只能有后端人员来写脚本，因为公司的测试人员没有这个技能。
-- 这是一个很奇怪的理由，后端人员也没有 APP 自动化测试的技能啊，为什么就只能由后端人员来写呢？ 没有对口技能的人员，要么从外面招一些进来，要么从内部挖掘可以转型的资源（或许你老板就是考虑到后端人员有对应的开发背景，上手自动化测试更快）。但即使是这样，也不能定义成后端人员在写自动化测试，而是后端人员转型或者学多一个技能兼职自动化测试。这样想是不是就没那么奇怪了？

2.没有设计合理的测试用例，只能通过用户行为驱动去覆盖 app 的功能。
-- 这是需要整个团队考量的，自动化测试怎么和回归测试相结合。通常的做法是从回归用例里面提取和整合出来需要的自动化测试用例去实施。
而你后面提到的用户行为驱动，是怀疑自动化测试能不能覆盖后端所有逻辑？如果是这样，应该是要分层测试结合起来去做的，单元测试，接口测试加 UI 自动化测试。

3.在上线新功能的时候，测试人员已经把所有的功能都测试完了，自动化测试方面都还没有进行或者进展很慢，跟不上发版计划。
-- 自动化测试一般我们理解有两种模式：
-第一种：以回归测试为目的。你的每个新功能不是上线之后就不需要再测试的，每次发版，功能变更，甚至只是服务器做个操作系统升级，都需要进行回归测试。所以这种需要频繁执行的测试用自动化测试去覆盖是理论上可以最大程度节省人力的。

• 第二种：与开发同步的自动化测试。需求文档确定下来之后，开发根据设计去写代码，其实测试也可以同步去写自动化测试用例（只是没办法马上联调）。当开发交付之后，只需要把对应的 locator 补充上去就可以执行（甚至如果这个 locator 已经在设计阶段定义好了，则可以无缝开始测试）。 至于你说跟不上开发发版计划，这是和你们的人力投入有关的。要达到什么目的，才能去看需要补充投入多少人力；如果人力是没办法补充的 那整个事情也就无从说起了。

4.在实际使用过程中，很容易出现一些异常情况，例如：单个测试用例运行毫无问题，一旦串行多个测试用例或多或少的会出现一些异常现象。 该怎么来规避？
-- 这些都是自动化测试框架需要考虑的因素，而且业界已经有很多最佳实践的分享。还是得多投入点时间去看怎么优化。

如果只是根据自身的问题来讨论事情是否有必要，就等同于给自己找一个不去做这件事的理由。

同样的，我们也可以给单元测试，接口测试，甚至测试这个事情找到同样多的理由。但是 “测试是否有必要？” 这个问题相信你也有显而易见的答案吧？

所以还不如多花点时间去想怎么解决你的问题吧，或者如果你自己想不通为什么一个后端开发要来做自动化测试，要不和你领导聊一下，让他另请高明，你专心做开发？

我以前是白嫖阿里云测，每天免费两次大概三十多台设备，不过现在不知道还能不能免费了。

你的个人发展方向是什么呢？ 如果是测试，我觉得还是得把自动化测试框架，接口测试，和测试的基础先巩固好。现在这个行情下面，对很多团队来说最重要的还是找到能干测试活的人，测试平台什么的坦白说优先级没那么高了

嗯嗯，加油！

testin 不是云测平台吗，那么我理解它的优势应该是背后的云真机？
我们现在使用的国外云真机平台（device farm）是支持主流测试框架直接集成调用的（比如 selenium，appium，cypress，playwright 等），因为它所提供的服务就只是设备而已，不会也不应该强制客户要根据它的模式去写，或者重新编写一套用例。不然我以后不想继续用你了，要换个云真机平台或者自己搭建内部的平台，这套用例怎么办？又重写一次？

其实很多看似的没必要，背后都是为了兼容和处理不同场景。毕竟 appium 是一个同时兼容 Android 和 iOS 两个平台，底层还要集成不同的驱动类型。如果你这一套能实现到 appium 类似的体量，效果和程度，最后的效率提升会有多少呢？

从大部分的用户使用来看，这种方式起码保证了我只要专注于怎么使用和 selenium 一脉相承的语法去维护我的用例，甚至于同一套用例，只需要区分不同平台的 locator 就可以做到公用，牺牲一点执行时间是可以接受的。而且执行时间长，其实可以通过并发执行等方式去提升，一定程度上是可以接受的。

好像图片没有放上来？

不妨先大方（但私下）问问你主管是否有计划做，说不定他正好有想法但是没合适的人，那么刚好你可以领到这个任务去研究和主导；

但如果他实际上没有想法，或者他不懂自动化也不想，不敢去做，又或者他心里面有优先级更高的任务在计划中，可能他是不希望你在所谓的休息时间去做这个任务的。

没看出来是怎么实现关键字驱动的呢？效果怎么样？

我理解如果按常见的 BDD（业务行为驱动开发），是定义、封装好一系列的 keyword 关键字，测试同事可以根据业务场景，灵活使用关键字，结合 given，when，then 这种格式组合成不同的测试用例。
参考 cucumber 和 behave 的常见用法。

https://testerhome.com/articles/18060
之前类似的操作，可以参考一下

测试管理和测试执行一样吗？

遇到了

图像识别？录制回放？云设备并发测试？AI ？

我有个疑问，现在的并发只有 3500，平均处理时间是 200 ms.;但是不等同于可以推算出来 如果平均每秒可以处理的是 3500*5 吧？ 实际上随着你并发数增加，系统的响应时间往往会下降，比如到了某个拐点，突然处理性能大幅度下降，甚至奔溃呢？

所以是不是要继续增加并发，来达到系统的满负荷状态？

你这是机翻的吧？ 感觉翻译得挺全的，但是个别句子看起来又有点怪怪的

另一方面是不是也说明 web 自动化这块其实已经比较成熟了，没什么特别的亮点。难点还是在移动端上面。