怀疑是服务器被攻击了，导致处理不过来返回 502。。。

hmm，确实不大好。

晚些换个静态页替换掉 nginx 默认自带的这个页面。

不知道你这里的白名单，具体是指什么白名单？

我们之前支付环节不怎么做拨测，主要做监控 + 预警。主要原因是一般为了保障高可用会对接多个支付渠道，而支付渠道不同，背后走得第三方系统乃至自家系统配置都不少差异，要通过拨测覆盖成本不低。不如做支付失败数量，或者支付成功订单和前一天环比数量波动情况的预警性价比高。

这个问题描述看得我云里雾里。。。你的问题具体是什么，具体哪几行代码截取到的图不是指定元素的图？那截到的是什么图？

作为测试，描述问题请像报 bug 一样专业吧。

有这段代码的话，测试任务还是需要加锁的。因为测试任务里面的测试结果，pr 里面是不带有增量保存的。
同时前端记得按照我 pr 的说明里适配一下。

然后对于清除执行记录这个，我瞄了下我的前端，原来没把这个功能迁移过来。。。所以我只说思路吧。

思路是给服务端请求了 clear 清除了对应的测试结果记录后，把新结果的 json 对象更新到 VueTestcaseMinderEditor 的 init-json 属性绑定的对象即可（印象中 react 要显式用 set 属性名 的方法才能更新指定对象，而 vue 直接更新绑定的对象值即可）。组件内部有对这个属性值进行 watch 监听，一旦检测到变更，会立即变更自己的展示内容。

1、 前端想加上这个清除结果功能的时候，发现后端里面还调用了 websocket，会报错 ，不知道您的解决方案是？

你的服务端用的是 agileTC 么？清除结果的核心是清理掉数据库里 exec_record 表里的内容，清理了这里后重新从服务端再拉一次合并测试结果后的用例数据，就是清除了所有测试结果后的数据了。

2、保存 baseCaseContent 内容，在分配多个子任务的情况下，需要获取到全量的 baseCase？还是说只要获取到当前子集的 baseCase 内容？

没太明白你的问题，这里的全量和子集具体是指？

然后如果是使用这个组件配合 agiletc 服务端使用的话，多人协作这块可能你需要花点精力处理下，比如加个锁或者让服务端能做增量保存，否则按照默认情况，是会出现相互覆盖的问题的。

客气啦。

PS：建议你用下 python 的语法糖，用

code, udid = get_code()

这样的写法，会更清晰简洁。

你的工程代码方便分享下不？之前也有同学反馈过，但我这重现不了，不好处理。

额，排查说不上，只能说给些思路参考。

你这里报错的原因上面已经有同学说得很清楚了，原因是 find_element_by_class('android.widget.button') 没找到元素，所以返回的内容是 None 。一个 None 类型的对象，是没有 click() 方法的，所以才会出现你正文里的报错。

相当于你直接运行 None.click() 这段代码，这样会报正文里的错，应该显而易见吧。

然后你说的 最后测试跳过这个元素，操作点击其他的元素的时候同样也会报这个错误 ，没看懂你这里跳过是什么意思，请把你改动后的代码以及错误信息都贴上来吧（请不要截图，直接贴文字，截图看得好累。。。）

你截图里用的不是 VueTestcaseMinderEditor 组件，而是 AgileTCEditor 组件哦。

VueTestcaseMinderEditor 目前没有支持 websocket ，所以你如果用这个组件的话，涉及 websocket 部分的都会用不了。

code = get_code()[0]
uuid = get_code()[1]

这里调用了两次获取图片验证码信息的接口，有确认这个接口在一定时间内多次请求，会返回一样的结果么？如果不确定，这里改写成只获取一次吧。

看你简历一共有多少个项目，多的话写你觉得比较亮点的就行，少的话可以都写上。

1、把你的脚本内容发出来看看？现在信息太少了
2、可以的话录个屏，对比看下你手动登录 + 点按钮，以及自动化登录 + 点按钮有什么差异？
3、和开发确认下，登录后登录态在客户端的保存是怎么做的？（浏览器的话一般是 cookies），确认下你自动化提示 404 时，登录态的存储信息是不是丢失了？

信息有限，且不知道你的内部网络环境具体情况，不好给意见。

可以参照下这篇看看？https://blog.csdn.net/qq_39390545/article/details/108755289

今天写帖子写的云里雾里的感觉。

看完表示也有点云里雾里

建议你先确认下，你这个 find_element_by_class 方法，找不到元素是不是会抛出 NoSuchElementException ？还是只是返回个 None ？如果是后者，那这个 try catch 就是无效的。

在 appium python client 里没找到 driver 对象有 find_element_by_class 的方法，所以无法确认。

关于场景图在实际项目中应该写到什么粒度比较合适，这个在实践中有什么比较适合的经验分享么？

