qileilove

軟件測試中用正交實驗法設計測試用例

正交實驗法的由來

一、正交表的由來

拉丁方名稱的由來

古希臘是一個多民族的國家，國王在檢閱臣民時要求每個方隊中每行有一個民族代表，每列也要有一個民族的代表。

數學家在設計方陣時，以每一個拉丁字母表示一個民族，所以設計的方陣稱為拉丁方。

什么是n階拉丁方？

用n個不同的拉丁字母排成一個n階方陣（n<26 ），如果每行的n個字母均不相同，每列的n個字母均不相同，則稱這種方陣為n*n拉丁方或n階拉丁方。每個字母在任一行、任一列中只出現一次。

什么是正交拉丁方？

設有兩個n階的拉丁方，如果將它們疊合在一起，恰好出現n2個不同的有序數對，則稱為這兩個拉丁方為互相正交的拉丁方，簡稱正交拉丁方。

例如：3階拉丁方

用數字替代拉丁字母：

二、正交實驗法

正交試驗設計(Orthogonal experimental design)是研究多因素多水平的又一種設計方法，它是根據正交性從全面試驗中挑選出部分有代表性的點進行試驗，這些有代表性的點具備了“均勻分散，齊整可比”的特點，正交試驗設計是分式析因設計的主要方法。是一種高效率、快速、經濟的實驗設計方法。

日本著名的統計學家田口玄一將正交試驗選擇的水平組合列成表格，稱為正交表。例如作一個三因素三水平的實驗，按全面實驗要求，須進行33=27種組 合的實驗，且尚未考慮每一組合的重復數。若按L9(33) 正交表按排實驗，只需作9次，按L18(37) 正交表進行18次實驗，顯然大大減少了工作量。因而正交實驗設計在很多領域的研究中已經得到廣泛應用。

利用因果圖來設計測試用例時, 作為輸入條件的原因與輸出結果之間的因果關系,有時很難從軟件需求規格說明中得到。往往因果關系非常龐大,以至于據此因果圖而得到的測試用例數目多的驚人，給軟件測試帶來沉重的負擔，為了有效地,合理地減少測試的工時與費用,可利用正交實驗設計方法進行測試用例的設計。

正交實驗設計方法:依據Galois理論,從大量的（實驗）數據（測試例）中挑選適量的、有代表性的點（例），從而合理地安排實驗（測試）的一種科學實驗設計方法。類似的方法有:聚類分析方法、因子方法方法等。

三、利用正交實驗設計測試用例的步驟：

（1）提取功能說明,構造因子--狀態表

把影響實驗指標的條件稱為因子，而影響實驗因子的條件叫因子的狀態。

利用正交實驗設計方法來設計測試用例時，首先要根據被測試軟件的規格說明書找出影響其功能實現的操作對象和外部因素，把他們當作因子；而把各個因子 的取值當作狀態。對軟件需求規格說明中的功能要求進行劃分，把整體的、概要性的功能要求進行層層分解與展開，分解成具體的有相對獨立性的、基本的功能要 求。這樣就可以把被測試軟件中所有的因子都確定下來，并為確定每個因子的權值提供參考的依據。確定因子與狀態是設計測試用例的關鍵。因此要求盡可能全面 的、正確的確定取值，以確保測試用例的設計作到完整與有效。

（2）加權篩選,生成因素分析表

對因子與狀態的選擇可按其重要程度分別加權?？筛鶕鱾€因子及狀態的作用大小、出現頻率的大小以及測試的需要，確定權值的大小。

（3）利用正交表構造測試數據集

利用正交實驗設計方法設計測試用例，比使用等價類劃分、邊界值分析、因果圖等方法有以下優點：節省測試工作工時；可控制生成的測試用例數量；測試用例具有一定的覆蓋率。

在使用正交實驗法時，要考慮到被測系統中要準備測試的功能點，而這些功能點就是要獲取的因子或因素，但每個功能點要輸入的數據按等價類劃分有多個，也就是每個因素的輸入條件，即狀態或水平值。

四、正交表的構成

行數(Runs)：正交表中的行的個數，即試驗的次數，也是我們通過正交實驗法設計的測試用例的個數。

因素數(Factors) ：正交表中列的個數，即我們要測試的功能點。

水平數(Levels)：任何單個因素能夠取得的值的最大個數。正交表中的包含的值為從0到數“水平數-1”或從1到“水平數” 。即要測試功能點的輸入條件。

正交表的形式：

L_行數(水平數^因素數)

如：L₈(2⁷)

五、正交表的正交性

整齊可比性

在同一張正交表中，每個因素的每個水平出現的次數是完全相同的。由于在試驗中每個因素的每個水平與其它因素的每個水平參與試驗的機率是完全相同的，這就保證在各個水平中最大程度的排除了其它因素水平的干擾。因而，能最有效地進行比較和作出展望，容易找到好的試驗條件。

均衡分散性

在同一張正交表中，任意兩列（兩個因素）的水平搭配（橫向形成的數字對）是完全相同的。這樣就保證了試驗條件均衡地分散在因素水平的完全組合之中，，因而具有很強的代表性，容易得到好的試驗條件。

用正交實驗法設計測試用例

以上介紹了正交實驗法的由來。怎么用正交實驗法進行用例的設計呢？

一、用正交表設計測試用例的步驟

(1) 有哪些因素（變量）

(2) 每個因素有哪幾個水平（變量的取值）

(3) 選擇一個合適的正交表

(4) 把變量的值映射到表中

(5) 把每一行的各因素水平的組合做為一個測試用例

(6) 加上你認為可疑且沒有在表中出現的組合

二、如何選擇正交表

• 考慮因素（變量）的個數
• 考慮因素水平（變量的取值）的個數
• 考慮正交表的行數
• 取行數最少的一個

三、設計測試用例時的三種情況

（1）因素數（變量）、水平數（變量值）相符

（2）因素數不相同

（3）水平數不相同

四、我們來看看第一種情況:

（1）因素數與水平數剛好符合正交表

我們舉個例子：

這是個人信息查詢系統中的一個窗口。我們可以看到要測試的控件有3個：姓名、身份證號碼、手機號碼，也就是要考慮的因素有三個；而每個因素里的狀態有兩個：填與不填。

選擇正交表時分析一下：

1、表中的因素數>=3；

2、表中至少有3個因素數的水平數>=2；

3、行數取最少的一個。

從正交表公式中開始查找，結果為：

L₄(2³)

變量映射：

測試用例如下：

1：填寫姓名、填寫身份證號、填寫手機號

2：填寫姓名、不填身份證號、不填手機號

