一．簡介

簡介部分就不用過多描述了，進行此次性能測試的原因，以及性能測試覆蓋的范圍等等，幾乎所有項目文檔都在開端對項目進行簡單的闡述。

二．性能測試需求

尋找的被測試對象和壓力點

要測試的對象不是憑空想象出來，而是經過分析與系統數據收集得到。下取幾個典型的壓力點

登錄：對于一般的系統來說，登錄是用戶操作系統的前提，如果用戶根本就登錄不了，那么其它功能將毫無用處。例如網游戲，開新服的時候，玩家擠破了腦袋只為登錄。

查詢：查詢一般比較消耗系統和數據庫資源。搜索引擎的查詢功能就是典型，如果你在輸入框內輸入內容，很久就得不到結果。我想被稱為“互聯網入口”的搜索引擎就不會存在。

交易：對于一些電子商務系統來說，交易過程的性能要求是很高的，如果交易過程消耗用戶很長時間的話。我寧愿去超市買東西了。當然，除了交易速度外，對交易的成功率要求也是非常高的。不然，造成的損失也是不可估量的。

被測的系統應該是最重要的最基本的功能，也是用戶使用最頻繁的功能。

一般的性能要求包括：

系統容量：系統最大容納多少個用戶注冊。

訪問數：同時訪問系統的用戶數。

并發數：一個操作同時執行的并發數目，一個系統中應該有不同操作的并發數的組合（一般是有權限進行操作的用戶）。

系統的最大用戶數與最佳用戶數:系統在承受的最大并發用戶數量，系統在最佳狀態下承受的并發用戶數據。

響應時間：用戶提交一個操作到得到響應的時間間隔。

吞吐率：系統每秒鐘處理的TPS

性能測試關鍵的一個因素就是壓力，性能是在系統設計滿足的最大壓力下的性能。并發數要不小于系統正常運行的峰值，數據總量不小于系統正常運行3個月的數據量。

在描述并發用戶數目時，總是會帶有相應的時間段限制。系統的性能指標實質上應當使用單位時間內系統處理請求的個數以及請求響應時間描述。單位時間內能處理的請求個數就是系統的業務吞吐量。虛擬并發用戶的數量可以使用如下的公式換算： （真實用戶數×每個真實用戶請求數）/(總請求響應時間+真實用戶總思考時間)=(虛擬用戶數×每用戶請求個數)/(總請求響應時間+虛擬用戶總思考時間)=吞吐量。

三．測試環境

這里的測試環境主要指的軟件硬件環境和網絡環境。

筆者認為性能測試最好在一個獨立的環境內進行，這樣不會受到外界的干擾，能夠保證測試的數據是獨立有效的。如果現你對某個已經上線的網站進行壓力測試，那么你得到的數據不是獨立的，因為你在做壓力測試的時候，其它散戶也在訪問系統。

軟件環境：

這里的軟件環境主要指項目運行的環境，比如采用什么樣的操作系統、中間件、和數據庫。

硬件環境：

這里的硬件環境除了主要包括主機內部部件，cpu、內存、磁盤以及主板、網卡等，傳輸介質和路由器也應該考慮在內，

網絡環境：

網絡環境除了考慮測試機與被系統服務器在一個局域網中進行，還應該保證這個網絡的獨立性。如果在在性能測試的過程中，其它機子也在消耗著路由器資源。那么路由器也會影響到數據庫的傳輸速度。

四．數據準備

在很多時候，我們是要準備測試數據的，例如系統不允許相同用戶的重復登錄，那么必須要生成合法的用戶數據。有時要對系統進行查詢測試，只有在系統有一定數據量進才能驗證出系統的真實性能。一個數據庫中有兩條數據和有兩千萬條數據，同相一條查詢操作，對系統造成的壓力是完全不一樣的。

系統所需數據的分析可以參考以下方式：

歷史數據分析有助于數據量級的確定。從歷史數據入手，找出高峰期數據量。

從其他相似或者相同系統入手，進行數據分析，找出高峰期數據量。

