整體性能測試剖析

整體性能測試剖析

作者: 陳衛俊    來源:51testing

【摘要】性能測試不只是測試人員的事情，只有通過不同階段不同參與人的通力合作才能把性能測試做好。

【關鍵詞】性能測試性能優化 DBA

隨著項目越來越大，性能問題層出不窮。如何做好性能測試成為測試人員經常討論的話題。很多時候，大家都在疑惑性能測試如何來做，性能標準從那里來，有沒有通用的標準，性能測試由誰來做，如何規劃。首先我們了解一下，什么是性能測試。性能測試的目的：通過性能測試了解系統的性能有沒有滿足需求，對于不滿足需求的模塊則通過測試發現可能的性能瓶頸，并進行相應的性能調優，從而達到最終用戶的要求。由于項目巨大，所以性能測試不僅僅是測試人員的事情，可能需要整個項目組的參與，而測試人員則更需要清晰的了解到性能測試分幾個階段，每個階段如何來做，需要協調那些資源？

在性能測試的每一個階段，性能測試的參與人是不一樣的，下面的圖就是不同階段的人員參與表。

性能測試人員圖

從上圖中可以看出，其實性能測試不是一個人可以搞定的事情，在需求階段，制定性能初步的標準則需要需求人員的協助，了解那些場景是重要的，大約有多少人用，有多大數據量；而在設計場景時不僅要從需求中設計出必需要測試的場景，有時候需要通過功能測試人員了解，他們在測試過程中那些場景運行的比較慢。而運行腳本時，則需要SA（System Administrator系統管理員，編者注）,程序員幫你增加分析所需要的性能指標，而DBA（DataBase Administrator數據庫管理員，編者注）則增加數據庫監控的參數。在分析結果的階段則需要三者相互靈活的配合，當發現性能問題時，可能會根據程序員或DBA的要求，不斷的調整監控的參數，以便更精確的定位問題。而在優化階段，則是找出性能的瓶頸并優化，更需要多方的配合，不僅僅是測試。

在性能測試前期，也就是上圖的前三個階段，重點需要了解，系統有那一些重要的功能模塊，大約的用戶是多少，用戶的行為是如何分布的，每個模塊的使用頻度，大約的數據量，使用什么樣的硬件，系統穩定性的要求等等。當然需求人員不是專業的測試人員，這時專業性能測試人員就是跟據需求人員大致的描述或是文檔，提取出這些重要信息，建立系統模型。下面的一份表就是某個大型系統郵件模塊的數據模型：

某模塊數據模型圖

上表中可以分析出此郵件系統中最主要的應用是webmail,smtp,pop，其中webmail方式大約為活躍用戶的70%,而其它方式則占30%,同時它還給出了平時的參數指標，與峰值的時間與指標。這樣你后面的場景設計則重點會很清楚，三種方式是測試的重點，用戶的分布也很清晰。從上表中還可以看出，此場景的需求人員做了大量的細致的性能分析工作，在國內這樣專業的需求人員不是很多，有時候只能靠性能測試人員不斷的溝通來獲得必要的性能信息，同時在這個階段也最好與有經驗的架構師多溝通，了解系統可能存在的性能瓶頸，以便使自己設計的場景更有針對性。

場景設計完成之后就進入了腳本的編寫，在這個階段，主要是性能測試人員的程序能力。在這一方面，測試工具是比較多的，我所熟知的就有ACT，WAS，LoadRunner等工具。從原理看，其實都是一樣的，不過如果是測試復合協議的應用，LoadRunner 則是首選，特別是在幾個協議同時使用的應用，比如類似于QQ這樣的應用可能會用到多個協議來進行錄制。其實在錄制腳本的第三個階段也是需要跟程序員配合的，比如在錄制web應用程序中，對session,cookie的處理，對業務上一些請求的處理,這些都需要程序員協助，同時他們也能夠幫你確認某一階段，用什么樣的技術，選什么樣的協議，從而幫助你更好的編寫模擬應用場景的腳本，在這里測試人員經常會認為只要掌握了工具就行了，其實在這里需要很好的編程功底,希望大家多多關注這些腳本的編程，而不是用一兩個工具。

腳本的運行與監控，還有分析結果也是重中之重，在運行時，可能會跟據不同的應用選擇監控的參數，比如在程序運行中，是否有大量的IO讀寫，網絡交互，或是線程切換，在數據庫，是不是有大量的邏輯讀寫的操作，或是執行頻度特別高的SQL執行，這些有可能你是了解的，但是如果身邊有DBA的專家，與架構師，他們會更了解應用程序的性能瓶頸，會需要一些有效的監控指標，這時你在選擇性能監控指標時，要多聽他們的意見。特別是發現性能問題時，可能需要程序員與DBA參與進來時，再次運行場景時，更需要增加一些他們認為可能出問題的監控指標。當然作為測試人員也要了解，這些指標的異常，可能是由于應用程序那一方面不合理的，為研發提出合理的意見。

發現問題后就是tuning ,這也是性能測試最終的目的，發現性能問題，并進行解決。前面的幾個階段，可能是只定性的發現問題，而如可精準的發現問題，則需要扎實的編程功底。對于代碼的tuning有如下原則，發現占用時間最長的函數，而不是優化性能不合理的函數。在對代碼的tuning中，你可以借助代碼分析工具，下面就是IBM-Quantify執行后的圖：

可能大家使用這個工具時會覺的暈，其實我第一次用時也暈的N次，其實用多了很簡單的，工具都是相通的，在這里只要把握程序的脈絡，就好像庖丁解牛，最主要是關注程序占用時間最長的函數和調用次數最多的函數，只有對這樣的函數進行優化才能事半功倍，而一些程序員往往喜歡優化算法不合理的函數，費了九牛二虎之力，卻發現效果并不是很好。在這一階段經常會碰到以下一些情況：

程序調用數據庫接口函數時發現時間過長；
初始化一些事務的次數過多；
某一些函數調用次數過多；
有一些不應當出現的異常函數出現。
對于上面的第一種情況，一般是數據庫可能是某一些SQL的效率不高，你可以與有經驗的DBA把這段應用的SQL取出來，進行分析，確認一下是不是數據庫的問題。其實在優化的過程中，數據庫的優化是最簡單的，不需要修改任何程序，而且效果往往是最好的。第二種情況，一般最大的可能是程序員把事務寫在了循環的里面，造成了N多次的重復對事務的構建，眾所周知分布式事務的構建是最消耗性能的，所以一般不要放在循環的里面。對于第三種情況可能性就更多了，調用次數多不代表錯誤，但如果性能因此大受影響，則是不被提倡的。第四種情況，就可能是一些什么不合理的異常出現所導致的，可能就是缺陷。在這個階段由于要閱讀成千上萬的代碼，即使你的能力超強，也是不可能完全了解了，所以當發現可疑的代碼時，應與當事人一起去剖析這段代碼，要耐心的分析每一種可能。有時候，這個活比技術還難做，如何在不傷到別人情感的情況下給別人指出錯誤，這可是測試人員最大的挑戰，從技術上，到人的心理都要有所把握。雖然這一階段難度比較高，但看到產品經過自己的努力，越來越快時，你會感到無限的成就感。

最后只想再說一下，性能測試是一個團隊的事情，不是某一種角色可以完全承擔的，測試人員在每一個階段要善于借用團隊的力量，協調著做，同時也要不斷提升自己的技術，只有不斷的努力，幫助研發成功，才能得到在大家的尊重。

原文轉自：http://www.kjueaiud.com