通過提供的一套全面的解決方案， 本文描述Quests Application Management Suite for Java and Portals是如何與該方法論相集成，從而在應(yīng)用開發(fā)生命周期的每個階段保證您的成功。運用這套方法論和Quest的應(yīng)用管理解決方案，您將充滿信心地把符合性能規(guī)范的應(yīng)用展現(xiàn)給您的用戶。

　　本文同時強調(diào)自動化的重要性，采用自動化方式可以創(chuàng)建重復的測試過程并迅速報告應(yīng)用代碼的質(zhì)量。只有自動化方式才能保證正確地遵循這些測試過程，并且保證準確和一致地測試應(yīng)用組件。

　　導言

　　性能測試已經(jīng)成為軟件開發(fā)界的一個事后總結(jié)出來的想法。IDG 的研究報告指出只有20%的上線的企業(yè)Java 應(yīng)用符合他們的性能要求。如果所有上線的企業(yè)Java應(yīng)用中有80%不滿足他們的服務(wù)標準協(xié)議(SLAs)，那么需要花費巨大努力去分析為什么會發(fā)生這種情況以及如何解決這種問題。要想成功滿足SLA，其關(guān)鍵在于應(yīng)該采用正規(guī)的性能測試方法論。本文將詳細闡述該方法論并且指出在每個測試階段所需使用的工具集，以成功確保企業(yè)應(yīng)用的性能。

　　測試主要分兩類: 功能測試和性能測試。 本文專注于性能測試，因此本文中的所有提及的測試除非有另外說明，否則都指性能測試。

　　性能測試的準備

　　一、量化性能需求

　　為了量化性能要求，我們假設(shè)您已經(jīng)定義了SLA。在深入分析問題之后，關(guān)鍵的負責人員應(yīng)該系統(tǒng)地定義SLA。SLA 的主要推動者應(yīng)該是應(yīng)用業(yè)務(wù)負責人和應(yīng)用技術(shù)負責人。 應(yīng)用業(yè)務(wù)負責人，有時是應(yīng)用產(chǎn)品經(jīng)理，他負責分析商業(yè)案例并把客戶的需求轉(zhuǎn)化為SLA。其實， 只要滿足SLA， 客戶的需求也會滿足。應(yīng)用技術(shù)負責人，有時是應(yīng)用構(gòu)架師，分析必要的技術(shù)需求，解釋用例并"真實地檢驗"SLA。因此，技術(shù)業(yè)務(wù)負責人的責任是確保服務(wù)等級是可達到的。有效的SLA具有三個關(guān)鍵特性:

　　1.具體的。

　　2.靈活的。

　　3.現(xiàn)實的。

　　一個有效的SLA 必須是一個具體的值。一個用例必須在大約五秒內(nèi)完成是不準確的，因此很難檢驗--5.25秒鐘是否是大約的五秒。一個具體的值便于QA在應(yīng)用上線前進行測試，當應(yīng)用上線后，SLA將提供對主動監(jiān)測和被動監(jiān)測兩種警報(Alert)的規(guī)范。同時，一個有效的SLA在分布式的變化環(huán)境中必須也是靈活的�？紤]到一些未預料到的情況，我們需要對靈活性進行測量，因此用例必須采用預先定義的時間百分比的方式滿足具體的SLA值。例如，您每天使用的常用搜索引擎。當您執(zhí)行一次查尋，在95%的時間里可以在2秒內(nèi)完成；在每20次查詢中，有一次的響應(yīng)時間是7秒；通常這種變化的范圍是可以接受的。但是如果每20次查詢中，有10次超過7秒，你可能會考慮換個搜索引擎了。SLA不僅必須是具體的， 也要靈活，同時必須也是現(xiàn)實的。你可以通過要求應(yīng)用業(yè)務(wù)負責人和應(yīng)用技術(shù)負責人共同制定SLA的方式保證SLA是現(xiàn)實的。這是一個有效用例的特別關(guān)鍵的特性，這是因為在大多數(shù)情況下，SLA只由應(yīng)用業(yè)務(wù)負責人單方面確定，沒有考慮應(yīng)用技術(shù)負責人的意見。當技術(shù)小組接到這些性能需求時，他們往往會忽略，一個不現(xiàn)實的SLA比根本沒有還要糟糕。