3：不填姓名、填寫身份證號、不填手機號

4：不填姓名、不填身份證號、填寫手機號

增補測試用例

5：不填姓名、不填身份證號、不填手機號

從測試用例可以看出：如果按每個因素兩個水平數來考慮的話，需要8個測試用例，而通過正交實驗法進行的測試用例只有5個，大大減少了測試用例數。用最小的測試用例集合去獲取最大的測試覆蓋率。

（2）因素數不相同

如果因素數不同的話，可以采用包含的方法，在正交表公式中找到包含該情況的公式，如果有N個符合條件的公式，那么選取行數最少的公式。

（3）水平數不相同

采用包含和組合的方法選取合適的正交表公式。

正交實驗法的又一個例子

上面就正交實驗法進行了講解，現在再拿PowerPoint軟件打印功能作為例子，希望能為大家更好地理解給方法的具體應用

假設功能描述如下：

• 打印范圍分：全部、當前幻燈片、給定范圍 共三種情況；
• 打印內容分：幻燈片、講義、備注頁、大綱視圖 共四種方式；
• 打印顏色/灰度分: 顏色、灰度、黑白 共三種設置；
• 打印效果分：幻燈片加框和幻燈片不加框兩種方式。

因素狀態表：

我們先將中文字轉換成字母，便于設計。得到：

因素狀態表：

我們分析一下：

被測項目中一共有四個被測對象，每個被測對象的狀態都不一樣。

選擇正交表：

1、表中的因素數>=4

2、表中至少有4個因素的水平數>=2

3、行數取最少的一個

最后選中正交表公式：

L₁₆(4⁵)

正交矩陣為：

用字母替代正交矩陣：

　　在測試過程中，測試人員經常需要將測試對象的各種輸入參數進行組合之后進行測試。有時候，將各種輸入參數進行組合，得到的測試用例數目將是非常龐大的。由于測試時間和成本的限制，無法對測試對象輸入值的所有組合進行測試。下面是某個網站測試的要求：

　　------------案例描述：開始-------------

　　某網站需要支持

　　● 不同的瀏覽器：IE5.0、IE5.5、IE6.0、Netscape6.0、Netscape6.1、Netscape7.0、Mozilla1.1和Opera7；

　　● 不同的插件：RealPlayer、MediaPlayer或者沒有任何插件None；

　　● 不同的客戶端操作系統：Windows95、Windows98、WindowsME、、WindowsNT、Windows2000和WindowsXP；

　　● 不同的Web服務器軟件：IIS、Apache和WebLogic；

　　● 不同的服務器端操作系統：WindowsNT、Windows2000和Linux。

　　這種情況下，需要針對不同的組合進行測試：

　　● 8種瀏覽器

　　● 3種插件

　　● 6種客戶端操作系統

　　● 3種Web服務器軟件

　　● 3種服務器端操作系統

　　如果考慮所有參數不同取值的組合，那么需要設計和執行的測試用例的數目是1296（8 x 3 x 6 x 3 x 3 = 1296）。

　　------------案例描述：結束-------------

　　在軟件測試過程中，這種類型的組合是非常普遍的。每種情形都可能有龐大的組合需要進行測試，假如不對它們進行測試，可能會存在較大的風險；而如果對所有組合進行測試，測試時間和資源又不允許。測試人員在面對這種情況的時候，可以采用以下幾種常用的策略：

　　● 嘗試測試所有輸入的組合，延期項目，導致的后果可能是失去產品的市場。

　　● 選擇一些容易設計和執行的測試用例，而忽略其是否能夠提供產品質量的信息。

　　● 羅列所有的組合，并隨機選擇其中的子集進行測試。

　　● 采取特殊的測試技術，選擇能發現大部分缺陷的子集進行測試。

　 　如果采用最后一個策略，那么使用結對測試技術是一個很好的選擇。采用結對測試的技術，測試并不針對輸入值的所有組合進行測試，而只是針對所有輸入值的兩 兩組合。結對測試技術可以顯著地減少測試用例的數目，同時保證較高的測試質量。下面是應用結對測試技術減少測試用例數目的例子：

　　● 假如軟件系統有四個不同的輸入參數，每個參數有3個不同的輸入值，得到的完全組合數目是34即81。假如采用結對測試的技術，只需要9個測試用例即可覆蓋所有參數的兩兩組合。

　　● 假如軟件系統有13個不同的輸入參數，每個參數有3個不同的輸入值，得到的完全組合數目是313即1594323。假如采用結對測試的技術，只需要15個測試用例即可覆蓋所有參數的兩兩組合。

　　● 假如軟件系統有20個不同的輸入參數，每個參數有10個不同的輸入值，得到的完全組合數目是1020。假如采用結對測試的技術，只需要180個測試用例即可覆蓋所有參數的兩兩組合。

　　結對測試技術能夠發現所有的單模式失效（Single-mode Fault）和雙模式失效（Double-mode Fault）。但是，結對測試并不一定適合于發現測試對象中的多模式失效（Multimode Fault）。

　　● 單模式失效：失效是由單個參數引起的，只要針對所有獨立參數進行測試，就能夠發現該失效。

　　● 雙模式缺陷：失效是由兩個參數共同引起的，必須針對所有參數的兩兩組合進行測試，才能夠確保發現此類缺陷。

　　● 多模式缺陷：失效是由三個或三個以上參數共同引起的，采用結對測試技術也可能發現多模式缺陷，但是不能保證測試的充分性。

　　摘要：本文通過對測試原則與用況驅動思想的分析，提出了用況驅動系統測試用例設計的思想。從功能性測試、性能測試、回歸測試等三方面，闡述了該思想在測試用例設計過程中的必要性和應用方式。并重點以功能性測試為例，給出一些該思想應用于實踐的方法和經驗。

　　關鍵詞：用況驅動；系統測試；測試用例設計

　　一、系統測試用例設計原則和優點

　　軟件測試是為了發現錯誤而執行程序的過程，一般來說橫跨軟件生命周期的兩個階段：開發階段和測試階段。其中開發階段的測試工作主要是指單元測試和集成測試，一般由開發人員完成；測試階段是軟件生命周期的一個獨立階段，主要的任務是進行系統測試，由專門的測試人員完成。無論單元集成測試，還是系統測試，都應該進行必要的測試用例設計，本文的側重點在于系統測試的用例設計。

　　系統測試在待測系統組裝到一起并通過了單元和集成測試之后進行，一般采用黑盒測試的 方式，側重于測試軟件的功能性需求，兼顧性能、壓力等各方面的因素。系統測試的意圖在于發現系統與用戶期望的差距，通過測試暴露出軟件中隱藏的錯誤和缺 陷，權衡并改進系統。Davis曾經提出了一組測試原則，其中包括兩點：一是所有測試都應該可以追溯到用戶需求；二是窮舉測試是不可能的。

