企业官网建设流程全解析

分支功能：实现多场景覆盖

主线描述脚本要做的功能，分支描述该功能在各条路径上的执行情况。
一份代码，配上 N 个分支场景，得到 N 份测试结论。

项目地址：https://qingxun.online

一、问题：脚本在正常情况下通常验证充分，出问题的往往是各种分支情况

脚本的功能通常覆盖多种情况：命令是否执行成功、回显里有没有目标字段、数值是否在阈值内、型号是否匹配。这些情况在正常情况下都能验证到：操作者在一台正常设备上取到display version的回显，照它写需求，脚本按这份回显做完判断、测试通过。

出问题的是正常情况之外的那些回显。发布之后，设备群里总有一些设备回显不一样——命令报错、字段为空、型号不符、权限不足。这些分支情况在生成阶段从来没有验证过，问题就只能在真机上暴露。

结论：正常情况通常验证充分，容易漏掉的是各种分支情况。

分支功能解决的就是这个问题：给同一个脚本建多个分支场景，每个场景验证一种分支情况，分别得出结果。

二、做法：一份代码，多组回显

生成页的描述区是标签页：主线占一个，每条分支各占一个。两者的分工如下：

一次「自动化生成」包含三件事：

1. 生成代码——只看主线，产出一份脚本代码；
2. 生成分支映射——为每个分支造出这个场景下设备的命令-报文对应关系；
3. 执行与评估——同一份代码分别放进各个场景的回显里执行，各自得出评估结论。

结果按标签页展示：每个分支有自己的一套命令映射、执行日志、返回结果和评估结论，标签上用 ✅ / ❌ 标出这个场景的结果。

三、哪些场景值得覆盖

网络设备脚本里，下面几类场景最值得覆盖：

两三个最容易出问题的场景通常就够了。场景加得越多，验证越完整，需要维护的描述也越多。

四、操作：填写、检查与生成

填写主线。主线要把规则写全：分支只能触发主线里已经声明的规则，主线没写的判定，在分支里用不出来。

添加分支。两种方式：手动「添加分支」，按场景填写；「AI建议分支」根据主线给出三条候选场景（命令失败、报文为空、型号差异、权限不足等），每条都能改完再采纳，「换一批」换一组候选。建议会先做一次一致性检查，超纲或与主线矛盾的建议会被自动丢弃并写明原因。建议只是参考，不采纳也能自己写。

检查分支。「检查分支」逐条给出分支和主线的关系：合规/超纲（分支引入了主线没声明的判定、阈值、失败处理或终止条件）/矛盾（分支结论和主线冲突）。这个检查只提示、不拦着生成，作用是提前发现分支里多出来的要求。

生成与查看结果。「自动化生成」跑完后，每个标签页显示这个场景的命令映射、执行日志、返回结果和评估结论。

单独重跑一个场景。已经有脚本代码时，标签页上的「运行」只跑当前这个场景，「运行全部」跑主线加全部分支；两者都不重新生成代码，适合改完某条分支描述后单独重跑，不用整体重来。

改动留痕。分支描述随脚本一起保存，并进入版本历史；历史里的差异对比把分支描述排在最前面，这次改的是"要验证什么"一眼可见，主线描述没动也会明确写出来。

五、分支描述的写法

分支描述和主线格式一样：按执行顺序写命令 / 报文 / 处理逻辑。三条规则：

1. 只写这个场景真正会执行的步骤。流程在哪一步结束，就写到哪一步，后面的命令不用列。
2. 不要写占位。「（不执行）」「其余同主线」「同上」这类写法，以及"场景前提""验证点"这类说明，都不提供有用信息。
3. 不要超出主线。分支只能用另一组报文或数值，去触发主线里已经声明的规则。

以主线「取版本号，匹配不到SW-9000就判定模板不符并结束」为例：

反例（平台只能猜没写出来的步骤）：

命令 display version 报文（不执行） 处理逻辑：其余同主线

正例（平台能照着造出回显）：

命令 display version 报文 %Error: no such file: version.txt 处理逻辑：命令返回错误回显，判定取版本失败，输出可读原因并结束本次检查

错误回显要写原文，不要只写"报错"两个字。平台拿这段文字去造模拟设备：写得越具体，得出的结果越可信。

六、分支没通过时怎么处理

主线通过，就说明这一版脚本能用；分支不参与通过判定。这样设计是因为代码只有一份：先确认主线能用，再看哪些分支没走通，不让一个边缘分支卡住整个生成流程。

生成结束时，汇总会给出各分支的结果，例如「主线评估通过；分支 1/2 通过」。❌ 表示这个场景还没有被验证过。

没通过的分支，按标签页给出的原因处理：

一个 ❌ 分支通常比三个 ✅ 分支更有用：✅ 只确认了已经想到的情况，❌ 指出的是没想到的情况。

项目地址：https://qingxun.online