很赞的思考总结，加个精让更多人可以关注到

按照文中的方式进行安装并启动，固定出现如下报错，无法运行起来：

$ python3 -m solox
Traceback (most recent call last):
  File "/usr/local/Cellar/python@3.9/3.9.2_1/Frameworks/Python.framework/Versions/3.9/lib/python3.9/runpy.py", line 197, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/usr/local/Cellar/python@3.9/3.9.2_1/Frameworks/Python.framework/Versions/3.9/lib/python3.9/runpy.py", line 87, in _run_code
    exec(code, run_globals)
  File "/usr/local/lib/python3.9/site-packages/solox/__main__.py", line 2, in <module>
    from .web import *
  File "/usr/local/lib/python3.9/site-packages/solox/web.py", line 9, in <module>
    from flask_socketio import SocketIO,disconnect
  File "/usr/local/lib/python3.9/site-packages/flask_socketio/__init__.py", line 24, in <module>
    from werkzeug.serving import run_with_reloader
ImportError: cannot import name 'run_with_reloader' from 'werkzeug.serving' (/usr/local/lib/python3.9/site-packages/werkzeug/serving.py)

python 版本： Python 3.9.2 。是我运行姿势不对？

AOP IN LINUX（在 shell 命令行中实现 aop）

好奇楼主的最终解决方案是什么？个人以自己已知的知识，想到的方法：
1、针对构建工具运行命令加参数的，可以给编译环境增加临时 alias 覆盖原有命令，让 alias 的新命令默认自带添加覆盖率所需参数
2、针对需要针对项目结构注入新配置的，可以看看这类配置构建工具本身是否支持将其转换为方式 1，不行的话考虑对构建工具进行扩展，让其可以在加载外部配置时自动注入（不过这样还是深坑，不见得所有构建工具都能这么方便扩展，但至少应该比去重新根据构建工具的规则，解析各个配置文件并插入覆盖率配置要简单一些）。

好奇问下，用这些生成类似随机字符串方式生成的用例，实际跑的时候不会因为不符合业务规则导致接口返回错误什么的吗？

这个问题好大，不知道怎么去回答你。。。而且也没看出你的任何思考和尝试，有点伸手的味道。

仅分享个人的一些观点：一般从功能测试转技术性岗位（比如测开、自动化）这类，最总要的是体现你真的具备方面的能力，包括能写脚本、知道原理、一些常见的难题自己可以解决或者大致知道怎么解决（最常见的是自动化不稳定怎么解、难维护怎么解）、最好是有这方面的项目经验（能用 STAR 法则清晰表达这方面的项目经验）。

楼主可以考虑准备下这方面的资料，优化好自己简历，然后上招聘网站投递下试试？

觉得这个行覆盖率做到什么程度，才能真的有收益呢？

感觉你的方向反了，应该是为了得到 xx 收益，因此在行覆盖度上需要达到 xx 水平。目标应该是获得 xx 收益，而不是行覆盖度达到多少。

如果发现提高全量代码的行覆盖率没有获得收益，建议要复盘分析下这些原来没覆盖，现在覆盖的代码是否存在质量风险，如果大部分通过阅读代码，就可以确认没啥风险或者风险很小，那费劲覆盖它也只是求个心安而已，很难获得很大的收益。建议是先阅读未覆盖部分的代码，找到风险大的部分再针对性覆盖，同时做好覆盖后其实也发现不了 bug 的风险预期，控制好投入。

另外，对于 “发现更多 bug ” 这个收益目标，用覆盖率作为手段可能性价比不大高。要在测试阶段发现更多 bug ，应该考虑引入更多、更复杂但实际可能出现的场景。从这个点出发，可以考虑怎么提高测试设计能力进而设计出更全面的用例、引入内部其他人员体验测试等让测试过程中可以覆盖更多意想不到但可能出现的场景、提高程序可测性（说大白话就是多加一些能让场景模拟更简单的后门）让你可以更方便地注入各种想要的异常。技术上则可以引入随机测试（比如移动端的 monkey 测试、遍历测试）、模糊测试 (fuzz testing)、混沌工程等手段快速创造更多的异常场景。

要想避免做了之后得不到收益，建议是一开始多花时间思考预期能获得的收益和可能得不到收益的风险，衡量好投入收益比再做。虽然是句正确的废话，但要真正做到还是得花一些功夫的。

哈哈，确实是，越大越发现相比其他更重要的事情，这些算不了什么。

以前我不能接受有瑕疵的东西。比如一支笔的笔套丢了，那这个笔我就不要了。但现在完全不在乎，笔能用就可以。人生也是在慢慢妥协，妥协的过程就是做减法的过程。

同感。有些以前强迫症接受不了的，现在强迫症也慢慢减弱了。