一、WEB 全面性能測試模型
Web 性能測試模型提出的主要依據是：一種類型的性能測試可以在某些條件下轉化成為另外一種類型的性能測試，這些類型的性能測試的實施是有著相似之處的；
1. 預期指標的性能測試
系統在需求分析和設計階段都會提出一些性能指標，完成這些指標的相關的測試是性能測試的首要工作之一，這些指標主要諸于“系統可以支持并發用戶200個；”系統響應時間不得超過20秒等，對這種預先承諾的性能要求，需要首先進行測試驗證；
2. 獨立業務性能測試
獨立業務實際是指一些核心業務模塊對應的業務，這些模塊通常具有功能比較復雜，使用比較頻繁，屬于核心業務等特點。
用戶并發測試是核心業務模塊的重點測試內容，并發的主要內容是指模擬一定數量的用戶同時使用某一核心的相同或者不同的功能，并且持續一段時間。對相同的功能進行并發測試分為兩種類型，一類是在同一時刻進行完全一樣的操作。另外一類是在同一時刻使用完全一樣的功能。
3. 組合業務性能測試
通常不會所有的用戶只使用一個或者幾個核心業務模塊，一個應用系統的每個功能模塊都可能被使用到；所以WEB性能測試既要模擬多用戶的相同操作，又要模擬多用戶的不同操作；組合業務性能測試是最接近用戶實際使用情況的測試，也是性能測試的核心內容。通常按照用戶的實際使用人數比例來模擬各個模版的組合并發情況；組合性能測試是最能反映用戶使用情況的測試往往和服務器性能測試結合起來，在通過工具模擬用戶操作的同時，還通過測試工具的監控功能采集服務器的計數器信息進而全面分析系統瓶頸。
用戶并發測試是組合業務性能測試的核心內容。組合并發的突出特點是根據用戶使用系統的情況分成不同的用戶組進行并發，每組的用戶比例要根據實際情況來匹配；
4. 疲勞強度性能測試
疲勞強度測試是指在系統穩定運行的情況下，以一定的負載壓力來長時間運行系統的測試，其主要目的是確定系統長時間處理較大業務量時的性能，通過疲勞強度測試基本可以判定系統運行一段時間后是否穩定；
5. 大數據量性能測試
一種是針對某些系統存儲，傳輸，統計查詢等業務進行大數據量時的性能測試，主要針對某些特殊的核心業務或者日常比較常用的組合業務的測試；
第二種是極限狀態下的數據測試，主要是指系統數據量達到一定程度時，通過性能測試來評估系統的響應情況，測試的對象也是某些核心業務或者常用的組合業務。
第三種大數據量測試結合了前面兩種的測試，兩種測試同時運行產生較大數據量的系統性能測試；
大數據量測試通常在投產環境下進行，并獨立出來和疲勞強度測試放在一起，在整個性能測試的后期進行；大數據量的測試可以理解為特定條件下的核心業務或者組合業務測試；
6. 網絡性能測試
主要是為了準確展示帶寬，延遲，負載和端口的變化是如何影響用戶的響應時間的，在實際的軟件項目中
主要是測試應用系統的用戶數目與網絡帶寬的關系。網絡測試的任務通常由系統集成人員完成；
7. 服務器（操作系統，WEB服務器，數據庫服務器）性能測試
初級服務器性能測試主要是指在業務系統工作或者進行前面其他種類性能測試的時候，監控服務器的一些計數器信息，通過這些計數器對服務器進行綜合性能分析，為調優或提高系統性能提供依據；
高級服務器性能測試一般由專門的系統管理員來進行如數據庫服務器由專門的DBA來進行測試和調優；
8. 一些特殊的測試
主要是指配置測試，內存泄露測試的一些特殊的WEB性能測試；
二、WEB 性能測試策略
性能測試策略一般從需求設計階段開始討論如何定制，它決定著性能測試工作要投入多少資源，什么時間開始實施等后續工作的安排；其制定的主要依據是軟件自身的特點和用戶對性能的關注程度，其中軟件自身的特點起決定性的作用；
軟件按照用途的不同可以分為兩大類，系統類軟件和應用類軟件。系統類軟件通常對性能要求較高，因此性能測試應該盡早介入；應用類軟件分為特殊類應用和一般類應用，特殊類應用主要有銀行，電信，電力，保險，醫療，安全等領域軟件，這類軟件使用頻繁，用戶較多，也需要較早進行性能測試；一般類主要是指一些普通類應用如OA，MIS 等一般類軟件根據實際情況制定性能測試策略，受用戶因素影響較大；
1. 系統類軟件
從設計階段就開始針對系統架構，數據庫設計等方面進行討論，從根源來提高性能，系統類軟件一般從單元測試階段開始性能測試實施工作，主要是測試一些和性能相關的算法和模塊；
2. 應用類軟件
特殊應用：從設計階段就開始針對系統架構，數據庫設計等方面進行討論，從根源來提高性能，系統類軟件一般從單元測試階段開始性能測試實施工作，主要是測試一些和性能相關的算法和模塊；
一般應用：與使用用戶的重視程度有關，用戶高度重視時 ，設計階段開始進行一些討論工作，主要在系統測試階段開始進行性能測試實施；用戶一般重視時，可以在系統測試階段的功能測試結束后進行性能測試；用戶不怎么重視時，可以在軟件發布前進行性能測試，提交測試報告即可；
三、WEB性能測試用例設計模型
性能測試用例設計通常不會一次設計到位，是一個不斷迭代完善的過程，即使在使用過程中，也不是完全按照設計好的測試用例來執行，需要根據需求的變化進行調整和修改； WEB性能測試用例設計模型是一個內容全面比較容易組織和調整的模型架構
1. 預期性能指標測試用例
指一些十分明確的，在系統需求設計階段預先提出的，期望系統達到的，或者向用戶保證的性能指標，針對每個指標都要編寫一個或者多個測試用例來驗證系統是否達到要求，預期性能指標測試用例主要參考需求和設計文檔，把里面十分明確的性能要求提取出來，指標中通常以單用戶為主；
如：對于普通的客戶端，系統上傳5MB以內的文件，速度不低于2MB/S；
輸入動作：選擇1-5 MB的文件并上傳，用秒表計時；
期望的性能：上傳的時間小于等于2.5S
實際性能：上傳的時間2.29秒；
這類用例通常以手工的方式執行；
2. 用戶并發性能測試用例
用戶并發測試主要通過逐漸增加用戶數量來加重系統負擔，并通過測試工具對應用系統，各種服務器資源進
監控，用戶并發測試可以是正常數量用戶和特殊數量用戶進行并發， 用戶并發測試是系統性能測試的核心部分，涉及壓力測試，負載測試，強度測試等多方面的內容.獨立業務性能測試實際就是核心業務模塊的某一業務的并發性能測試，可以理解為單元性能測試；組合業務的性能測試是一個或者多個模塊的多個業務同時進行并發性能測試，可以理解為集成性能測試，單元性能測試和集成性能測試兩者緊密相連合并稱為用戶并發性能測試；用戶并發測試要求選擇有代表性的關鍵的業務來設計測試用例，以便更有效的評測系統性能；其測試用例設計文檔的基本的編寫思想是按照系統的體系結構進行編寫.
3. 獨立核心模塊用戶并發性能的測試用例設計
完全一樣功能的并發測試：主要檢查系統的健壯性，從技術角度講就是檢查程序對同一時刻并發操作的處理.
完全一樣操作的并發測試：基本要求是在同一時刻進行完全一樣的操作，這類測試的目的是驗證核心模塊在
大量用戶使用同一功能時是否正常工作；
相同/不同功能的子功能并發：每個不同的子功能都模擬一定的用戶數量，通過工具來控制并發情況；
如發送與接收郵件模塊的一個測試用例，
功能：當在線用戶達到高峰時，發送和接收普通郵件正常，保證2000個以內用戶可以同時訪問郵件系統，能夠正常發送和接收郵件；
目的：測試系統2000個以內的用戶同時在線時能否正常發送郵件；
方法：采用LOADRUNNER的錄制工具錄制一個郵件發送過程測試，要監視數據庫服務器和WEB服務器的性能，其中發送的郵件為普通郵件，附件大小不超過1MB.
并發用戶數與事務執行情況：并發用戶數，事務平均響應時間，事務最大響應時間，平均每秒處理事務數，事務成功率，每秒點擊率，平均流量；
并發用戶數與數據庫主機：并發用戶數，CPU利用率，MEM利用率，磁盤I/O參數，DB參數；
并發用戶數與應用服務器的關系表：并發用戶數，CPU利用率，MEM利用率，磁盤I/O參數；
4. 組合模塊用戶并發性能測試的用例設計
組合模塊的性能測試是最能反映用戶實際使用情況的測試，它把前面系統中具有耦合關系的模塊組合起來進行測試，可以理解為集成性能測試，組合模塊并發測試可以真實反映用戶使用系統的情況，可以從需求，設計文檔；現場調查，系統采集數據獲取用戶場景；
具有耦合關系的核心模塊進行組合并發測試：主要測試在多用戶并發條件下，一些存在耦合關系或者數據接口的模塊是否正常運行；
彼此獨立的，內部具有耦合關系的核心模塊組的并發測試：這類測試的對象是多個模塊組，每個組相關的模塊具有一定的耦合關系，組與組之間關系相互獨立，主要站在用戶的角度考慮問題；
基于用戶場景的并發測試：選擇用戶的一些典型場景進行測試，測試對象不限制于核心模塊或非核心模塊；
組合模塊用戶并發性能測試的前兩種類型仍然是針對核心模塊的同時也關注用戶場景，這樣做的原因是大多數的性能問題都是由用戶經常使用的核心模塊一起的；可以看出，組合模塊的用戶并發性能測試既關注功能測試，也關注性能測試，通過發現一些接口和綜合性能方面的問題，使系統更加穩定的運行。
如下某OA系統組合模塊的一個測試用例：
功能：在線用戶數達到高峰時，用戶可以正常使用系統，目標是滿足500個以內用戶同時在線使用系統；
目的：測試500個以內用戶同時在線時能否使用比較常見的模塊：公文系統，電子公告，網上論壇；
方法：采用LOADRUNNER 的錄制工具錄制三項業務；業務1，在公文系統內進行打開，修改等操作；業務2，在電子公告系統內，察看發布公告； 業務3 ，在網上論壇系統內發布帖子，查看文章；每項業務分配一定數量的用戶，利用LOADRUNNER來完成；
并發用戶數與事務執行情況：業務1，業務2，業務3事務平均響應時間；業務1，業務2，業務3事務最大響應時間；業務1，業務2，業務3平均每秒事務數；業務1，業務2，業務3平均成功率；每秒點擊率；平均流量；
并發用戶數與數據庫主機：CPU利用率；MEM利用率；磁盤I/O情況；DB參數；
并發用戶數與應用服務器的關系：CPU利用率，MEM利用率；磁盤I/O情況；
5. 疲勞強度與大數據量測試
疲勞強度測試：主要特點是長時間對目標測試系統加壓，目的是測試系統的穩定性，持續時間一般在1小時以上；疲勞強度測試屬于用戶并發測試的延續，因此核心內容仍然是核心模塊用戶并發和組合模塊用戶并發，在編寫測試用例時需要編寫不同參數或者負載條件下的多個測試用例，可以參考用戶并發性能測試用例的設計內容，通常修改相應的參數就可實現所需要的測試場景；如下疲勞強度測試用例：
極限名稱：200個用戶同時使用系統的3個模塊；
前提條件：測試客戶端要有足夠的資源；
運行時間：連續運行16小時；
測試方法：采用LOADRUNNER錄制3個任務，然后開始對系統加壓；
輸入動作：任務1，任務2，任務3 ；持續時間， 任務20小時， 任務2，21小時，任務3，16小時；用戶數量；現象；
大數據量測試：主要針對對數據庫有特殊要求的系統進行的測試，如電信業務系統的手機短信業務；可以分為實時大數據量，主要目的是測試用戶較多或者某些業務產生較大數據量時，系統能否穩定運行；極限狀態下的測試，測試系統使用一段時間即系統累計一點量的數據時能否正常的運行業務；前面兩種的結合，測試系統已經累計了較大數據量時，一些實時產生較大數據量的模塊能否穩定工作；如下大數量測試用例：
功能：數據庫中的短信息表可以保存所有不能及時發送的短信息，用戶上線后又能及時發送已經保存的信息；
目的：
方法：
并發用戶數與事務執行情況：輸入說明； 事務平均響應時間；事務最大響應時間；平均每秒處理事務數，事務成功率；每秒點擊率；平均流量；
6. 網絡性能測試
基于硬件的測試：主要是通過各種軟件工具，儀器等測試整個系統的網絡運行環境，一般由系統集成人員負責 ；
基于應用系統的測試：主要測試用戶數目與網絡帶寬的關系，通過測試工具準確展示帶寬，延遲，負載和端口的變化是如何影響用戶響應時間的；
網絡性能測試的用例設計主要針對后一種類型，可以獨立進行測試，也可以和用戶并發性能測試，疲勞強度與大數據量測試結合起來，在原有的基礎上采用工具來調整網絡設置，從而達到監視網絡性能的目的；如下網絡性能測試用例；
目的： 測試系統運行在不同網絡帶寬條件下的性能情況，以及與并發用戶數量的關系；
方法：在不同的廣域網帶寬下使用LOADRUNNNER錄制郵件系統得相關事務操作腳本，然后以不同的帶寬和并發用戶數進行壓力測試，并記錄在各種用戶條件下各種事務的響應情況，同時記錄路由器端口的流量和其他數據；
運行時間：
并發用戶數與事務響應時間：
7. 服務器性能測試
服務器性能測試主要是對數據庫，WEB服務器，操作系統的測試，目的是通過性能測試找出服務器的瓶頸，為系統擴展，優化提供相關的依據；分為：
高級服務器性能測試：在特定的硬件條件下，由數據庫，WEB服務器，操作系統相應領域的專家進行的性能測試；
初級服務器性能測試：在系統運行前面的性能測試時，通過測試工具對數據庫，WEB服務器，操作系統的使用情況進行監控，然后進行綜合分析，找出系統瓶頸；性能測試的主要目的是在軟件功能良好的前提下，發現系統瓶頸并解決，而軟件和服務器是產生瓶頸的兩大來源，因此服務器測試一定要和前面的測試結合起來進行；在進行用戶并發性能測試，疲勞強度與大數據量性能測試時，可以完成對服務器的監控并對服務器性能進行評估；這類部分的測試用例一般不必單獨編寫。
四、WEB性能測試用例設計
WEB 性能測試用例設計模型是設計性能測試用例的一個框架，在實際項目中，需要對其進行適當的剪裁，從而確定性能測試用例的范圍和類別，裁減的依據是性能測試策略和測試范圍；在測試用例主要框架確定后，接下來就要如何設計各類性能測試用例中具體數據。
基于用戶的測試多在用戶現場進行，而為了測試目的而進行的測試多在開發環境即開發團隊的內部進行；為了測試目的而設計的測試用例場景主要根據測試設計人員的經驗來進行，但是仍要參考用戶的實際場景，用戶實際使用場景是設計所有測試用例的依據，性能測試用例設計首先要分析出用戶現實中的典型場景，然后參照典型場景進行設計。比較常見的用戶場景有如下三種：一天內不同時段的使用場景；系統運行不同時期的場景；不同業務模式下的場景；各類測試用例設計的細節：
1. 確定用戶使用系統情況的方法
確定用戶對系統的使用情況是設計用例具體數據的基礎，后面并發用戶數據設計，疲勞強度設計以及各種場景設計都要依賴對用戶使用系統情況的分析，分析用戶使用情況經常采用現場調查和分析系統日志兩種方法；
用戶現場調查：通過和用戶進行溝通，可以確定用戶的人員組成情況；這類方法適用于用戶群體固定且目標測試系統沒有投產前的情況；
分析系統日志：當用戶比較分散，現場調查比較困難時，可以采用對系統日志進行分析的方法，作為對用戶現場調查的補充；
2. 并發用戶數量設計
設計并發用戶數量前，首先要了解確定系統最大并發用戶數量的方法；可以根據系統的最大使用人數或者最大在線數量來評估最大并發用戶數量的方法；
極限法：取最大在線用戶數作為最大并發數，這種方法適用于系統已經投產目標用戶群體不確定的門戶網站，可以通過分析日志來進行測試；也可以使用系統已經注冊的用戶數量作為系統的用戶數量，按照經驗公式來估算最大用戶數量；
用戶趨勢分析：對軟件生存周期內的用戶未來走勢進行分析，預測系統可能達到的最大使用用戶數目，從而估算系統的最大并發用戶數目，這種方法多用于用戶數目逐漸增多的情況；
經驗評估法：多用于系統的使用用戶數目相對穩定而且比較明確的系統；
并發用戶數量的設計基本是按照最大并發用戶的數量的百分比來設計的，對于某一特定的用例，需要注意：
一按照各類用戶同時遞增的方式來設計用戶數量，是為了按照由淺入深的方法來發現系統的瓶頸；二并發用戶的最大值一般不會超過前面計算的最大并發用戶數量的 20% ，除非是為了測試系統能支持的最大并發用戶數量；三設計用戶數量時要考慮成本，因為每組用戶數都意味著至少執行一次測試；
3. 系統不同時間段場景的設計
不同時間段的場景更接近用戶使用情況，它也是設計核心模塊和組合模塊并發性能測試用例的基礎，不同時間段場景分析的數據主要是前面的需求分析和日志分析結果；不同時間段場景的設計基本原則有兩個：一是選擇典型的場景進行測試；尤其要選擇場景中并發用戶數目較大的場景；二是要覆蓋全面，設計出的用例要覆蓋到壓力可能較大的時間段；用戶場景的設計一般與后面的業務模式結合起來進行；
4. 業務模式的設計
業務模式的設計是不同時間段場景設計的特例，也是設計核心模塊和組合模塊并發性能測試用例的基礎，設計業務模式的目的是專注于某些功能模塊的組合，按時間段來設計場景通常會涉及很多模塊，如果系統存在的由應用軟件引起的瓶頸則很難定位，所以才抽象一些特定的業務模式來進行用例的設計；
按照業務模式和時間段的場景來設計性能測試用例時，會涉及到如何設計每個模塊并發用戶數目的問題，通常會取各個相關模塊在24小時內最大的并發用戶數目進行組合；
5. 大數據量測試用例的設計
歷史數據相關的大數據量測試設計與并發用戶的測試設計很類似，首先要確定系統數據的最長遷移周期，確定了系統的最大數據量后，接下來選擇一些前面的核心模塊或者組合模塊的并發用戶測試用例作為其主要內容即可；
運行時大數據量測試主要根據模擬系統運行時可能產生的大數據量來進行測試，這類測試用例通常根據實際情況去分析設計；
6. 一些特定測試用例的設計
疲勞強度測試，最大用戶測試，容量測試等一些特殊的測試用例設計，根據用戶的需求進行，這類用例的相關要求通常十分明確；
性能測試用例最重要的是注意用例間的關系，孤立的設計各類用例只能增加測試成本，浪費人力。性能測試用例設計人員應該追求設計既能覆蓋性能測試需求，又能以較低的成本來執行測試用例；
五、WEB性能測試用例設計總結
1. 測試用例可用性總結
對于一個比較完善的性能測試項目，經常會有一些測試用例不能執行，，因此測試完成后應該分析哪些用例不能執行以及不能執行的原因，這樣可以為下次測試打好基礎。
2. 用例執行效果分析
通過對用例執行效果進行分析，可以為升級或者開發新的性能測試用例提供有利的參考，不是所有的用例都能導致系統瓶頸的出現，因此應該分析哪些用例能夠發現系統問題，哪些用例執行時沒有太大效果。分析那些設計好的用例不但有助于以后設計用例，還可以為再次執行提供參考：當下次測試進度壓力較大時可以先執行重要的用例，跳過那些嘗試性的，不容易發現問題的用例；
3. 用例執行時間分析
分析用例的執行時間是為下次規劃性能測試提供參考，由于很多用例執行時間不是特別確定，導致性能測試計劃也具有一定的不確定性。通過分析用例的執行時間可以為以后的制定測試計劃提供參考；
總之，性能測試用例的設計是需要通過不斷分析總結才能做好，不但要分析性能測試用例的可用性，執行效果，執行時間，還應該分析用例的設計方法，設計思路等。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
