效能測試是為了保證產品釋出後其效能能夠滿足使用者的需求，本文結合具體案例介紹了應用系統性能測試的六大步驟。

　　在本文介紹的這個案例中，被測應用系統是一家公司的客戶資訊系統，它主要用來錄入、修改以及查詢全球客戶的資訊，並將客戶資訊轉入到業務系統。但是，在應用過程中，客戶經常投訴在某個時刻新建或者修改一個客戶資訊非常慢，正常情況下完成該操作只需要1～5秒，而異常時卻需要10分鐘左右，而且系統管理員發現系統資源使用率都比較低，這種情況的出現並沒有規律性。

　　在這個案例中我們發現了系統存在效能問題，下一步工作就是要在效能測試過程中查詢形成系統瓶頸和故障的根本原因，在此項工作中我們應該按照如下幾個步驟進行。

　　1.確定明確的測試目標

　　效能調優是是無止境的，所以在測試之前應確定一個明確性能調優目標，這也是後面“評估效能驗證”的一個基準，也是測試終止的一個基準。在本案例中目標設定為: 在相同系統環境配置下30個併發使用者在1～5秒鐘內完成各類線上操作。

　　2.測試需求分析

　　效能調優的測試分析主要目的是要挖掘出可能造成系統瓶頸的因素，併為後面的測試用例設計提供保證。影響系統性能有很多種原因，在此應關注如下幾個關鍵點:

　　應用配置需求: 例如應用整體框架、涉及到哪些第三方的元件、應用層與資料庫層的介面、使用了什麼資料庫等。

　　系統配置需求: 例如使用者客戶端配置、客戶端與伺服器

　　使用者使用情況需求: 例如使用者分佈情況; 哪些模組使用者使用比較頻繁; 在使用者操作的資料有哪些特點等。

　　這方面工作是非常繁雜的，而且要求測試人員具有挖掘可能造成系統瓶頸因素的洞察力和敏銳感，但是很多測試人員在接手測試之後，很快進入到測試用例設計階段。實踐證明，這樣做往往都適得其反，要麼工期延期，要麼專案開發失敗。這個過程在測試整體過程中是非常關鍵的一環。效能測試分析有個特點: 它關注的是應用的整體，或者會仔細分析圍繞著應用的各種外部因素，比如說它所涉及到的硬體、第三方軟體，而不會深入到專案具體的內部。這是因為效能測試關注的是專案整體、是一種黑盒

　　3.測試用例設計

　　此過程主要目的是設計出一些合理的場景去驗證在需求分析階段獲得的可能影響效能的因素是否是造成系統瓶頸的因素。測試用例設計一般包括測試策略、測試案例、測試內容。

　　測試策略一般包括對比測試環境與真實的業務操作環境，真實業務操作環境又可能涉及區域網測試環境與機房測試環境等

　　測試案例主要是根據測試需求分析的結果制定出在測試執行時系統的執行方法，比如本案例中“5個人同時錄入不同的新客戶資訊，以及具體的模擬步驟”。在測試案例設計時應注意如下幾點:

　　虛擬使用者的操作步驟要儘量類似於真實使用者的操作。

　　操作的資料要類同於真實使用者實際使用資料，例如在案例中使用者錄入客戶資訊時，根據需求得到的結果，我們可以設計有3～4個虛擬使用者在錄入一些小客戶的資訊，1～2個虛擬使用者在錄入大客戶的資訊等。

　　在案例設計時要充分考慮到需求中使用者對模組的使用頻率。使得在模擬時每個模組使用情況儘量地類似於真實環境。

　　測試內容一般包括併發效能測試、疲勞強度測試、大資料量測試以及系統資源監控等，我們在做效能調優測試時主要是做併發效能測試以及系統資源監控這些方面的工作。從對系統產生併發效能測試過程中監控系統中各種資源的變化，來判斷導致效能瓶頸的原因。

　　4.指令碼開發資料的準備以及測試執行與監控

　　測試執行與監控的主要目的是根據設計方案去驗證系統是否存在瓶頸，給測試分析提供各種分析資料。此過程會與下面的“測試分析”過程不斷進行重複執行，直至真正確定出系統瓶頸所在。

　　筆者認為，在此過程中如果有測試工具能夠滿足測試要求，那麼應儘量使用測試工具，不要手工去開發測試程式，因為做企業專案往往時間緊張，而且測試工具畢竟是一個成熟的產品，在各方面都得到驗證。使用工具將會縮短測試周期，而且現在市場上有很多成熟的測試軟體。例如: Mercury的LoadRunner、IBM的Robot、Compuware的QALoad等。在這個案例中筆者使用的是Mercury的LoadRunner。關於一些技術細節筆者就不再贅述了，在這裡主要提兩點。

一是資料的準備。資料準備一定要關注資料的質量和數量，不要出現一些不符合業務邏輯的廢資料，並且資料量要滿足測試執行的需要。例如測試需要100組資料，但是實際只准備了50組，從而導致測試執行結果出現大的偏差。

