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

項(xiàng)目背景

該案例是某通信企業(yè)Web業(yè)務(wù)系統(tǒng)的性能測試。該Web業(yè)務(wù)系統(tǒng)用于管理企業(yè)的備品和備件，包括對(duì)網(wǎng)絡(luò)設(shè)備的庫存管理、庫存流轉(zhuǎn)、備品備件的查詢統(tǒng)計(jì)等功能。其中庫存管理、備品備件查詢等功能主要是對(duì)數(shù)據(jù)庫的增、刪、改、查操作，庫存流轉(zhuǎn)則主要體現(xiàn)為工作流的實(shí)現(xiàn)。

該系統(tǒng)的主要用戶是通信企業(yè)的備品備件管理人員，通過該系統(tǒng)，管理人員能夠?qū)ΜF(xiàn)有的備品備件庫數(shù)據(jù)進(jìn)行查詢、更新，也可以通過該系統(tǒng)提供的業(yè)務(wù)流程完成備品備件的出庫和入庫操作。

對(duì)系統(tǒng)的測試在系統(tǒng)上線時(shí)進(jìn)行，主要目的是驗(yàn)證系統(tǒng)的性能能否達(dá)到用戶要求。

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

該項(xiàng)目基于J2EE實(shí)現(xiàn)，采用Tomcat作為應(yīng)用服務(wù)器，架構(gòu)上使用Struts+EJB+Herbinate，在業(yè)務(wù)上實(shí)現(xiàn)了多個(gè)流轉(zhuǎn)的流程。

該系統(tǒng)是一個(gè)典型的J2EE應(yīng)用，從性能測試的角度來說，具有很強(qiáng)的代表性。從技術(shù)的角度來說，該系統(tǒng)使用了驗(yàn)證碼方式防止對(duì)系統(tǒng)口令的暴力破解和可能的內(nèi)部SPAM，由于現(xiàn)在越來越多的系統(tǒng)都采用驗(yàn)證碼方式提高系統(tǒng)的安全性，因此在對(duì)本案例的描述中也特別給出了針對(duì)這種驗(yàn)證碼的性能測試解決方案。

該系統(tǒng)的網(wǎng)絡(luò)環(huán)境和設(shè)備相對(duì)簡單，網(wǎng)絡(luò)環(huán)境是企業(yè)內(nèi)部的千兆網(wǎng)絡(luò)，基本不可能對(duì)系統(tǒng)性能造成影響；設(shè)備方面，采用一臺(tái)UNIX服務(wù)器作為數(shù)據(jù)庫服務(wù)器，一臺(tái)UNIX服務(wù)器作為應(yīng)用服務(wù)器。

該系統(tǒng)是一個(gè)以人機(jī)交互為主的系統(tǒng)，因此，對(duì)系統(tǒng)性能的體現(xiàn)主要通過響應(yīng)時(shí)間來給出。

由于Web應(yīng)用采用的協(xié)議單一（HTTP和HTTPS協(xié)議），因此特別適合用商業(yè)的性能測試工具（如LoadRunner）來輔助進(jìn)行測試，本案例的描述中重點(diǎn)結(jié)合LoadRunner的使用，描述了在項(xiàng)目性能測試中用LoadRunner等工具進(jìn)行測試的方法。

性能測試過程

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

測試前期準(zhǔn)備

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

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

本案例中描述的性能測試安排在功能驗(yàn)收測試之后，因此在性能測試中不需要額外安排基礎(chǔ)功能驗(yàn)證。

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

根據(jù)該項(xiàng)目的具體情況，建立一個(gè)5人的團(tuán)隊(duì)負(fù)責(zé)本次測試工作。由于該系統(tǒng)的設(shè)備環(huán)境和網(wǎng)絡(luò)環(huán)境相對(duì)簡單，因此沒有特別在團(tuán)隊(duì)中包括系統(tǒng)工程師，團(tuán)隊(duì)的5個(gè)成員中，1名是數(shù)據(jù)庫工程師，1名是性能測試設(shè)計(jì)和分析人員，3名是性能測試開發(fā)和實(shí)施人員。

在測試開始之前，根據(jù)對(duì)項(xiàng)目的了解，預(yù)計(jì)該系統(tǒng)的性能測試難點(diǎn)主要在測試設(shè)計(jì)和測試腳本實(shí)現(xiàn)階段，由于系統(tǒng)協(xié)議單一，架構(gòu)相對(duì)比較簡單，且有合適的商業(yè)工具可以直接使用，因此在測試工具方面不需要投入太多的精力。

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

考慮到系統(tǒng)測試的要求，確定的測試工具需求如下：

• 支持HTTP/HTTPS協(xié)議層上的測試。
• 能監(jiān)控UNIX服務(wù)器的主要性能計(jì)數(shù)器值，如服務(wù)器的內(nèi)存使用狀況、CPU使用狀況、磁盤I/O情況等。
• 能監(jiān)控Windows服務(wù)器的主要性能計(jì)數(shù)器，如服務(wù)器的內(nèi)存使用狀況、CPU使用狀況、磁盤I/O情況、進(jìn)程的內(nèi)存使用情況等。
• 支持對(duì)Oracle數(shù)據(jù)庫的主要性能計(jì)數(shù)器值進(jìn)行監(jiān)控。
• 支持對(duì)Tomcat應(yīng)用服務(wù)器的JVM內(nèi)存使用狀況進(jìn)行監(jiān)控。

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

性能預(yù)備測試用于對(duì)系統(tǒng)建立直觀的認(rèn)識(shí)，在正式開始測試之前體驗(yàn)性地使用了本系統(tǒng)的主要功能，根據(jù)體驗(yàn)，系統(tǒng)的所有操作均能在4秒之內(nèi)完成，響應(yīng)時(shí)間相對(duì)較長的是登錄過程。

測試工具引入

根據(jù)測試前期準(zhǔn)備確定的測試工具需求，目前市面上的性能測試工具基本都能夠支持這些需求，唯一有困難的是“監(jiān)控Tomcat應(yīng)用服務(wù)器的JVM使用狀況”，基本上所有的商業(yè)工具都不支持該需求。

最終確定的測試工具包括兩個(gè)方面的內(nèi)容：采用LoadRunner工具作為主要的性能測試工具；對(duì)Tomcat的JVM使用狀況的監(jiān)控通過自行開發(fā)工具來實(shí)現(xiàn)。

測試計(jì)劃

測試計(jì)劃階段需要分析用戶活動(dòng)，確定系統(tǒng)的性能目標(biāo)。

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

根據(jù)對(duì)項(xiàng)目背景的了解，本性能測試要解決的主要問題為：驗(yàn)證系統(tǒng)是否達(dá)到了預(yù)期的性能指標(biāo)。

這些內(nèi)容對(duì)應(yīng)于第2章中給出的能力驗(yàn)證應(yīng)用領(lǐng)域。進(jìn)一步根據(jù)第2章的內(nèi)容，本測試可用的性能測試方法包括PerformanceTesting和StressTesting方法。

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

本案例描述系統(tǒng)的建模主要通過用戶活動(dòng)建模和業(yè)務(wù)建模來體現(xiàn)和進(jìn)行。

根據(jù)對(duì)被測系統(tǒng)的使用用戶進(jìn)行書面的問卷調(diào)查，在問卷基礎(chǔ)上進(jìn)行分析，可以得到如表1所示的典型用戶活動(dòng)分析列表。

表1

表1初步描述了用戶對(duì)各業(yè)務(wù)系統(tǒng)的使用情況，可以以此為基礎(chǔ)來進(jìn)一步分析用戶場景，并據(jù)此設(shè)計(jì)相應(yīng)的測試方案和用例，業(yè)務(wù)場景的分析與企業(yè)的實(shí)際業(yè)務(wù)模式相關(guān)。

在對(duì)用戶活動(dòng)進(jìn)行建模的過程中，還得到了以下數(shù)據(jù)：

1. 平均每天使用該系統(tǒng)的總用戶數(shù)約為600。
2. 平均每個(gè)用戶的loginsession時(shí)間為4小時(shí)（也就是說，平均每個(gè)用戶在8小時(shí)時(shí)間內(nèi)有4小時(shí)處于“使用系統(tǒng)”的狀態(tài)）。
3. 平均每個(gè)用戶在loginsession的時(shí)間范圍內(nèi)進(jìn)行500個(gè)業(yè)務(wù)操作。

