在性能測試過程中，明確每個場景的參與者人數、比例和具體行為是非常重要的，這些都是構成性能測試腳本的基礎。根據經驗，可以從應用服務器的日志中分析用戶行為。例如，對于一個OA系統，我們從日志中分析出在上午9:00～9:30時段內有200個查看郵件頁面的page view，且查看時間基本集中在前10分鐘; 而在9:00～9:30時間段內對BUG顯示頁面的查看量是300個page view，對頁面的訪問基本平均分配在整個時間段，則我們可以建立兩個腳本，前一個腳本模擬查看郵件操作(腳本1)，后一個腳本模擬查看BUG操作(腳本2)，考慮運行15分鐘的測試場景，則只需在前5分鐘運行腳本1，在整個過程中運行腳本2，通過調整think time使得page view達到實際的數值即可。
當然，并不是每個不同的用戶應用剖面都需要作為測試場景來設計，在多數情況下，可以通過對測試場景出現的幾率、重要性、風險等進行分析，從而最終確定需要設計的測試場景。明確了場景之后，根據性能測試應用領域的不同，可以采用不同的性能測試方法來達到性能測試的目標。另外需要提醒的是，性能測試設計還應該包括測試環境、測試數據等的設計，因為影響系統性能的因素很多，保持測試過程中環境和數據的可控性是非常重要的。
第三步 第三步性能測試結果分析，是性能測試過程中最困難，也是最重要的步驟。它需要分析人員對測試結果中的各項數據有準確的認識，明確各指標之間的關系。如果各項數據指標間沒有明顯聯系，在多數情況下需要綜合考慮各種因素，才能得出最終結論。
根據經驗，在性能測試過程中最容易發生的問題是數據庫訪問層問題、應用服務器配置問題以及網絡問題。因此建議一般按照“從簡至繁”的原則，先排除網絡問題，其次對應用服務器配置進行分析，然后在數據庫訪問層進行性能分析，重點是索引、數據庫Cache、死鎖等問題的分析。在確認所有這些因素都不是性能瓶頸的情況下，才對代碼進行分析和檢查，找出導致性能問題的因素。
只要看看現代軟件的規模和功能點數就可以明白，功能測試早已跨越了單靠手工敲敲鍵盤、點點鼠標就可以完成的階段。而性能測試則是控制系統性能的有效手段，在軟件的能力驗證、能力規劃、性能調優、缺陷修復等方面都發揮著重要作用。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
