性能測試

因為系統性能問題造成系統當機，業務無法進行的情形發生，可能成為企業的致命傷，失去顧客的信賴。因此讓我們重新認識性能測試的重要性。

性能測試的時機通常在開發環境或測試環境下的測試結束後，移至正式環境下進行全體系統測試的同時進行。如果開發環境的主機、網路、資料庫等環境和正式環境相同，性能測試也可以在測試環境下進行，否則會失去性能測試的意義。

性能通常有「處理能力(Throughput)」、「回覆時間(Response Time)」、「資源使用量(Resource)」3種指標。

●處理能力(Throughput)

在批次處理上(B/T)系統單位時間的處理件數，單位為tps(Transaction per Second)。例如訂貨系統每秒能夠處理50件的訂單，訂貨系統的處理能力(Throughput)為「50件/sec」。另外在線上(O/L)處理，通常指單位時間顯示的畫面數，單位為PV/s(Page View per Second)。

●回覆時間(Response Time)

端末向主機提出處理要求到處理結果回覆到端末的時間。複數處理要求時，通常取平均或90 Percentile(如有100的Response，從大排到小，第90個值))等。

●資源使用量(Resource)

CPU、MEMORY、DISK、NETWORK等系統資源的使用量，單位為百分比(%)。

圖1:系統性能指標

性能測試的目的

一般在「系統需求規格書」中，會設定性能需求規格。性能測試的目的就是要檢視是否達到規格書中所設定的目標值，例如1秒間同時50人接續時的回覆時間為3秒。而這些目標值應該要包含上述3個性能指標。另外，還有檢視系統性能的極限值，到甚麼樣的程度系統性能會下降，甚至當機，一般稱做「壓力測試(Rush Test)」。「壓力測試」也可以獨立出來進行測試，不過通常會和性能測試同時進行，以避免影響全體系統測試的行程。

在性能測試階段如果能夠確實掌握到系統的性能，可以避免正式上線後，須要停機調整或擴充系統性能的窘境發生。有些也不是單純的擴充系統性能就能解決問題，如是問題出現在軟體設計上，最糟的可能要重新設計開發。

確實掌握到系統的性能，也可以適當的設定系統資源，process等的監控值，在問題還未發生之前提出警訊，提前進行擴充系統資源等對應。以及事前設計「障礙復原程序書」，以便發生問題時能夠迅速的對應。

圖2:系統性能測試目的

性能測試的項目和方法

根據「系統需求規格書」內設定性能需求規格，加上壓力測試等內容，反映到「性能測試規格書」以及「性能測試實施計畫書」上。測試的項目通常包含線上(O/L)的Response Time，批次處理(B/T)的執行時間、B/T JOB並行處理的能力、JOB-NET的確認、列印時間，以及尖峰期大容量資料的確認、耐負荷程度確認等。

性能測試時，不可能取得實際的資料量和接續端末進行測試，都必須藉由自行程式開發或一些工具(Tools)來不斷的複製假資料和接續端末來進行測試。主機只有1台時，本身擔任主機又擔任主機的角色，有2台主機時，彼此擔任對方的主機和端末的方式，進行反覆模擬測試。目前網際網路上有一些Open Source能夠模擬性能測試，例如像「Apache Jmeter」、「ApacheBench」。

通常模擬性能測試的工具，都具備有檢視處理能力(Throughput)和回覆時間(Response Time)的功能。也有支援製作測試劇本(scenario)的功能。例如模擬購物網站的預覽者購物行為製作測試劇本，設定不同的接續頻率。

另外在檢視系統資源的使用量上，在Windows系通常利用「資源監視器(Resource Monitor)」可以觀察，Unix系則利用sar，vmstat，iostat，netstat等指令。市面上也有很多監控檢視系統資源的工具。例如，NagiosExchange、Big Brother、ZABBIX、Hinemos，網路資源監控的有MRTG。

資源	監視種類
CPU	CPU使用率
	等待執行Process數
DISK	DISK使用率
	等待執行數
MEMORY	MEMORY使用量
	SWAP使用量
Network	頻寬使用量

表1:一般經常確認的資源監控項目