　 　正如我們所知，軟件測試的目的在于發現錯誤，而最嚴重的錯誤莫過于導致程序無法滿足需求的錯誤。因此測試用例的設計必須充分考慮用戶需求，是否正確的滿 足了用戶需求是判別一個軟件系統是否能夠通過測試，是否合格產品的最重要標準。在實際的測試工作中，追求系統測試用例對用戶明示和隱含需求的100%覆 蓋，試圖窮舉用戶需求進行測試是不現實的。系統測試用例的設計原則應該是盡可能覆蓋用戶工作中使用本系統的各種工作場景和情況（包括正常方式使用和異常方 式使用的情況），至少應完全覆蓋用戶日常工作使用系統的全部場景和情況。

　　用況驅動（Use-Case Driven）是統一過程（UP）的核心思想之一，也是其精髓所在。統一過程的目標是指導開發人員有效的實現并實施滿足用戶需求的系統。統一過程一般被認為是一種OO（面向對象）開發方法，實際上它的思想也同樣支持非OO系統的開發。統一過程特點在于：用況驅動、以框架為中心、迭代和增量的。

　 　用況（Use-Case）的目的在于捕獲真正的需求和使用適于用戶、客戶、開發、測試等各方人員理解的形式將捕獲到的需求加以描述。它幾乎普遍用于捕獲 軟件系統需求。但它的作用不僅如此，還能夠驅動整個開發過程，在尋找和確定類、子系統和接口、尋找和確定測試用例、規劃開發迭代和系統集成時，均可以將用 況作為主要輸入。因而可以毫不夸張地說，在應用統一過程思想指導軟件開發過程中，用況的驅動作用貫穿整個軟件生命周期。

　　用況驅動設計與 開發過程的思想，目前已被軟件業內人士廣泛接受，并越來越多地付諸于實踐；而用況驅動思想在測試領域的實踐中卻并未得到應有的重視。我們的測試團隊也經歷 了一個對此思想逐步認知的過程，在工作實踐中積累了一些相關的思路和方法，并且還在繼續摸索，希望能對測試過程持續改進。

　　與傳統系統測試用例設計相比，強調用況驅動的思想會體現出一定的優越性。

　 　首先，利于系統測試用例貼近用戶需求。用況描述用戶對系統的期望和真正的需求，這恰恰與系統測試的主要目標不謀而合。因此系統測試用例的設計由用況驅 動，以用況為輸入，實現對用況的追蹤與覆蓋，是確保系統測試用例設計滿足功能和場景覆蓋，達到系統測試用例設計的質量要求的捷徑。

　　其次，便于與其它小 組溝通，便于對用戶需求實施追蹤。若該項目的需求、設計、開發、維護等過程同樣以統一過程思想、用況驅動的思想作為指導，則在整個項目內部更易形成溝通， 在該軟件系統生命周期涉及到的各個產物之間能很容易的進行追蹤。將以用況為指導形成的系統測試用例應用于測試活動，得到的測試結果直接體現用戶需求的實施 情況。

　　二、用況驅動系統測試用例設計實踐

　　用況是需求分析階段的產物，系統測試用例的質量在一定程度上依賴于用況的質量，只有用況描述的真實、全面、易理解，系統測試用例才有可能達到相應的質量目標。

　　對于系統測試的分類，業界有很多種說法，不盡相同。最常見的包括：功能性測試、性能測試、回歸測試等。下面將主要就功能性測試，說明用況驅動思想在其測試用例設計過程中的作用；同時說明用況驅動思想對性能測試和回歸測試用例選取原則的影響。

　　1．功能性測試

　?。?）用況驅動功能性測試的組成

　 　傳統概念中的功能性測試和性能測試主要是針對功能點進行的，這主要源于傳統的軟件功能相對單一、獨立。當前軟件發展趨勢，越來越綜合化、系統化、全面 化，軟件系統越來越龐大、復雜，單一、割裂的功能點往往難以滿足用戶實際需求，將各功能點按用戶實際使用場景，以不同的順序組合起來，才能真正滿足用戶實 際應用的需要。換言之，用戶的需求可以體現為一個個用況，而用況在系統中的實現則體現為功能點的有序組合。

　　第二種，可在同一張用況圖中以分層的方式描述出功能點/場景（用況）-測試點-測試用例的逐級細化關系。例如圖2，這是以用況圖形式體現的用戶權限管理部分的功能點-測試點的細化。

圖2 用況圖描述功能細化舉例

　　第三種，可采用狀態轉移圖、活動圖、順序圖、協作圖等方式或者將它們結合以對測試用例加以描述。

　　2）測試用例包的組織形式

　　描述測試用例包中測試用例的順序和條件限制關系，并不拘泥于具體的形式。我們曾采用過兩種方式，即表格形式和動圖形式。

　　例如：前面提到的業務流程正常流轉用況的測試用例以及相關功能點測試用例可以以下面的表格形式體現。

　　在活動圖中，使用對子活動的嵌套，可以實現在當前測試用例中對其它測試用例的引用，從而方便的實現了測試用例間的組合重用，完成了測試用例包的組織。

　　2. 性能測試

　　廣義上的性能測試一般包括常態下的性能測試、壓力測試和負載測試等，而實際工作中經常遇到的性能測試往往是對典型用 戶環境下使用情況的模擬，在此基礎上所進行并發性和持續性壓力測試，而并非考驗系統極限值的測試。系統的性能指標和性能測試所遵循的都應該是“適度”原 則。系統性能指標優越，性能測試充分當然好，但是這是要付出高昂的代價的。實際上，實際而有效的性能測試也應該是由用況驅動的，是針對用戶使用場景所設計 的，需要根據用戶對各項指標所提出的明確需求，或者根據用戶現場的實際情況，結合測試人員的經驗設計出相應的性能測試方案和數據，并依照實施。

　　例如：一個正常情況下最多只有50個并發用戶的系統，就沒有必要進行1000個用戶的并發測試，而一個每天夜間自動重起的系統，就沒必要對其實施持續一周的負載測試。

　　3．回歸測試

　　用況驅動的思想同樣指導回歸測試用例的選取。由于時間和成本的限制，每次回歸測試，都將所有功能和場景重新測試一遍是不現實的，如何能既盡量降低風險，又提高測試效率呢？就需要在測試用例選取的過程中注意把握平衡。

