MILY: 宋體; mso-ascii-font-family: 'Times New Roman'; mso-hansi-font-family: 'Times New Roman'; mso-bidi-font-family: 宋體">摘要：本文從性能測試的過程著手，將性能測試過程劃分為性能測試準備和組織、性能測試設計、性能測試結果分析三個階段，并介紹了每個階段的主要工作內容和方法。

       關鍵字：軟件性能測試 性能測試過程 性能測試設計

性能測試的重要性是隨著網絡應用的發展而發展的，在單機應用占據主導地位的時代，軟件性能基本上都可以通過提升硬件配置來改善，而且由于硬件設備的快速更新，軟件性能并沒有成為制約軟件成功的主要因素。而在網絡應用高度發展和吸引用戶眼球越來越難的今天，系統的性能受到應用開發商和運營商的高度重視；但與此同時，由于網絡環境、數據庫環境、應用服務器環境、系統平臺和技術等的復雜性和多樣性，軟件性能又非常難于控制，例如，對一個部署在Internet環境下的Portal來說，由于Internet復雜的網絡環境、無法控制的訪問者等因素，如果沒有好的性能控制手段，要想讓其達到好的性能簡直是天方夜談。    當然，改善系統性能不是單單依靠性能測試就能完成的，需要從需求、設計、代碼到測試的整個過程中貫穿性能工程的實踐，對產品進行全過程的性能控制。不過，到目前為止，性能測試仍然是控制性能的非常有效的手段，在軟件的能力驗證、能力規劃、性能調優、缺陷修復等方面都發揮著重要作用。

       本文擬結合本人的經驗和體會，從性能測試的過程入手，討論性能測試的過程。

1.       性能測試準備和組織

性能測試的準備和組織是性能測試過程的第一步，在這個階段，我們需要明確性能測試的目標和性能測試需求，并組織起合適的人員，制訂性能測試計劃。

一般來說，性能測試的應用領域分為能力驗證、能力規劃、性能調優和缺陷修復四個方面，其中能力驗證表明測試的目的是驗證系統能力是否達到預期的性能標準；能力規劃意味著測試的目的是考察系統的可擴展性；性能調優則表示性能測試的目的是通過性能測試手段，找到系統的性能瓶頸，為性能調優提供依據；缺陷修復應用領域是指通過性能測試手段，找出系統中存在的并發等方面的缺陷。

明確性能測試的目標也就是要把性能測試的目的歸到相應的應用領域，而確定性能測試需求則是要更詳細地確定性能測試的基準。對產品的性能測試需求的來源是軟件需求、設計文檔或是用戶備忘錄等設計和需求相關的文檔。當然，并非所有的性能測試需求都在這些文檔中以明確的方式標識出來了，此時就需要根據不十分明確的文檔描述進行進一步的細化。我們的經驗是在文檔評審時高度關注所有與性能相關的描述，例如“要求操作響應時間小于……”、“要求……能夠快速……”、“要求……能夠支持……用戶訪問”、“要求……能快速穩定運行”等，然后依據表1進行進一步的細化，細化后的測試需求就可以作為測試的依據。

性能測試涉及的設備、環境、技術、工具較多，性能測試人員的組織也必須兼顧這些方面，根據我們的經驗，一個性能測試組最好包括系統工程師（負責測試環境搭建、服務器和應用服務器的配置）、網絡工程師（負責網絡環境的維護和驗證）、性能分析工程師（負責測試計劃的擬定，負責對性能測試結果進行分析，給出性能測試報告）、自動化工程師（負責測試腳本的編寫和測試工具實施），數據庫工程師（負責對數據庫層進行性能問題定位）；在條件允許的情況下，還可以包括開發工程師和客戶代表，輔助對性能測試結果進行分析和確認。

性能測試計劃是用來指導性能測試過程的主要文檔，在測試計劃中除了要寫明本次測試的測試目標、測試需求外，還需要測試計劃中給出明確的測試退出條件和測試的時間和資源計劃。

2.       性能測試設計

與功能測試一樣，測試設計也是性能測試過程中的主要內容。性能測試的測試設計一般基于測試場景（Test Scenario）進行，一個測試場景就是一個用戶的實際使用系統的剖面。例如，對一個用于開發人員工作的OA系統，該系統在每天9:00 - 9:30期間，用戶主要是在執行查看郵件和查看BUG操作，在上午的其他時間主要是修改BUG狀態和處理郵件，則從對該系統的簡單使用分析中，我們至少可以得到兩個不同的應用場景：一個是“用戶查看郵件和查看BUG”場景，另一個是“用戶發送郵件、接收郵件、修改BUG狀態”場景。

在性能測試過程中，明確每個場景的參與者人數、比例和具體行為是非常重要的，這些都是構成性能測試腳本的基礎。我們的經驗是可以從應用服務器如IIS的日志中分析用戶行為，例如，對我們作為示例的這個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達到實際的數值即可。

當然，測試場景的提取需要測試設計人員對用戶的行為和業務有較為深入的了解，并不是每個不同的用戶應用剖面都需要作為測試場景來設計，在多數情況下，我們可以通過對測試場景出現的幾率、重要性、風險等進行分析，從而最終確定需要設計的測試場景。

明確了性能測試包括的場景之后，根據性能測試應用領域的不同，可以采用不同的性能測試方法來達到性能測試的目標。例如，對性能調優和能力規劃應用領域，可以通過配置測試的方法，應用相同的測試場景，針對不同配置的系統進行測試，通過一次性修改少數配置參數或是硬件配置的方法，找到對性能影響最大的因素，從而對其進行優化和規劃。

最后還需要提醒的是，性能測試設計還應該包括測試環境、測試數據等的設計，因為影響系統性能的因素很多，保持測試過程中環境和數據的可控性是非常重要的。

3.       性能測試結果分析

性能測試結果分析是性能測試過程中最困難，然而也是最重要的步驟。性能測試結果分析需要分析人員對測試結果中的各項數據有準確的認識，明確各指標之間的關系。性能測試結果的各項數據指標并沒有顯而易見的聯系，在多數情況下都需要綜合考慮各種因素，才能得出最終的結論。

       根據我們的經驗，在性能測試過程中最容易發生的問題主要是數據庫訪問層問題（未優化的SQL語句和存儲過程）、應用服務器配置問題（不合理的配置）以及網絡問題（狀況差的網絡），因此我們建議的一般原則是“從簡至繁”的原則，即首先排除網絡問題，其次對應用服務器配置進行分析，確認不是由于應用服務器本身的配置引起的性能問題，然后在數據庫訪問層進行性能分析，重點是索引、數據庫Cache、死鎖等問題的分析，在確認所有這些因素都不是性能瓶頸的情況下，才對代碼進行分析和檢查，找出導致性能問題的因素。

文章來源于領測軟件測試網 http://www.kjueaiud.com/