性能測試是產品測試流程的必經之路，產品性能的好壞不但關系到產品的用戶體驗，對于像電子商務這一的應用來說，性能的好壞直接關系到客戶的網(wǎng)站是否有好的用戶忠誠度，從而也就影響到訂單轉化率等跟客戶盈利直接相關的指標。

客戶與用戶

客戶指的是購買我們產品的企業(yè)，他們購買了產品之后，經過定制上線，展示給最終的用戶來使用。因此客戶非常關心用戶的使用感受，因為這直接決定他們的網(wǎng)站或者終端是不是受歡迎，能不能留住用戶。

對于一個應用服務的性能來說，客戶的關注點：

頁面/客戶端的響應時間： 直接影響最終用戶的使用體驗，在很大程度上影響用戶忠誠度

服務器的吞吐量：系統(tǒng)每小時處理的業(yè)務量

最大并發(fā)用戶數(shù)：在響應時間合理的情況下，能夠承受的并發(fā)用戶數(shù)

是否能穩(wěn)定的長期運行，最大數(shù)據(jù)規(guī)模等。

如何理解性能測試？

簡單的說，就是給系統(tǒng)一些壓力，看系統(tǒng)跑得快不快，好不好。說得文一些，就是讓系統(tǒng)工作在一定的負載狀態(tài)下，把系統(tǒng)工作的性能指標與期望的性能指標相比較。

性能測試策略和方法的出發(fā)點，就是要模擬客戶對系統(tǒng)的訪問行為，包括并發(fā)、壓力、長時間的訪問等。

性能測試的分類：

客戶端性能測試：關注用戶體驗，即訪問應用程序時的響應時間。

服務器端性能測試：注重在不同負載條件下的應用程序的健壯性。

性能測試的類型：

壓力測試：

限時搶購，是一種短時間內把系統(tǒng)負載壓到極限的例子，測試時，一般通過壓力測試來模擬。

壓力測試主要考察讓系統(tǒng)運行在比較大的負載條件下的性能表現(xiàn)。可以發(fā)現(xiàn)系統(tǒng)工作在多任務并發(fā)情況下可能出現(xiàn)的性能問題。由于壓力測試下系統(tǒng)工作在非常高的負載情況下，所以衡量性能運行指標一般為吞吐率和錯誤率，而不包括響應時間。

壓力測試的目的：

發(fā)現(xiàn)并解決在并發(fā)、長時間運行或者大量數(shù)據(jù)情況下才出現(xiàn)的系統(tǒng)缺陷，如數(shù)據(jù)庫死鎖，代碼級死鎖，內存泄漏等。

在指定并發(fā)用戶數(shù)下是否能達到吞吐率目標。

從上述兩個方面可以得知，壓力測試按照目的的不同可以分成兩類：

系統(tǒng)的性能瓶頸：通過標準是系統(tǒng)在CPU運算能力飽和狀態(tài)下（CPU占有率大于95%）的吞吐率和錯誤率。

系統(tǒng)的崩潰點：不關心具體的吞吐率和錯誤率指標，關注考察吞吐率、錯誤率指標與負載關系曲線。

--->什么是吞吐率？

通常吞吐率是指應用系統(tǒng)在單位時間內實際處理的交易數(shù)量（交易吞吐率）或頁面點擊數(shù)量（頁面點擊吞吐率）。

壓力測試通過的標準：

在承受指定負載的前提下，系統(tǒng)的吞吐率是否達標、并發(fā)用戶數(shù)是否達標、出錯率是否達標。

吞吐率測試往往可以用于產品新舊版本之間的比較試驗。比如，在新版本增加某個新功能之后，你想驗證新功能的引入會不會對性能產生負面的影響，就可以通過在相同的硬件條件下做吞吐率的比較試驗來確認。

響應時間測試：

響應時間測試是另一個常見的衡量系統(tǒng)快慢的運行指標。一般來說，響應時間越短越好。

響應時間測試測的是在正常負載狀態(tài)下，被測系統(tǒng)的服務器端和客戶端響應時間（不考慮外部網(wǎng)絡傳輸影響）。即，響應時間的測試結果更接近通常狀態(tài)下系統(tǒng)真實性能表現(xiàn)。

響應時間測試的目的：正常負載（CPU使用率50%左右）前提下，保證服務器或者客戶端的操作響應時間不超過規(guī)定的標準。

--->網(wǎng)頁響應時間的組成：在網(wǎng)絡上傳輸數(shù)據(jù)、在服務器端處理、服務器將響應數(shù)據(jù)傳回到客戶端、在瀏覽器中顯示。

