PS：如果发现找不到团队痛点，问业务、问领导都问不到（很常见，习惯了就会成为盲点），你自己直接跑去业务，和业务一起当一个月业务测试，一起测需求，哪些地方低效且容易提升效率，就立马可以发现了。

你的关注点有点不对，关注点不是写脚本还是写平台，这个只是实现形式。关注点应该是做什么能帮助团队的质量保障做得更好。包括效率上的提升，以及一些深度上的扩展。

你领导认为不只是做自动化，我个人其实也认同，毕竟自动化用例这个大多是强耦合业务的，测开人力比业务测试少很多，测开干这个，投入产出比不匹配，而且写出来的自动化业务测试同学不一定信任，还是手动再测一遍才心安，那就是白写。

举几个以前带的团队做过提效的例子：

1、测试环境数据库 ddl 的维护提效。为了便于有需要时并行测试需求，一共有维护 4 套测试环境（此处先不追究是否合理，这个是当时现状）。经常遇到由于 DDL 维护不及时导致需求部署上去后，由于 DDL 过时导致部分核心流程不可用。前期是做了一个 Python 脚本能一键应用上线时的 DDL 到 4 个环境的数据库中，保障和线上 DDL 一致。后期是引入了 flyway ，能让服务自维护 DDL 的框架。

2、定时任务触发提效。开发的定时任务用的是 spring boot 自带的 @Schedule ，缺少手动触发机制，每次测都得等到时间才能触发。后续基于做了扩展方法，测试可以通过调用接口传入定时任务相关参数，就立即启动定时任务，不用干等。

这些都不涉及平台开发，也不是写自动化脚本，但都是能有效解决当时团队痛点的手段。视野拓宽点，不要只看到自动化。当然楼主说的开源有好工具直接用这个是认可的，只是开源工具平台很容易在接入业务的最后一公里不方便（最常见的是和公司账号体系的打通，开源工具不大可能适配每个公司自己的账号体系），所以一般还是要做点二次开发才更适合使用。

长期也要考虑后面怎么 show 的问题，从这个角度，搞个前端界面包一下， show 起来容易很多，所以领导一般也喜欢做成平台形式，ppt 展示起来，总归比配一个报告或者代码的图看起来好很多。

。。。你这个不叫 10 条用例，只是 10 个函数而已。大家被你的术语误导了，默认你应该用了框架并用上了 @Test 这类注解将函数注明为用例。

后续建议在提问题的同时，把你的代码、日志也贴上来吧，这样更全面，也能尽量避免理解偏差。

好奇你用例是怎么写的，可以把具体写法贴一下么？还有具体的报错信息。

用例 fail 后继续执行后续用例，直到全部用例执行完毕，我理解应该是一个测试执行管理框架的标配，unittest 就有这样的设定。

这个是个新思路，可以开个帖子详细说下？

发你要解绑那个账号的邮箱地址，没有邮箱地址没法解绑。

你们的标准化是标准化用例的哪个部分，格式、分类还是啥？

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 用过么？没有的话可以试试。