實戰篇：客戶關係管理系統性能測試

系統介紹

圖1（客戶關係管理系統模塊關係圖）

需求分析

一、性能指標

性能指標分析，根據客戶需求與本系統相結合，用戶希望模塊能滿足下表所列的性能指標。

圖2（性能指標）

很明顯，上面的需求是不具可操作性的，這就像和客戶談需求一樣，客戶只是很簡單地描述了需求，而如果僅僅從上面這個簡單的表格來進行性能測試，是很難的一件事情，並且很可能測試出來的結果與實際結果存在很大的差距，這樣就需要對需求進行詳細分析。

有一點需要說明的是，本書只是藉助這個系統對一個案例的性能測試的實踐做深入的分析，故只選擇了部分模塊進行測試，並沒有對整個系統每個模塊的性能測試過程進行詳細的分析。

二、需求詳細分析

既然上面的需要對實際測試指導意義不大，那麼就必須對需求作進一步的詳細分析。

1、登錄

目前情況該公司大概有700名員工，但只有500名員工使用該系統，部分員工是不使用該系統的，但5年後，公司大概有800名員工會使用系統，故確定測試100個用戶同時併發進行登錄操作。所有客戶端都在公司的區域網內。

2、聯繫人管理模塊

從需求可以看出聯繫人管理有兩部分內容，一是統計進入聯繫人管理界面的時間，二是新建聯繫人並提交需求的時間。

併發用戶數，將進入聯繫人管理界面和提交新建聯繫人信息的用戶數設置為相同的用戶數。即使這樣這條需求還是有兩層意思：一是有多少用戶同時在線；二是在線的用戶不一定都進行新建聯繫人活動的操作，也就是說有多少用戶在併發進行新建聯繫人活動。

首先，雖然有500名員工會用到這個系統，但統計日常訪問量，同時在線的用戶大概是40名左右，即使5年後也差不多是60人同時使用該系統。這樣就確定同時在線的用戶大概在60名左右。接著，要確定多少用戶同時併發進行新建聯繫人活動，根據日常統計，現在併發用戶應該在15個左右，即使是5年後也大概是在25個左右，這樣就又確定了同時併發的用戶數為25個。

但這樣還是不夠的，現在系統的記錄條數比較少，如果5年後系統中有大量的聯繫人記錄后情況又將怎麼樣？根據統計每天新增的聯繫人記錄大概在10條左右，一個月大概是200條，這樣5年後大概是12000條。這樣就可以很清楚地對它進行性能測試了。

3、客戶管理模塊

與聯繫人管理模塊分析相同。

4、商機管理模塊

與聯繫人管理模塊分析相同。

5、線索管理模塊

與聯繫人管理模塊分析相同。

測試方案及計劃

一、人力資源

性能測試作為軟體測試的一部分工作，並且性能測試一般都是在系統測試完成後，或者是在系統測試階段中評估系統功能比較穩定，對性能測試沒有影響的情況下進行的。根據測試計劃，性能測試允許的時間為25個工作日，故計劃需要一個人進行測試。

二、時間進度

圖3（時間進度）

三、測試環境準備

在進行測試前，必須先搭建好測試平台。伺服器安裝操作系統為windows2003系統，其中資料庫伺服器和應用伺服器安裝在同一台機器上，伺服器的IP地址為192.168.14.25。測試機安裝的操作系統為windows xp系統，因為測試的併發用戶數最多為100個，故只要一台測試機即可，其中controller和負載機為同一台機器。測試機與伺服器在同一個區域網內。詳細配置如下表。

圖4（配置表）

測試拓撲結構如圖5所示（測試工具：LoadRunner 9.1；錄製協議：HTTP/HTML）

圖5（拓撲圖）

四、業務模型創建

測試環境準備好后還要對業務模型進行設置。業務模型是用來約束和規範業務活動的，指導錄製腳本時的業務流程及業務背景。如果沒有定義好業務模型就很難去錄製腳本或者是錄製好的腳本無法滿足客戶的需求，這幾個模塊具體的業務模型如下表。

圖6（業務模型）

創建業務模型應該注意以下幾點：

1. 對於某個業務流程，用戶在使用過程中是如何操作的

2. 一個業務包含多個子業務時，子業務的先後順序和子業務的關係如何處理。

3. 為了更好地接近用戶的使用習慣，確定業務流程需要哪些支持（如數據準備）

4. 確定虛擬用戶併發數和系統在線用戶數

五、場景模型創建

業務模型是用來規定業務如何活動的，那麼場景又如何控制呢？這就需要創建一個場景模型。場景模型是用來約束和規範業務活動時的場景環境，指導場景如何設計。也就是說，如果沒有定義好場景模型就無法很好地去定義control部分的場景設計或者測試出來的結果和真實的結果還存在很大的差異。這幾個模型具體的場景模型如下表所示。

圖7（場景模型）

創建場景模型應該注意以下幾點：

1. 確定虛擬用戶如何載入？如何釋放？以及場景持續運行的時間，這些數據可以通過以往系統使用的歷史記錄獲得，如果以前沒有相關的這方面記錄，那麼可以通過類似或同行業的情況來做參考。

2. 確定集合點使用的情況

3. 確定是否使用IP欺騙技術

4. 確定要添加哪些計數器

六、測試數據準備

完成以上工作后，接下來就要為業務模型準備數據，一般準備數據可以從以下幾個方面入手：

1. 數據可以來自於以前的歷史數據。如登錄模塊，測試10個用戶同時登錄的情況，如果已有10個真實的用戶賬號信息，那麼在準備數據時，就可以直接調用這些現有的數據。

