在實(shí)際的工作中系統(tǒng)的性能需求通常是一個(gè)籠統(tǒng)的需求，而且有可能給提需求的人并不知道具體的性能需要，所以只能含糊的列出。如果測試人員不搞清楚，就會出現(xiàn)實(shí)際要把殺豬刀，需求標(biāo)明能屠龍?。?！

下面，還是舉一個(gè)講個(gè)我真實(shí)經(jīng)歷過的故事來做實(shí)例分析。

故事開始：

需求方是一個(gè)研究機(jī)構(gòu)（甲方），它旗下本身也有一個(gè)軟件技術(shù)部（但不承擔(dān)開發(fā)測試任務(wù)），但是這個(gè)項(xiàng)目是外包方（乙方）來做的，我們公司當(dāng)時(shí)是中間的監(jiān)理機(jī)構(gòu)（第三方），主要監(jiān)理整個(gè)項(xiàng)目系統(tǒng)的性能質(zhì)量以及整個(gè)工程（包括開發(fā)、測試以及系統(tǒng)運(yùn)行）的質(zhì)量，對我來講任務(wù)只是考察系統(tǒng)的性能，系統(tǒng)講的是一個(gè)圖書檢索系統(tǒng)，包含主要功能:圖書上傳，圖書分類，目錄索引，圖書搜索，圖書下載以及圖書的全文檢索功能。

我也參加了他們項(xiàng)目組組織的一次“性能需求”會議，當(dāng)時(shí)的合同我們監(jiān)理拿給我看了一下，實(shí)際在合同上并沒有規(guī)定具體的性能指標(biāo)，只有一句話：系統(tǒng)需要滿足甲方5年內(nèi)的業(yè)務(wù)需求。

系統(tǒng)甲方在會議上張口提出了需求：并發(fā)用戶要到5000，業(yè)務(wù)響應(yīng)時(shí)間要控制在3秒內(nèi)；乙方開發(fā)組長是個(gè)年輕的小伙子，對這個(gè)性能完全沒有概念，就問我們監(jiān)理這個(gè)是否合理，監(jiān)理把這個(gè)問題拋給了我，我用筆在紙上做了提綱，然后對甲方和乙方提出了問題。

(1) 請問甲方，當(dāng)前的業(yè)務(wù)量或者訪問量是每天多少？答：10000左右，有時(shí)候15000訪問用戶

--我扭頭想罵人，這不是欺負(fù)人嗎？

(2) 請問甲方5000的TPS從哪兒來的？答：10000的用戶并發(fā)1000，估計(jì)5年內(nèi)業(yè)務(wù)能上升到5倍，所以是5000

--我低頭對監(jiān)理說：這個(gè)5000太不合理了，是不想讓上線啊。

--監(jiān)理：給出合理解釋，給個(gè)合理的范圍。你直接說。

--好吧，每天的業(yè)務(wù)峰值才只有15000，咱們就按10倍來計(jì)算，150000，每天8個(gè)小時(shí)正常工作時(shí)間，按照只有20%的時(shí)間用戶會集中，就算20%的時(shí)間所有用戶都集中在這，那么TPS計(jì)算一下150000/(0.2860*60) 大約是26，還不到30的TPS，怎么會出現(xiàn)5000并發(fā)呢；當(dāng)然30對一個(gè)系統(tǒng)來說可能是有點(diǎn)小，咱們來平衡一下。

最后在各方的努力下做出如下的改變：

當(dāng)前峰值訪問15000，5年內(nèi)，假設(shè)業(yè)務(wù)發(fā)展增加100倍，最后定到并發(fā)訪問用戶和TPS在300，響應(yīng)時(shí)間根據(jù)業(yè)務(wù)而定，全文檢索在3分鐘內(nèi)，下載，上傳業(yè)務(wù)不做限制，圖書索引和圖書索引搜索（模糊搜索）在5秒內(nèi)。

故事結(jié)束。

這個(gè)例子，其實(shí)沒有其他意思，只是想說，很多時(shí)候需求可能是“拍腦袋”想出來的，沒有數(shù)據(jù)支撐，這個(gè)時(shí)候我們需要的是需要多次的溝通，需要達(dá)到項(xiàng)目組多方的一致認(rèn)可（理由和數(shù)據(jù)充分，才可行）（作為監(jiān)理需要既不偏袒甲方也不包庇乙方，一個(gè)項(xiàng)目組的共同目的就是項(xiàng)目保質(zhì)保量、完美的上線運(yùn)行）。

