設備軟體可靠性測試

2023-07-04 14:21:23

    檢驗設備軟體在各種條件下可實現持續運行狀態，以及評估設備從故障中恢復正常服務所需要的時間和其他影響，就是軟體可靠性測試主要涉及的課題。

    設備為達到連續可運行目標，除了在硬體設計中考慮器件可連續無故障運行外，很重要的方面是軟體在各種條件下可經受考驗，持續工作。這需要在實現基本功能前提下，在軟體中設計一系列容錯性邏輯去保證。

    為全面評估軟體容錯性和故障恢復能力，測試需要製造或模擬一系列條件，包括內部硬體故障條件、外部惡意攻擊條件、偶發過載條件、軟體資源耗盡條件、周邊環境故障條件以及長時間正常負荷持續運行模擬。為了在產品開發的不同階段組織針對性測試，這些測試行為又被明確定義並歸類。

測試分類

1、協議健壯性測試

    協議健壯性測試是為了找出特定協議的具體實現代碼的弱點。是一種以破壞性手段去嘗試運行軟體的行為，通過用戶接口的異常輸入，使用異常協議消息交互引導軟體進入未定義或未保護的狀態。

    對軟體系統而言，合法輸入組合以外的輸入往往超出正常輸入的組合，軟體運行中總會遇到一些預期之外的輸入。因此，軟體需要有嚴格的合法性檢查才能避免進入未知狀態。協議健壯行測試的目標就是儘可能找出軟體保護不周的問題。

    在軟體測試的早期階段進行的參數邊界值測試就屬於健壯性測試的一部分。比如一個用戶接口接受1-100的整數輸入，那麼1和100就是合法邊界，大於100和小於1的輸入都是非法輸入。其他非整數型的輸入也屬於非法值，包括故意破壞檢查輸入條件的代碼的一些組合（如超長輸入值，空輸入，格式化字符等）。軟體面對的接口除了最終用戶可見的部分之外，還有大量的軟體組件之間的不可見部分，以及設備之間的通信協議接口。

    除了單一輸入的簡單合法性判斷，軟體在組合輸入和特定狀態下可接受輸入的定義更為複雜。為確認軟體在各種條件下的運行正常，測試需要嘗試儘可能多的組合。複雜的通信協議除了定義有邏輯化結構的報文格式，還有一系列的內部狀態，要測試人員完全手工方式遍歷這些狀態，並且構造所有可能的異常組合輸入條件是無法想像的，因此需要專用的測試工具和儀器專門檢測軟體對各種協議變異報文的處理。目前，商用化的測試工具已經很多，比如IxDefend協議健壯性測試套件和Mu Dynamics的fuzzing測試套件是比較強大的。為了達成在特定狀態下注入錯誤，測試套件需要先完成一些合法的交互過程，使被測目標達到預設狀態，然後再注入異常。複雜的協議需要事先配置很多參數去達成這種交互，而變異輸入的變化和組合數量非常龐大，一個複雜協議經常達到幾十萬甚至上百萬的測試用例，儘管有自動化測試工具，這種測試運行也要耗費大量的時間。因此，對參數的調整是測試需要關注的一個重要方面。

    從系統測試的角度，觀測協議健壯性的測試結果是比較困難的，一般是從系統外部觀察整機是否存在異常，正在被測試的協議功能有沒有停止響應，正常用戶請求是否得到及時處理，設備的性能有沒有下降。最容易被觀測到現象是系統死鎖或重啟，系統性能變化或主要功能異常也能被及時發現。而一些細微的功能異常或資源耗費，很容易被測試人員忽視，在這裡，測試工具也無能為力。

以IxDefend測試TLS-Server舉例。

? 完成測試儀器與被測試設備的物理連接，並且將埠配置IP位址，開啟TLS-Server服務。

? 通過測試儀器的GUI控制界面裝入TLS Server測試套件，如圖1所示。

? 配置TLS Server測試所需要的參數，包括被測試設備IP、TLS服務埠、超時時間等，如圖2所示。

? 點擊開始按鈕啟動測試運行。

    測試運行期間，儀器會發送事先定義好的各種異常組合，並檢查設備對這些報文的響應。一旦被測試設備失去任何響應，就記錄為一次失敗，並持續嘗試下面的測試用例。如圖3所示的是一個真實的運行記錄，設備在某項測試運行後發生異常，該項目被標記為紅色。測試人員可以根據該記錄重現問題，並將設備異常信息一併提交給開發定位具體原因。

圖1 IxDefend選擇測試套件

圖2 IxDefend配置TLS-Server套件運行參數

