1、 背景 本次效能測試的系統是X銀行營銷服務系統總行版，該系統使用的資料庫伺服器、應用伺服器均佈署在總行機房，各地分行通過 WEB 方式登入訪問本系統。系統上線後的總使用者數（包括各分行、支行主管，客戶經理等）在 5000 左右。 該系統採用 DB2 資料庫、 WebLogic 應用伺服器。 本次效能測試進入的條件是系統的程式碼已經基本完成並經過功能測試。 2、 測試計劃 在確定了本次效能測試的要點後，我們初步擬定一份效能測試計劃，提交給客戶，並獲得了客戶的認可。在本文中不列出專案測試計劃中的所有內容，僅就主要問題進行說明。 測試範圍：在真實業務區域網測試環境下，對系統實施併發效能測試的同時，監控 Web 伺服器和資料庫伺服器的系統資源，以及資料庫資源的使用情況。 測試內容：併發效能測試、系統資源監控。 測試方法與工具：採用自動測試與人工測試相結合的測試方法，測試工具使用 LoadRunner 。 測試資源：測試環境及測試資料準備。 3、 測試用例 確定了測試計劃，我們針對該系統的特點，從中挑選出三個有代表性的功能點，作為本次效能測試的用例。我們認為作為銀行的營銷服務系統，最常使用且對於系統的整體效能有著較大影響的是“客戶資訊查詢”和“客戶對賬單查詢”兩個模組。因此，我們設計了三個單交易效能測試用例，分別是：“使用者簽到 / 簽退”、“客戶資訊查詢”、“客戶對賬單查詢”。然而客戶卻對此提出異議，他們認為我們設計的測試用例數量太少，要求我們的測試用例應包含更多的功能模組。經過會議討論，最終我們根據客戶給出的一份效能測試大綱，針對其中提出的測試內容、測試策略，以及測試目標，將單交易測試用例增加到十四個。 測試用例採用以下格式：

案例名稱

併發 使用者數

資料量

操作步驟

備註

