| | 性能測試是通過自動化的測試工具模擬多種正常、峰值以及異常負載條件來對係統的各項性能指標進行測試。負載測試和壓力測試都屬於性能測試，兩者可以結合進行。通過負載測試，確定在各種工作負載下係統的性能，目標是測試當負載逐漸增加時，係統各項性能指標的變化情況。壓力測試是通過確定一個係統的瓶頸或者不能接收的性能點，來獲得係統能提供的最大服務級別的測試。
一、概述
性能測試在軟件的質量保證中起着重要的作用，它包括的測試內容豐富多樣。中國軟件評測中心將性能測試概括為三個方面：應用在客戶端性能的測試、應用在網絡上性能的測試和應用在服務器端性能的測試。通常情況下，三方面有效、合理的結合，可以達到對係統性能全面的分析和瓶頸的預測。
·應用在客戶端性能的測試
應用在客戶端性能測試的目的是考察客戶端應用的性能，測試的入口是客戶端。它主要包括並發性能測試、疲勞強度測試、大數據量測試和速度測試等，其中並發性能測試是重點。
並發性能測試是重點
並發性能測試的過程是一個負載測試和壓力測試的過程，即逐漸增加負載，直到係統的瓶頸或者不能接收的性能點，通過綜合分析交易執行指標和資源監控指標來確定係統並發性能的過程。負載測試（load testing）是確定在各種工作負載下係統的性能，目標是測試當負載逐漸增加時，係統組成部分的相應輸出項，例如通過量、響應時間、cpu負載、內存使用等來决定係統的性能。負載測試是一個分析軟件應用程序和支撐架構、模擬真實環境的使用，從而來確定能夠接收的性能過程。壓力測試（stress testing）是通過確定一個係統的瓶頸或者不能接收的性能點，來獲得係統能提供的最大服務級別的測試。
並發性能測試的目的主要體現在三個方面：以真實的業務為依據，選擇有代表性的、關鍵的業務操作設計測試案例，以評價係統的當前性能；當擴展應用程序的功能或者新的應用程序將要被部署時，負載測試會幫助確定係統是否還能夠處理期望的用戶負載，以預測係統的未來性能；通過模擬成百上千個用戶，重複執行和運行測試，可以確認性能瓶頸並優化和調整應用，目的在於尋找到瓶頸問題。
當一傢企業自己組織力量或委托軟件公司代為開發一套應用係統的時候,尤其是以後在生産環境中實際使用起來,用戶往往會産生疑問,這套係統能不能承受大量的並發用戶同時訪問? 這類問題最常見於采用聯機事務處理(oltp)方式數據庫應用、web瀏覽和視頻點播等係統。這種問題的解决要藉助於科學的軟件測試手段和先進的測試工具。
舉例說明：電信計費軟件
衆所周知,每月20日左右是市話交費的高峰期，全市幾千個收費網點同時啓動。收費過程一般分為兩步,首先要根據用戶提出的電話號碼來查詢出其當月産生費用,然後收取現金並將此用戶修改為已交費狀態。一個用戶看起來簡單的兩個步驟,但當成百上千的終端，同時執行這樣的操作時，情況就大不一樣了,如此衆多的交易同時發生,對應用程序本身、操作係統、中心數據庫服務器、中間件服務器、網絡設備的承受力都是一個嚴峻的考驗。决策者不可能在發生問題後纔考慮係統的承受力, 預見軟件的並發承受力, 這是在軟件測試階段就應該解决的問題。
目前，大多數公司企業需要支持成百上千名用戶，各類應用環境以及由不同供應商提供的元件組裝起來的復雜産品，難以預知的用戶負載和愈來愈復雜的應用程序，使公司擔憂會發生投放性能差、用戶遭受反應慢、係統失靈等問題。其結果就是導致公司收益的損失。
如何模擬實際情況呢? 找若幹臺電腦和同樣數目的操作人員在同一時刻進行操作,然後拿秒錶記錄下反應時間？ 這樣的手工作坊式的測試方法不切實際，且無法捕捉程序內部變化情況,這樣就需要壓力測試工具的輔助。
測試的基本策略是自動負載測試，通過在一臺或幾臺pc機上模擬成百或上千的虛擬用戶同時執行業務的情景，對應用程序進行測試，同時記錄下每一事務處理的時間、中間件服務器峰值數據、數據庫狀態等。通過可重複的、真實的測試能夠徹底地度量應用的可擴展性和性能，確定問題所在以及優化係統性能。預先知道了係統的承受力,就為最終用戶規劃整個運行環境的配置提供了有力的依據。
並發性能測試前的準備工作
測試環境：配置測試環境是測試實施的一個重要階段，測試環境的適合與否會嚴重影響測試結果的真實性和正確性。測試環境包括硬件環境和軟件環境，硬件環境指測試必需的服務器、客戶端、網絡連接設備以及打印機/掃描儀等輔助硬件設備所構成的環境；軟件環境指被測軟件運行時的操作係統、數據庫及其他應用軟件構成的環境。
一個充分準備好的測試環境有三個優點：一個穩定、可重複的測試環境，能夠保證測試結果的正確；保證達到測試執行的技術需求；保證得到正確的、可重複的以及易理解的測試結果。
測試工具：並發性能測試是在客戶端執行的黑盒測試，一般不采用手工方式，而是利用工具采用自動化方式進行。目前，成熟的並發性能測試工具有很多，選擇的依據主要是測試需求和性能價格比。著名的並發性能測試工具有qaload、loadrunner、benchmark factory和webstress等。這些測試工具都是自動化負載測試工具，通過可重複的、真實的測試，能夠徹底地度量應用的可擴展性和性能，可以在整個開發生命周期、跨越多種平臺、自動執行測試任務，可以模擬成百上千的用戶並發執行關鍵業務而完成對應用程序的測試。
測試數據：在初始的測試環境中需要輸入一些適當的測試數據，目的是識別數據狀態並且驗證用於測試的測試案例，在正式的測試開始以前對測試案例進行調試，將正式測試開始時的錯誤降到最低。在測試進行到關鍵過程環節時，非常有必要進行數據狀態的備份。製造初始數據意味着將合適的數據存儲下來，需要的時候恢復它，初始數據提供了一個基綫用來評估測試執行的結果。
在測試正式執行時，還需要準備業務測試數據，比如測試並發查詢業務，那麽要求對應的數據庫和表中有相當的數據量以及數據的種類應能覆蓋全部業務。
模擬真實環境測試，有些軟件，特別是面嚮大衆的商品化軟件，在測試時常常需要考察在真實環境中的表現。如測試殺毒軟件的掃描速度時，硬盤上佈置的不同類型文件的比例要盡量接近真實環境，這樣測試出來的數據纔有實際意義。
並發性能測試的種類與指標
並發性能測試的種類取决於並發性能測試工具監控的對象，以qaload自動化負載測試工具為例。軟件針對各種測試目標提供了db2、dcom、odbc、oracle、netload、corba、qarun、sap、sqlserver、sybase、telnet、tuxedo、uniface、winsock、www、java script等不同的監控對象，支持windows和unix測試環境。
最關鍵的仍然是測試過程中對監控對象的靈活應用，例如目前三層結構的運行模式廣泛使用，對中間件的並發性能測試作為問題被提到議事日程上來，許多係統都采用了國産中間件，選擇java script監控對象，手工編寫腳本，可以達到測試目的。
采用自動化負載測試工具執行的並發性能測試，基本遵循的測試過程有：測試需求與測試內容，測試案例製定，測試環境準備，測試腳本錄製、編寫與調試，腳本分配、回放配置與加載策略，測試執行跟蹤，結果分析與定位問題所在，測試報告與測試評估。
並發性能測試監控的對象不同，測試的主要指標也不相同，主要的測試指標包括交易處理性能指標和unix資源監控。其中，交易處理性能指標包括交易結果、每分鐘交易數、交易響應時間（min：最小服務器響應時間；mean：平均服務器響應時間；max：最大服務器響應時間；stddev：事務處理服務器響應的偏差，值越大，偏差越大；median：中值響應時間；90％：90％事務處理的服務器響應時間）、虛擬並發用戶數。
應用實例：“新華社多媒體數據庫 v1.0”性能測試
中國軟件評測中心（cstc）根據新華社技術局提出的《多媒體數據庫（一期）性能測試需求》和gb/t 17544《軟件包質量要求和測試》的國傢標準，使用工業標準級負載測試工具對新華社使用的“新華社多媒體數據庫 v1.0”進行了性能測試。
性能測試的目的是模擬多用戶並發訪問新華社多媒體數據庫，執行關鍵檢索業務，分析係統性能。
性能測試的重點是針對係統並發壓力負載較大的主要檢索業務，進行並發測試和疲勞測試，係統采用b/s運行模式。並發測試設計了特定時間段內分別在中文庫、英文庫、圖片庫中進行單檢索詞、多檢索詞以及變檢索式、混合檢索業務等並發測試案例。疲勞測試案例為在中文庫中並發用戶數200，進行測試周期約8小時的單檢索詞檢索。在進行並發和疲勞測試的同時，監測的測試指標包括交易處理性能以及unix（linux）、oracle、apache資源等。
測試結論：在新華社機房測試環境和內網測試環境中，100m帶寬情況下，針對規定的各並發測試案例，係統能夠承受並發用戶數為200的負載壓力，最大交易數/分鐘達到78.73，運行基本穩定，但隨着負載壓力增大，係統性能有所衰減。
係統能夠承受200並發用戶數持續周期約8小時的疲勞壓力，基本能夠穩定運行。
通過對係統unix（linux）、oracle和apache資源的監控，係統資源能夠滿足上述並發和疲勞性能需求，且係統硬件資源尚有較大利用餘地。
當並發用戶數超過200時，監控到http 500、connect和超時錯誤，且web服務器報內存溢出錯誤，係統應進一步提高性能，以支持更大並發用戶數。
建議進一步優化軟件係統，充分利用硬件資源，縮短交易響應時間。
疲勞強度與大數據量測試
疲勞測試是采用係統穩定運行情況下能夠支持的最大並發用戶數，持續執行一段時間業務，通過綜合分析交易執行指標和資源監控指標來確定係統處理最大工作量強度性能的過程。
疲勞強度測試可以采用工具自動化的方式進行測試，也可以手工編寫程序測試，其中後者占的比例較大。
一般情況下以服務器能夠正常穩定響應請求的最大並發用戶數進行一定時間的疲勞測試，獲取交易執行指標數據和係統資源監控數據。如出現錯誤導致測試不能成功執行，則及時調整測試指標，例如降低用戶數、縮短測試周期等。還有一種情況的疲勞測試是對當前係統性能的評估，用係統正常業務情況下並發用戶數為基礎，進行一定時間的疲勞測試。
大數據量測試可以分為兩種類型：針對某些係統存儲、傳輸、統計、查詢等業務進行大數據量的獨立數據量測試；與壓力性能測試、負載性能測試、疲勞性能測試相結合的綜合數據量測試方案。大數據量測試的關鍵是測試數據的準備，可以依靠工具準備測試數據。
速度測試目前主要是針對關鍵有速度要求的業務進行手工測速度，可以在多次測試的基礎上求平均值，可以和工具測得的響應時間等指標做對比分析。
·應用在網絡上性能的測試
應用在網絡上性能的測試重點是利用成熟先進的自動化技術進行網絡應用性能監控、網絡應用性能分析和網絡預測。
網絡應用性能分析
網絡應用性能分析的目的是準確展示網絡帶寬、延遲、負載和tcp端口的變化是如何影響用戶的響應時間的。利用網絡應用性能分析工具，例如application expert，能夠發現應用的瓶頸，我們可知應用在網絡上運行時在每個階段發生的應用行為，在應用綫程級分析應用的問題。可以解决多種問題：客戶端是否對數據庫服務器運行了不必要的請求？當服務器從客戶端接受了一個查詢，應用服務器是否花費了不可接受的時間聯繫數據庫服務器？在投産前預測應用的響應時間；利用application expert調整應用在廣域網上的性能；application expert能夠讓你快速、容易地仿真應用性能，根據最終用戶在不同網絡配置環境下的響應時間，用戶可以根據自己的條件决定應用投産的網絡環境。
網絡應用性能監控
在係統試運行之後，需要及時準確地瞭解網絡上正在發生什麽事情；什麽應用在運行，如何運行；多少pc正在訪問lan或wan；哪些應用程序導致係統瓶頸或資源競爭，這時網絡應用性能監控以及網絡資源管理對係統的正常穩定運行是非常關鍵的。利用網絡應用性能監控工具，可以達到事半功倍的效果，在這方面我們可以提供的工具是network vantage。通俗地講，它主要用來分析關鍵應用程序的性能，定位問題的根源是在客戶端、服務器、應用程序還是網絡。在大多數情況下用戶較關心的問題還有哪些應用程序占用大量帶寬，哪些用戶産生了最大的網絡流量，這個工具同樣能滿足要求。
網絡預測
考慮到係統未來發展的擴展性，預測網絡流量的變化、網絡結構的變化對用戶係統的影響非常重要。根據規劃數據進行預測並及時提供網絡性能預測數據。我們利用網絡預測分析容量規劃工具predictor可以作到：設置服務水平、完成日網絡容量規劃、離綫測試網絡、網絡失效和容量極限分析、完成日常故障診斷、預測網絡設備遷移和網絡設備升級對整個網絡的影響。
從網絡管理軟件獲取網絡拓撲結構、從現有的流量監控軟件獲取流量信息（若沒有這類軟件可人工生成流量數據），這樣可以得到現有網絡的基本結構。在基本結構的基礎上，可根據網絡結構的變化、網絡流量的變化生成報告和圖表，說明這些變化是如何影響網絡性能的。 predictor提供如下信息：根據預測的結果幫助用戶及時升級網絡，避免因關鍵設備超過利用閥值導致係統性能下降；哪個網絡設備需要升級，這樣可減少網絡延遲、避免網絡瓶頸；根據預測的結果避免不必要的網絡升級。
·應用在服務器上性能的測試
對於應用在服務器上性能的測試，可以采用工具監控，也可以使用係統本身的監控命令，例如tuxedo中可以使用top命令監控資源使用情況。實施測試的目的是實現服務器設備、服務器操作係統、數據庫係統、應用在服務器上性能的全面監控，測試原理如下圖。
unix資源監控指標和描述
監控指標 描述
平均負載 係統正常狀態下，最後60秒同步進程的平均個數
衝突率 在以太網上監測到的每秒衝突數
進程/綫程交換率 進程和綫程之間每秒交換次數
cpu利用率 cpu占用率（％）
磁盤交換率 磁盤交換速率
接收包錯誤率 接收以太網數據包時每秒錯誤數
包輸入率 每秒輸入的以太網數據包數目
中斷速率 cpu每秒處理的中斷數
輸出包錯誤率 發送以太網數據包時每秒錯誤數
包輸入率 每秒輸出的以太網數據包數目
讀入內存頁速率 物理內存中每秒讀入內存頁的數目
寫出內存頁速率 每秒從物理內存中寫到頁文件中的內存頁數
目或者從物理內存中刪掉的內存頁數目
內存頁交換速率 每秒寫入內存頁和從物理內存中讀出頁的個數
進程入交換率 交換區輸入的進程數目
進程出交換率 交換區輸出的進程數目
係統cpu利用率 係統的cpu占用率（％）
用戶cpu利用率 用戶模式下的cpu占用率（％）
磁盤阻塞 磁盤每秒阻塞的字節數
二、為什麽進行性能測試？
目的是驗證軟件係統是否能夠達到用戶提出的性能指標，同時發現軟件係統中存在的性能瓶頸，優化軟件，最後起到優化係統的目的。
包括以下幾個方面
1．評估係統的能力，測試中得到的負荷和響應時間數據可以被用於驗證所計劃的模型的能力，並幫助作出决策。
2．識別體係中的弱點：受控的負荷可以被增加到一個極端的水平，並突破它，從而修復體係的瓶頸或薄弱的地方。
3．係統調優：重複運行測試，驗證調整係統的活動得到了預期的結果，從而改進性能。
檢測軟件中的問題：長時間的測試執行可導致程序發生由於內存泄露引起的失敗，揭示程序中的隱含的問題或衝突。
4．驗證穩定性（resilience）可靠性（reliability）：在一個生産負荷下執行測試一定的時間是評估係統穩定性和可靠性是否滿足要求的唯一方法。
性能測試類型包括負載測試，強度測試，容量測試等
負載測試：負載測試是一種性能測試指數據在超負荷環境中運行，程序是否能夠承擔。
強度測試： 強度測試是一種性能測試，他在係統資源特別低的情況下軟件係統運行情況。
容量測試：確定係統可處理同時在綫的最大用戶數
觀察指標：
性能測試主要是通過自動化的測試工具模擬多種正常、峰值以及異常負載條件來對係統的各項性能指標進行測試。負載測試和壓力測試都屬於性能測試，兩者可以結合進行。通過負載測試，確定在各種工作負載下係統的性能，目標是測試當負載逐漸增加時，係統各項性能指標的變化情況。壓力測試是通過確定一個係統的瓶頸或者不能接收的性能點，來獲得係統能提供的最大服務級別的測試。
在實際中作中我們經常會對兩種類型軟件進行測試：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：數據庫死鎖；
* butter cache hit ：數據庫cache的命中情況
當然，在實際中我們還會察看多用戶測試情況下的內存，cpu，係統資源調用情況。這些指標其實是引申出來性能測試中的一種：競爭測試。什麽是競爭測試，軟件競爭使用各種資源（數據紀錄，內存等），看他與其他相關係統對資源的爭奪能力。
我們知道軟件架構在實際測試中製約着測試策略和工具的選擇。如何選擇性能測試策略是我們在實際工作中需要瞭解的。一般軟件可以按照係統架構分成幾種類型：
c/s
client/server 客戶端/服務器架構
基於客戶端/服務器的三層架構
基於客戶端/服務器的分佈式架構
b/s
基於瀏覽器/web服務器的三層架構
基於中間件應用服務器的三層架構l
基於web服務器和中間件的多層架構l
三、性能測試的步驟
在每種不同的係統架構的實施中，開發人員可能選擇不同的實現方式，造成實際情況紛繁復雜。我們不可能對每種技術都詳細解說，這裏衹是介紹一種方法提供給你如何選擇測試策略，從而幫助分析軟件不同部分的性能指標，進而分析出整體架構的性能指標和性能瓶頸。
由於工程和項目的不同，所選用的度量,評估方法也有不同之處。不過仍然有一些通用的步驟幫助我們完成一個性能測試項目。步驟如下
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結構我們可能更關心會係統整體配置對用戶操作的影響。
四、性能測試方法
對於企業應用程序，有許多進行性能測試的方法，其中一些方法實行起來要比其他方法睏難。所要進行的性能測試的類型取决於想要達到的結果。例如，對於可再現性，基準測試是最好的方法。而要從當前用戶負載的角度測試係統的上限，則應該使用容量規劃測試。本文將介紹幾種設置和運行性能測試的方法，並討論這些方法的區別。
如果不進行合理的規劃，對j2ee應用程序進行性能測試將會是一項令人望而生畏且有些混亂的任務。因為對於任何的軟件開發流程，都必須收集需求、理解業務需要，並在進行實際測試之前設計出正式的進度表。性能測試的需求由業務需要驅動，並由一組用例闡明。這些用例可以基於歷史數據（例如，服務器一周的負載模式）或預測的近似值。弄清楚需要測試的內容之後，就需要知道如何進行測試了。
在開發階段前期，應該使用基準測試來確定應用程序中是否出現性能倒退。基準測試可以在一個相對短的時間內收集可重複的結果。進行基準測試的最好方法是，每次測試改變一個且衹改變一個參數。例如，如果想知道增加jvm內存是否會影響應用程序的性能，就逐次遞增jvm內存（例如，從1024 mb增至1224 mb，然後是1524 mb，最後是2024 mb），在每個階段收集結果和環境數據，記錄信息，然後轉到下一階段。這樣在分析測試結果時就有跡可循。下一小節我將介紹什麽是基準測試，以及運行基準測試的最佳參數。
開發階段後期，在應用程序中的bug已經被解决，應用程序達到一種穩定狀態之後，可以運行更為復雜的測試，確定係統在不同的負載模式下的表現。這些測試被稱為容量規劃測試、滲入測試(soak test)、峰𠔌測試(peak-rest test)，它們旨在通過測試應用程序的可靠性、健壯性和可伸縮性來測試接近於現實世界的場景。對於下面的描述應該從抽象的意義上理解，因為每個應用程序的使用模式都是不同的。例如，容量規劃測試通常都使用較緩慢的ramp-up（下文有定義），但是如果應用程序在一天之中的某個時段中有快速突發的流量，那麽自然應該修改測試以反映這種情況。但是，要記住，因為更改了測試參數（比如ramp-up周期或用戶的考慮時間(think-time)），測試的結果肯定也會改變。一個不錯的方法是，運行一係列的基準測試，確立一個已知的可控環境，然後再對變化進行比較。
基準測試
基準測試的關鍵是要獲得一致的、可再現的結果。可再現的結果有兩個好處：減少重新運行測試的次數；對測試的産品和産生的數字更為確信。使用的性能測試工具可能會對測試結果産生很大影響。假定測試的兩個指標是服務器的響應時間和吞吐量，它們會受到服務器上的負載的影響。服務器上的負載受兩個因素影響：同時與服務器通信的連接（或虛擬用戶）的數目，以及每個虛擬用戶請求之間的考慮時間的長短。很明顯，與服務器通信的用戶越多，負載就越大。同樣，請求之間的考慮時間越短，負載也越大。這兩個因素的不同組合會産生不同的服務器負載等級。記住，隨着服務器上負載的增加，吞吐量會不斷攀升，直到到達一個點。
註意，吞吐量以穩定的速度增長，然後在某一個點上穩定下來。
在某一點上，執行隊列開始增長，因為服務器上所有的綫程都已投入使用，傳入的請求不再被立即處理，而是放入隊列中，當綫程空閑時再處理。
註意，最初的一段時間，執行隊列的長度為零，然後就開始以穩定的速度增長。這是因為係統中的負載在穩定增長，雖然最初係統有足夠的空閑綫程去處理增加的負載，最終它還是不能承受，而必須將其排入隊列。
當係統達到飽和點，服務器吞吐量保持穩定後，就達到了給定條件下的係統上限。但是，隨着服務器負載的繼續增長，係統的響應時間也隨之延長，雖然吞吐量保持穩定。
註意，在執行隊列（圖2）開始增長的同時，響應時間也開始以遞增的速度增長。這是因為請求不能被及時處理。
為了獲得真正可再現的結果，應該將係統置於相同的高負載下。為此，與服務器通信的虛擬用戶應該將請求之間的考慮時間設為零。這樣服務器會立即超載，並開始構建執行隊列。如果請求（虛擬用戶）數保持一致，基準測試的結果應該會非常精確，完全可以再現。
您可能要問的一個問題是：“如何度量結果？”對於一次給定的測試，應該取響應時間和吞吐量的平均值。精確地獲得這些值的唯一方法是一次加載所有的用戶，然後在預定的時間段內持續運行。這稱為“flat”測試。
與此相對應的是“ramp-up”測試。
ramp-up測試中的用戶是交錯上升的（每幾秒增加一些新用戶）。ramp-up測試不能産生精確和可重現的平均值，這是因為由於用戶的增加是每次一部分，係統的負載在不斷地變化。因此，flat運行是獲得基準測試數據的理想模式。
這不是在貶低ramp-up測試的價值。實際上，ramp-up測試對找出以後要運行的flat測試的範圍非常有用。ramp-up測試的優點是，可以看出隨着係統負載的改變，測量值是如何改變的。然後可以據此選擇以後要運行的flat測試的範圍。
flat測試的問題是係統會遇到“波動”效果。
）
註意波動的出現，吞吐量不再是平滑的。
這在係統的各個方面都有所體現，包括cpu的使用量。
註意，每隔一段時間就會出現一個波形。cpu使用量不再是平滑的，而是有了像吞吐量圖那樣的尖峰。
此外，執行隊列也承受着不穩定的負載，因此可以看到，隨着係統負載的增加和減少，執行隊列也在增長和縮減。
註意，每隔一段時間就會出現一個波形。執行隊列麯綫與上面的cpu使用量圖非常相似。
最後，係統中事務的響應時間也遵循着這個波動模式。
註意，每隔一段時間就會出現一個波形。事務的響應時間也與上面的圖類似，衹不過其效果隨着時間的推移逐漸減弱。
當測試中所有的用戶都同時執行幾乎相同的操作時，就會發生這種現象。這將會産生非常不可靠和不精確的結果，所以必須采取一些措施防止這種情況的出現。有兩種方法可以從這種類型的結果中獲得精確的測量值。如果測試可以運行相當長的時間（有時是幾個小時，取决於用戶的操作持續的時間），最後由於隨機事件的本性使然，服務器的吞吐量會被“拉平”。或者，可以衹選取波形中兩個平息點之間的測量值。該方法的缺點是可以捕獲數據的時間非常短。
性能規劃測試
對於性能規劃類型的測試來說，其目標是找出，在特定的環境下，給定應用程序的性能可以達到何種程度。此時可重現性就不如在基準測試中那麽重要了，因為測試中通常都會有隨機因子。引入隨機因子的目的是為了盡量模擬具有真實用戶負載的現實世界應用程序。通常，具體的目標是找出係統在特定的服務器響應時間下支持的當前用戶的最大數。例如，您可能想知道：如果要以5秒或更少的響應時間支持8,000個當前用戶，需要多少個服務器？要回答這個問題，需要知道係統的更多信息。
要確定係統的容量，需要考慮幾個因素。通常，服務器的用戶總數非常大（以十萬計），但是實際上，這個數字並不能說明什麽。真正需要知道的是，這些用戶中有多少是並發與服務器通信的。其次要知道的是，每個用戶的“考慮時間”即請求間時間是多少。這非常重要，因為考慮時間越短，係統所能支持的並發用戶越少。例如，如果用戶的考慮時間是1秒，那麽係統可能衹能支持數百個這樣的並發用戶。但是，如果用戶的考慮時間是30秒，那麽係統則可能支持數萬個這樣的並發用戶（假定硬件和應用程序都是相同的）。在現實世界中，通常難以確定用戶的確切考慮時間。還要註意，在現實世界中，用戶不會精確地按照間隔時間發出請求。
於是就引入了隨機性。如果知道普通用戶的考慮時間是5秒，誤差為20%，那麽在設計負載測試時，就要確保請求間的時間為5×（1 +/- 20%）秒。此外，可以利用“調步”的理念嚮負載場景中引入更多的隨機性。它是這樣的：在一個虛擬用戶完成一整套的請求後，該用戶暫停一個設定的時間段，或者一個小的隨機時間段（例如，2×（1 +/- 25%）秒），然後再繼續執行下一套請求。將這兩種隨機化方法運用到測試中，可以提供更接近於現實世界的場景。
現在該進行實際的容量規劃測試了。接下來的問題是：如何加載用戶以模擬負載狀態？最好的方法是模擬高峰時間用戶與服務器通信的狀況。這種用戶負載狀態是在一段時間內逐步達到的嗎？如果是，應該使用ramp-up類型的測試，每隔幾秒增加x個用戶。或者，所有用戶是在一個非常短的時間內同時與係統通信？如果是這樣，就應該使用flat類型的測試，將所有的用戶同時加載到服務器。兩種不同類型的測試會産生沒有可比性的不同測試。例如，如果進行ramp-up類型的測試，係統可以以4秒或更短的響應時間支持5,000個用戶。而執行flat測試，您會發現，對於5,000個用戶，係統的平均響應時間要大於4秒。這是由於ramp-up測試固有的不準確性使其不能顯示係統可以支持的並發用戶的精確數字。以門戶應用程序為例，隨着門戶規模的擴大和集群規模的擴大，這種不確定性就會隨之顯現。
這不是說不應該使用ramp-up測試。對於係統負載在一段比較長的時間內緩慢增加的情況，ramp-up測試效果還是不錯的。這是因為係統能夠隨着時間不斷調整。如果使用快速ramp-up測試，係統就會滯後，從而報告一個較相同用戶負載的flat測試低的響應時間。那麽，什麽是確定容量的最好方法？結合兩種負載類型的優點，並運行一係列的測試，就會産生最好的結果。例如，首先使用ramp-up測試確定係統可以支持的用戶範圍。確定了範圍之後，以該範圍內不同的並發用戶負載進行一係列的flat測試，更精確地確定係統的容量。
滲入測試
滲入測試是一種比較簡單的性能測試。滲入測試所需時間較長，它使用固定數目的並發用戶測試係統的總體健壯性。這些測試將會通過內存泄漏、增加的垃圾收集(gc)或係統的其他問題，顯示因長時間運行而出現的任何性能降低。測試運行的時間越久，您對係統就越瞭解。運行兩次測試是一個好主意——一次使用較低的用戶負載（要在係統容量之下，以便不會出現執行隊列），一次使用較高的負載（以便出現積極的執行隊列）。
測試應該運行幾天的時間，以便真正瞭解應用程序的長期健康狀況。要確保測試的應用程序盡可能接近現實世界的情況，用戶場景也要逼真（虛擬用戶通過應用程序導航的方式要與現實世界一致），從而測試應用程序的全部特性。確保運行了所有必需的監控工具，以便精確地監測並跟蹤問題。
峰𠔌測試
峰𠔌測試兼有容量規劃ramp-up類型測試和滲入測試的特徵。其目標是確定從高負載（例如係統高峰時間的負載）恢復、轉為幾乎空閑、然後再攀升到高負載、再降低的能力。
實現這種測試的最好方法就是，進行一係列的快速ramp-up測試，繼之以一段時間的平穩狀態（取决於業務需求），然後急劇降低負載，此時可以令係統平息一下，然後再進行快速的ramp-up；反復重複這個過程。這樣可以確定以下事項：第二次高峰是否重現第一次的峰值？其後的每次高峰是等於還是大於第一次的峰值？在測試過程中，係統是否顯示了內存或gc性能降低的有關跡象？測試運行（不停地重複“峰值/空閑”周期）的時間越長，您對係統的長期健康狀況就越瞭解。
結束語
本文介紹了進行性能測試的幾種方法。取决於業務需求、開發周期和應用程序的生命周期，對於特定的企業，某些測試會比其他的更適合。但是，對於任何情況，在决定進行某一種測試前，都應該問自己一些基本問題。這些問題的答案將會决定哪種測試方法是最好的。
這些問題包括：
結果的可重複性需要有多高？
測試需要運行和重新運行幾次？
您處於開放周期的哪個階段？
您的業務需求是什麽？
您的用戶需求是什麽？
您希望生産中的係統在維護停機時間中可以持續多久？
在一個正常的業務日，預期的用戶負載是多少？
將這些問題的答案與上述性能測試類型相對照，應該就可以製定出測試應用程序的總體性能的完美計劃。 | | 性能測試是通過自動化的測試工具模擬多種正常、峰值以及異常負載條件來對係統的各項性能指標進行測試。負載測試和壓力測試都屬於性能測試，兩者可以結合進行。通過負載測試，確定在各種工作負載下係統的性能，目標是測試當負載逐漸增加時，係統各項性能指標的變化情況。壓力測試是通過確定一個係統的瓶頸或者不能接收的性能點，來獲得係統能提供的最大服務級別的測試。
一、概述
性能測試在軟件的質量保證中起着重要的作用，它包括的測試內容豐富多樣。中國軟件評測中心將性能測試概括為三個方面：應用在客戶端性能的測試、應用在網絡上性能的測試和應用在服務器端性能的測試。通常情況下，三方面有效、合理的結合，可以達到對係統性能全面的分析和瓶頸的預測。
·應用在客戶端性能的測試
應用在客戶端性能測試的目的是考察客戶端應用的性能，測試的入口是客戶端。它主要包括並發性能測試、疲勞強度測試、大數據量測試和速度測試等，其中並發性能測試是重點。
並發性能測試是重點
並發性能測試的過程是一個負載測試和壓力測試的過程，即逐漸增加負載，直到係統的瓶頸或者不能接收的性能點，通過綜合分析交易執行指標和資源監控指標來確定係統並發性能的過程。負載測試（Load Testing）是確定在各種工作負載下係統的性能，目標是測試當負載逐漸增加時，係統組成部分的相應輸出項，例如通過量、響應時間、CPU負載、內存使用等來决定係統的性能。負載測試是一個分析軟件應用程序和支撐架構、模擬真實環境的使用，從而來確定能夠接收的性能過程。壓力測試（Stress Testing）是通過確定一個係統的瓶頸或者不能接收的性能點，來獲得係統能提供的最大服務級別的測試。
並發性能測試的目的主要體現在三個方面：以真實的業務為依據，選擇有代表性的、關鍵的業務操作設計測試案例，以評價係統的當前性能；當擴展應用程序的功能或者新的應用程序將要被部署時，負載測試會幫助確定係統是否還能夠處理期望的用戶負載，以預測係統的未來性能；通過模擬成百上千個用戶，重複執行和運行測試，可以確認性能瓶頸並優化和調整應用，目的在於尋找到瓶頸問題。
當一傢企業自己組織力量或委托軟件公司代為開發一套應用係統的時候,尤其是以後在生産環境中實際使用起來,用戶往往會産生疑問,這套係統能不能承受大量的並發用戶同時訪問? 這類問題最常見於采用聯機事務處理(OLTP)方式數據庫應用、Web瀏覽和視頻點播等係統。這種問題的解决要藉助於科學的軟件測試手段和先進的測試工具。
舉例說明：電信計費軟件
衆所周知,每月20日左右是市話交費的高峰期，全市幾千個收費網點同時啓動。收費過程一般分為兩步,首先要根據用戶提出的電話號碼來查詢出其當月産生費用,然後收取現金並將此用戶修改為已交費狀態。一個用戶看起來簡單的兩個步驟,但當成百上千的終端，同時執行這樣的操作時，情況就大不一樣了,如此衆多的交易同時發生,對應用程序本身、操作係統、中心數據庫服務器、中間件服務器、網絡設備的承受力都是一個嚴峻的考驗。决策者不可能在發生問題後纔考慮係統的承受力, 預見軟件的並發承受力, 這是在軟件測試階段就應該解决的問題。
目前，大多數公司企業需要支持成百上千名用戶，各類應用環境以及由不同供應商提供的元件組裝起來的復雜産品，難以預知的用戶負載和愈來愈復雜的應用程序，使公司擔憂會發生投放性能差、用戶遭受反應慢、係統失靈等問題。其結果就是導致公司收益的損失。
如何模擬實際情況呢? 找若幹臺電腦和同樣數目的操作人員在同一時刻進行操作,然後拿秒錶記錄下反應時間？ 這樣的手工作坊式的測試方法不切實際，且無法捕捉程序內部變化情況,這樣就需要壓力測試工具的輔助。
測試的基本策略是自動負載測試，通過在一臺或幾臺PC機上模擬成百或上千的虛擬用戶同時執行業務的情景，對應用程序進行測試，同時記錄下每一事務處理的時間、中間件服務器峰值數據、數據庫狀態等。通過可重複的、真實的測試能夠徹底地度量應用的可擴展性和性能，確定問題所在以及優化係統性能。預先知道了係統的承受力,就為最終用戶規劃整個運行環境的配置提供了有力的依據。
並發性能測試前的準備工作
測試環境：配置測試環境是測試實施的一個重要階段，測試環境的適合與否會嚴重影響測試結果的真實性和正確性。測試環境包括硬件環境和軟件環境，硬件環境指測試必需的服務器、客戶端、網絡連接設備以及打印機/掃描儀等輔助硬件設備所構成的環境；軟件環境指被測軟件運行時的操作係統、數據庫及其他應用軟件構成的環境。
一個充分準備好的測試環境有三個優點：一個穩定、可重複的測試環境，能夠保證測試結果的正確；保證達到測試執行的技術需求；保證得到正確的、可重複的以及易理解的測試結果。
測試工具：並發性能測試是在客戶端執行的黑盒測試，一般不采用手工方式，而是利用工具采用自動化方式進行。目前，成熟的並發性能測試工具有很多，選擇的依據主要是測試需求和性能價格比。著名的並發性能測試工具有QALoad、LoadRunner、Benchmark Factory和Webstress等。這些測試工具都是自動化負載測試工具，通過可重複的、真實的測試，能夠徹底地度量應用的可擴展性和性能，可以在整個開發生命周期、跨越多種平臺、自動執行測試任務，可以模擬成百上千的用戶並發執行關鍵業務而完成對應用程序的測試。
測試數據：在初始的測試環境中需要輸入一些適當的測試數據，目的是識別數據狀態並且驗證用於測試的測試案例，在正式的測試開始以前對測試案例進行調試，將正式測試開始時的錯誤降到最低。在測試進行到關鍵過程環節時，非常有必要進行數據狀態的備份。製造初始數據意味着將合適的數據存儲下來，需要的時候恢復它，初始數據提供了一個基綫用來評估測試執行的結果。
在測試正式執行時，還需要準備業務測試數據，比如測試並發查詢業務，那麽要求對應的數據庫和表中有相當的數據量以及數據的種類應能覆蓋全部業務。
模擬真實環境測試，有些軟件，特別是面嚮大衆的商品化軟件，在測試時常常需要考察在真實環境中的表現。如測試殺毒軟件的掃描速度時，硬盤上佈置的不同類型文件的比例要盡量接近真實環境，這樣測試出來的數據纔有實際意義。
並發性能測試的種類與指標
並發性能測試的種類取决於並發性能測試工具監控的對象，以QALoad自動化負載測試工具為例。軟件針對各種測試目標提供了DB2、DCOM、ODBC、ORACLE、NETLoad、Corba、QARun、SAP、SQLServer、Sybase、Telnet、TUXEDO、UNIFACE、WinSock、WWW、Java Script等不同的監控對象，支持Windows和UNIX測試環境。
最關鍵的仍然是測試過程中對監控對象的靈活應用，例如目前三層結構的運行模式廣泛使用，對中間件的並發性能測試作為問題被提到議事日程上來，許多係統都采用了國産中間件，選擇Java Script監控對象，手工編寫腳本，可以達到測試目的。
采用自動化負載測試工具執行的並發性能測試，基本遵循的測試過程有：測試需求與測試內容，測試案例製定，測試環境準備，測試腳本錄製、編寫與調試，腳本分配、回放配置與加載策略，測試執行跟蹤，結果分析與定位問題所在，測試報告與測試評估。
並發性能測試監控的對象不同，測試的主要指標也不相同，主要的測試指標包括交易處理性能指標和UNIX資源監控。其中，交易處理性能指標包括交易結果、每分鐘交易數、交易響應時間（Min：最小服務器響應時間；Mean：平均服務器響應時間；Max：最大服務器響應時間；StdDev：事務處理服務器響應的偏差，值越大，偏差越大；Median：中值響應時間；90％：90％事務處理的服務器響應時間）、虛擬並發用戶數。
應用實例：“新華社多媒體數據庫 V1.0”性能測試
中國軟件評測中心（CSTC）根據新華社技術局提出的《多媒體數據庫（一期）性能測試需求》和GB/T 17544《軟件包質量要求和測試》的國傢標準，使用工業標準級負載測試工具對新華社使用的“新華社多媒體數據庫 V1.0”進行了性能測試。
性能測試的目的是模擬多用戶並發訪問新華社多媒體數據庫，執行關鍵檢索業務，分析係統性能。
性能測試的重點是針對係統並發壓力負載較大的主要檢索業務，進行並發測試和疲勞測試，係統采用B/S運行模式。並發測試設計了特定時間段內分別在中文庫、英文庫、圖片庫中進行單檢索詞、多檢索詞以及變檢索式、混合檢索業務等並發測試案例。疲勞測試案例為在中文庫中並發用戶數200，進行測試周期約8小時的單檢索詞檢索。在進行並發和疲勞測試的同時，監測的測試指標包括交易處理性能以及UNIX（Linux）、Oracle、Apache資源等。
測試結論：在新華社機房測試環境和內網測試環境中，100M帶寬情況下，針對規定的各並發測試案例，係統能夠承受並發用戶數為200的負載壓力，最大交易數/分鐘達到78.73，運行基本穩定，但隨着負載壓力增大，係統性能有所衰減。
係統能夠承受200並發用戶數持續周期約8小時的疲勞壓力，基本能夠穩定運行。
通過對係統UNIX（Linux）、Oracle和Apache資源的監控，係統資源能夠滿足上述並發和疲勞性能需求，且係統硬件資源尚有較大利用餘地。
當並發用戶數超過200時，監控到HTTP 500、connect和超時錯誤，且Web服務器報內存溢出錯誤，係統應進一步提高性能，以支持更大並發用戶數。
建議進一步優化軟件係統，充分利用硬件資源，縮短交易響應時間。
疲勞強度與大數據量測試
疲勞測試是采用係統穩定運行情況下能夠支持的最大並發用戶數，持續執行一段時間業務，通過綜合分析交易執行指標和資源監控指標來確定係統處理最大工作量強度性能的過程。
疲勞強度測試可以采用工具自動化的方式進行測試，也可以手工編寫程序測試，其中後者占的比例較大。
一般情況下以服務器能夠正常穩定響應請求的最大並發用戶數進行一定時間的疲勞測試，獲取交易執行指標數據和係統資源監控數據。如出現錯誤導致測試不能成功執行，則及時調整測試指標，例如降低用戶數、縮短測試周期等。還有一種情況的疲勞測試是對當前係統性能的評估，用係統正常業務情況下並發用戶數為基礎，進行一定時間的疲勞測試。
大數據量測試可以分為兩種類型：針對某些係統存儲、傳輸、統計、查詢等業務進行大數據量的獨立數據量測試；與壓力性能測試、負載性能測試、疲勞性能測試相結合的綜合數據量測試方案。大數據量測試的關鍵是測試數據的準備，可以依靠工具準備測試數據。
速度測試目前主要是針對關鍵有速度要求的業務進行手工測速度，可以在多次測試的基礎上求平均值，可以和工具測得的響應時間等指標做對比分析。
·應用在網絡上性能的測試
應用在網絡上性能的測試重點是利用成熟先進的自動化技術進行網絡應用性能監控、網絡應用性能分析和網絡預測。
網絡應用性能分析
網絡應用性能分析的目的是準確展示網絡帶寬、延遲、負載和TCP端口的變化是如何影響用戶的響應時間的。利用網絡應用性能分析工具，例如Application Expert，能夠發現應用的瓶頸，我們可知應用在網絡上運行時在每個階段發生的應用行為，在應用綫程級分析應用的問題。可以解决多種問題：客戶端是否對數據庫服務器運行了不必要的請求？當服務器從客戶端接受了一個查詢，應用服務器是否花費了不可接受的時間聯繫數據庫服務器？在投産前預測應用的響應時間；利用Application Expert調整應用在廣域網上的性能；Application Expert能夠讓你快速、容易地仿真應用性能，根據最終用戶在不同網絡配置環境下的響應時間，用戶可以根據自己的條件决定應用投産的網絡環境。
網絡應用性能監控
在係統試運行之後，需要及時準確地瞭解網絡上正在發生什麽事情；什麽應用在運行，如何運行；多少PC正在訪問LAN或WAN；哪些應用程序導致係統瓶頸或資源競爭，這時網絡應用性能監控以及網絡資源管理對係統的正常穩定運行是非常關鍵的。利用網絡應用性能監控工具，可以達到事半功倍的效果，在這方面我們可以提供的工具是Network Vantage。通俗地講，它主要用來分析關鍵應用程序的性能，定位問題的根源是在客戶端、服務器、應用程序還是網絡。在大多數情況下用戶較關心的問題還有哪些應用程序占用大量帶寬，哪些用戶産生了最大的網絡流量，這個工具同樣能滿足要求。
網絡預測
考慮到係統未來發展的擴展性，預測網絡流量的變化、網絡結構的變化對用戶係統的影響非常重要。根據規劃數據進行預測並及時提供網絡性能預測數據。我們利用網絡預測分析容量規劃工具PREDICTOR可以作到：設置服務水平、完成日網絡容量規劃、離綫測試網絡、網絡失效和容量極限分析、完成日常故障診斷、預測網絡設備遷移和網絡設備升級對整個網絡的影響。
從網絡管理軟件獲取網絡拓撲結構、從現有的流量監控軟件獲取流量信息（若沒有這類軟件可人工生成流量數據），這樣可以得到現有網絡的基本結構。在基本結構的基礎上，可根據網絡結構的變化、網絡流量的變化生成報告和圖表，說明這些變化是如何影響網絡性能的。 PREDICTOR提供如下信息：根據預測的結果幫助用戶及時升級網絡，避免因關鍵設備超過利用閥值導致係統性能下降；哪個網絡設備需要升級，這樣可減少網絡延遲、避免網絡瓶頸；根據預測的結果避免不必要的網絡升級。
·應用在服務器上性能的測試
對於應用在服務器上性能的測試，可以采用工具監控，也可以使用係統本身的監控命令，例如Tuxedo中可以使用Top命令監控資源使用情況。實施測試的目的是實現服務器設備、服務器操作係統、數據庫係統、應用在服務器上性能的全面監控，測試原理如下圖。
UNIX資源監控指標和描述
監控指標 描述
平均負載 係統正常狀態下，最後60秒同步進程的平均個數
衝突率 在以太網上監測到的每秒衝突數
進程/綫程交換率 進程和綫程之間每秒交換次數
CPU利用率 CPU占用率（％）
磁盤交換率 磁盤交換速率
接收包錯誤率 接收以太網數據包時每秒錯誤數
包輸入率 每秒輸入的以太網數據包數目
中斷速率 CPU每秒處理的中斷數
輸出包錯誤率 發送以太網數據包時每秒錯誤數
包輸入率 每秒輸出的以太網數據包數目
讀入內存頁速率 物理內存中每秒讀入內存頁的數目
寫出內存頁速率 每秒從物理內存中寫到頁文件中的內存頁數
目或者從物理內存中刪掉的內存頁數目
內存頁交換速率 每秒寫入內存頁和從物理內存中讀出頁的個數
進程入交換率 交換區輸入的進程數目
進程出交換率 交換區輸出的進程數目
係統CPU利用率 係統的CPU占用率（％）
用戶CPU利用率 用戶模式下的CPU占用率（％）
磁盤阻塞 磁盤每秒阻塞的字節數
二、為什麽進行性能測試？
目的是驗證軟件係統是否能夠達到用戶提出的性能指標，同時發現軟件係統中存在的性能瓶頸，優化軟件，最後起到優化係統的目的。
包括以下幾個方面
1．評估係統的能力，測試中得到的負荷和響應時間數據可以被用於驗證所計劃的模型的能力，並幫助作出决策。
2．識別體係中的弱點：受控的負荷可以被增加到一個極端的水平，並突破它，從而修復體係的瓶頸或薄弱的地方。
3．係統調優：重複運行測試，驗證調整係統的活動得到了預期的結果，從而改進性能。
檢測軟件中的問題：長時間的測試執行可導致程序發生由於內存泄露引起的失敗，揭示程序中的隱含的問題或衝突。
4．驗證穩定性（resilience）可靠性（reliability）：在一個生産負荷下執行測試一定的時間是評估係統穩定性和可靠性是否滿足要求的唯一方法。
性能測試類型包括負載測試，強度測試，容量測試等
負載測試：負載測試是一種性能測試指數據在超負荷環境中運行，程序是否能夠承擔。
強度測試： 強度測試是一種性能測試，他在係統資源特別低的情況下軟件係統運行情況。
容量測試：確定係統可處理同時在綫的最大用戶數
觀察指標：
性能測試主要是通過自動化的測試工具模擬多種正常、峰值以及異常負載條件來對係統的各項性能指標進行測試。負載測試和壓力測試都屬於性能測試，兩者可以結合進行。通過負載測試，確定在各種工作負載下係統的性能，目標是測試當負載逐漸增加時，係統各項性能指標的變化情況。壓力測試是通過確定一個係統的瓶頸或者不能接收的性能點，來獲得係統能提供的最大服務級別的測試。
在實際中作中我們經常會對兩種類型軟件進行測試：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：數據庫死鎖；
* Butter Cache hit ：數據庫Cache的命中情況
當然，在實際中我們還會察看多用戶測試情況下的內存，CPU，係統資源調用情況。這些指標其實是引申出來性能測試中的一種：競爭測試。什麽是競爭測試，軟件競爭使用各種資源（數據紀錄，內存等），看他與其他相關係統對資源的爭奪能力。
我們知道軟件架構在實際測試中製約着測試策略和工具的選擇。如何選擇性能測試策略是我們在實際工作中需要瞭解的。一般軟件可以按照係統架構分成幾種類型：
c/s
client/Server 客戶端/服務器架構
基於客戶端/服務器的三層架構
基於客戶端/服務器的分佈式架構
b/s
基於瀏覽器/Web服務器的三層架構
基於中間件應用服務器的三層架構l
基於Web服務器和中間件的多層架構l
三、性能測試的步驟
在每種不同的係統架構的實施中，開發人員可能選擇不同的實現方式，造成實際情況紛繁復雜。我們不可能對每種技術都詳細解說，這裏衹是介紹一種方法提供給你如何選擇測試策略，從而幫助分析軟件不同部分的性能指標，進而分析出整體架構的性能指標和性能瓶頸。
由於工程和項目的不同，所選用的度量,評估方法也有不同之處。不過仍然有一些通用的步驟幫助我們完成一個性能測試項目。步驟如下
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結構我們可能更關心會係統整體配置對用戶操作的影響。
四、性能測試方法
對於企業應用程序，有許多進行性能測試的方法，其中一些方法實行起來要比其他方法睏難。所要進行的性能測試的類型取决於想要達到的結果。例如，對於可再現性，基準測試是最好的方法。而要從當前用戶負載的角度測試係統的上限，則應該使用容量規劃測試。本文將介紹幾種設置和運行性能測試的方法，並討論這些方法的區別。
如果不進行合理的規劃，對J2EE應用程序進行性能測試將會是一項令人望而生畏且有些混亂的任務。因為對於任何的軟件開發流程，都必須收集需求、理解業務需要，並在進行實際測試之前設計出正式的進度表。性能測試的需求由業務需要驅動，並由一組用例闡明。這些用例可以基於歷史數據（例如，服務器一周的負載模式）或預測的近似值。弄清楚需要測試的內容之後，就需要知道如何進行測試了。
在開發階段前期，應該使用基準測試來確定應用程序中是否出現性能倒退。基準測試可以在一個相對短的時間內收集可重複的結果。進行基準測試的最好方法是，每次測試改變一個且衹改變一個參數。例如，如果想知道增加JVM內存是否會影響應用程序的性能，就逐次遞增JVM內存（例如，從1024 MB增至1224 MB，然後是1524 MB，最後是2024 MB），在每個階段收集結果和環境數據，記錄信息，然後轉到下一階段。這樣在分析測試結果時就有跡可循。下一小節我將介紹什麽是基準測試，以及運行基準測試的最佳參數。
開發階段後期，在應用程序中的bug已經被解决，應用程序達到一種穩定狀態之後，可以運行更為復雜的測試，確定係統在不同的負載模式下的表現。這些測試被稱為容量規劃測試、滲入測試(soak test)、峰𠔌測試(peak-rest test)，它們旨在通過測試應用程序的可靠性、健壯性和可伸縮性來測試接近於現實世界的場景。對於下面的描述應該從抽象的意義上理解，因為每個應用程序的使用模式都是不同的。例如，容量規劃測試通常都使用較緩慢的ramp-up（下文有定義），但是如果應用程序在一天之中的某個時段中有快速突發的流量，那麽自然應該修改測試以反映這種情況。但是，要記住，因為更改了測試參數（比如ramp-up周期或用戶的考慮時間(think-time)），測試的結果肯定也會改變。一個不錯的方法是，運行一係列的基準測試，確立一個已知的可控環境，然後再對變化進行比較。
基準測試
基準測試的關鍵是要獲得一致的、可再現的結果。可再現的結果有兩個好處：減少重新運行測試的次數；對測試的産品和産生的數字更為確信。使用的性能測試工具可能會對測試結果産生很大影響。假定測試的兩個指標是服務器的響應時間和吞吐量，它們會受到服務器上的負載的影響。服務器上的負載受兩個因素影響：同時與服務器通信的連接（或虛擬用戶）的數目，以及每個虛擬用戶請求之間的考慮時間的長短。很明顯，與服務器通信的用戶越多，負載就越大。同樣，請求之間的考慮時間越短，負載也越大。這兩個因素的不同組合會産生不同的服務器負載等級。記住，隨着服務器上負載的增加，吞吐量會不斷攀升，直到到達一個點。
註意，吞吐量以穩定的速度增長，然後在某一個點上穩定下來。
在某一點上，執行隊列開始增長，因為服務器上所有的綫程都已投入使用，傳入的請求不再被立即處理，而是放入隊列中，當綫程空閑時再處理。
註意，最初的一段時間，執行隊列的長度為零，然後就開始以穩定的速度增長。這是因為係統中的負載在穩定增長，雖然最初係統有足夠的空閑綫程去處理增加的負載，最終它還是不能承受，而必須將其排入隊列。
當係統達到飽和點，服務器吞吐量保持穩定後，就達到了給定條件下的係統上限。但是，隨着服務器負載的繼續增長，係統的響應時間也隨之延長，雖然吞吐量保持穩定。
註意，在執行隊列（圖2）開始增長的同時，響應時間也開始以遞增的速度增長。這是因為請求不能被及時處理。
為了獲得真正可再現的結果，應該將係統置於相同的高負載下。為此，與服務器通信的虛擬用戶應該將請求之間的考慮時間設為零。這樣服務器會立即超載，並開始構建執行隊列。如果請求（虛擬用戶）數保持一致，基準測試的結果應該會非常精確，完全可以再現。
您可能要問的一個問題是：“如何度量結果？”對於一次給定的測試，應該取響應時間和吞吐量的平均值。精確地獲得這些值的唯一方法是一次加載所有的用戶，然後在預定的時間段內持續運行。這稱為“flat”測試。
與此相對應的是“ramp-up”測試。
ramp-up測試中的用戶是交錯上升的（每幾秒增加一些新用戶）。ramp-up測試不能産生精確和可重現的平均值，這是因為由於用戶的增加是每次一部分，係統的負載在不斷地變化。因此，flat運行是獲得基準測試數據的理想模式。
這不是在貶低ramp-up測試的價值。實際上，ramp-up測試對找出以後要運行的flat測試的範圍非常有用。ramp-up測試的優點是，可以看出隨着係統負載的改變，測量值是如何改變的。然後可以據此選擇以後要運行的flat測試的範圍。
Flat測試的問題是係統會遇到“波動”效果。
）
註意波動的出現，吞吐量不再是平滑的。
這在係統的各個方面都有所體現，包括CPU的使用量。
註意，每隔一段時間就會出現一個波形。CPU使用量不再是平滑的，而是有了像吞吐量圖那樣的尖峰。
此外，執行隊列也承受着不穩定的負載，因此可以看到，隨着係統負載的增加和減少，執行隊列也在增長和縮減。
註意，每隔一段時間就會出現一個波形。執行隊列麯綫與上面的CPU使用量圖非常相似。
最後，係統中事務的響應時間也遵循着這個波動模式。
註意，每隔一段時間就會出現一個波形。事務的響應時間也與上面的圖類似，衹不過其效果隨着時間的推移逐漸減弱。
當測試中所有的用戶都同時執行幾乎相同的操作時，就會發生這種現象。這將會産生非常不可靠和不精確的結果，所以必須采取一些措施防止這種情況的出現。有兩種方法可以從這種類型的結果中獲得精確的測量值。如果測試可以運行相當長的時間（有時是幾個小時，取决於用戶的操作持續的時間），最後由於隨機事件的本性使然，服務器的吞吐量會被“拉平”。或者，可以衹選取波形中兩個平息點之間的測量值。該方法的缺點是可以捕獲數據的時間非常短。
性能規劃測試
對於性能規劃類型的測試來說，其目標是找出，在特定的環境下，給定應用程序的性能可以達到何種程度。此時可重現性就不如在基準測試中那麽重要了，因為測試中通常都會有隨機因子。引入隨機因子的目的是為了盡量模擬具有真實用戶負載的現實世界應用程序。通常，具體的目標是找出係統在特定的服務器響應時間下支持的當前用戶的最大數。例如，您可能想知道：如果要以5秒或更少的響應時間支持8,000個當前用戶，需要多少個服務器？要回答這個問題，需要知道係統的更多信息。
要確定係統的容量，需要考慮幾個因素。通常，服務器的用戶總數非常大（以十萬計），但是實際上，這個數字並不能說明什麽。真正需要知道的是，這些用戶中有多少是並發與服務器通信的。其次要知道的是，每個用戶的“考慮時間”即請求間時間是多少。這非常重要，因為考慮時間越短，係統所能支持的並發用戶越少。例如，如果用戶的考慮時間是1秒，那麽係統可能衹能支持數百個這樣的並發用戶。但是，如果用戶的考慮時間是30秒，那麽係統則可能支持數萬個這樣的並發用戶（假定硬件和應用程序都是相同的）。在現實世界中，通常難以確定用戶的確切考慮時間。還要註意，在現實世界中，用戶不會精確地按照間隔時間發出請求。
於是就引入了隨機性。如果知道普通用戶的考慮時間是5秒，誤差為20%，那麽在設計負載測試時，就要確保請求間的時間為5×（1 +/- 20%）秒。此外，可以利用“調步”的理念嚮負載場景中引入更多的隨機性。它是這樣的：在一個虛擬用戶完成一整套的請求後，該用戶暫停一個設定的時間段，或者一個小的隨機時間段（例如，2×（1 +/- 25%）秒），然後再繼續執行下一套請求。將這兩種隨機化方法運用到測試中，可以提供更接近於現實世界的場景。
現在該進行實際的容量規劃測試了。接下來的問題是：如何加載用戶以模擬負載狀態？最好的方法是模擬高峰時間用戶與服務器通信的狀況。這種用戶負載狀態是在一段時間內逐步達到的嗎？如果是，應該使用ramp-up類型的測試，每隔幾秒增加x個用戶。或者，所有用戶是在一個非常短的時間內同時與係統通信？如果是這樣，就應該使用flat類型的測試，將所有的用戶同時加載到服務器。兩種不同類型的測試會産生沒有可比性的不同測試。例如，如果進行ramp-up類型的測試，係統可以以4秒或更短的響應時間支持5,000個用戶。而執行flat測試，您會發現，對於5,000個用戶，係統的平均響應時間要大於4秒。這是由於ramp-up測試固有的不準確性使其不能顯示係統可以支持的並發用戶的精確數字。以門戶應用程序為例，隨着門戶規模的擴大和集群規模的擴大，這種不確定性就會隨之顯現。
這不是說不應該使用ramp-up測試。對於係統負載在一段比較長的時間內緩慢增加的情況，ramp-up測試效果還是不錯的。這是因為係統能夠隨着時間不斷調整。如果使用快速ramp-up測試，係統就會滯後，從而報告一個較相同用戶負載的flat測試低的響應時間。那麽，什麽是確定容量的最好方法？結合兩種負載類型的優點，並運行一係列的測試，就會産生最好的結果。例如，首先使用ramp-up測試確定係統可以支持的用戶範圍。確定了範圍之後，以該範圍內不同的並發用戶負載進行一係列的flat測試，更精確地確定係統的容量。
滲入測試
滲入測試是一種比較簡單的性能測試。滲入測試所需時間較長，它使用固定數目的並發用戶測試係統的總體健壯性。這些測試將會通過內存泄漏、增加的垃圾收集(GC)或係統的其他問題，顯示因長時間運行而出現的任何性能降低。測試運行的時間越久，您對係統就越瞭解。運行兩次測試是一個好主意——一次使用較低的用戶負載（要在係統容量之下，以便不會出現執行隊列），一次使用較高的負載（以便出現積極的執行隊列）。
測試應該運行幾天的時間，以便真正瞭解應用程序的長期健康狀況。要確保測試的應用程序盡可能接近現實世界的情況，用戶場景也要逼真（虛擬用戶通過應用程序導航的方式要與現實世界一致），從而測試應用程序的全部特性。確保運行了所有必需的監控工具，以便精確地監測並跟蹤問題。
峰𠔌測試
峰𠔌測試兼有容量規劃ramp-up類型測試和滲入測試的特徵。其目標是確定從高負載（例如係統高峰時間的負載）恢復、轉為幾乎空閑、然後再攀升到高負載、再降低的能力。
實現這種測試的最好方法就是，進行一係列的快速ramp-up測試，繼之以一段時間的平穩狀態（取决於業務需求），然後急劇降低負載，此時可以令係統平息一下，然後再進行快速的ramp-up；反復重複這個過程。這樣可以確定以下事項：第二次高峰是否重現第一次的峰值？其後的每次高峰是等於還是大於第一次的峰值？在測試過程中，係統是否顯示了內存或GC性能降低的有關跡象？測試運行（不停地重複“峰值/空閑”周期）的時間越長，您對係統的長期健康狀況就越瞭解。
結束語
本文介紹了進行性能測試的幾種方法。取决於業務需求、開發周期和應用程序的生命周期，對於特定的企業，某些測試會比其他的更適合。但是，對於任何情況，在决定進行某一種測試前，都應該問自己一些基本問題。這些問題的答案將會决定哪種測試方法是最好的。
這些問題包括：
結果的可重複性需要有多高？
測試需要運行和重新運行幾次？
您處於開放周期的哪個階段？
您的業務需求是什麽？
您的用戶需求是什麽？
您希望生産中的係統在維護停機時間中可以持續多久？
在一個正常的業務日，預期的用戶負載是多少？
將這些問題的答案與上述性能測試類型相對照，應該就可以製定出測試應用程序的總體性能的完美計劃。
性能測試是為描述測試對象與性能相關的特徵並對其進行評價，而實施和執行的一類測試，如描述和評價計時配置文件、執行流、響應時間以及操作的可靠性和限製等特徵。不同類型的性能測試側重於不同的測試目標，這些性能測試的實施貫穿於整個軟件開發生命周期 (Software Development Life Cycle, SDLC)。起初，在構架迭代中，性能測試側重於確定和消除與構架有關的性能瓶頸。在構建迭代中還將實施和執行其他類型的性能測試，以調整軟件和環境（優化響應時間和資源），並核實應用程序和係統是否能夠處理高負載和高強度的情況，如有大量事務、客戶機和/或數據的情況。
性能測試中包含以下測試類型：
基準測試 - 比較新的或未知測試對象與已知參照標準（如現有軟件或評測標準）的性能。
爭用測試： - 核實測試對象對於多個主角對相同資源（數據記錄、內存等）的請求的處理是否可以接受。
性能配置 - 核實在操作條件保持不變的情況下，測試對象在使用不同配置時其性能行為的可接受性。
負載測試 - 核實在保持配置不變的情況下，測試對象在不同操作條件（如不同用戶數、事務數等）下性能行為的可接受性。
強度測試 - 核實測試對象性能行為在異常或極端條件（如資源減少或用戶數過多）之下的可接受性。
性能評價通常是和用戶代表一起協作並且以多級方法執行的。
性能分析的第一級涉及單一主角/用例實例的結果評價和多個測試執行的結果比較。例如，在測試對象上沒有其他活動的情況下，記錄單一主角執行單一用例的性能行為，並將結果與相同主角/用例的其他幾個測試執行進行比較。第一級分析有助於確定可以表明係統資源中存在爭用的趨勢，該趨勢將影響從其他性能測試結果所得出的結論的有效性。
分析的第二級檢查特定主角/用例執行的摘要統計信息和實際數據值，以及測試對象的性能行為。摘要統計信息包括響應時間的標準偏差和百分位分佈，這些信息顯示了係統響應的變動情況，正如每個主角所見到的一樣。
分析的第三級有助於理解性能問題的起因和加權值。該詳細分析采用低級數據並且使用統計方法，幫助測試員從數據中得出正確的結論。詳細分析為决策提供客觀和定量的標準，但是它耗時較長，並且要求對統計學有基本的理解。
當性能行為差異確實存在，或是由於某些與測試數據收集相關的隨機事件引起時，詳細分析使用統計加權值的概念來幫助理解。即認為在基本級上，任何事件都具有隨機性。統計測試確定是否存在無法用隨機事件解釋的係統差異。 | | | 測試工具 | j2ee | 手機 | 軟件測試 | loadrunner | 自動化測試 | 軟件工程 | 軟件性能測試與實戰 | | 電腦測速 | 計算機 | 軟件 | 圖書 | 實戰 | |
| | | 機械性能測試 | 性能測試軟件 | 性能測試應用 | | 軟件性能測試 | 性能測試實戰 | 密封性能測試儀 | | 熱封性能測試儀 | 質量和性能測試 | 性能測試進階指南 | | 性能測試從零開始 | 防雷器性能測試儀 | 高嶺土工藝性能測試 | | LoadRunner性能測試應用 | RFID性能測試 | 應用程序性能測試的藝術 | | 安全帽阻燃性能測試儀 | 水泥物理化學性能測試 | 橡膠物理機械性能測試 | | 網絡性能測試與分析 | 包裝密封性能測試儀 | 金屬力學性能測試技術 | | 安全帽電絶緣性能測試儀 | 金屬材料物理性能測試機 | 垂直法阻燃性能測試儀 | | loadrunner性能測試實戰 | 材料物理性能測試係統 | 和軟件項目性能測試 | | 軟件性能測試與實戰 | 氧氣阻隔性能測試儀 | 精通軟件性能測試與實戰 | | 真空包裝密封性能測試儀 | 紙杯特理性能測試儀器 | 電纜防白蟻性能測試 | | 汽車內飾件成霧性能測試 | 航天器材料性能測試驗工 | 精通軟件性能測試與LoadRunner實戰 | | 《軟件性能測試與LoadRunner實戰》 | 軟件性能測試與LoadRunner實戰 | 應用程序性能測試藝術(影印版) | | 溫差發電器熱電性能測試係統 | 新型防護服裝熱防護性能測試裝置 | loadrunner和軟件項目性能測試 | |
|
|
|