性能測試人員面試經(jīng)典技術(shù)問題.doc

1.請問什么是性能測試、負(fù)載測試、壓力測試？性能測試：對一個軟件系統(tǒng)而言，包括執(zhí)行效率、資源占用、系統(tǒng)穩(wěn)定性、安全性兼容性、可擴(kuò)展性等。負(fù)載測試：通過逐步加壓的方式來確定系統(tǒng)的處理能力，確定系統(tǒng)能承受的各項(xiàng)閥值。壓力測試：逐步增加負(fù)載，使系統(tǒng)某些資源達(dá)到飽和甚至失效的測試。2.請分別針對性能測試、負(fù)載測試和壓力測試試舉一個簡單的例子？性能測試?yán)樱汗鹃_發(fā)了一個小型項(xiàng)目管理系統(tǒng)，上線前需要做負(fù)載、壓力、大數(shù)據(jù)量、強(qiáng)度測試等。負(fù)載測試：逐步加壓，從而得到“響應(yīng)時間不超過10秒”，“服務(wù)器平均CPU利用率低于85%”等指標(biāo)閥值。壓力測試：逐步加壓，從而使“響應(yīng)時間超過10秒”，“服務(wù)器平均CPU利用率高于90%”等指標(biāo)來確定系統(tǒng)能承受的最大負(fù)載量。3.請例舉出常用的性能測試工具，并指出這些工具的優(yōu)缺點(diǎn)？LoadRunner，錄制腳本快捷操作簡便，需要一定的學(xué)習(xí)時間，有采購成本。4.請問您是如何得到性能測試需求？怎樣針對需求設(shè)計、分析是否達(dá)到需求？在查看需求文檔，從中提取性能測試需求，與用戶交流，了解實(shí)際使用情況。結(jié)合業(yè)務(wù)信息設(shè)計操作場景總結(jié)出需測試的性能關(guān)鍵指標(biāo)。執(zhí)行用例后根據(jù)提取關(guān)鍵性能指標(biāo)來分析是否滿足性能需求。5.什么時候可以開始執(zhí)行性能測試？在產(chǎn)品相對比較穩(wěn)定，功能測試結(jié)束后。靈活性比較強(qiáng)。6.什么是集合點(diǎn)？設(shè)置集合點(diǎn)有什么意義？LoadRunner中設(shè)置集合點(diǎn)的函數(shù)是哪個？集合點(diǎn)可以控制各個Vuser以便在同一時刻執(zhí)行任務(wù)。借助集合點(diǎn)，可以再LoadRunner中實(shí)現(xiàn)真正意義上的并發(fā)。lr_rendezvous()7.性能測試時，是不是必須進(jìn)行參數(shù)化？為什么要創(chuàng)建參數(shù)？LoadRunner中如何創(chuàng)建參數(shù)？8是。模擬用戶真實(shí)的業(yè)務(wù)操作。創(chuàng)建參數(shù)列表，用參數(shù)替換固定的文本。8.您了解關(guān)聯(lián)嗎？如何找出哪里需要關(guān)聯(lián)？請給一些您所在項(xiàng)目的實(shí)例。了解。使用LoadRunner自動關(guān)聯(lián)功能。手動關(guān)聯(lián)：錄制兩份相同操作步驟的腳本，找出不同的部分進(jìn)行判斷。一個項(xiàng)目管理系統(tǒng)，每次登錄后服務(wù)器都自動分配一個sessionID以便之后每次表單提交后驗(yàn)證。9.您如何調(diào)試LoadRunner腳本？設(shè)置斷點(diǎn)、增加log。10.在LoadRunner中如何編寫自定義函數(shù)？請給出一個您在以前項(xiàng)目中編寫的函數(shù)。11.請問您是如何理解LoadRunner中集合點(diǎn)、事務(wù)以及檢查點(diǎn)等概念？集合點(diǎn)：可以控制各個Vuser以便在同一時刻執(zhí)行任務(wù)，可實(shí)現(xiàn)真正意義上的并發(fā)。事務(wù)：事務(wù)是用來度量服務(wù)器響應(yīng)時間的操作集。檢查點(diǎn)：在回放腳本期間搜索特定內(nèi)容，從而驗(yàn)證服務(wù)器響應(yīng)內(nèi)容的正確性。12.如何應(yīng)用LoadRunner進(jìn)行性能測試？使用虛擬用戶生成器創(chuàng)建腳本，使用控制器設(shè)定場景、運(yùn)行腳本，使用分析器分析運(yùn)行后得到的數(shù)據(jù)。13.LoadRunner中思考時間有什么作用？用戶執(zhí)行兩個連續(xù)操作期間等待的時間。模擬用戶真實(shí)的使用情況。14.LoadRunner中如何實(shí)現(xiàn)多用戶并發(fā)操作，需要進(jìn)行哪些設(shè)置？設(shè)置集合點(diǎn)來實(shí)現(xiàn)，在腳本中加入lr_rendezvous()，然后可以在控制器中設(shè)定集結(jié)百分比。15.LoadRunner中有基于目標(biāo)和手動兩種場景設(shè)計方式，他們分別適用于什么情況？手動場景可按照要求來配置場景，能夠更加精確的滿足測試需要。目標(biāo)場景要先制定希望實(shí)現(xiàn)的測試目標(biāo)，然后由控制器驚醒自動測試評估。16.LoadRunner中有幾種并發(fā)執(zhí)行策略，它們的含義是什么？三種。1.當(dāng)所有虛擬用戶中的x%到達(dá)集合點(diǎn)時釋放。2.當(dāng)所有正在運(yùn)行的虛擬用戶中的x%到達(dá)集合點(diǎn)時釋放。3.當(dāng)x個虛擬用戶到達(dá)集合點(diǎn)時釋放。17.有5臺配置為處理器：Intel Pentium 4 1.6G，內(nèi)存容量 512MB，硬盤容量 40GB的機(jī)器，如何較好的利用這些機(jī)器完成一次并發(fā)用戶數(shù)為1000人的性能測試工作？1臺做應(yīng)用服務(wù)器，1臺做數(shù)據(jù)庫服務(wù)器，1臺運(yùn)行控制器并承擔(dān)一部分負(fù)載生成任務(wù)，2臺負(fù)載生成器。18.平時大家在注冊郵箱等關(guān)聯(lián)操作時，經(jīng)常會遇到需要輸入驗(yàn)證碼的情況，請問，如果我們公司也開發(fā)了一套帶驗(yàn)證碼的應(yīng)用軟件，需要警醒性能測試，您會如何處理？留一個后門，我們設(shè)定一個所謂的“萬能驗(yàn)證碼”，只要用戶輸入這個“萬能驗(yàn)證碼”，系統(tǒng)就驗(yàn)證通過。測試完成后補(bǔ)上后門。LR性能測試結(jié)果樣例分析 測試結(jié)果分析 LoadRunner性能測試結(jié)果分析是個復(fù)雜的過程，通?？梢詮慕Y(jié)果摘要、并發(fā)數(shù)、平均事務(wù)響應(yīng)時間、每秒點(diǎn)擊數(shù)、業(yè)務(wù)成功率、系統(tǒng)資源、網(wǎng)頁細(xì)分圖、Web服務(wù)器資源、數(shù)據(jù)庫服務(wù)器資源等幾個方面分析，如圖1- 1所示。性能測試結(jié)果分析的一個重要的原則是以性能測試的需求指標(biāo)為導(dǎo)向。我們回顧一下本次性能測試的目的，正如所列的指標(biāo)，本次測試的要求是驗(yàn)證在30分鐘內(nèi)完成2000次用戶登錄系統(tǒng)，然后進(jìn)行考勤業(yè)務(wù)，最后退出，在業(yè)務(wù)操作過程中頁面的響應(yīng)時間不超過3秒，并且服務(wù)器的CPU使用率、內(nèi)存使用率分別不超過75%、70%，那么按照所示的流程，我們開始分析，看看本次測試是否達(dá)到了預(yù)期的性能指標(biāo)，其中又有哪些性能隱患，該如何解決。圖1- 1性能測試結(jié)果分析流程圖 結(jié)果摘要 LoadRunner進(jìn)行場景測試結(jié)果收集后，首先顯示的該結(jié)果的一個摘要信息，如圖1- 2所示。概要中列出了場景執(zhí)行情況、“Statistics Summary（統(tǒng)計信息摘要）”、“Transaction Summary（事務(wù)摘要）”以及“HTTP Responses Summary（HTTP響應(yīng)摘要）”等。以簡要的信息列出本次測試結(jié)果。圖1- 2性能測試結(jié)果摘要圖場景執(zhí)行情況該部分給出了本次測試場景的名稱、結(jié)果存放路徑及場景的持續(xù)時間，如圖5- 3所示。從該圖我們知道，本次測試從15:58:40開始，到16:29:42結(jié)束，共歷時31分2秒。與我們場景執(zhí)行計劃中設(shè)計的時間基本吻合。圖1- 3場景執(zhí)行情況描述圖Statistics Summary（統(tǒng)計信息摘要）該部分給出了場景執(zhí)行結(jié)束后并發(fā)數(shù)、總吞吐量、平均每秒吞吐量、總請求數(shù)、平均每秒請求數(shù)的統(tǒng)計值，如圖5- 4所示。從該圖我們得知，本次測試運(yùn)行的最大并發(fā)數(shù)為7，總吞吐量為842,037,409字節(jié)，平均每秒的吞吐量為451,979字節(jié)，總的請求數(shù)為211,974，平均每秒的請求為113.781，對于吞吐量，單位時間內(nèi)吞吐量越大，說明服務(wù)器的處理能越好，而請求數(shù)僅表示客戶端向服務(wù)器發(fā)出的請求數(shù)，與吞吐量一般是成正比關(guān)系。圖1- 4統(tǒng)計信息摘要圖Transaction Summary（事務(wù)摘要）該部分給出了場景執(zhí)行結(jié)束后相關(guān)Action的平均響應(yīng)時間、通過率等情況，如圖1- 5所示。從該圖我們得到每個Action的平均響應(yīng)時間與業(yè)務(wù)成功率。注意：因?yàn)樵趫鼍暗摹癛un-time Settings”的“Miscellaneous”選項(xiàng)中將每一個Action當(dāng)成了一個事務(wù)執(zhí)行，故這里的事務(wù)其實(shí)就是腳本中的Action。圖1- 5事務(wù)摘要圖HTTP Responses Summary（HTTP響應(yīng)摘要）該部分顯示在場景執(zhí)行過程中，每次HTTP請求發(fā)出去的狀態(tài)，是成功還是失敗，都在這里體現(xiàn)，如圖5- 6所示。從圖中可以看到，在本次測試過程中LoadRunner共模擬發(fā)出了211974次請求（與“統(tǒng)計信息摘要”中的“Total Hits”一致），其中“HTTP 200”的是209811次，而“HTTP 404”則有2163，說明在本次過程中，經(jīng)過發(fā)出的請求大部分都能正確響應(yīng)了，但還是有部分失敗了，但未影響測試結(jié)果，“HTTP 200”表示請求被正確響應(yīng)，而“HTTP 404”表示文件或者目錄未能找到。有朋友可能會問，這里出現(xiàn)了404的錯誤，為什么結(jié)果還都通過了。出現(xiàn)這樣問題的原因是腳本有些頁面的請求內(nèi)容并非關(guān)鍵點(diǎn)，比如可能請求先前的cookie信息，如果沒有就重新獲取，所以不會影響最終的測試結(jié)果。圖1- 6 HTTP響應(yīng)摘要常用的HTTP狀態(tài)代碼如下：400 無法解析此請求。401.1 未經(jīng)授權(quán)：訪問由于憑據(jù)無效被拒絕。401.2 未經(jīng)授權(quán): 訪問由于服務(wù)器配置傾向使用替代身份驗(yàn)證方法而被拒絕。401.3 未經(jīng)授權(quán)：訪問由于 ACL 對所請求資源的設(shè)置被拒絕。401.4 未經(jīng)授權(quán)：Web 服務(wù)器上安裝的篩選器授權(quán)失敗。401.5 未經(jīng)授權(quán)：ISAPI/CGI 應(yīng)用程序授權(quán)失敗。401.7 未經(jīng)授權(quán)：由于 Web 服務(wù)器上的 URL 授權(quán)策略而拒絕訪問。403 禁止訪問：訪問被拒絕。403.1 禁止訪問：執(zhí)行訪問被拒絕。403.2 禁止訪問：讀取訪問被拒絕。403.3 禁止訪問：寫入訪問被拒絕。403.4 禁止訪問：需要使用 SSL 查看該資源。403.5 禁止訪問：需要使用 SSL 128 查看該資源。403.6 禁止訪問：客戶端的 IP 地址被拒絕。403.7 禁止訪問：需要 SSL 客戶端證書。403.8 禁止訪問：客戶端的 DNS 名稱被拒絕。403.9 禁止訪問：太多客戶端試圖連接到 Web 服務(wù)器。403.10 禁止訪問：Web 服務(wù)器配置為拒絕執(zhí)行訪問。403.11 禁止訪問：密碼已更改。403.12 禁止訪問：服務(wù)器證書映射器拒絕了客戶端證書訪問。403.13 禁止訪問：客戶端證書已在 Web 服務(wù)器上吊銷。403.14 禁止訪問：在 Web 服務(wù)器上已拒絕目錄列表。403.15 禁止訪問：Web 服務(wù)器已超過客戶端訪問許可證限制。403.16 禁止訪問：客戶端證書格式錯誤或未被 Web 服務(wù)器信任。403.17 禁止訪問：客戶端證書已經(jīng)到期或者尚未生效。403.18 禁止訪問：無法在當(dāng)前應(yīng)用程序池中執(zhí)行請求的 URL。403.19 禁止訪問：無法在該應(yīng)用程序池中為客戶端執(zhí)行 CGI。403.20 禁止訪問：Passport 登錄失敗。404 找不到文件或目錄。404.1 文件或目錄未找到：網(wǎng)站無法在所請求的端口訪問。需要注意的是404.1錯誤只會出現(xiàn)在具有多個IP地址的計算機(jī)上。如果在特定IP地址/端口組合上收到客戶端請求，而且沒有將IP地址配置為在該特定的端口上偵聽，則IIS返回 404.1 HTTP錯誤。例如，如果一臺計算機(jī)有兩個IP地址，而只將其中一個IP地址配置為在端口80上偵聽，則另一個IP地址從端口80收到的任何請求都將導(dǎo)致IIS返回404.1錯誤。只應(yīng)在此服務(wù)級別設(shè)置該錯誤，因?yàn)橹挥挟?dāng)服務(wù)器上使用多個IP地址時才會將它返回給客戶端。404.2 文件或目錄無法找到：鎖定策略禁止該請求。404.3 文件或目錄無法找到：MIME 映射策略禁止該請求。405 用于訪問該頁的 HTTP 動作未被許可。406 客戶端瀏覽器不接受所請求頁面的 MIME 類型。407 Web 服務(wù)器需要初始的代理驗(yàn)證。410 文件已刪除。412 客戶端設(shè)置的前提條件在 Web 服務(wù)器上評估時失敗。414 請求 URL 太大，因此在 Web 服務(wù)器上不接受該 URL。500 服務(wù)器內(nèi)部錯誤。500.11 服務(wù)器錯誤：Web 服務(wù)器上的應(yīng)用程序正在關(guān)閉。500.12 服務(wù)器錯誤：Web 服務(wù)器上的應(yīng)用程序正在重新啟動。500.13 服務(wù)器錯誤：Web 服務(wù)器太忙。500.14 服務(wù)器錯誤：服務(wù)器上的無效應(yīng)用程序配置。500.15 服務(wù)器錯誤：不允許直接請求 GLOBAL.ASA。500.16 服務(wù)器錯誤：UNC 授權(quán)憑據(jù)不正確。500.17 服務(wù)器錯誤：URL 授權(quán)存儲無法找到。500.18 服務(wù)器錯誤：URL 授權(quán)存儲無法打開。500.19 服務(wù)器錯誤：該文件的數(shù)據(jù)在配置數(shù)據(jù)庫中配置不正確。500.20 服務(wù)器錯誤：URL 授權(quán)域無法找到。500 100 內(nèi)部服務(wù)器錯誤：ASP 錯誤。501 標(biāo)題值指定的配置沒有執(zhí)行。502 Web 服務(wù)器作為網(wǎng)關(guān)或代理服務(wù)器時收到無效的響應(yīng)。 并發(fā)數(shù)分析 “Running Vusers（運(yùn)行的并發(fā)數(shù)）”顯示了在場景執(zhí)行過程中并發(fā)數(shù)的執(zhí)行情況。它們顯示Vuser的狀態(tài)、完成腳本的Vuser的數(shù)量以及集合統(tǒng)計信息，將這些圖與事務(wù)圖結(jié)合使用可以確定Vuser的數(shù)量對事務(wù)響應(yīng)時間產(chǎn)生的影響。圖1- 7顯示了在OA系統(tǒng)考勤業(yè)務(wù)性能測試過程中Vusers運(yùn)行情況，從圖中我們可以看到，Vusers的運(yùn)行趨勢與我們場景執(zhí)行計劃中的設(shè)置是一樣，表明在場景執(zhí)行過程中，Vusers是按照我們預(yù)期的設(shè)置運(yùn)行的，沒有Vuser出現(xiàn)運(yùn)行錯誤，這樣從另一個側(cè)面說明我們的參數(shù)化設(shè)置是正確的，因?yàn)槭褂梦ㄒ粩?shù)進(jìn)行參數(shù)化設(shè)置，如果設(shè)置不正確，將會導(dǎo)致Vuser運(yùn)行錯誤。在腳本中我們加入了這樣一段代碼：if (atoi(lr_eval_string(num) 0) lr_output_message(登錄成功，繼續(xù)執(zhí)行.); else lr_error_message(登錄失敗，退出測試); return -1; 上述代碼的意思是說，如果登錄失敗了，就退出腳本的迭代，那么什么原因可能會導(dǎo)致登錄失敗呢？就是我們前面參數(shù)化的設(shè)置，一旦Vuser分配不到正確的登錄賬號，就可能導(dǎo)致登錄失敗，從而引起Vuser停止運(yùn)行。所以，從圖5- 7的表現(xiàn)，可以認(rèn)為參數(shù)化是沒有問題的。圖1- 7運(yùn)行的并發(fā)數(shù)圖測試腳本中我們還使用了集合點(diǎn)，那么這里還可以看看集合點(diǎn)在場景執(zhí)行過程中的表現(xiàn)，點(diǎn)擊左邊的“New Graph”，出現(xiàn)圖5- 8，展開“Vusers”前的加號，雙擊“Rendezvous”，出現(xiàn)集合點(diǎn)的圖形后，點(diǎn)擊【Close】，關(guān)閉添加新圖界面。圖1- 8添加集合點(diǎn)統(tǒng)計圖集合點(diǎn)的圖形如圖1- 9所示，從圖中可以看到，所有用戶到達(dá)集合點(diǎn)后，立刻就釋放了。與之前設(shè)定的集合點(diǎn)策略設(shè)置“所有運(yùn)行用戶到達(dá)后釋放“是一致的。假設(shè)這樣的一種情況，Running的Vusers有10個，集合點(diǎn)策略設(shè)置是“所有運(yùn)行用戶到達(dá)后釋放”，而集合點(diǎn)圖形顯示的最大釋放Vusers是7個，那么就表示有些Vuser超時了，引起超時的原因可能是Vuser得到的響應(yīng)超時了，可以結(jié)合平均事務(wù)響應(yīng)時間再詳細(xì)分析原因。圖1- 9集合點(diǎn)狀態(tài)圖我們本次測試Running Vusers與集合點(diǎn)是一致，說明整個場景執(zhí)行過程中，并發(fā)數(shù)用戶的執(zhí)行正確，OA系統(tǒng)測試服務(wù)器能夠應(yīng)付7個并發(fā)用戶的業(yè)務(wù)操作。 響應(yīng)時間 在性能測試要求中我們知道，有一項(xiàng)指標(biāo)是要求登錄、考勤業(yè)務(wù)操作的頁面響應(yīng)時間不超過3秒，那么本次測試是否達(dá)到了這個要求呢？我們先來看“Average Transaction Response Time（平均事務(wù)響應(yīng)時間圖）”（圖1- 10），這張圖是平均事務(wù)響應(yīng)時間與結(jié)果摘要中的“Transaction Summary”合成的。圖1- 10平均事務(wù)響應(yīng)時間圖從圖形下部我們可以看到，登錄部分對應(yīng)的Action是“submit_login”，考勤業(yè)務(wù)提交對應(yīng)的Action是“submit_sign”，他們的“Average Time（平均響應(yīng)時間為）”分別是4.425秒與0.848秒，從這兩個數(shù)值來看，考勤業(yè)務(wù)的事務(wù)響應(yīng)時間0.848秒小于預(yù)期的3秒，達(dá)到了要求，而登錄是4.425秒，大于預(yù)期的3秒，不符合要求。這樣的結(jié)果是不正確的，因?yàn)樵诮y(tǒng)計的登錄業(yè)務(wù)的時候，我們沒有去除思考時間，所以，登錄功能的實(shí)際事務(wù)時間應(yīng)該是4.425秒-3秒=1.425秒，小于預(yù)期的3秒，故登錄業(yè)務(wù)的事務(wù)響應(yīng)時間也達(dá)到了我們的要求。在平時的性能測試活動中，統(tǒng)計結(jié)果的時候需要去掉思考時間，加上思考時間是為了真實(shí)的模擬用戶環(huán)境，統(tǒng)計結(jié)果中除去思考時間是為了更真實(shí)的反映服務(wù)器的處理能力，兩者并不矛盾?？赐炅恕癆verage Time”，我們再看“90 Percent Time”，這個時間從某種程度來說，更準(zhǔn)確衡量了測試過程中各個事務(wù)的真實(shí)情況，表示90%的事務(wù)，服務(wù)器的響應(yīng)都維持在某個值附近，“Average Time”值對于平均事務(wù)響應(yīng)時間變動趨勢很大的情況統(tǒng)計就不準(zhǔn)確了，比如有三個時間：1秒、5秒、12秒，則平均時間為6秒，而另外一種情況：5秒、6秒、7秒，平均時間也為6秒，顯然第二種比第一種要穩(wěn)定多了。所以，我們在查看平均事務(wù)響應(yīng)時間的時候，先看整體曲線走勢，如果整體趨勢比較平滑，沒有忽上忽下的波動情況，取“Average Time”與“90 Percent Time”都可以，如果整體趨勢毫無規(guī)律，波動非常大，我們就不用“Average Time”而使用“90 Percent Time”可能更真實(shí)些。從圖5- 10可以看出，所有Action平均事務(wù)響應(yīng)時間的趨勢都非常平滑，所以使用“Average Time”與“90 Percent Time”差別不是很大，用哪個都可以。這里是使用最常用的統(tǒng)計方法“90 Percent Time”。登錄業(yè)務(wù)的“90 Percent Time”是5.298秒-3秒（思考時間）=2.298秒，考勤業(yè)務(wù)的“90 Percent Time”是1.469秒，沒有思考時間，那么就是實(shí)打?qū)嵉睦病８鶕?jù)上面的計算，本次測試結(jié)果記錄如表1所示。測試項(xiàng)目標(biāo)值實(shí)際值是否通過登錄業(yè)務(wù)響應(yīng)時間=3秒2.298秒Y考勤業(yè)務(wù)響應(yīng)時間=3秒1.469秒Y登錄業(yè)務(wù)成功率100%考勤業(yè)務(wù)成功率100%登錄業(yè)務(wù)總數(shù)30分鐘完成2000考勤業(yè)務(wù)總數(shù)30分鐘完成2000CPU使用率75%內(nèi)存使用率70%表1測試結(jié)果對照表一 每秒點(diǎn)擊數(shù) “Hits per Second（每秒點(diǎn)擊數(shù)）”反映了客戶端每秒鐘向服務(wù)器端提交的請求數(shù)量，如果客戶端發(fā)出的請求數(shù)量越多，與之相對的“Average Throughput (bytes/second)”也應(yīng)該越大，并且發(fā)出的請求越多會對平均事務(wù)響應(yīng)時間造成影響，所以在測試過程中往往將這三者結(jié)合起來分析。圖1- 11顯示的是“Hits per Second”與“Average Throughput(bytes/second)”的復(fù)合圖，從圖中可以看出，兩種圖形的曲線都正常并且基本一致，說明服務(wù)器能及時的接受客戶端的請求，并能夠返回結(jié)果。如果“Hits per Second”正常，而“Average Throughput (bytes/second)”不正常，則表示服務(wù)器雖然能夠接受服務(wù)器的請求，但返回結(jié)果較慢，可能是程序處理緩慢。如果“Hits per Second”不正常，則說明客戶端存在問題，那種問題一般是網(wǎng)絡(luò)引起的，或者錄制的腳本有問題，未能正確的模擬用戶的行為。具體問題具體分析，這里僅給出一些建議。圖1- 11每秒點(diǎn)擊數(shù)與每秒吞吐量復(fù)合圖對于本次測試來說，“Hits per Second”與“Average Throughput (bytes/second)”都是正常的，而且整體表現(xiàn)還是不錯的。一般情況下，這兩種指標(biāo)用于性能調(diào)優(yōu)，比如給定了幾個條件，去檢測另外一個條件，用這兩個指標(biāo)衡量，往往起到很好的效果。比如要比較某兩種硬件平臺的優(yōu)劣，就可以使用相同的配置方法部署軟件系統(tǒng)，然后使用相同的腳本、場景設(shè)計、統(tǒng)計方法去分析，最終得出一個較優(yōu)的配置。 業(yè)務(wù)成功率 “業(yè)務(wù)成功率”這個指標(biāo)在很多系統(tǒng)中都提及到，比如電信的、金融的、企業(yè)資源管理的等等。舉個例子，我們樓下的建行，假如每天的業(yè)務(wù)類別是這樣的：20個開戶，5個銷戶，300個存款，500取款，100個匯款等，那么在做他們的營業(yè)系統(tǒng)測試時就需要考慮業(yè)務(wù)成功率了，一般不得低于98%。具體的業(yè)務(wù)成功率是什么意思呢？排除那些復(fù)雜的業(yè)務(wù)，比如異步處理的業(yè)務(wù)（移動的套卡開通就是異步的），業(yè)務(wù)成功率就是事務(wù)成功率，用戶一般把一個Aciton當(dāng)做一筆業(yè)務(wù)，在LoadRunner場景執(zhí)行中一筆交易稱為一個事務(wù)。所以，說業(yè)務(wù)成功率其實(shí)就是事務(wù)成功率、通過率的意思。在“Transaction Summary”中我們可以很明確的看到每個事務(wù)的執(zhí)行狀態(tài)，如圖1- 12所示。圖1- 12事務(wù)狀態(tài)統(tǒng)計圖從圖中可以看出，所有的Aciton都是綠色的，即表示為Passed，同時除了vuser_init與vuser_end兩個事務(wù)，其他的事務(wù)通過數(shù)為2163，也就表明在30分鐘的時間里，共完成了2163次登錄考勤業(yè)務(wù)操作。那么根據(jù)這些可以判斷本次測試登錄業(yè)務(wù)與考勤業(yè)務(wù)的成功率是100%，再次更新測試結(jié)果記錄表如表2所示。測試項(xiàng)目標(biāo)值實(shí)際值是否通過登錄業(yè)務(wù)響應(yīng)時間=3秒2.298秒Y考勤業(yè)務(wù)響應(yīng)時間=3秒1.469秒Y登錄業(yè)務(wù)成功率100%100%Y考勤業(yè)務(wù)成功率100%100%Y登錄業(yè)務(wù)總數(shù)30分鐘完成20002163Y考勤業(yè)務(wù)總數(shù)30分鐘完成20002163YCPU使用率75%內(nèi)存使用率70%表2測試結(jié)果對照表二 系統(tǒng)資源 系統(tǒng)資源圖顯示了在場景執(zhí)行過程中被監(jiān)控的機(jī)器系統(tǒng)資源使用情況，一般情況下監(jiān)控機(jī)器的CPU、內(nèi)存、網(wǎng)絡(luò)、磁盤等各個方面。本次測試監(jiān)控的是測試服務(wù)器的CPU使用率與內(nèi)存使用率，以及處理器隊(duì)列長度，具體的數(shù)據(jù)如圖1- 13所示。圖1- 13測試服務(wù)器系統(tǒng)資源監(jiān)控結(jié)果圖從圖中可以看出，CPU使用率、可用物理內(nèi)存、CPU的隊(duì)列長度三個指標(biāo)的曲線逗較為平滑，三者的平均值分別為：53.582%、83.456M、8.45，而測試服務(wù)器總的物理內(nèi)存為384M，那么內(nèi)存使用率為（384-83.456）/384=78.26%，根據(jù)本次性能測試要求的：CPU使用率不超過75%，物理內(nèi)存使用率不超過70%這兩點(diǎn)來看，內(nèi)存的使用率78.26%大于預(yù)期的70%，故內(nèi)存使用率不達(dá)標(biāo)。根據(jù)Windwos資源性能指標(biāo)的解釋，一般情況下，如果“Processor Queue Length（處理器隊(duì)列長度）”一直超過二，則可能表示處理器堵塞，我們這里監(jiān)控出來的數(shù)值是8.45，而且總體上保持平衡，那么由此推斷，測試服務(wù)器的CPU也可能是個瓶頸