第5章 Web性能測試方法
良好的開始是成功的一半。小白所在公司網站的代碼編寫的差不多了，安放服務器的機房也已經找好，只要等第4章選購的服務器正式到位，就可以上機架、部署測試版本網站進行試運行了。離部署測試版的日子還有一段時間，小白對現在這段短暫的空閑，做了如下的安排：
首先要熟悉性能測試的幾種方法。
在第4章CPU和硬盤的基礎上，熟悉常見操作系統的性能計數器特點，并在自己的電腦上進行一次手工的性能測試。
熟悉常用的幾種性能測試軟件，聽說有Load Runner等，從中選擇一個比較好的，畢竟這也是部門經理在第4章開頭布置的任務之一。
這3點內容將分別在從本章開始的第5章、第6章和第7章中講述?，F在就開始介紹Web性能測試的一些方法。
5.1 Web性能測試的目的與方法
本節首先介紹測試的目的，然后會介紹最常見的9種Web性能測試的方法，希望讀者通過這些方法，對性能測試有深度的認識。
5.1.1 Web性能測試的目的
進行Web性能測試的目的很簡單：
獲得Web應用的性能表現情況。
發現并驗證、修改Web應用中影響性能的Bug。
為網站性能優化提供數據參考。
實際所做的一切測試工作都要圍繞這3個目的來進行，這樣才不會在出現這樣或那樣困難的時候迷失方向，導致資源浪費。
5.1.2 Web性能測試方法的先決條件
對于性能測試方法，在某種意義上說，就是性能測試的分類。不同的性能測試分類，決定了需要采用不同的性能測試方法。Web性能測試也是如此。
不過在介紹具體的分類或者方法之前，有必要強調一下進行Web性能測試的先決條件。其實，從前面的章節，我們已經能夠發現，進行Web性能測試的先決條件有這樣幾條：
一個穩定的Web應用版本。該版本必須與投入生產環境的版本極其類似。這一點的原因在前文也介紹過，對一個最終不會上線運行的版本，或者功能沒有完成的版本進行性能測試是沒有多大意義的，除非為了演練性能測試方法本身。
性能測試所處的測試環境，必須獨立于開發環境，并且盡量類似于實際生產環境。這一點也很重要，測試環境必須是可比較的，大致擁有相同的參照物（比如CPU、硬盤速度等），這樣的測試結果才更有參考價值。
當然，小白在今后這3章所做的性能測試，是為了在個人電腦上方便快速地了解性能測試方法，熟悉性能測試軟件，并不打算將測試報告發送出去形成結果。對于小白和我們一般的初學者，這不失是一個好的學習方法。但是，在真正的性能測試工作中，對于上面的兩個Web性能測試（也可以推廣到所有的軟件性能測試上面），一定要記牢。
下面將介紹Web性能測試方法的具體內容。
5.1.3 Web性能測試的詳細分類
在第2章中曾粗略地講到性能測試包含性能測試方法（狹義的）、壓力測試等，現在可以將絕大部分文檔中提到的眾多分類列舉出來了，它們是如下9種：
性能測試（Performance Testing）；
壓力測試（Stress Testing）；
負載測試（Load Testing）；
并發測試（Concurrency Testing）；
配置測試（Configuration Testing）；
耐久度測試（Endurance Testing）；
可靠性測試（Reliability Testing）；
尖峰沖擊測試（Spike Testing）；
失敗恢復測試（Failover Testing）。
看起來分類很多，但它們實際上都是為了性能測試的目的：考察應用對于系統性能的影響狀況。因此，它們的區別只在于考察系統性能的角度不同。角度決定方法，這正是本節開始時將性能測試方法和性能測試分類基本劃等號的原因。
5.1.4 性能測試（Performance Testing）
在介紹性能測試具體方法之前，首先說明一下性能測試（總稱）和性能測試（方法）的區別。我們也分別把它們叫做廣義性能測試和狹義性能測試。
【廣義性能測試與狹義性能測試】
廣義性能測試包括前述所有分類或方法，以考察Web應用對于系統性能影響狀況為目的的測試活動。而狹義性能測試則是其中的一個小分類，為了區別廣義性能測試中的其他分類。這種測試也是廣義性能測試中最基本的方法之一。利用第一章所講過的維恩圖，廣義性能測試和狹義性能測試之間的關系如圖5-1所示。
圖5-1 廣義狹義性能測試的包含關系
聽起來有些混淆，但對于我們要從事實際工作的人來說，名詞并不重要，只需要知道有性能測試這樣的總稱（廣義），還有性能測試這樣的方法（狹義）即可。在看相關參考文獻的時候，根據上下文一般能很容易判斷出當前所指的性能測試是狹義還是廣義。
本書中凡是"Web性能測試"這樣的字眼，都是指的廣義性能測試，特此說明。
【性能測試】
性能測試（英文名稱也是Performance Testing）是這樣一種方法：它通過模擬實際生產環境中運行的軟件平均業務量，測試系統的性能是否滿足設計說明書中的性能要求。性能測試方法在所有前述9種方法中是一種最基本、最常見的測試方法。這就是說，它是實施性能測試所必須進行的一種方法。
5.1.5 小白的第一次性能測試
為了盡快熟悉這種方法，小白決定利用自己電腦和公司網站的測試版本來做一次手工性能測試的實踐。
一般來說，在網站尚未上線的期間內，網站的技術部門都會維護一個或幾個網站的測試版本，方便開發工程師和測試工程師開展工作。即便是網站上線以后，也會繼續維護這樣的網站，以方便網站每日更新時的調試，待沒有問題后再正式上傳到生產環境中。這種結構如圖5-2所示。
圖5-2 網站正式版本與測試版本關系示意
對于小白的第一次性能測試，該如何選擇測試所針對的網站版本呢？有兩點需要考慮：
由于網站正式版本尚未發布，目前還沒有正式版本可供選擇。
即使正式版本發布也不能直接使用它來測試（因為這樣會影響用戶的使用）。
根據以上兩點，選擇圖5-2中的穩定測試版本。
截至目前為止，小白所知道的僅僅是打開網站的響應時間，所以他想從這個時間入手，來評估一下網站測試版本的性能。他是這樣進行測試的：
打開瀏覽器，輸入網站測試版本的網址，按下Enter鍵，并記錄此時的機器時間。
在網站全部打開后再記錄一次當前機器時間。
兩者相減，得到一個時間間隔。
重復多次，最后計算平均時間間隔。
對比網站的設計說明書，在那里一般都會有以響應時間為標準的性能要求。
根據兩者數值的比較，決定網站測試版本的性能好壞。
【有關時間的記錄】
在性能測試過程中，往往免不了進行當前時間的記錄，或者計算兩個時間的差值。由于Windows系統任務欄中的時間數字較小，讀者可以在互聯網中尋找一些顯示桌面時鐘的免費軟件（顯示時間最好可以包含秒數以達到精度要求）。當然，這樣的時間記錄是依賴于肉眼，精度依然不夠高?？梢酝ㄟ^編程的方法來獲得更精確的時間。
雖然小白所列出的上述測試過程看起來與用戶瀏覽網站沒有什么不同，而且，也看不到使用哪些高級的工具軟件，但它確實是一次人工的性能測試。性能測試真的都是這么簡單嗎？小白非常好學，進而思考了下列幾個問題。
5.1.6 小白的思考
在第3章中我們已經知道響應時間，并且知道用戶所感覺的響應時間并不很準確。那么，小白這次測試應用了計算機時間等"高科技"計時裝備，是否就意味著準確呢？
1．響應時間的問題
其實，對于感覺和記時兩種方法，響應時間數值都是差不多的。那么，訪問Web應用，多長的響應時間說明性能比較好呢？實際上依賴于幾條標準。
軟件設計說明書中的標準：根據用戶的需求，一般都會列出。
不成文的習慣標準：如果在設計說明書中沒有列出，那么可以參考國外的業內公認標準，即3/5/10原則。
在3秒鐘之內，頁面給予用戶響應并有所顯示被認為是"不錯的"。
在3～5秒鐘內，頁面給予用戶響應并有所顯示被認為是"好的"。
而5～10秒鐘是可以"勉強接受的"。
超過10秒鐘就有點讓人不耐煩了，用戶很可能不會繼續等待下去。
在盡可能合理的情況下，響應時間應該越快越好。
另外，響應時間包含了網絡傳輸數據的時間、DNS記錄查找時間和真正由網站服務器處理的時間，因此，遇到時間間隔很長的情況時，首先要排除前兩個時間的影響。
另外，還有很重要的兩點不能忽略：
小白只是以一個用戶的身份去訪問網站的測試版本，而網站一旦投入使用，真實情況是會有上萬人同時訪問它，那么響應時間還會有現在這么好嗎？
小白是在公司內部進行測試的，要知道公司內部的局域網一般都是百兆、千兆網，速度非?？欤蝗绻麚Q到家里，用ADSL之類的上網條件，響應時間還會如此快嗎？
這幾個問題都說明小白的這次性能測試確實欠缺很多因素。不過，這正是我們在下面的章節要學習的。
2．測試場所和指標的問題
小白在進行測試的時候，記錄的是自己電腦上的時間間隔，從它數值的大小來間接判斷服務器端性能的好壞。那么，能不能直接獲得服務器端的性能數據，豈不是更加精確嗎？
是的，完全可以。響應時間所帶給人的只是性能好壞的大概印象，如果要更加專業的測試性能，需要獲取服務器端的指標數據，我們管這些指標叫做性能計數器（Performance Counter），在第6章，我們將重點介紹它們的單個含義以及獲取方法。
綜上所述，小白基于目前理解的第一次性能測試有了結果，雖然過程遠遠不夠，但也讓我們體會到了性能測試所關注的要點，進行的大致過程。簡單地說，Web應用的性能測試方法，就是通過模擬若干用戶對于網站的訪問，獲得性能計數器和其他指標的數據，再分析它們以進行性能評估，使得關注性能測試的各方對系統性能有基本的認識。
5.1.7 壓力測試（Stress Testing）
相對于前面性能測試方法的普通，壓力測試（Stress Testing）方法可以說走了一個極端。它測試Web應用在事先規定的某種飽和狀態下，比如CPU處于75%利用率的情況下，系統是否還具備處理業務的能力，或者系統會發生什么樣的狀況（出現錯誤？系統宕機？等）。
一句話，壓力測試是考驗一個系統的抗壓能力的：在當前比較大的壓力下，它能否承受得住。壓力測試的目的是為了測試Web應用的穩定性。
【壓力測試與體操比賽】
在體育比賽場上我們可以看到生活中的壓力測試，例如體操比賽中的規定動作環節。場上選手在比賽時，其動作組合必須包含組委會所設定的所有規定動作，如圖5-3所示的經典規定動作--托馬斯全旋。通過在這樣的條件下比賽，裁判來考察運動員的完成質量，由于動作難度系數基本一致，重點將是完成質量的穩定性。通過這個類比，壓力測試就很好理解了。
圖5-3 類似壓力測試的體操規定動作比賽（圖中動作為托馬斯全旋）
壓力測試方法有如下的兩個特點：
?。?）壓力測試方法的目的是測試系統（本書中為Web應用）的穩定性。人們對很多軟件系統都有這樣一個經驗：當系統處于較大壓力的時候，如果還能夠維持正常工作，那么，就能說明它在壓力不大的一般條件下，具有長時間正常工作的能力。從這里可以看出，壓力測試方法有一點“一葉知秋”、“以小見大”的含義在其中。
（2）壓力測試方法的具體操作過程是通過對系統施加負荷（模擬用戶對Web應用的訪問等），使系統的資源占用保持在一個事先約定的水平（比如前文所提到的CPU占用率75%），來檢驗此時系統的表現。測試的重點在于系統對于用戶的響應時間變化、系統是否出現錯誤甚至崩潰等。
5.1.8 負載測試（Stress Testing）簡介
在實際工作中，負載測試方法和壓力測試方法往往被放在一起談論，因此很容易混淆，其實它們的區別是很明顯的。
【負載測試方法】
負載測試（Load Testing）方法通過在被測試系統上不斷增加負荷，直到事先選定的性能指標（比如響應時間），變為不可接受或系統的某類資源使用已經達到飽和狀態。負載測試方法實際就是一個不斷加壓，直到找到系統不可用臨界點的過程，形象地說，那一點正是“強弩之末”。
【負載測試方法與舉重比賽】
在5.1.7節我們把壓力測試和體操比賽的規定動作相類比，在這里我們將負載測試方法類比為舉重比賽，如圖5-4所示。在比賽中，選手不斷地增加重量，挑戰自己的極限，直到杠鈴加到某一個重量時，3次試舉都失敗。這一重量就是舉重比賽的最終結果。
圖5-4 舉重比賽與負載測試有相同之處
通過負載測試方法，我們可以發現系統的處理極限點在哪里。
5.1.9 負載測試的特點
負載測試方法有如下幾個特點。
?。?）它的主要目的在于找到系統處理能力的極限，為系統進一步優化做參考。另外，這種測試也可以用來比較不同的優化方法對于性能極限的提升，因此也可以稱之為可擴展性測試（Scalability Testing）。這個名詞可以用圖5-5清晰地表述出來。
在圖5-5中，2條曲線分別代表兩種優化方法經歷負載測試的結果。A方法的性能極限在A點，B方法的性能極限在B點。根據負載測試的定義，比A、B兩點值小的部分都是系統的安全運行區間。由于B的數值要大于A，說明采用B方法優化，系統的可擴展性提高了。
圖5-5 負載測試用于優化方法的比較：B好于A
（2）負載測試方法的操作是一個不斷加壓的過程。負載測試方法是一個"性能指標記錄--增加負荷"的操作循環，直到預定被關注的性能指標不再令人滿意。這個極限點在測試結果中的表示類似這樣的形式："在給定條件下當前Web應用將最多允許10000個并發用戶訪問"、"在給定條件下當前Web應用最多能夠在1分鐘內處理1000次用戶對數據庫的修改"等。常見的在負載測試方法中被關注的性能指標包括：Web應用的響應時間、Web服務器平均CPU利用率等，它們的具體數值需要根據實際情況來調整。
?。?）負載測試方法要考慮被測Web應用的實際業務負荷量與正確的使用場景，以保證測試結果具有參考價值。
【實戰演練：教訓】
在這方面，筆者的同事曾經有一個教訓。有一個網站，可以通過Web直接訪問，也可以通過RSS進行訂閱。在網站發布之前，網站技術部門的所有工程師都認為絕大部分用戶都是通過Web來訪問的，因此，在時間緊迫的情況下，重點測試了Web訪問的性能，對于RSS相關代碼測試的就很少。結果在網站上線之后，他們驚奇地發現，大部分用戶訪問都是通過RSS來完成的，因為負載測試做的很簡略，結果每過多久服務器就被拖的幾乎無法訪問了。可見，對于負載測試，乃至整個性能測試而言，模擬真實的應用場景是多么的關鍵。
?。ㄎ赐甏m）
相關鏈接：
捉蟲記--大容量Web應用性能測試與LoadRunner實戰(連載一)
捉蟲記--大容量Web應用性能測試與LoadRunner實戰(連載二)
捉蟲記--大容量Web應用性能測試與LoadRunner實戰(連載三)