　　回歸測試用例的組織應該是分層次、分優先級的，基于用戶最常用的場景的測試用例處于最高優先級。每次執行回歸測試 時，基于軟件修改所影響的范圍，根據時間、人員、成本等因素，按照優先級次序抽取適量的相關測試用例，構造一個優化的測試用例組來完成回歸測試，才是正確 的選擇。

　　三、結語

　　用況驅動系統測試用例設計，是軟件系統發展的需要，更符合軟件生命周期的規律，廣泛應用于功能性測試、性能測試、回歸測試等各測試領域。用況驅動系統測試用例設計之路尚在探索之中，并無定式，在實踐中不斷嘗試和改進才是提高測試用例設計水平、提高軟件質量的正確途徑。

　　上一篇關于測試用例設計的博文《設計測試用例的四條原則》中，介紹了設計測試用例的四條原則。本篇結合最近工作遇到的一個小插曲，介紹一下測試用例本身Passed和Failed的有效性問題。

　 　我所在的團隊上個 Sprint有一項很重要的工作，就是進行Stress 測試，需要編寫自動化用例測試模擬程序長時間的執行，并觀察其內存消耗是否呈現合理的增長趨勢，以及有沒有內存的泄漏等問題。同事很快編寫好了測試用例， 并執行了個把個小時，得出了初步的數據。數據顯示程序的表現相當完美，不僅內存沒有陡峭的突變，甚至連大斜率的線性增長也木有，基本呈現為一條略有波動的 水平直線。非常讓人振奮，這樣的表現打消團隊之前的擔心，完成這項工作所需的時間也將大大小于之前的預估。

　　我對這項測試也非常感興趣， 并和同事進行了一些交流，想深入了解一些更詳細的情況，比如測試數據規模、執行的時間長短、測試數據分布等，隨著交流的深入同事突然意識到似乎測試代碼似 乎有些不大合乎常理的表現，進一步調試發現代碼中一段生成數據的代碼并沒有正確生成數據，雖然測試仍在執行但輸入的數據沒有，測試只是在空轉，并沒有真正 執行被測程序的邏輯，所以整個曲線才呈現為一條水平線。

　　這件事本身是個小問題，但其背后隱藏著一個值得我們深究的問題：當你的測試用例Passed的時候，被測產品果真是正確的嗎？仔細想想這個問題，可以得到一些對我們的測試工作有意的思考：

　　1. 自動化測試需要有詳細的日志輸出，以便于診斷測試的確切執行情況。

　 　自動化測試用例的執行過程對我們來說是一個黑盒過程，我們一般只是看到它的結果是Passed或者Failed。如果這個黑盒過程本身就是錯誤的，如本 文一開始所給出的例子，結果是Passed就沒有任何意義了。而且這樣的Passed只會是給問題雪上加霜，減少了發現問題的可能性。

　　2. 測試人員特別是自動化測試工程師，應該對那些看似完美的東東多些疑問，多些探究精神，在經過客觀途徑驗證之前時刻保持謹慎的樂觀。

　　從某個角度講，經常Failed測試用例并不值得你太擔心，而那些從來都是Passed的用例，應該是值得你抽時間檢查的對象。

　　3. 測試用例要么Passed要么 Failed，看似簡單的結果，但其中還是有些值得深究的內容的。

　 　任何一個測試用例實際上是肩負著雙重責任： 其一，保證在被測功能正確的情況下，測試用例應該是Passed；其二，則是在被測功能異常的情況下，測試返回Failed。一般的情況下，我們只是驗證 了第一種情況后就算完成，并將用例提交到用例管理庫或者代碼庫中。很少真正有人去驗證一下在被測試功能異常的情況下，測試用例確實Failed。這樣的用 例驗證可以總結為如下的模式：

　 　之所以會有這樣的情況，首先，是因為從意識上講，大多數人都認為測試中對被測功能行為的判斷以足夠強壯，但其實這種沒有客觀佐證的判斷并不可靠；其次， 很多用例的實現和執行多是在被測功能實現之后才開始，這時的被測功能剛實現出來，并經過開發人員反復調試修改，絕大多數情況下都是正確的，由于產品代碼已 經提交，此時很難再有簡單的途徑模擬出錯誤的功能行為，以驗證測試用例Failed的情況。

　　解決的辦法有兩種：一、盡可能尋找途徑去模擬被測功能的異常；二、再就是合理選擇實現測試用例的時間。很多情況我們的用例是為了覆蓋已有的Bug而添加的，以避免回歸缺陷。這樣的測試用例最好是在Bug修復之前就實現，那么它一定是Failed，這個機會就可以驗證出Failed情況。

　　擴展一下這個話題，從用例Failed/Passed路徑這角度上看，測試驅動開發（Test Driven Development，TDD）的模型更為合理和自然。因為，TDD強調先有測試用例，再實現產品功能代碼，先實現的測試用例必然是經過一系列的Failed之后，最終達到Passed，其模型可以總結如下：

　　TDD的原理保證了測試用例一定是由Failed開始，到Passed結束，所以不用費心去模擬功能異常以得到Failed結果，同時保證了用例對Failed和Passed都一定進行了驗證。

　　4. 產品的質量有測試來監控，那么誰來監控測試本身的質量呢？人、過程和工具。

　　人－測試人員需要更有責任心，保持對任何問題的謹慎樂觀和探究精神；過程－測試計劃和用例的交叉評審，測試代碼也要進行review，同時選擇合理的時機實現測試；工具 – 利用代碼覆蓋來探究測試用例有效性。

　　總之，我們在編寫和實現測試用例的時候，除了實現基本功能之外，還要多留意的用例（特別是自動化用例）Passed和Failed有效性，經常容易被忽略地是Failed有效性，所以要盡可的尋找途徑來驗證其有效性。

　　1、等價類分法的基本概念

　　等價類分法是將測試空間劃分成若干個子集，并且滿足每個子集中的任一數據對揭露程序中的缺陷都是等價的，這些子集就叫做等價類或者叫等價子集。

　　比如一個程序的輸入數據滿足   0<x<100為有效數據，其他為無效數據，那么就可以劃分成兩個等價類，一個是有效數據的等價類，另一個是無效數據的等價類，設計測試用例時就可以從這兩個等價類中分別取一個輸入數據來得到兩個測試用例。有效數據的等價類為1～99，所以可以從1～99中任意取一個數作為輸入數據來作為一個測試用例，從x不等于1～99中的數據中任意取一個數據作為輸入數據得到另一個測試用例。

　　1～99中的任一數據和其他數據都是等價的，比如使用了2來進行測試，那么可以假定數據2測試通過的話，1～99中的其他數據也能測試通過。

