• 項目背景
• 項目特點
• 性能測試過程
  • 測試前期準(zhǔn)備
  • 測試工具引入
  • 測試計劃
  • 測試設(shè)計與開發(fā)
  • 測試執(zhí)行與管理
  • 測試分析
• 案例小結(jié)

一、項目背景

出于市場考慮，某集成商準(zhǔn)備面向中小企業(yè)推出一套基于其開發(fā)的J2EE應(yīng)用的解決方案，該解決方案不僅僅是一套開發(fā)完成的產(chǎn)品包，而是包括應(yīng)用系統(tǒng)、應(yīng)用服務(wù)器、數(shù)據(jù)庫服務(wù)器、服務(wù)器在內(nèi)的解決方案包。從市場策略方面考慮，該解決方案面向的是相對較低的中小企業(yè)市場，因此整個解決方案包要求在滿足客戶要求的情況下具有最大的性價比。

解決方案能夠為客戶提供的功能當(dāng)然是解決方案包首要考慮的問題，但除了功能外，作為整體推出的解決方案包必然需要提供良好的性能；另一方面，由于要求該解決方案包在滿足客戶要求的情況下具有最大的性價比，也就必須通過容量規(guī)劃的方式，選擇最合適的硬件設(shè)備、操作系統(tǒng)、應(yīng)用服務(wù)器和數(shù)據(jù)庫的配合。通過前期的選型和決策，擬采用IBM Open Power 710作為服務(wù)器，IBM Wep Shpere 9.0作為應(yīng)用服務(wù)器，Oracle 10g作為數(shù)據(jù)庫服務(wù)器，操作系統(tǒng)則從幾個不同的Linux發(fā)行版本中選擇最適合的。因此，對本項目來說，性能選型測試一方面需要驗證系統(tǒng)是否滿足預(yù)期的性能要求；另一方面，也要求能夠從多種不同的組合方式中選擇出最具有性價比的解決方案架構(gòu)。

二、項目特點

該項目是針對整體解決方案的選型測試，項目中的Web應(yīng)用系統(tǒng)采用J2EE架構(gòu)，服務(wù)器擬選用IBM Open Power 710，應(yīng)用服務(wù)器選用IBM Web Sphere 9.0，數(shù)據(jù)庫采用Oracle 10g，操作系統(tǒng)則需要從幾個不同的Linux發(fā)行版（Suse、Redhat、Redflag、Turbo）中選取具有最佳性能的一個。

該項目是一個典型的性能選型測試，測試過程中，需要根據(jù)不同的組合方式，用同樣的負(fù)載條件進(jìn)行測試，測試目的是找出各種組合中具有最佳性能的那個。

對這種類型的性能選型測試來說，需要重點關(guān)注兩個方面：一是規(guī)劃合理的組合方式和需要關(guān)注的性能指標(biāo)；二是需要保證每次測試的相同負(fù)載條件。

三、性能測試過程

本節(jié)描述性能測試的全過程，根據(jù)本書第5章的性能測試過程描述，按照PTGM模型分別對性能測試的各階段進(jìn)行闡述。

測試前期準(zhǔn)備

在了解該項目的基本狀況之后，首先開始測試前期準(zhǔn)備工作。

1.系統(tǒng)基礎(chǔ)功能驗證

在本案例中，系統(tǒng)基礎(chǔ)功能驗證工作不包括在選型測試工作中。

2.組建測試團隊

根據(jù)該項目的具體情況，建立一個3人的團隊負(fù)責(zé)本次測試工作。團隊的3個成員中，1名是系統(tǒng)工程師，1名是性能測試設(shè)計和分析人員，1名是性能測試開發(fā)和實施人員。所有的成員均來自組織內(nèi)部，且接受了必要的培訓(xùn)。

該團隊中的系統(tǒng)工程師承擔(dān)的工作較多，一方面需要搭建各種不同的環(huán)境；另一方面，在測試過程中，必須保持和相關(guān)廠商的聯(lián)系，確保操作系統(tǒng)已經(jīng)經(jīng)過仔細(xì)調(diào)優(yōu)，得到的測試結(jié)果是在當(dāng)前操作系統(tǒng)下的最佳結(jié)果。

