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）
　　　　並發用戶數用來度量服務器並發容量和同步協調能力。在客戶端指一批用戶同時執行一
　　個操作。並發數反映了軟件系統的並發處理能力，和吞吐量不同的是，它大多是占用套接字、
　　句柄等操作系統資源。
　　另外，度量軟件系統的性能指標還有系統恢復時間等，其實凡是用戶有關資源和時間的
　　要求都可以被視作性能指標，都可以作為軟件系統的度量，而性能測試就是為了驗證這些性
　　能指標是否被滿足。

　　6.TPS（Transaction Pre Second） 每秒完成的事務數

　　　　通常指每秒成功的事務數，事務可以理解為完成一件事可能要經過幾個小的步驟，這些小的

　　步驟必須全部成功執行，才算成功

測試人員眼中的軟件性能

　　用戶恨不得讓軟件有無線的性能，但作為技術人員，我們需認識到，那種理想化的要求時不可能的。

軟件性能方案充滿了辯證的各種矛盾。每種方案和方法幾乎都有利有弊。只有把握設計系統的具體環境，

明確設計目標，具體問題具體分析，合理平衡各種矛盾，牢牢抓住主要矛盾，才能產生出優化的軟件系

統性能方案。

那麽其實滿足用戶的性能需求，只有以下幾種方案：

1．消除軟件對空間和時間不必要的浪費
　　一個最明顯的例子就是內存泄漏問題，它被開發人員看作是大忌。
嚴格地說，內存泄漏應該屬於軟件程序設計的一種缺陷，該缺陷直接導致了程序在運行
過程中無法釋放不再需要的內存空間，從而造成內存資源浪費，嚴重的會造成無可用內存，
導致系統崩潰。具體來說，當用戶程序在運行過程中需要動態獲得內存時，操作系統總是從
堆（heap）上分配相應的空間給應用，分配的結果是將該堆內存的起始地址通過指針返回給
應用。正常情況下，使用完這塊內存後，應通過系統調用主動通知操作系統回收這些堆內
存以便重用。但是，如果由於設計缺陷導致在某些情況下程序沒有主動地通知到操作系統，
而後應用又失去了對這塊內存的引用時，則該堆內存塊將成為既不受程序控制，又不能被系
統回收重用的“孤兒”內存，這便是我們所指的內存泄漏。

2．以空間換時間

軟件的高性能並不是憑空產生的，在解決了空間和時間浪費的問題之後，如果用戶還有
更高的性能要求，我們軟件人員只好“偷梁換柱”，做一下調整，而這種調整往往是很靈活的。
空間換時間是軟件人員解決性能問題最常見的方法。是在系統功能正常的前提下增大軟
件空間開銷的方法來縮減運行的時間。一般的方法有算法調整、並行計算方法、體系結構方
法和一些不是“辦法”的辦法。

通常的解決方案有 Cache 緩存、數據庫的 index 等。

3．以時間換空間
時間換空間的方案解決性能問題的情形比較少。有時會出現在對內存要求十分苛刻的地
方，比如嵌入式操作系統中。

以上是我們從簡單的程序例子來理解性能解決方案，但現實要遠遠復雜得多，因為隨著
軟件系統功能的復雜強大，軟件的規模也在不斷擴大，我們不可能完全自己開發程序，很多
時候是利用已有的平臺和中間件資源。在這種場景下，我們應該怎樣考慮性能問題呢？
第一，軟件系統設計的架構及技術平臺
軟件在設計階段一旦決定采用哪種架構和技術，其性能也就註定只能在一定的範圍內變
動了。這就是“先天”因素。比如在上節講到的一個刪除/增加數據的業務操作，如果用戶對
時間非常苛刻，密集型計算、在線的大數據量統計和分析等應用，這些場景通常 J2EE 不能
夠很好地解決，使用 C++或者其他平臺搭建會更合理些。如果在這些場景下硬要采用 J2EE
架構，那麽開發和設計人員如何絞盡腦汁，優化設計和程序，也不會滿足用戶的性能要求。
第二，中間件的設置和優化
這裏的中間件是廣義的中間件，是應用程序調用的第三方軟件，包括操作系統、數據庫、
Web 服務器、消息服務器等。我們不能改變中間件的程序，只能通過調優手段來提高它所
支持的軟件系統的性能。
第三，硬件的配置
這裏包括服務器硬件配置和網絡環境。服務器硬件包括內存、CPU 等，網絡環境有交
換機、路由器等。

衡量系統性能的常見指標