恭喜恭喜！

建议先准备一些简单的小的点的思路（如楼上说的优化流程、增加基建等，最好是你自己测试时就觉得是个需要优化的痛点的，这样优化后效果有保障；举个例子，某个流程的测试，每次造数据都要 10 分钟以上走各种流程，这时候如果有个脚本可以一键造数据，提升就会很直接明显），然后找你的上级沟通下，了解他的想法吧。

上级提升你上来，一般内心都会有一些希望你去做的想法的。要获得上级认可，首先要了解上级的想法，确保方向不要走歪。

不好意思，我这边已经 5 年多没有碰过这个了，估计没法回答你这个问题。

建议你到官方的沟通群里反馈下？

PS：建议把相关报错截图信息也附上，光一个 “回放失败”，信息有点少。

工作内容除了日常的测试，还需要兼顾一定的测试管理，项目经理传达的意思是，之前的管理主要都是做一些资源的分配，想让通过推动例会复盘的形式，实现测试工作的提质和提效

这个目的，感觉怪怪的。一般复盘会应该是有明确的问题，要复盘根因，确认改进项，避免问题再次发生才开的，第一次听复盘会目的是 “实现测试工作的提质和提效”

我理解这个是不是应该是一个内部的定期例会，用于一起去 review 看整个 QA 的目标（OKR 或 KPI）的进度和困难，以及不同的组之间做一些信息同步和交流分享？

额，你这个不算单元测试吧。如果里面有一些上下游函数需要 mock 返回，你都不在同一个进程里，做不了，那你异常处理的代码会很难覆盖，行覆盖率会上不去。

建议花点时间去学下 java 和 javascript 的单元测试框架，比你这么折腾简单，而且现在有挺多能生成单元测试的 AI 工具，上手不难。

| 是否需要将 yaml 格式的用例，转换成页面组件的形式进行编写呢？

建议自己权衡吧。做成页面组件，好处是可以折叠省一些空间，以及对于小白友好，缺点是可能编写和查看效率降低（比如要知道某一步的参数，还得多展开一下）。

| 当前 yaml 内容步骤过多的时候，自己看的都有些费劲。不知道有什么好方法去改进这块。

做封装呀。参照 Page Object 把页面和页面上的常用操作封装一下，这样应该你的步骤应该就少很多了。

个人能想到的，仅供参考

1、换幻觉少一些的模型，比如最新出的 GPT5
2、调用多个模型，只取多个模型都一致的结果（基本不大会多个模型在同一个位置有一样的幻觉）
3、调整 prompt 及模型参数，减少模型自行发挥空间

如果是我，我会先问项目落地情况、实际收益、遇到的困难和解决方法，后面再进一步去深挖实现原理等细节。测开不像开发，落地会有产品 + 运营等负责，测开基本要自己负责落地，完成整体闭环的。

另外，这里的量化指标，说实话，太工整了，很明显不是统计出来，而是自己拍脑袋估算出来的。

34+

97 年，如果还想拼，能拼，建议选能走得更远的 B。
AI 目前在改变整个行业，甚至产品、业务本身都在适配改造，并且在一些业务上已经证明了其价值。虽然有一些吹的成分，但很多领域已经实打实地产生收益，甚至离不开了。

想延长职业生涯，走得更远，还是往这个方向靠吧。

打羽毛球，自驾游，打打游戏，补下觉

想问下，所以崩溃率大概是多高？百分之多少？

老功能不常用，所以没回归，但灰度或全量时用户会遇到，而且遇到得还不少导致你们崩溃率高。“不常用” 和 “崩溃率高” 两个有点矛盾。

没有移动办公的需求，就 mini 吧。同样价格 Mini 配置更高。

我很久以前第一个 mac 买的官翻版 air，主要是当年还有些热情带着 air 去图书馆啥的折腾技术，顺便骑自行车到处走走，在家里干扰会比较多。如果你没有类似情况，可以直接 mini。

