自動軟件測試讓您可以在一段時間內運行相同的測試，從而確保您所比較的內容具備真正的可比性。在本文中， Linux Test Project 團隊的成員們分享了他們對 Linux? 內核進行壓力所使用的測試的方法、原理以及腳本和工具。 在對 Linux 內核版本穩定性的測試中，需要明確地聲明並證明為什麼版本是穩定的或者是不穩定的。 然而還沒有被證明和證實當前現有的系統范圍內的壓力測試可以測試 Linux 內核整體上的穩定性。 本文給出了一個創建系統范圍內 Linux 壓力測試並證明其結果正確性的方法。不同的 Linux 開發者、 用戶和發行版本會使用他們自己的方法來測試內核的穩定性。不過，關於他們決定運行哪些測試、覆蓋的代碼、 達到的壓力級別等的基礎信息都沒有發布，這就大大降低了結果的價值。 使用實驗室的機器以及來自 Linux Test Project 測試套件的測試，我們基於系統資源的利用率統計開發了一個 測試的組合，為系統提供足夠的壓力。我們對這個組合測試進行了分析，以確定 Linux 內核的哪些部分在測試 執行中得到了使用。然後，我們修改了組合測試，在保持期望的高強度系統壓力的同時提高代碼覆蓋率的百分比。 最終得到的壓力測試涵蓋了 Linux 內核的足夠多部分，有助於穩定性聲明，並且有系統使用情況和內核代碼覆蓋情況的數據來支持它。 這一組合測試方法的四個步驟是：測試選擇、系統資源利用率評價、內核代碼覆蓋分析以及最終的壓力測試評價。
選擇測試 測試選擇包括選擇達成兩方面目的的測試： - 測試應該可以得到 CPU（s）、內存、I/O 和網絡等主要內核區域的高水平的資源利用率。 - 測試應該充分地覆蓋內核代碼，以幫助支持自其結果中生成的穩定性聲明。 只要有可能，都要使用自動化的或者易於修改的測試，以支持自動操作。自動操作可以使得測試 更快而且可以重復進行，並幫助降低人為錯誤的風險。選擇合適的測試時需要考慮的另一個方面是， 使用可以自由發布結果的應用程序。最好是選擇堅決擁護開放源代碼方法 和/或 GPL 的測試和測試套件，以助於確保 發布過程的簡便。
評價系統資源利用率 所選擇的測試的組合必須給系統的資源帶來足夠的壓力。Linux 內核的四個主要方面可以影響系統的 響應和執行時間： - CPU：用於在機器的 CPU（s）上處理數據的時間。 - Memory：用於自真實存儲器中讀寫數據的時間。 - I/O：用於自磁盤存儲器讀寫數據的時間。 - Networking：用於自網絡讀寫數據的時間。 測試設計者應該使用下面這兩個著名的且廣為應用的開放源代碼 Linux 資源監控工具來評價資源利用率水平。 （請參閱本文稍後的 參考資料 以獲得下載這些工具的鏈接。） - top：由 Albert D. Cahalan 維護著的一個開放源代碼工具， 包含於大部分 Linux 發行版本中，可用於當前的 2.4 和 2.6 內核。 - sar：另一個開放源代碼工具；它由 Sebastien Godard 維護。 這個工具也包含於大部分 Linux 發行版本中，可用於當前的 2.4 和 2.6 內核。 方法中的系統資源利用率評價階段通常需要多次嘗試才能得到合適的測試組合，並得到期望水平的利用率。 當確定測試組合時，過度利用總是一個至關重要的問題。例如，如果選擇的組合過於受 I/O 所限，可能會 導致 CPU 的測試結果不好，反之亦然。方法的這一部分主要是大量的試驗和出錯，直到所有資源達到期望 水平。 top 工具可用於迅速確定每個測試影響哪個資源（CPU、內存或者 I/O），並實時地顯示出它們使用了多少資源。 sar 工具用於收集一段時間內的網絡利用率統計數據，並將所有利用率數據的快照記錄到一個文件。 當選定一個組合後，測試必須長時間運行以准確評價資源的利用率。測試運行的時間長短取決於每個測試的長度。 假如多個測試同時運行，則時間必須足夠長以使得這些測試中最長的那個可以完成。在這個評價過程中，sar 工 具也應該在運行。在評價運行的結論中，您應該收集並評價所有四種資源的利用率水平。 下面的例子顯示了 sar 輸出的 CPU、內存和網絡利用率： 清單 1. sar 的輸出示例 10:48:27 CPU %user %nice %system %iowait %idle 10:48:28 all 0.00 0.00 0.00 0.00 100.00 10:48:29 all 3.00 0.00 1.00 0.00 96.00 10:48:30 all 100.00 0.00 0.00 0.00 0.00 10:48:31 all 100.00 0.00 0.00 0.00 0.00 02:27:31 kbmemfree kbmemused %memused kbswpfree kbswpused %swpused 02:29:31 200948 53228 20.94 530104 0 0.00 02:31:31 199136 55040 21.65 530104 0 0.00 02:33:31 198824 55352 21.78 530104 0 0.00 02:35:31 199200 54976 21.63 530104 0 0.00 02:27:31 IFACE rXPck/s txpck/s rxbyt/s txbyt/s 02:29:31 eth0 738.79 741.66 76025.55 136941.85 02:31:31 eth0 743.30 744.97 76038.82 136907.77 02:33:31 eth0 744.80 745.02 76135.53 136901.38 02:35:31 eth0 742.35 744.34 75947.45 136864.77
分析內核代碼覆蓋率 獲得足夠的內核覆蓋率是系統壓力測試的另一個職責。盡管所選的測試組合充分地利用了四種主要資源，它 也有可能只是執行了內核的一小部分。因而，您應該對覆蓋率進行分析以確保組合可以成為一個系統壓力 測試，而不是一個系統負載生成器。當前，有兩個開放源代碼工具可以幫助進行 Linux 內核的代碼覆蓋率分析： - gcov：一個由 Linux Test Project 維護的開放源代碼工具。 這個工具分析內核代碼的覆蓋率，並報告哪些行、函數和分支被覆蓋以及它們被訪問了多少次。 - lcov：另一個由 IBM 開發，由 Linux Test Project 維護的開放源代碼工具。 這個工具由一組構建於基於文本的 gcov 輸出之上的 Perl 腳本構成，以實現基於 Html 的輸出。 輸出包括覆蓋率百分比、圖表以及概述頁，可以快速浏覽覆蓋率數據。您可以自 Linux Test Project（LTP）主頁 找到這兩個工具（參閱 參考資料 以獲得鏈接）。 gcov 模塊加載以後，所有運行於系統壓力測試組合中的測試都必須執行。盡管原來的系統壓力測試可以同時執行， 也應該同時執行，但是這次運行應該是循環進行的。每個測試都應該運行一次直到結束，一個接一個地運行， 不能重復運行任何測試。單個地、循環地運行，是為了減少在同時運行多個系統壓力測試時，內核嘗試 去平衡它們的負載而導致的不可預知的和無目的的內核代碼執行。您應該在最後一個測試運行結束後再進行 gcov 分析。由於最終是要格式化數據以進行分析，所以運行 lcov 工具並?載 gcov 模塊。 lcov 工具會生成一棵完整的 HTML 樹，其中包含有內核中代碼的每一行以及關於每一行執行了 多少次的數據（如果有的話）。這個工具會量化覆蓋率數據並生成關於內核中每一部分和 文件覆蓋率的百分比數字。下面的例子展示了一個示例性的代碼覆蓋率輸出： 圖 1. gcov 輸出示例 lcov 維護者定義了“足夠的覆蓋”（綠色的），因而這個 lcov 示例僅僅是一種評價。不過，所包括的 原始數據讓任何浏覽者都可以做出他或她自己的判斷。在浏覽了覆蓋率分析後，測試創建者現在可以修改 測試的組合，以改變 和/或 增加所覆蓋的代碼的數量。
評價最終壓力測試 之所以要執行方法中的這最後一步，是為了對系統壓力測試進行核實。在一個被認為是穩定的內核上執行壓力測試； 通常，發行版本中的內核可以滿足這一要求，但不總是如此。要長時間地執行壓力測試（推薦至少 24 個小時），同 時運行 sar 工具，原因有以下兩點： - 長時間運行有助於發現組合中的所有問題，否則，在短時間的“取樣測試（sniff test）”中這些問題可能會被忽略。 - sar 生成的數據構成以後測試運行中進行比較的基線。 長時間運行結束後，您現在可以基於收集的所有數據來決定這個測試組合是否是系統壓力測試的合適候選者。 圖 2. 設計過程總結 Linux Test Project 在設計 Linux 內核壓力測試腳本 ltpstress.sh 時使用了這一設計方法。 這個應用程序組合了來自 LTP 的測試套件不同方面的多個測試以及內存和網絡傳輸負載生成器。 在執行之前，測試會根據系統中存在多少物理和虛擬內存來調整其總的內存使用情況。這個測試 腳本可以自 LTP 測試套件獲得（見 參考資料）。為了確保結果的 准確性，這個腳本創建於受控的實驗室條件下。 IBM Linux Technology Center Test 部門使用這個壓力測試以及其他工具和測試作為幫助確認 Linux 內核發行版本穩定性的一個相對快速和簡便的途徑。為幫助確保得到足夠的覆蓋率，測試既 在實驗室條件下也在模擬的用戶情形下進行。
