系統介紹
圖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，系統資源也超過安全指標，但應用服務器正常，可以通過優化服務器的配置來提高性能。
備注：文字講解來自《深入性能測試--LoadRunner性能測試、流程、監控、調優全程實戰剖析》（黃文高、何月順編著）一書，我是新手，參照此教程做了下實踐，順便將學到的東西寫下來。----此篇完全是從書上摘抄下來的理論實戰，后續實戰后會補上詳細的實戰操作說明