客戶關系管理系統性能測試課題名學生姓名指導教師：**第一章測試計劃1.1人力資源1.2測試環境1.3業務模型創建1.4場景模型創建1.5測試數據準備第二章測試用例第三章執行測試3.1腳本開發133.2場景設計3.3計數器設置第四章結果分析第五章測試結論第一章測試計劃1.1人力資源性能測試作為測試的一部分工作，根據測試計劃，性能測試允許的時間為25個工作日，計劃需要一個人進行測試。1.2測試環境在進行測試前，必須先搭建好測試平臺。服務器按章操作系統為系統，其中數據庫和應用服務器安裝在同一臺機測試機安裝的操作系統為系統，因為測試的并發用戶最多為100個，其中和負載機為同一臺及其。測試機和服務器在同一個局域網內。詳細的測試機與服務器軟硬件配置，見表1-1所示；設備硬件配置軟件配置數據庫服務器應用服務器PC機（一臺）CPU：.4GHz內存：2.0GB硬盤：控制器負載機PC機（一臺）CPU：.06GHz內存：512MB硬盤：ner9.1IE6..3業務模型創建測試環境準備好之后要對業務模型進行設計，知道錄制腳本時的業務流程及業務背景，如表1-2所示；指標種類業務模型登陸100個虛擬用戶同時并發測試業務聯系人準備12000條聯系人記錄進入聯系人管理界面的并發用戶數位25增聯系人活動并提交的并發用戶數位25客戶準備2400條客戶記錄進入客戶界面的并發用戶為25新增客戶記錄并提交的并發用戶數位25商機準備2400條商機記錄進入商機管理界面的并發用戶為25新增商機管理界面的并發用戶為25線索準備12000條銷售活動記錄進入線索管理界面的并發用戶25新增線索并提交的并發用戶251-2業務模型1.4場景模型創建業務模型是用來規范業務如何活動的。
那么場景又如何控制呢？這就需要創建一個場景模型。什么叫場景模型？場景模型用來約束和規范業務活動時的場景環境，指導場景如何設計。也就是說，如果沒有定義好場景模型，那么就無法很好地去定義部分的場景設計或者測試出來的結果和真實的結果還存在很大的差異。這幾個模塊具體的場景模型，如表1-3所示；1-3場景模型：指標種類場景模型業務登陸秒加載一個虛擬用戶，虛擬用戶加載完成之后，場景持續運行使用IP欺騙，IP欺騙新建１５個IP地址添加計數器監視虛擬用戶運行日志文件聯系人秒加載一個虛擬用戶，虛擬用戶加載完成之后，使用IP欺騙，IP欺騙新建１５個IP地址添加計數器監視虛擬用戶運行日志文件客戶秒加載一個虛擬用戶，虛擬用戶加載完成之后，使用IP欺騙，IP欺騙新建１５個IP地址添加計數器監視虛擬用戶運行日志文件商機秒加載一個虛擬用戶，虛擬用戶加載完成之后，使用IP欺騙，IP欺騙新建１５個IP地址添加計數器監視虛擬用戶運行日志文件線索秒加載一個虛擬用戶，虛擬用戶加載完成之后，使用IP欺騙，IP欺騙新建１５個IP地址添加計數器監視虛擬用戶運行日志文件1.5測試數據準備完成以上工作后，接下來就要為業務模型準備數據，一般準備數據可以從以下幾個方面入手：數據可以來自于以前的歷史數據。
如登陸模塊，測試10個用戶同時登陸的情況，如果已有10個真實的用戶賬號信息，那么在準備數據時，就可以直接調用這些現有的數據。手動添加準備數據。如登錄模塊，如果現在沒有10個現成的真實用戶賬號信息，那么就需要自己手動去創建，當然創建的方式就有很多種了，可以使用進行創建，也可以寫一段小程序去創建，當然還可以選擇手動創建。但是當數據量很大時，選擇手動創建就是一件很困難的事，如測試BOSS（）系統，幾千個虛擬用戶并發，如果手動去準備這些數據就很麻煩。數據以何種形式調用。如登陸模塊的這10個賬號信息，在測試過程中如何調用，這里會出現兩種不同的情況。一是文本形式，文本形式有一個缺點是，參數列表中最多允許100行參數，那么如果參數很多就不能用這種方式了，二是數據庫的方式，如果大量參數要被調用的話，就應選擇數據庫的形式，因為數據庫形式沒有受記錄的限制。各模塊數據準備情況，見表1-4。1-4準備數據指標種類準備數據登陸準備好100個正確的用戶賬號信息業務聯系人準備好12000條聯系人記錄客戶準備好2400條客戶記錄商機準備好2400條商機記錄線索準備好12000條線索記錄這些數據都選擇生成，100個用戶賬號信息存儲在數據庫中，以方便參數化時調用。
第二章測試用例根據測試計劃，設計了包括用力編號、測試目的、開發用戶數、模擬用戶行為和預期結果五大部分的測試用例。登陸用力編號測試目的測試100個虛擬用戶并發時，系統登陸響應時間并發用戶數100個模擬用戶行為輸入用戶名和密碼，點擊登陸預期結果系統登陸的響應時間不能超過進入聯系人管理界面用力編號測試目的測試進入聯系人管理界面活動，系統進入聯系人管理界面的響應時間并發用戶數25進入首頁，點擊“聯系人管理”按鈕，進入聯系人管理界面預期結果系統處理進入聯系人管理界面響應時間不能超過新增聯系人用力編號測試目的測試提交新增聯系人活動，系統提交的響應時間并發用戶數25進入首頁，點擊“聯系人管理”按鈕，進入聯系人管理界面填寫新增聯系人信息，并提交”預期結果系統處理提交新增聯系人信息的響應時間不能超過進入客戶管理界面用力編號測試目的測試進入客戶界面活動，系統進入客戶界面的響應時間并發用戶數25進入首頁，點擊“客戶管理”按鈕預期結果系統處理進入客戶管理界面響應時間不能超過新增客戶記錄用力編號測試目的測試提交客戶記錄，系統提交客戶記錄的響應時間并發用戶數25填寫新增客戶信息，并提交預期結果系統處理提交新增客戶信息響應時間不能超過進入商機管理界面用力編號測試目的測試進入商機管理界面活動，系統進入客戶界面的響應時間并發用戶數25進入首頁，點擊“商機管理”按鈕預期結果系統處理進入商機管理界面響應時間不能超過新增商機記錄用力編號測試目的測新增商機記錄，系統新增商機的響應時間并發用戶數25填寫新增商機信息，并提交預期結果系統處理新增商機響應時間不能超過 進入線索管理界面用力編號 測試目的 測試進入線索管理界面活動，系統進入線索界面的響應時間 并發用戶數 25 進入首頁，點擊“線索管理”按鈕預期結果 系統處理進入線索管理界面響應時間不能超過 新增線索記錄用力編號 測試目的 測試提交線索管理界面活動，系統新增線索界面的響應時間 并發用戶數 25 險些新增線索信息，并提交預期結果 系統處理提交新線索響應時間不能超過 第三章執行測試 3.1 腳本開發 根據業務模型和場景模型可以開始開發測試腳本，主要涉及到測試腳本實現過程和腳 本的結構。
虛擬用戶腳本的開發情況見表 3-1 3-1虛擬用戶腳本開發情況 用例編號 用例名稱 開發情況 并發登陸 在腳本中對用戶名和密碼進行參數化， 參數調用 是通過讀取數據庫中的數據來獲得， 設置文本檢 查點，檢查登陸的用戶名是都正確 進入聯系人管理界 該腳本和 合并，在 登陸后，其中 25個虛擬用戶進行并發聯系人管理界面操作 新增聯系人 該腳本和 合并，在 登陸后，其中 25個虛擬用戶進行并發提交新增聯系人活動 操作 進入客戶管理界面 該腳本和 合并，在 登陸后，其中 25個虛擬用戶進行并發進入客戶管理界面操 新增客戶記錄 該腳本和 合并，在 登陸后，其中 25個虛擬用戶進行并發新增客戶記錄操作 進入商機管理界面 該腳本和 合并，在 登陸后，其中 25個虛擬用戶進行并發進入商機管理界面操 新增商機 該腳本和 合并，在 登陸后，其中 25個虛擬用戶進行并發新增商機記錄操作 進入線索管理界面 該腳本和 合并，在 登陸后，其中 25個虛擬用戶進行并發進入線索管理界面操 新增線索記錄 該腳本和 合并，在 登陸后，其中 25個虛擬用戶進行并發新增線索操作 登陸進入 主界面，如圖 3-1 所示； 圖3-1 點擊“ /Edit ”，啟用后新建一個用戶腳本，因為我們要測試的是 Web應用所以如下所示，選擇 Web(HTTP/Html)協議，如圖 3-2 所示； 3-2Web(HTTP/Html) 協議 在錄制腳本中定義一個集合點 “并發登陸”，用來保證虛擬用戶真的進行了并發登錄操 作。
定義一個事務“提交登陸” ，這樣來統計登陸所花費的時間。添加文本檢查點，檢查登 陸的用戶名是否正確。 所有代碼都放在 部分。并發登陸實例的腳本結構如圖 3-3 3-3登陸用例腳本結構 對登陸的用戶名進行參數化，將參數化的文件放在一個專門管理參數化數據的文件夾 中，將參數列表中讀取參數的路徑由絕對路徑更改為相對路徑。在這里并未對密碼進行參 數化，為了測試方便，在準備數據時，用戶名密碼統一設置為“ Admin”。故不需要對密碼 進行參數化。 進入聯系人管理界面在進入聯系人管理界面的腳本中， 只需對登陸的用戶名進行參數化， 這里沒有對密碼進 行參數化，因為所有用戶名、密碼都是一樣的。設置集合點，確保所有虛擬用戶并發進入 聯系人管理界面。其腳本結構圖，如圖 3-4 所示。 3-4進入聯系人管理界面 新增聯系人信息新增聯系人腳本是最重要的腳本之一。錄制完成腳本之后，對腳本進行回放，回放 后進入系統查看是否已添加腳本中的新增聯系人信息，此時發現，該腳本中新增用戶信息 并未被添加（錄制腳本使用的登錄用戶名為 test1, 添加的聯系人姓名為 hehel ，腳本調試 過程中對登陸用戶名進行參數化，參數內容為 test1 test2），即用戶 test2 中并沒有聯 hehel的信息，這說明腳本出現問題。
這時分析回放日志，但并未發現異常日志，這 時一種猜測是腳本應該需要關聯， 前面講了腳本關聯的幾種方法， 下面進行以下分析處理： ）使用兩個用戶test1 和test2 分別錄制業務流程一樣的腳本。 ）再使用 自帶的 WDiff 工具比較兩個腳本，此時發現在提交新增聯系人信 息的過程中“ Name=”的內容不一致，如圖 3-5 所示。 3- 比較腳本 這說明每次提交一個新增聯系人信息時， “Name=”的值是服務器分配的， 并且每次的值都不一樣，這就說明需要對該 ID 進行關聯，接著找到需要關聯 ID 的左右邊 界，手動創建一個關聯規則，重新錄制腳本即可，關聯后代碼如圖 3-6 所示。 3-6腳本關聯 關聯后再次進行回放，發現 admin 下面還是沒有添加那個聯系人，這說明腳本還是有 問題，但實在是想不出哪里有問題，然后手動用 admin 這個用戶名登陸系統，添加剛才的 聯系人，結果提示：“存在同名的聯系人，是否正確添加” 。到這里說明腳本已經成功添加 了聯系人，只是在聯系人列表中未看到添加的聯系人信息，如圖 3-7 所示。
圖3-7 聯系人列表 這說明腳本在處理業務流程時已經出現問題， 接下來應該分析添加聯系人的業務流程， 添加聯系人界面如圖 3-8 所示。 3-8添加聯系人 經過分析發現，在提交新增聯系人信息時，有一項“負責人”一直都是當前的用戶名， 再看一下聯系人列表中的“負責人”欄，只有當前負責人添加的聯系人信息才會顯示出來， test2用戶下其實是添加了 hehel 這個聯系人的，之所以看不到是因為在腳本運行的時 候“負責人”項一直都是 test1 ，原因找到了，最后只需要對“負責人”項進行參數化， 并且負責人應該和登陸用戶保持一致，但問題是不知道腳本中哪一項是負責人信息，又沒 有其他的技巧，后來經過多次手動試驗一項一項的排除后才找到了“負責人”項在腳本的 位置，下面是修改后的腳本，如圖 3-9 所示。 圖3-9 對負責人的值進行參數化 3.2 場景設計 場景設計主要是對 （控制器）進行設置，設置腳本運行時的環境。這里只 對登陸、進入聯系人管理界面和新增聯系人三個模塊進行詳細的描述，其他的模塊都大同 小異，在此不進行詳細的描述。 登陸這里場景組設置 10 個虛擬用戶，如圖 3-10 所示。
3-10場景組設計 場景策略的設置，在腳本運行時對所有的虛擬用戶進行初始化，每 秒加載一個虛擬用戶，虛擬用戶加載完成后，持續運行 秒釋放一個虛擬用戶，直到所有用戶釋放完成，如圖 3-11 所示。 3-11場景策略設置 啟動 IP 欺騙功能，腳本中所有集合點都設置為使用狀態，如圖 3-12 所示。 3-12集合點設置 進入聯系人管理界面場景組設置 10 個虛擬用戶，如圖 3-13 所示。 3-13場景組設置 和登錄模塊一樣，負載發生器沒有進行設置。 場景策略設置， 在腳本運行時對所有的虛擬用戶進行初始化， 秒加載一個虛擬用戶，虛擬用戶加載完成后，持續運行 秒釋放一個虛擬用戶，直到所有虛擬用戶釋放完成，如圖 3-14 所示。 3-14場景策略設置 啟動 IP 欺騙功能，腳本中所有集合點都設置為使用狀態，如圖 3-15 所示。 3-15集合點設置 新增聯系人管理信息場景組設置 10 個虛擬用戶，如圖 3-16 所示。 3-16場景組設置 場景策略設置，在腳本運行時對所有的虛擬用戶進行初始化，每 秒加載一個虛擬用戶，虛擬用戶加載完成后，持續運行 秒釋放一個虛擬用戶，直到所有虛擬用戶釋放完成。
如圖 3-17 所示。 3-17場景策略設置 啟動 IP 欺騙功能，腳本中所有集合點都設置為使用的狀態，如圖 3-18 所示。 3-18集合點設置 3.3 計數器設置 計算器設置主要是設置在場景運行時，需要監控那些資源。在這里所有的腳本都對 資源和數據庫服務器進行監控。這里以登錄模塊為例，其他的模塊設置一致。 1. 計數器 添加 計數器，具體如何添加在前面講述過，這里就不再詳細描述，監控的對 象為需要監控的某臺服務器 （數據庫服務器或應用服務器的 資源），當然因為這里 兩個服務器都安裝在同一臺機器，不存在這些之分。 資源計數器如圖 3-19 所示。 3- 資源監控圖 2.MySQL數據庫計數器 MySQL 數據庫計數器的添加方式與 計數器的添加放肆一樣。被監控的機器為數 據庫服務器。 MySQL數據庫計數器如圖 3-20 所示。 3-數據庫計數器 在添加數據庫計數器時， 有時場景狀態欄輸出窗口會提示如圖 3-20 所示的錯誤信息， 2-21所示； 3-21數據庫計數器添加報錯 出錯的原因是計數器的這些信息和 的這些信息名稱不相符引起的，有時候 計數器中也會出現。
出錯后這些指標的值 無法獲取。但是為什么與 資源的名稱不相符就會報錯，并且沒有值顯示呢？原因是因為 的這些 計數器的值其實不是自己創建的，而是從 系統中調用出來的，故如果名稱不一樣 就無法從 系統中讀到這些指標的值，這樣這些指標的值就無法被 顯示出來， 場景狀態欄就會彈出錯誤提示信息。 操作系統內部監視器如圖 3-22 所示。 3- 操作系統監視器 操作系統監視器也可以添加計數器，這和 添加的計數器如出一轍。 所以其實這些指標并不是 自己去創建的， 而是直接從 操作系統中“挖 過來的”。 3.4 場景監視 在場景運行過程中必須對場景進行監控，通過監控場景運行時的情況來獲得一些信 息，這樣有利于對性能測試結果進行分析，以下幾個方面的信息需要監控。 在這里需要監控場景組中所有虛擬用戶運行的情況，同時也可以對虛擬用戶運行的情 況進行控制，如圖 3-23 所示。 3-23場景組中虛擬用戶運行的情況 同時還需要監視虛擬用戶組中每個虛擬用戶運行的情況， 并且一定要觀察日志文件的情 況，如圖 3-24 所示。
3-24監視虛擬用戶組運行的情況和日志文件 監視場景狀態圖中信息的情況， 最重要的是關注錯誤事務的情況，如圖 3-25 所示。 3-25監視場景運行狀態圖 如果在運行過程中場景狀態出現 的信息管理系統測試點，那么一定要查看輸出對話框錯誤信息 的情況，可以幫助調試腳本和分析結果，如圖 3-26 所示。 3-26監視輸出對話框的提示信息 監視數據庫在數據圖部分主要監視 個視圖的變化（正運行虛擬用戶數、事物的響應時間、每秒點擊率、 計數器和 MySQL計數器），如圖 3-27 所示。 3-27監視數據圖的信息 第四章 結果分析 登陸場景是模擬 100個虛擬用戶并發登陸， 當虛擬用戶增加到 50 個時，每加載一個虛擬用 戶時，場景狀態欄的失敗事務數和錯誤信息就在增多，如圖 4-1 所示。這說明當加載到 50 個虛擬用戶后，服務器無法處理客戶端的請求。 4-1失敗事務和錯誤信息 接下來分析平均事務響應時間，如圖 4-2 所示。平均事務響應時間一直在增加，也 同樣說明服務器無法處理客戶端的請求管理系統測試點，事務一直無法處理完成。到這里可以得到結論應 該是服務器已經出現問題，但還不明確是什么原因導致的。
4-2平均事務響應時間 再看一下 計數器捕捉到的數據，可以看到 CPU的使用率達到 100%，內存也 存在問題，但是網絡沒有問題，這說明服務器的硬件配置無法處理 100 個虛擬用戶并發登 陸，硬件平臺成為性能瓶頸。為了驗證這個判斷，可以在腳本運行過程中，手動登陸一次 試一下，結果發現系統幾乎無法動彈。這說明判斷是正確餓的，系統硬件資源成為系統性 能的瓶頸。 要解決這個問題，必須優化系統配置，否則系統無法處理 100 個虛擬用戶并發登陸。在這 里是因為進行實例講述，不方便去優化系統配置，但可以降低并發用戶數，測試 35 個虛擬 用戶并發的情況。 35個虛擬用戶時， CPU 的使用率還是幾乎達到 100%，內存 Page/sec 的指標超過 80，說明硬件配置在 35 個虛擬用戶并發登陸時，還不是最好的，但是并沒有失敗的事務， 這說明處理 35 個虛擬用戶并發登陸時沒有任何影響， 在這里就不再繼續測試下去了， 有興趣的朋友可以自己試試。 通過上面的結果可以得知， 系統無法處理 100 個虛擬用戶同時并發登陸， 在使用 50 個虛擬用戶并發登陸時， 雖然沒有 失敗的事務，但是事務的處理時間過長，平均時間大概在 60 秒。
這是因為服務器的硬件配 置引起的。 進入聯系人管理界面從上圖可以看到平均時間在 33.188 秒，這個時間應該不是很確切，從曲線圖中可以看 到大概是在 40 秒，但不管哪個時間，這個平均時間顯示是太長了，這樣的系統性能不能讓 人滿意。 新增聯系人場景運行完成后，首先分析平均事務響應時間，平均事務響應時間為 15.893 秒，這個 時間也是很長的一個時間，并且平均事務響應時間像波浪一樣有規律的出現，該頁面 是在新增加一條聯系人記錄并保存后進入的頁面，本來應該是顯示當前添加的信息人 信息，但在試驗過程中，添加聯系人后，系統無法從數據庫只能夠讀取該數據庫，導 致頁面出錯，這就是為什么平均事務響應時間達到 15.893 秒的原因，同時也可以解釋 為什么平均事務項波浪一樣。因為在新增聯系人時，這個頁面有時訪問成功，有時訪 問不成功。 第五章 測試結論 每個模塊的測試結果如下 登陸登陸模塊，服務器當前的配置無法處理 100 個虛擬用戶并發的活動， 測試 50個虛擬用 戶并發時，發現事務都能被成功的處理，但是登陸的時間過長，平均時間為 60秒，系統資 源也超過安全指標，但應用服務器正常，可以通過優化服務器的配置來提高性能。
進入聯系人管理界面進入聯系人管理界面模塊，在 25 個虛擬用戶并發時，平均事務響應時間在 40 時網絡傳輸時間明顯過長，系統資源使用超過安全指標，再試驗20 個虛擬用戶并發，發現 平均事務響應時間為 增加聯系人25 個虛擬用戶并發，平均事務響應時間為 15.893 秒，服務器無法處理 25個虛擬用戶 并發，有頁面訪問出錯的現象，主要可以通過調節系統配置來優化性能，與應用服務 器、數據庫服務器的關系不大。