　　二是測試執行。除了正確按照設計的要求去設定各種引數之外，還要關注系統是否存在功能問題，這往往成為效能測試的“盲點”。原則上效能測試之前必須確保功能測試已經完備，但是任何事情都不絕對，所以一般做效能測試之初，都會模擬一個使用者去執行設計的場景，主要是確保“測試指令碼正確性”、“在設計的場景中應用系統不存在功能上的問題”。很多效能測試過程往往因為功能問題導致效能測試失敗，或者是測試延期的現象。

　　5.測試分析

　　測試分析的主要目的是要根據測試執行獲取到的資料去判斷造成系統出現瓶頸的位置，挖掘造成系統瓶頸的真正原因。這個過程是技術含量最高的一環，因為在測試執行過程獲取到的資料會涉及到各個方面，在這個案例中就涵蓋了網路方面的知識、系統方面的知識、應用方面的知識等，測試人員需要從這些繁雜的資料中挑出異常，系統越大越複雜在這個方面對測試人員要求會更高。但是這裡面也有一些技巧:

　　在做測試分析時人員組成建議為: 開發人員、系統人員、測試人員共同組成。這樣會在技術上填補個人技術上的不足。實際每個專案涉及到的技術都可能各有不同，對於個人來說不可能每樣都精通。

　　反覆比較一個型別的引數在不同時間的跳躍值，或者不同場景下同一個型別引數的變化。

　　在發現引數有異常變化時，不要輕易下結論，而是要儘量挖掘可能影響這個引數的其他引數值。在長期的測試過程中發現往往發現第一個所謂的瓶頸都是因為其他因素造成的。

　　在測試分析時使用較多的一種方式是排除法，根據開始獲取到的資訊大概能將問題定位在某一層面上。但具體在什麼地方，就可以採取排除的方法去定位。

　　儘量使用一些比較成熟的工具協助分析工作，這樣將大大減輕工作負擔。

　　在確定出真正的效能瓶頸時，可以做一些小的測試模型去做驗證，確定分析的正確性。

　　在本案例中，在測試結果經過各種比對之後，最後確定是資料庫層上出現問題。但是問題究竟出現什麼地方呢?筆者在分析過程中採用了許多排除法，比如更新索引的統計值、將資料庫中的表從頁級鎖改為行級鎖等，但是都效果甚微。

　　所以，我們回到上面看與資料庫層相關的需求:

　　1. 因為業務需要，需要使用很多模糊查詢。此類操作會進行表掃描。為了防止髒讀，會向資料庫申請表級意向鎖。

　　2. 因為客戶關係複雜，所以資料庫設計的時候，存在多表關聯。

　　3. 在應用開發時，我們使用了Hiberate這個元件，這些元件對於開發人員來說是一個黑盒，而且存在一些侷限性: 在更新記錄時會同步更新所有相關聯的表，即使關聯表不需要更新; 同步更新的記錄操作會涵蓋一個事物處理過程中，會產生大事務操作; 無法利用SQL優化技術去優化他所產生出來的SQL語句。

　　研究之後發現: 在進行模糊查詢與大客戶資訊錄入與修改的操作時，由hiberate這個元件產生的大事務SQL導致了資料庫的互鎖，是系統瓶頸所在。為了驗證這一判斷的正確性，筆者做了一個小的模型去驗證。

　　假設庫中有A、B、C三張表，現在有三個虛擬使用者同時在上面進行操作: 使用者Vuser1需要查詢客戶資訊，他只知道客戶的姓氏，所以他採取了模糊查詢; 使用者Vuser2正在修改一個客戶資訊，正準備儲存; 使用者Vuser3正在查詢客戶辦公資訊，也需要模糊查詢。

　　Vuser1操作先得到執行，在表掃描中出現表級意向鎖; 此時Vuser2進來需要修改A、B、C三張表對應記錄，併成功的鎖定了B、C兩張表對應的行(因為是行級鎖)，然後進行了修改，但是無法修改表A，所以Vuser2此時等待Vuser1釋放鎖; 此時Vuser3進來了，需要查詢C表，因為Vuser2並沒有釋放鎖，此時Vuser3也處在等待狀態。驗證顯示，在出現大數量的操作並且在多使用者的操作下，此瓶頸將不斷地暴露出來。

　　6.系統調優與驗證

　　將獲取的分析資料交付到開發組進行調優，經過調優後一般都需要再次進行驗證，驗證主要關注調優後的結果是否解決了所發現的系統性能瓶頸和是否產生了新的效能瓶頸。這方面的工作主要由開發人員來完成。在本案例中，去掉了Hiberate元件，改為由應用自身控制，儘量減少了大事物的出現概率，並同業務部門商議，降低了模糊查詢操作的次數。在後來再做“效能評測”時確認系統達到了預期目標。