根據(jù)以上數(shù)據(jù)，可以用第1章給出的公式進(jìn)行計(jì)算：

并發(fā)用戶數(shù)：600×4/8=300

吞吐量：300×500/（4×60×60）=10，單位是頁面瀏覽數(shù)/秒（PageView/sec）。

有了這些數(shù)據(jù)就可以進(jìn)行測試場景的設(shè)計(jì)了。

在分析了用戶的行為之后，為了給測試腳本開發(fā)提供依據(jù)，還需要對(duì)每個(gè)業(yè)務(wù)的操作過程進(jìn)行描述。在本案例中，以“庫存流轉(zhuǎn)―審批”為例，對(duì)業(yè)務(wù)操作進(jìn)行描述。

從表1中可以看到，該系統(tǒng)的主要業(yè)務(wù)集中在庫存流轉(zhuǎn)流程相關(guān)的活動(dòng)上，因?yàn)檫@些活動(dòng)都圍繞流轉(zhuǎn)進(jìn)行，在業(yè)務(wù)場景設(shè)計(jì)時(shí)必須考慮流程之間的交互性。

另外，“導(dǎo)入備件Excel文件”業(yè)務(wù)的發(fā)生頻率和實(shí)際使用的用戶數(shù)量都不大，但由于每次的導(dǎo)入操作均會(huì)導(dǎo)入大量的數(shù)據(jù)，導(dǎo)入過程中系統(tǒng)承受的壓力很大，因此在設(shè)計(jì)場景時(shí)有必要單獨(dú)考慮該場景。

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

本性能測試的應(yīng)用領(lǐng)域已被確定為能力驗(yàn)證，在確定性能目標(biāo)時(shí)，主要圍繞這個(gè)方面確定。

本項(xiàng)目是一個(gè)開發(fā)項(xiàng)目，從需求和設(shè)計(jì)中可以獲得關(guān)于該系統(tǒng)性能目標(biāo)的描述。根據(jù)需求和設(shè)計(jì)文檔，該系統(tǒng)的性能約束在文檔中的表達(dá)如下：

1. 系統(tǒng)的頁面響應(yīng)時(shí)間不超過10秒。
2. 需要評(píng)估導(dǎo)入備件Excel文件對(duì)系統(tǒng)性能的影響，如果該操作影響其他業(yè)務(wù)，需給出建議。
3. 系統(tǒng)能夠穩(wěn)定運(yùn)行。

在這些描述中，第（1）條是比較清晰的性能需求描述；第（2）條實(shí)際描述的并不是需求，而是希望在性能測試中安排對(duì)“導(dǎo)入”操作的性能表現(xiàn)的測試；第（3）條描述的是用戶的性能要求，但不夠明確。

經(jīng)過多次溝通，最終確定的明確的性能需求如下：

系統(tǒng)在典型數(shù)據(jù)量情況下，頁面響應(yīng)時(shí)間不超過10秒：典型數(shù)據(jù)量定義為當(dāng)前系統(tǒng)的所有備件規(guī)模的靜態(tài)數(shù)據(jù)和半年的流轉(zhuǎn)數(shù)據(jù)。

1. 系統(tǒng)在典型數(shù)據(jù)量情況下，頁面響應(yīng)時(shí)間不超過10秒：典型數(shù)據(jù)量定義為當(dāng)前系統(tǒng)的所有備件規(guī)模的靜態(tài)數(shù)據(jù)和半年的流轉(zhuǎn)數(shù)據(jù)。
2. 系統(tǒng)能夠在高于實(shí)際系統(tǒng)運(yùn)行壓力1倍的壓力情況下，持續(xù)穩(wěn)定工作72小時(shí)：持續(xù)穩(wěn)定工作定義為在系統(tǒng)運(yùn)行期間，系統(tǒng)的可用資源不會(huì)出現(xiàn)持續(xù)性地減少，用戶響應(yīng)速度沒有顯著變化。

除了這兩個(gè)直接從文檔中反映的系統(tǒng)性能需求，根據(jù)和用戶、項(xiàng)目經(jīng)理等的溝通，另外確定的其他性能目標(biāo)包括：

1. 評(píng)估典型規(guī)模的Excel備件文件導(dǎo)入時(shí)對(duì)系統(tǒng)性能的影響：評(píng)估內(nèi)容包括兩個(gè)方面，一個(gè)方面是對(duì)典型規(guī)模的Excel文件（考慮到系統(tǒng)實(shí)際的備件數(shù)據(jù)規(guī)模，選擇一個(gè)20MB、包含50000條數(shù)據(jù)記錄的Excel文件）進(jìn)行導(dǎo)入時(shí)的效率評(píng)估；另一方面是通過組合場景，判斷導(dǎo)入操作對(duì)其他操作的影響。
2. 在頁面響應(yīng)時(shí)間要求10秒的情況下，找到系統(tǒng)能夠承受的最大用戶數(shù)量：該要求可以給用戶提供一個(gè)可擴(kuò)展性的參考。

表2給出了分析整理后的性能需求描述。

表2

對(duì)能力驗(yàn)證應(yīng)用領(lǐng)域來說，本測試需要重點(diǎn)關(guān)注的是業(yè)務(wù)的響應(yīng)時(shí)間、各服務(wù)器的資源使用狀況，結(jié)合性能測試需求，性能目標(biāo)可以定義如下：

1. 在典型用戶數(shù)量要求的情況下，服務(wù)器CPU平均使用率不高于75%，內(nèi)存使用率不高于75%。
2. 在穩(wěn)定性測試的壓力情況下，服務(wù)器CPU平均使用率不高于95%，內(nèi)存使用率不高于90%。

4.制定測試時(shí)間計(jì)劃

本案例采用商業(yè)性能測試工具LoadRunner進(jìn)行測試，由于本案例涉及較多的流程交互等內(nèi)容，因此重點(diǎn)集中在如何設(shè)計(jì)和實(shí)現(xiàn)合理的性能測試腳本，這需要消耗較多的時(shí)間和人力資源。

另外，測試結(jié)果的分析也需要安排足夠的時(shí)間進(jìn)行。本案例的測試時(shí)間計(jì)劃安排如表3所示。

表3

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

測試設(shè)計(jì)與開發(fā)包括測試環(huán)境設(shè)計(jì)、測試場景設(shè)計(jì)、測試用例設(shè)計(jì)和測試輔助工具開發(fā)多個(gè)活動(dòng)。對(duì)本案例而言，測試場景關(guān)注用戶以何種方式使用本系統(tǒng)，以場景來體現(xiàn)性能測試的目的和目標(biāo)。

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

本性能測試需要驗(yàn)證系統(tǒng)在實(shí)際生產(chǎn)部署環(huán)境上的性能，因此，選擇盡可能接近實(shí)際生產(chǎn)環(huán)境的環(huán)境來進(jìn)行測試。由于本測試的環(huán)境就是實(shí)際的生產(chǎn)環(huán)境，因此在環(huán)境設(shè)計(jì)上，沒有太多需要考慮的內(nèi)容。

最終確定的測試環(huán)境如表4所示。

表2給出了用作測試的基礎(chǔ)數(shù)據(jù)量?；A(chǔ)數(shù)據(jù)量的計(jì)算方法在前兩個(gè)案例中都有描述，在此不再重復(fù)。

表4

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

結(jié)合表1的和表2可以很容易地為該案例給出需要的測試場景。

根據(jù)上面給出的數(shù)據(jù)，設(shè)定的總并發(fā)用戶數(shù)為300，按照業(yè)務(wù)模塊訪問用戶數(shù)比例給定VU分配比例，為了達(dá)到10PageView/sec的吞吐量，每個(gè)VU的操作之間間隔應(yīng)該為300/10=30秒。

根據(jù)調(diào)查的結(jié)果，我們確定了幾個(gè)典型的測試場景，如表5所示。

表5-1

表5-2

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

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

在本案例中，可以將用戶業(yè)務(wù)操作形成更詳細(xì)的用例步驟。例如，“審批”業(yè)務(wù)可以描述如下：

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

用例條件：用戶已登錄，登錄用于具有審批的權(quán)限

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

