轉載自：http://blog.chinaunix.net/uid-20682147-id-76384.html
性能測試是 Web 應用系統的一項重要質量保證措施。在現實中，很多 Web 性能測試項目由于性能測試需求定義不合理或不明確，導致性能測試項目不能達到預期目標或進度超期。本文針對 Web 應用系統的技術架構和系統使用特點，探討如何有效實施性能測試過程，并重點介紹如何分析獲得合理的性能測試需求，最終對 Web 應用系統性能進行科學、準確的評估。
1 引言
基于Web服務器的應用系統由于提供瀏覽器界面而無須安裝，大大降低了系統部署和升級成本，得以普遍應用。目前，很多企業的核心業務系統均是Web應用，但當Web應用的數據量和訪問用戶量日益增加，系統不得不面臨性能和可靠性方面的挑戰。因此，無論是Web應用系統的開發商或最終用戶，都要求在上線前對系統進行性能，科學評價系統的性能，從而降低系統上線后的性能風險。
在很多性能測試項目中，由于不能合理定義系統的性能測試需求，不能建立和真實環境相符的負載模型，不能科學分析性能測試結果，導致性能測試項目持續時間很長或不能真正評價系統性能并提出性能改進措施。
本文在總結許多Web應用系統性能測試實踐經驗和教訓的基礎上，從與性能測試工具無關的角度介紹Web應用系統性能測試的方法和實施過程，以及如何定義合理的性能測試需求。
1.1 術語定義
性能測試：通過模擬大量瀏覽器客戶端同時訪問Web服務器，獲得系統的性能數據。
虛擬用戶：模擬瀏覽器向Web服務器發送請求并接收響應的一個進程或線程。
響應時間：瀏覽器向Web服務器提交一個請求到收到響應之間的間隔時間。
思考時間：瀏覽器在收到響應后到提交下一個請求之間的間隔時間。
請求成功率：Web服務器正確處理的請求數量和接收到的請求數量的比。
吞吐量：單位時間內Web服務器成功處理的HTTP頁面或HTTP請求數量。
在線用戶：用戶通過瀏覽器訪問登錄Web應用系統后，并不退出該應用系統。通常一個Web應用服務器的在線用戶對應Web應用服務器的一個Session。
并發用戶數：Web服務器在一段時間內為處理瀏覽器請求而建立的HTTP連接數或生成的處理線程數。當所有在線用戶發送HTTP請求的思考時間為零時，Web服務器的并發用戶數等于在線用戶數。
1.2 Web應用系統技術架構
Web應用系統的前端為瀏覽器，后臺為Web服務器（如Apache，Microsoft Internet Information Server），瀏覽器和Web服務器之間的交互基于HTTP協議。HTTP協議本身是無連接的，Web服務器通過Session機制來建立一個瀏覽器所發出的先后連接之間的關聯。通過實驗證明，當瀏覽器客戶端在首次訪問Web服務器后，如果該瀏覽器客戶端不發送后續請求，服務器維持該瀏覽器客戶端的Session變量所消耗的系統資源非常小。
2 Web應用系統性能測試過程
標準的Web應用系統性能測試過程包括確定性能測試需求，開發性能測試腳本，定義性能測試負載模型，執行性能測試和形成性能測試報告。本章將分別介紹上述過程，并通過舉例說明如何完成每一環節。
2.1 確定性能測試需求
科學定義Web應用系統性能測試需求對一個成功的性能測試非常重要。通常，Web應用系統的性能測試需求有如下兩種描述方法。
2.1.1 基于在線用戶的性能測試需求
該需求描述方法主要基于Web應用系統的在線用戶和響應時間來度量系統性能。當Web應用系統在上線后所支持的在線用戶數以及操作習慣（包括操作和請求之間的延遲）很容易獲得，如企業的內部應用系統， 通常采用基于在線用戶的方式來描述性能測試需求。以提供網上購物的Web應用系統為例，基于在線用戶的性能測試需求可描述為：10個在線用戶按正常操作速度訪問網上購物系統的下定單功能，下定單交易的成功率是100%，而且90%的下定單請求響應時間不大于8秒；當90%的請求響應時間不大于用戶的最大容忍時間20秒時，系統能支持50個在線用戶。
2.1.2 基于吞吐量的性能測試需求
該需求描述方法主要基于Web應用系統的吞吐量和響應時間來度量系統性能。當Web應用在上線后所支持的在線用戶無法確定，如基于Internet的網上購物系統，可通過每天下定單的業務量直接計算其吞吐量，從而采取基于吞吐量的方式來描述性能測試需求。以網上購物系統為例，基于吞吐量的性能測試需求可描述為：網上購物系統在每分鐘內需處理10筆下定單操作，交易成功率為100%，而且90%的請求響應時間不大于8秒。
2.2 開發性能測試腳本
在確定Web應用系統性能測試需求后，就要根據性能測試需求中確定的功能開發性能測試腳本。比如，針對前面定義的網上購物系統的性能測試需求，將開發下定單功能的性能測試腳本。
性能測試腳本是描述單個瀏覽器向Web服務器發送的HTTP請求序列。每個性能測試工具（如IBM Rational Performance Tester， LoadRunner）所提供的測試腳本語法是不同的。測試人員利用性能測試工具可從頭手工編寫測試腳本，也可以通過錄制瀏覽器和Web服務器之間的網絡通信數據而自動形成測試腳本。
任何性能測試工具都不能保證錄制形成的性能測試腳本的正確性，測試人員應通過在單用戶下運行性能測試腳本對其正確性進行驗證。測試腳本不正確的一個重要原因就是腳本的數據關聯不正確，也就是并沒完全建立一個測試請求和前面的響應內容之間的關聯。測試腳本HTTP請求和響應之間的數據關聯是否正確的一個重要標準是單用戶運行腳本，腳本能完成期望的功能。
在完成性能測試腳本的數據關聯后，需要對腳本進行參數化，也就是把腳本中的某些請求數據替換成變量，變量的值來于一個獨立的數據文件，從而保證在多虛擬用戶運行腳本的情況下，每個虛擬用戶所提交的數據是不同的。
此外，為了測試Web應用的可靠性，還需要對請求所收到的響應進行驗證（比如驗證響應的HTTP返回碼或驗證響應的內容），便于性能測試完成后統計請求成功率。
2.3 建立性能測試負載模型
性能測試負載模型定義了測試工具如何向Web應用系統提交請求，包括向Web應用系統發送請求的虛擬用戶數，每個虛擬用戶發送請求的速度和頻率。針對前面介紹的網上購物系統的性能測試需求，在性能測試工具中定義的性能測試負載模型應包括如下信息：
虛擬用戶數：性能測試不僅僅是執行一次，而且每次執行時虛擬用戶數也不固定，因此在性能測試負載模型中定義的虛擬用戶數將在測試執行時進行設置。
虛擬用戶發送請求的思考時間和迭代次數：虛擬用戶發送請求的思考時間長短是決定Web應用系統負載量的重要因素之一，而迭代次數將決定性能測試的執行持續時間。對基于在線用戶的性能測試需求，將基于錄制腳本時記錄的思考時間，而且由于現實中不同用戶訪問系統的思考時間不同，可把思考時間設置為在一定范圍內的隨機值。對于基于吞吐量的性能測試需求，將把思考時間設置為零，此時Web應用系統的在線用戶數量將等于并發用戶數。同時，為了避免性能測試壓力的隨機性，將增加請求的迭代次數來增加測試執行持續時間，從而獲得系統在穩定壓力下的性能數據。
虛擬用戶啟動模式：在現實中，Web應用系統的用戶不太可能同時做相同的操作，因此為了讓Web應用系統所承擔的壓力隨時間均勻分布，建議虛擬用戶依次啟動，同時也避免大量用戶同時登錄造成系統阻塞。以10個虛擬用戶模擬下定單為例，可設置每個虛擬用戶間隔30秒啟動，這樣10個虛擬用戶可在5分鐘后完成啟動，并保證10個虛擬用戶不會在同一時刻下定單，從而更符合實際情況。
2.4 執行性能測試
執行性能測試是指通過多次運行性能測試負載模型，獲得系統的性能數據。在執行過程中，需利用測試工具、操作系統、系統軟件（如Web Server或DB Server）提供的資源監控手段對資源進行監控和分析，幫助發現資源瓶頸，并在系統層面進行優化。同時，還需對應用進行性能分析，幫助定位應用代碼中的性能問題，切實解決系統的性能問題。
2.5 形成性能測試報告
性能測試項目的最后階段就是向相關人員提交性能測試報告，匯報性能測試結果。在向相關人員匯報性能測試結果時，并不是性能測試報告越豐富、性能數據越多越好。好的性能測試報告是能準確、簡單地傳遞性能測試結論，而不需太多的技術細節。
針對基于在線用戶數的性能測試需求，可通過下圖總結性能測試結論。其中橫軸是在線用戶數，縱軸是響應時間，如40在線用戶訪問網上購物系統時，90%的下定單請求響應時間不超過10秒。
圖一：在線用戶數和響應時間時間的趨勢圖
針對基于吞吐量的性能測試需求，可通過下圖的曲線來描述性能測試結果。以網上購物系統為例，下圖描述下定單的并發用戶、下定單響應時間以及吞吐量（服務器每秒處理定單筆數）之間的關系，從而快速判斷系統是否能滿足性能測試需求。從下圖中可看出，并發用戶增加，請求的響應時間也增加。服務器的吞吐量是先隨并發用戶數增加而增加，當吞吐量到達一定峰值后，再增加并發用戶數，吞吐量會減少。原因在于當并發用戶數少時，向Web服務器提交的請求量不大，服務器處理能力還有富余，所以吞吐量逐步增大；但當并發用戶數超過某一值時，由于向服務器提交的請求太多，造成服務器阻塞，反而導致吞吐量減少。
圖二：響應時間、吞吐量和并發用戶數的趨勢圖
3 如何獲取合理的性能測試需求
前一章介紹了Web應用系統的性能測試過程，確定性能測試需求是整個性能測試的起點和成功的重要因素。性能測試需求定義得過高，雖然確保系統上線后能滿足性能需求，但可能會造成硬件資源的浪費；性能測試需求定義得過低，系統上線后可能會出現性能問題。如何通過分析系統上線后可能的用戶訪問行為，來獲得合理的性能測試需求指標呢？
假設現有一個基于Web的辦公自動化系統（簡稱OA系統），該系統提供公文收發和查詢功能。在部署該系統前，將對該系統進行性能測試。下面將詳細介紹如何分析該OA系統的使用情況，定義合理的性能測試需求。
3.1 如何獲得OA系統的在線用戶數量
在線用戶數量是指在特定時間區間內，有多少用戶訪問Web應用系統（對應到Web服務器的Session數），根據系統可能訪問用戶數以及每個用戶訪問系統的時間長短來確定。
對于將要部署的OA系統，通過分析獲得該系統有8000個注冊用戶，基本上所有的用戶每天（8小時工作時間）都會訪問OA系統，平均在線時間（從登錄OA系統到退出OA系統之間的時間間隔，也可以是多次在線時間的合計）為12分鐘，那么該OA系統的平均在線數（也就是Web應用Session變量數）為200個（8000 * 0.2 / 8），假設峰值在線用戶數是平均在線用戶數的3倍（該倍數可根據實際情況調整），則性能測試需求的在線用戶數為600。
3.2 如何確定OA系統的性能測試用例
由于時間和資源限制，不可能對Web應用系統的所有功能進行性能測試，而是從業務的角度（如某一功能操作的用戶多）和技術的角度（如某一功能雖然訪問用戶不多，但內部處理邏輯復雜或處理數據量大）來選擇Web應用系統的特定功能作為性能測試用例。
以OA系統為例，由于所有用戶都經常公文查詢功能，因此確定的性能測試用例為公文查詢。
3.3 如何確定OA系統的響應時間
響應時間的快慢直接影響了系統使用用戶的滿意度，采用平均響應時間來描述系統系統性能測試需求是不科學的，因為無法直接和客戶的滿意度掛鉤。而且，在做性能測試，如果某一請求的響應時間過長或過短，將導致平均響應時間和實際情況偏離。
以OA系統為例，定義的響應時間需求為：90%（該百分比和要求的系統用戶滿意度相關）的查詢請求響應時間不超過8秒（該時間可根據實際情況確定）。
3.4 如何確定OA系統的交易吞吐量
單位時間內Web應用系統需處理多少筆特定的交易可通過統計獲得。以OA系統為例，假設每個用戶每天（一天按8小時計算）平均會查詢公文4次，那OA應用的Web服務器平均每分鐘要能處理8000 * 4 / ( 60 * 8 ) = 66.67筆查詢公文交易，考慮到峰值因素，要求每分鐘能處理66.7 * 3=200筆查詢公文交易。
3.5 OA系統性能測試需求描述
通過前面的分析，能明確定義合理的性能測試需求。OA系統性能測試需求定義如下：
基于在線用戶數的性能測試需求：600個在線用戶按正常操作速度訪問OA系統的查詢公文功能，所有查詢請求的成功率是100%，而且90%的查詢請求響應時間不大于8秒。
基于吞吐量的性能測試需求：OA系統在每分鐘內需處理200筆查詢公文操作，交易成功率為100%，而且90%的請求響應時間不大于8秒。
4 總結
Web應用性能測試項目成功的關鍵不在于性能測試工具，而在于有效的性能測試分析方法和實踐。只有切實掌握性能測試需求分析方法，性能測試實踐經驗，才能保證一個Web應用性能測試的成功。