3.測試工具需求確認(rèn)

根據(jù)系統(tǒng)測試的要求，綜合工具成本和測試團隊已有技能考慮，最終確定測試工具至少能滿足：

• 支持對Web系統(tǒng)的性能測試，支持HTTP和HTTPS協(xié)議。
• 負(fù)載生成器和調(diào)度工具運行在Windows平臺上。
• 支持對WebSphere、Oracle和Linux Server的性能計數(shù)器進(jìn)行監(jiān)控。

4.性能預(yù)備測試

本次性能選型測試需要針對各種不同配置進(jìn)行，在不同配置下進(jìn)行相同的測試，我們并沒有安排對每個不同配置下的系統(tǒng)進(jìn)行性能預(yù)備測試。

測試工具引入

測試工具引入在本性能測試過程中不作為一個關(guān)鍵的過程，根據(jù)本性能測試對工具的功能需求以及團隊成員本身使用工具的經(jīng)驗，最終選擇Mercury公司的LoadRunner 8.0版本工具作為本次測試使用的主要工具。

測試計劃

對本案例來說，由于并不是對系統(tǒng)進(jìn)行能力驗證的性能測試，因此在測試計劃階段，需要重點關(guān)注的是選擇典型的業(yè)務(wù)和場景，該業(yè)務(wù)和場景從以往對Web應(yīng)用的測試中獲取。

1.性能測試領(lǐng)域分析

根據(jù)對項目背景的了解，本性能測試要解決的主要問題是在何種配置條件下系統(tǒng)具有最佳的性能表現(xiàn)，根據(jù)領(lǐng)域分析，本測試應(yīng)該落在規(guī)劃能力領(lǐng)域。

2.用戶活動剖析與業(yè)務(wù)建模

該解決方案中的Web業(yè)務(wù)系統(tǒng)已經(jīng)在多個客戶現(xiàn)場運行了一段時間，并已經(jīng)經(jīng)歷過多次能力驗證領(lǐng)域的性能測試。因此，在本案例中，可以很容易地從以前的測試計劃中獲取典型的業(yè)務(wù)和場景。

本案例中，選取典型業(yè)務(wù)的原則是：

• 選取業(yè)務(wù)量較大的業(yè)務(wù)。
• 選取業(yè)務(wù)量不大但消耗系統(tǒng)資源多的業(yè)務(wù)。
• 選取需要重點關(guān)注的業(yè)務(wù)。

表1描述了在選型測試中將會使用到的所有業(yè)務(wù)，可以以此為基礎(chǔ)來進(jìn)一步分析用戶場景，并據(jù)此設(shè)計相應(yīng)的測試方案和用例。

表1 選取的業(yè)務(wù)

當(dāng)然，按照的要求，需要為每個業(yè)務(wù)準(zhǔn)備其相應(yīng)的業(yè)務(wù)操作描述（用例），在其他3個案例（《某省電信公司業(yè)務(wù)系統(tǒng)的性能測試》、《某通信企業(yè)Web業(yè)務(wù)系統(tǒng)的性能測試》）中，已經(jīng)展示了對業(yè)務(wù)操作進(jìn)行描述的方法，在本案例中這部分內(nèi)容不是重點，因此不再贅述。

3.確定性能目標(biāo)

本性能測試的應(yīng)用領(lǐng)域是規(guī)劃能力，由于解決方案包面對的是中小企業(yè)，預(yù)期的用戶數(shù)量主要從營銷部門獲得：

• 頁面響應(yīng)時間小于5秒。
• 能夠支持的并發(fā)用戶數(shù)不小于50，最大支持并發(fā)用戶數(shù)要求為100。
• 在50個并發(fā)用戶條件下，服務(wù)器的CPU平均使用率小于70%，內(nèi)存使用率小于75%；在100個并發(fā)用戶的條件下，服務(wù)器CPU平均使用率小于90%，內(nèi)存使用率小于85%。

4.制訂測試時間計劃

