请我们做自动化的团队
每次发布都需要同样的检查，但手动运行既缓慢又会在截止期压力下被跳过。与此同时，一个随机失败的套件会教会团队忽视红色的构建。
- 频繁发布但仍在手动点击完成回归检查的团队
- CI 套件缓慢、不稳定或被反复重跑直到变绿的工程负责人
- 使用 AI 编码智能体、拉取请求（pull request）速度超过手动测试的团队
各套件分别在何时运行
这是一个 Web 产品的典型时间安排；具体划分取决于你的流水线必须保持多快。
| 每个拉取请求（pull request） | 每晚 | 发布前 | 部署后 | |
|---|---|---|---|---|
| 单元测试 | 运行并为该步骤设置关卡 | 此时不运行 | 运行并为该步骤设置关卡 | 此时不运行 |
| API 与契约测试 | 运行并为该步骤设置关卡 | 运行并为该步骤设置关卡 | 运行并为该步骤设置关卡 | 此时不运行 |
| 端到端冒烟测试 | 运行并为该步骤设置关卡 | 运行并为该步骤设置关卡 | 运行并为该步骤设置关卡 | 运行并为该步骤设置关卡 |
| 完整端到端回归 | 子集，或仅做报告 | 运行并为该步骤设置关卡 | 运行并为该步骤设置关卡 | 此时不运行 |
| 视觉对比 | 子集，或仅做报告 | 此时不运行 | 运行并为该步骤设置关卡 | 此时不运行 |
| 第三方沙箱检查 | 此时不运行 | 运行并为该步骤设置关卡 | 子集，或仅做报告 | 此时不运行 |
- 运行并为该步骤设置关卡
- 子集，或仅做报告
- 此时不运行
捕获回归问题而非噪音的自动化
只有当你的团队信任测试套件时，它才有帮助。缓慢、不稳定或浅层的测试会被忽视，回归问题就会漏过去。对于频繁发布或仍依赖人工检查的团队，我们会围绕你的需求和风险最高的流程来设计自动化，然后构建可在你的 CI 流水线中运行的单元、API 和端到端测试。当代码由 AI 工具编写时，这一点更为重要：变更来得更快，而生成的测试可能只是确认代码做了什么，而非它应该做什么。
AI 辅助编写测试，由工程师审查
AI 如何协助
- 根据需求、API 规格和现有代码起草单元、API 和端到端测试，供工程师审查。
- 将覆盖率报告与你的关键流程和近期变更进行比对，以显示缺少测试的地方。
- 利用运行历史、日志和追踪调查不稳定和失败的测试，并提出可能的原因。
- 当界面或 API 发生变化时，更新选择器、测试夹具（fixtures）和测试数据，并以经过评审的拉取请求（pull request）形式提交。
我们的专家负责什么
- 由工程师决定哪些内容归入快速单元测试，哪些需要集成测试或端到端测试覆盖。
- 每一个生成的测试都会检查是否包含有意义的断言；仅仅照搬代码的测试会被重写。
- 由 QA 工程师决定哪些检查会阻止合并或发布，哪些只做报告。
- 不稳定（flaky）的测试会被有意地修复或隔离，而不是反复重试直到碰巧通过。
您将获得什么
一套可在你的流水线中运行的测试套件
自动化策略
确定自动化什么、在哪个层级、使用哪些工具，例如 Jest、Vitest、pytest、Playwright 或 Cypress，选型以契合你的技术栈和团队为准。
单元测试和集成测试
针对业务规则、数据访问和服务边界的快速检查，配以你的开发人员能够维护的测试数据和模拟（mock）。
API 与契约测试
依据你的 API 规范检查请求、响应、错误和权限，包括你与第三方服务之间的契约。
端到端旅程测试
针对注册、结账、角色及其他关键流程的浏览器测试，并在布局重要之处配以截图、追踪（trace）和视觉对比。
CI 流水线集成
测试套件在拉取请求（pull request）上以及发布前，在 GitHub Actions、GitLab CI 或你当前的流水线中运行，并带有清晰的通过与失败关卡。
测试健康度报告
关键流程的覆盖情况、不稳定测试（flaky-test）跟踪以及失败趋势，让你能够看清该测试套件是否值得团队信任。
我们如何构建你的测试套件
- 01
审计当前的测试
审查现有测试、CI 配置、覆盖率和失败历史，并找出一旦出现回归就损害最大的那些流程。
- 02
商定方法
选择测试层级、工具和关卡，商定约定规范，并搭建你的团队可复用的测试数据和环境。
- 03
构建关键覆盖
AI 起草测试，工程师进行评审和打磨。先覆盖关键路径，然后按风险逐步扩展覆盖范围。
- 04
运行、报告、维护
测试套件在 CI 中运行并附带报告。我们会连同文档一起移交，或在持续 QA 中保持其处于最新状态。
典型的自动化需求
我们所界定范围的典型场景，而非客户案例研究。
一个没人信任的不稳定套件
某团队的浏览器测试在这一次运行时通过、下一次却失败。我们把共享测试数据和时序问题与真正的缺陷区分开来，从源头修复测试，并商定哪些检查可以阻止合并。
每次发布前耗费数日的手动回归
某产品团队在发布日花时间反复点击同样的流程。我们在最低的可靠层级上自动化关键路径——先做单元或 API，只有在旅程确实需要时才用浏览器——并把它们作为发布关卡运行。
针对智能体编写的拉取请求（pull request）的关卡
某团队让一个 AI 编码智能体开启拉取请求（pull request）。我们加入必需的检查，使智能体的改动面对与人工改动相同的单元测试、契约测试和冒烟测试，并且每次合并仍由人来批准。
自动化工作不包括什么
- 探索性测试和发布风险建议随《软件 QA 与测试》提供；本服务负责构建和维护自动化检查。
- 搭建或迁移 CI 平台本身属于 DevOps 与 CI/CD 工作；我们只是把套件接入你已经在运行的流水线。
- 负载测试和耐久测试需要各自专门的工具和环境——参见《性能测试》。
- 依据评测数据集为 LLM 的回答打分是另一门学科——参见《AI 评估与测试》。
自动化如何契合设计、QA 和运维
设计：值得测试的状态
设计中的空状态、加载状态、错误状态和权限被拒状态会成为明确的测试用例，这样它们在页面变化时仍能持续正常工作。
QA：自动化加上探索
自动化处理可重复的检查，使 QA 专家能够把时间花在探索新功能上。每一个被确认的缺陷都会获得属于它自己的回归测试。
运维：清晰的发布信号
测试套件在发布前于部署流水线中运行，发布后再运行冒烟测试（smoke test），为 DevOps 提供清晰的信号，决定是继续推进还是回滚。
持续：保持套件处于最新状态
我们会随着功能变化更新测试、淘汰过时的测试并跟踪不稳定性，作为与你商定的持续 QA 计划的一部分。
常见问题
常见问题解答
我们应该使用哪个测试框架？
通常是最契合你的技术栈和团队的那一个：JavaScript 和 TypeScript 用 Jest 或 Vitest，Python 用 pytest，浏览器测试用 Playwright 或 Cypress。对已经适合你的工具我们会保留，只有在有明确理由时才会更换。
我们需要多少测试覆盖率？
单看一个覆盖率数字是一个很弱的目标。我们从关键流程、业务规则和过往缺陷入手，报告这些方面覆盖得如何，而不仅仅是代码行数。一个断言薄弱的高分几乎保护不了什么。
你们能为遗留代码或 AI 生成的代码添加测试吗？
可以。我们从特征化测试（characterization test）入手，记录当前行为，将该行为与你的需求进行对比，并把差异标记为缺陷或待解问题。随后在有测试护航的情况下进行重构。无论代码是由人编写还是用 AI 工具生成，方法都是一样的。
AI 工具在编写测试时会看到我们的源代码吗？
仅在你所选择的边界之内。采用私有 / 本地 AI 工程时，模型运行在你所掌控的基础设施上，或运行在我们与你商定的隔离环境中。采用 Claude Code / OpenAI Codex 工程时，商业提供商会在开始工作前商定的账户、数据处理和留存条款下处理代码。