　　二、了解你的用戶

　　為了保證調(diào)優(yōu)努力的成功你能做的重要的事是安排時間了解你的用戶和理解他們在使用你的應(yīng)用時的行為情況。很少會在生產(chǎn)環(huán)境中調(diào)優(yōu)應(yīng)用服務(wù)器，而更多的情況是，通過寫測試腳本再現(xiàn)為虛擬用戶，在上線前的環(huán)境中執(zhí)行負載并進行調(diào)優(yōu)。當在上線前環(huán)境中完成調(diào)優(yōu)后， 可以安全地把配置信息應(yīng)用到生產(chǎn)環(huán)境中。多數(shù)公司無法在上線前的環(huán)境中充分地再現(xiàn)生產(chǎn)負載。如果您在這些公司中工作，沒必要失望。多數(shù)大型的公司并沒有對他們的用戶行為有很好的理解并且在測試環(huán)境中不能產(chǎn)生有代表性的負載。

　　有兩個共同的似是而非的理由：

　　1. 生產(chǎn)負載太大，在上線前無法模擬。

　　2. 我沒有任何辦法知道我的終用戶到底是如何操作的。

　　針對第一點，我們可以在上線前環(huán)境中建立一個按比例縮減的生產(chǎn)版本，當在生產(chǎn)環(huán)境中部署時，再按比例放大。雖然沒有做一個生產(chǎn)環(huán)境的鏡像有效，但是有時并值得那么做。針對第二點，下面將說明如何采集終用戶的操作行為。

　　由于我們需要在投入生產(chǎn)之前設(shè)法在上線前的環(huán)境中調(diào)優(yōu)我們的應(yīng)用系統(tǒng)，這樣才能驗證配置，所以一個隨之而來的問題是我們需要在這個環(huán)境中執(zhí)行的負載測試腳本。對一個企業(yè)應(yīng)用進行調(diào)優(yōu)的步驟包括實施一些佳實踐設(shè)置，負載測試應(yīng)用，觀察應(yīng)用的行為，以及適當調(diào)整配置參數(shù)等。這是一個疊代過程，我們需要不斷調(diào)整以達到優(yōu)的配置。一些調(diào)整可能會提高性能，而一些會降低性能。這也是為什么性能調(diào)優(yōu)不應(yīng)該放在開發(fā)周期后期的一個原因。

　　假設(shè)我們根據(jù)我們的負載腳本進行調(diào)優(yōu)，那對你又意味著什么呢？這意味著負載腳本應(yīng)該真實反映現(xiàn)實世界用戶的使用行為。假設(shè)我們在優(yōu)化一個Web搜索引擎，我們可以寫一個測試腳本，該腳本總是在測試蘋果和香蕉，但是用戶是這樣使用嗎？我們可以為此調(diào)整出好的性能。但是當查詢Bea和IBM時，又會怎樣呢？在我的應(yīng)用中，我可以將技術(shù)公司的詞匯放在與水果和蔬菜不同的數(shù)據(jù)庫中，那么在測試環(huán)境中，永遠不會執(zhí)行到那段代碼，我們的調(diào)優(yōu)努力也徒勞無益了。

　　更好的解決辦法是確定名列前茅1000 或10，000 個查尋詞組和他們頻率。然后，計算每個被請求的時間百分比并且編寫按照該百分比查詢這些詞匯的測試腳本。對于剩余的百分比，你可以把負載測試工具連到一個詞典，可以隨機生成查詢的詞匯。

　　三、使用工具分析

　　編寫一個典型用戶負載腳本的困難之處是發(fā)現(xiàn)你的用戶是怎么使用的應(yīng)用的。 這不是一門精確的學問。但是為得到一個合理的可靠的結(jié)果，第一步是看看您的訪問日志�，F(xiàn)在，我不會推薦手工做這件事，因為對于一個中型的Web應(yīng)用，工作量也是巨大的�，F(xiàn)在有大量商業(yè)或免費工具可為您分析訪問日志。

　　這些工具將告訴你有關(guān)你的服務(wù)請求的一些情況:

　　a) 將服務(wù)請求按時間的百分比排序，并顯示百分比。

