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

嗯嗯，加油！

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。

需要有自动驾驶方面的业务经验吗

应该还要保持播放的状态吧？

一个猜测：你的文件名不以 test 开头的话，好像默认是不会扫描出来的。可以在 pytest ini 里面配置。

从理想的模型来说，这完全是可行的：

1. 需求明确下来了，可以编写完整的测试用例，并且从里面挑选需要做自动化的用例。
2. 用例编写：先写结构，元素的 locator 可以两种方式处理： 2.1 待定，先留空。等开发的页面出来之后，补充上对应的 locator。这时候理论上用例就可以执行了。 2.2 如果做得细致一点，可开发沟通好每个主要元素的定义，比如 ID，name 或者是自己添加专门用来做自动化的自定义属性，比如 @testdataID 。只要开发和测试都把这些属性加完整，那么用例可以事先编写完整，等页面开发出来可以直接执行。

这其实是测试有效性的问题：怎么进行完整的测试。像你说的一样，用户是在前端操作的，所以你完整的端到端测试应该是前端发起；如果你看一下测试金字塔，接口测试其实是归属于分层测试的其中一个环节，也就是说只能保证你接口这一层没问题，不能保证端到端。
要解决你的疑问，应该要在接口自动化之余，加上适当的 UI 自动化，由接口去保障大部分的调用场景，由 UI 去保障端到端。

要想彻底节省工作量，还得 UI 自动化；接口自动化是可以帮你做更大范围的覆盖，保障一下单纯从界面上发现不了的问题，或者更快更直接定位到接口的错误。