你截图里用的不是 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)、混沌工程等手段快速创造更多的异常场景。

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

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

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

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

迟来的点赞。之前竟然没留意到这个项目。。。

额，我这个文章已经比较老了，没想到还这么多人看。

我当时的文字描述可能有点引起误解了，我当时的误区是：想通过接口自动化测试这个方式，去做非常详细的后端服务测试，甚至包括上传后存储的图片内容对不对这种级别的校验。而实际上，对于这个功能，用接口自动化去测试，相比直接人工做接口测试（上传一个图片后，直接打开返回值里的 url ，人工确认一下两个是否一致），性价比比较低。这个并不代表接口测试，就不用去测试后端服务的功能哈。

所以对于标题里的问题，我的观点是：测试的是后端服务。

然后对于第二个点，，你现在的现状其实对让接口测试产生比较明显的收益是不利的：

1、接口设计频繁变更，意味着很难并行，只能等开发功能都联调完毕，设计不再改后再开始开展。而一般调好后客户端其实都差不多可以提测了，这时候做单独的接口测试不如直接做客户端整体集成测试性价比高。除非测试团队后端和客户端是分开的，后端测试团队专职做接口测试。

2、一般对于新接口的测试，核心的目的应该是在接口设计稳定的前提下，提前测试确认后端服务提供的功能正确，减少联调期间由于服务端接口功能问题引起联调不通，问题排查时两端都得排查的高成本。如果没有接口设计相对稳定这个前提，而是一旦联调接口设计就各种改甚至推倒重来，那接口测试很难发挥威力。

建议先想办法提高团队对接口设计质量把控的能力，让接口设计能尽量稳定下来，而不是一到实现或者联调层面就各种修改吧。

请查看评论区右下角排版说明，优化下排版吧。

现在的排版完全没法看

这个确实运气有点背。塞翁失马，焉知非福，继续加油吧！

1、录制回放要看回放的是读接口还是写接口。读接口相对简单，保障中间件数据一致的情况下，直接回放请求值即可。

2、楼主说的 大多新增数据的场景都有唯一性校验 ，新增数据一般就是写接口。唯一性校验本质上是依赖数据库告知的信息的，所以写接口要做到能回放，一般需要把数据库告知信息这类和外部中间件通讯的返回值也录制下来，回放时直接 mock 告知程序，这样程序收到的一切外部输入就和录制时完全一致，所以执行逻辑也是基本一致的，不会引起唯一性校验不通过这类问题。

可以参考下 双引擎回归测试平台介绍。

不知道标题的 “震惊” 是和什么框架的写法对比得出的结论？建议文中给点对比参考，要不可能每个人接触的框架不一样，有的觉得比自己用的容易，有的可能没感觉。比如我自己就没啥感觉，看起来和日常接触的写法基本差不多，还少了个很常见的基于数据库表结构自动生成 rest 接口代码。

另外，这个 FastAPI 是你们自研后开放出来的么？还是业内已有的那个开源框架？如果是后者，建议说明下并附上框架地址之类的信息，避免引起误解吧。

没写完？

请用 markdown 代码块来排版代码部分吧，现在代码部分没有缩进高亮什么的，读起来不是很舒服。

1、裁员并不一定是淘汰，也可能是业务不行所以整个业务裁掉。

2、如果抛开业务线整个裁掉这种因素看的话，核心就是看你对业务有没有贡献。所以我理解核心要具备能发现并解决业务中遇到痛点的技能。你做的东西业务用得多、效果明显、持续有产出，自然不会先动你，因为后面还需要你。而且最好除了测开本身的技术能力，对业务也需要有一定的熟悉度，有需要时随时可以直接上手做业务测试，毕竟人少之后其实对提效工具的需求也会减少或者弱化，大家更需要的是能保障业务质量的人。