Codex 自动测试与代码审查：从覆盖边界到 /review
Codex 可以帮助编写测试和审查代码，但质量取决于范围、证据和验收标准。不能简单输入“补一下测试”或“看看有没有问题”。
1. 测试的目标不是追求行数
高质量测试应该覆盖：
- 用户或系统行为；
- 关键边界；
- 已知回归风险；
- 错误分支；
- 权限；
- 并发和状态变化。
不应只为了提高覆盖率复制大量低价值断言。
2. 让 Codex先理解现有测试体系
先不要修改代码。
分析当前项目的测试体系：
- 使用哪些测试框架；
- 单元、集成、E2E 分别放在哪里；
- 如何运行单个文件；
- Fixture、Mock 和测试数据的约定；
- 找出与目标模块最接近的 3 个测试示例。
这样可以避免 Codex引入新的测试风格或错误命令。
3. 为纯函数补测试
为 calculateInvoiceTotal 添加单元测试，不修改生产实现。
覆盖：
- 无折扣；
- 百分比折扣；
- 固定金额折扣；
- 折扣超过小计；
- 税费顺序；
- 小数舍入；
- 空项目；
- 非法负数。
使用项目现有测试框架和命名风格。
运行最小测试并汇报实际结果。
如果测试暴露现有 Bug，先报告，不要自动修改生产代码，除非任务明确授权。
4. 为 Bug 添加回归测试
先添加一个能复现 Issue #123 的回归测试。
确认测试在当前代码上失败，并说明失败原因。
不要修改生产代码，直到失败被确认。
然后：
现在做最小修复，使回归测试通过。运行受影响模块的已有测试。
这可以证明测试不是“修复后才写、无论如何都会通过”的形式测试。
5. 组件测试
前端组件测试应验证行为，而不是内部实现。
为删除确认对话框补充测试：
- 点击删除打开对话框；
- 点击取消不调用 API；
- 点击确认调用一次 API；
- 请求中按钮禁用；
- 失败显示错误；
- 成功关闭对话框并刷新列表。
优先通过可访问角色和文本查找元素，不依赖脆弱 className。
6. API 测试
为 POST /orders 添加接口测试：
- 正常创建；
- 未登录；
- 无权限；
- 参数缺失；
- 重复幂等键；
- 数据库失败时不产生部分写入。
复用现有测试数据库和认证 Fixture。
API 测试应验证状态码、响应结构、数据持久化和权限副作用。
7. E2E 测试
E2E 适合覆盖关键用户路径，而不是所有细节。
为“用户完成首次购买”增加一个 E2E 场景：
登录 -> 选择商品 -> 创建订单 -> 模拟支付成功 -> 订单页显示已支付。
要求：
- 复用现有登录状态；
- 不依赖真实支付服务；
- 使用稳定选择器；
- 确保测试数据清理；
- 记录运行命令。
8. 要求实际执行测试
运行测试，并输出：
- 完整命令；
- 退出码；
- 通过/失败数量；
- 关键错误；
- 未运行的测试及原因。
不要接受“预计通过”。Codex必须基于工具输出报告。
9. 测试失败时如何处理
先分类：
- 新功能真实错误；
- 测试本身错误；
- 环境缺失；
- 原有基线失败；
- 偶发测试；
- 与任务无关的完整套件失败。
Prompt：
不要立即修改断言。先判断失败属于生产代码、测试代码、环境还是原有基线。
给出证据和最小复现。
10. 进入代码审查
在 Git 仓库中使用：
/review
官方支持的常见范围：
- Review against a base branch；
- Review uncommitted changes；
- Review a commit；
- Custom review instructions。
审查模式会使用独立 Reviewer 检查 Diff，并通常不会修改工作树。
11. 审查未提交改动
/review
选择：
Review uncommitted changes
它会包含暂存、未暂存和未跟踪文件。审查前先检查：
git status
避免把无关本地修改混入 Review。
12. 与基础分支比较
选择：
Review against a base branch
通常用于 PR 风格审查。它根据 merge base 审查当前分支相对基础分支的变更。
开始前确认：
git branch --show-current
git fetch origin
git log --oneline --decorate -5
基础分支过旧会使审查范围不准确。
13. 自定义审查标准
通用：
/review
重点检查逻辑错误、边界条件、错误处理和缺失测试。
安全：
/review
重点检查身份认证、授权绕过、输入验证、Secret 泄露、注入和不安全默认值。
并发：
/review
重点检查竞态、重复执行、事务边界、幂等、锁和异步资源清理。
兼容性：
/review
重点检查公共 API、数据库 Schema、配置文件和旧客户端兼容性。
14. 如何阅读 Review 结果
每个有效发现应包含：
- 严重等级；
- 文件和位置；
- 触发条件；
- 造成的实际影响；
- 为什么当前测试没有覆盖；
- 可行修复方向。
让 Codex补充证据：
对每个发现给出最小触发案例。无法从代码证明的内容降为建议，不要当作确定 Bug。
15. 不要自动接受所有发现
AI Review 会有误报。处理流程：
- 人工理解触发条件；
- 在代码或测试中复现；
- 判断是否在当前任务范围；
- 确认后修复；
- 添加测试；
- 再次 Review。
先验证 P1 和 P2 发现。只修复可以复现或从代码直接证明的问题。
16. 修复后复审
/review
或：
重新审查当前未提交改动，确认之前的并发和空值问题已经解决，并检查修复是否引入新回归。
17. 配置独立 Review 模型
官方代码审查页面说明，可在 config.toml 中设置：
review_model = "<available-review-model>"
具体可用模型以账户和当前版本为准。日常开发模型和深度审查模型可以分开，但不要为了形式而增加不必要成本。
18. 自动化审查思路
codex exec 可用于脚本或 CI：
codex exec --profile deep-review \
"Review the current branch against main. Focus on correctness and security."
自动化时应明确：
- 只读沙箱；
- 禁止网络或限制网络；
- 固定输出格式；
- 哪些严重等级导致 CI 失败；
- 如何避免误报阻断发布；
- 保存日志和审查报告。
也可以使用官方 GitHub Action 把 Codex反馈接入 PR 或发布流程。
19. 测试与审查组合流程
推荐顺序：
- 开发前识别测试框架；
- 为需求或 Bug设计测试；
- 实现代码；
- 运行最小测试；
- 运行类型检查和 Lint；
- 查看 Git Diff；
- 使用
/review； - 验证 Review 发现；
- 修复并补测试；
- 再次 Review；
- 运行提交前完整检查。
20. 最终质量报告模板
## Tests added or changed
- 文件：
- 覆盖行为：
## Commands executed
- 命令：
- 结果：
## Review
- 范围：
- 已确认发现：
- 已修复：
- 未处理及原因：
## Remaining risk
- 未覆盖环境：
- 手工验收：
- 后续监控：
官方参考
- https://learn.chatgpt.com/docs/code-review
- https://learn.chatgpt.com/docs/prompting
- https://learn.chatgpt.com/docs/codex/cli
- https://learn.chatgpt.com/docs/developer-commands?surface=cli
- https://learn.chatgpt.com/docs/codex/github-action
资料核对日期：2026-07-14。