在網(wǎng)絡上數(shù)據(jù)傳輸?shù)臅r間取決于頁面數(shù)據(jù)量的大小、網(wǎng)絡速度和網(wǎng)絡上的擁擠程度。

在瀏覽器中顯示的時間取決于客戶端程序(JavaScript, Dojo,Flash等)的復雜程度以及運行瀏覽器的客戶計算機的處理速度。

可靠性測試：

可靠性測試一般選取系統(tǒng)日常處理的平均負載，其評估的性能指標通常是響應時間、錯誤率和系統(tǒng)資源占用率。為了更好地發(fā)現(xiàn)問題，一般可靠性測試的測試周期都比較長，比如壓力測試執(zhí)行3小時，對應可靠性測試可能需要執(zhí)行72小時甚至更長時間。

可靠性測試的目的：

評估長時間的性能指標是否滿足要求，往往考察平均值。

考察性能指標的變化趨勢，發(fā)現(xiàn)可能存在的內存泄漏、性能下降等于執(zhí)行時間相關的性能問題。

考察某些維護性操作是否會對前臺用戶訪問的性能造成大的影響。

可擴展性測試：

可擴展性測試(Scalability Test)是驗證被測試系統(tǒng)隨著計算能力的擴展是否能夠承受更大的負載。負載的增大包括數(shù)據(jù)規(guī)模、業(yè)務種類、數(shù)據(jù)復雜度等。

可擴展性測試的目的：

針對系統(tǒng)在某一個負載方向上的可擴展性，通過一組測試評估系統(tǒng)在不同負載下的性能情況，從而分析系統(tǒng)在此負載變化方向上的可擴展性。

在不同的負載下衡量系統(tǒng)響應時間或吞吐率的變化趨勢。

--->任何性能指標的好壞，除了與軟件本身的并發(fā)性能好壞有關，還在很大程度上取決于硬件系統(tǒng)的處理能力。

性能測試流程

編寫性能測試計劃--設計與實現(xiàn)測試用例--執(zhí)行測試--性能問題確定與調優(yōu)--編寫測試報告

制定性能測試計劃：

內容：

開始的必要條件，即開發(fā)人員、其他類型測試人員為了保證性能測試順利進行而必須做的工作。

退出條件，定義什么時候性能測試結束，通常與產品的質量控制標準有關。

目標與范圍，目標往往直接來自于用戶需求規(guī)格說明書中的非功能性需求描述。

測試用例，包括測試場景的描述、輸入/輸出描述。

--->性能需求的來源:

性能需求根本上應該來自實際用戶的需求，對于有明確性能指標定義的描述都應該在測試計劃中制定相應的測試用例，量化的性能指標應該成為制定測試用例通過標準的依據(jù)。

以前版本的用戶缺陷報告

行業(yè)的質量標準

由于硬件/軟件版本升級帶來的性能提升測試需求

--->一個完整的測試用例描述如下：

測試場景，描述待測系統(tǒng)處理的業(yè)務內容，或者說測試用戶所執(zhí)行的業(yè)務操作<---->系統(tǒng)交互的角色/角色所執(zhí)行的業(yè)務流程。

測試負載和通過標準，并發(fā)用戶數(shù)、思考時間、測試持續(xù)時間等。通過標準包括吞吐率、頁面響應時間、資源占用率通過標準。

測試數(shù)據(jù)規(guī)模，測試數(shù)據(jù)的設計應該從實際用戶的需求出發(fā)。

待測系統(tǒng)軟/硬件配置和拓撲結構，測試計劃中應明確描述操作系統(tǒng)版本在內的所有測試相關軟件版本信息、硬件平臺和詳細配置信息及系統(tǒng)的拓撲結構。

性能測試一般不會涵蓋系統(tǒng)所支持的所有可能的功能場景，設計測試用例的原則之一就是用盡可能小的測試場景覆蓋盡可能多的測試目標。

測試用例設計不合理有可能導致測試結果的無效性，進而引起測試返工甚至有可能發(fā)現(xiàn)不了系統(tǒng)性能缺陷。

執(zhí)行測試：

執(zhí)行測試從測試用例的實現(xiàn)開始，包括測試腳本和測試數(shù)據(jù)集的開發(fā)、測試執(zhí)行、測試過程中的系統(tǒng)監(jiān)視、收集測試結果、分析測試等。

性能測試的特點決定了性能測試的執(zhí)行與其他類型測試相比要復雜得多。性能測試執(zhí)行過程中至少要監(jiān)視待測系統(tǒng)各方面的運行狀況，所以性能監(jiān)視技術是性能測試人員必備的技能。

一個明確的測試執(zhí)行清單有助于測試執(zhí)行過程的規(guī)范化，且測試執(zhí)行清單應該像測試腳本和數(shù)據(jù)一樣被實時和定期維護。

