X銀行營銷服務系統性能測試小記續

　　9、 經驗在本次性能測試的過程中，我們遇到一些問題，通過解決這些問題，從中獲得了一些經驗。

　　現總結如下： 問題一在我們對系統進行測試的過程中，某些操作是相關聯的。例如我們測試“查看客戶資產歷史”這個交易的系統響應時間，這時需要先列出客戶的基本信息，選中一個客戶，點擊打開另一個頁面，才能查看到該客戶的資產歷史信息，同時，在測試腳本中需要對所選擇的客戶編號做一個參數化，但由于LoadRunner不提供像WinRunner或QTP一樣識別頁面對象的功能，如果在Vugen中直接抓取頁面上顯示的客戶編號去參數化，實現起來將十分煩瑣?？紤]到在以上那兩步操作中，第一步“列出客戶基本信息”只是輔助的操作，而第二步操作“查看客戶資產歷史”才是我們要測試的功能點，因此我們忽略了這二者之間的關聯性，僅對第二步操作中的客戶編號進行參數化。(只要服務器端對此不加驗證，甚至我們將第一步操作都忽略掉，也是可行的)。結論：LoadRunner的工作原理是根據所選擇的協議組裝成相應的報文在前后臺之間通訊，以此達到模擬實際操作的目的，因此我們只需將要測試的交易或功能點所需要組裝的報文傳送給后臺服務器即可(因為我們關注的只是系統的性能，不是功能)，而不必像功能測試那樣，按部就班地重現每一步操作。

　　問題二在測試過程中，我們發現有一個查詢交易的系統響應速度特別慢，無論是在Controller中使用單個虛擬用戶執行腳本，還是在Vuser中直接運行，情況均是如此，然而當我們用手工進行同樣操作的時候，響應時間卻明顯地小于工具統計出來的時間，也就是說，在LoadRunner中模擬操作的結果與真實操作的結果明顯不一致。經過反復嘗試與觀察，我們才終于找到問題的原因所在：該查詢交易是通過客戶的證件號碼查詢客戶信息，當用戶輸入客戶的證件號碼時，如果沒有選擇證件類型，系統會自動將證件類型設置為默認值“身份證”。按“證件類型+證件號碼”為組合索引查詢客戶信息表，查詢速度極快，而在我們錄制腳本時，忽視了“證件類型”這項輸入，只有“證件號碼”，因此查詢的效率大為降低。解決辦法：只需在測試腳本中，對CertType(“證件類型”)一項賦值為“A”(“身份證”)，此時在LoadRunner中重新運行該腳本，響應速度提高，統計結果與實際完全一致!結論：LoadRunner的工作原理是根據所選擇的協議組裝成相應的報文在前后臺之間通訊，以此達到模擬實際操作的目的，因此我們在測試腳本中組裝發送到服務器端的報文時，注意一定要和實際操作時的發送報文完全一致，這樣才能保證測試的結果與真實情況相吻合。這就要求在測試正式開始執行時，要對測試腳本進行反復的調試，通常的做法是：在Vugen中執行一遍腳本，統計執行某個事務的時間，再用手工實際做一遍同樣的操作，大體上比較一下，確保與實際估算的時間沒有太大出入后，再逐漸增加并發用戶數，正式開始性能測試。

　　問題三在我們的每個測試腳本中的init部分，都錄制了登錄系統的操作，并且對登錄的用戶名進行了參數化，使用各種不同身份的用戶(分行主管、支行主管、客戶經理等)進行相同的操作。在并發測試過程中發現對某些查詢交易測試的結果波動較大，系統響應時間從零點幾秒到幾十秒不等。經檢查后發現原因在于：使用不同身份的用戶登錄系統后，在輸入查詢條件后，點擊查詢按鈕后會將根據該用戶的身份，將其所屬的分行機構號、支行機構號、客戶經理編號等一并提交，因此在腳本中，就必須根據不同的用戶身份，分別將其對應的分支行機構號等也運用參數提交，否則在執行腳本時就會出現查詢不到記錄或查詢速度變慢等各種問題。解決方法有三個：1、修改腳本，使其能夠依據用戶的身份分別傳送相應參數，2、針對不同類型的用戶使用不同的腳本分別測試。3、輸入參數使用統一的用戶類型。在實際中，我們為了簡化腳本的復雜度，節省對腳本編程的時間，采取的是第三種方法。結論：由于LoadRunner的工作原理是根據所選擇的協議組裝成相應的報文在前后臺之間通訊，因此它會跳過在應用程序前臺進行的校驗，所以在腳本回放的時候一定要注意在腳本中提前進行這些校驗或改由人工控制，以保證發送報文的正確性(如操作權限的控制等)。

　　問題四測試多用戶并發登錄系統的時候，從虛擬用戶圖和事務圖上發現，總有一部分用戶在登錄的時候要等待很長時間，用戶登錄的最小時間與最大時間相差非常大。于是我們在讓腳本自動運行的同時，手工再登錄一個用戶，發現無論如何都不會發生等待的情況，多次試驗的結果均是如此，也就是說LoadRunner測試的結果與實際結果再次發生了偏差!經過反復的調試，以及與程序開發人員溝通，我們終于發現問題的原因所在：在用戶登錄系統的時候，系統會自動記錄登錄用戶的信息，并產生一個登錄ID，以此ID做為主鍵，向數據庫插入記錄。因此當大量用戶在極短的時間內同時登錄時，就有可能出現生成相同的登錄ID的情況，此時便會造成數據庫中的主鍵沖突，導致用戶等待很長時間或登錄失敗。而我們手工測試時卻無法做到在很短的時間內同時登錄，因此很難用手工重現此種情況。通過LoadRunner的模擬表現出來的狀況，正是我們測試出程序存在的性能問題，并非與實際結果的偏差。還有一個例子，在第二輪性能測試中，同樣發生了類似的情況。在本系統中，如果同一個用戶登錄后，未正常退出超過5次，系統將會把該用戶鎖住，使其無法再次登錄，而我們用于參數化的用戶名個數有限，因此當腳本使用大量用戶同時登錄時，很容易造成同樣的用戶登錄系統而未簽退的情況發生(腳本正在執行，還未能退出)，此時將會造成許多用戶操作的失敗。結論：使用LoadRunner可以模擬出大量用戶同時對系統操作的情況，而這些情況通過手工往往是很難重現出來的。例如大量用戶在同時對系統做某些操作時，很容易造成數據庫的死鎖、鎖等待、主鍵沖突、數據混亂等等問題，因此在做性能測試的同時，也常?？梢赃B帶測試出系統的一些隱蔽的“缺陷”。在本次性能測試中，這種例子是很多的。對待此類“缺陷”，應具體情況具體分析。有些確實是程序的BUG，需要修正，而有些可能只是很極端的情況，只有在做壓力測試時才有可能發生，可不必深究。

　　問題五此問題發生在第二輪測試(即回歸測試)中。在第一輪測試中發現的性能問題，經程序員修正后，我們對系統進行了第二輪性能測試，以驗證其性能改進的效果。在前一輪測試中，我們發現通過選擇客戶級別為“未評級”時，查詢的速度極慢，經過改進后，速度應有較大提高。然而在回歸測試中，卻依然很慢。經過對測試腳本和程序的仔細檢查，才發現原來在程序中已將“未評級”這個選項去除，而我們的測試腳本的參數文件中仍然保留有該選項，因此測試的結果與前次沒有區別。在參數文件中將該選項去掉后，測試結果正常，查詢效率有所提高。

原文轉自：http://www.kjueaiud.com