軟件系統在滿足用戶強大的功能需求同時，架構和實現上也變得複雜，軟件系統經過單機系統時代、客戶機服務器系統時代，到現在跨廣域網的龐大分佈式系統時代，這樣的例子在金融、電信系統中隨處可見。
系統的業務量大了，就要使用更多的時間和空間資源，在一般情況下不能出現的軟件性能問題就暴露出來了，這些問題“不鳴則已，一鳴驚人”，輕則讓軟件對外不能正常提供服務，重則可能會導致系統的崩潰甚至數據的丟失，這都會給用戶帶來無法估量的損失。
案例1
某西部大型油田使用鑽井平臺數據採集系統，在上線之前已經通過功能測試，但軟件系統上線之後，在使用採集的電子數據勘探油層時，總是不能準確地找到油口，導致數百萬元的損失。經過研究試驗，發現軟件從平臺採集的數據和手工採集的數據有很大出入，性能測試後，找到根本原因：由於採集過程中產生的數據量非常大，導致軟件系統在採集過程中線程死掉，丟失部分數據，最終產生的是一個錯誤的採集結果，爲工程人員提供了錯誤的判斷依據。
案例2
日本第三大手機運營商——軟銀移動2006年10月遇到了麻煩，本指望通過降低手機資費來吸引用戶，誰想大量用戶蜂擁而至卻導致自己的電腦系統陷入癱瘓，軟銀移動在10月29日不得不宣佈暫停接納新的用戶，直接損失逾億日元。
用戶當然不想看到以上的場景發生在自己的軟件系統上，“癱瘓”意味着響應時間過長，不能爲客戶正常提供服務；數據丟失則是一個不可接受的嚴重問題，損失幾乎不可彌補。因此用戶對軟件性能的要求日益細化嚴格，可以說是“與時俱進”。
簡單地說，在軟件發展的初級階段，“又要馬兒跑，又要馬兒少吃草”，這是當時很多用戶對軟件系統提出的性能要求，“跑”有關時間，“草”有關空間。馬兒跑，就是軟件系統給用戶的響應要快，處理時間要短；馬兒少吃草就是軟件系統能夠儘可能地少佔用和消耗資源，諸如內存、CPU等。因此，測試人員在做性能測試時，往往要把響應時間、內存利用率、I/O佔用率等寫在最後測試報告裏，因爲這是用戶最關心的東西。
隨着用戶的軟件質量意識的增強，用戶對軟件的性能需求也越來越多，越來越細緻。這時不僅要讓馬兒跑，還要馬兒能快能慢（軟件系統的伸縮性），“路遙知馬力”（軟件系統在長時間運行下的穩定性）等。細數起來，如下：
計算性能；
資源的利用和回收；
啓動時間；
伸縮性；
穩定性。
計算性能——就是馬兒要能跑，要有很快的速度，最好是“日行千里，夜行八百”。對軟件系統來講，計算性能是用戶最關心的一個指標，即軟件系統有多快。比如，用戶會關注軟件系統執行一個典型的業務需要花多少時間。我們要給出用戶答案，我們的系統完成用戶典型操作，比如業務的交易計算，數據的增、刪、改、查時間是不是在用戶可以接受的範圍內。
資源的利用和回收——就是馬兒少吃草。軟件系統的“草料”就是其依存的硬件和軟件資源，硬件資源包括客戶端硬件、服務器硬件和網絡硬件；軟件資源包括操作系統、中間件和數據庫等。其中要特別說的是，運行軟件系統需要使用到的服務器內存數量，對於整個系統的性能表現是至關重要的。因此，軟件系統能否在運行時有效地使用和釋放內存是我們考察軟件性能的一個重要因素。
對計算機來講，計算機內存爲程序提供運行空間（有代碼區和數據區），如果內存不夠大，CPU就不能把全部的數據和程序放到內存裏，只好放一部分在內存，一部分放在硬盤中，現用現取，而讀取內存和讀取硬盤數據的速度要差好幾個數量級，這就大大影響了計算機的工作效率。如果還不能理解內存的重要性的話，可以用個形象的例子來說明：
如果CPU是個畫家，那麼內存就是他的工作臺。工作臺上放着畫布（被操作的數據），還有各種畫筆、刷子等各種工具（運行的程序）。如果工作臺（內存）不能足夠大，容納不下繪畫所使用的所有工具，那麼畫家就需要不時地去儲藏室（硬盤等存儲設備）裏取所需的工具，這就會大大影響繪畫的速度。
所以在評價一個系統性能的時候，要特別關注這個系統對內存的使用。
啓動時間——這是馬兒的加速度問題。用戶希望系統進入正常工作狀態的時間越短越好，尤其在主備系統中，軟件的啓動時間直接影響主備的切換效率。而不同軟件系統啓動時間會不同的。J2EE系統在第一次啓動的時候一般會比較慢，因爲期間涉及緩存的加載、JSP頁面的編譯、Java class編譯成機器指令等。所以在第一次啓動應用感到非常慢是比較正常的，這也是J2EE或者Java應用的一個特點。而C/C++程序直接運行的是二進制機器代碼，啓動速度就要快一些。
伸縮性——馬兒要能快能慢。伸縮性是分析系統性能經常被忽略的一個方面。比如一個系統在50個併發用戶訪問的時候表現正常，但是當併發用戶達到1000的時候，系統表現如何？服務器的性能是逐漸下降呢，還是在某個拐點附近急劇下降呢？
如圖1-1所示，該圖是一個伸縮性不好的系統的表現，隨着併發用戶的增加，平均相應時間越來越長。系統最終會達到一個不可用的程度，沒有一個用戶會接受系統這樣的性能表現。
 |