　　等價類分法可以用來對一些不能窮舉的集合進行合理分類，從各個等價類中選出有代表性的數據進行測試，從而保證設計出來的設計用例具有一定的代表性和一定范圍內的完整性，有效地縮減測試用例的數量。

　 　等價類實際上是符合測試空間劃分原則的一種特殊劃分形式，即劃分完后的子集里的可測數據是等價的，而測試空間劃分原則則是要求里面有一個可測數據測試通 過能夠代表其他測試數據在滿足選取概率條件下也都可以通過。等價類選取測試數據時可以選取等價類中的任意數據作為測試數據，而測試空間劃分原則劃分的子集 一般是選擇指定的數據作為測試數據，如果按測試空間劃分原則劃分后的子集剛好成為了等價類才可以選擇里面的任一數據作為測試數據。

　　2、等價類的幾種類型

　　在現實情況中，由于缺陷的可能情況非常多，一個子集中的數據對某種缺陷是等價的，但對另外一種缺陷可能又是不等價的。所以把等價類分為弱等價類、強等價類、理想等價類三種類型。

　　1）弱等價類

　　弱等價類是考慮某個單一缺陷情況下的等價情況，子集里所有數據在這種缺陷假設下是等價的，并且劃分成的幾個等價類能夠覆蓋整個測試空間的單一缺陷。比如以下一段程序：

　 　我們可以將數據劃分為兩個等價類，0~10為1個等價類，大于10的數據為1個等價類，在考慮“>”號誤寫成“<”號這種缺陷的情況下，這 兩個等價集中的數據都是等價的，比如0～10這個等價類中，使用0或使用10來進行測試都能發現缺陷。這兩個等價類中各自抽取一個測試數據進行測試，都能 代表其他數據揭示出“>”號誤寫成“<”號這種缺陷來，因此整個測試空間都被覆蓋了。

　　2）強等價類

　　強等價類是在多個缺陷假設前提下，各個等價類中的可測數據在單個或多個缺陷假設下是等價的，并且劃分的各個等價子集中各自取一個測試數據可以覆蓋整個測試空間的多個缺陷情況。

　 　再考慮前面弱等價類中的例子程序，出錯的可能性有那些呢？除了大于號會錯寫成小于號外，實際上還有可能寫成大于等于號，10有可能寫成1或100等大于 10或小于10的數，為方便描述以錯寫成1和100為例，事實上錯誤成其他數和錯寫成1和100是等價的。這樣將各種可能出錯的情況組合起來，程序中的判 斷條件有可能有以下12種情況：

　　考慮0～10這個集合，在誤寫成中間一列條件中情況下，里面的數據并不等價，比如誤寫成x>1的情況下，使用1做測試和使用2做測試揭示缺陷是不同的，使用1做測試發現不了缺陷，但使用2測試就能發現缺陷。

　　在判斷條件誤寫成x>=10條件下，10和0~9中的任一數據也不等價，并且使用大于10的數據也無法揭示出條件錯寫成x>=10這個缺陷，因此整個測試空間的多個缺陷無法被已劃分的兩個等價類來覆蓋，10需要單獨劃分成一個等價類。

　 　這樣將數據劃分成三個等價類{0～9}、{10}、{大于10的數據}，再看看這三個等價類是否可以覆蓋表中各種出錯情況，顯然在x>100和 x>=100兩種情況下，大于10的數據集合中的數據是不等價的，使用大于100的數據不能揭示出缺陷，但使用大于10小于100的數據卻能揭示出 缺陷，因此需要對大于10的數據再劃分等價類，實際上只要將邊界值{11}劃一個單獨的等價類就可以了。

　　這 樣總共得到四個等價類{0～9}、{10}、{11}、{大于11的數據}，從這四個等價類中各取一個數據的話就可以將以上列出的所有可能的缺陷情況都揭 示出來，但是各個等價類并不是對所有缺陷都等價的，這種劃分的等價類由于可以將各種缺陷情況覆蓋到，把它叫叫做強等價類。

　　一、測試用例設計概述

　　測試伴隨在整個手機軟件開發的各個階段中，測試質量的高低直接關系到手機軟件的可用性，友好性，可靠性。可以說，測試環節是手機軟件開發的重要環節，是整個開發過程的“中樞神經”。同時，測試用例的設計在測試過程中是非常重要的一個環節，是重中之重。

　　一般來說，設計測試用例應該考慮如下幾方面：

　　1）有效性：測試用例是測試人員測試過程中的重要參考依據。不同的測試人員依據相同的測試用例所得到的輸出應該是一致的。

　　2）可復用性：良好的測試用例具有重復使用的功能，使得測試過程事半功倍，設計良好的測試用例將大大節約時間，提高測試效率。

　　3）易組織性：即使是很小的項目，也可能有幾千甚至更多的測試用例，測試用例可能在數月甚至幾年的測試過程中被創建和使用，正確的測試計劃會很好地組織這些測試用例并提供給測試人員或者其他項目的人參考和有效的使用。

　　4）可評估性：從測試的項目管理角度來說，測試用例的通過率是檢驗代碼質量的保證。經常說代碼的質量不高或者代碼的質量很好，量化的標準應該是測試用例的通過率和軟件錯誤（bug）的數目。

　　5）可管理性：測試用例也可以作為檢驗測試人員進度、工作量以及跟蹤/管理測試人員的工作效率的因素，尤其是比較適用于對于新的測試人員的檢驗，從而更加合理做出測試安排和計劃。

　　二、手機軟件測試用例設計分析

　　通常手機軟件測試用例可以分為如下幾類：

　　1）基本功能測試用例設計

　　基本功能是指手機軟件向手機用戶提供的最小的、可以進行的所有簡單操作的集合。

　 　基本功能測試是指測試工程師在被測試的手機上進行實際操作，來驗證操作是否可行，操作的結果是否滿足設計要求，如果不滿足，就要報告錯誤。具體的操作例 如：接電話，打電話，發送普通短信，接收普通短信，發送彩信，接收彩信，播放靜態音樂文件（mp3），播放一段視頻文件，等等。

　　以“短消息SMS”功能為例，基本功能測試的用例可以從如下方面進行考慮：

　　測試系統包括客戶端仿真平臺以及與客戶端仿真平臺連接的統計模塊，通過在客戶端仿真平臺中模擬并向被測彩信中心系統發送基于MM1，MM3，MM4或MM7接口的彩信業務，通過統計模塊對運行結果進行統計顯示，實現了對MMSC上的各個接口的處理性能的有效分析。

　　1. 引言

