夜雨聆风一、标准说了"应当做"，但没说"怎么做"
DO-178C 第 6 节是软件验证过程，核心就一句："验证是评审、分析和测试的组合。"第 9 节给了测试指南，告诉你测试用例要覆盖正常和异常、结果要记录差异、覆盖率要达标。
听起来很完善对吧？
但你随便拉一个测试工程师过来问问——拿到一条需求，"系统应在 200ms 内完成故障重构"，接下来怎么办？
- 这条需求该拆成几个用例？
- 正常值测几个？边界值取多少个点？异常路径走几条？
- 前置条件要写到什么粒度？全部初始化状态全列一遍，还是只列影响本条的那几个？
- 预期结果是写"系统正常响应"，还是精确到寄存器 bit 级？
DO-178C 不回答这些问题。不是它不够好，是它根本没打算回答——标准的职责是原则，但工程师要的是指令。在不少民机测试现场，那个"指令"长这样："老李知道，问老李。"
别问我怎么知道的 😅
二、四个断层：模板不是没有，是填不进去
断层一：用例模板有，但每个格子怎么写——没人教
民机项目基本都有测试用例模板。长啥样？一堆列：用例编号、名称、前置条件、输入、步骤、预期结果、覆盖需求标识、类型、优先级、备注。
模板看着没问题。问题在于你面对"预期结果"这一列的时候——
- 浮点计算类需求：精确到小数点后几位？舍入误差 ±1 LSB 到底算不算过？
- 时序类需求：要求"200ms 内完成"，199ms 过了、201ms 怎么判？这 1ms 是环境因素还是设计缺陷？
- 状态机类需求：预期结果写"进入状态 X"，还是把所有中间状态序列全列出来？
模板不附带填写指南。 即是模板再完善，没有配套的填写规则，填出来的东西照样五花八门。不同工程师对同一列的理解天差地别，AI Agent 面对碎片输入，输出的东西也不会靠谱。
真正缺的不是更多模板——是模板下面多走一步：针对计算类、时序类、状态机类、接口类这些常见需求类型，给每列配示例、配判断规则。这种东西——目前基本只在老工程师脑袋里。
断层二：规程格式统一了，但流程节点没定义
测试规程是连接用例和执行的桥。不少项目有规程模板——Step 、Action、Expected Result、Pass/Fail——格式是统一的，这点没毛病。但对于不同的测试环境和手段，手动测试、自动测试、插桩测试，是否都有明确的规程撰写指南，数据到底要怎么给进去，怎么读出来，不可读数据怎么处理。
从规程起草到关闭，中间的过程节点呢？
- 规程写完了，怎么评审？评审通过了的标准是什么？
- 环境准备好了，谁来确认"可以开始执行了"？确认依据是啥？
- 执行中偏离规程了——步骤跳过、参数临时调了——谁来批准？偏差记在哪？
- 一批用例跑完，谁判定"本次测试完成"？完成的标准是什么？怎么留痕，怎么防篡改
一个能落地的流程，罗辑上需要回答的问题就七个：时机、输入、角色、工具、要求、标准、输出。但现实是——很多项目只定义了前端模板，后面这些节点上的确认动作，要么直接跳过了，要么靠口头发起、微信确认，不留下任何痕迹。
断层三：结果怎么判——完成标准和评价规则不统一
用例执行完了，什么算"通过"？
直觉是"预期结果完全匹配就行"。现实复杂多了——
- 浮点数 1.00001 和 1.0，算不算过？
- 执行中出了一次环境异常，重跑三次都正常——这次异常记不记？用例算过还是重测？
- 覆盖率统计里 80% 的分支覆盖了，剩下 20% 经分析是不可达代码——这个结论谁签字生效？如果错了谁兜底？
问题怎么分类？致命/严重/一般/轻微？每种的处置方式是改完重测、出分析说明、还是直接关了？军机和民机的要求该不该区别对待？
以经搞得很清楚了：这些规则不落地，每个项目都在自行定义"通过"。 AI 面对一个没有统一规则的结果判断逻辑，它产出的结论——能信吗？
断层四：数据应该关联，但关联规则没人写
DO-178C 最核心的验证要求之一是可追踪性：需求→用例→执行→缺陷→回归，每一步都得能向前追溯、向后追踪。
模板里"覆盖需求标识"那一列天生就是干这个的。问题在模板外面——
- 一条需求能被多少用例覆盖？一条用例能对应多少需求？多对多的关系谁来管？
- 需求改了，哪些用例受影响？是人工一条条核对，还是工具自动标？
- 回归测试的范围怎么定？全量回归还是只测变更影响面？如果开发那边对变更记录不靠谱，测试团队怎么办？
骨架有了，肉没长齐。"怎么建立追溯"和"怎么判断关联"这最后一步，需要更具体的实施细则/标准/指南。
三、解法不在推翻标准，而在标准下面多走一步
上面四个断层，背后是一个共同问题：现有标准给的是原则级指令，但工程师要的是操作级指令。
解法不是去推翻 DO-178C——它的权威性和完备性摆在那，没人质疑。该做的是在 DO-178C 框架下，往下再走一公里。把"应当"翻译成"怎么做"。
这一公里长啥样？
第一，用例模板不能是空壳。 每个字段——前置条件、输入、预期结果、覆盖标识——都要配套填写规则。不是"建议"，是强制要求：不同人面对同一条需求，产出的用例在结构和粒度上必须一致。做不到一致，模板就等于没模板。
第二，规程不能只是格式模板。 从起草到关闭，每个节点上的角色、输入物、输出物、审批标准，全部书面定义，不留口头交接的灰色地带。输出物的格式和内容必须满足预定标准，不然评审就是走形式。
第三，通过/失败不能靠拍脑袋。 针对不同软件等级和需求类型，定好问题分类规则、等级划分规则、处置方式规则，再配上具体示例。让工程师看到一条偏差记录，不用开会就知道——这算致命还是轻微、该重测还是分析关闭。
第四，数据追溯不是填表。 需求→用例→执行→缺陷→回归，每一跳用明确的关联规则连起来。数据分级分类管好，变更影响自动标。必竟，追溯的价值不在"有表"，在"能追"。
这些不是"未来的理想状态"。它们早就是被定义过的、可审计的要求。不需要 AI 来发明，需要的是把散落在不同项目、不同团队、不同工程师脑子里的"约定俗成"，系统化地整理出来，写成一份能对着干的标准。
四、AI来了之后，什么会先变？
如果把 AI Agent 丢进这个框架里，它倒逼的不会是工具升级，而是三个标准化动作：
第一，倒逼操作级指南成型。 AI 不吃"老李知道"这套。要让 AI 稳定出用例，"预期结果怎么写""前置条件怎么列"必须白纸黑字写进规则里。这玩意现在不是没有——骨架在，缺的是填写指南的肉。
第二，倒逼流程节点固化。 AI 可以自动把"需求→用例→规程"的链路串起来，但生成出来之后的评审、批准、执行、结论——这些节点上的人和规则必须提前定好。流程七大要素（时机、输入、角色、工具、要求、标准、输出），少一个就是断头路。
第三，倒逼数据追溯自动化。 一旦需求→用例→规程→结果这条链格式统一了，AI 就能自动维护追踪矩阵，实时检测需求变更的影响范围，自动标出受影响的用例和规程。追溯关系的框架早就有了，缺的是格式标准化的最后一公里。
五、先说好——不是AI不行，是具有实操性/能落地的体系流程得先跟上去
AI Agent 进民机测试，不是在给团队加工具，它更像是一面镜子——把你那些"原则说到了但操作没落地"的地方照得清清楚楚。
现阶段最该做的事，不是选 AI 模型，不是对工具链，而是先把操作级指南写出来。在现有标准框架下，用例怎么填、规程怎么走、结果怎么判、数据怎么追——每个环节配上具体的填写规则和判断标准。
这些事不看 AI 的能力，看测试团队的决心。AI 不会自动解决"指南不落地"的问题，它只是让不落地的代价更扎眼——你越早把规则写清楚，AI 越是能早点真正干活。
*聊完了。你觉得你们团队的测试体系是"能直接用"还是经常"得问老李、老张"？留言区吐槽一下。*
*觉得有用的话，点个「在看」让更多人看到 👇*
#民机软件测试 #DO178C #AI Agent #测试标准化 #测试用例 #软件验证 #适航 #独立测试 #指南落地
