关于脚本测试过程中端口预期不一致的情况
来源:互联网 发布:cda数据分析师官网 编辑:程序博客网 时间:2024/05/21 20:04
在脚本测试过程中,我们经常会遇到一些端口会话状态与预期不一致的问题。比如说,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查询一次。当结果达到预期时,跳出循环,继续脚本执行。
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查询一次。当结果达到预期时,跳出循环,继续脚本执行。
阅读全文
1 0
- 关于脚本测试过程中端口预期不一致的情况
- 测试代码运行状态和预期不一致时的处理
- 关于Response.Redirect 端口不一致的跳转
- 关于eclipse中tomcat端口 被占用的情况
- 项目测试过程中应该避免的一些情况
- 关于多线程导致数据不一致的情况的思考
- 开发过程端口被占用的情况
- MySQL主从不一致的情况
- 在测试过程中,可能会出现以下常见的几种测试情况
- 关于ASP.NET分配端口与浏览器调用端口不一致的问题
- VS端口不一致的问题
- 关于域脚本影响性能的情况
- 关于函数声明和调用时参数个数不一致的情况
- 关于函数声明和调用时参数类型不一致的情况
- 关于windows下的端口使用情况查询
- 关于确认clearcase端口使用情况的方法
- android 开发过程中测试内存使用情况
- 一个关于继承的程序,求高人解释程序执行过程中内存的数据存储情况
- JDBC数据库连接池
- [USACO4.3.2]Street Race
- 圆形图片
- 二分+贪心 [NOIP2015] 跳石头
- [总结]C++真是博大精深(四)
- 关于脚本测试过程中端口预期不一致的情况
- eos的石墨烯技术是什么
- LDA主题模型
- 剑指offer:复杂链表的复制
- 2017暑训摸底(xdoj1045,xdoj1173,xdoj1007,xdoj1038)
- 求LIS 的o(nlogn)的解法及 路径记录
- 二叉搜索树 (c++递归版)
- 选择排序
- 暑假集训日记--8.7--搜索+图论