本案例中，測試時間計劃安排如表2所示。

表2 測試時間計劃

測試設(shè)計與開發(fā)

本案例中，由于需要在多個不同的環(huán)境中進(jìn)行性能測試，因此測試環(huán)境搭建和測試執(zhí)行占了主要的時間。

1.測試環(huán)境設(shè)計

本性能測試需要給出“在何種配置條件下系統(tǒng)具有最佳的性能表現(xiàn)？”這個問題的答案。因此，在性能測試中，需要安排多個不同的配置環(huán)境，在不同的配置環(huán)境下檢查應(yīng)用系統(tǒng)的性能，并對不同配置條件下的系統(tǒng)測試結(jié)果進(jìn)行分析。

根據(jù)該案例的背景描述，需要為不同的操作系統(tǒng)搭建不同的測試環(huán)境。最終確定的測試環(huán)境為4個，每個環(huán)境上除了操作系統(tǒng)不同外，其他內(nèi)容都相同，如表3、4、5、6所示。

表3 測試環(huán)境1

表4 測試環(huán)境2

表5 測試環(huán)境3

表6 測試環(huán)境4

本案例的數(shù)據(jù)環(huán)境設(shè)計根據(jù)系統(tǒng)環(huán)境進(jìn)行了簡單估算。以兩個月作為基準(zhǔn)的數(shù)據(jù)存儲周期，大致的數(shù)據(jù)規(guī)模如下。

1. 工單數(shù)據(jù)數(shù)量：19800條。
2. 知識經(jīng)驗庫數(shù)據(jù)數(shù)量：10000條。
3. 作業(yè)計劃數(shù)據(jù)數(shù)量：2800條。

對本案例來說，保證數(shù)據(jù)環(huán)境在每次測試中一致非常重要，否則很可能由于數(shù)據(jù)基礎(chǔ)的不同而導(dǎo)致對測試結(jié)果的分析出現(xiàn)失誤，因此在首次生成基礎(chǔ)的數(shù)據(jù)記錄后，通過數(shù)據(jù)庫的export命令將數(shù)據(jù)導(dǎo)出為本地文件并保存，每次測試開始前，都通過數(shù)據(jù)庫的import命令將數(shù)據(jù)直接導(dǎo)入到數(shù)據(jù)庫，保證數(shù)據(jù)環(huán)境的一致性。

2.測試場景設(shè)計

在表1的基礎(chǔ)上，直接使用選擇的每一個業(yè)務(wù)形成一個場景。此外，還對部分業(yè)務(wù)形成了組合場景。

3.測試用例設(shè)計

確定測試場景之后，原有的業(yè)務(wù)操作描述，可以更進(jìn)一步完善為可映射為腳本的測試用例描述。

本案例中，以“新建工單”業(yè)務(wù)為例，可以給出相應(yīng)的測試用例描述。

用例編號：TC_XXXX_XX-1

用例條件：用戶已登錄，登錄用戶具有新建工單的權(quán)限

用戶步驟和驗證方法。

1. 用戶單擊“新建工單”鏈接，進(jìn)入新建工單頁面。
   【驗證】銷售單頁面標(biāo)題為“新建工單”。
2. 用戶在新建工單頁面中輸入工單信息，包括“工單標(biāo)題”、“工單內(nèi)容”和“工單要求答復(fù)時間”3個域，其他保留默認(rèn)值，單擊“提交”按鈕。
   【驗證】返回HTTP200，轉(zhuǎn)向的頁面標(biāo)題為“工單新建成功”。

4.腳本和輔助工具的開發(fā)

按照測試用例的描述方式，通過測試工具錄制用例的步驟，并在測試工具中對腳本進(jìn)行調(diào)試和修改，保證腳本能夠達(dá)到測試要求，這就是腳本開發(fā)過程。本案例設(shè)計的業(yè)務(wù)過程相對簡單，按照用例描述直接錄制即可。

需要注意的是對腳本的參數(shù)化等處理。腳本錄制完成后，一般需要對其進(jìn)行修改操作，包括參數(shù)化、關(guān)聯(lián)和增加檢查點。第12章中以LoadRunner為例，描述了這幾種不同操作的方法和步驟。