1. 用戶單擊“庫存流轉(zhuǎn)”鏈接，進(jìn)入庫存流轉(zhuǎn)頁面。
   【驗(yàn)證】頁面出現(xiàn)“庫存流轉(zhuǎn)”提示字符串。
2. 用戶在頁面左側(cè)樹視圖上單擊“審批”鏈接，進(jìn)入審批頁面。
   【驗(yàn)證】頁面上出現(xiàn)“申請(qǐng)單列表”提示字符串。
3. 用戶在頁面給出的等待審批的申請(qǐng)單列表中選擇最上方的一個(gè)，單擊“審批”按鈕，進(jìn)入審批頁面。
   【驗(yàn)證】給出選中審批單信息，頁面上出現(xiàn)被選中審批單的編號(hào)。
4. 用戶輸入審批信息，單擊“通過”按鈕。
   【驗(yàn)證】頁面上出現(xiàn)“審批通過”提示字符串

從該用例的描述可以看到，在每個(gè)操作步驟之后，都給出了相應(yīng)的驗(yàn)證手段。對(duì)性能測試來說，驗(yàn)證手段同樣關(guān)鍵。性能測試工具（如LoadRunner等）在性能測試過程中為了VU的效率，一般只通過HTTP返回的HTTPCode判斷請(qǐng)求是否成功，對(duì)于典型的如HTTP500、HTTP404等錯(cuò)誤，LoadRunner能夠判斷，但如果采用了自定義錯(cuò)誤頁面，或是返回了表示異常狀態(tài)的頁面，LoadRunner便不能發(fā)現(xiàn)。

基于以上原因，通常需要在腳本中添加一些用于驗(yàn)證返回頁面是否正確的代碼，最常用的方法是判斷頁面中是否存在特定的字符串。因此，在每個(gè)用例中都描述了每個(gè)步驟結(jié)果的驗(yàn)證方法。

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

本案例采用LoadRunner作為性能測試工具，下面通過該案例首先介紹LoadRunner在性能測試中的一般應(yīng)用步驟，然后重點(diǎn)說明在性能測試過程中遇到的問題和解決方法，依次演示LoadRunner使用中的一些技巧和技術(shù)。

（1）LoadRunner的性能測試過程。

用LoadRunner工具輔助進(jìn)行性能測試，一般包括錄制和調(diào)試腳本、設(shè)置場景、運(yùn)行場景、收集結(jié)果并分析4個(gè)活動(dòng)。

錄制和調(diào)試腳本活動(dòng)使用LoadRunner的VirtualUserGenerator應(yīng)用（下文中簡稱為VUGenerator）完成，運(yùn)行該應(yīng)用，選擇合適的錄制協(xié)議，打開被測應(yīng)用的客戶端程序（對(duì)B/S應(yīng)用，客戶端程序就是瀏覽器），按照預(yù)期即可進(jìn)行錄制。LoadRunner錄制的腳本中體現(xiàn)的是客戶端和服務(wù)器之間的通信數(shù)據(jù)以及相互的交互關(guān)系。

腳本的錄制依據(jù)事先分析出的用戶活動(dòng)和案例。按照測試用例設(shè)計(jì)中給出的具體操作描述，打開VUGenerator工具，輸入應(yīng)用的起始URL，根據(jù)用例描述執(zhí)行操作，錄制腳本。LoadRunner針對(duì)Web應(yīng)用錄制的腳本默認(rèn)分為vuser_init、Action和vuser_end3段，其中，vuser_init和vuser_end段只在腳本運(yùn)行時(shí)執(zhí)行一次，而Action段的執(zhí)行次數(shù)由腳本或場景的RuntimeSetting控制。一般來說，在錄制腳本時(shí)，會(huì)把Login和Logout的步驟分別放在vuser_init和vuserend段中，而把針對(duì)業(yè)務(wù)的操作步驟放在Action段中。

VUGenerator同時(shí)提供了對(duì)腳本調(diào)試的良好支持。腳本錄制完成后，需要經(jīng)過一個(gè)仔細(xì)的調(diào)試階段才能保證腳本確實(shí)準(zhǔn)確無誤地反映了計(jì)劃中的測試意圖。調(diào)試過程中經(jīng)常進(jìn)行的操作是參數(shù)化、關(guān)聯(lián)和調(diào)試輸出。

設(shè)置場景活動(dòng)由LoadRunner的Controller工具支持。運(yùn)行Controller工具，根據(jù)測試設(shè)計(jì)中確定的典型測試場景（見表1），將不同的腳本按照?qǐng)鼍爸性O(shè)計(jì)的比例分配到一個(gè)場景中。并且，測試場景中還需要根據(jù)設(shè)計(jì)的典型場景中的“性能計(jì)數(shù)器”項(xiàng)目，設(shè)置需要進(jìn)行監(jiān)控的性能計(jì)數(shù)器內(nèi)容。圖1描述的是根據(jù)表5設(shè)計(jì)的“系統(tǒng)應(yīng)用典型場景1”實(shí)施的場景。

圖1

場景設(shè)置涉及的細(xì)節(jié)內(nèi)容較多，除了在該場景中分配執(zhí)行各腳本的VU數(shù)量外，還需要根據(jù)測試設(shè)計(jì)添加需要增加的性能計(jì)數(shù)器（見圖2），最后，特別需要關(guān)注的是針對(duì)腳本的RuntimeSetting設(shè)置（見圖3），例如，表5給出的“典型場景1”中描述了需要每個(gè)腳本Action部分迭代100次，這就需要在Controller的設(shè)置中給出每個(gè)腳本的迭代次數(shù)設(shè)置。

圖2

圖3

運(yùn)行場景活動(dòng)相對(duì)簡單，單擊Run頁面中的StartScenario按鈕，Controller就會(huì)自動(dòng)開始運(yùn)行場景，并在ScenarioStatus中顯示運(yùn)行時(shí)的信息。

收集結(jié)果并分析活動(dòng)需要Analysis應(yīng)用的支持，Analysis應(yīng)用可以被獨(dú)立啟動(dòng)，也可以從Controller程序中調(diào)用。從Controller程序中調(diào)用時(shí)，Analysis應(yīng)用直接讀取本Controller當(dāng)前場景運(yùn)行時(shí)的信息。圖4給出了Analysis應(yīng)用運(yùn)行時(shí)的界面。

圖4

Analysis應(yīng)用能夠根據(jù)用戶設(shè)定的性能計(jì)數(shù)器生成各種性能報(bào)表。不過，Analysis最多也只能起到輔助進(jìn)行性能測試分析的作用，要對(duì)性能測試的結(jié)果進(jìn)行分析，還要依靠測試分析者的經(jīng)驗(yàn)、技能和對(duì)系統(tǒng)的了解。

（2）錄制“登錄”腳本。

針對(duì)該應(yīng)用錄制登錄腳本時(shí)，驗(yàn)證碼是一個(gè)首要的困難。

驗(yàn)證碼是在進(jìn)行登錄或內(nèi)容提交時(shí)，頁面上隨機(jī)出現(xiàn)的人工可識(shí)別但機(jī)器不可識(shí)別的驗(yàn)證字符串（一般是采用背景、扭曲等方式產(chǎn)生的圖片），要求登錄或提交內(nèi)容的同時(shí)輸入，如果驗(yàn)證碼輸入錯(cuò)誤，則不允許進(jìn)行要求的操作。

本案例中的被測系統(tǒng)使用了驗(yàn)證碼技術(shù)，其要求輸入驗(yàn)證碼的頁面內(nèi)容如圖5所示。

驗(yàn)證碼可以有效防止采用機(jī)器猜測方法對(duì)口令的刺探，目前己經(jīng)被許多Internet或Intranet應(yīng)用接受為標(biāo)準(zhǔn)的實(shí)現(xiàn)方式。但對(duì)性能測試來說，驗(yàn)證碼卻帶來了很大的問題。因?yàn)轵?yàn)證碼具有阻止通過自動(dòng)工具嘗試的特性，因此，對(duì)于本質(zhì)上也是自動(dòng)化工具的性能測試工具，驗(yàn)證碼同樣具有相當(dāng)?shù)耐Α?/p>

圖5