2. 手動添加準備數據。如登錄模塊，如果現在沒有10個現成的真實用戶賬號信息，那麼就需要自已手動去創建，當然創建的方式就有很多種了，可以使用LR進行創建，也可以寫一段小程序去創建，當然還可以選擇手動創建。但當數據量很大時，選擇手動創建就是一件很困難的事，如測試BOSS系統，幾千個虛擬用戶併發，如果手動去準備這些數據就很麻煩。

3. 數據以何種形式調用。如登錄模塊的這10個用戶賬號信息，在測試過程中如何調用，這裡會出現兩種不同的情況。一是文本形式，文本形式有一個缺點是，LR參數列表中最多允許100行參數，那麼如果參數很多就不能用這種方式了，二是資料庫的方式，如果大量參數要被調用就應選擇資料庫的形式，因為資料庫形式受記錄條件的限制。

各模塊數據準備情況如表

圖8（數據準備）

這些數據都選擇LR生成，100個用戶賬號信息存儲在資料庫中，以方便參數化時調用

測試用例

測試用例是進行性能測試過程中最重要的環節之一，一般地，一個性能測試用例必須包括用例編號、測試目的、併發用戶數、模擬用戶行為和預期結果這五大部分。

圖9（測試用例表）

執行測試

一、腳本開發

根據業務模型和場景模型可以開始開發測試腳本，主要涉及測試腳本實現過程和腳本的結構。虛擬用戶腳本的開發情況如下表

圖10（腳本開發用例）

對於腳本的結構分析，這裡以登錄、進入聯繫人管理界面和新增聯繫人信息3個業務活動為例。（當然只是理論的提及一下）

1、 登錄

在錄製腳本中定義一個集合點「併發登錄」，用來保證虛擬用戶進行了併發登錄操作。定義一個事務「提交登錄」，這樣來統計登錄所花費的時間。添加文本檢查點，檢查登錄的用戶名是否正確。還有對登錄的用戶名和密碼進行參數化。當然為了測試的方便，在準備數據時，用戶名的密碼統一設置為1，這時便不需要對密碼進行參數化。

2、 進入聯繫人管理界面

在進入聯繫人管理界面的腳本中，只需對登錄的用戶名進行參數化，因為所有用戶名和密碼都是一樣的，所以不用對密碼進行參數化。設置集合點，確保所有虛擬用戶併發進入聯繫人管理界面。

3、 新增聯繫人信息

錄製完成腳本后，對腳本進行回放，回放後進入系統查看是否已添加腳本中的新增聯繫人信息，如果沒有的話，則要分析一下是否對腳本進行關聯。

二、場景設計

場景設計主要是對controller（控制器）進行設置，設置腳本運行時的環境。

這裡按場景模型創建中所設計的模型來設置就可以了。比如登錄模塊：在場景組設置100個虛擬用戶；在場景策略中，在腳本運行時對所有的虛擬用戶進行初始化，每5s載入一個虛擬用戶，虛擬用戶載入完成後，持續運行5min，運行結束后每5s釋放一個虛擬用戶，直到所有虛擬用戶釋放完成。啟用IP欺騙功能，腳本中所有集合點都設置為使用的狀態。

註：在這裡沒有對負載發生器（load generators）進行設置，因為在試驗時只使用了一台機器作負載發生器，並且負載發生器和控制器是在同一台機器上，故看到的負載發生器只有localhost，但是如果在測試過程中有多台時，就得對負載發生器進行配置。還有一點就是如果有多台負載發生器，為了達到負載均衡的目的，需要將所有的負載平均地施壓到伺服器上，即負載均衡技術。

三、計數器設置

計數器設置主要是設置在場景運行時，需要監控哪些資源。在這裡所有的腳本都對windows資源和資料庫伺服器進行監控。可添加如下計數器：windows計數器、MySQL資料庫計數器。

四、場景監視

在場景運行過程中必須對場景進行監控，通過監控場景運行時的情況以獲得一些信息，這樣有利於性能測試結果進行分析。如場景組運行控制信息、監視場景狀態圖、監視輸出對話框、監視數據圖。（這些在controller面板中都可以直接看到）

結果分析

腳本執行完成後，就得分析測試結果了，每個模塊執行的結果都要進行分析。比如登錄模塊：

場景是模擬100個虛擬用戶併發登錄，當虛擬用戶載入到50個時，每載入一個虛擬用戶，場景狀態欄的失敗事務數和錯誤信息就在增多。這說明當載入到50個虛擬用戶后，伺服器無法處理客戶端的請求。

接下來分析平均事務響應時間，可以在analysis中看到結果圖，平均事務響應時間一直在增加，也同樣說明伺服器無法處理客戶端的請求，事務一直無法處理完成。到這裡可以得出結論，應該是伺服器已經出現問題，但還不明確是什麼原因導致的。

再來看下windows計數器捕捉到的數據，很明顯地看到CPU的使用率達到100%，內存也存在問題，但是網路沒有問題，這說明伺服器的硬體配置無法處理100個虛擬用戶併發登錄，硬體平台成為性能瓶頸。為了驗證這個判斷，可以在腳本運行過程中手動登錄試一下，結果發現系統幾乎無法動彈，這說明判斷是正確的。

要解決這個問題，必須優化系統配置，否則系統無法處理100個虛擬用戶併發登錄。

測試結論

分析完成後，每個模塊都要寫測試結果。比如登錄模塊：伺服器當前的配置無法處理100個虛擬用戶併發的活動，測試50個虛擬用戶併發時，發現事務都能被成功地處理，但是登錄的時間過長，平均時間為60s，系統資源也超過安全指標，但應用伺服器正常，可以通過優化伺服器的配置來提高性能。

End.

如果對軟體測試感興趣，想了解更多的軟體測試知識，請大家關注「51Testing軟體測試網」鳳凰號。