輔助工具的開發(fā)取決于測試本身的需要，本案例沒有使用任何輔助工具。

測試執(zhí)行與管理

在測試執(zhí)行與管理之前的過程和活動中，己經(jīng)明確規(guī)劃了本性能測試的環(huán)境、場景和腳本，在本過程中，只需要按照前面階段的要求，將測試場景和腳本進(jìn)行部署，然后執(zhí)行測試并記錄結(jié)果即可。

1.建立測試環(huán)境

建立測試環(huán)境就是按照測試設(shè)計中設(shè)計的環(huán)境設(shè)計內(nèi)容部署測試環(huán)境，在本案例中，由于測試的目標(biāo)之一是要找到硬件配置是否是制約系統(tǒng)性能的主要因素，因此一個較大的風(fēng)險是能否保證各測試環(huán)境之間，體現(xiàn)在測試結(jié)果上的差異主要是由操作系統(tǒng)差異導(dǎo)致的，也就是說，在測試環(huán)境中，要盡量保證測試的結(jié)果不會受到其他因素的影響。為了實現(xiàn)這點，在本測試過程中使用了CheckList來檢查具體的數(shù)據(jù)庫設(shè)置和應(yīng)用服務(wù)器設(shè)置，并由系統(tǒng)工程師對其進(jìn)行了仔細(xì)的調(diào)整。

2.部署測試腳本和測試場景

部署測試腳本和測試場景通過LoadRunner來控制。LoadRunner本身提供了較為完善的對測試腳本和場景進(jìn)行部署和管理的機制。

本案例使用的場景類型是Manual Scenario類型，即完全由用戶設(shè)定場景的條件。

3.執(zhí)行測試和記錄結(jié)果

LoadRunner工具能夠在運行測試的過程中自行保存測試的結(jié)果，因此無需特別設(shè)計方法來記錄vu的響應(yīng)時間等數(shù)據(jù)，同時，LoadRunner還能夠記錄部分主機和應(yīng)用服務(wù)器的資源使用信息。

根據(jù)設(shè)計，最終需要運行的測試內(nèi)容如表7所示。

表7 需要實際執(zhí)行的測試項目

測試分析

根據(jù)表7的描述，列出執(zhí)行的各種不同測試結(jié)果，并進(jìn)行分析。為了不使描述顯得過于重復(fù)，我們沒有給出全部測試項目的圖表，只是有選擇性地給出了具有代表性的分析過程。以下分析結(jié)果以“查詢知識經(jīng)驗庫”和“新增作業(yè)計劃”為例進(jìn)行說明。

（1）Suse操作系統(tǒng)上50、100用戶條件下的Running Vusers-Average Transaction Response Time曲線如圖1和圖2所示。

圖1 50并發(fā)用戶條件下的Running Vusers-Average Transaction Response Time曲線

圖2 100并發(fā)用戶條件下的Running Vusers-Average Transaction Response Time曲線

從圖1和圖2可以看到，當(dāng)并發(fā)用戶數(shù)超過50時，系統(tǒng)出現(xiàn)了一個明顯的性能瓶頸，根據(jù)性能下降曲線分析，在Suse操作系統(tǒng)環(huán)境下，性能的拐點應(yīng)該出現(xiàn)在48個Vuser左右。而在50并發(fā)用戶情況下，系統(tǒng)的平均響應(yīng)時間在3～5秒之間。

（2）Redhat操作系統(tǒng)上50、100用戶條件下的Running Vusers-Average Transaction Response Time曲線如圖3和圖4所示。

圖3 50并發(fā)用戶條件下的Running Vusers-Average Transaction Response Time曲線

圖4 100并發(fā)用戶條件下的Running Vusers-Average Transaction Response Time曲線

從圖3和圖4可以看到，當(dāng)并發(fā)用戶數(shù)超過58時，系統(tǒng)出現(xiàn)了一個明顯的性能瓶頸，根據(jù)性能下降曲線分析，在Redhat操作系統(tǒng)環(huán)境下，性能的拐點應(yīng)該出現(xiàn)在58個Vuser左右。而在50并發(fā)用戶情況下，系統(tǒng)的平均響應(yīng)時間在2～4秒之間。