與功能測試不同，性能測試結果如果不滿足通過標準不一定是應用系統(tǒng)本身的缺陷，因此，執(zhí)行測試用例得到的結果需要進行分析。

執(zhí)行測試的步驟：

1. 熟悉測試計劃與測試用例：由于性能測試的復雜性，反復閱讀測試計劃中隊測試方法和測試用例直至徹底理解是開始執(zhí)行測試的前提。

2. 搭建或檢驗測試客戶端：性能測試的運行通常需要依賴于一定的自動化測試工具或框架，測試工具通常運行在測試客戶端的計算機上，并檢驗客戶端的相關配置是否滿足要求。

3. 搭建或檢驗測試服務器環(huán)境：待測系統(tǒng)的軟/硬件配置及正常工作狀態(tài)時得到有效測試結果的前提。

4. 設置調優(yōu)參數(shù)：不要因為片面追求調優(yōu)帶來的好的性能而掩蓋了應用程序代碼本身的性能問題，因此，參數(shù)調優(yōu)應該只作為一種必要的輔助手段。

5. 編寫或校驗測試腳本和數(shù)據(jù)：測試腳本的執(zhí)行需要配合測試所需要的數(shù)據(jù)。

6. 預熱執(zhí)行及逐步增加并發(fā)用戶負載：預熱執(zhí)行還可以彌補自動測試數(shù)據(jù)生成工具的不足。對于大并發(fā)用戶數(shù)下的壓力測試一般不采用將大量并發(fā)用戶同時開始的方法，而是采用從少到多逐步增加的方式。

7. 配置監(jiān)視工具：在測試執(zhí)行清單中應該對各種類型的測試需要對監(jiān)視工具做何種配置有明確規(guī)定。

8. 執(zhí)行測試：定期通過監(jiān)視工具檢查服務器和測試客戶端的運行狀態(tài)，同時注意監(jiān)視工具的開銷。

9. 收集、分析測試結果并整理測試報告：不論測試是否通過，都應該按照測試執(zhí)行清單的要求收集各種結果信息。收集測試失敗的日志反而對于分析解決問題至關重要。

--->測試系統(tǒng)的性能監(jiān)視一般有性能測試人員或開發(fā)人員進行。測試系統(tǒng)的系統(tǒng)運行時間短而壓力大。

--->生產系統(tǒng)的性能監(jiān)視一般由系統(tǒng)維護人員進行。系統(tǒng)長時間運行，出現(xiàn)性能問題的可能性較小，但一旦出問題，產生的影響大。

以上兩種系統(tǒng)上進行性能監(jiān)視的目的都是為了盡早地發(fā)現(xiàn)性能問題。

性能監(jiān)視一般采取從前到后的監(jiān)視順序。監(jiān)視系統(tǒng)的性能運行指標，在測試環(huán)境中一般通過測試工具進行。找到問題出現(xiàn)的時間點往往很重要，因為系統(tǒng)日志很多時候是先從引起問題的根源處開始記錄出錯的。

一般來說，基于應用服務器的系統(tǒng)一般需要做以下幾個級別的監(jiān)視：操作系統(tǒng)級別，數(shù)據(jù)庫級別，應用服務器級別

操作系統(tǒng)的監(jiān)視

監(jiān)視各種系統(tǒng)資源的使用狀況：CPU占用情況，內存占用情況，I/O使用情況

--->當系統(tǒng)性能出現(xiàn)瓶頸時，查看系統(tǒng)的I/O情況也是確定問題的重要手段。

數(shù)據(jù)庫的監(jiān)視

使用DB2快照監(jiān)視其時，一個典型的過程如下：

a. 首先查看數(shù)據(jù)庫監(jiān)視對象開關狀態(tài)

1

db2 GET MONITOR SWITCHES

b. 查看數(shù)據(jù)庫管理系統(tǒng)監(jiān)視對象開關狀態(tài)的命令

1

db2 GET DBM MONITOR SWITCHES

c. 打開指定的數(shù)據(jù)庫監(jiān)視對象開關的命令

1

db2 Update MONITOR SWITCHES USINGswitch-name ON/OFF

可以一次打開一個或多個開關

1

db2 Update MONITOR SWITCHES USING LOCK ON BUFFERPOOL ON

d. 再執(zhí)行

1

db2 GET MONITOR SWITCHES

此時，會發(fā)現(xiàn)緩沖池監(jiān)視開關和鎖的監(jiān)視已經打開了

e. 執(zhí)行命令

1

db2 GET SNAPSHOT