這個(gè)例子也是一個(gè)沒有既定具體需求的案例，需要我們了解業(yè)務(wù)功能，并應(yīng)用常用的規(guī)則來進(jìn)行推導(dǎo)一些可能的需求。

這個(gè)業(yè)務(wù)里面，全文檢索業(yè)務(wù)響應(yīng)時(shí)間是一個(gè)比較難定義的點(diǎn)，需要在圖書庫里面（注意圖書不是錄入數(shù)據(jù)庫的，都是PDF文件要在各個(gè)文件里面）進(jìn)行檢索，雖然文件進(jìn)行了科目的分類檢索，但是每一個(gè)科目圖書還是很多的，全文檢索那速度可能就更是問題了，這個(gè)問題為了給用戶更好的體驗(yàn)，在前端進(jìn)行了處理，有一個(gè)類似于進(jìn)度條的展示，展示當(dāng)前的所有進(jìn)度，并且逐漸展示已經(jīng)檢索到的部分內(nèi)容，提供用戶的體驗(yàn)度。這個(gè)并沒有使用任何的后臺技術(shù)進(jìn)行調(diào)優(yōu)，因?yàn)檫@個(gè)代價(jià)可能非常大，只是在設(shè)計(jì)上進(jìn)行了優(yōu)化，而這個(gè)需求的最終確定也是測試和整個(gè)項(xiàng)目組一起討論后確定下來的。

這里要說的，并不是一個(gè)具體可以拿來照搬的（需求分析）方法，只是想強(qiáng)調(diào)一點(diǎn)：分析和了解需求很重要，并且你分析得到的需求與整個(gè)項(xiàng)目組的溝通和確認(rèn)至關(guān)重要，它關(guān)系到你后面所做的所有事情是否有效。

接下來，我們總結(jié)一下需求分析的方法：

(1) 具體有文檔的和需求的，先分析文檔需求，找出疑問和項(xiàng)目組進(jìn)行確認(rèn)，最好自己整理一個(gè)系統(tǒng)結(jié)構(gòu)和業(yè)務(wù)流程圖在項(xiàng)目組進(jìn)行講解確認(rèn)，達(dá)成一致觀點(diǎn)。

(2) 沒有文檔需求的，需要和整個(gè)項(xiàng)目組進(jìn)行溝通交流，先大致了解，然后逐漸細(xì)化分析系統(tǒng)的各個(gè)業(yè)務(wù)流，最終形成系統(tǒng)結(jié)構(gòu)和業(yè)務(wù)流程圖在項(xiàng)目組進(jìn)行講解確認(rèn)，達(dá)成一致觀點(diǎn)。

(3) 一些細(xì)節(jié)的性能需求，項(xiàng)目組不能提供時(shí)，需要結(jié)合一些原理進(jìn)行分析拿出具體數(shù)據(jù)和項(xiàng)目組進(jìn)行確認(rèn)，達(dá)成一致觀點(diǎn)。

可以看到，最后都是落實(shí)到和項(xiàng)目組確認(rèn)，你確認(rèn)的時(shí)候，從這幾個(gè)方面入手：

(1) 對給出的每一個(gè)需求點(diǎn)，給出需求是怎么來的？要有數(shù)據(jù)說明。

(2) 對給出的每一個(gè)需求點(diǎn)，給出這個(gè)值合理性？做好數(shù)據(jù)和原理說明。

(3) 最后詢問一下項(xiàng)目組是否有遺漏？一個(gè)人的力量始終是沒有一組人的力量大。整個(gè)項(xiàng)目組一起思考也許就能夠補(bǔ)充一個(gè)人所想不到的一些放面。

(4) 當(dāng)項(xiàng)目組提不出問題的時(shí)候，要主動提出一些問題，比如是否需要穩(wěn)定性測試，是否需要考察可靠性，咱們是否需要做這些等等。

這個(gè)方法其實(shí)應(yīng)該是所有的項(xiàng)目都能夠采用，可能有些項(xiàng)目時(shí)間上比較緊張的時(shí)候，不允許我們有時(shí)間進(jìn)行全面的分析，這就是測試中的最大風(fēng)險(xiǎn)所在。

那我們該如何學(xué)習(xí)性能測試呢？

