AI 生成测试用例需要什么输入
如果需求只写“功能正常”或“体验良好”，就无法形成可判定的断言。应先改写为前置状态、输入、操作、预期结果和异常处理。
- 可验证的需求或验收条件。
- 接口定义、字段约束、错误码和状态变化。
- 关键业务规则及禁止发生的结果。
- 正常、边界和已知失败样本。
- 运行环境、依赖版本和外部服务处理方式。
- 本次变更范围以及已有测试。
不同测试层级中 AI 的作用
- 单元测试：可扩展边界值、异常分支和参数组合；需要确认断言对应真实业务规则，而不是只匹配当前实现。
- 接口测试：可草拟请求组合、状态码、字段校验和权限反例；需要复核接口契约、幂等、并发和数据清理。
- 集成测试：可补充跨模块流程和依赖失败场景；需要确认真实依赖版本、超时和补偿逻辑。
- 端到端测试：可覆盖关键用户流程；应控制数量与稳定性，避免全部堆进快速流水线。
- 设备与现场测试：AI 可辅助整理输入组合和复测步骤，但真实功耗、温度、网络和硬件差异必须在目标环境验证。
从候选用例到 CI 门禁的六个步骤
- 把需求改写成可测试条件；涉及性能时说明数据量、并发、硬件、网络和统计口径。
- 先列数据错误、权限越界、重复提交、依赖失败、资源不足和版本兼容风险，再按目标生成候选用例。
- 审核断言是否真正区分正确与错误结果，防止固定样例、宽松匹配或错误模拟造成假通过。
- 准备可初始化、可清理且来源合规的数据，并记录 CI 环境与目标环境差异。
- 提交阶段运行快速检查，合并阶段运行接口与集成测试，发布前完成关键端到端、迁移、回退和目标环境测试。
- 门禁失败要能定位测试、变更和日志；不稳定测试应修复、隔离或删除，不能依靠反复重跑。
如何判断生成的测试是否有价值
- 覆盖新增或修改的业务规则，并包含正常、边界、异常和权限反例。
- 人为注入错误时能够失败，且失败信息指向具体条件。
- 能在清洁环境中重复执行，维护成本与所保护风险匹配。
- 减少后续人工回归或缺陷重开，而不是只增加测试代码量。
- 覆盖率只能作为线索；高覆盖率仍可能遗漏错误断言、跨模块状态和真实环境问题。
常见失败方式
- 测试复制实现逻辑，业务代码与测试共享同一错误假设。
- 只验证正常路径，遗漏空值、边界、重复请求、权限不足、依赖超时和恢复流程。
- 模拟过多，未验证数据库、网络、第三方服务、设备和部署环境差异。
- 不稳定测试长期依靠重跑通过，持续消耗排查时间并削弱门禁可信度。
AI 能自动生成完整测试集吗？
不能默认认为可以。AI 可根据现有信息扩展候选用例，但业务正确性、风险优先级、真实数据和环境差异仍需工程人员确认。
生成测试后是否还需要测试人员？
需要。测试人员或承担测试职责的工程人员仍需设计风险模型、审核断言、准备环境、分析失败并决定放行。生成工具主要减少重复准备工作。
所有测试都应该阻止合并吗？
不一定。稳定、快速且与本次变更直接相关的检查适合作为提交或合并门禁；耗时的端到端和设备测试可分阶段执行，但发布前必须完成约定验证。
CI 通过是否说明系统可以上线？
不能直接说明。还要确认部署配置、数据迁移、第三方依赖、权限、监控、回退和目标环境复测。CI 是证据的一部分，不是全部验收结论。
参考依据与适用边界
- NIST Secure Software Development Framework（SSDF）：https://csrc.nist.gov/pubs/sp/800/218/final
- DORA 生成式 AI 与软件开发研究：https://dora.dev/ai/gen-ai-report/report/
- 门禁层级和阈值需要根据系统风险、技术栈、目标环境和双方确认的验收标准设定。