# 测试工程师

> 在用户之前找出软件会怎么坏 —— 并且是那个说「能不能发」的人。

网页: https://flyvolo.ai/zh/careers/software-tester
影响指数: 72/100 · 置信度 中等置信度 · 评估于 2026-09-10
这不是失业概率。

## 适用范围

适用于产品软件团队中的手工测试与自动化测试工程师。安全关键领域的认证测试(医疗、汽车、航空)与游戏 QA 情况不同。

## 任务

### 手工回归测试

- 方向: 正在自动化
- 依据: 有证据(附已核实记录)
- 为什么: 脚本化回归本来就可以自动化;变化在于智能体现在能按自然语言描述操作真实界面,并在界面变化时自行修复脚本 —— 这拿掉了过去让团队停留在手工测试上的维护负担。这是大多数 QA 岗位里最大的一块工时,而且走得很快。
- 这还不能说明什么: 这是多数质量保障岗位里耗时最多的一块。在 Uber,原来执行脚本的测试工程师转去为系统构建上下文,公司说的是人员没有同比例增长,而不是减少;剩下的任务能否容纳所有原本把一周花在这上面的人,这里没有确证。
- 记录:
  - 2026-07-30 · 实际部署 · Uber 称,其 AI 移动测试系统在持续集成中不间断运行 1,013 个端到端测试,并把测试工程师从「点击者」变成了为它构建上下文的人 — https://flyvolo.ai/zh/changes/ev-20260730-software-tester-3 (来源: https://arxiv.org/abs/2607.28750)

### 编写测试用例与自动化脚本

- 方向: 正在自动化
- 依据: 有证据(附已核实记录)
- 为什么: 从需求或代码本身生成测试,是代码生成工具最有效的用法之一,过去要一个迭代才能达到的覆盖率现在一个下午就出来了。生成的测试和生成的代码一样浅 —— 它们确认代码「做了什么」而不是「应该做什么」—— 所以下一项任务变得更重要。
- 这还不能说明什么: 生成的测试确认的是「代码做了什么」,不是「代码应该做什么」。用覆盖率而不是缺陷来衡量的团队会认定这件事已解决 —— 那是一个伤害测试人员的度量问题。
- 记录:
  - 2026-01-30 · 实际部署 · Meta 称,其基于大模型的测试生成已部署在持续集成系统中,覆盖率测试生成器已在 Meta 部署两年 — https://flyvolo.ai/zh/changes/ev-20260130-software-tester-4 (来源: https://arxiv.org/abs/2601.22832)
  - 2025-12-31 · 实际部署 · 在字节跳动为期九个月的生产部署中,一个大模型工具生成了 3,196 个接口回归测试用例,工程师采用了其中 2,730 个(85.4%) — https://flyvolo.ai/zh/changes/ev-20251231-software-tester-5 (来源: https://arxiv.org/abs/2607.24000)
  - 2024-02-14 · 试点 · Meta 报告在 Instagram 与 Facebook 的测试马拉松中部署 TestGen-LLM:被应用的类中 11.5% 得到改进,工程师将其 73% 的推荐测试用例接受进入生产 — https://flyvolo.ai/zh/changes/ev-20240214-software-tester-1 (来源: https://arxiv.org/abs/2402.09171)

### 探索性与对抗性测试

- 方向: 仍由人主导
- 依据: 有证据(附已核实记录)
- 为什么: 生成的测试来源于需求或代码,所以和它们有同样的盲区。找出没人想到的失败,需要一个关于真实用户和真实系统如何出错的模型,它来自对这个产品、这个领域的经验。工具扩大了搜索范围;「往哪找」的假设仍然是人的,而昂贵的 bug 就在那里。
- 这还不能说明什么: 「该往哪里找」的直觉,是靠做那些正在消失的回归工作练出来的。护住这项任务的是一种流水线不再生产的经验。
- 记录:
  - 2026-04-14 · 限制或撤回 · 一项针对 200 位 SRE 与 DevOps 负责人的调查显示:43% 的 AI 生成代码变更在通过 QA 与预发布之后,仍需在生产环境手工调试 — https://flyvolo.ai/zh/changes/ev-20260414-software-tester-2 (来源: https://venturebeat.com/technology/43-of-ai-generated-code-changes-need-debugging-in-production-survey-finds)

### 决定能不能发

- 方向: 仍由人主导
- 依据: 有证据(附已核实记录)
- 为什么: 这是一个有组织后果的担责决定,团队没有表现出任何委托它的意愿。看板汇总状态;而「这次发布、这批客户、这一周能承受多大风险」的判断,由一个团队信任其判断的人来做。
- 这还不能说明什么: 在很多团队里,这个决定属于研发经理,不属于测试。在那些团队里,护住它护住的是别人的工作。
- 记录:
  - 2026-04-14 · 限制或撤回 · 一项针对 200 位 SRE 与 DevOps 负责人的调查显示:43% 的 AI 生成代码变更在通过 QA 与预发布之后,仍需在生产环境手工调试 — https://flyvolo.ai/zh/changes/ev-20260414-software-tester-2 (来源: https://venturebeat.com/technology/43-of-ai-generated-code-changes-need-debugging-in-production-survey-finds)

### 测试内含模型的系统

- 方向: 新出现的任务
- 依据: 有证据(附已核实记录)
- 为什么: 大多数新产品有模型在环,无法用「断言固定输出」来测试。评测设计、对抗性提示、行为回归是一门从业者稀少的新学科,而 QA 的思维方式 —— 假定它坏了、找出怎么坏的 —— 可以直接迁移。
- 这还不能说明什么: 「从业者很少」是对当下的描述。这门学科还太年轻,最终会有多大没人知道 —— 它也可能最后长在模型团队里,而不是 QA 里。
- 记录:
  - 2025-04-03 · 政策推动 · 根据 OMB M-25-21,美国联邦机构必须在部署前测试高影响 AI —— 拿不到模型时就查询服务、观察输出 —— 部署后还要继续测试 — https://flyvolo.ai/zh/changes/ev-20250403-software-tester-7 (来源: https://www.whitehouse.gov/wp-content/uploads/2025/02/M-25-21-Accelerating-Federal-Use-of-AI-through-Innovation-Governance-and-Public-Trust.pdf)
  - 2024-10-31 · 实际部署 · 微软 AI 红队称,已对 100 多个生成式 AI 产品开展 80 多次行动,并表示自动化不应被用来把人排除在环节之外 — https://flyvolo.ai/zh/changes/ev-20241031-software-tester-6 (来源: https://arxiv.org/abs/2501.07238)

## 怎么引用

- 单位是任务,不是职位名:说哪些任务在变、哪些不变。
- 每项任务的依据与限制要一起带上;推断不是结论。
- 本页不给年份。不要从中推出一个。
- 更多: https://flyvolo.ai/llms.txt