具體到本案例系統(tǒng)，在錄制腳本時(shí)，LoadRunner可以錄制用戶輸入的“用戶名”、“密碼”和“驗(yàn)證碼”信息，但在回放時(shí)，由于要求的驗(yàn)證碼與錄制時(shí)的驗(yàn)證碼不可能相同，因此回放必然會(huì)失敗。

為使性能測試能夠順利進(jìn)行，需要采用某種方法解決上述問題。在筆者的實(shí)際工作中，通常使用下面3種方法解決該問題。

第1種方法是最容易想到的方法——在被測系統(tǒng)中暫時(shí)屏蔽驗(yàn)證功能，也就是說，為性能測試臨時(shí)修改應(yīng)用，在應(yīng)用中屏蔽驗(yàn)證碼（也就是說，無論用戶輸入的是什么驗(yàn)證碼，應(yīng)用都認(rèn)為其是正確的）。

這種方法最容易實(shí)現(xiàn)，對(duì)性能測試結(jié)果也不會(huì)有太大的影響。這種方式去掉了“驗(yàn)證驗(yàn)證碼正確性”這個(gè)環(huán)節(jié)，從理論上來說，測試得到的結(jié)果與存在“驗(yàn)證驗(yàn)證碼正確性”環(huán)節(jié)的應(yīng)用系統(tǒng)存在細(xì)微的差異，不過考慮到此環(huán)節(jié)一般不會(huì)成為系統(tǒng)性能瓶頸，因此認(rèn)為這種處理方式對(duì)性能測試結(jié)果沒有太大的影響。

這種方法對(duì)于處于未上線狀態(tài)或在受控的測試環(huán)境中運(yùn)行的系統(tǒng)非常適用，但對(duì)于已經(jīng)實(shí)際上線運(yùn)行的系統(tǒng)來說，這種方法有一個(gè)明顯的問題：屏蔽驗(yàn)證功能會(huì)對(duì)己經(jīng)在線運(yùn)行的業(yè)務(wù)造成非常大的安全性風(fēng)險(xiǎn)。

因此，我們建議在受控的測試環(huán)境中采用該方法，但對(duì)于已上線的系統(tǒng)來說，不推薦使用該方法。

第2種方法是在第1種方法的基礎(chǔ)上稍微進(jìn)行一些改進(jìn)。

第1種方法的主要問題是安全性問題，為了應(yīng)對(duì)對(duì)在線系統(tǒng)安全性的威脅但在其中留一個(gè)“后門”——設(shè)定一個(gè)“萬，可以在修改程序時(shí)不取消驗(yàn)證，能驗(yàn)證碼”，只要用戶輸入該“萬能驗(yàn)證碼”，應(yīng)用就認(rèn)為驗(yàn)證通過，否則，還是按照原先的驗(yàn)證方式進(jìn)行驗(yàn)證。

這種方式仍然存在安全性問題，但由于可以通過管理手段將“萬能驗(yàn)證碼”控制在一個(gè)較小的范圍內(nèi)，而且只在性能測試期間保留這個(gè)“后門，基本上可以看作是可靠的。

相對(duì)第1種方法來說，這種方法在安全性方面進(jìn)行了改進(jìn)，在能夠通過管理手段控制“萬能驗(yàn)證碼”范圍的情況下，該方法不失為一種簡單易行且相對(duì)安全的方法。

第3種方法采用更進(jìn)一步的方法來處理驗(yàn)證碼的問題。

LoadRunner能夠調(diào)用外部的DLL或組件接口，考慮到這個(gè)特性可以根據(jù)“驗(yàn)證碼驗(yàn)證”的實(shí)現(xiàn)，寫一個(gè)獲取驗(yàn)證碼的動(dòng)態(tài)庫，在測試腳本中調(diào)用其接口即可。關(guān)于如何在LoadRunner中使用外部DLL，參見本書第11章的內(nèi)容。

在使用以上驗(yàn)證碼處理的方法時(shí)，特別要注意，如果針對(duì)的是己上線運(yùn)行的實(shí)際系統(tǒng)，無論用哪種方法，測試完成后，都必須立刻將應(yīng)用恢復(fù)，并對(duì)系統(tǒng)進(jìn)行一次安全審計(jì)，以免在測試期間被他人入侵。

在本案例中，采用第2種方法來解決驗(yàn)證碼帶來的問題。

以下是腳本中與登錄相關(guān)的部分代碼：

圖6-1

圖6-2

這段腳本中灰色背景的粗斜體內(nèi)容就是修改系統(tǒng)實(shí)現(xiàn)后留下的“后門”，其中，5847是在代碼中控制的一個(gè)“萬能驗(yàn)證碼”，主要用戶輸入該驗(yàn)證碼，系統(tǒng)就認(rèn)為驗(yàn)證通過。

細(xì)心的讀者還會(huì)發(fā)現(xiàn)，這段代碼已經(jīng)經(jīng)過了關(guān)聯(lián)處理，其中粗斜體標(biāo)識(shí)的內(nèi)容就是關(guān)聯(lián)產(chǎn)生的參數(shù)內(nèi)容。這段代碼的關(guān)聯(lián)是通過LoadRunner的“自動(dòng)關(guān)聯(lián)”方式實(shí)現(xiàn)的，具體實(shí)現(xiàn)方法請(qǐng)見第11章。

解決了驗(yàn)證碼和登錄時(shí)關(guān)聯(lián)的問題后，登錄腳本還需要處理的另一個(gè)問題就是針對(duì)輸入的用戶名和口令進(jìn)行參數(shù)化處理，本案例中共使用了10組不同的用戶名和口令組合。對(duì)用戶名和口令實(shí)現(xiàn)參數(shù)化的具體步驟請(qǐng)見第11章。

（3）錄制“新建申請(qǐng)單”腳本。

錄制“新建申請(qǐng)單”腳本需要首先按照設(shè)計(jì)中該用例的操作步驟進(jìn)行錄制，以下是按照“新建申請(qǐng)單”用例步驟進(jìn)行錄制后生成的部分腳本代碼。

圖7

從腳本中可以看到，腳本中給出了申請(qǐng)的發(fā)起時(shí)間和到期時(shí)間，為了使腳本具有更好的適應(yīng)性，我們決定將這兩個(gè)時(shí)間分別以“當(dāng)前時(shí)間”和“當(dāng)前時(shí)間的前4天”進(jìn)行替代，這需要對(duì)腳本進(jìn)行參數(shù)化操作。在VUGenerator中，選中需要參數(shù)化的內(nèi)容（兩個(gè)時(shí)間），從右鍵菜單中選擇Replacewithaparameter命令，在出現(xiàn)的對(duì)話框中設(shè)定參數(shù)類型為Date/Time，設(shè)置時(shí)間格式為適合的格式，如圖8所示。

設(shè)置到期時(shí)間時(shí)，需要將參數(shù)在當(dāng)前時(shí)間的基礎(chǔ)上再增加4天。圖9所示為設(shè)置到期時(shí)間的對(duì)話框，要注意其中設(shè)置的Offsetparameterby選項(xiàng)。

另外，為了便于直觀地識(shí)別數(shù)據(jù)是在哪次操作時(shí)插入的，在新建申請(qǐng)單時(shí)將“備注”的內(nèi)容修改為“test-”+“當(dāng)前時(shí)間”（當(dāng)前時(shí)間精確到秒）。

圖8

圖9

參數(shù)化修改完成后的腳本代碼如下：

圖10

除了參數(shù)化之外，在腳本中還需要體現(xiàn)“驗(yàn)證返回結(jié)果是否正確”，驗(yàn)證返回結(jié)果是否正確通過LoadRunner提供的web_eg_find函數(shù)實(shí)現(xiàn)。該函數(shù)的原型是：

圖11

在腳本中加入該函數(shù)可以根據(jù)頁面是否存在指定的文本等來驗(yàn)證系統(tǒng)處理的正確性。在用例設(shè)計(jì)時(shí)我們給出了“審批”業(yè)務(wù)的用例，其中包括的每個(gè)“驗(yàn)證”點(diǎn)都可以用這種方式來處理。例如，對(duì)給出的“【驗(yàn)證】頁面上出現(xiàn)‘申請(qǐng)單：列表’提示字符串”要求，可以在指定的發(fā)送請(qǐng)求的語句后添加下面的語句來驗(yàn)證：

Web_reg_find（"Text=申請(qǐng)表：列表＂，LAST）；

