三个测试层级,三个不同的问题

每个测试层级在软件开发中都扮演特定的角色,并回答一个不同的问题:

单元测试(Unit Tests) - "某个本应保持不变的函数是否发生了变化?" 它们独立于系统其余部分,测试最小的孤立代码片段(单个函数或方法)。(关于单元测试的详细分析见另一篇博客文章。)

集成测试(Integration Tests) - "变更之后,各组件是否仍能正确地协同工作?" 它们测试模块之间的真实连接(例如数据库 + 服务层 + API),而不仅仅是孤立的函数。它们能发现这样的场景:各个部分单独运行都能通过,组合在一起却失败。

E2E(端到端)测试 - "系统对真实用户来说是否正常运行?" 它们通过真实的 UI 或 API 模拟完整的用户工作流(登录 → 操作 → 结果)。它们能捕获单元测试和集成测试都无法发现的回归,因为这些问题只有在真实工作流中才会浮现。

(当然还有其他类型的测试,例如 *冒烟测试(Smoke tests)**、负载测试或安全测试,它们不在本文讨论范围之内。)*

所有自动化测试层级有一个共同的目标:验证在当前任务范围之外,功能没有被破坏。一个任务可能完全按照规格完成,却仍然作为意外的副作用破坏了其他东西。如果没有一个超出具体变更范围的测试层,在用户于生产环境中报告问题之前,没有人会注意到。

手动测试的重要作用

尽管有先进的自动化和 AI 集成,手动测试依然保持着不可或缺的首要地位。人类测试员带来真正的判断力、直觉,以及发现自动化脚本很容易漏掉的细微差别或意外 UI 行为的能力。手动验证过去是、现在是、将来也永远是让开发团队对应用已为真实用户做好准备拥有 100% 信心的依据。

在 AI 辅助开发的时代,自动化测试层更加关键。AI agent 无法一次性感知整个系统,因此与掌握完整上下文和过往决策历史的人类开发者相比,更容易出现副作用。测试是一种机制,用来在代码到达最终的人工批准之前,系统性地弥补这种系统盲区。

创建 E2E 测试对 AI 来说尤其复杂。这不仅仅是编写测试脚本本身,更主要的是准备合适的测试数据,以便软件能够使用它(通常只用于测试的一小部分)。准备这些数据要求非常高。

考虑一个看似简单的操作:点击下拉列表并选择一个参数(例如文档类型发票)。如果测试失败或没有完成,准确诊断根本原因至关重要。可能发生了各种情况:

仅一个下拉列表就可能出现许多问题。关键在于 AI(或评估系统)能否区分真正的 bug 与由其他原因引起的连锁失败。数据成功保存并不保证一切运转正常。

因此,测试应始终聚焦于系统的行为层面,测试我们实际期望发生的事情:

其他可能性较小的组合不会预先测试。如果它们在生产环境中出现,会被即时修复,或通过软件约束和校验加以预防(例如在输入有效之前禁用导航)。

在 AITM 中,对于影响 UI 的任务(由任务类型/意图决定),E2E 测试是一个明确的强制 pipeline 阶段。它不是在截止日期临近时可以跳过的可选附加项——没有它,pipeline 无法被标记为完成。

如果缺少 E2E 测试或环境不可用,构建默认会失败(只有极少数例外允许 E2E 失败时继续)。此外,每次 E2E 执行都会捕获截图,并显示在任务结果中。

E2E 目前的工作方式:

E2E 未来路线图:

流程地图(Flow Maps)- 系统构建通往指定元素的路径地图,并直接关联到业务逻辑(已集成在 AITM 中)。
自主导航(Autonomic Navigation)- 测试读取实时路径地图,精确知道在哪里点击、输入和验证(目前正在测试中)。
状态对比(可视化差异)- 每一步都会在代码修改前后截图记录,以确认预期的元素和数据与数据库或 UI 的预期相符。
业务逻辑验证 - 自动检查预期的输出数据(例如经过验证的发票合计——目前正在开发中)。
夜间集成运行(Nightly Integration Runs)- 端到端集成测试将根据步骤状态和软件需求自动生成,并在夜间运行。任何失败都会生成任务或请求人工验证(因为 AI 可能出错,需要人工签字确认)。
高级场景(Advanced Scenarios)- 未来版本将加入无效参数注入、多实例并发测试和边界情况模拟。

有效 E2E 测试的本质在于管理地图和数据实体关系。对于 90% 的软件,它归结为标准的生命周期:

#AITM #Data Input Validation #E2E #Integration test #AI TESTING