Pure Software vs Appliance測試工具 測試工具
因為工作的原因,我會經常去關注一些實用性強的性能測試工具。軟件測試有很多的領域和方面,可能性能測試這個方面最離不開工具,基本上沒有辦法純手工來做軟件測試,因為你不大可能請一百個人同時點擊按鈕來模擬100個并發連接。所以軟件測試工具在這個時候就顯得比較重要,甚至軟件測試的范圍和深度也很大程度上也依賴于軟件測試工具的能力，這也是為什么Mercury，Quest還有Spirent這種純粹做軟件測試工具的廠商可以成為年收入幾億美刀公司的原因之一吧。不過近年有很多純做軟件測試工具的廠商被一些巨頭如IBM,HP收購，這可能和IT行業的另一場大討論有關，那就是專注和大而全的問題，anyway，這些都沒有否定他們的價值。
性能測試工具的出現有很長時間了，而且已經有很多的領先者，比如Mercury LoadRunner, Rational Performance Tester, Segue SilkPerformer, 還有Empirix， Compuware，Quest的產品，后面的因為沒有機會試用，所以不熟悉。以上這些工具都是純軟件的性能測試工具的代表。各家的產品設計理念都不相同，基本上每家都提出了一些概念和賣點。但其實它們的主要架構都是類似的，大致可以分為以下幾個方面：
1． Virtual User Generator。性能測試很多是要模擬多個用戶或者client的行為，所以一個自然的起點是你要知道一個用戶的behavior，這個模塊的輸出一般是一個client的腳本，可以獨立執行完成一次操作。各家用的語言不同，大致有C，Java，Pascal等幾種。Of coz都說自己的好，可能用的人還是覺得自己熟悉的好。這個話題也很有意思，當別論。還有一個問題是如何生成這樣的腳本，基本上有兩種辦法，一是自己寫，根據手冊，甚至有些可以用標準的C和Java語言。二是錄制，就是捕捉真正的client的一次操作過程，然后通過協議的反向解析，得到步驟，就是上面說的腳本。很多時候可能是先錄制，再在上面改改。
2． Load Generator。 一個用戶的行為已經有了，現在的問題是要模擬出成百上千的用戶。這個可以借助多進程或者多線程的方法，單個機器的能力有限，所以很多都支持distribution的方法，可以把很多機器組織起來作為一個group來產生load。
3． Conductor/Controller。性能測試有時候像指揮一群人長跑，所以需要組織和協調，比如是所有人聽到槍聲就開始跑呢還是一批批的跑，好點的工具都支持壓力曲線。如果跑的過程中隊形亂了，你也可以大喊一聲stop，讓所有人都停下來，退回原點。Conductor做的事情還有很多，比如可以設定monitor和實時的數據顯示。
4． Analysis/report generator。軟件測試跑完了之后自然是要有結果的，一般都會提供一份自動生成的report，這些就是分析模塊做的事情。好的工具應該可以提供詳細的不同層次的數據分析，也有一些智能化的分析會給出可能的bottleneck。
潮流總是一陣一陣的，今年皮草明年復古。IT這個行業也是一樣，最近幾年的一個潮流是Appliance，簡單的說就是以前賣軟件，現在把軟件裝在硬件里面連硬件一起賣。比如一些網關安全產品，像http，email方面已經有很多了，還有Google也推出了search appliance。記得以前聯想出過漢卡，還有什么殺毒卡，后面都被純軟件取代了�，F在又開始有一些硬件取代純軟件的例子。由此可見很多東西都不是絕對的，要看環境了，有點適者生存的味道。關于純軟和appliance各自的優劣，我覺得是一個big topic，還有很多問題沒有想太清楚，另找機會來討論吧。
還是回來看性能測試工具領域，現在也有這樣的趨勢。其實上面說的性能測試，受個人眼光之狹隘，更偏向于應用系統的性能測試。因為在網絡基礎設施，比如交換 機，路由器和無線設備的測試方面，性能測試設備的使用由來已久，而且占主導地位。成熟的領域總是有一些廠商奠定了自己的領先地位，比如Spirent，IXIA和Agilent等等�，F在的一個趨勢是這些傳統的網絡性能測試廠商開始向應用性能測試領域挺進，唯一的解釋是application load testing領域是一個很大的市場。是的，Yankee的預測是這個領域的revenue在08年將超過600M USD，所以對他們而言，跑到第七層是一個必然的方向。他們的宣傳口號已經變成了“提供完整和先進的2－7層性能測試解決方案”�，F在這方面已經有了一些比較成熟的產品，比如Spirent的Avalanche＋Reflector，IXIA的硬件搭載它們的IxLoad模塊。上面提到的性能測試工具的四個主要模塊他們都有。很多的性能測試用純軟件和appliance都可以完成，那么他們就沒有分別了嗎？目前來看還是有不少差別的，比如以下幾個方面。
1．就client類型的支持方面，目前來看software的產品還是占優勢。我想這是因為純軟件的產品一直都是關注application，在這方面有長期的積累。對標準的協議如HTTP(S),SMTP,FTP的支持兩邊都差不多，這些也是比較容易做到的。但是對一些應用平臺的支持相對要復雜一些，比如很多software產品都支持各種數據庫的性能測試，以及中間件，如BEA Tuxedo，還有ERP系統，如SAP，Oracle，除此之外，有些還甚至支持IBM Legacy系統。Appliance產品對這方面的支持目前還很少，多半集中在標準協議方面。不過這其實也不是致命傷，因為這些測試工具都是按協議來賣，可以搭配的，這也是因為買測試工具的客戶也不是什么client都需要。比如有的公司主要是要測試自己的web應用系統的性能，那么他的選擇實在很多。有些要測在Tuxedo上面開發的應用，可能software的產品目前是唯一的選擇。
2． 擴展性。性能測試，特別是大的系統對測試工具本身的性能也是有要求的。這個很好理解，如果一個系統1秒能處理1萬個請求，但是測試工具只能發起5千個，那就說不過去了。很多情況下，靠一臺主機來模擬client可能還不夠，這就涉及擴展性的問題，關于這個問題，兩邊給出了不同的solution。Software這邊的答案是前面提到的distribution的方法。Appliance這邊的方法還是appliance式的，很多產品提供擴展槽，你可以再插一套主機系統進去，有點像通信設備里面單板機的概念，每個板子上都有自己的CPU和Memory和network port。
3． 升級的問題。相對而言，軟件的升級比較簡單。Appliance這邊硬件自身的升級除了擴展之外應該不是很方便，但是里面搭載的軟件是可以更新的。
4． Appliance的產品提供了網絡狀況的測試和模擬功能，比如當前測試環境的網絡狀況，可以模擬出帶寬小，丟包率高的情況。Software這邊可能要借助3rd party的方法。這些可能對某些測試有意義，對有些而言，可能就不care了。
5． 可能因為自己產品的原因，注意到appliance有個不錯的好處，那就是他們比較適合測試gateway之類的產品。這類產品測試的過程中需要關注upstream和downstream的狀況，而傳統的software solution基本上都是C/S結構，你得到的最主要數據是client的響應狀況。我想這可能是因為這些appliance一開始就是用來測試router和switch之類的東西，所以自然前后都要看。他們把這個特點帶到了application測試上面來。比如IXIA利用一臺測試設備的兩個端口模擬出test client和server，發給gateway然后再收回來，這樣就有前后的分析數據了。Spirent把這兩塊分開成Avalanche和Reflector來完成。沒有試用過，不過相信在report里面，兩邊的數據是可以sync在一起的。
軟件測試工具的競爭其實是蠻殘酷的，因為這些產品的客戶都是十分挑剔的，而且，怎么講，寫一首皆大歡喜的歌很難。軟件測試工具基本上都想一套方法一套工具適應大量的場合和客戶群，但是這本身就是很難的事情，就像他們要去測的應用系統一樣。這也是為什么近年很多軟件公司開始做segmentation，分出enterprise，SMB和consumer。
作為產品的軟件測試人員，對自己的產品使用場景很了解，需要找到盡可能適合自己產品的軟件測試工具，但是很少有完全滿足要求的軟件測試工具。所以如果對某個客戶而言，他們提供的軟件測試工具有某些方面不適合造成的硬傷，那只能說遺憾。
最后有個問題，這些純軟件測試工具廠商難道就這樣看著appliance蠶食他們的市場嗎？我想不會，他們可能也會推出自己的testing appliance，也可能繼續加強自己的優勢，因為appliance有天然的優勢也有天然的劣勢。當然還有一種可能就是并購，到時候可能同一家就會提供軟硬兩套方案，說你自己選吧，然后廣告改成“提供業界領先的基于軟件和高性能測試設備的應用系統性能測試全面解決方案”。
文章來源于領測軟件測試網 http://www.k11sc111.com/