用Codex解决测试失败：错误日志与请求示例

摘要： 请求解决测试失败时，应同时提供执行命令、失败日志、预期行为与修改边界。应区分让测试通过，与功能正确运行。

1. 不要把所有测试失败视为同一种问题

失败界面可能混有不同问题：验证值与预期不同、无法加载模块、测试命令本身没有执行，起点各不相同。如果断定“出现红字，所以函数有错”，可能不必要地修改代码。

先确认执行进展到哪一步。区分测试案例已执行并在值比较时失败，还是更早就找不到工具或配置。如果知道仅本地失败，还是CI也相同，应一并提供背景。尚未确认时，应标注未确认，而不推测“CI正常”。

2. 向Codex提供的最少信息

OpenAI官方错误修复指南说明了包含复现步骤、约束与修改后确认的请求。测试问题也适合提供已运行命令与复现条件。下方是将该原则应用于测试失败调查的自编检查清单。

• 项目中运行的准确命令与工作文件夹
• 失败测试名称与关键错误信息
• 关于正确行为的要求
• 近期变更与需保留的功能
• 是否实际确认了本地与CI的差异

优先分享首个错误的相关日志。检查是否混入令牌、密码或个人信息，删除不必要秘密值。只提供最后“失败”句子，可能遗漏前方指出原因的部分；反之，无说明地粘贴数千行日志，也会增加查找相关信息的负担。

3. 针对假想失败的请求模板

가격 합계 계산 테스트가 실패합니다.
실행 명령: [실제로 사용한 명령]
실패 테스트: [실제 테스트 이름]
핵심 로그: [민감정보를 제거한 오류 내용]
기대 동작: 수량이 0인 항목은 합계에 포함하지 않습니다.
최근 변경: 수량 입력 검증을 수정했습니다.

원인부터 조사하고 코드 오류와 환경 오류를 구분해 주세요.
공개 함수의 입력·반환 형식은 유지해 주세요.
통과만을 위해 기대값을 바꾸거나 테스트를 삭제하지 마세요.
수정 후 같은 명령과 관련 검증을 실행하고 결과를 보고해 주세요.
실행하지 못한 검증은 이유와 함께 표시해 주세요.

方括号应填入实际信息。如果不知道价格计算的正常规则，可请求检查需求文档或现有调用位置。测试预期值不一定总正确，实现也不一定总正确，需要判断应修改哪一方的标准。

4. 修改后重新确认同一失败

首项验证应回到原先失败的命令。其他测试通过，并不能证明旧问题解决。需要确认失败案例现在通过，以及相关正常案例保持正常。按变更可能影响的范围增加验证。

例如修改数量0的处理后，也可考虑确认正常数量、多项合计与错误数量处理。需要哪些案例取决于项目要求。结果报告应明确区分“已执行”“已通过”与“因环境无法执行”。新建测试这一事实，也不同于测试执行结果。

5. 持续失败时需要确认的问题

• 失败位置改变了吗？ 区分并比较新错误与旧错误。
• 环境准备好了吗？ 检查必要工具、依赖与本地配置。
• 依赖外部服务吗？ 区分连接失败与功能错误。
• 只是偶尔失败吗？ 保留复现条件与执行记录，不要断定原因。
• 测试变弱了吗？ 审查更改预期值或删除验证是否符合要求。

从PR失败检查开始工作的流程，也见于官方代码审查文档。诊断内容可能因检查服务不同而异，应区分界面仅显示失败状态，还是能访问实际日志。

6. 从错误信息选择下一调查位置

不要试图从头解释全部长日志，应先找测试停在哪一阶段。按命令启动、配置读取、依赖加载、测试执行与结果比较划分，调查位置就会不同。下方错误表达仅用于说明类型，实际工具文字与环境可能不同，应依据自己的首个错误判断。

试图靠修改函数解决命令错误，或只靠重装解决值比较错误，可能遗漏原失败。应询问Codex提出的行动对应日志的哪一阶段。有多个问题时，先解决阻止首次运行的原因，再阅读下一失败。日志变化不一定表示情况变差，也可能是通过前一阶段后发现了下一问题。

7. 将假想合计测试整理为复现信息

以下是假想案例，用于说明数量0的问题，并非真实项目的测试执行记录。假设JavaScript项目的npm test配置为运行Vitest，且存在tests/total.test.js。不满足这些条件的项目，不能直接使用下方文件名或命令。