要求清晰地描述出詳細的操作步驟。 4、 測試資料 針對以上設計的測試用例，需要準備大量的業務資料。本次效能測試的環境即系統上線後真實執行的環境，所有的業務資料均來自興業銀行的真實核心系統（通過 ETL 轉換），資料量已經能滿足測試的需要。 由於測試用例中要求執行併發操作的時候使用不同身份的使用者登入系統，因此在測試開始前需要準備一批具有不同身份的使用者名稱（包括各分支行的主管以及客戶經理），並且要有相應的操作許可權。 對於“積分轉移”、“積分兌換”、“禮品兌換”等等交易，則需要提供一批卡上有足夠積分的客戶理財卡號。 以上測試資料由興業銀行負責提供，在效能測試執行之前提供給我們。 5、 測試指令碼 使用效能測試工具 LoadRunner 錄製並除錯測試指令碼，對相關的輸入項進行引數化。 6、 測試實施 在 LoadRunner 中執行測試指令碼，實施效能測試。對於每個單交易測試指令碼各執行一輪測試，並按一定的使用者比例設計出一個混合交易場景，令其自動持續執行五小時左右，觀察系統的效能表現。每次執行的結果檔案均儲存下來，待測試完成後連同效能測試報告一併交付客戶確認。在此過程中，需要監視相關的系統資源使用情況，包括：應用伺服器和資料庫伺服器的所有系統資源指標，所有資料庫資源指標。 7、 測試結果 經過本次效能測試，發現了系統五個主要的效能問題。我們與程式開發人員一同分析問題產生的原因，並給出改進建議，一起記錄到測試報告中。其中的一個問題在效能測試報告提交客戶之前已經過優化，得到顯著改進。 8、 測試結論 測試結果顯示，系統性能能滿足測試目標， 交易併發數達到或超過30個，批量交易（查詢記錄50條以上的交易）併發數也能達到或超過10個，交易平均響應時間在2－12秒內，90％平均響應時間在2－15秒間完成。 混合交易案例持續執行 5 小時，執行結果正常，系統沒有報任何錯誤，系統穩定， 可用率應達到100％ 。 另外如在ETL批處理期間執行 營銷服務系統 ，系統性能明顯下降，建議ETL批處理在夜間處理，避免影響 系統的正常執行 。 9、 經驗 在本次效能測試的過程中，我們遇到一些問題，通過解決這些問題，從中獲得了一些經驗。現總結如下： l問題一 在我們對系統進行測試的過程中，某些操作是相關聯的。例如我們測試“檢視客戶資產歷史” 這個交易的系統響應時間，這時需要先列出客戶的基本資訊，選中一個客戶，點選開啟另一個頁面，才能檢視到該客戶的資產歷史資訊，同時，在測試指令碼中需要對所選擇的客戶編號做一個引數化，但由於 LoadRunner 不提供像 WinRunner 或 QTP 一樣識別頁面物件的功能，如果在 Vugen 中直接抓取頁面上顯示的客戶編號去引數化，實現起來將十分煩瑣。考慮到在以上那兩步操作中，第一步“列出客戶基本資訊”只是輔助的操作，而第二步操作“檢視客戶資產歷史”才是我們要測試的功能點，因此我們忽略了這二者之間的關聯性，僅對第二步操作中的客戶編號進行引數化。（只要伺服器端對此不加驗證，甚至我們將第一步操作都忽略掉，也是可行的）。 結論： LoadRunner 的工作原理是根據所選擇的協議組裝成相應的報文在前後臺之間通訊，以此達到模擬實際操作的目的，因此我們只需將要測試的交易或功能點所需要組裝的報文傳送給後臺伺服器即可（因為我們關注的只是系統的效能，不是功能），而不必像功能測試那樣，按部就班地重現每一步操作。 l問題二 在測試過程中，我們發現有一個查詢交易的系統響應速度特別慢，無論是在 Controller 中使用單個虛擬使用者執行指令碼，還是在 Vuser 中直接執行，情況均是如此，然而當我們用手工進行同樣操作的時候，響應時間卻明顯地小於工具統計出來的時間，也就是說，在 LoadRunner 中模擬操作的結果與真實操作的結果明顯不一致。經過反覆嘗試與觀察，我們才終於找到問題的原因所在：該查詢交易是通過客戶的證件號碼查詢客戶資訊，當用戶輸入客戶的證件號碼時，如果沒有選擇證件型別，系統會自動將證件型別設定為預設值“身份證”。按“證件型別 + 證件號碼”為組合索引查詢客戶資訊表，查詢速度極快，而在我們錄製指令碼時，忽視了“證件型別”這項輸入，只有“證件號碼”，因此查詢的效率大為降低。解決辦法：只需在測試指令碼中，對 CertType （“證件型別”）一項賦值為“ A ”（“身份證”），此時在 LoadRunner 中重新執行該指令碼，響應速度提高，統計結果與實際完全一致！ 結論： LoadRunner 的工作原理是根據所選擇的協議組裝成相應的報文在前後臺之間通訊，以此達到模擬實際操作的目的，因此我們在測試指令碼中組裝傳送到伺服器端的報文時，注意一定要和實際操作時的傳送報文完全一致，這樣才能保證測試的結果與真實情況相吻合。這就要求在測試正式開始執行時，要對測試指令碼進行反覆的除錯，通常的做法是：在 Vugen 中執行一遍指令碼，統計執行某個事務的時間，再用手工實際做一遍同樣的操作，大體上比較一下，確保與實際估算的時間沒有太大出入後，再逐漸增加併發使用者數，正式開始效能測試。 l問題三 在我們的每個測試指令碼中的 init 部分，都錄製了登入系統的操作，並且對登入的使用者名稱進行了引數化，使用各種不同身份的使用者（分行主管、支行主管、客戶經理等）進行相同的操作。在併發測試過程中發現對某些查詢交易測試的結果波動較大，系統響應時間從零點幾秒到幾十秒不等。經檢查後發現原因在於：使用不同身份的使用者登入系統後，在輸入查詢條件後，點選查詢按鈕後會將根據該使用者的身份，將其所屬的分行機構號、支行機構號、客戶經理編號等一併提交，因此在指令碼中，就必須根據不同的使用者身份，分別將其對應的分支行機構號等也運用引數提交，否則在執行指令碼時就會出現查詢不到記錄或查詢速度變慢等各種問題。解決方法有三個： 1 、修改指令碼，使其能夠依據使用者的身份分別傳送相應引數， 2 、針對不同型別的使用者使用不同的指令碼分別測試。 3 、輸入引數使用統一的使用者型別。在實際中，我們為了簡化指令碼的複雜度，節省對指令碼程式設計的時間，採取的是第三種方法。 結論：由於 LoadRunner 的工作原理是根據所選擇的協議組裝成相應的報文在前後臺之間通訊，因此它會跳過在應用程式前臺進行的校驗，所以在腳本回放的時候一定要注意在指令碼中提前進行這些校驗或改由人工控制，以保證傳送報文的正確性（如操作許可權的控制等）。 l問題四 測試多使用者併發登入系統的時候，從虛擬使用者圖和事務圖上發現，總有一部分使用者在登入的時候要等待很長時間，使用者登入的最小時間與最大時間相差非常大。於是我們在讓指令碼自動執行的同時，手工再登入一個使用者，發現無論如何都不會發生等待的情況，多次試驗的結果均是如此，也就是說 LoadRunner 測試的結果與實際結果再次發生了偏差！經過反覆的除錯，以及與程式開發人員溝通，我們終於發現問題的原因所在：在使用者登入系統的時候，系統會自動記錄登入使用者的資訊，併產生一個登入 ID ，以此 ID 做為主鍵，向資料庫插入記錄。因此當大量使用者在極短的時間內同時登入時，就有可能出現生成相同的登入 ID 的情況，此時便會造成資料庫中的主鍵衝突，導致使用者等待很長時間或登入失敗。而我們手工測試時卻無法做到在很短的時間內同時登入，因此很難用手工重現此種情況。通過 LoadRunner 的模擬表現出來的狀況，正是我們測試出程式存在的效能問題，並非與實際結果的偏差。 還有一個例子，在第二輪效能測試中，同樣發生了類似的情況。在本系統中，如果同一個使用者登入後，未正常退出超過 5 次，系統將會把該使用者鎖住，使其無法再次登入，而我們用於引數化的使用者名稱個數有限，因此當指令碼使用大量使用者同時登入時，很容易造成同樣的使用者登入系統而未簽退的情況發生（指令碼正在執行，還未能退出），此時將會造成許多使用者操作的失敗。 結論：使用 LoadRunner 可以模擬出大量使用者同時對系統操作的情況，而這些情況通過手工往往是很難重現出來的。例如大量使用者在同時對系統做某些操作時，很容易造成資料庫的死鎖、鎖等待、主鍵衝突、資料混亂等等問題，因此在做效能測試的同時，也常常可以連帶測試出系統的一些隱蔽的“缺陷”。在本次效能測試中，這種例子是很多的。對待此類“缺陷”，應具體情況具體分析。有些確實是程式的 BUG ，需要修正，而有些可能只是很極端的情況，只有在做壓力測試時才有可能發生，可不必深究。 l問題五 此問題發生在第二輪測試（即迴歸測試）中。在第一輪測試中發現的效能問題，經程式設計師修正後，我們對系統進行了第二輪效能測試，以驗證其效能改進的效果。在前一輪測試中，我們發現通過選擇客戶級別為“未評級”時，查詢的速度極慢，經過改進後，速度應有較大提高。然而在迴歸測試中，卻依然很慢。經過對測試指令碼和程式的仔細檢查，才發現原來在程式中已將“未評級”這個選項去除，而我們的測試指令碼的引數檔案中仍然保留有該選項，因此測試的結果與前次沒有區別。在引數檔案中將該選項去掉後，測試結果正常，查詢效率有所提高。 結論：使用錄製好的測試指令碼進行迴歸測試之前，一定要先仔細檢查、瞭解程式的改動，對原先的測試指令碼做必要的修改後，才可以重新測試，否則只是在做無用功。 10、教訓 在本次測試過程中，由於經驗不足，我們也得到了一些教訓。前事不忘，後事之師，現總結出來與大家分享。 l與客戶的溝通做得不夠，客戶要求我們做的效能測試用例數量太多，我們未能據理力爭，最後導致工作量過大。 l按照原定的專案計劃，我們要在系統的功能測試即將結束前進駐專案組，準備並進行效能測試。然而由於客戶在功能測試的後期仍然不斷的提出新需求，導致開發人員疲於奔命，系統的效能難以穩定下來，效能測試的前期準備工作也受到很大影響，不能正常開展，浪費了很多人力物力。 l由於客戶無法提供一個單獨的效能測試環境，我們的效能測試工作與業務組的功能測試在同一個環境下進行，而系統的功能測試遲遲未能完成，加上 ETL （資料轉換）小組對資料庫資源的佔用，因此我們的效能測試只能在夜間才能進行。導致時間上的浪費，使專案的成本增加。 l沒有將效能測試中發現的缺陷記錄到缺陷管理工具中加以跟蹤，而僅僅體現在最後的測試報告上，個人認為這是比較不規範的做法。 l效能測試前的資料準備不夠充分。客戶提供測試的系統使用者、身份數量有限，導致許多案例的測試只能使用少量資料進行引數化，由此帶來許多本可以避免的問題。 l測試計劃及測試報告的書寫格式缺乏規範，尤其測試計劃書未能包含本應包含的所有內容。 l在我們將 LoadRunner 的測試結果檔案全部提交給客戶的前提下，客戶仍然要求我們在測試報告中將每一次測試的資料均以表格的形式填至測試報告中，此項工作的工作量十分巨大，個人認為這樣做並無必要。 以上是在本次效能測試及迴歸測試過程中總結出來的一些經驗教訓，在此做一個小小的總結，以便下次工作中改進。