該語句可以驗(yàn)證返回的頁面上是否包含“申請(qǐng)表：列表”文本內(nèi)容。

（4）錄制“審批”腳本。

“審批”涉及到“流程”的概念，測試場景中要求一部分用戶“新建”申請(qǐng)單，另一部分用戶對(duì)已有的申請(qǐng)單進(jìn)行“審批”操作。錄制腳本時(shí)，假設(shè)錄制了對(duì)某一條己有的申請(qǐng)單的“審批”，在回放時(shí)，如果指定的申請(qǐng)單已經(jīng)被處理，則腳本的處理就會(huì)出錯(cuò)。

圖12給出了審批時(shí)能看到的待審批申請(qǐng)單列表，在性能測試過程中，每個(gè)VU看到的列表都會(huì)有所不同，為了使性能測試時(shí)每個(gè)VU都能夠順利執(zhí)行（處理待審批的申請(qǐng)單），必須在腳本中約定申請(qǐng)單的處理規(guī)則。為簡單起見，我們約定的規(guī)則是“每個(gè)VU都只處理當(dāng)前未被處理申請(qǐng)單列表中的第一條記錄”。

圖12

為了實(shí)現(xiàn)這個(gè)規(guī)則，必須對(duì)錄制后的腳本進(jìn)行一些處理。未處理的錄制生成腳本的相關(guān)部分代碼如下：

圖13

/＊?jiǎng)幼?——單擊指定的審批單記錄，給出審批單的詳細(xì)信息，允許用戶對(duì)其進(jìn)行審批＊/

圖14

/＊?jiǎng)幼?——填寫審批單后進(jìn)行提交，提交為＂通過審批＂＊/

圖15

以上代碼中的數(shù)字“20051223004”表明了要處理的記錄的ID。動(dòng)作2和動(dòng)作3都使用了唯一標(biāo)識(shí)審批單記錄的ID（數(shù)字20051223004）來對(duì)指定的審批單操作，那么，這個(gè)審批單的ID是從哪里得到的呢？

注意動(dòng)作1，該動(dòng)作返回當(dāng)前所有可被處理的審批單列表，幾乎可以肯定，用于標(biāo)識(shí)審批單ID的數(shù)字是作為該動(dòng)作的響應(yīng)返回給我們的。在VUGenerator中切換到TreeView視圖（單擊工具欄中的ViewTree按鈕），選擇ServerResponse選項(xiàng)卡，可以看到圖16所示的結(jié)果。

將圖16顯示的信息與圖15進(jìn)行對(duì)比，圖15是瀏覽器呈現(xiàn)的頁面，而圖16給出的則是該頁面的對(duì)象信息和以文本方式顯示的HTML內(nèi)容。

圖16左側(cè)樹型的3個(gè)radio:appids節(jié)點(diǎn)對(duì)應(yīng)于圖15顯示的3條待處理審批單。而且，從右側(cè)顯示的HTML文本內(nèi)容來看，這個(gè)Radio的value就是在后續(xù)腳本中需要使用到的用作ID的數(shù)值。

圖16

根據(jù)約定的規(guī)則，只要求每個(gè)VU處理第一條未審批的記錄，這樣問題就轉(zhuǎn)變成了一個(gè)典型的關(guān)聯(lián)問題―如何從動(dòng)作1返回的HTML文本中獲取到第一條未審批記錄的value值。

本書的第11章詳細(xì)描述了相關(guān)的內(nèi)容，對(duì)Web應(yīng)用的性能測試腳本而言，主要的關(guān)聯(lián)函數(shù)是web_reg_save_param函數(shù)。該函數(shù)必須放在產(chǎn)生需要獲取關(guān)聯(lián)內(nèi)容的語句之前（在本案例中，要放置在“動(dòng)作1”的語句之前），其原型是：

圖17

其中，第一個(gè)參數(shù)是關(guān)聯(lián)操作獲取的內(nèi)容保存的變量；最后一個(gè)參數(shù)是LAST；中間的參數(shù)描述了約束要獲取關(guān)聯(lián)內(nèi)容的各種屬性。指定關(guān)聯(lián)屬性時(shí)，必須指定“左邊界”和“右邊界”，視情況還可指定其他屬性。對(duì)本案例來說，需要進(jìn)行關(guān)聯(lián)的內(nèi)容在返回的HTML文本中，文本內(nèi)容為：

圖18

需要通過關(guān)聯(lián)操作獲取的內(nèi)容是“20051223004"，可以選取左邊界為“value="”，右邊界為“＂”。考慮到返回的HTML文本中能夠與選取的左邊界與右邊界匹配的內(nèi)容較多，因此還需要通過ORD屬性指明具體的需要關(guān)聯(lián)的內(nèi)容位置。

最終關(guān)聯(lián)處理完成后的腳本代碼片斷如下：

圖19

添加的web_reg_save_param語句表明，需要關(guān)聯(lián)的內(nèi)容存在于下一個(gè)Request為“＂”返回的HTML內(nèi)容的BODY中，該內(nèi)容左邊界為“value=＂”，右邊界，在這個(gè)HTML內(nèi)容的BODY中，我們想要通過關(guān)聯(lián)獲取的內(nèi)容順序排在第4個(gè)出現(xiàn)符合約束條件的位置。

（5）錄制其他腳本

錄制其他腳本的過程相對(duì)比較簡單，主要的技術(shù)細(xì)節(jié)和難點(diǎn)都在上幾個(gè)腳本的錄制過程中進(jìn)行了詳細(xì)描述，在此不再贅述。

測試執(zhí)行與管理

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

建立測試環(huán)境

建立測試環(huán)境只需要按照測試設(shè)計(jì)中設(shè)計(jì)的環(huán)境設(shè)計(jì)內(nèi)容部署測試環(huán)境。部署測試環(huán)境的工作一般由團(tuán)隊(duì)中的系統(tǒng)工程師完成，可以采用CheckList幫助進(jìn)行測試環(huán)境的部署。

表6給出了一個(gè)CheckList的示例。

表6

部署測試腳本和測試場景

根據(jù)設(shè)定的性能測試場景，在LoadRunner工具中對(duì)其進(jìn)行部署，部署過程請(qǐng)參考本書的第11章。

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

本性能測試中使用LoadRunner作為性能測試工具，性能指標(biāo)的數(shù)據(jù)主要通過LoadRunner的Monitor等獲得，因此主要通過LoadRunner來記錄數(shù)據(jù)。唯一例外的是針對(duì)Tomcat的服務(wù)器狀態(tài)監(jiān)控，這部分通過Tomcat提供的StatusSeverlet進(jìn)行監(jiān)控，監(jiān)控得到的數(shù)據(jù)保存在本地文件中，通過Excel進(jìn)行處理并以圖表的方式呈現(xiàn)。

用LoadRunner執(zhí)行測試非常簡單，只需要通過Controller的GUI界面就可以完成執(zhí)行和監(jiān)控工作。這部分的具體內(nèi)容請(qǐng)參考本書的第11章。對(duì)Tomca秒獲取一次數(shù)據(jù)t使用的JVM進(jìn)行監(jiān)控通過Tomcat的statusservelet實(shí)現(xiàn)，每5，獲取的數(shù)據(jù)保存在文本文件中。

但在實(shí)際的性能測試過程中，由于一些設(shè)置等問題，有時(shí)候會(huì)遇到執(zhí)行出錯(cuò)的情況。典型的情況是腳本在單獨(dú)回放時(shí)沒有任何問題，但部署到場景中執(zhí)行時(shí)卻出現(xiàn)一些奇怪的錯(cuò)誤。

本案例的執(zhí)行過程中就出現(xiàn)了這樣的情況。設(shè)定好測試場景并開始執(zhí)行后，從Controller的界面上可以看到“HTTP404:CannotfindpageXXXX”的錯(cuò)誤信息。剛看到這個(gè)問題時(shí)覺得特別奇怪，因?yàn)?在回放的過程中沒有出現(xiàn)過這樣的錯(cuò)誤，而且，從計(jì)數(shù)上看，通過的Transaction一共只有500個(gè)，除去200個(gè)vuser_init和vuser_end的Transaction，通過的只有300個(gè)，也就是說，每個(gè)腳本都只有第一次迭代的執(zhí)行是正確的。

