退出状态怎样进入测试结论：不要只看屏幕上的成功提示

一句成功文字不能代表整个任务

假设一个本地练习工具读取文件，生成一个结果，再写出结束提示。自动测试只要在窗口中找到“完成”便显示通过。随后才发现结果文件缺少内容。这并不一定是程序在说谎，也可能是提示写得过早，或测试根本没有检查它真正需要的产物。先把任务成功的条件写成可验证条目，比猜测哪一句输出更可信更有用。进程结束只是一个事件，满足需求则是一组需要证明的事实。

退出状态为父进程提供简短的结果信息，通常用于表达宽泛的成功或失败。它不能容纳整个诊断报告，也不会自动检查输出内容。GNU C 库文档特别区分程序的退出状态与进程终止状态：进程还可能以正常结束之外的方式终止。测试记录应当保留这种区别，避免把没有取得正常退出结果的运行强行塞进普通业务错误。一个清楚的测试结果需要同时交代运行是否结束、怎样结束，以及需求是否成立。

先确定被测程序自己的约定

对于自己的练习程序，应当写出退出结果的含义，并确认每条主要结束路径遵守约定。不要只在主流程末尾设置一次成功结果，却让早期错误走到相同位置。读取输入失败、参数不被接受、结果无法写出，都可能需要被调用者识别。具体是否区分成多个值取决于用途，重点是约定稳定而且有文档，调用者能够据此选择后续动作。数字数量多并不自动等于信息质量高。

对外部工具则要先查它的说明，而不是把每个非零结果都解释成同一种故障。GNU 文档举出的比较工具就是重要例子：不相同与无法比较可以是不同类别。若测试本来希望发现两份文件不同，那么对应的比较结果可能正是预期观察。把外部工具的接口语义转换成当前测试的判定，是测试作者的责任；让一个通用的“非零即全部失败”规则代替理解，容易把有效信息丢掉。

预期失败也需要成功的测试判定

输入验证测试常常故意提供不合法参数。如果程序按约定拒绝，并且没有执行成功路径，这条测试应该通过。这里存在两个层次：被测操作没有成功，而测试成功验证了拒绝行为。报告中把两者写清楚，就不会出现一边声称测试失败、一边又说程序正确的矛盾。用“预期拒绝得到确认”这样的结果，比把所有层次都压缩成一个“失败”更容易阅读。

一条完整的拒绝用例还应检查必要的附加条件。假设无效路径应当被拒绝，那么不能只确认有错误状态，还要确认程序没有用旧文件冒充新产物。如果要求错误时不创建结果，就要在运行前准备明确的目录状态，再在运行后检查。若测试目录里已经留有上次结果，程序即使什么都没有生成，单纯的存在检查仍可能通过。测试的前置条件必须与退出状态一起成为证据的一部分。

包装层不能悄悄替换原来的结果

实际运行往往不止一层：编辑器任务启动脚本，脚本准备文件，再启动练习程序，最后打印一段说明。人眼看到的最后一句文字可能来自脚本，任务窗口显示的结果也可能对应外层动作。调查时先画出这条调用链，为每层标注它收到了什么结果、怎样决定自己的结果。不要只改最内层程序，然后希望所有外层自动传递语义。包装层有责任保留它向上承诺的信息。

可以在自有本地环境中分别验证三条简单路线：内层成功、内层按约定拒绝、内层未能正常运行。查看外层报告是否仍然区分它们。这里不需要使用真实业务文件，也不需要制造不可控制的系统故障，用有限而可恢复的测试入口即可。若外层始终报告同一种完成状态，先修正结果传递再继续排查业务逻辑，否则后续每次测试都可能在同一个盲点上得出错误结论。

产物检查应当针对本次运行

结果文件存在，不代表它来自本次任务；文件大小不为零，也不代表内容符合需求。可以给每次本地测试安排独立的临时输出位置，或者在明确控制下清理本次生成目标，再检查创建和内容。选择哪种办法取决于工具的实际行为，但要避免误删无关文件。最小测试目录有助于把产物来源讲清楚，且能让失败时留下的材料更容易分析，而不是与历史运行混在一起。

产物验证还应该具体到需要的结构。假设程序输出一份包含记录数量的文本，测试可以同时检查可读取、必要字段和预期记录，而不只搜索一个片段。具体断言要与稳定契约一致，不应把无关空白或不承诺的排列顺序加入判断。如果只因为格式细节变化就失败，维护者可能被迫绕开测试；如果只检查一个过宽的标记，又会漏掉真实损坏。退出状态与有目的的内容断言能够互相补充。