| 圖1-1 伸縮性不好的用戶 - 響應時間圖 |
如圖1-2所示就是一個伸縮性較好的系統的表現，隨着併發用戶的增加，平均響應時間逐漸穩定下來。
 |
| 圖1-2 伸縮性良好的用戶 - 響應時間圖 |
穩定性——千里馬能夠“路遙知馬力”，而黑馬只能夠一時跑得快。用戶希望自己的軟件系統是千里馬，而不是黑馬。尤其是金融和電信系統，這些系統基本上都是每天24小時運轉，時時刻刻準備着爲用戶提供服務。如果它們在運行一段時間後出現了問題，不能響應用戶的請求甚至破壞或丟失了數據，那麼系統爲用戶帶來的損失是巨大的。這種穩定性問題應該在軟件系統上線之前就被考慮並得到解決。
“快”、“好”這只是用戶的主觀體驗，如果能讓這些感覺和要求被其他人正確地理解（尤其是對軟件人員），那麼就需要用數據把上述用戶的感受量化並表達出來，這就是性能指標。
通常，衡量一個軟件系統性能的常見指標有：
1．響應時間（Response time）
響應時間就是用戶感受軟件系統爲其服務所耗費的時間，對於網站系統來說，響應時間就是從點擊了一個頁面計時開始，到這個頁面完全在瀏覽器裏展現計時結束的這一段時間間隔，看起來很簡單，但其實在這段響應時間內，軟件系統在幕後經過了一系列的處理工作，貫穿了整個系統節點。根據“管轄區域”不同，響應時間可以細分爲：
（1）服務器端響應時間，這個時間指的是服務器完成交易請求執行的時間，不包括客戶端到服務器端的反應（請求和耗費在網絡上的通信時間），這個服務器端響應時間可以度量服務器的處理能力。
（2）網絡響應時間，這是網絡硬件傳輸交易請求和交易結果所耗費的時間。
（3）客戶端響應時間，這是客戶端在構建請求和展現交易結果時所耗費的時間，對於普通的瘦客戶端Web應用來說，這個時間很短，通常可以忽略不計；但是對於胖客戶端Web應用來說，比如Java applet、AJAX，由於客戶端內嵌了大量的邏輯處理，耗費的時間有可能很長，從而成爲系統的瓶頸，這是要注意的一個地方。
那麼客戶感受的響應時間其實是等於客戶端響應時間+服務器端響應時間+網絡響應時間。細分的目的是爲了方便定位性能瓶頸出現在哪個節點上（何爲性能瓶頸，下一節中介紹）。
2．吞吐量（Throughput）
吞吐量是我們常見的一個軟件性能指標，對於軟件系統來說，“吞”進去的是請求，“吐”出來的是結果，而吞吐量反映的就是軟件系統的“飯量”，也就是系統的處理能力，具體說來，就是指軟件系統在每單位時間內能處理多少個事務/請求/單位數據等。但它的定義比較靈活，在不同的場景下有不同的詮釋，比如數據庫的吞吐量指的是單位時間內，不同SQL語句的執行數量；而網絡的吞吐量指的是單位時間內在網絡上傳輸的數據流量。吞吐量的大小由負載（如用戶的數量）或行爲方式來決定。舉個例子，下載文件比瀏覽網頁需要更高的網絡吞吐量。
3．資源使用率（Resource utilization）
常見的資源有：CPU佔用率、內存使用率、磁盤I/O、網絡I/O。
我們將在Analysis結果分析一章中詳細介紹如何理解和分析這些指標。
4．點擊數（Hits per second）
點擊數是衡量Web Server處理能力的一個很有用的指標。需要明確的是：點擊數不是我們通常理解的用戶鼠標點擊次數，而是按照客戶端向Web Server發起了多少次http請求計算的，一次鼠標可能觸發多個http請求，這需要結合具體的Web系統實現來計算。
5．併發用戶數（Concurrent users）
併發用戶數用來度量服務器併發容量和同步協調能力。在客戶端指一批用戶同時執行一個操作。併發數反映了軟件系統的併發處理能力，和吞吐量不同的是，它大多是佔用套接字、句柄等操作系統資源。
另外，度量軟件系統的性能指標還有系統恢復時間等，其實凡是用戶有關資源和時間的要求都可以被視作性能指標，都可以作爲軟件系統的度量，而性能測試就是爲了驗證這些性能指標是否被滿足。