idevice_id error: /bin/sh: idevice_id: command not found

这个报错很明显了，找不到 idevice_id 命令。idevice_id 命令所属的 libmobiledevice 这个库装了么？你直接命令行调用，可以成功调起 idevice_id 命令么？

ERROR [device_service] Environment variable ANDROID_HOME not found!

这个 ANDROID_HOME 环境变量配了么？

顺道搜了下官网文档，确实没写装 libmobiledevice 这方面的信息，只有插件的 github 主页有写：https://github.com/Meituan-Dianping/lyrebird-ios。可以给官方反馈个 issue ，让他们补全这部分信息到官网上。

优雅是个很主观的词，我也不知道怎么样的用例算优雅。。。

对于 ov 的安装弹窗，目前貌似除了用自动化脚本针对性去点掉外，没啥特别好的办法，除非能搞到内部版系统之类的。不过这个只是安装时用到，而且相对比较通用，写一个性价比还可以。

至于登录，我们是复用 UI 自动化里的登录用例的，不过在原来登录基础上加上了多账号管理机制，多设备同时跑的时候，会额外传一个机器序号的字段（比如跑 2 台机器，1 台传 1，另一台传 2），避免账号互踢导致实际并没有登录。登录完再开始跑遍历程序（可以理解为是前置脚本）。

而针对内部随时冒出来的权限弹窗，这个应该要在遍历程序内处理的，这个是自动遍历类工具的标配吧。

如果是自家 app ，可以找开发加 contentDescription 属性以及根据开关状态切换这个 id 值的逻辑。

可以参照：https://developer.android.com/guide/topics/ui/accessibility/apps

客气了。

每个奇葩问题的背后，其实都是一系列运行原理的组合。搞懂这个能让你更清晰真切地了解 python 的外部库加载机制，建议你可以继续追查下，相信会有所收获的。

至于为啥会自动加载，我从你的文件名大概知道原因了，你可以自己试着查下，了解后能有效帮助你避免以后出现同类问题（这个问题其实并不奇葩，属于新手常见问题之一，只是你的脚本刚好输出内容有点特别而你又没提及，所以大家都被你给出的 “磁盘空间不足” 误导了方向）

PS：下次提问建议最好是把你项目有关的全部信息附上，最好是把代码放到 github 仓库方便其他人复现，否则缺少有效线索，大家只能靠你选择性给出的信息去猜，很容易方向错误。

很不错的文章，先增加一些场景细化复现场景，然后查资料了解黑盒子背后的原理，提出假设 + 验证确认，点赞！

话说，这种为了高性能服务，并且发了后不用管的，用 UDP 应该比 TCP 更合适，当时开发为啥不考虑直接用 UDP ，这个有和开发探讨过么？

这个要看你这报警的阈值是怎么设置的。

如果是抛个异常就预警，估计会很多（很可能出个 bug 就异常了，或者是历史原因系统存在很多其实不用关注的异常）很快就疲了，加了等于没加

如果是能限制为影响环境主流程才预警，那会比较有效，但会比较难，因为从日志其实很难区分，比较有效的是 4 楼所说的，在测试环境里跑已有的自动化用例（特别是流程类的），不通过的时候预警。我们之前是加了主流程自动化的失败监控，30 分钟跑一次并且自带重试机制（有可能刚好某个服务在部署，引起失败），如果重试还是失败就预警。

已 star，能把环境里的流量转到本地方便联调，挺不错的。

话说，你是转行做运维开发了？

你的户籍人口这个控件的 xpath 是怎么来的，有确认过这个 xpath 的正确性吗？这个控件查找的时候加个显式等待试试（因为从你描述看，应该是请求网络成功过后才会出现这个元素，所以点击后立即找有可能网络还没返回，所以找不到）

可以在 chrome 浏览器的 审查元素 - 元素 tab 用 xpath 搜索，看看在你点击了下拉框加载到数据后进行搜索，是否有搜索到结果。

挺好，问题范围缩小了。不过我自己没遇到过这个问题，所以也只能给些建议：

可以试试：
1、确认下是所有 import 都有问题，还是只有 request 库？如果是后者，可以试试重装 requests 库，看是不是装的时候有问题。
2、项目目录不要放 C 盘桌面，改放别的盘或别的位置（因为一般系统也在 C 盘，桌面属于 C 盘用户文件夹下目录，所以 C 盘特别容易遇到有权限限制的文件夹）

请把你微信误绑定的邮箱地址发出来。管理员可以根据这个地址找到绑定信息，帮你进行解绑。

请把你微信误绑定的邮箱地址给出。管理员可以根据这个地址找到绑定信息，帮你进行解绑。

你把你代码改用纯 selenium python 库方法写一遍，然后运行。把你的代码 + 运行错误日志贴上来吧。

你现在这样也看不出为啥你自己封装的一个 __find_element__(section, option) 会返回一个 None ，与其花时间逐层看你的封装有没有问题，还不如你直接去掉所有封装，直接写代码发上来。

这里面不同定位策略你逻辑还不一样，看起来比较麻烦。

