本文介绍如何对基于 input() 的 Python 命令行 UI 进行结构化手动测试，涵盖正确路径验证、边界/异常输入防护、状态逻辑覆盖及可重复性实践，确保四个功能选项稳定可靠。
本文介绍如何对基于 `input()` 的 python 命令行 ui 进行结构化手动测试，涵盖正确路径验证、边界/异常输入防护、状态逻辑覆盖及可重复性实践，确保四个功能选项稳定可靠。
开发完一个交互式命令行 UI（如本例中包含 4 个主选项的物流包状态查询系统）后，“写完即运行”远远不够——真正的可靠性来自有目的、有覆盖、有反馈的测试过程。以下是一套专业、可落地的测试方法论，适用于此类基于 while 循环 + input() 的控制台程序。
✅ 一、核心测试策略：三类输入全覆盖
不要只测试“1→2→3→4”的理想流程。必须系统覆盖三类输入场景：
| 类型 | 示例 | 目标 | 预期行为 |
|---|---|---|---|
| 有效输入（Happy Path） | "1", "2" + "08:30:00", "3" + "7" + "10:15:00", "4" | 验证主干逻辑是否按设计输出结果 | 正确打印所有包裹状态、时间切片状态或单包详情；程序优雅退出 |
| 无效输入（Invalid Input） | "0", "5", "abc", " "（空格）, ""（直接回车） | 检验健壮性与容错能力 | 绝不崩溃；应提示错误并重新显示菜单（例如："Invalid choice. Please enter 1, 2, 3, or 4."） |
| 恶意/畸形输入（Edge Case） | "2" 后输入 "ga:me:ov:er"、"24:61:99"、"12:3"（格式错误） | 暴露 split(":") 和 timedelta 构造的脆弱点 | 应捕获 ValueError 或 IndexError，给出友好提示（如 "Time format invalid. Use HH:MM:SS."），并重新请求输入 |
? 关键提醒：当前代码中选项 2 和 3 的时间解析逻辑（checkTime.split(":")）未做异常处理。若用户输入 "12" 或 "12:30"，程序将抛出 ValueError 并中断。务必在 try...except 中包裹时间解析块：
# ✅ 在选项 2 和 3 中添加此结构
try:
hour, minute, second = checkTime.split(":")
rtime = datetime.timedelta(
hours=int(hour),
minutes=int(minute),
seconds=int(second)
)
except (ValueError, IndexError):
print("❌ Invalid time format. Please use 'HH:MM:SS' (e.g., '09:15:30').")
continue # 返回菜单顶部，重试✅ 二、状态逻辑验证：用已知数据驱动测试
UI 的价值在于正确反映业务状态（如 At Hub / En Route / Delivered）。测试时需准备预设的、时间点明确的测试数据：
立即学习“Python免费学习笔记（深入）”；
仅使用 Python 将 Claw Code 虚拟化框架与 OpenClaw 集成，提供 184 种工具和 200 多条命令，用于安全分析和代码质量...
- 假设 pkg1.timeLeftHub0 = "08:00:00"，pkg1.time_delivered = "10:45:00"
- 测试时间点：
- "07:59:59" → 应显示 "At Hub"
- "09:00:00" → 应显示 "En Route"
- "10:45:00" 或 "11:00:00" → 应显示 "Delivered"
⚠️ 注意：原代码中 if checkTime < pkg1.timeLeftHub0: 存在严重缺陷——checkTime 是字符串，而 pkg1.timeLeftHub0 也是字符串，字典序比较不等于时间比较（例如 "10:00:00" < "09:00:00" 为 True！）。必须统一转换为 timedelta 或 datetime 对象后比较：
# ✅ 正确做法：全部转为 timedelta 再比 if rtime < pkg1.timeLeftHub: # 假设 pkg1.timeLeftHub 是 timedelta pkg1.status = 'At Hub' elif rtime <= pkg1.time_delivered: # 注意：<= 覆盖等于送达时刻 pkg1.status = 'Delivered' else: pkg1.status = 'En Route'
✅ 三、提升可测性：小改造，大收益
为便于反复测试，建议在开发阶段加入两个轻量级辅助机制：
- 快速复位功能：在菜单中增加隐藏选项（如 "0"），用于重载测试数据或清空状态，避免每次重启。
- 日志开关：添加全局变量 DEBUG = True，在关键分支插入 print(f"[DEBUG] Option 2 triggered with time: {rtime}")，帮助追踪执行流。
✅ 四、测试清单（Checklist）
每次修改后，快速执行以下 5 分钟验证：
- [ ] 输入 "1" → 观察是否输出 40 行（ID 1–40），末尾含总里程（确认 t1.mileage + t2.mileage + t3.mileage 计算无误）
- [ ] 输入 "2" → 输入 "08:00:00" → 检查前几包是否均为 "At Hub"（根据其 timeLeftHub 判断）
- [ ] 输入 "3" → 输入 "1" → 输入 "09:00:00" → 输出是否含 "Package 1 status at 09:00:00 = En Route"
- [ ] 输入 "9" → 是否提示错误并重新显示菜单？
- [ ] 输入 "2" → 输入 "12:xx:yy" → 是否捕获异常并友好提示？
通过这套方法，你不再“不知道怎么测”，而是拥有一份可执行、可传承、能发现真实风险的测试规程。记住：好的 UI 测试不是证明它能工作，而是证明它在各种意外下依然不会失败。