仔細(xì)檢查WebServer的日志，發(fā)現(xiàn)該日志中有多個(gè)訪問timeout.jsp的記錄，詢問開發(fā)人員得知，session超時(shí)后才會(huì)訪問這個(gè)頁面。首先排除了由于迭代之間的等待時(shí)間過長導(dǎo)致超時(shí)的可能，隨后經(jīng)過仔細(xì)分析，覺得問題產(chǎn)生的原因可能與LoadRunner的設(shè)置有關(guān)。

HTTP協(xié)議本身是非面向連接的無狀態(tài)的協(xié)議，為了適應(yīng)Web應(yīng)用需要的交互特性，一般需要使用sessionid來標(biāo)識(shí)一些會(huì)話中的各個(gè)request和response為了保留住sessionid，一般的做法是用hiddenfield、cookie或是在URL上附加sessionid來解決，我們懷疑本題的出現(xiàn)與sessionid的處理相關(guān)。

查看LR記錄的頁面訪問數(shù)據(jù)（見圖20），可以看到，在ClientRequest中附帶了JSESSIONID的信息，可見，該應(yīng)用是用cookie解決sessionid的問題的。

圖20

接下來，可以大膽猜測，出現(xiàn)問題的原因可能是在兩次迭代之間LR清除了cookie，這就使在第一次迭代時(shí)應(yīng)用操作成功，但在隨后的執(zhí)行中由于不存在sessionid的標(biāo)識(shí)，使后續(xù)的操作全部失敗。

檢查腳本RuntimeSetting的設(shè)置（見圖21），果然Simulateanewuseroneachiteration選項(xiàng)被選中。LoadRunner的Manual里對(duì)Simulateanewuseroneachiteration選項(xiàng)的解釋是：“選中該選項(xiàng)后，LoadRunner在每次迭代時(shí)清除當(dāng)前的上下文。”iteration選項(xiàng)的解釋是：“選中該選項(xiàng)后，LoadRunner在每次迭代時(shí)清除當(dāng)前的上下文。”

圖21

取消選中該選項(xiàng)，重新運(yùn)行Controller中的場景，結(jié)果正常。

首先說一下session的起源。

HTTP協(xié)議本身是無狀態(tài)的，這與HTTP協(xié)議本來的目的是相符的，客戶端只需要簡單地向服務(wù)器請(qǐng)求下載某些文件，無論是客戶端還是服務(wù)器都記錄彼此過去的行為，每一次請(qǐng)求之間都是獨(dú)立的。

然而，對(duì)目前的大部分Web應(yīng)用來說，“無狀態(tài)”導(dǎo)致許多應(yīng)用都不得不花費(fèi)大量的精力記錄用戶的操作步驟，人們很快發(fā)現(xiàn)，如果能夠提供一些按需生成的動(dòng)態(tài)信息，會(huì)使Web變得更加有用，這種需求一方面迫使HTML逐步添加了表單、腳本、DOM等客戶端行為，另一方面在服務(wù)器端則出現(xiàn)了CGI規(guī)范以響應(yīng)客戶端的動(dòng)態(tài)請(qǐng)求，作為傳輸載體的HTTP協(xié)議也添加了文件上載、cookie這些特性。其中cookie的作用就是為了解決HTTP協(xié)議無狀態(tài)的缺陷所作出的努力。至于后來出現(xiàn)的session機(jī)制則是又一種在客戶端與服務(wù)器之間保持狀態(tài)的解決方案。下面用幾個(gè)例子來描述一下cookie和session機(jī)制之間的區(qū)別與聯(lián)系。假設(shè)在一個(gè)快餐廳有累計(jì)消費(fèi)滿200元返50元的優(yōu)惠，為了能夠準(zhǔn)確地返給用戶正確的金額，可以有這樣幾種方案：

（1）該店的店員很厲害，能記住每位顧客的累計(jì)消費(fèi)金額，只要顧客一走進(jìn)快餐廳，店員就知道該怎么對(duì)待了。這種做法就是協(xié)議本身支持狀態(tài)。

（2）發(fā)給顧客一張卡片，上面記錄著消費(fèi)的數(shù)量，一般還有一個(gè)有效期限。每次消費(fèi)時(shí)，如果顧客出示這張卡片，則此次消費(fèi)就會(huì)與以前或以后的消費(fèi)聯(lián)系起來。這種做法就是在客戶端保持狀態(tài)。

（3）發(fā)給顧客一張會(huì)員卡，除了卡號(hào)之外什么信息也不記錄，每次消費(fèi)時(shí)，如果顧客出示該卡片，店員則在店里的記錄本上找到該卡號(hào)對(duì)應(yīng)的記錄并添加一些消費(fèi)信息。這種做法就是在服務(wù)器端保持狀態(tài)。

由于HTTP協(xié)議是無狀態(tài)的，而出于種種考慮也不希望其成為有狀態(tài)的，因此，后面兩種方案就成為現(xiàn)實(shí)的選擇。具體來說，cookie機(jī)制采用的是在客戶端保持狀態(tài)的方案，而session機(jī)制采用的是在服務(wù)器端保持狀態(tài)的方案。同時(shí)也看到，由于采用服務(wù)器端保持狀態(tài)的方案在客戶端也需要保存一個(gè)標(biāo)識(shí)，所以session機(jī)制可能需要借助于cookie機(jī)制來達(dá)到保存標(biāo)識(shí)的目的。

session機(jī)制是一種服務(wù)器端的機(jī)制，服務(wù)器使用一種類似于散列表的結(jié)構(gòu)（也可能就是使用散列表）來保存信息。

當(dāng)程序需要為某個(gè)客戶端的請(qǐng)求創(chuàng)建一個(gè)session時(shí)，服務(wù)器首先檢查這個(gè)客戶端的請(qǐng)求里是否已包含了一個(gè)session標(biāo)識(shí)——sessionid，如果包含，則說明以前已經(jīng)為此客戶端創(chuàng)建過session，服務(wù)器就按照sessionid把這個(gè)session檢索出來使用（如果檢索不到，可能會(huì)新建一個(gè)）；如果不包含，則為此客戶端創(chuàng)建一個(gè)session并且生成一個(gè)與此session相關(guān)聯(lián)的sessionid，sessionid的值應(yīng)該是一個(gè)既不會(huì)重復(fù)，又不容易被找到規(guī)律以仿造的字符串，該sessionid將在本次響應(yīng)中返回給客戶端保存。

保存sessionid的方式可以采用cookie，這樣在交互過程中，瀏覽器可以自動(dòng)按照規(guī)則把這個(gè)標(biāo)識(shí)發(fā)送給服務(wù)器。一般將cookie，設(shè)定為類似于SESSIONID的名稱，如weblogic對(duì)于Web應(yīng)用程序生成的cookie，JSESSIONID=ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng！-145788764，該cookie的名字就是JSESSIONID。

測試分析

測試執(zhí)行完成后，通過LoadRunner的Analysis模塊，可以對(duì)測試過程中得到的性能數(shù)據(jù)進(jìn)行分析。

針對(duì)場景1、場景2、場景3的基礎(chǔ)性能分析

在進(jìn)行性能分析時(shí)，首先可以檢查Analysis模塊提供的SummaryReport。下面以系統(tǒng)應(yīng)用典型場景1為例進(jìn)行分析。

圖22給出了該場景運(yùn)行后的SummaryReport。

圖22

從圖22可以看出，整個(gè)測試過程中我們所關(guān)心的各業(yè)務(wù)（備件信息、查詢、申請(qǐng)表和登錄）的響應(yīng)時(shí)間均超過了性能需求中定義的10秒，因此從總體來說，本系統(tǒng)沒有達(dá)到性能要求。

到此為止，已經(jīng)得出了總體的結(jié)論，但是，性能測試結(jié)果的分析過程還遠(yuǎn)遠(yuǎn)沒有結(jié)束。因?yàn)槲覀兊哪康牟⒉粌H僅要得出“系統(tǒng)是否滿足預(yù)期的性能要求”這樣一個(gè)結(jié)論，還應(yīng)該給出更加具有建設(shè)性的意見和建議。

例如，還需要考慮：性能是在什么時(shí)候開始變壞的？性能可能的瓶頸在哪里？