無歷史或者相關系統可以參考的時候，就要對系統的性能數據進行估算，包含系統容量，并發數等數據，估算以后給相關人員進行評審或者修訂以后，按照大家同意的性能指標進行測試。

…………

測試數據最好和真實數據相同，如果能夠獲得真實系統運行3個月的數據，我們就可以在此基礎上進行性能測試。

關于數據的生成，我們可以祝一個工具完成，如數據庫數據生成工具，大小文件生成工具等。

五．測試工具

前面已經介紹如何分析需求，需求確定下來之后，我們可以考慮引入什么樣的工具適合性能需求。

當然，在引入工具的時候除了考慮可以是否滿足需求，還應該考慮工具的成本，這不單指工具的購買成本，還有測試人員對工具的學習成本。

關于測試工具的選擇，后面會單獨有一章節介紹，這里就不細說了。

如果你選擇的性能測試工具不是足夠的強大的話，你可能還需要其它的輔助的工具。如果jmeter利用badboy來錄制腳本，更能提高腳本開發效率。在壓力測試的過程中也可能需要性能計數器來記錄軟硬件的性能。如監控服務器cpu、內存的計數器，記錄中間件日志的監控中工具，監控數據庫性能的監控工具等。

六．測試策略

對于一個特定的業務系統，用戶一般會分散在一天的各個時間段進行訪問。在不同的時間段中，用戶使用業務系統的頻率不同，而系統的繁忙程度不同。在一些特定的條件下，可能出現短時間內用戶集中訪問某個業務系統的情況。例如對于公文處理子系統而言，可能就存在短時間內大量用戶查看并辦理某條公文的情況。 在進行性能測試時，應當使用“考慮最壞情況的原則”。也就是應當在用戶使用業務系統最頻繁、對系統造成最大壓力的情況下對系統的功能進行測試，判斷各功能和頁面是否能夠滿足性能的要求，系統的響應時間是否過長。

另一方面，系統性能的驗證必須做到“覆蓋全面”。雖然系統中各個功能的使用頻率并不相同，一些功能的使用頻率相對于其他功能來說比較低，但是在進行性能測試和優化時，不能忽略這些功能，編制測試用例時也不能僅僅選擇最常用功能。例如可能所有的用戶都會訪問我的通知列表，但是一般只有5%的用戶會使用通過系統設置模塊查找某個用戶的信息；但是在測試時，我們并不能因為查看用戶信息功能的使用頻率相對較少，而忽略掉這項功能的測試。所以，這里進行系統性能測試時，對于不同業務，用戶的訪問比例應該做一個合理分配。

在測試策略上，我們還應該考慮，同一個系統在不同硬件環境下的性能表現。從而讓系統滿足需求的情況下，硬件配置也能達到一個最佳的狀態。過份的增加硬件來滿足需求也是一種浪費。再說增加硬件設備不是能解決所有性能問題的。

七．人力與時間安排

最后一條，就是要根據項目的進度要求以及規模，來進行人力與時間的安排。對于大型的性能測試，項目前期的需求調研，環境的部署，工具的選購或開發，人員對測試工具的學習與使用，性能測試的后進行，后期數據的分析與調優。都需要人員安排的。有可以需要專業的，系統工程師、數據庫工程師、軟件開發工程師、網絡工程師以及性能測試工程師的共同參與配合完成。不是一個性能測試人員就可以全部搞定的。

筆者聽說，最牛x的性能測試，需要幾個國家的十幾個城市的性能測試團隊同步時行。前期的準備工作就需要幾個月的時間。如何把控性能測試的同步進行。后期測試數據的匯總與分析。是一個非常復雜的過程。這個例子有待考證，我想說明的是，對于大項目的性能測試，人員與時間安排也至關重要。

根據項目的不同，我們在做性能測試計劃椒考慮的問題不僅僅上面這些內容，這一節所羅列的內容是基本需要考慮的因素。
　　
　　歡迎關注公眾號 了解更多測試內容
　　

總結

以上是生活随笔為你收集整理的性能测试计划的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。