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

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

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

没有移动办公的需求，就 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 个参数（注意，这里就是技术细节了，需要了解参数名 + 参数值规范），然后调用认证接口，获得四要素认证，最后返回认证通过

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

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

很顺的一年呀，羡慕

很圆满的一年呀

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

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

看了你 2 个截图，有个数据挺有意思的：

1. 你压测时，统计到的数据发送量是 860KB/sec
2. 压测时，响应时间最小值是 3 秒多
3. 你压测同时试验的时候，1 个请求大约 1 秒完成，发送量接近 460B/sec。

有个数没对上：
每秒传输的文件数，按传输量统计，每秒大概有 860*1000/460=1869 个。
但按 qps 算，每秒完成的请求数不到 1 个。
这个差距非常大，没太能想象出到底是什么原因（也许实际传的文件不是同一个？）

建议可以试下：
1、用同一台机器，在 jmeter 压测时，进行手动上传，看看效果（排除网络条件不同，导致的结果差异）
2、在被测机上，也看下压测期间接口 qps 和响应时间数据，看和 jmeter 差距如何

方便的话，建议你把 jmeter 的脚本贴上来，现在的线索还是太少了。

建议可以把目光放长远一些

看短期，关注的会是会不会被开，有没有赔偿。

看长期，你可以得到了一个成长契机，以后发展空间更广阔。比如你可以借助这个能力强的人，快速获取到很多行业经验知识，少走很多弯路。如果合得来，还能成为你以后长期的人脉，后续你找工作可以借助他的人脉帮你内推。

有些时候，想什么就会看到什么，最后就会变成什么。改变想法，路会更宽（有点鸡汤，但从个人接触的身边人看，这确实就是人与人之间的差距所在）

OA 打错字了？

可以用前端组件库呀，比如 vue-admin-template。

有别人封装好的，用就是，开发效率会高不少，代码也更容易维护。

推荐 gidevice，稳定性比 tidevice 高，可以 github 搜一下

我们之前云真机要保持 7*24 小时连接，用 tidevice 基本 1 天左右就要重启一次，gidevice 可坚持的时间长不少（具体多久忘了，应该超过 3 天）。

看个人习惯吧，我自己更习惯通过手势操作进行后退。

如果想新增标签页，可以按住 ctrl/command 键来点击新话题，这样会新标签页打开

我之前文章里有提到，通过 nyc 命令可以插桩：

你试下对编译后的 js，用类似的命令插桩下，看看效果？

PS：我这个文章已经是 17 年的了，不确定现在是否还可以用，建议你到 vue 社区里问下，可能会有更好的答案。

有插件可以做到类似效果：https://plugins.jenkins.io/rebuild/（只是网上搜到，实际建议自己试验下）

另外，这个场景听起来，是暴露的参数过多，而实际构建其实只有少数几个典型参数组合场景？

如果是，建议改为两端式的 job。用历史构建的话，如果找不到对应的历史构建，还是解决不了这个问题。

job1：对应少数典型参数组合场景，只需要选少量参数即可满足大部分需求。job1 的实际逻辑是根据参数选择情况，对应推断出 job2 所需的参数，并触发 job2 运行。
job2：就是现在的 job，暴露所有参数，按需自定义。

这里特指的是不碰业务测试的测试开发部门吧。不是所有测开都在这种部门，所以也不是所有测开都干这个事。