mini 你还得算上显示器、键盘鼠标等配件的费用，air 就简单很多，还能带出去随时用。财力 ok 的话，建议 air。

我是

倒没有特别去挑选对比，只是这个最简单方便，题目也多。

个人经验，一般会逐级分类：

先按责任方分，主责事故（自己系统导致的问题）、非主责事故（其他系统出问题，连带影响到。比如机房网络挂了）
然后主责里面再分，具体的类型，比如代码问题、配置问题、数据问题、人为操作问题
根据具体类型，可以再进一步细分，比如代码问题，再细分为实现遗漏、实现不正确、健壮性不足等

一般统计分析，分到第二层就差不多了，到达这一层就足够去定一些比较通用的改进项，预防高频发生的事故。

我想到的也是截图对比。这块比较容易做自动化

如果不熟悉写对应的代码，可以用 cursor 辅助下

是的。现在外包很多简历，以前都是做正职的，能力都不差（基本都是业务测试 + 自动化测试 + 少量专项）。没有 gap 的非常多，相比之下有 gap 的竞争力会低不少

现在岗位太少，gap 2 年基本 hr 这一关就过不了了

我用的是这个，在 cursor 里项目的根目录下执行，仅供参考：

请使用python pytest、request框架，生成根目录下django后端项目对应的接口自动化用例到 api-test 文件夹中。要求：

1、覆盖所有接口

2、断言覆盖接口返回码、关键返回字段值

3、使用 allure-report 生成测试报告

4、一个接口一个py文件，py文件中1个用例一个函数

5、合理使用setup和teardown减少代码重复

生成出来的内容大概如下：

当然缺点还是有，比如跑起来有些用例会报错，需要人肉看和修正，有些断言写得还是过于简单，需要人肉加。但从提效角度，省了很多手工活。

确实还是会有一些 bug，需要足够熟悉，给到真正有效的指引，才可以快速和有效解决。但相比自己从零撸代码，省了很多力了。

最近试了下 cursor，可以直接给 django 后台项目，生成完整的 python+pytest+request 的接口自动化用例（根据项目代码自动理解有哪些接口 + 生成对应的自动化用例 + 错误码及关键字段的断言）。这堆代码人肉写，至少 1 人天，用 AI 几分钟左右就可以生成出来，提效挺明显的。

现在 cursor、trae 等深度结合 AI 的 IDE，已经可以做到用自然语言从零生成完整项目，且可以正常跑起来，还可以通过自然语言提需求，AI 直接根据需求改代码，给我震撼还挺大的。

个人观点：
接口自动化平台主要的限制，是整体设计是为自动化使用的，功能上会比较复杂无法方便的提供给非测试/研发人员使用（如产品验收），赋能能力会相对有限
而数据工厂则更加纯粹，界面设计可以更简单，更便于推广给非技术人员使用

以金融场景常用的创建一个系统内已完成四要素信息的账号为例：

• 接口自动化：先调用注册接口，传入 n 个参数（注意，这里就是技术细节了，需要了解参数名 + 参数值规范），然后调用认证接口，获得四要素认证，最后返回认证通过

• 数据工厂：一个按钮即可，返回创建完毕的账号名称 + 登录密码

技术实现上，可以数据工厂背后实现就是调用接口自动化平台的用例来完成，只是包一个单独的前端界面，这样可以大幅减少维护成本

很顺的一年呀，羡慕

很圆满的一年呀

我们也是工作流系统，我们自动化主要关注的是按照线上典型的工作流配置，进行工作流操作后，结果是否和预期一致。建议也可以从业务角度看下，实际用户使用的典型工作流配置是怎样的，进行覆盖。

另外，关于封装配置这个，可以考虑封装接口调用时，所有参数都提供默认参数，用例只需要传个别场景需要，要用非默认值的场景，这样也可以减少用例的编写时间。