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