---> 數(shù)據(jù)庫上發(fā)生死鎖是并發(fā)訪問時很常見的問題，尤其是壓力測試用例這種比較極端的用例。因此監(jiān)視死鎖也是對數(shù)據(jù)庫監(jiān)視很重要的一部分。

有時候沒有出現(xiàn)死鎖問題，而僅僅是懷疑某些操作使用的SQL語句不合理，因此可以監(jiān)視特定操作使用的SQL語句。

性能問題定位的一般策略

確定性能問題一般有自頂向下分析和自底向上分析法。

自頂向下分析：指將應用系統(tǒng)劃分為若干部分，采用排除法或歸謬法首先確定問題出現(xiàn)的位置，然后再這個部分尋求問題的原因和解決方案。自頂向下分析在確定問題屬于哪一部分的時候，往往采取一種逐漸細分的方法，從比較粗的定位到非常細的功能模塊劃分，它分析重視文體產生的條件，即出現(xiàn)問題之前和出現(xiàn)問題之后的不同，通過對產生問題條件的歸謬確定存在問題的部分。

自底向上分析方法注重問題的現(xiàn)象。通過考察性能問題現(xiàn)象的各種細節(jié)與以往出現(xiàn)問題的現(xiàn)象進行對比，確定性能問題的類型。自底向上分析方法往往直奔問題的日志或其他細節(jié)。

找到性能問題出現(xiàn)的原因，就可以確定問題的解決方案了。并不是所有的性能問題都需要修改程序代碼解決，有些可以通過調優(yōu)性能參數(shù)解決，有些則必須通過修改軟硬件配置解決。

--->既然我們知道性能問題的定位比較困難，在設計測試計劃和用例的時候，對于一些新的功能，如果想要驗證它的性能，最好能讓用例的設計相對獨立一些。換句話說，就是避免多個可能引起性能問題的新功能之間互相影響。

常見問題一覽

并發(fā)：引起并發(fā)問題的原因有很多，大多數(shù)是由多個并發(fā)線程搶奪資源引起的：

等待隊列里的事務出現(xiàn)超時或回滾，從而導致訪問出錯

競爭鎖資源時導致了死鎖

超時：使用監(jiān)視工具得到監(jiān)視結果并分析實際使用的資源數(shù)是否小于系統(tǒng)設置的最大資源數(shù)并作相應提高。

死鎖：出現(xiàn)在多個進程相互持有對方需要的鎖而得不到自己所需要的鎖的情況下：數(shù)據(jù)庫死鎖、進程死鎖。數(shù)據(jù)庫死鎖一般會在應用進程的日志中拋出異常，進程死鎖指線程之間相互占用所需資源而不釋放導致的死鎖。

性能下降主要是指在負載沒有變化的情況下，系統(tǒng)的性能指標隨時間而逐漸下降。

在性能測試中發(fā)現(xiàn)或重現(xiàn)性能下降問題主要是通過可靠性測試用例，即通過較長的執(zhí)行時間發(fā)現(xiàn)各種性能指標的變化趨勢。

應用服務性能下降問題由以下單個或多個原因混合導致：

應用程序資源使用問題，主要是內存使用問題：內存碎片、內存泄漏等

應用程序設計問題，主要存在可擴展性或可靠性問題

數(shù)據(jù)庫訪問問題

性能下降問題中做問題定位的一個重要手段是分段和比較。

性能參數(shù)調優(yōu)是指通過調整配置參數(shù)改進應用系統(tǒng)性能的過程。性能參數(shù)調優(yōu)的最低目標是避免由于不恰當?shù)恼{優(yōu)參數(shù)引起的性能問題。

性能參數(shù)調優(yōu)的基本方法，就是通過反復的系統(tǒng)性能監(jiān)測及分析，以配置參數(shù)調優(yōu)為手段對系統(tǒng)資源進行合理的配置及調整，從而最大限度地提高系統(tǒng)性能，避免潛在性能問題的發(fā)生。

總結

性能測試的設計人員必須透徹理解產品的需求和設計，尤其是設計中關于性能目標的定義，之后設計出能夠有效覆蓋這些性能目標的性能測試計劃。性能測試計劃需要從產品的并發(fā)能力、響應時間、可擴展性、可靠性、安全性等多方面保證產品符合性能通過標準。

與其他測試不同，性能測試過程中不僅要看用例本身的執(zhí)行情況，還要對測試系統(tǒng)和被測系統(tǒng)進行適當調優(yōu)、實時監(jiān)控，及時發(fā)現(xiàn)問題，合理收集所需要的監(jiān)視日志，為后面的性能分析或問題定位做好準備。

作者：Ribbon 出處： http://www.cnblogs.com/Ribbon/ 本文版權歸作者和博客園共有