關於腳本測試過程中端口預期不一致的情況

在腳本測試過程中，我們經常會遇到一些端口會話狀態與預期不一致的問題。比如說，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查詢一次。當結果達到預期時，跳出循環，繼續腳本執行。