應用系統性能測試六大步(2)

　　一是數據的準備。數據準備一定要關注數據的質量和數量，不要出現一些不符合業務邏輯的廢數據，并且數據量要滿足測試運行的需要。例如測試需要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組件，改為由應用自身控制，盡量減少了大事物的出現概率，并同業務部門商議，降低了模糊查詢操作的次數。在后來再做“性能評測”時確認系統達到了預期目標。

原文轉自：http://www.uml.org.cn/Test/200809046.asp