或者你不要用你封装的，直接用 selenium python 库自带的函数 (driver.find_element 以及 click 方法) 来写看看？就写两次点击这个方式的就行。

即文件的存放路径为：C:\Users\xxx\Desktop\test.py 可以正常执行成功
当文件的存放路径为：C:\Users\xxx\Desktop\xuexi\test.py 就会报磁盘空间不足

从这个现象看，同样 C 盘有 2 个报错，说明大概率不是真的磁盘不足，有可能是权限问题导致无法写入。你有没有装 pycharm 之类的，可以在里面打个断点之类排查下具体是哪行语句报错？

self.base.click(section="add_Basic_population_jump", option="House_registration_register") 这个函数的具体实现是怎样的，发一下？需要细到能看到调用的是哪个 selenium python 库的方法，现在你封装了不知道里面做的啥操作。

selenium 的 select 相关 api 是肯定不行的，报错里已经说了只能用于 select 标签元素，不能用于 div 标签。

不知道楼主正文这段话是想讲给谁说的？看起来有点怪怪的。

个人理解，对于整个团队乃至公司来说，测试人员的价值不就是让有你的时候，质量能比没有你的情况下高，减少质量问题带来的损失么？只要这个有做到位，就有价值呀。

目前的情况是，QA 发现 bug，他们会认为那是你分内的事情，但是如果没有发现 bug，那就是你的不称职

额，前半句 “QA 发现 bug，他们会认为那是你分内的事情” ，我觉得没毛病。“但是如果没有发现 bug，那就是你的不称职” ，如果 bug 造成了损失而测试没发现，测试肯定是有责任的（主要但非全部），这个也啥没问题。

还有些公司采购了一些自动化的工具，然后就把测试人员裁掉了，好像测试人员是没有价值的。

这个推断没看懂，是买了之后就把测试人员全部干掉，让开发或者其它角色用自动化工具保障质量，还是只是裁掉一部分节省人力？如果是后者，我觉得很正常，这个和测试人员价值没啥关系。本身公司花钱买工具的目的就是为了提高效率节省人力，原本 5 个人干得活现在 3 个人就能干，多出来的 2 个人裁掉省成本，这是非常正常的思维，放到产品、开发、测试任何一个角色都是一样的。

1、你是要 UI 自动化还是接口自动化？如果不是为了验证产品功能，接口自动化是最稳定的。至于你说加密，不知道你说的是 https 还是别的加密方式，这个和开发沟通就好。

2、如果是要做 UI 自动化的话，网易 airtest 用过么？没有的话可以试试。

就你现在的代码，截图或者直接贴内容都可以，想看看你现在是不是用了错误的姿势来做下拉框操作，所以定位不到。

一般下拉框会有两种实现，一种是 html 自带的 select + option 标签，selenium 对应 api 是 select_by_index 等专门的 api。另一种是用 div 标签模拟的下拉框（实际值存在一个 input 标签里），这种就按照用户的操作顺序，一个一个来 定位元素 + 点击 就可以。

另外，既然你都可以截图看到 dom 树里面点击后更新的内容了，为啥你一直说 selenium 找不到呢？我在 1 楼已经说了，你这个加载是通过点击下拉框才触发，那自动化里也点击下拉框后再找，不应该找不到呀（涉及网络有可能立即找还没加载出来，可以加个显式等待）。

个人常用的方法，仅供参考：

1、先把需求点列上

2、列的时候先考虑用户使用场景，补充不同的场景（边界值也会在这个里面用到）

3、查看开发的技术方案，看从技术方案角度还有什么新的场景需要补充（举个例子，和第三方通讯且通过对方回调返回结果的场景，需要有对应的补偿机制，这个补偿机制一般是需要单独测的，需求不会提及，但实际这个功能可以用和不可以用，对业务的稳定性有非常大的影响）

4、需求会涉及服务端接口的，针对接口文档和技术方案/代码里的接口逻辑，单独补充接口测试用例

你把你的代码贴上来，我们看看是怎么写的，再针对性说明吧。

都是很正确的理论，但实际落地还有很多需要考虑的点，不见得没做到就不优秀。

相比完美的理论，我更喜欢因地制宜的落地和背后的思考，这才是管理的关键所在，也是人与人之间最大的不同。

如果指的是数据库数据，思路上可以整个数据库 DML 在执行前 dump 下来，执行完毕后删数据重新把 DML 恢复回去。

但实际业务上，评估了性价比后，我们没有做回收。

测试环境并不是专用自动化环境的话，用上面说的方式会影响其他人日常使用。如果一个一个表去恢复数据的话，表结构比较复杂，或者数据分散存储在多个服务中的话，回收成本很高，需要梳理清楚整个数据流，而且维护要跟上，稍有不慎就变脏数据。
还不如每次重新注册个新账号来得简单。

极少数场景不回收不行的（比如线上有些场景要用真实手机号且按流程只能走一遍，账号比较有限）的，再针对性开发相关的回收功能。

@debugtalk 看看？

先点击下拉框元素，再查找及点击出来的其中一个子元素？
只要你查找的那一刻，元素有在 dom 树里面，就可以找到。