　　b) 放大或縮小分析時間間隔，便于以粗粒度或細粒度方式顯示結(jié)果。

　　c) 識別每天，周，月，年的高峰使用時間。

　　d) 跟蹤字節(jié)傳輸和請求的平均時間。

　　e) 按照你的應(yīng)用的內(nèi)部，外部或地理位置，識別和分類請求的用戶。

　　f) 匯總成功請求的百分比。

　　g) 匯總HTTP發(fā)生的錯誤。

　　h) 匯總顧客忠誠度， 譬如回頭客和平均會話長度。

　　i) 跟蹤從其他站點的轉(zhuǎn)入情況。

　　無論你選擇哪種軟件分析訪問日志，重要的是你應(yīng)該做這些分析工作并且把這些信息作為編寫測試腳本的基礎(chǔ)。有時訪問日志的作用是有限的，在某些情況下不能提供足夠的信息。例如前端應(yīng)用只使用一個URL發(fā)出請求，而通過在請求中嵌入不同的參數(shù)區(qū)分業(yè)務(wù)功能。在這種情況下，需要高級一些的工具根據(jù)不同的請求參數(shù)監(jiān)測應(yīng)用的使用情況和劃分業(yè)務(wù)功能。

　　訪問日志只能提供部分解決辦法。接下來需要對應(yīng)用本身有更深入的理解。例如，當發(fā)出一個特定的服務(wù)請求時，你應(yīng)該知道其不同的選項所控制的相應(yīng)行為。這些信息的好來源是應(yīng)用的用例和負責該功能的架構(gòu)設(shè)計人員。這些工作的目標是識別出真實世界中用戶的使用行為，所以應(yīng)該徹底和全面地完成此階段任務(wù)。這里發(fā)生的錯誤將導致上文提到的"蘋果和香蕉"搜索引擎的問題。

　　 為了全面獲得更可靠和更詳盡的終用戶行為信息，可以考慮Quest公司的User ExperienceMonitor(UEM)。UEM在終用戶和WebServer之間，實時捕獲向你應(yīng)用環(huán)境發(fā)出的每個請求，可提供有關(guān)真實用戶所做的詳盡數(shù)據(jù)，包括連接速度，瀏覽器版本，按地理位置匯總等信息。由于采用了被動的網(wǎng)絡(luò)Sniff技術(shù)，所以對應(yīng)用的性能影響為零。

　　四、用戶如何退出系統(tǒng)

　　后，有一個值得重視的問題，我們了解到目前客戶在編寫負載測試腳本時大的錯誤是：用戶不知道怎樣退出應(yīng)用系統(tǒng)。不管你把退出按扭作的多大，至多只有20%用戶會使用。這是由于現(xiàn)在將Web作為主要業(yè)務(wù)平臺的必然結(jié)果。商業(yè)Web站點正式基于此而得以快速發(fā)展并統(tǒng)治了Internet.

　　因此，現(xiàn)在用戶習慣以下面方式退出網(wǎng)站：

　　1. 離開當前網(wǎng)站，轉(zhuǎn)到其他網(wǎng)站

　　2. 關(guān)上瀏覽器窗口。

　　由于這已是根深蒂固的Web 使用模式，

　　所以不能指望用戶正確地退出網(wǎng)站。當編寫測試腳本時，應(yīng)用確定正確退出和非正確退出的用戶比例，然后根據(jù)這個比例編寫腳本。我們遇到的一個大型汽車網(wǎng)站，已經(jīng)為此困擾了一年多，他們的應(yīng)用服務(wù)器每隔幾天會崩潰，他們已經(jīng)習慣于在晚上重起應(yīng)用服務(wù)器。仔細分析HTTP會話的使用模式，我們發(fā)現(xiàn)閑置的會話非常多。

　　我們檢查了他們的測試腳本，發(fā)現(xiàn)每個測試場景都包含了正確的退出。他們是基于這個假設(shè)進行優(yōu)化的，因此優(yōu)化工作并沒有觸及閑置的會話內(nèi)存問題。在調(diào)整測試腳本，重新優(yōu)化系統(tǒng)環(huán)境后，由于"Outof memory"引發(fā)的強制重起問題解決了。