性能測試的目的是發(fā)現(xiàn)系統(tǒng)處理能力的瓶頸而系統(tǒng)調(diào)優(yōu)才是最終的目的，如果能進(jìn)一步提高各業(yè)務(wù)服務(wù)器、數(shù)據(jù)庫服務(wù)器的調(diào)優(yōu)技能，對性能測試工作來說是如虎添翼。

性能測試針對

1、系統(tǒng)的性能指標(biāo)

2、建立性能測試模型

3、制定性能測試方案

4、制定監(jiān)控策略

5、在場景條件之下執(zhí)行性能場景

6、分析判斷性能瓶頸并調(diào)優(yōu)

7、最終得出性能結(jié)果來

8、評估系統(tǒng)的性能指標(biāo)是否滿足既定值

有人說，我們在做項(xiàng)目的時(shí)候，就沒有指標(biāo)，老板只說一句，系統(tǒng)壓死為止。聽起來很兒戲，但這樣的場景不在少數(shù)。在我看來，把系統(tǒng)壓死也算是一種指標(biāo)。至于你用什么手段把系統(tǒng)“壓死”，那就是實(shí)現(xiàn)的問題了

一、準(zhǔn)備工作

1、系統(tǒng)基礎(chǔ)功能驗(yàn)證 性能測試在什么階段適合實(shí)施？切入點(diǎn)很重要！一般而言，只有在系統(tǒng)基礎(chǔ)功能測試驗(yàn)證完成、系統(tǒng)趨于穩(wěn)定的情況下，才會進(jìn)行性能測試，否則性能測試是無意義的。

2、測試團(tuán)隊(duì)組建 根據(jù)該項(xiàng)目的具體情況，組建一個(gè)幾人的性能測試team，其中DBA是必不可少的，然后需要一至幾名系統(tǒng)開發(fā)人員（對應(yīng)前端、后臺等），還有性能測試設(shè)計(jì)和分析人員、腳本開發(fā)和執(zhí)行人員；在正式開始工作之前，應(yīng)該對腳本開發(fā)和執(zhí)行人員進(jìn)行一些培訓(xùn)，或者應(yīng)該由具有相關(guān)經(jīng)驗(yàn)的人員擔(dān)任。

3、工具的選擇 綜合系統(tǒng)設(shè)計(jì)、工具成本、測試團(tuán)隊(duì)的技能來考慮，選擇合適的測試工具。

最起碼應(yīng)該滿足一下幾點(diǎn)：

①支持對web（這里以web系統(tǒng)為例）系統(tǒng)的性能測試，支持http和https協(xié)議；

②工具運(yùn)行在Windows平臺上；

③支持對webserver、前端、數(shù)據(jù)庫的性能計(jì)數(shù)器進(jìn)行監(jiān)控；

4、預(yù)先的業(yè)務(wù)場景分析 為了對系統(tǒng)性能建立直觀上的認(rèn)識和分析，應(yīng)對系統(tǒng)較重要和常用的業(yè)務(wù)場景模塊進(jìn)行分析，針對性的進(jìn)行分析，以對接下來的測試計(jì)劃設(shè)計(jì)進(jìn)行準(zhǔn)備。

二、測試計(jì)劃

測試計(jì)劃階段最重要的是分析用戶場景，確定系統(tǒng)性能目標(biāo)。 1、性能測試領(lǐng)域分析 根據(jù)對項(xiàng)目背景，業(yè)務(wù)的了解，確定本次性能測試要解決的問題點(diǎn)；是測試系統(tǒng)能否滿足實(shí)際運(yùn)行時(shí)的需要，還是目前的系統(tǒng)在哪些方面制約系統(tǒng)性能的表現(xiàn)，或者，哪些系統(tǒng)因素導(dǎo)致系統(tǒng)無法跟上業(yè)務(wù)發(fā)展？

確定測試領(lǐng)域，然后具體問題具體分析。

2、用戶場景剖析和業(yè)務(wù)建模 根據(jù)對系統(tǒng)業(yè)務(wù)、用戶活躍時(shí)間、訪問頻率、場景交互等各方面的分析，整理一個(gè)業(yè)務(wù)場景表，當(dāng)然其中最好對用戶操作場景、步驟進(jìn)行詳細(xì)的描述，為測試腳本開發(fā)提供依據(jù)。

3、確定性能目標(biāo) 前面已經(jīng)確定了本次性能測試的應(yīng)用領(lǐng)域，接下來就是針對具體的領(lǐng)域關(guān)注點(diǎn)，確定性能目標(biāo)（指標(biāo)）；