為此，我們首先關(guān)注性能測試過程中業(yè)務(wù)的執(zhí)行成功比例。圖23給出了所有事務(wù)執(zhí)行情況的柱狀圖。

圖23

從圖23可以看到，所有的事務(wù)執(zhí)行都為成功，也就是說，測試結(jié)果基本可信。另外，從SummaryReport中的HTTP返回碼統(tǒng)計(jì)圖（見圖24）中可以看到，大部分的HTTP返回碼都是200和302，這說明應(yīng)用在HTTP返回層面上是成功的，少部分的404返回碼通過對(duì)日志的檢查，可以確認(rèn)是由于部分圖片文件缺失引起的，而這部分圖片文件的缺失是在開發(fā)過程中造成的，并不影響應(yīng)用本身的正確性，也不影響應(yīng)用性能測試結(jié)果的有效性。

圖24

確認(rèn)測試結(jié)果的有效性之后，接下來對(duì)應(yīng)用的性能表現(xiàn)進(jìn)行初步的分析。

圖25給出了“申請(qǐng)單”業(yè)務(wù)的“RunningVuser-AverageTransactionResponseTime關(guān)聯(lián)曲線，從該關(guān)聯(lián)圖可以看出，應(yīng)用系統(tǒng)的性能隨著RunningVusers數(shù)量的變化有一個(gè)明顯的變化趨勢(shì)。

圖25

具體的操作步驟如下：

1. 選中RunningVusers頁面，在圖形上單擊鼠標(biāo)右鍵，選擇MergeGraph命令。
2. 從彈出的對(duì)話框中選擇AverageTransactionResponseTime，從Merge類型中選擇Correlate，單擊OK按鈕。
3. Analysis應(yīng)用會(huì)打開一個(gè)新的頁面，該頁面顯示RunningVusers-AverageTransactionResponseTime曲線。

在圖25中，排除那些明顯的離散點(diǎn)，Vuser的數(shù)量從0至150增加時(shí)，各事務(wù)的性能表現(xiàn)基本保持穩(wěn)定；當(dāng)Vuser的數(shù)量從150至200增加時(shí)，事務(wù)的響應(yīng)時(shí)間呈緩慢的線性增長狀態(tài)；當(dāng)Vuser的數(shù)量超過200時(shí)，事務(wù)的響應(yīng)時(shí)間急劇增加。

根據(jù)本書第1章中描述的性能下降曲線分析法可以知道，150個(gè)用戶為最佳狀態(tài)下的最大并發(fā)用戶數(shù)。從圖中可以看到，當(dāng)Vuser增長到180時(shí)，基本上所有事務(wù)的響應(yīng)時(shí)間都在10秒以內(nèi)，因此，根據(jù)需求和性能下降曲線分析法，可以得出以下結(jié)論：

1. 在系統(tǒng)應(yīng)用典型場景1條件下，被測系統(tǒng)在180個(gè)并發(fā)用戶訪問的情況下事務(wù)響應(yīng)時(shí)間小于10秒。
2. Vuser為200是該系統(tǒng)性能表現(xiàn)的拐點(diǎn)。
3. “申請(qǐng)單”事務(wù)是性能相對(duì)最差的事務(wù)。

為了確定影響性能的主要因素，我們采用同樣的方法得到RunningVusers-UNIXResources關(guān)聯(lián)曲線。圖26給出了兩臺(tái)服務(wù)器的CPU使用狀況和RunningVusers的關(guān)聯(lián)曲線。

圖26

從圖26可以看到，當(dāng)Vuser超過110時(shí)，應(yīng)用服務(wù)器的CPU使用率就已經(jīng)超過了預(yù)期的75%，而將應(yīng)用服務(wù)器和數(shù)據(jù)庫服務(wù)器的CPU使用率進(jìn)行對(duì)比發(fā)現(xiàn)，數(shù)據(jù)庫服務(wù)器的CPU使用率一直都很低。由此可見，應(yīng)用服務(wù)器的CPU應(yīng)該是系統(tǒng)性能的瓶頸之一。

同樣，兩臺(tái)服務(wù)器的內(nèi)存使用狀況和RunningVusers的關(guān)聯(lián)曲線也可用于比較，在本案例中，經(jīng)過比較發(fā)現(xiàn)，在整個(gè)性能測試過程中，兩臺(tái)服務(wù)器的內(nèi)存使用都沒有超過可用內(nèi)存的70%，由此可見，可用內(nèi)存并不是性能瓶頸之一。

對(duì)應(yīng)用服務(wù)器來說，在性能測試中，除了關(guān)注服務(wù)器的內(nèi)存使用狀況外，一個(gè)更重要的需要關(guān)注的內(nèi)容是JVM內(nèi)存的使用狀況。

圖27給出了應(yīng)用服務(wù)器的JVM內(nèi)存使用情況。

圖27

從圖27可以看到，在整個(gè)測試過程中，應(yīng)用服務(wù)器的JVM可用內(nèi)存處于相對(duì)充裕的狀況，應(yīng)該說JVM的可用內(nèi)存不是性能瓶頸。但需要注意的是，JVM的內(nèi)存使用呈現(xiàn)出鋸齒狀的波動(dòng)，很可能在代碼中存在產(chǎn)生了過多的臨時(shí)對(duì)象等情況。

其他的場景可以采用類似的方法進(jìn)行分析。分析表明，在測試方案中計(jì)劃的3個(gè)不同場景均存在同系統(tǒng)應(yīng)用典型場景1類似的情況。

針對(duì)場景1、場景2、場景3的頁面分析

通過以上分析，可以基本解了應(yīng)用的性能能力以及影響性能的系統(tǒng)瓶頸。在接下來的分析過程中，我們還希望了解到底哪個(gè)頁面在測試過程中的性能表現(xiàn)最差，表現(xiàn)差的具體原因是什么。

LoadRunner的Analysis應(yīng)用提供了對(duì)頁面進(jìn)行分解（breakdown）分析的輔助功能。下面以“申請(qǐng)單”事務(wù)為例，說明對(duì)頁面進(jìn)行breakdown分析的方法和過程。

在AverageTransactionResponseTime頁面上單擊鼠標(biāo)右鍵，從彈出的菜單中選擇ShowTransactionBreakDownTree命令，此時(shí)Analysis應(yīng)用的左側(cè)會(huì)出現(xiàn)一個(gè)TransactionBreakdown樹型窗口，窗口中顯示所有事務(wù)的樹型列表（見圖28）。

圖28

在該列表上雙擊需要關(guān)注的事務(wù)，則可以打開一個(gè)新的WebBreakdown頁面（見圖29）。

圖29

從圖29可以看到，左側(cè)的Breakdown列表中列出了每個(gè)事務(wù)所包含的頁面請(qǐng)求動(dòng)作，而對(duì)于每個(gè)頁面請(qǐng)求動(dòng)作，用戶可以從DownloadTimeBreakdown、ComponentBreakdown（overtime）、DownloadTimeBreakdown（overtime）和TimetoFirstBufferBreakdown（overtime）4個(gè)不同的角度來對(duì)一個(gè)請(qǐng)求的響應(yīng)進(jìn)行分析。

從分析的角度來說，首先會(huì)關(guān)注每個(gè)請(qǐng)求響應(yīng)所花費(fèi)的時(shí)間，從而找出幾個(gè)最關(guān)鍵的請(qǐng)求（頁面），然后對(duì)其進(jìn)行更詳細(xì)的分析。以本案例來說，考察“申請(qǐng)單”事務(wù)，//server:7001/bill/worklist.jsp?rd=0.5476723708419389請(qǐng)求的響應(yīng)花費(fèi)了最長的響應(yīng)時(shí)間。圖30給出了其響應(yīng)時(shí)間的曲線。

圖30

對(duì)這個(gè)具體的請(qǐng)求，可以首先從ComponentBreakdown（overtime）圖表上看返回頁面的每個(gè)組件所花費(fèi)的具體時(shí)間。具體方法是選中ComponentBreakdown（overtime）單選按鈕。

圖31給出了進(jìn)行ComponentBreakdown（overtime）分解后的曲線圖形。

圖31