실행 폴더: C:\Projects\cart-demo
실행 명령: npm test -- tests/total.test.js
실패 사례: 수량 0 항목은 합계에서 제외
가상 비교 로그:
Expected: 0
Received: 1200
입력: [{ price: 1200, quantity: 0 }]

如果调查的函数如下所示，将0变成默认数量1的部分就是原因候选。可通过阅读计算路径作出说明，但要确认是否与真实项目失败同因，需要连接测试输入与调用位置。若测试加载了其他函数，或根据配置使用不同实现，只修改此代码后原失败也可能保留。

function sumCart(items) {
  return items.reduce((total, item) => {
    const quantity = item.quantity || 1;
    return total + item.price * quantity;
  }, 0);
}

确定修改方向时，还需检查值缺失的既有政策。如果“缺少数量时采用1”是预期，就需区分0与缺失。负数或字符串输入在哪个层级检查，是另一个要求。应确定范围，避免修复本次失败时，擅自增加数字转换与数据格式变更。

실패 입력이 실제로 호출하는 함수를 찾아 주세요.
수량 0과 값 누락을 현재 코드가 어떻게 구분하는지 설명하세요.
기존 요구사항과 테스트의 기대값이 맞는지 먼저 확인하세요.
그 근거를 바탕으로 최소 수정하고 원래 실패 명령을 다시 실행하세요.
입력 형식이나 다른 수량 정책을 임의로 새로 정하지 마세요.

8. 连同失败案例周边的正常行为一起检查

如果为了让一个案例通过，把所有数量都按0处理，失败测试虽通过，功能却被破坏。因此修改后应同时检查原失败与相近正常案例。下表是基于假想合计要求的验证设计。未确定政策应保留为需求确认项，而不是编造答案。

先重新运行原失败案例并执行相关验证，再按修改影响开展项目必需检查。小函数修改宜遵循已有验证流程，而不是新装无关工具。反之，修改多处调用的公共函数时，也应确认各调用位置的预期行为。

修改测试代码时，应阅读差异，确认改了什么。弱化输入条件、删除验证语句或skip测试后报告通过，并不能证明原问题解决。如果需求本身改变，可以留下依据并修改验证以检查新政策。实现与测试哪一方正确，应由产品规则决定。

9. 调查本地与CI差异以及偶发失败

本地通过而CI失败时，可用表格比较运行环境。只记录实际确认的版本与命令，未查看的CI配置标为未确认。操作系统差异可能暴露文件大小写或路径处理问题，时区、环境变量与服务准备状态也可能影响结果。但不能把所有可能性都断定为原因。

로컬 통과와 CI 실패를 비교해 주세요.
각 환경의 실제 실행 명령, 작업 폴더, 런타임 버전,
설정 파일, 필요한 서비스의 준비 조건을 근거와 함께 정리하세요.
첫 오류가 같은지 비교하고 차이와 실패 사이의 연결을 조사하세요.
확인되지 않은 환경 정보는 추측하지 마세요.

偶发失败的起点是收集成功与失败运行的差异。记录执行顺序、并行测试、共享数据与依赖时间的输入等。一律延长等待可能隐藏症状，因此应先说明在等待什么。仅特定顺序失败时，也可调查前一测试留下的状态是否影响后续测试。

이 테스트는 가끔 실패합니다.
실패한 실행과 성공한 실행의 로그를 각각 제공합니다.
차이를 비교하고 재현 가능한 조건부터 좁혀 주세요.
대기 시간 증가나 무조건 재시도보다 실패 원인의 근거를 우선 찾으세요.
원인을 확정하지 못하면 추가로 수집할 정보와 다음 실험을 제안하세요.

最终结果应保留原命令结果、相关正常案例与必要后续验证。未复现原失败就修改时，应说明该限制。读取CI日志，与实际重新运行CI并通过，是两回事。报告明确区分后，下一负责人才能在相同条件下继续调查。

10. 常见问题

可以只删除失败测试吗？ 先确认测试原本保证什么。产品规则变化时，可留下依据并修改验证；但为隐藏失败而删除，不能证明解决。

通过一次就完成吗？ 不稳定失败难以仅凭一次成功确定原因，应同时确认发生条件与修改依据。

无法执行怎么办？ 获取必要环境与未确认事项的报告，在可执行环境中继续同一流程。不能将未执行测试表述为已通过。

官方来源与确认日期： OpenAI官方文档：提示词——修复错误 · OpenAI官方文档：代码审查——失败检查。2026年10月3日确认。示例应按自己的项目与当前功能调整。