其中需要和其他業(yè)務(wù)部門進(jìn)行溝通協(xié)商，以及結(jié)合當(dāng)前系統(tǒng)的響應(yīng)時(shí)間等數(shù)據(jù)，確定最終我們需要達(dá)到的響應(yīng)時(shí)間和系統(tǒng)資源使用率等目標(biāo)；

例如：

①登錄請求到登錄成功的頁面響應(yīng)時(shí)間不能超過2秒；

②報(bào)表審核提交的頁面響應(yīng)時(shí)間不能超過5秒；

③文件的上傳、下載頁面響應(yīng)時(shí)間不超過8秒；

④服務(wù)器的CPU平均使用率小于70%，內(nèi)存使用率小于75%；

⑤各個(gè)業(yè)務(wù)系統(tǒng)的響應(yīng)時(shí)間和服務(wù)器資源使用情況在不同測試環(huán)境下，各指標(biāo)隨負(fù)載變化的情況等；

4、制定測試計(jì)劃的實(shí)施時(shí)間 預(yù)設(shè)本次性能測試各子模塊的起止時(shí)間，產(chǎn)出，參與人員等等。

三、測試腳本設(shè)計(jì)與開發(fā)

性能測試中，測試腳本設(shè)計(jì)與開發(fā)占據(jù)了很大的時(shí)間比重。

1、測試環(huán)境設(shè)計(jì) 本次性能測試的目標(biāo)是需要驗(yàn)證系統(tǒng)在實(shí)際運(yùn)行環(huán)境中的性能外，還需要考慮到不同的硬件配置是否會是制約系統(tǒng)性能的重要因素！

因此在測試環(huán)境中，需要部署多個(gè)不同的測試環(huán)境，在不同的硬件配置上檢查應(yīng)用系統(tǒng)的性能，并對不同配置下系統(tǒng)的測試結(jié)果進(jìn)行分析，得出最優(yōu)結(jié)果（最適合當(dāng)前系統(tǒng)的配置）。 這里所說的配置大概是如下幾類： ①數(shù)據(jù)庫服務(wù)器 ②應(yīng)用服務(wù)器 ③負(fù)載模擬器 ④軟件運(yùn)行環(huán)境

平臺測試環(huán)境測試數(shù)據(jù)，可以根據(jù)系統(tǒng)的運(yùn)行預(yù)期來確定，比如需要測試的業(yè)務(wù)場景，數(shù)據(jù)多久執(zhí)行一次備份轉(zhuǎn)移，該業(yè)務(wù)場景涉及哪些表，每次操作數(shù)據(jù)怎樣寫入，寫入幾條，需要多少的測試數(shù)據(jù)來使得測試環(huán)境的數(shù)據(jù)保持一致性等等。

可以在首次測試數(shù)據(jù)生成時(shí)，將其導(dǎo)出到本地保存，在每次測試開始前導(dǎo)入數(shù)據(jù)，保持一致性。

2、測試場景設(shè)計(jì) 通過和業(yè)務(wù)部門溝通以及以往用戶操作習(xí)慣，確定用戶操作習(xí)慣模式，以及不同的場景用戶數(shù)量，操作次數(shù)，確定測試指標(biāo)，以及性能監(jiān)控等。

3、測試用例設(shè)計(jì) 確認(rèn)測試場景后，在系統(tǒng)已有的操作描述上，進(jìn)一步完善為可映射為腳本的測試用例描述。

用例大概內(nèi)容如下：

用例編號：查詢表單_xxx_x1（命名以業(yè)務(wù)操作場景為主，簡潔易懂即可）

用例條件：用戶已登錄、具有對應(yīng)權(quán)限等。。。

操作步驟：

①進(jìn)入對應(yīng)頁面。。。。。。

②查詢相關(guān)數(shù)據(jù)。。。。。。

③勾選導(dǎo)出數(shù)據(jù)。。。。。。

④修改上傳數(shù)據(jù)。。。。。。

PS：這里的操作步驟只是個(gè)例子，具體以系統(tǒng)業(yè)務(wù)場景描述；

4、腳本和輔助工具的開發(fā)及使用 按照用例描述，可利用工具進(jìn)行錄制，然后在錄制的腳本中進(jìn)行修改；比如參數(shù)化、關(guān)聯(lián)、檢查點(diǎn)等等，最后的結(jié)果使得測試腳本可用，能達(dá)到測試要求即可；

