QA 与发布保障
软件 QA 与测试
在你的用户发现之前，先找出真正重要的缺陷。我们对普通软件、AI 生成的代码库和 AI 驱动的产品分别采用各自的方式进行测试，并在你发布之前向你展示发布风险。
谁把 QA 工作交给我们
开发人员往往只测试他们构建的路径，因此功能、角色和设备之间的缝隙无人检查。你需要一个独立的视角来判断什么可以安全发布，无论代码是由你的团队、另一家供应商还是 AI 工具编写的。
- 接收由代理机构或自由职业者交付的软件的产品负责人
- 没有专职测试人员、且发布不断破坏旧功能的小型团队
- 准备发布一款主要用 AI 编码工具构建的应用的创始人
哪些测试类型覆盖各条流程
这是面向 Web 产品的示例覆盖计划；您的计划将依据您自己的流程和风险而定。
| API 与集成 | 自动化端到端 | 探索式 | 无障碍性 | |
|---|---|---|---|---|
| 注册与登录 | 深度规划 | 深度规划 | 较轻量或抽样检查 | 深度规划 |
| 结账与支付 | 深度规划 | 深度规划 | 深度规划 | 较轻量或抽样检查 |
| 角色与权限 | 深度规划 | 较轻量或抽样检查 | 深度规划 | 本流程未规划 |
| 账户恢复 | 深度规划 | 较轻量或抽样检查 | 深度规划 | 较轻量或抽样检查 |
| 搜索与筛选 | 较轻量或抽样检查 | 较轻量或抽样检查 | 深度规划 | 较轻量或抽样检查 |
| 报表与数据导出 | 深度规划 | 本流程未规划 | 较轻量或抽样检查 | 本流程未规划 |
- 深度规划
- 较轻量或抽样检查
- 本流程未规划
面向普通、AI 生成和 AI 驱动软件的 QA
软件很少在所有人都盯着看的地方出问题。它会在结账时的某个边缘情况、一项无人测试的权限，或是一处破坏了旧功能的改动中失败。无论你是在准备发布还是运营一款上线产品，我们都会区别对待三种情况。普通软件对照需求和真实用户流程进行测试。AI 生成的代码库会受到额外审视，因为能够运行的代码仍可能做出错误的事情。AI 驱动的产品还需要对其模型行为进行评估。
AI 辅助测试，专家主导的 QA
AI 如何协助
- 根据需求、用户故事和验收标准起草测试用例，供 QA 专家审查和扩充。
- 分析覆盖率，显示哪些流程、角色和错误路径尚无测试。
- 通过阅读日志、追踪记录和近期改动来缩小可能的原因范围，从而加快缺陷调查。
- 当界面、API 或测试数据发生变化时，帮助编写和更新自动化测试。
我们的专家负责什么
- QA 专家根据业务风险和需求来决定测试什么，而不是根据代码恰好做了什么。
- 探索性测试由人来完成，他们会探查边缘情况、异常输入和令人困惑的流程。
- 每一个 AI 起草的测试在加入测试套件之前都会经过审查，薄弱的断言会被重写。
- 缺陷严重程度和发布建议由我们的 QA 负责人掌握，并与你的团队达成一致。
您将获得什么
从测试策略到发布风险报告
测试策略
范围、风险、环境、测试数据和退出标准，并根据你的产品是普通软件、AI 生成还是 AI 驱动进行调整。
基于需求的测试
可追溯到需求的功能测试用例，覆盖业务流程、角色和权限，以及你所支持的浏览器和设备上的错误状态。
探索性测试
专注的手动测试环节，QA 专家像真实用户和粗心输入那样探索新的和高风险的区域，并记录覆盖情况。
自动化回归测试套件
单元、API 和端到端检查，例如使用 Playwright，在你的 CI 流水线中运行，以便在发布前暴露回归问题。
可复现的缺陷报告
每个缺陷都记录在你的追踪工具中，附有复现步骤、预期和实际结果、证据和严重程度，并在修复后重新测试。
发布风险报告
测试了什么、没测试什么、未解决的缺陷和已知风险，并给出明确的建议，以便你的团队做出放行/不放行的决定。
一次 QA 合作如何进行
- 01
评估风险和范围
审查需求、现有测试、过往缺陷以及产品的构建方式。商定范围、环境和测试数据。
- 02
设计测试
AI 起草候选测试用例；QA 专家对其进行审查、填补空白并按风险排定优先级。我们一起选择哪些要自动化。
- 03
测试与调查
运行基于需求的、探索性的和自动化的测试，记录可复现的缺陷，并与工程师一起排查原因和修复。
- 04
报告并保持覆盖率
交付发布风险报告，然后移交测试套件，或作为持续 QA 的一部分保持其时效性。
典型的 QA 需求
我们所界定范围的典型场景，而非客户案例研究。
供应商交接前的验收测试
一家公司即将接收来自外部代理机构的 Web 应用。我们对照商定的需求进行测试，在该公司的追踪工具中记录可复现的缺陷，并在任何人签字之前给出发布风险视图。
快速发布后旧功能被破坏
一个小团队用 AI 编码工具每周发布，而每次发布都会破坏某些原本正常的功能。我们梳理出关键流程，在每次发布前探索风险最高的那些流程，并为每个已确认的缺陷添加一项回归测试。
固定发布日期前的放行/不放行输入
产品负责人已确定上线日期，并列出了一份未解决缺陷清单。我们针对支付、注册和权限进行专项排查，按用户影响程度对每个缺陷评级，并建议哪些必须优先修复；是否上线的决定权仍在他们手中。
QA 不涵盖的内容
- 负载、压力和容量检查不属于功能性 QA——请参阅性能测试。
- 尝试利用安全弱点需要单独的书面授权——请参阅渗透测试或 API 安全。QA 检查权限是否按规定生效。
- 与真实用户进行的可用性会话属于用户测试；QA 对照需求和商定的验收标准来检查产品。
- 在独立的 QA 服务中，由您的开发人员修复缺陷，或在单独的范围下由我们的工程师修复；无论哪种方式，我们都会重新测试。
QA 如何与设计、工程和运营相连接
设计：对照真实流程进行测试
来自设计的用户流程、交互状态和无障碍要求会成为验收标准，因此 QA 检查的是体验，而不仅仅是代码。
工程：在同一循环中修复
缺陷会连同复现步骤一起送达工程师。修复后会重新测试，每个已确认的缺陷都会成为一项回归测试。
运营：发布门禁
自动化套件在你的部署流水线中对发布设立门禁，每次发布后会运行冒烟测试并配合监控。
持续：跟得上的覆盖率
随着你的产品变化，我们会保持回归测试的时效性、移除不稳定的测试并重新审视风险，这些都在与你商定的支持计划之下进行。
常见问题
常见问题解答
你们能测试由我们团队或另一家供应商构建的软件吗？
可以。QA 可以作为与我们的开发合作的一部分，作为针对已有软件单独界定范围的服务，或作为持续的回归覆盖。对于已有产品，我们通常先从一次简短的风险和现有测试评估开始，然后与你商定测试计划。
我们的应用主要是用 AI 编码工具构建的。你们会以不同方式测试什么？
我们从你的需求中推导测试，而不是从生成的代码中推导，因为 AI 编写的测试可能只是确认代码做了什么，而不是它应该做什么。我们还会更仔细地审视生成代码可能会微妙出错的地方：授权、输入校验、错误处理、重复逻辑以及无人选择的依赖项。代码审计通常是一个有用的第一步。
我们的产品有 AI 功能。软件 QA 覆盖它们吗？
它覆盖围绕这些功能的应用部分：登录、支付、权限和集成。AI 行为本身需要另一种测试，包括评估数据集、答案质量和接地检查、工具权限、故障处理，以及当模型或提示词变化时的回归检查。我们将其界定为 AI Evaluation & Testing，与你的 QA 并行开展。
AI 工具会看到我们的代码和测试数据吗？
只在你选择的边界内。使用 私有 / 本地 AI 工程 时，模型运行在你控制的基础设施上，或运行在我们与你商定的隔离环境中。使用 Claude Code / OpenAI Codex 工程 时，商业提供商在工作开始前商定的账户、数据处理和留存条款下处理代码。在可能的情况下，我们使用合成或脱敏数据进行测试，而不是真实的个人数据。