因此，單從系統(tǒng)能夠支持的并發(fā)用戶數(shù)考慮，在Redhat環(huán)境下的系統(tǒng)比Suse環(huán)境下的系統(tǒng)有一定的優(yōu)勢。

（3）Redffag操作系統(tǒng)上50、100用戶條件下的Running Vusers-Average Transaction Response Time曲線如圖5和圖6所示。

圖5 50并發(fā)用戶條件下的Running Vusers—Average Transaction Response Time曲線

圖6 100并發(fā)用戶條件下的Running Vusers—Average Transaction Response Time曲線

從圖5和圖6可以看到，當(dāng)并發(fā)用戶數(shù)超過55時，系統(tǒng)出現(xiàn)了一個明顯的性能瓶頸，根據(jù)性能下降曲線分析法，在Redffag操作系統(tǒng)環(huán)境下，性能的拐點應(yīng)該出現(xiàn)在55個Vuser左右。而在50并發(fā)用戶情況下，系統(tǒng)的平均響應(yīng)時間在3～5秒之間。

從曲線上看，Redffag上的性能表現(xiàn)與Suse上的性能表現(xiàn)基本相當(dāng)。

（4）Turbo操作系統(tǒng)上50、100用戶條件下的Running Vusers-Average Transaction Response Time曲線7和圖8所示。

圖7 50并發(fā)用戶條件下的Running Vusers-Average Transaction Response Time曲線

圖8 100并發(fā)用戶條件下的Running Vusers-Average Transaction Response Time曲線

從圖形上可以明顯地看到，相對于其他3個操作系統(tǒng)，Turbo操作系統(tǒng)下的性能表現(xiàn)明顯要差一些。在100并發(fā)用戶條件下，從30個并發(fā)用戶開始，響應(yīng)時間就大于20秒；而在50并發(fā)用戶條件下，在25個并發(fā)用戶處，系統(tǒng)有一個明顯的性能瓶頸。

由于所有操作系統(tǒng)的優(yōu)化調(diào)整都是由廠商的工程師直接進(jìn)行的，不排除在調(diào)整過程中出現(xiàn)廠商沒有很好地進(jìn)行操作系統(tǒng)設(shè)置優(yōu)化，導(dǎo)致測試結(jié)果存在明顯差異的情況。

（5）其他測試項目分析。

以上僅從系統(tǒng)能夠支持的并發(fā)用戶數(shù)角度對各種不同配置下的系統(tǒng)進(jìn)行了比較，其實對選型測試來說，需要比較的內(nèi)容還遠(yuǎn)不止這些。表8給出了總體的比較結(jié)果。

表8-1

表8-2 總體比較結(jié)果

從表8可以看到，在不同的操作系統(tǒng)上，CPU、內(nèi)存使用情況都會有一些差異，但從總體來看，差異并不明顯。也就是說，不同的Linux操作系統(tǒng)并不是影響性能的關(guān)鍵性因素。綜合總體比較結(jié)果以及前面分析的各不同配置條件對并發(fā)用戶數(shù)的支持來看，RedHat操作系統(tǒng)相對來說具有較優(yōu)的性能。

四、案例小結(jié)

該案例的重點在于演示性能選型測試的過程，并進(jìn)一步演示了如何使用LoadRunner進(jìn)行結(jié)果分析。

性能選型測試/容量規(guī)劃測試是實際工作中較為常見的一類性能測試要求，一般而言，這種類型的測試都需要通過性能測試的手段從不同的配置中選取具有最佳性能的配置。這種類型的測試需要在兩個方面特別注意：一是環(huán)境的一致性；二是確定性能測試的主要比較指標(biāo)。

最后要說明的是，本案例僅描述了一個筆者親身經(jīng)歷過的選型測試，其中包含的數(shù)據(jù)不能用來說明本案例涉及的Linux操作系統(tǒng)的性能優(yōu)劣。