关于脚本测试过程中端口预期不一致的情况

在脚本测试过程中，我们经常会遇到一些端口会话状态与预期不一致的问题。比如说，BFD会话过程中，期望BFD会话的状态是up的，但是在实际中显示的state为down的或者是为‘[ ]’的状态；或者期望BFD的会话是down但实际为up；又或者在CC会话中，期望CFM的会话状态是up，但实际为down的情况等等，那么当我们遇到这样的情况，我们该怎么进行分析呢？

1、BFD为例
a、BFD会话状态期望为up
当我们期望两者之间可以建立BFD的会话时，即state的状态为“up”，此时BFD的state不是我们预期时，一般情况下是等待时间不足的问题。
一般BFD的会话建立时间为（50+N/10）s，这里的N为设备的数量。这种情况下，我们只需在规定时间内建立循环，每5s查询一次状态就可以解决。当实际为down的情况下，我们循环中检查state为非down的情况下跳出；当实际为“[ ]”情况下，我们在循环中检查state为非“[ ]”时跳出。

b、BFD会话状态期望为down
如果期望BFD会话的状态为down时出错，那么实际BFD的会话状态一般为up的。由于BFD的特性决定可以快速感知链路中的错误，那么这种情况下与等待时间基本没有关系。
在测试环境中，我们希望链路出现shutdown的情况时，BFD能快速感知。如果在这种情况下，BFD会话仍未up，那么我们需要在脚本中设置出错暂停机制。当出现这种错误时，一般情况下是由于环境残留造成的，因此我们需要去检查此时两台设备之间是否还存在着其他的连接链路。当我们shutdown掉多余的连接链路时，一般可以解决我们的问题。
当然可能也会遇到一种特殊情况。脚本中没有多余的配置，链路也shutdown了，但BFD会话显示为up。当我们按照步骤进行复现时却显示正常，那这种情况下一般就是版本问题了。

2、CC会话为例
当在cc会话中，我们期望cfmStatus的状态为up但是实际为down的情况，一般由几种情况造成。
a、CFM显示为disable
这种情况要具体分析，一种可能是在脚本中误操作，undo cfm enable 导致的。另一种情况在确保脚本没有问题时，这时要去看看跑到过程中是不是有设备异常重启等过程。如果在测试套跑完进入脚本之前，设备被人误动导致重启，那么会恢复设备初始状态，显示CFM disable，导致cc会话中cfmStatus显示为down。此时要查看测试套文件和脚本日志文件确认。这时的建议是增加支撑库文件，检查设备异常重启，确保脚本运行过程中，设备正常运行。

b、环境残留问题。
如果是环境残留问题，此时脚本无需改动。这时查看测试套文件我们可以发现，在进入脚本运行前，设备显示目前配置时并不是理想环境。并且在执行错误暂停机制后，会发现设备上存在多种相连链路。此时，我们需要shutdown掉多余的接口，即可实现预期结果。

c、等待时间不足
虽说，CFM会话，我们希望快速感知。但在实际中，与BFD类似，存在等待时间。因此，对于这种情况下，我们可以增加循环，限时1min，每5s查询一次。当结果达到预期时，跳出循环，继续脚本执行。