結(jié)合圖30和圖31可以很清楚地看到，在性能測試執(zhí)行到45分鐘左右時(shí)，返回頁面的幾個(gè)部件的響應(yīng)時(shí)間都非常長，最為典型的是tool_del.gif、done_click_bg.gif等圖片文件。而從DownloadTimeBreakdown圖形中可以看到（見圖32），這些圖片都非常小（小于1KB），而且這些圖片的平均downloadtime都很短，只在45分鐘附近才出現(xiàn)響應(yīng)時(shí)間急劇增長的情況。

圖32

從這里基本可以斷定，引起這些圖片響應(yīng)時(shí)間過長的問題應(yīng)該在于系統(tǒng)的吞吐量受到了限制，由于我們關(guān)注的部件是靜態(tài)的圖片文件，也就是說，該問題主要是由于應(yīng)用服務(wù)器在該時(shí)刻處理靜態(tài)文件時(shí)的吞吐量受到限制而引起的。

為了進(jìn)一步驗(yàn)證我們的結(jié)論，在TimetoFirstBufferBreakdown（overtime）的圖形中（見圖33）可以看到，在45分鐘左右，請(qǐng)求tool_del.gif文件的所有的時(shí)間消耗都是Servertime。

圖33

結(jié)合整個(gè)測試過程的RunningVusers、HitsperSecond以及Throughput的曲線（見圖34），可以看到，在45分鐘左右，RunningVusers保持在高水平上，但此時(shí)的吞吐量有一個(gè)明顯的變低的趨勢(shì)，說明此時(shí)應(yīng)用服務(wù)器已經(jīng)遇到了瓶頸，而且，該瓶頸表現(xiàn)在請(qǐng)求的靜態(tài)文件的響應(yīng)時(shí)間顯著變長。

根據(jù)這些分析，基本可以得出以下結(jié)論和建議：

1. 在測試進(jìn)行到45分鐘時(shí)，系統(tǒng)遇到了一個(gè)明顯的性能瓶頸，該瓶頸的表現(xiàn)是響應(yīng)時(shí)間明顯變長。
2. 該性能瓶頸的產(chǎn)生主要是由應(yīng)用服務(wù)器引起的，從應(yīng)用服務(wù)器的表現(xiàn)來看，在該時(shí)刻對(duì)靜態(tài)文件的請(qǐng)求響應(yīng)速度非常慢，而且服務(wù)器吞吐量明顯受到了制約。
   
    

   圖34

3. 應(yīng)用服務(wù)器的瓶頸之一是服務(wù)器的CPU，但并發(fā)用戶數(shù)應(yīng)該是一個(gè)引起吞吐量制約的因素。
4. 如果需要進(jìn)一步確定系統(tǒng)的性能瓶頸，建議采用類似RBI的方法，首先純粹通過靜態(tài)文件檢查各種不同的并發(fā)條件下應(yīng)用服務(wù)器的吞吐量限制，然后與場景的測試結(jié)果比較，檢查是否是由于應(yīng)用服務(wù)器本身的吞吐量限制，從而決定進(jìn)一步的調(diào)優(yōu)策略。
5. 如果最終的問題定位在應(yīng)用服務(wù)器對(duì)靜態(tài)文件的吞吐量上，可以考慮采用Apache+Tomcat的架構(gòu)，用Apache處理靜態(tài)頁面文件和圖形文件，用Tomcat處理JSP文件。

最后要說明的是，根據(jù)我們對(duì)測試結(jié)果的分析，性能的主要瓶頸在于應(yīng)用服務(wù)器，因此在本案例中基本沒有對(duì)數(shù)據(jù)庫服務(wù)器的性能指標(biāo)進(jìn)行關(guān)注和分析。

針對(duì)穩(wěn)定性測試場景的性能分析

對(duì)應(yīng)用系統(tǒng)的穩(wěn)定性測試，重點(diǎn)在于通過壓力測試，檢查長時(shí)間運(yùn)行條件下的應(yīng)用系統(tǒng)運(yùn)行狀況，以及各服務(wù)器的資源使用狀況。

測試設(shè)計(jì)中設(shè)計(jì)的運(yùn)行時(shí)間是72小時(shí)，主要的測試關(guān)注點(diǎn)包括：

1. 服務(wù)器內(nèi)存使用狀況。
2. 應(yīng)用服務(wù)器JVM內(nèi)存使用狀況。
3. 持續(xù)測試過程中的系統(tǒng)性能表現(xiàn)（響應(yīng)時(shí)間）。
4. 數(shù)據(jù)庫服務(wù)器的主要性能指標(biāo)。

實(shí)際測試過程中，由于對(duì)場景1～場景3的測試結(jié)果表明，系統(tǒng)根本無法支持預(yù)期的壓力測試的用戶訪問量，因此沒有對(duì)其進(jìn)行穩(wěn)定性測試。

針對(duì)數(shù)據(jù)導(dǎo)入場景的性能分析

數(shù)據(jù)導(dǎo)入場景測試除了關(guān)注系統(tǒng)的響應(yīng)時(shí)間等性能表現(xiàn)外，還特別關(guān)注服務(wù)器的磁盤I/O是否達(dá)到磁盤處理能力的極限。

系統(tǒng)響應(yīng)時(shí)間性能的分析與上面的分析過程一樣，對(duì)磁盤I/O的關(guān)注通過UNIX系統(tǒng)提供的iostat命令獲取相關(guān)數(shù)據(jù)并進(jìn)行分析。

計(jì)算最大磁盤I/O數(shù)的公式在本書的第3章中進(jìn)行了詳細(xì)的討論，在此不再贅述。在本案例中，沒有發(fā)現(xiàn)系統(tǒng)存在服務(wù)器磁盤I/O方面的瓶頸。

四、案例小結(jié)

該案例展示了一個(gè)完整的應(yīng)用LoadRunner對(duì)Web應(yīng)用進(jìn)行性能測試的全過程，它遵循PTGM模型進(jìn)行性能測試，并重點(diǎn)給出應(yīng)用LoadRunner進(jìn)行性能測試需要關(guān)注的重點(diǎn)內(nèi)容，展示了使用LoadRunner進(jìn)行性能測試結(jié)果分析的方法。

該案例系統(tǒng)是一個(gè)具有典型代表性的基于J2EE的Web應(yīng)用系統(tǒng)，采用標(biāo)準(zhǔn)的HTTP協(xié)議，因此主要使用LoadRunner這個(gè)商業(yè)工具作為性能測試工具。本案例非常詳細(xì)地描述了LoadRunner在實(shí)際應(yīng)用中需要注意的一些問題，介紹的一些技巧和技術(shù)都值得讀者仔細(xì)體會(huì)。

本案例還額外討論了性能測試時(shí)驗(yàn)證碼的處理方法，并根據(jù)一次解決實(shí)際問題的方法介紹了session這個(gè)對(duì)Web系統(tǒng)非常重要的概念。在對(duì)驗(yàn)證碼處理方法的討論中，給出了3種可能的解決方案，逐一討論了各種方案的優(yōu)點(diǎn)和缺點(diǎn)，并給出了每種方案的適用場合和使用注意事項(xiàng)。

使用LoadRunner對(duì)性能測試結(jié)果進(jìn)行輔助分析是使用LoadRunner進(jìn)行性能測試時(shí)的重要內(nèi)容，本案例通過有針對(duì)性地重點(diǎn)描述系統(tǒng)測試結(jié)果的分析過程（包括基礎(chǔ)分析和頁面響應(yīng)分析），并結(jié)合性能下降曲線分析方法，演示了對(duì)性能測試結(jié)果的分析過程。本案例描述的分析過程當(dāng)然不是唯一的分析方法和過程，但確實(shí)是具有代表性的分析方法，希望讀者能夠仔細(xì)體會(huì)。

當(dāng)然，就本案例本身來說，并不是針對(duì)被測的Web系統(tǒng)的全部性能測試內(nèi)容（在對(duì)本系統(tǒng)的實(shí)際性能測試中，我們還按照RBI的方法對(duì)其進(jìn)行了吞吐量測試、并發(fā)測試等），而只是為了說明性能測試進(jìn)行了有針對(duì)性的簡化的一個(gè)案例描述，因此，讀者在學(xué)習(xí)體會(huì)本案例的過程中，也應(yīng)該更深入的思考——如果你是這個(gè)性能測試項(xiàng)目的負(fù)責(zé)人，還需要關(guān)注哪些方面？