圖3 IxDefend運行結果統計

    2、硬體故障模擬測試

    通常，判斷軟體行為是否正常的先決條件之一是其是否運行在正確的硬體環境之下，因為硬體故障對軟體產生的影響往往是致命的和不可預測的。在實際情況中，越是造價昂貴且承擔重要任務的硬體系統，其硬體的複雜度越高，故障率也更高。為了提高系統的可靠性，硬體在設計上會使用冗餘器件的方式（比如多個電源、多個風扇、多個交換網板、多個主控板），但在很多情況下，硬體替換做不到對軟體透明，需要依賴軟體檢測並採取一系列措施。此外，軟體還需要設計足夠的容錯性去隔離硬體錯誤的影響範圍。在非關鍵器件停止工作之前，軟體需要儘可能保證系統其它功能不受影響。

    對測試人員而言，了解軟體對硬體的依賴，通過製造或模擬硬體器件故障檢驗軟體行為的合理性，是可靠性測試的一個重要環節。硬體故障測試的目標就是觀測和評估軟體在硬體失效時的反映，找出預期與實際結果之間的差距。在測試有備份硬體系統的產品時，測試人員往往使用硬體拔出槽位，命令重啟等方式驗證備份機制的有效性。然而，這還遠遠不夠。設備在實際運行條件下器件被拔出只是一種維護行為，很多情況下是在連續運行過程中，器件突然失效。測試人員需要驗證這些情況，以確認軟體設計的故障檢測機制和容錯機制的真實有效性。

    由於硬體系統的具體情況不同，每個器件的故障形式和直接影響不同，是否有規避方案需要具體分析。軟體對硬體可用性的依存度往往很高，因此硬體故障測試的結果經常具有很大的爭議性。對測試結果的分析和判斷比測試設計和執行更為重要。

    現有的測試手段中，最直接的方式是通過改動硬體線路或幹預數位訊號製造故障。此外，可以通過軟體加入調試命令，對一些關鍵器件的狀態進行修改，設置為非法的狀態來模擬故障。

    3、壓力測試

    任何設備或系統都是在一定的工作負荷下完成其功能。如果外部加入的工作負擔超過其最大能力，系統效能會下降甚至是停止工作。這是一種與可用性相背離的特性，卻是任何系統的必然屬性。很多重要系統是通過增加硬體成本，人為降低承諾指標來緩解這一問題，然而事實上都存在一個能力極限，除非輸入子系統進行了硬性限制。

    為了提高設備的性價比，一般軟體系統不會設定承載能力的硬性約束，因此，設備都會面對超負荷工作的場景。軟體設計力爭減少超負荷運行的負面效應，使系統在合理壓力下能夠正常運作是可靠性的一個重要考量。雖然用戶不會要求設備能在超負荷的工作環境下連續穩定運行，但在真實網絡中，負荷波動是無法避免的，短時間的超載運行不應該導致災難性的後果。

    事實上，壓力除了令系統的計算能力經受考驗，也會使系統內的很多資源被軟體進程佔用；如果壓力消除以後，這些資源不能被充分釋放和回收，經受過壓力的系統將無法完全恢復正常的工作能力。
壓力測試就是通過製造設備的超載負荷，模擬設備在真實環境下可能遇到的場景。一臺網絡設備會有很多負載指標，驗證各個指標的超載工作能力是一項繁雜的測試工作。除了觀測壓力下設備的反應，在負荷恢復到承諾指標範圍內之後，系統完全達到正常工作狀態的能力和恢復時間也是用戶關心的指標。這些高負載的測試一般都要依賴專用的測試儀器來模擬。

    一般在設備規格會寫明產品支持的IP路由表容量、最大轉發數據流量、ARP或MAC地址容量等指標。測試的工作就是把被測試設備與測試儀器連接，通過儀器構造與規格指標相同或略低的一項負載，再製造一個10%左右的異常波動衝擊被測設備，並觀察被測設備在加載超載負荷前、負荷中和恢復到初始設定負荷之後的實際表現。。
