在明確性能需求時，測試活動相對來說，較爲容易開展。但實際工作中，經常會碰到沒有明確性能需求的測試要求。因此，測試工程師需要具備不同輸入分析，獲取性能測試需求的能力。以ecshop項目爲例，產品團隊並未指明性能測試需求，那麼測試工程師可以按以下方法，分析提取量化的性能指標。
從用戶應用角度考慮，被測試對象常用業務性能存在瓶頸的話，很容易引起用戶的反感。
以登陸功能爲例，輸入用戶名與密碼，點擊登錄按鈕到顯示成功登錄信息，如果耗時1分鐘，這樣的速度用戶絕對無法忍受。用戶不常用，比如年度報表彙總功能，三個季度甚至是一年才使用，等個10分鐘或者更長的時間，也是正常的。
不同的應用頻率，決定了用戶的使用感受，也決定了測試的需求。針對本次ecshop電商系統而已，商城用戶經常時候用的功能，且存在大量用戶使用的業務爲用戶註冊和登陸、隨機瀏覽商品及購買業務等。而其他功能，則相對用戶較少。
具體的數據如果系統已經運營了，則可從系統運營日誌分析。如果尚未上線的運營，則需要調研用戶或根據自身經驗進行分析獲取。
測試工程師，需要根據理論知識，分析哪些是用戶常用或交易佔比超過80%的業務、從運營及項目組角度分析，哪些業務相對重要，然後確定這些業務爲測試點。
綜合分析，以用戶登陸、隨機瀏覽併購買商品爲測試點。確定業務測試點後，即可進行詳細的業務需求分析，從而明確性能測試指標。
通常情況下，性能測試關注被測試對象的時間與資源利用特性及穩定性。
時間特性：即被測試對象實現業務交易過程中所需的處理時間，從用戶角度來說，越短越好。
資源利用特性：即被測試對象的系統資源佔用情況，一般web系統不關注客戶端的資源佔用情況。僅關注服務器端，通常 爲服務器的CPU、內存、網絡帶寬、磁盤等（根據被測試對象架構設計，還可分爲web服務器、中間件、數據庫、負載均衡等）。穩定性，關注被測試對象在一定負載情況下，持續穩定提供服務的能力。
不同的被測試對象，不同的業務需求，可能有不同的指標需求，但大多數測試需求中都包括以下幾個性能指標。
併發數：
併發，即爲同時出發，從應用系統架構層面來看，併發就是單位時間內服務器接受到的請求數。客戶端的某個具體業務行爲包括了若干個請求，因此，併發數被抽象理解爲客戶端單位時間內發送給服務器端的請求，而客戶端的業務請求一般爲用戶操作行爲，因此，併發數，也可理解爲併發用戶數。而這些用戶是虛擬的。又可稱爲虛擬用戶。
併發數，廣義來講，是單位時間內同時發送給服務器的業務請求，不限定具體業務類型，俠義來看，是單位時間內同時發送給服務器的相同的業務請求，需要限定具體業務類型。在性能測試實施過程中需要注意二者的區別。
響應時間：
用戶關注的是：發出請求至看到響應結果的時間，而服務器關注的是接受請求到返回結果的時間。對於用戶而言，忽略了瀏覽器展示的時間，對於服務器而言，則忽略了瀏覽器展示、網絡傳輸等時間。因此，在實際測試過程中，需明確以什麼視角驗證被測試對象的性能。
大多數情況下，性能測試主要是以用戶視角進行。因此在實際測試過程中，通常關注用戶行爲，所以，響應時間一般指客戶端發出請求到接收到服務器端的響應數據所消耗的時間。
需要注意的是，性能測試工作中，客戶有時可能需要測試公網的系統來驗證性能指標，從測試經驗來看，最好不要嘗試在公網進行性能測試，原因是：
- 可能影響現網用戶。實施性能測試過程中，可能產生大量的壓力與垃圾數據。從而破壞生產環境，導致缺陷的產生，影響實際的業務。
- 壓力模擬可能無法真實體現。性能測試工程師實施性能測試時，利用測試工具，來模擬了大量的併發數，產品了大量的業務數據，但因負載生成器所在的網絡與服務器所在的網絡不同，或者服務器的網絡安全設置，導致壓力數據無法達到被測試服務器，整個網絡環境 不可控，從而導致測試失敗。
有一種情況除外，模擬固定寬帶網絡訪問的場景，可在局域網中使用限制寬帶的手段，進行測試。遵循一個原則，測試過程中，任何資源都必須可控。
吞吐量
單位時間內系統處理用戶請求的數量，可以用請求數/單位時間、或者點擊數/單位時間，或者字節數/單位時間等方式來衡量。其中通過字節數/單位時間的計算方式，與當前的網絡帶寬比較，可以找出網絡方面的問題。
例如：1分鐘內系統可以處理1000次轉賬交易，則吞吐量爲1000/60=16.7。
吞吐量指標直接體現了軟件系統的業務處理能力，尤其使用於系統架構選型，做對比測試。
系統資源耗用
客戶端與服務器系統各項硬件資源的耗用情況。如CPU使用率，內存使用率，用戶帶寬佔用率，磁盤I/O輸入輸出量等。一個系統的高效運行，除了軟件資源外，硬件資源也是不可缺少的部分，因此在性能測試過程中，需關注系統資源的耗用。
業務成功率
業務成功率意爲用戶發起了多筆業務請求。成功的比率有多少。如果測試銀行營業系統的併發處理性能，全北京100個網點，中午12:30到13:30一個小時的高峯期裏，要求能支持50000筆開戶業務，其中成功率不少於98%，也就是需要成功開戶49000筆，其他的1000筆可能是超時，或者其他錯誤導致未能開戶成功。
業務成功率展示了在特定壓力或負載情況下，服務器正確穩定處理業務請求的能力。
每秒服務器處理的事務數TPS
單位時間內服務器處理的事務數，該指標值越大，越好。一般情況下，用戶業務操作過程可能細分爲若干個事務，單位時間處理的事務數越多，說明服務器的處理能力越強。
通過上圖分析，業務峯值幾乎在15點-17點及21點-23點左右。業務峯值期待持續2個小時左右。若要測試穩定性，則需根據實際業務情況，模擬用戶真實的應用場景。
確定性能測試評估的時間段後，需確定在該時間段內需完成的業務量。這就需要統計有多少人在這個時間段使用ECShop電商系統，統計這個數據比較難。因爲各個公司運營規模不一樣。這種情況下，測試工程師需根據產品團隊的業務規劃，產品設計給出一個參考值。比如系統初期設計規模在單天15w業務量，峯值交易5000筆，最高併發100用戶（如秒殺業務）等。通過對預設業務目標的分析，可得到以下幾個數據：
- 峯值時間段2個小時
- 單天15w業務量訪問
- 峯值交易5000筆
- 最高併發100用戶
接着分析，滿足上述需求的同時，還需要考慮業務響應時間。被測對象的響應時間，作爲一個很直觀的用戶體驗數據。可很好的衡量被測對象是否讓用戶感受好，但感受好並沒有一個量化的指標。只是個相對的概念。響應時間在業內一個經驗值，根據2-5-8原則，在實際測試中對確定響應時間有很高的參考價值。當然響應時間還應該根據業務類型確定，而不能僅從用戶的感官考慮。本次項目測試採用常規的5秒爲目標，也就是說Ecshop平臺處理登陸、商品隨機瀏覽購買等業務的服務器響應時間均不超過5秒。
看圖得知，用戶訪問並非是均分在24小時內，因此，在沒有歷史數據可依據的情況下，利用經濟學中的’二八原則‘進行分析。80%的業務量集中在20%的時間段內。單天峯值時間段共有2個：15點-17點，21點-23點，可將業務量這麼分解數據：
15w * 80% = 12w
24個小時 * 20% = 4.8小時
4小時 / 4.8小時 = 83%
以15點-17點，21點-23點爲總考察時間段，則期望業務量值爲：
12w * 83% = 9.96w
以15點-17點爲測試考察段，則期望業務量值爲：
12w * （2小時 / 4.8小時） = 5 w
通過上述分析，需測試Ecshop平臺在2小時內支持5w用戶登陸及商品隨機瀏覽購買。
除了軟件性能要求外，還應該對硬件資源進行監控，比如服務器CPU使用率，內存使用率，網絡帶寬等。如果用戶需求，項目組或其他利益相關未提出性能指標要求，則可按照行業經驗，cpu使用率不超過80%、內存使用率不超過80%，網絡帶寬佔用不超過50%。cpu使用率超過80%表面CPU繁忙，如果持續維持在90%甚至更高，很可能導致機器響應慢，死機等問題。當然，過低也不好，說明CPU比較空閒，可能存在資源浪費的問題。對於內存存在同樣的問題，當然，80%只是一個經驗值，最終的性能測試指標需經過評審才能最終確定。
