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 自动化这块其实已经比较成熟了，没什么特别的亮点。难点还是在移动端上面。

https://testerhome.com/topics/13372 之前用 docker 搭建 selenium 的记录。
其实本质上可以分成两部分：

1. 执行 Python 的容器。可以基于 Linux 或者 Python3 的镜像，拉取你的执行代码进行执行。
2. 执行 selenium 的服务。可以是你启动的一个远程 selenium server 或者 guid ，或者是基于 selenium 的镜像启动的容器。通过 selenium server 指定地址执行就可以了。

说说我自己的体会吧：

1. 如果是实际项目中做过了自动化测试，我会让对方介绍一下用的什么框架，什么结构，写了多少用例，通过率怎么样；怎么做的每日构建，适配多少浏览器或者机型，怎么看报告和维护；项目中花多少时间做自动化，项目过程中有做过什么尝试推动有利于自动化铺开的方法。再考察一些常见的元素定位，用例架构相关的问题。
2. 如果是项目中，没有做过自动化，我会问对方业余时间对自动化的学习和研究情况，问题也类似第一种情况，但是回答的要求会适当降低。毕竟如果没有自动化项目经验，就只能考虑招进来培养的情况了。

加油！

1. 尝试联系客户，能不能配合你们做一下调试排查，比如指导他导出一下 Chrome 的 log 之类的 给你们分析。
2. 如果客户不肯配合，看能不能从服务端的 log 找到什么信息，或者尝试参考用户的配置，去模拟相同配置下去重现。

还啥护城河呢，真以为公司没你不行？就算公司没你不行，说不定公司哪天倒了呢？
好好学习好好积累，随时做好即使被裁了也能快点找到下家才是硬道理。

问清楚后台校验是用什么字段吧，可能不是 cookie，或者 header 里的其他字段，比如 token 之类的。参考接口文档，或者直接抄浏览器上看到的 header。