軟件系統性能的常見指標：
響應時間：用戶感受軟件系統爲其服務所耗費的時間
響應時間細分爲： 服務器端響應時間（可用來度量服務器的處理能力），網絡響應時間（網絡硬件傳輸交易請求和交易結果所耗費的時間）， 客戶端響應時間
吞吐量：“吞”進去的是請求，“吐”出來的是結果；具體指的是 軟件系統在每單位時間內能處理多少個事務/請求/單位數據
資源使用率： 常見的資源有 cpu佔用率，內存使用率，磁盤I/O，網絡I/O
點擊數：該點擊數不是表示通常理解的用戶鼠標點擊次數，而是按照客戶端向web server發起多少次http請求計算的，一次鼠標可能觸發多個http請求；
併發用戶數：併發用戶數用來度量服務器併發容量和同步協調的能力；在客戶端指一批用戶同時執行一個操作；併發數反應了軟件系統的併發處理能力；和吞吐量不同的是，它大多佔用套接字，句柄等操作資源。
滿足用戶性能需求，有以下幾種方案：
消除軟件對時間和空間不必要的浪費
以空間換時間
以時間換空間
軟件生產過程的v型圖：
需求分析-設計-編碼-單元測試-集成測試-系統測試（性能測試）
性能測試爲軟件系統級測試，可用來做： 識別系統瓶頸和產生瓶頸的原因；最優化和調整平臺的配置來達到最高的性能；判斷一個新的模塊是否對整個系統的性能有影響
作爲軟件測試的一種，軟件測試的規則童謠適用於性能測試中：
確定預期輸出是測試必不可少的一部分
必須徹底檢查每一個測試結果
窮舉測試是不可能的，在性能測試中不可能覆蓋每一個功能部分
做性能測試案例時要遵循：
做基本且常用的功能模塊測試；做響應時間要求苛刻的模塊
常見的性能測試方法：
負載測試：負載測試是站在用戶的角度去觀察在一定時間下軟件系統的性能表現
負載測試的預期結果是用戶的性能需求得到滿足，此指標體現爲：響應時間，交易容量，併發容量，資源使用率
壓力測試：考察系統在極端條件下的表現，這個極端條件不一定是用戶的性能需求，可能要遠遠高於用戶的性能需求
併發測試：負載測試往往就會使用併發來創造負載，之所以把併發測試單獨提出來，是因爲併發測試往往涉及服務器的併發容量，以及多進程/多線程協調同步可能帶來的問題。這是要特別注意，必須測試的
基準測試：當軟件系統中增加新的模塊時，要做基準測試，用來判斷新的模塊對整個軟件系統的性能影響；按照基準測試的方法，需要打開/關閉新模塊至少各做一次測試。關閉模塊之前的系統各個性能指標記下來作爲基準（Benchmark），然後與打開模塊狀態下的系統性能指標作比較，以判斷模塊對系統性能 的影響
穩定性測試：查看測試系統在一定負載下運行長時間後是否發生問題
可恢復測試：查看測試系統能否快速的從錯誤狀態恢復到正常狀態；通常結合壓力測試一起做
常規的性能測試目標：
度量最終用戶響應時間
定義最優的硬件配置
檢查可靠性：確定系統在連續的高工作負載下的穩定性級別
查看硬件或者軟件升級對響應時間和可靠性的影響
確定瓶頸
度量系統容量
分析性能需求：
要細化需求，找到測試點：
測試的對象是什麼，例如“被測系統中有負載壓力需求的功能點包括哪些？”；“測試中需要模擬哪些部門用戶產生的負載壓力？”等問題。
系統配置如何，例如“預計有多少用戶併發訪問？”；“用戶客戶端的配置如何？”；“使用什麼樣的數據庫”；“服務器怎樣和客戶端通信？”。
應用系統的使用模式是什麼，例如“使用在什麼時間達到高峯期？”；“用戶使用該系統
是採用 B/S 運行模式嗎？”；“網絡設備的吞吐能力如何，每個環節承受多少併發用戶？”等問題。
最後得出的性能測試指標標準至少要包含測試環境、業務規則、期望響應時間等。
開發Loadrunner腳本需要經過幾個步驟：
創建腳本-完善編輯腳本-場景的指定-獨立運行腳本-場景中運行腳本
錄製腳本的錄製原則： 錄製腳本不要有多餘重複性的操作；錄製具有代表性的功能；選擇具有影響的事務