　 　隨著彩信業務的發展迅速，其用戶數量不斷增長，對彩信業務系統的性能也提出了很高的要求。彩信業務在實際網絡環境中的系統結構圖（見圖1）主要包括多媒 體信息中心（MultimediaMessageServiceCenter，簡稱MMSC，通常又稱為彩信中心）、MMS終端用戶UA，Push代理網 關PPG、外部郵件（ExternalE-mail）服務器SMTP、增值業務提供商VAS。這些設備可以互為客戶端或服務器端，即發送方或接收方。

　 　對于一個MMSC而言，體系架構中一般包含了MM1/MM3/MM4/MM7各個接口信息的處理，包括來自終端用戶（MO）的MM1接口信息，來自 VASP下發的MM7接口信息，來自外部郵件（ExternalE-mail）服務器smtp的MM3接口信息以及來自其他MMSC的MM4接口信息。

　 　為了衡量MMSC是否能夠承載移動商用網業務以及突發高峰時段對MMSC的影響，保證移動運營商的服務質量，需要獲知MMSC上的各個接口的處理性能。 然而，目前國內外包括一些國際標準化組織尚未對MMSC上的各個接口的處理性能進行有效的分析，例如OMA組織一般僅側重于通信協議進行分析，并沒有針對 MMS系統的性能進行測試。本文提出了一種彩信中心系統性能測試系統，包括客戶端仿真平臺、統計模塊和服務器端仿真平臺。本文還提出了彩信系統性能測試方 法，并給出了彩信系統不同信息傳遞流程的具體測試方法和步驟。

　　2. 彩信中心性能測試系統

　 　圖2是彩信中心系統性能測試系統組成圖：客戶端仿真平臺用于模擬彩信發送端并向被測彩信中心系統發送彩信測試消息，測試被測彩信中心接口MM4的處理性 能。統計模塊與該客戶端仿真平臺連接，用于統計及顯示該客戶端仿真平臺發送和接收的信息。服務器端仿真平臺通過被測彩信中心系統與客戶端仿真平臺連接，用 于模擬彩信接收端接收被測彩信中心轉發的彩信。加入服務器端仿真平臺后，本系統可以測試被測彩信中心更多接口的處理性能。

　 　客戶端仿真平臺模擬包含MM1/MM3/MM4/MM7各個接口的客戶：信息發起終端（MO）模塊用于模擬終端用戶（UA）和WAP網關（WG）；E- mail客戶端（SMTP）模塊用于模擬E-mail客戶端發送E-mail信息到MM3接口；彩信中心仿真模塊用于模擬彩信中心客戶端從MM4接口向被 測的彩信中心發送MM4-Forward信息；增值應用服務商客戶端（VAS）模塊用于模擬增值應用服務商客戶端發送MM7接口信息。

　　 服務器仿真平臺模擬各個接口的服務器端，包括：PPG模塊直接與彩信中心的MM1接口進行通信，用于處理彩信中心的PUSH信息；E-mail服務器端 （SMTP）模塊用于模擬E-mail服務器端從MM3接口接收E-mai信息并且處理接收到的信息；用戶接收終端（MT）模塊用于接收來自PPG轉發的 彩信；增值應用服務商服務器端（VAS）模塊用于模擬增值應用服務商服務器端接收并處理MM7接口信息。MMS系統性能測試主要包括 MM1，MM3，MM4，MM7四個接口的協議處理。

　　本系統通過模擬實現MMSC四個接口的所有彩信發送和接收流程以及各個接口之間的 信息交互，即通過彩信中心接收來自各個接口的信息，并且同時通過各個接口下發彩信信息，真實仿真現網各種業務流程，并對收發信息進行統計顯示，從而得出彩 信中心系統的處理性能參數，實現對彩信中心系統性能的有效測試。本系統將被測MMSC獨立出來，完全脫離除被測MMS中心以外的其他網絡設備，用客戶端仿真平臺和服務器仿真平臺模擬了除被測MMS中心以外和MMS中心交互的網絡設備（如WAP網關和PPG），以保證測試結果的正確性。

　　1）走通性能測試流程，從造數據到測試，可以走通，方可交由測試同學。畢竟開發（相對性能測試人員而非功能測試）對業務邏輯更了解一些。

　　2）測試一些顯而易見的bug；

　　3）建立性能方面的信心；

　　4）可在測試的同學做完測試以后做一個對比，不至于偏離太過離譜。

　　參照測試部門的意見，我把這次的性能測試總結了如下幾個步驟：

　　1、測試目標和范圍：根據需要滿足的非功能需求，確定上線功能點哪些需要測試。測試性能、穩定性、最大壓力。

　　2、測試方案準備：包括施壓方式，環境配置，環境依賴，資源監控，整理方案文檔。

　　3、環境準備：準備壓力測試環境，一般是壓力測試機配置，壓力測試數據庫配置。

　　4、數據準備：根據線上預估數據，對數據庫數據進行準備和模擬。

　　5、測試準備：包括需要編寫的程序，如其他系統間依賴可寫mock程序。另外編寫jmeter的測試計劃等。嘗試測試，并確保一個請求或處理過程能順利通過。

　　6、進行測試：通過客戶端施壓服務器，監控器各方面資源利用。

　　7、進行測試分析總結：寫測試報告。TPS，吞吐量，CPU占比等。對異?，F象記錄，如內存溢出等。

　　8、根據測試報告對程序進行優化或重構。

　　做技術還是有做技術的天性，我們開發最關心的也就是5-8的步驟。我們的應用主要以hessian接口的形式向外面暴露，另外的就是任務在后臺處理接口推送過來的數據。所以，我們的測試主要集中在接口測試和任務測試。比一般網頁的性能測試更簡單一些。

　　我們選用的施壓客戶端是開源的jmeter，文檔較為豐富，且操作極為方便，擴展性好。服務器端性能監控工具，均采用linux的shell命令和jvm自帶的工具或命令。jvm的工具已經夠強大了，測試團隊也是利用linux的命令采集服務器端資源，然后把消息發送到自己編寫的一些資源監控工具上，其實都是利用了原生的shell命令和jvm命令來周期性采集并繪圖的。

　　JMeter沒有現成的sampler施壓hessian的接口，所以我們需要利用它極具擴展性的java請 求sampler來施壓hessian接口。我們查看jmeter安裝目錄下的lib>ext下可以發現其他多種類型的sampler。其他的種類 都可以由javasampler來實現。我們只需要繼承org.apache.jmeter.protocol.java.sampler. AbstractJavaSamplerClient該類，在runTest方法中調用hessian接口，并封裝返回值即可。然后把工程打成jar包， 放到jmeter安裝目錄下的lib>ext下。啟動jemter，在利用javasampler就可以定為到我們編寫的擴展測試程序了。

