Linux 標準測試的設計過程

層級: 初級

Robert Williamson （robbiew@us.ibm.com）
軟體工程師, Linux Technology Center, IBM

自動軟體測試讓您可以在一段時間內運行相同的測試，從而確保您所比較的內容具備真正的可比性。在本文中，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 核心發行版本穩定性的一個相對快速和簡便的途徑。為協助確保得到足夠的覆蓋率，測試既 在實驗室條件下也在類比的使用者情形下進行。

參考資料
- 在 Linux Test Project 首頁 下載壓力測試 shell 指令碼以及其他一些實用的測試。

- IBM Linux Technology Center 的使命是 直接與 Linux 開發社區合作以共同促進 Linux 的成功。

- OSDL 的 Linux Kernel Scalable Test Platform（STP） 提供了一個架構，開發人員可以通過它使用一個線上的效能和可擴充性套件來 測試核心補丁。

- LTP 壓力測試使用的工具包括 top （procps 程式包的一部分）和 sar （systat 的一部分）。

- 此外，LTP 壓力測試還充分利用了 GNU 測試覆蓋率的程式 gcov 以及它的基於 Perl 的將 gcov 結果轉化為 HTML 的工具（HTMLizer）lcov。

- 核心比較：從 2.4 到 2.6 核心開發中的改進 （developerWorks，2004 年 2 月）介紹了使得 2.6 比以前的任何核心更好的工具、 測試和技術。

- 核心比較：2.4 和 2.6 上的 Web 服務（developerWorks，2004 年 2 月） 描述了 IBM Linux Technology Center 的 Web 服務測試工作的成果。

- 在 測試 Linux 的可靠性 （developerWorks，2003 年 12 月） 為 IBM Linux Technology Center 所做的關於 Linux 核心和其他核心 OS 組件的測試結果與分析 提供了檔案資料。

- Linux 核心調試器內幕（developerWorks，2003 年 6 月）向您展示了如何追蹤 核心的執行並檢查它的記憶體和資料結構。

- 在 developerWorks Linux 專區 可以找到 更多為 Linux 開發人員準備的參考資料。

- 購買 Developer Bookstore Linux 區 打折出售的 Linux 書籍。

- 通過 developerWorks Subscription 使用最新的 IBM 工具和中介軟體來開發與測試您的 Linux 應用程式：您可以自 WebSphere?、DB2?、 Lotus?、Rational?和 Tivoli? 擷取 IBM 軟體，以及一個可以在 12 個月內使用這些軟體的許可，所有的花費都比您想像的要低。

- 自 developerWorks 的 為您的 Linux 應用開發加油提速 專區下載可以運行於 Linux 之上的經過挑選的 developerWorks Subscription 產品免費測試版本，包括 WebSphere Studio Site Developer、WebSphere SDK for Web services、WebSphere Application Server、DB2 Universal Database Personal Developers Edition、Tivoli Access Manager 和 Lotus Domino Server。要更快速地開始上手，請參閱針對各個產品的 how-to 文章和支援人員。

關於作者
Robbie Williamson 是 IBM Linux Technology Center 的專職軟體工程師。 他於 2000 年畢業於德克薩斯州立大學，獲電腦科學學士學位。在他的職業生涯中， 他當過技術支援人員、驗證工程師，以及各種 UNIX 實現的開發人員。Robbie 當前是 Linux Test Project 的維護者之一，可以通過 robbiew@us.ibm.com與他聯絡。

註：本文只代表作者的觀點，並不代表 IBM 的觀點。本文中討論的研究結果的基礎是 一個在實驗室環境下建立並測試的方案。這些研究結果可能不會在所有的使用者環境中得到，而且， 在那些環境中實現需要進行另外的步驟、配置和效能分析。在這裡給出的是原封不動的資訊，沒有保證、 說明或暗指。本資料不是任何 IBM 產品保證的說明或組成部分。解決方案的實現和證明由實現團隊負責。

全文出自 : IBM developerWorks 中國網站