不受壓力影響和能快速恢復的設備是可能被製造出來的，但是代價是必然提高硬體和軟體成本。因此一個合理的可接受的壓力反應和恢復時間，往往需要根據用戶的使用場景和可承受成本綜合考慮。

    4、內存耗盡測試

    與硬體發生故障類似，軟體所要面對的另一種是情況是資源枯竭。因為軟體要流暢地運行需要依賴很多外部資源，其中包括：內存、定時器、隊列、文件句柄、Socket等等。這些資源中最關鍵的就是內存，因為很多資源不足可以等待，內存短缺會導致立即的操作失敗。一個複雜的軟體系統內存資源都是動態申請和釋放的， 在各個處理進程之間動態流轉。在突發任務佔用大量內存的情況下，其他任務就可能面臨資源枯竭。一個良好設計的軟體系統需要設定內存門限，一旦內存消耗達到門限會強制一些不重要的任務退出運行而釋放資源。而且所有申請內存的任務需要自身設計保護代碼，避免沒有申請成功時誤入歧途。

    資源耗盡的情況下軟體系統必然會產生一些功能受限的反應，只要這種情況能在資源充足後得到恢復就不構成嚴重問題。確認系統在資源不足時沒有異常反映，合理屏蔽了次要功能，同時確保高優先級進程得到應得的資源就是軟體測試所要做的工作。

    測試手段通常是啟動一些重要的功能和構造動態的運行負荷，然後用調試命令佔用內存或啟動一些消耗型任務佔用內存，以構造資源耗盡的條件，觀察被測系統在內存枯竭後的反應，並繼續進行操作。最後再通過釋放佔用的內存來恢復正常條件，觀察系統受影響的功能是否自動恢復。

    內存耗盡測試的原理非常簡單，但是因為動態分配內存的指令無處不在，測試覆蓋各種流程分支就要設定各種組合條件，存在很大執行的難度。內存耗盡測試可能發現長期隱藏於軟體中的嚴重問題，徹底解決這些問題，對軟體的可靠性有很重要的意義。

    5、拷機測試

    由於軟體固有的邏輯複雜性和系統測試手段的限制，有些問題只有在實際環境下經過足夠長時間運行才會出現。拷機測試就是在實驗室模擬設備運行的真實工作場景，通過規定負荷及偶發性過載條件下連續運行，觀測被測設備連續無故障運行時間，俘獲異常錯誤的測試。

    測試所構造的工作場景能否還原真實應用，是能否提早發現問題的關鍵。由於用戶的應用場景千差萬別，需要用很多設備搭建組網來還原，而且必須等候足夠長的時間，這是一種高成本的測試方式，卻又不可替代。測試人員一般會採用頻繁觸發設備狀態變化的手段加速問題出現，這對某些問題有效，卻可能隱蔽另外一些問題。

    H3C的每個產品都要經過嚴格測試，其中必須進行的一項就是長時間的拷機環境測試。設備被接入一個運行各種拓撲管理協議和有大量背景流量的模擬環境，以驗證設備在典型應用環境下7*24小時的穩定運行。即使產品已經在市場正式投入使用，這套拷機環境還會持續運行，並且經常調整流量和業務規劃，以期覆蓋更多的用戶應用環境。

    6、收斂指標測試

    對網絡設備而言，保證網絡通暢是其最重要的功能之一。因此，網絡設備除保障自身連續運行外，還專門設計了很多從環境故障中恢復網絡連通性的協議。有些則是針對自身發生異常時實現冗餘硬體切換，流量路徑切換或快速故障恢復的協議。針對這些情況，有一個通用的度量指標，即網絡收斂指標，是通過網絡中斷服務（或故障恢復）時間來考察設備或網絡提供的可靠性。

    任何一種網絡路由協議或拓撲管理協議都是為了在動態變化的網絡中提供一個可行的流量路徑而設計的，所以收斂是一個基本屬性。從注入拓撲變化或故障發生的時間開始，網絡服務和數據流量受到影響，在拓撲收斂後路徑切換到備份網絡上，恢復網絡服務和流量所經歷的時間就是收斂時間。為加速收斂而提出的一些附加技術可以使收斂時間縮短到毫秒級甚至在設備主控發生重啟等情況下提供不中斷的轉發服務。

圖4 IGP路由收斂測試組網圖

    IGP收斂的測試實例。

    如圖4所示，被測試設備首先從B和C埠學習到大量的IGP路由信息，其中B埠的度量值優於C埠。測試儀器用穩定的流量由A埠發送，被測設備轉發到B埠。測試儀器通過在B埠模擬拓撲變化，撤銷一部分路由信息，受影響的流量開始丟失。被測試設備在完成路由計算後將這些流量重新路由到C埠上。測試儀器通過計算這個過程丟失的數據流量和發送速率折算收斂過程經歷的時間。

    在收斂網絡之外來評估收斂時間時，可以使用相同的原則，根據發送流量的速率和被丟失報文數量計算出收斂經歷的時間。收斂測試的另一個方向是故障恢復主路徑時，對於流量的保護。理想的情況可以做到網絡無中斷地回切到主路徑。然而不同的拓撲管理協議和具體實現技術有一定差別，很多情況下回切過程的流量丟失不能完全避免。

    常見的收斂指標測試有二層網絡STP收斂測試，RPR和RRPP環網收斂，三層路由協議RIP、OSPF、BGP收斂，以及雙主控設備的主備倒換測試，VRRP設備倒換測試。為了減少拓撲管理協議在設備重啟期間對周邊網絡的衝擊，很多協議開發了Graceful Restart的功能，並通過控制與數據轉發分離的Non-Stop Forwarding技術使流量轉發近乎不中斷。H3C的IRF2技術也可以將多個物理設備組成一個邏輯設備，以降低對STP、VRRP等慢收斂協議的依賴。所有這些技術的目標都是減少設備故障造成的網絡影響，提高組網的可靠性，而評價這些技術的指標都是網絡收斂時間。測試執行的步驟幾乎是相同的，首先構建正常的網絡拓撲，模擬故障發生，監測流量切換的過程和流量丟失的情況，計算切換需要的時間。

結束語

    以上的幾種測試類型基本覆蓋了軟體可靠性相關的測試。在具體的產品開發過程中，協議健壯性測試、硬體故障模擬測試、內存耗盡測試等適合在軟體功能組件的開發過程中進行測試，而壓力測試、收斂指標測試、拷機測試需要在系統整合併且功能穩定後才能實施，所以一般放在產品開發後期。經過全方位的可靠性測試並解決所有問題之後，軟體系統可以應對各種內部外部的複雜情況，為用戶提供更高可用性的健壯網絡。