　　在壓力測試過程中，包括兩部分的資源檢測，jvm的資源占用。一般利用jdk自帶工具集

　　1、jps

　　常用的幾個參數：

　　-l輸出java應用程序的mainclass的完整包

　　-q僅顯示pid，不顯示其它任何相關信息

　　-m輸出傳遞給main方法的參數

　　-v輸出傳遞給JVM的參數。在診斷JVM相關問題的時候，這個參數可以查看JVM相關參數的設置

　　2、jstat-JavaVirtualMachineStatisticsMonitoringTool

　　jstat[Options]vmid[interval][count]

　　Options--選項，我們一般使用-gcutil查看gc情況還有其他選項如：

　　-class-compiler-gc-gccapacity-gccause-gcnew-gcnewcapacity-gcold-gcoldcapacity-gcpermcapacity-gcutil-printcompilation

　　vmid--VM的進程號，即當前運行的java進程號

　　interval--間隔時間，單位為毫秒

　　count--打印次數，如果缺省則打印無數次

　　-----------------------------------------------jstat-gcutil[pid]輸出解釋

　　S0--Heap上的Survivorspace0區已使用空間的百分比

　　S1--Heap上的Survivorspace1區已使用空間的百分比

　　E--Heap上的Edenspace區已使用空間的百分比

　　O--Heap上的Oldspace區已使用空間的百分比

　　P--Permspace區已使用空間的百分比

　　YGC--從應用程序啟動到采樣時發生YoungGC的次數

　　YGCT--從應用程序啟動到采樣時YoungGC所用的時間（單位秒）

　　FGC--從應用程序啟動到采樣時發生FullGC的次數

　　FGCT--從應用程序啟動到采樣時FullGC所用的時間（單位秒）

　　GCT--從應用程序啟動到采樣時用于垃圾回收的總時間（單位秒）

　　云計算數據中心的網絡測試主要包含虛擬化測試、安全測試、高可靠測試和性能測試四 個部分。前三者重點在于對數據中心網絡的功能設計進行測試驗證，性能測試則是度量整個云網絡的關鍵，用以確認其能夠提供的服務能力基線。云計算技術目前很 多應用在大型的高性能計算（超算）數據中心中，在此類數據中心內部，性能處于業務保障的第一關鍵位置。本文重點關注性能測試的部分，從測試設計方面進行探 討。

　　測試設計

　　數據中心網絡性能測試手段很多，業務仿真測試是最能體現實際應用情 況的測試方法。業務仿真測試往往需要利用大量服務器和存儲設備，通過部署仿真應用環境來測試網絡針對此類型應用的轉發性能。但此方法受成本和測試復雜度影 響，一般只在超大型且應用較為單一的數據中心測試時使用，如百度/SOHU搜索業務仿真、QQ/MSN實時通訊業務仿真、石油勘探/氣象預報計算業務仿真 等。

　　除了上述專用測試方法外，還可以通過測試儀器模擬一些基本的應用流量來測試其主要性能。此方式由于實施簡便、通用型強，在數據中心 網絡性能測試中應用較多。受當前整個Internet應用使用情況影響，測試儀模擬的網絡應用以TCP的HTTP為主，有時會根據具體的實際業務情況添加 Mail、FTP和HTTPS進行補充，這種測試設計也符合當前云計算數據中心的實際應用情況。

　　測試環境

　　在測試數據中心網絡性能時，通常使用成對的測試儀器端口，連接到數據中心網絡兩端，將整個網絡視為黑盒進行端到端的性能結果測試。典型測試組網設計如圖1所示。

圖1   數據中心性能典型測試組網

　 　圖1中的數據中心網絡結構采用典型的3層雙冗余結構。核心層設備采用高端交換設備進行三層路由轉發，其與匯聚層設備間通過OSPF動態路由協議互連，以 提供多路冗余保障，同時通過只發布缺省路由到匯聚層設備的方式來減輕匯聚層設備的路由壓力；匯聚層設備作為模擬服務器設備的網關提供三層轉發功能，使能 VRRP等網關冗余協議來保證雙機熱備，并通過VLANTRUNK方式與接入層設備相連；接入層設備部署為二層轉發模式，通過MSTP協議確保多VLAN 環境下的冗余鏈路備份功能。

　　測試儀器通過多個接口分別與核心層設備和接入層設備連接，并模擬Client和Server進行有狀態的流量轉發性能測試。測試模擬的協議類型盡量與使用環境貼近，最常見的是使用HTTP協議進行基于L7的業務流量模擬。

　　另外為了確保數據中心測試的仿真度，還需要模擬大量的路由、VLAN和流數量。例如測試的為一個大型的企業云數據中心，則需要定義以下背景環境參量：

　　1. 首先設置背景路由，在核心設備上模擬發布1萬條OSPF散列路由，其發起源為50個Router，路由模擬調配比例為NetworkLSA：SummaryLSA：ExternalLSA=1：3：16

　　2. 然后設置背景VLAN與模擬服務器，在匯聚層與接入層設備上部署8個MSTP的Instance，每個Instance中包含8個VLAN，使用測試儀器在每個VLAN中模擬100個HostServer，總共64個VLAN，6400個Server。

　　3. 最后構造測試流量，定義1萬個Client源IP地址一一對應到模擬的1萬條散列OSPF路由中，目的IP地址64個，分別為模擬的64個VLAN中每個VLAN隨機抽取的各一個HostServer地址?？偣矠?4萬條IP測試流。

　　上述測試參數定義均可通過測試儀器配置完成。

　　當測試環境部署完畢后，即可使用測試儀器進行整網性能指標的測試執行工作。

　　舉例：期望的網絡并發數為300萬，使用1千CPS的速率進行新建，則需要將測試儀器的會話回應等待時間調整至 3，000，000/1，000=3000s才能得到接近期望的測試結果，而如此長的會話保持時間對網絡中間設備來說屬于并不符合實際網絡業務模型的處理 方式。

　　因此正確的測試方法是，先測試出中間網絡的極限CPS能力，然后取中間設備穩定運行時（如CPU使用率在60％）能夠處理的新建速率，再根據并發數期望測試結果計算出測試儀的會話回應關閉等待時間，通過調整此時間測試出實際的設備并發數處理能力。

　　舉例：先測試出的網絡新建速率極限值為20萬CPS，CPU穩定在60％時的最大新建速率值為15萬CPS，期望的最大并發數為300萬，則在 測試并發數時設置測試儀器的新建速率為15萬CPS，會話回應關閉等待時間為20s上下調整，以確認網絡能夠達到的實際最大并發數。