把无法完成测试与结论不符分开

测试环境可能缺少必需输入，调用工具可能不可用，运行也可能没有在设定期限内完成。这些情况说明本次没有取得完整证据，不能直接等同于“被测算法计算错了”。给它们单独的结果类别，可以避免把环境故障混进回归统计。明确是哪一步没有完成，通常已经足够支持下一步处理，不必在证据不足时猜测更深层的程序原因。

例如一条测试期待得到特定文本，但实际没有启动被测程序。报告应该说明启动阶段未完成，而不是仅显示文本不匹配。又如程序一直等待未关闭的输入通道，期限到了以后测试结束，这时应保留等待条件和终止动作，而非编造一个普通返回值。分类的价值在于引导调查方向：先解决取得证据的障碍，再讨论结果是否符合预期。测试结论的精确程度不能超过它实际观察到的内容。

简短状态与详细诊断各司其职

退出状态适合提供粗粒度结果，错误原因可以通过单独诊断材料表达。GNU 文档提醒，不要把错误数量或任意错误变量直接拿来当退出状态；这种做法可能丢失含义，甚至让某些数值在外层看起来像成功。更稳妥的设计是定义少量有意义的结果类别，再在日志中保留具体信息。日志与状态之间需要相互一致，但不必把所有细节都挤进一个数字。

详细诊断也应以调用者能够使用的方式组织。面向人的说明可以解释哪个输入被拒绝，面向自动处理的结果则要有稳定结构，不能依赖一句容易改写的自然语言。两种输出是否共用通道，要根据实际协议决定。若正文需要被另一程序读取，调试文字就不应无规则地插入其中。把机器判断与人工阅读的用途分清，可以降低一次文案调整意外改变测试含义的风险。

为组合任务定义失败后的动作

一个脚本可能依次转换、校验和归档。前一步失败后，后一步是否仍应执行，需要被明确规定。用于保存诊断材料的动作也许应当继续，而依赖有效结果的归档步骤就不该假装一切正常。不要让“任务最终执行到了最后一行”成为成功条件。逐步写清哪些操作依赖前一步成立，哪些是无论结果如何都要做的收尾，组合任务才有可以理解的行为。

收尾动作本身失败时，也应保留原始问题。假设程序已经输出错误，随后保存诊断材料又失败，报告最好同时说明两个事实，而不是让后一个结果完全覆盖前一个。对于小型练习，可以用简单的分层记录达到目的，无需引入复杂平台。关键是按事件保留信息，再由明确规则形成最后判定。这样既能看到当前任务是否达到要求，也能知道失败材料是否完整，避免把调查线索在收尾阶段再次丢掉。

在修改程序前保存判定依据

发现结果异常时，先保存本次使用的输入、实际执行入口、测试预期和取得的状态。不要立即重新运行覆盖原产物，再凭记忆描述第一次发生了什么。若只能保留一组材料，就优先选择能区分假设的部分，例如外层报告与内层结果为何不一致，而不是截取一整屏没有关联的历史输出。记录不必包含个人目录或其他任务数据，围绕这次有限实验保持材料清楚即可。

修改以后应当用相同前提重新验证，再补上能够防止复发的针对性用例。如果同时换了输入、输出位置和包装脚本，最终成功也无法说明是哪一项变化解决了问题。可以先验证最小改动，再逐项恢复实际调用条件。这样不仅能够确认结果有所改善，还能解释改善发生在哪一层。把修复依据写到测试旁边，比留下“现在可以运行”的一句话更便于后来维护，尤其能避免其他人再次简化掉必要的状态检查。

用一张判定表审查测试覆盖

给每条用例列出输入前提、预期结束类别、预期产物和不应出现的效果，能直观看出测试是否只依赖一项信号。合法输入的用例应要求任务达到预期；无效输入的用例应要求按约定拒绝；环境不满足的用例则应说明测试无法完成。表格中的各列不必都转换为复杂自动化，但必须有明确的观察办法，否则所谓覆盖只是列了一串名称。

审查时尤其要找互相矛盾的组合：成功结果配上缺失产物、错误结果配上被使用的新产物、没有启动记录却出现完成提示。它们不一定都来自被测程序，也可能暴露包装层或测试前提的问题。保留这些不一致，而不是强行择一相信，才能让测试继续发挥诊断作用。一个可靠的判定流程会解释每条信号的来源，并在证据不足时明确停止下结论，而不是用最醒目的成功文字替整个任务作证。

延伸阅读

• GNU C Library — 退出状态与终止状态