一、性能測試的目的
性能測試的目的是驗證軟件系統是否能夠達到用戶提出的性能指標，同時發現軟件系統中存在的性能瓶頸，優化軟件，最後起到優化系統的目的。
包括以下幾個方面
1．評估系統的能力，測試中得到的負荷和響應時間數據可以被用於驗證所計劃的模型的能力，並幫助作出決策。
2．識別體系中的弱點：受控的負荷可以被增加到一個極端的水平，並突破它，從而修復體系的瓶頸或薄弱的地方。
3．系統調優：重複運行測試，驗證調整系統的活動得到了預期的結果，從而改進性能。檢測軟件中的問題：長時間的測試執行可導致程序發生由於內存泄露引起的失敗，揭示程序中的隱含的問題或衝突。
4．驗證穩定性（resilience）可靠性（reliability）：在一個生產負荷下執行測試一定的時間是評估系統穩定性和可靠性是否滿足要求的唯一方法。
二、類型
性能測試類型包括負載測試，強度測試，容量測試等。
負載測試（Load Testing）：負載測試是一種主要爲了測試軟件系統是否達到需求文檔設計的目標，譬如軟件在一定時期內，最大支持多少併發用戶數，軟件請求出錯率等，測試的主要是軟件系統的性能。
壓力測試（Stress Testing）：強度測試也就是壓力測試，壓力測試主要是爲了測試硬件系統是否達到需求文檔設計的性能目標，譬如在一定時期內，系統的cpu利用率，內存使用率，磁盤I/O吞吐率，網絡吞吐量等，壓力測試和負載測試最大的差別在於測試目的不同。
容量測試（Volume Testing）：確定系統最大承受量，譬如系統最大用戶數，最大存儲量，最多處理的數據流量等。
性能測試中包含以下測試類型：
基準測試 - 比較新的或未知測試對象與已知參照標準（如現有軟件或評測標準）的性能。
爭用測試：- 覈實測試對象對於多個主角對相同資源（數據記錄、內存等）的請求的處理是否可以接受。
性能配置 - 覈實在操作條件保持不變的情況下，測試對象在使用不同配置時其性能行爲的可接受性。
負載測試- 覈實在保持配置不變的情況下，測試對象在不同操作條件（如不同用戶數、事務數等）下性能行爲的可接受性。
強度測試- 覈實測試對象性能行爲在異常或極端條件（如資源減少或用戶數過多）之下的可接受性。
容量測試- 覈實測試用戶同時使用軟件程序的最大數量。
性能評價通常是和用戶代表一起協作並且以多級方法執行的。
性能分析的第一級涉及單一主角/用例實例的結果評價和多個測試執行的結果比較。例如，在測試對象上沒有其他活動的情況下，記錄單一主角執行單一用例的性能行爲，並將結果與相同主角/用例的其他幾個測試執行進行比較。第一級分析有助於確定可以表明系統資源中存在爭用的趨勢，該趨勢將影響從其他性能測試結果所得出的結論的有效性。
分析的第二級檢查特定主角/用例執行的摘要統計信息和實際數據值，以及測試對象的性能行爲。摘要統計信息包括響應時間的標準偏差和百分位分佈，這些信息顯示了系統響應的變動情況，正如每個主角所見到的一樣。
分析的第三級有助於理解性能問題的起因和加權值。該詳細分析採用低級數據並且使用統計方法，幫助測試員從數據中得出正確的結論。詳細分析爲決策提供客觀和定量的標準，但是它耗時較長，並且要求對統計學有基本的理解。
當性能行爲差異確實存在，或是由於某些與測試數據收集相關的隨機事件引起時，詳細分析使用統計加權值的概念來幫助理解。即認爲在基本級上，任何事件都具有隨機性。統計測試確定是否存在無法用隨機事件解釋的系統差異。
三、指標
性能測試主要是通過自動化的測試工具模擬多種正常、峯值以及異常負載條件來對系統的各項性能指標進行測試。負載測試和壓力測試都屬於性能測試，兩者可以結合進行。通過負載測試，確定在各種工作負載下系統的性能，目標是測試當負載逐漸增加時，系統各項性能指標的變化情況。壓力測試是通過確定一個系統的瓶頸或者不能接收的性能點，來獲得系統能提供的最大服務級別的測試。
在實際工作中我們經常會對兩種類型軟件進行測試：bs和cs，這兩方面的性能指標一般需要哪些內容呢？
Bs結構程序一般會關注的通用指標如下（簡）：
Web服務器指標指標：
Avg Rps: 平均每秒鐘響應次數=總請求時間 / 秒數；
Avg time to last byte per terstion （mstes）：平均每秒業務腳本的迭代次數，有人會把這兩者混淆；
Successful Rounds：成功的請求；
Failed Rounds ：失敗的請求；
Successful Hits ：成功的點擊次數；
Failed Hits ：失敗的點擊次數；
Hits Per Second ：每秒點擊次數；
Successful Hits Per Second ：每秒成功的點擊次數；
Failed Hits Per Second ：每秒失敗的點擊次數；
Attempted Connections ：嘗試鏈接數；
CS結構程序，由於一般軟件後臺通常爲數據庫，所以我們更注重數據庫的測試指標：
User 0 Connections ：用戶連接數，也就是數據庫的連接數量；
Number of deadlocks：數據庫死鎖；
Buffer Cache hit ：數據庫Cache的命中情況
當然，在實際中我們還會察看多用戶測試情況下的內存，CPU，系統資源調用情況。這些指標其實是引申出來性能測試中的一種：競爭測試。什麼是競爭測試，軟件競爭使用各種資源（數據紀錄，內存等），看他與其他相關係統對資源的爭奪能力。
我們知道軟件架構在實際測試中制約着測試策略和工具的選擇。如何選擇性能測試策略是我們在實際工作中需要了解的。一般軟件可以按照系統架構分成幾種類型：
c/s
client/Server 客戶端/服務器架構
基於客戶端/服務器的三層架構
基於客戶端/服務器的分佈式架構
b/s
基於瀏覽器/Web服務器的三層架構
基於中間件應用服務器的三層架構l
基於Web服務器和中間件的多層架構
四、步驟
在每種不同的系統架構的實施中，開發人員可能選擇不同的實現方式，造成實際情況紛繁複雜。我們不可能對每種技術都詳細解說，這裏只是介紹一種方法提供給你如何選擇測試策略，從而幫助分析軟件不同部分的性能指標，進而分析出整體架構的性能指標和性能瓶頸。
由於工程和項目的不同，所選用的度量，評估方法也有不同之處。不過仍然有一些通用的步驟幫助我們完成一個性能測試項目。步驟如下
1． 制定目標和分析系統
2． 選擇測試度量的方法
3． 學習的相關技術和工具
4． 制定評估標準
5． 設計測試用例
6． 運行測試用例
7． 分析測試結果
制定目標和分析系統
每一個性能測試計劃中第一步都會制定目標和分析系統構成。只有明確目標和了解系統構成纔會澄清測試範圍，知道在測試中要掌握什麼樣的技術。
目標：
1． 確定客戶需求和期望
2． 實際業務需求
3． 系統需求
系統組成
系統組成這裏包含幾方面含義：系統類別，系統構成，系統功能等。瞭解這些內容的本質其實是幫助我們明確測試的範圍，選者適當的測試方法來進行測試。
系統類別：分清系統類別是我們掌握什麼樣的技術的前提，掌握相應技術做性能測試纔可能成功。例如：系統類別是bs結構，需要掌握 http協議，java，html等技術。或者是cs結構，可能要了解操作系統，winsock，com等。所以甄別系統類別對於我們來說很重要。
系統構成：硬件設置，操作系統設置是性能測試的制約條件，一般性能測試都是利用測試工具模仿大量的實際用戶操作，系統在超負荷情形下運作。不同的系統構成性能測試就會得到不同的結果。
系統功能：系統功能指系統提供的不同子系統，辦公管理系統中的公文子系統，會議子系統等，系統功能是性能測試中要模擬的環節，瞭解這些是必要的。
選擇測試度量的方法
經過第一步，將會對系統有清醒的認識。接下來我們將把精力放在軟件度量上，收集系統相關的數據。
度量的相關方面：
制定規範
制定相關流程，角色，職責
制定改進策略
制定結果對比標準
學習的相關技術和工具
性能測試是通過工具，模擬大量用戶操作，對系統增加負載。所以需要掌握一定的工具知識才能進行性能測試。大家都知道性能測試工具一般通過winsock,http等協議記錄用戶操作。而協議選擇是基於軟件的系統架構實現（web一般選擇http協議，cs選擇winsock協議），不同的性能測試工具，腳本語言也不同，比如rational robot中vu腳本用類c語言實現。
開展性能測試需要對各種性能測試工具進行評估，因爲每一種性能測試工具都有自身的特點，只有經過工具評估，才能選擇符合現有軟件架構的性能測試工具。確定測試工具後，需要組織測試人員進行工具的學習，培訓相關技術。
制定評估標準：
任何測試的目的都是確保軟件符合預先規定的目標和要求。性能測試也不例外。所以必須制定一套標準。
通常性能測試有四種模型技術可用於評估：
線性投射：用大量的過去的，擴展的或者將來可能發生的數據組成散佈圖，利用這個圖表不斷和系統的當前狀況對比。
分析模型：用排隊論公式和算法預測響應時間，利用描述工作量的數據和系統本質關聯起來
模仿：模仿實際用戶的使用方法測試你的系統
基準：定義測試和你最初的測試作爲標準，利用它和所有後來進行的測試結果進行對比
設計測試用例：
設計測試用例是在瞭解軟件業務流程的基礎上。設計測試用例的原則是受最小的影響提供最多的測試信息，設計測試用例的目標是一次儘可能的包含多個測試要素。這些測試用例必須是測試工具可以實現的，不同的測試場景將測試不同的功能。因爲性能測試不同於平時的測試用例，儘可能把性能測試用例設計的複雜，纔有可能發現軟件的性能瓶頸。
運行測試用例：
通過性能測試工具運行測試用例。同一環境下作的性能測試得到的測試結果是不準確的，所以在運行這些測試用例的時候，需要用不同的測試環境，不同的機器配置上運行。
分析測試結果：
運行測試用例後，收集相關信息，進行數據統計分析，找到性能瓶頸。通過排除誤差和其他因素，讓測試結果體現接近真實情況。不同的體系結構分析測試結果的方法也不同，bs結構我們會分析網絡帶寬，流量對用戶操作響應的影響，而cs結構我們可能更關心會系統整體配置對用戶操作的影響。
五、原則
1）情況許可時，應使用幾種測試工具或手段分別獨立進行測試，並將結果相互印證，避免單一工具或測試手段自身缺陷影響結果的準確性；
2）對於不同的系統，性能關注點是有所區別的，應該具體問題具體分析；
3）查找瓶頸的過程應由易到難逐步排查：
服務器硬件瓶頸及網絡瓶頸（局域網環境下可以不考慮網絡因素）
應用服務器及中間件操作系統瓶頸（數據庫、WEB服務器等參數配置）
應用業務瓶頸（SQL語句、數據庫設計、業務邏輯、算法、數據等）
4）性能調優過程中不宜對系統的各種參數進行隨意的改動，應該以用戶配置手冊中相關參數設置爲基礎，逐步根據實際現場環境進行優化，一次只對某個領域進行性能調優（例如對CPU的使用情況進行分析），並且每次只改動一個設置，避免相關因素互相干擾；
5）調優過程中應仔細進行記錄，保留每一步的操作內容及結果，以便比較分析；
6）性能調優是一個經驗性的工作，需要多思考、分析、交流和積累；
7）瞭解“有限的資源，無限的需求”；
8）儘可能在開始前明確調優工作的終止標準。
#