给失败结果分类：让超时、崩溃与输出不符进入不同处理路线
测试面板上的失败可能来自不同层次，统一重跑往往无法解释问题。本文说明如何区分启动障碍、超时、异常终止、应用拒绝与语义不符，怎样保存最小必要材料，并让分类指向明确下一步，而不是给没有证据的根因贴标签。
失败不是一个足够具体的调查入口
假设一个本地回归集合出现三条失败：一条超过等待期限，一条进程异常结束，另一条正常结束但结果少一项。如果全部交给同一个“重新执行”按钮，可能暂时改变面板，却没有解释任何原因。先分类能够让维护者知道需要检查运行条件、终止状态还是业务断言。分类不是为了创造更多术语，而是让下一步与已观察事实对应，避免每种问题都从修改同一段代码开始。
报告首先应说明实际取得什么证据。程序是否启动、是否结束、以怎样方式结束、输出是否完整取得以及预期是否成立，属于不同层次。一个结果可能同时包含多个事实，例如期限到了以后由测试结束进程，留下部分输出。不能为了只保留一个标签就丢掉其他信息。分类应组织证据，而不是把复杂情况压成一个看似精确、实际上失去背景的词。
启动障碍先于业务判断
如果目标程序没有启动，就不能说它计算结果不正确。路径错误、运行前提不足或调用配置问题，应该首先在入口层报告。保留实际程序身份与必要参数，确认任务尝试启动什么，再决定如何修复。不要在缺少目标运行的情况下修改算法，因为这类改动无法解释当前观察。测试没有取得结果，并不等于取得了一个错误业务结果。
对本地练习，可以在运行前核对有限前提，避免无关环境问题不断进入业务失败统计。但前提检查也不应自动掩盖缺失，报告应说明本次未完成验证。Python 的子进程接口提供明确的结果与异常机制，实际使用时应按对应语义处理，而不是捕获所有情况后统一返回一个空字符串。空结果如果失去来源，会让后续比较误以为程序正常输出为空，错误层次因此被进一步混淆。
超时说明没有在当前期限内完成
超过等待期限，直接支持的结论是当前条件下任务没有按时完成，不是已经证明死锁、无限循环或性能退化。可能存在输入未结束、外层等待、检查工具开销或其他尚未确认条件。报告应保留期限、启动前提、最后确认阶段与结束测试的动作。根因需要进一步证据，不能由一个时间标签自动生成。清楚表达能让调查避免在错误假设上扩大修改范围。
Python 文档说明，不同子进程接口对超时后的处理有具体约定，不能从一个接口的行为推断所有调用。测试作者应查明自己使用的是哪种方式，是否已经结束并等待目标，以及还有哪些组件需要管理。不要让超时标签掩盖残留任务或丢失材料。本文不要求对真实系统执行额外终止操作，而是强调本地测试设计需要有明确且有限的收尾路线，并把实际动作写入记录。
异常终止与应用拒绝不是同一状态
进程可能通过正常返回报告业务拒绝，也可能因信号或其他机制异常终止。应按照当前平台与接口解释结果，而不是把所有非零值都叫崩溃。Python 文档对 POSIX 下负返回值的含义有说明，这是一项带平台条件的规则，不能直接复制到所有环境。报告需要写清来源，避免一个数值离开上下文以后被误读成通用错误码。
应用主动拒绝无效输入，可能正是测试期待的正确行为。此时需要检查拒绝类别、必要说明与不应发生的副作用，而不是要求所有输入都返回成功。若实际是异常终止，即使窗口里出现了错误文字，也不能自动当成有控制的拒绝。分类帮助保持这一边界：程序按契约报告不接受，与程序失去正常控制流，具有不同的维护意义，也需要不同回归条件。
正常结束仍需语义断言
程序返回正常，不代表输出完整正确。可能漏处理最后记录、使用旧产物、生成字段错误或提前跳过工作。测试需要将实际结果与独立预期比较，并选择符合契约的粒度。只搜索成功提示过宽，锁定全部无关日志又可能过于脆弱。应当明确哪些字段、数量或状态是真正要求，哪些展示细节可以变化，让比较既能抓住问题，又不给等价实现设置不必要障碍。
语义不符应保留预期与实际差异，而不只是一个布尔值。差异材料可以很小，例如缺少哪条记录、哪个字段不符合约定。不要为了报告完整而附带全部真实输入，有限替代样本通常更便于分析。若实际输出没有完整取得，应先报告材料限制，不能将缺失采集当成程序输出少。采集与语义是两层，先确认材料，再比较含义，才能避免错误归类。
捕获策略会影响你能够看到的证据
标准输出与标准错误可以分别保存，也可以按明确政策合并。选择应根据程序协议与调查问题决定。若错误通道没有被收集，就不能因为正文安静而推断没有诊断；若两者合并，则需知道哪些内容属于业务数据，哪些属于说明。Python 文档描述了相关捕获方式，测试封装应保留它们的语义，而不是在外层悄悄丢弃一个通道。
文本与原始字节捕获也有不同用途。若需要验证精确数据，就应考虑编码与换行转换等条件；若只需要面向人的说明，则可以采用清楚的文本政策。不要在没有说明时把转换后的文本称为原始输出。失败分类依赖材料，如果材料层已经改变或截短内容，后续判断就可能把采集问题归到程序。记录捕获条件，有助于让结论知道自己依据什么。
为每类结果安排有限下一步
启动障碍可以先核对入口与前提；超时可以检查最后确认事件和结束条件；异常终止可以保留对应构建与必要诊断；业务拒绝可以核查输入政策；语义不符则沿数据关系和独立预期分析。这些路线不是根因公式，而是由当前证据支持的调查入口。下一步应当能够缩小不确定性，不能只是对所有类别都无条件增加日志或延长时间。
若一份材料同时涉及多类，应保留主要事件与附加状态。例如测试因超时结束以后，外层可能得到一个终止结果，但这不应抹掉超时由测试触发的事实。反过来，程序先异常结束，之后收集流程迟迟不完成，也需要说明两个阶段。清楚的事件关系比单一标签更有价值。分类可以帮助扫描，但原始观察应当允许读者重新核对，不能被标签永久替代。
重试需要有理由与次数边界
某些前提问题可能在有限重试后消失，但重试本身不解释原因。若每次失败都自动重跑直到通过，就会隐藏不稳定性，并让最终报告失去代表性。可以为确有需要的类别设置明确政策，保留每次结果与触发理由。稳定重现的语义不符通常需要调查，不应因反复重试而被绿色结果覆盖。测试目标是发现和解释差异，不是筛选一个成功样本。
重试也不能覆盖原始材料。第一次失败输入、程序身份与观察应当保留，再将后续尝试作为新的事件。若条件发生改变，要写清变化，而不是把它们当成相同运行。对于学习用本地任务，有限次数与有限资源已经足够。无期限等待或反复创建任务不仅没有更强证明力，还可能让调查材料混乱，最终无法区分哪个结果属于哪个条件。
统计按类别呈现，避免数字制造误解
一份测试摘要可以按结果类别列出数量，同时保留具体样本入口。总失败数有助于快速了解规模，却不能说明所有失败具有相同原因。版本变化以后，新增类别也可能来自观察能力改善，而非程序突然退化；失败减少则可能来自覆盖范围缩小。比较统计应先确认样本、配置与判定政策一致，再解释变化，不能让一个数字独立承担质量结论。
同一根因可能产生多个症状，多个根因也可能共享一个标签。因此分类后的归组仍需要技术分析。可以记录已确认关联与尚未确认项目，不必为了清单简洁强行合并。修复完成以后，针对相应契约重跑代表样本，再按需要扩大验证。测试报告应同时支持扫描与追溯：读者既能看到哪类问题值得优先处理，也能进入具体材料确认原因，而不只面对一张没有上下文的排行榜。
收尾失败也应保留原始结果
测试已经取得一项语义不符，随后保存报告失败，这两个事实都值得记录。不能让收尾错误覆盖原问题，使维护者只看到最后一个异常；也不能因为原问题已经存在，就忽略报告不完整。可以保留主要结果与材料状态，让读者知道现有证据是否足以继续调查，缺少部分需要怎样补充。
同样，清理临时文件失败不等于被测程序计算错误。应限定清理目标并独立报告，不通过扩大删除范围来让任务结束。结果、证据与收尾各有职责，将它们分开能够让失败路线更透明，也避免修复一层时无意改变另一层的含义。
将分类政策写进测试封装
如果脚本将子进程异常、返回结果与断言统一转换为报告，应当在封装中保留必要层次。不要用一个通用捕获把所有情况改写为成功，也不要将无法判断的状态自动标成业务失败。封装是观察系统的一部分，它的结果政策需要被核对。可以用有限的已知场景验证分类是否符合预期，而不是等真实故障发生以后才发现标签并不表达实际情况。
最后，为每项修复保存原问题的代表样本与清楚预期。超时问题修复后要验证任务按约定完成，崩溃问题修复后要验证正常行为，输出问题修复后要验证结果含义。不同类别可以共享测试基础，但不能共享一个含糊的验收标准。让失败名称对应观察，让下一步对应证据，测试系统才会帮助维护者更快接近原因，而不是把所有异常都变成同一场没有方向的重跑。