向Codex请求测试：正常案例、边界条件与失败条件
本文在AI辅助下由原文翻译而成。请结合原文核对专业术语和公式。
请Codex添加测试，可能只生成检查一个正常输入的代码。关键是要保证什么行为，而非测试文件数量。先确定输入、预期结果与失败处理，也更容易判断AI是否只照实现编写测试。
本文用虚构预约数量验证函数示例。数字不是实际产品限额或Codex用量。请求与案例表供读者按项目修改，不表示本文执行了该项目测试。
一览数量验证的正常、边界与失败案例
说明用示意图——并非实际画面或测试结果。
1. 定义函数输入输出契约
2. 编写正常输入与预期结果
3. 区分边界内外
4. 明确其他类型、缺失与失败结果
5. 区分实际执行与未执行项目
1. 测试前先写函数约定
设示例validate_quantity允许整数1至5，其他输入返回验证错误。成功与错误形式应遵循项目实际契约。不是阅读实现后照所得结果写预期，而是先定义读者所需行为。
本例不允许0、6、负数、小数、字符串与缺失输入。是否自动转换看似数字的字符串，也需独立决定。“合适数量就成功”会让Codex猜测何为合适，因此用句子与表明确范围。
OpenAI的Codex代码现代化示例展示计划正常流程与边界案例、整理各场景输入输出。官方提示指南也介绍指定测试函数并要求覆盖正常与边界案例的方法。以下格式为自行将原理应用于小功能的示例。
2. 正常案例应代表使用目的
虚构函数输入3预期成功，是正常案例。但多次用不同名称检查同一中间值，不增加重要条件。应检查返回类型、标准化数量与调用后必要状态等实际用户依赖的结果。
函数只验证，无须检查存储变更；反之，预约API契约要求成功请求保存一次，可一起检查保存数量与响应。区分函数单元测试与经API测试的对象范围，更易找失败原因。
| 区分 | 说明输入 | 契约预期 |
| 正常中间值 | 3 | 成功，保持数量3 |
| 最低允许值 | 1 | 成功 |
| 最高允许值 | 5 | 成功 |
| 低于最小值 | 0 | 验证错误 |
| 高于最大值 | 6 | 验证错误 |
| 类型不同 | 字符串3、小数3.5 | 不转换，验证错误 |
表结果来自所定示例契约。其他服务允许字符串，其表就应不同。编写前未定契约应留为问题或待定，不自动采用AI选择结果作为产品要求。
3. 边界同时看紧邻内外
检查最大5，应同时看5成功与6失败。只确认4成功，可能遗漏实现拒绝5。最小也关联1成功与0失败，体现两侧。测试名或短说明留下边界原因。
数量与日期条件边界单位不同。数量比一个整数间隔，预约时间需定时区、端点包含与输入精度。日期功能检查截止前，应先明确截止时刻。不要将数量表直接移用于全部时间条件。
拒绝小数的契约，1.5也是独立失败条件。只比较不低于最小、不高于最大，可能遗漏类型违约。也检查语言怎样处理布尔与整数，独立决定产品是否接收布尔作数量。
4. 失败条件明确错误内容与后续状态
输入错误时，比起只写失败即可，应定错误形式。抛异常、返回错误对象或API特定响应，测试不同。请Codex阅读项目现有错误处理惯例。
契约要求错误输入不保存时，也检查这一条件。例如虚构预约API可规定验证错误后预约数不增加。只检查错误文字、遗漏保存状态，就只检查了部分预期结果。
也判断是否必须固定整个错误消息。必须保证的错误码应检查；显示文案常变的产品，逐句比较可能增加维护负担。按契约选择检查强度。
5. 制作给Codex的请求
请求包含函数、相关文件、允许输入、预期结果、旧测试位置与执行方法。路径改为实际仓库确认值。可以要求先读现用工具与命令，而非让其推测是否需要安装新测试工具。
请阅读validate_quantity及现有测试，按相同惯例添加测试。契约仅整数1~5成功，不自动转换字符串。区分3、1、5成功，以及0、6、负数、小数、字符串、缺失输入失败。布尔处理与错误形式请确认现有契约，不明确先说明。修改实现以匹配测试前，报告契约与差异。执行相关测试，记录命令、结果与无法执行条件。
该请求不适用全部项目。填写实际不存在函数名或命令，可能无法开始验证。同时确认参数、调用路径与旧依赖准备方式，不把不必要部署纳入范围。
6. 找出只照实现写的测试
阅读Codex测试，确认预期值来自哪里。用待测函数也计算预期，可能把相同错误算两次仍通过。示例范围应来自独立契约表，直接检查输出重要部分。
设想错误实现改为拒绝5。最大允许值测试必须失败，才是在检查范围契约。反之只检查3，可能不暴露错误。思想实验用于检查能捕获什么，并非实际修改代码测试结果。
使用模拟对象时，也读取替代了什么。替代存储的模拟对象不证明外部服务器实际保存。区分确认函数以正确输入请求保存，与确认外部系统实际工作两个目的。
7. 区分执行结果与文件存在
| 报告状态 | 确认依据 | 含义 |
| 编写测试 | 新增代码与条件表 | 检查准备 |
| 发现测试 | 运行器选择的测试列表 | 是否包含目标 |
| 执行通过 | 命令、退出结果与通过数 | 已执行范围结果 |
| 跳过 | 条件与跳过项 | 未验证范围 |
| 无法执行 | 环境错误与原因 | 仍需验证 |
即使命令成功退出，若没选择任何测试，也不是检查了所需条件。读取筛选、执行位置与实际发现数量。依赖缺失阻止执行时，应区分产品代码失败与环境准备失败。
官方提示指南介绍修改后执行相关小测试与检查命令，并报告结果。报告比起只留成功，应留下何命令确认什么，使审查者理解范围。未执行条件不加到完成数。
8. 失败时一起对照契约、测试与实现
失败后，对照实际输入、预期、实际输出与契约表。测试可能用错预期，也可能实现违约。为通过而只改预期为当前结果，会消失原本行为，因此需说明修改依据。
若产品决定改变契约，先记录原因与受影响条件，再更新测试。若是实现错误，修改行为后检查相同失败案例是否解决、附近条件是否保持。旧通过测试出现新失败，也一起查看差异。
最后检查：是否代表正常使用、确认边界两侧、确认失败结果与状态、显示实际执行范围。将所需行为写成契约，并要求独立确认契约，可关联测试目的与Codex结果。
官方来源与撰写标准
资料确认日期：2026-10-07。这是AI依据实际打开的官方资料撰写的说明。单独标注的计算、代码与检查案例用于说明，并非直接测试用户环境或实测结果。发布时重新确认功能与资料是否改变。
为帮助理解本文而制作的原创插画。
Tistory 原文 ↗