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

一、項(xiàng)目背景

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

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

二、項(xiàng)目特點(diǎn)

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

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

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

三、性能測(cè)試過(guò)程

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

測(cè)試前期準(zhǔn)備

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

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

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

2.組建測(cè)試團(tuán)隊(duì)

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

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

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

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

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

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

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

測(cè)試工具引入

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

測(cè)試計(jì)劃

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

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

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

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

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

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

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

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

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

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

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

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

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

4.制訂測(cè)試時(shí)間計(jì)劃

本案例中，測(cè)試時(shí)間計(jì)劃安排如表2所示。

表2 測(cè)試時(shí)間計(jì)劃

測(cè)試設(shè)計(jì)與開(kāi)發(fā)

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

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

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

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

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

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

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

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

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

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

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

2.測(cè)試場(chǎng)景設(shè)計(jì)

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

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

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

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

用例編號(hào)：TC_XXXX_XX-1

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

用戶步驟和驗(yàn)證方法。

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

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

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

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

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

測(cè)試執(zhí)行與管理

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

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

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

2.部署測(cè)試腳本和測(cè)試場(chǎng)景

部署測(cè)試腳本和測(cè)試場(chǎng)景通過(guò)LoadRunner來(lái)控制。LoadRunner本身提供了較為完善的對(duì)測(cè)試腳本和場(chǎng)景進(jìn)行部署和管理的機(jī)制。

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

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

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

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

表7 需要實(shí)際執(zhí)行的測(cè)試項(xiàng)目

測(cè)試分析

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

（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ù)超過(guò)50時(shí)，系統(tǒng)出現(xiàn)了一個(gè)明顯的性能瓶頸，根據(jù)性能下降曲線分析，在Suse操作系統(tǒng)環(huán)境下，性能的拐點(diǎn)應(yīng)該出現(xiàn)在48個(gè)Vuser左右。而在50并發(fā)用戶情況下，系統(tǒng)的平均響應(yīng)時(shí)間在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ù)超過(guò)58時(shí)，系統(tǒng)出現(xiàn)了一個(gè)明顯的性能瓶頸，根據(jù)性能下降曲線分析，在Redhat操作系統(tǒng)環(huán)境下，性能的拐點(diǎn)應(yīng)該出現(xiàn)在58個(gè)Vuser左右。而在50并發(fā)用戶情況下，系統(tǒng)的平均響應(yīng)時(shí)間在2～4秒之間。

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

（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ù)超過(guò)55時(shí)，系統(tǒng)出現(xiàn)了一個(gè)明顯的性能瓶頸，根據(jù)性能下降曲線分析法，在Redffag操作系統(tǒng)環(huán)境下，性能的拐點(diǎn)應(yīng)該出現(xiàn)在55個(gè)Vuser左右。而在50并發(fā)用戶情況下，系統(tǒng)的平均響應(yīng)時(shí)間在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曲線

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

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

（5）其他測(cè)試項(xiàng)目分析。

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

表8-1

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

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

四、案例小結(jié)

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

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

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