目錄1. 簡介 2
1.1 目的 2
1.2 定義、首字母縮寫詞和縮略語 2
1.3 範圍 2
1.4 參考文獻 2
2. 測試準備 2
2.1 系統效能要求分析 2
2.2 測試資料準備 3
2.3 測試環境準備 3
2.4 測試工具選擇 3
3. 測試策略 4
3.1 測試場景 4
3.1.1 測試場景一 4
3.1.2 測試場景二 5
3.2 負載分配策略 5
4. 效能資料記錄和分析 5
4.1 被測系統 5
4.2 伺服器 6
4.3 資料庫 6
4.4 網路 6
5. 風險分析 7
6. 專案里程碑 7
7. 測試結束標準 7
8. 附錄i： 7
8.1 效能計數器 7
8.2 web伺服器 10
8.3 資料庫 12
效能測試計畫
此處描述本次測試的目的是什麼，比如驗證系統設計的效能目標。
此處描述本計畫中用到的專業術語定義。
本次測試覆蓋的範圍
此處列出本計畫相關的文件，包含資料**以及其他參考
一般的效能要求包括：
系統容量：系統最大容納多少個使用者註冊。
訪問數：同時訪問系統的使用者數。
併發數：乙個操作同時執行的併發數目，乙個系統中應該有不同操作的併發數的組合（一般是有許可權進行操作的使用者）。
響應時間：使用者提交乙個操作到得到響應的時間間隔。
…………
效能測試關鍵的乙個因素就是壓力，效能是在系統設計滿足的最大壓力下的效能。併發數要不小於系統正常執行的峰值，資料總量不小於系統正常執行3個月的資料量。
在描述併發使用者數目時，總是會帶有相應的時間段限制。系統的效能指標實質上應當使用單位時間內系統處理請求的個數以及請求響應時間描述。單位時間內能處理的請求個數就是系統的業務吞吐量。
虛擬併發使用者的數量可以使用如下的公式換算： （真實使用者數×每個真實使用者請求數）/(總請求響應時間+真實使用者總思考時間)=(虛擬使用者數×每使用者請求個數)/(總請求響應時間+虛擬使用者總思考時間)=吞吐量。
資料分析可以參考以下方式：
歷史資料分析有助於資料量級的確定。從歷史資料入手，找出高峰期資料量。
從其他相似或者相同系統入手，進行資料分析，找出高峰期資料量。
無歷史或者相關系統可以參考的時候，就要對系統的效能資料進行估算，包含系統容量，併發數等資料，估算以後給相關人員進行評審或者修訂以後，按照大家同意的效能指標進行測試。
…………
測試資料最好和真實資料相同，如果能夠獲得真實系統執行3個月的資料，我們就可以在此基礎上進行效能測試。
測試資料最重要的是要達到真實環境執行下的資料量級。
下面是某乙個系統一年的資料量估算。
測試環境要求盡量和真實環境相同，至少要求伺服器配置和網路頻寬和拓撲結構應該相似。主要內容：伺服器數量和配置，作業系統和資料庫版本，軟硬體部署等。
測試工具的選擇對效能測試能否成功至關重要。一般的測試b/s結構的系統我們現在使用的是lr。基本上可以解決目前我們需要測試的效能點問題。
c/s結構的系統一般要開發效能測試工具，模擬多路進行長時間的執行，並記錄相應的效能資料。
新工具要經過確認
對於乙個特定的業務系統，使用者一般會分散在一天的各個時間段進行訪問。在不同的時間段中，使用者使用業務系統的頻率不同，而系統的繁忙程度不同。在一些特定的條件下，可能出現短時間內使用者集中訪問某個業務系統的情況。
例如對於公文處理子系統而言，可能就存在短時間內大量使用者檢視並辦理某條公文的情況。 在進行效能測試時，應當使用「考慮最壞情況的原則」。也就是應當在使用者使用業務系統最頻繁、對系統造成最大壓力的情況下對系統的功能進行測試，判斷各功能和頁面是否能夠滿足效能的要求，系統的響應時間是否過長。
另一方面，系統效能的驗證必須做到「覆蓋全面」。雖然系統中各個功能的使用頻率並不相同，一些功能的使用頻率相對於其他功能來說比較低，但是在進行效能測試和優化時，不能忽略這些功能，編制測試用例時也不能僅僅選擇最常用功能。例如可能所有的使用者都會訪問我的通知列表，但是一般只有5%的使用者會使用通過系統設定模組查詢某個使用者的資訊；但是在測試時，我們並不能因為檢視使用者資訊功能的使用頻率相對較少，而忽略掉這項功能的測試。
測試場景的選擇和系統的具體業務相關。計畫制定者一定對系統的業務十分了解。測試場景從整個業務系統分離出來，一般可以參考以下方法：
● 以前的系統或者其他類似業務系統的資料參考
● 相關專案文件關於場景的描述
場景選擇的乙個策略可以是按照對系統效能影響的程度，以操作響應時間多少為序。
場景選擇要包含系統所有能夠影響效能的操作，這些影響主要有：
● 和其他系統有互動的操作，要等待其他系統或者元件返回結果的操作：第三方介面的使用，合成，識別等
● 本身存在後台處理的業務：後台處理耗時的業務（評分，更新排行榜等），資料庫查詢等
● 使用快取資訊的操作
設計場景的時候要考慮思考時間。在使用者真實使用環境中，使用者操作不同功能之間並不是連續不斷的，而是在不同步驟之間有所延遲，稱之為「思考時間」。在設計用例時，應當模擬實際使用者使用系統的方式，在不同的操作步驟中加入使用者的「思考時間」，才能夠模擬真實的壓力情況。
測試場景要說明覆蓋了哪些場景，沒有覆蓋到哪些場景，為什麼沒有覆蓋。
場景確定以後，就要確定各個場景的比例數。各個場景所佔比例的多少可以根據以下方法進行確定：
● 歷史資料統計
● 其他系統參考
● 如果是乙個全新的系統，需要測試人員估計乙個比例以後和專案組討論確定。
計畫的負載下，效能達到設計要求以後，可以持續增加系統的壓力，一直到瓶頸出現，可以為系統效能的提高提出改進方向。
根據系統效能要求，記錄需要的資料，可以對以下資料進行記錄和分析：
各個主要action的響應時間，在自動載入壓力測試的同時，人工檢查各項資料是否和自動記錄的資料相同。
記憶體、cpu、虛擬記憶體、控制代碼、執行緒，可以使用作業系統的效能計數器來記錄這些資料，或者測試工具自己可以記錄。
XX專案測試計畫
修訂歷史記錄 a 新增，m 修改，d 刪除 所需文件 軟體需求說明 文件中需包括 對測試物件 構件 應用程式 系統等 及其目標進行簡要說明。需要包括的資訊有 主要的功能和效能 測試物件的構架以及專案的簡史 目標 確定現有專案的資訊和應測試的軟體構件，確定測試範圍,包括測試物件中將接受測試或將不接受測...
效能測試計畫方案
discuz系統 xx公司 版權所有違者必究 檔案修改記錄 目錄1 文件目的 1 1.1 專案背景介紹 1 1.2 術語及縮略語 1 1.3 測試輸入 1 2 測試準備 重要 1 2.1 測試環境準備 1 2.2 測試內容 2 2.3 非測試內容 2 2.4 業務抽取 測試指令碼 2 2.4.1 需...
模版 效能測試計畫
網通系統壓力測試方案 微軟 中國 版本控制 目錄一 概述 4 1.1專案背景和測試目的 4 1.2被測系統介紹 4 1.3測試可接收條件 5 二 測試需求 5 三 測試方法 5 3.1測試方法 5 3.2測試案例 9 3.3測試流程 9 3.4資料檔案準備 9 3.5測試指令碼說明 10 四 測試環...