PS：個(gè)人而言，建議盡量自己寫腳本來實(shí)現(xiàn)業(yè)務(wù)操作場景，這樣對個(gè)人技能提升較大；

一句話：能寫就絕不錄制！??！

四、測試執(zhí)行與管理

在這個(gè)階段，只需要按照之前已經(jīng)設(shè)計(jì)好的業(yè)務(wù)場景、環(huán)境和測試用例腳本，部署環(huán)境，執(zhí)行測試并記錄結(jié)果即可。

1、建立測試環(huán)境 按照之前已經(jīng)設(shè)計(jì)好的測試環(huán)境，部署對應(yīng)的環(huán)境，由運(yùn)維或開發(fā)人員進(jìn)行部署，檢查，并仔細(xì)調(diào)整，同時(shí)保持測試環(huán)境的干凈和穩(wěn)定，不受外來因素影響。

2、執(zhí)行測試腳本 這一點(diǎn)比較簡單，在已部署好的測試環(huán)境中，按照業(yè)務(wù)場景和編號，按順序執(zhí)行我們已經(jīng)設(shè)計(jì)好的測試腳本。

3、測試結(jié)果記錄 根據(jù)測試采用的工具不同，結(jié)果的記錄也有不同的形式；現(xiàn)在大多的性能測試工具都提供比較完整的界面圖形化的測試結(jié)果，當(dāng)然，對于服務(wù)器的資源使用等情況，可以利用一些計(jì)數(shù)器或第三方監(jiān)控工具來對其進(jìn)行記錄，執(zhí)行完測試后，對結(jié)果進(jìn)行整理分析。

五、測試分析

1、測試環(huán)境的系統(tǒng)性能分析 根據(jù)我們之前記錄得到的測試結(jié)果（圖表、曲線等），經(jīng)過計(jì)算，與預(yù)定的性能指標(biāo)進(jìn)行對比，確定是否達(dá)到了我們需要的結(jié)果；如未達(dá)到，查看具體的瓶頸點(diǎn)，然后根據(jù)瓶頸點(diǎn)的具體數(shù)據(jù)，進(jìn)行具體情況具體分析（影響性能的因素很多，這一點(diǎn)，可以根據(jù)經(jīng)驗(yàn)和數(shù)據(jù)表現(xiàn)來判斷分析）。

2、硬件設(shè)備對系統(tǒng)性能表現(xiàn)的影響分析 由于之前設(shè)計(jì)了幾個(gè)不同的測試環(huán)境，故可以根據(jù)不同測試環(huán)境的硬件資源使用狀況圖進(jìn)行分析，確定瓶頸是再數(shù)據(jù)庫服務(wù)器、應(yīng)用服務(wù)器抑或其他方面，然后針對性的進(jìn)行優(yōu)化等操作。

3、其他影響因素分析 影響系統(tǒng)性能的因素很多，可以從用戶能感受到的場景分析，哪里比較慢，哪里速度尚可，這里可以根據(jù)2\5\8原則對其進(jìn)行分析； 至于其他諸如網(wǎng)絡(luò)帶寬、操作動作、存儲池、線程實(shí)現(xiàn)、服務(wù)器處理機(jī)制等一系列的影響因素，具體問題具體分析，這里就不一一表述了。

4、測試中發(fā)現(xiàn)的問題 在性能測試執(zhí)行過程中，可能會發(fā)現(xiàn)某些功能上的不足或存在的缺陷，以及需要優(yōu)化的地方，這也是執(zhí)行多次測試的優(yōu)點(diǎn)。

六、總結(jié)

只要你有能力去做的事就一定要去做，不要給自己留下任何遺憾，人生最重要的不是所站的位置，而是所朝的方向。

一個(gè)沒有目標(biāo)責(zé)任制的人就像一艘沒有過舵的船，永遠(yuǎn)漂流不定，只會到達(dá)失望失敗和喪氣的海灘。

生于憂患，死于安樂。如果你想跨越自己目前的成就，就不能畫地自限，而是要勇于接受挑戰(zhàn)。對畏畏縮縮的人來說，真正的危險(xiǎn)正在于不敢冒險(xiǎn)！

?正在做測試的朋友可以進(jìn)來交流，群里給大家整理了大量學(xué)習(xí)資料和面試題項(xiàng)目簡歷等等....文章來源地址http://www.zghlxwxcb.cn/news/detail-490881.html

到了這里，關(guān)于性能測試需求分析和學(xué)習(xí)的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！