性能測試 軟件測試
一、性能測試概念
性能測試是一個較大的范疇，包括負載測試、壓力測試和容量測試。其中負載測試是為了檢驗系統在給定負載下是否能達到預期性能指標；壓力測試是通過不斷向被測系統施加“壓力”，測試系統在壓力情況下的性能表現；容量測試針對數據庫而言，是在數據庫中有較大數量的數據記錄情況下對系統進行的測試。
性能測試是在交替進行負荷和強迫測試時常用的術語。性能測試關注的是系統的整體。它和通常所說的強度、壓力/負載測試測試有密切關系。所以壓力和強度測試應該于性能測試一同進行。例如：對一個網站進行測試，模擬10到100個用戶就是在進行常規性能測試，用戶增加到1000乃至上萬就應該是壓力/負載測試。
性能測試(Performance) 正常使用的時間內系統完成一個任務需要的時間，多人同時使用的時候響應時間。性能測試是為了檢查系統的反映，運行速度等性能指標，其前提是要求在一定負載下，例如：檢查一個網站在100人同時在線的情況下的性能指標，每個用戶是否都還可以正常的完成操作等
二、性能測試主要過程
對于一個完整的性能調優過程，其過程中應該包括測量性能、定義性能測試、確定基準性能、壓力測試、解決性能問題五大部分。
（一）、測量性能
為了要正確地調整性能，必須準確完整地記錄每次測試的結果并進行維護。記錄應包括：
精確的系統配置，尤其是與前幾次測試的不同之處
原始數據和性能監視工具計算的結果
這些記錄不僅指示應用程序是否達到性能目標，而且有助于識別未來性能問題的潛在原因。
在每遍測試中，運行一系列完全相同的性能測試；否則，無法分辨不同的結果是由于測試中的改動還是應用程序更改造成的。使盡可能多的性能測試操作自動進行有助于消除因操作者造成的差異。
其他表面上是良性的因素影響性能測試的結果，如應用程序在測試開始前運行的時間。正如冷的汽車引擎與熱引擎的性能不同，長時間運行的應用程序由于內存碎片這樣的因素，其性能可能與剛啟動的應用程序不同。
（二）、定義性能測試
性能測試期間，測量和記錄性能目標中指定的度量標準值。達到全部性能度量標準（如思考時間、事務混合等）很重要。在這些約束下，測試應盡可能實際。例如，對應用程序進行測試，確定它在許多客戶端同時訪問它時的性能。多線程測試應用程序可以用可復制的方式模擬多個客戶端，每個線程表示一個客戶端。如果應用程序訪問數據庫，則數據庫應包含實際數目的記錄，并且測試應使用數據項的隨機（但有效）值。如果測試數據庫太小，數據庫服務器的緩存效果將產生不符合實際情況的測試結果。如果輸入或訪問數據的方式不符合實際情況，則結果也可能不符合實際情況。例如，在主鍵上按字母順序創建新數據是不太可能的。
通常，測試裝置必須接受用戶指定的輸入參數，如事務混合、思考時間、客戶端數目等。然而，測試裝置本身可以規定創建實際的隨機數據的規則。
創建了驅動應用程序的測試裝置后，應該將所有運行測試的不變條件記入文檔。最起碼，這些條件應包括運行測試裝置所需的輸入參數。另外，應將如何設置運行測試的數據庫記入文檔。說明中應指定數據庫不應包含前一遍測試所做的更改。說明中還應指定用于測試的計算機配置。在不同于應用程序所在的另一臺計算機上運行測試裝置，因為這樣設置更接近生產環境。
（三）、確定基準性能
確定了性能目標并制定了性能測試后，運行一次測試以建立基準。驗證環境與生產環境越相似，應用程序部署后的性能令人滿意的可能性就越大。因此，一開始有一個符合實際情況的驗證環境很重要。
幸運的話，基準性能將符合性能目標，并且應用程序不需要任何調整。但更可能的情況是，基準性能不令人滿意。然而，記錄初始測試環境和基準結果可以為調整工作提供堅實的基礎。
（四）、壓力測試
壓力測試是性能測試的一種專門形式，它與其他工程領域的破壞性測試相似。壓力測試的目的是使應用程序產生故障，通過增加處理負載使其超過性能的降低，直到由于資源飽和或發生錯誤而使應用程序開始出問題。壓力測試有助于揭示細微的錯誤，這些錯誤本來要到部署應用程序時才會被發現。由于此類錯誤通常是因設計缺陷所致，壓力測試應該早在開發階段便在應用程序的每個區域上開始進行。在其源頭修復這些細微的錯誤，而不是忽視這些錯誤，直到它們可能在應用程序中的其他位置表現出癥狀時才修復它們。
（五）、解決性能問題
通�？蓪⑿阅軉栴}歸結于不止一個因素。因此，查找性能惡化的解決方案與進行科學實驗極為相似�？茖W實驗傳統上遵循一個分六步進行的過程，包括觀察、初步假設、預測、測試、控制和結論。結論由該過程積累的最佳證據集合所支持的假設組成�？梢宰裱瑯拥倪^程來解決性能問題。
當觀察到 ASP 應用程序的性能比期望的低時，您假定 ASPProcessorThreadMax 元數據庫屬性設置得太低。當“ASP 排隊請求”性能計數器上下移動，并且處理器的運行效率低于 50% 時，可能會發生這種情況。您預測增加 ASPProcessorThreadMax 元數據庫屬性的數值可以提高性能。
活動線程設置現在已經變成控件。一次僅進行一個設置更改，直到觀察到滿意的性能改變。如果在幾次調整 ASPProcessorThreadMax 元數據庫屬性之后獲得了更令人滿意的性能，則結論是某個屬性設置與所有當前變量（所需內存的總量、正在運行的應用程序數、已升級的軟件等）組合，可提供最佳服務器性能。變量中的任何更改就會形成進一步的實驗。
三、性能測試場景設計方法
主要分以下幾種：
壓力測試：已知系統高峰期使用人數，驗證各事務在最大并發數（通過高峰期人數換算）下事務響應時間能夠達到客戶要求。系統各性能指標在這種壓力下是否還在正常數值之內。系統是否會因這樣的壓力導致不良反應（如：宕機、應用異常中止等）。
Ramp Up 增量設計：如并發用戶為75人，系統注冊用戶為1500人，以5％－7％作為并發用戶參考值。一般以每15s加載5人的方式進行增壓設計，該數值主要參考測試加壓機性能，建議Run幾次。以事務通過率與錯誤率衡量實際加載方式。
Ramp Up增量設計目標：尋找已增量方式加壓系統性能瓶頸位置，抓住出現的性能拐點時機，一般常用參考Hits點擊率與吞吐量、CPU、內存使用情況綜合判斷。模擬高峰期使用人數，如早晨的登錄，下班后的退出，工資發送時的消息系統等。
另一種極限模擬方式，可視為在峰值壓力情況下同時點擊事務操作的系統極限操作指標。加壓方式不變，在各腳本事務點中設置同集合點名稱（如：lr_rendzvous("same");）在場景設計中，使用事務點集合策略。以同時達到集合點百分率為標準，同時釋放所有正在Run的Vuser。
穩定性測試：已知系統高峰期使用人數、各事務操作頻率等。設計綜合測試場景，測試時將每個場景按照一定人數比率一起運行，模擬用戶使用數年的情況。并監控在測試中，系統各性能指標在這種壓力下是否能保持正常數值。事務響應時間是否會出現波動或隨測試時間增漲而增加。系統是否會在測試期間內發生如宕機、應用中止等異常情況。
根據上述測試中，各事務條件下出現性能拐點的位置，已確定穩定性測試并發用戶人數。仍然根據實際測試服務器（加壓機、應用服務器、數據服務器三方性能），估算最終并發用戶人數。
場景設計思想：從穩定性測試場景的設計意義，應分多種情況考慮：
針對同一個場景為例，以下以公文附件上傳為例簡要分析場景設計思想：
1）場景一：已壓力測試環境下性能拐點的并發用戶為設計測試場景，目的驗證極限壓力情況下測試服務器各性能指標。
2）場景二：根據壓力測試環境中CPU、內存等指標選取服務器所能承受最大壓力的50%來確定并發用戶數。
測試方法：采用1)Ramp Up-Load all Vusers simultaneously
2)Duration-Run Indefinitely
3)在Sechedule-勾選Initalize all Vusers before Run
容錯性測試：通過模擬一些非正常情況（如：服務器突然斷電、網絡時斷時續、服務器硬盤空間不足等），驗證系統在發生這些情況時是否能夠有自動處理機制以保障系統的正常運行或恢復運行措施。如有HA（自動容災系統），還可以專門針對這些自動保護系統進行另外的測試。驗證其能否有效觸發保護措施。
問題排除性測試：通過原有案例或經驗判斷，針對系統中曾經發生問題或懷疑存在隱患的模塊進行驗證測試。驗證這些模塊是否還會發生同樣的性能問題。如：上傳附件模塊的內存泄露問題、地址本模塊優化、開啟Tivoli性能監控對OA系統性能的影響等等。
測評測試是用于獲取系統的關鍵性能指標點，而進行的相關測試。主要是針對預先沒有明確的預期測試結果，而是要通過測試獲取在特定壓力場景下的性能指標（如：事務響應時間、最大并發用戶數等）。
評測事務交易時間：為獲取某事務在特定壓力下的響應時間而進行的測試活動。通過模擬已知客戶高峰期的各壓力值或預期所能承受的壓力值，獲取事務在這種壓力下的響應時間。
評測事務最大并發用戶數：為獲取某事務在特定系統環境下所能承受的最大并發用戶數而進行的測試活動。通過模擬真實環境或直接采用真實環境，評測在這種環境下事務所能承受的最大并發用戶數。判定標準閾值需預先定義（如響應時間，CPU占用率，內存占用率，已出現點擊率峰值，已出現吞吐量峰值等）。
評測系統最大并發用戶數：為獲取整個系統所能夠承受的最大并發用戶數而進行的的測試活動。通過預先分析項目各主要模塊的使用比率和頻率，定義各事務在綜合場景中所占的比率，以比率方式分配各事務并發用戶數。模擬真實環境或直接采用真實環境，評測在這種環境下系統所能承受的最大并發用戶數。判定標準閥值預先定義（如響應時間，CPU占用率，內存占用率，已出現點擊率峰值，已出現吞吐量峰值等）。取值標準以木桶法則為準（并發數最小的事務為整個系統的并發數）。
評測不同數據庫數據量對性能的影響：針對不同數據庫數據量的測試，將測試結果進行對比，分析發現數據庫中各表的數據量對事務性能的影響。得以預先判斷系統長時間運行后，或某些模塊客戶要求數據量較大時可能存在的隱患。
問題定位測試在通過以上測試或用戶實際操作已經發現系統中的性能問題或懷疑已存在性能問題。需通過響應的測試場景重現問題或定義問題。如有可能，可以直接找出引起性能問題所在的代碼或模塊。
該類測試主要還是通過測試出問題的腳本場景，并可以增加發現和檢測的工具，如開啟Tivoli性能監控、開啟HeapDump輸出、Linux資源監控命令等。并在場景運行過程中輔以手工測試。
文章來源于領測軟件測試網 http://www.kjueaiud.com/