　　L4并發數測試配置需要注意以下幾點：

　　1. 根據網絡L4新建速率測試結果，設置穩定的新建速率參數和會話回應關閉等待時間參數。

　　2. 可以適當調整TCP會話關閉方式，以減少中間網絡設備壓力，如采用Reset方式關閉。

　　3. 同新建速率測試一樣，設置HTTP載荷為盡量小值（如64byte），并將每個TCPConnection中的HTTPTransaction數量設置為1，減少對測試結果的干擾。

　　4. 將整個測試周期時間設置為一個較長值（如3600s），同步驗證網絡的穩定性。

　　5. 測試前中后的整個過程中記錄網絡主要設備的關鍵性能指標，進行比較確認。

　　L4并發數測試結果體現了整網會話保持與表項存儲的能力，與網絡中L4-L7處理設備的內存大小有直接關系。這里的內存大小依據各個廠商設備實現的不同也指DRAM、接口內存和CAM等TCP會話表項存儲單元容量。TCP并發數與內存使用大小的線性關系如圖3所示。

　　圖3  L4并發數結果與網絡設備Memory使用率關系示意圖

　　L7吞吐量測試

　　L7吞吐量指當前網絡可以有效傳輸的最大HTTP數據量，也被稱為有效吞吐GoodPut，區別于傳統意義上的測試指標L3吞吐量ThroughPut，結果單位為BPS（BytePerSecond）。

　　L7吞吐量測試結果很大程度上依賴于L4新建速率能力，其間關系類似于傳統L3吞吐量BPS（BitPerSecond）與網絡設備包轉發能力 PPS（PacketsPerSecond）之間的關系。在測試L7吞吐量的過程中，首先測得網絡的新建速率，然后將新建速率測試結果乘以一定比率系數 （例如80％），作為L7吞吐量測試中使用的的穩定新建速率參數始終不變，測試時逐步提高HTTP有效載荷大小，通過觀察出現HTTP連接出現失敗前的有 效載荷最大傳輸速率，得到其L7吞吐量測試結果。

　　舉例：采用的穩定持續新建速率為20萬CPS，能夠無失敗傳輸的最大有效載荷值為500Byte，則系統的L7吞吐量為100MBPS（BytePerSecond）。

　　在L7吞吐量測試中還需要注意的是可以適當提高每TCPConnection中的HTTPTransaction數量，如采用1：10的比例， 這樣能夠進一步提高L7吞吐量測試結果。但需要注意采用多Transaction方式時，需要將測試儀器上的HTTP協議類型設置為HTTP1。 1，HTTP1。0協議不支持此種傳輸加載方式。

　　L7吞吐量的測試結果除了受L4新建速率的直接影響外，還會受到網絡中各設備的交換架構、接口總線等元件單位間處理能力的限制，其測試結果也直接體現了整個網絡的應用數據吞吐轉發能力。

　　L7響應時間測試

　　L7響應時間指從客戶端發起http請求，到得到正確數據響應所經歷的時間，一般用來衡量中間網絡的綜合處理能力，單位為毫秒。

　　L7響應時間與L7延遲時間的主要區別是：延遲時間指客戶端發出報文到服務器接收到此報文或反向發送接收的間隔時間；響應時間則指的時一個完整 連接的客戶端于服務器報文來回交互過程時間。在數據中心網絡中，響應時間可以更好的表現出整個網絡對有狀態的流量處理能力，在HTTP這種需要客戶端與服 務器進行反復交互的應用協議使用中尤為重要。

　　響應時間的測試方法主要有兩種：一種是基于真實服務器的業務響應時間測試，此測試結果包含了中間網絡設備與服務器兩部分處理延遲時間；另一種是 通過測試儀模擬服務器快速響應請求的測試，這種測試方法可以盡量減少服務器端處理延遲的影響，得到近乎純粹的網絡處理延遲時間。

　　L7響應時間測試要在一定的新建速率下進行，這樣做也是為了盡量貼近實際網絡情況。但此測試中的新建速率需要維持在一個較低的水平線上，最好是根據真實環境平均值設定，這是因為新建速率較高時會導致CPU資源占用較高，影響設備對連接的處理能力。

　　常用測試工具

　　使用專用測試工具測試數據中心網絡性能時，可以采用軟件與硬件兩類。

　　軟件測試工具指需要運行在例如UNIX、Linux和Windows等開放的操作系統及通用的硬件架構上，并且只需對現有系統做出微小甚至不做改動就能夠完成測試任務的軟件。

　　部分性能測試軟件如下：

　　HTTP–HTTPLOAD，WebServerStress，LOADRunner，WebBench，WebStone，SPECweb99

　　MAIL–Loadsim，Medusa（MicrosoftExchange），

　　DB-BenchmarkFactoryforDatabases，Jetstress，DBstress

　　IPSAN–IOmeter，Iozone，Bonnie++，dd

　　硬件測試工具指使用單獨的硬件設備配合裝載在PC上的控制軟件完成測試工作，其性能要遠優于一般的軟件測試工具，但相對的缺點是價格較高和可擴 展性較差（功能升級有時需要對硬件產品進行改變，成本很高）?；跀祿行囊詰脼楦镜木W絡流量特點，通常采用支持L7應用的測試儀器進行測試。目前主 流的測試儀器廠商有Spirent、IXIA和BreakingPoint等。

　　在云計算數據中心網絡性能測試中，如果需要更好的仿真業務應用，建議采用軟件集群服務器安裝測試方式；如果希望得到最大的極限能力，建議采用硬件測試儀器來進行測試。

　　結束語

　　在數據中心網絡性能測試中，還有以下一些常用經驗可以在測試設計和執行中進行參考：

　　1. 當測試模擬的流量越接近真實網絡，測試環境就需要越復雜。

　　2. 永遠不能通過測試設計去完全的模擬真實網絡環境。

　　3. 沒有任何兩個測試環境是完全相同的，因此所有測試結果只有參考性，不具標準性。

　　4. 不同的網絡環境體現不同的流量模型，最好的不見得是最適合的。

　　5. 數據中心性能測試結果永遠向網絡中性能最差設備指標看齊。

　　6. 所有測試之前一定先要進行測試工具的自測試，了解其能力限制。

　　云計算數據中心的廣泛部署是一個持續漸進的過程，而基于云計算數據中心的測試是使其大范圍推廣的關鍵保障。做好云計算數據中心網絡的測試設計和 執行，可以更好的了解當前網絡設計的能力范疇，以便更準確的應對基于云計算技術的應用業務需求，為云應用提供更好的通道架構服務。