這里僅僅做記錄，用于細化測試方法。

web性能測試不光是準(zhǔn)備測試腳本、測試場景以及環(huán)境準(zhǔn)備，在前期也需要很多工作。需要我們在溝通交流中投入很多精力。比如項目確認、需求確認、開發(fā)人員溝通、設(shè)計人員溝通等。這些東西一般別人不會直接告訴你，這就需要我們自己抓人去問，無論是打電話，發(fā)消息，還是跑到對方身邊，只要能找到自己想要的即可。

一般需要確認這樣幾個問題：

項目：項目是新項目還是老項目。

**需求文檔：**有沒有需求文檔，需求文檔中有沒有對于數(shù)據(jù)量、人數(shù)等進行描述。有沒有特殊的性能需求。

**歷史文檔：**如果是老項目，那肯定有之前的測試文檔了。尤其是有些項目的測試工具比較奇葩，如果有性能測試方案，那測試起來就方便很多。

**設(shè)計人員：**需要找設(shè)計人員確認數(shù)據(jù)庫設(shè)計表（要過來），使用了什么樣的技術(shù)（比如ajax），有沒有用到緩存技術(shù)（一般都用），有沒有什么需要注意的地方（比如調(diào)用外部接口的程序等）。

**需求人員：**需要找需求人員確認一下實際環(huán)境是什么樣子的，包括現(xiàn)場環(huán)境（操作系統(tǒng)、數(shù)據(jù)庫、中間件，網(wǎng)絡(luò)帶寬，服務(wù)器配置），使用人數(shù)、在線人數(shù)。了解整個系統(tǒng)是要做什么的。性能測試的時候也需要了解業(yè)務(wù)，才能更好的去分析需求。

根據(jù)以上內(nèi)容，初步的問題確認就完成了。然后性能測試的第一步，該項目是否有可測性就可以開始分析了。

項目可測性

對于領(lǐng)導(dǎo)分配項目，首先要進行可測性驗證。因為設(shè)計人員、測試經(jīng)理不一定能正確評估性能測試。有些項目僅僅是設(shè)計人員覺得某個模塊存在瓶頸，需要并發(fā)壓一下，（出于多測比不測強的心理）然后，找到測試經(jīng)理的時候就是要求進行整體性能測試了。所以在跟設(shè)計人員確認問題的時候，設(shè)計人員肯定會詳細講述那個模塊需要著重測試。

以上是舉個例子，下面描述下常見不測項目。

1.使用人數(shù)過少的項目（10人以內(nèi)），這樣的項目在功能測試的時候如果有問題就能發(fā)現(xiàn)了，不需要再申請做性能測試。

2.使用人數(shù)很多，但是在線用戶數(shù)很少的（比如論壇），公司論壇可能使用人數(shù)是全體職工，公司沒有強制要求必須上論壇，那可能就不需要進行性能測試。

3.BI項目：BI項目針對前臺頁面基本上不需要測試性能，因為性能瓶頸主要在數(shù)據(jù)庫，可以直接優(yōu)化sql。

4.統(tǒng)計查詢：統(tǒng)計查詢功能一般是領(lǐng)導(dǎo)使用。一般一個系統(tǒng)也就1個領(lǐng)導(dǎo)在用，所以也不涉及性能。

5.接口部分：有時候項目會用到一些外部接口，這些接口需要做并發(fā)測試，但是頁面不需要做。

以上不一定符合實際情況，僅僅做參考。性能測試其實就是并發(fā)測試，所以主要關(guān)注的是用戶在某一段時間的使用數(shù)量，所以判斷可測性的時候可以用這個作為參考。

分析完項目的可測性后，確定這個項目確實有值得測試的地方，下一步就要針對項目內(nèi)容進行深入測試。

數(shù)據(jù)量分析

如果是老項目，那很好辦了，看看主表放了多少條數(shù)據(jù)，用了多少年，每年都有多少條數(shù)據(jù)，一個漂亮的分析就產(chǎn)生了。諸如第一年50000條數(shù)據(jù)每年依次遞升10%，共計500000條數(shù)據(jù)等。那往后在推3年、5年，約需要制作xxxx條數(shù)據(jù)。

如果是新項目，那就慘了，因為沒有參考，那咋整呢？我是這么考慮的，第一參考依據(jù)來自于需求人員，問問他大概多少數(shù)據(jù)量。因為現(xiàn)在的電子商務(wù)，一般來說都是將紙質(zhì)轉(zhuǎn)化成電子，如果有可能，需求人員是可以跟業(yè)務(wù)人員確認數(shù)據(jù)量的。還有一種方式就是可勁加數(shù)據(jù)，加到撐為止。什么叫撐呢，頁面打開慢了，查詢速度慢了就成了。然后開始優(yōu)化sql，至少保證sql本身沒有什么優(yōu)化的余地了，那數(shù)據(jù)量分析也就到這了。（前提：這個是有前提的，時間得富裕，沒時間的話都是扯淡）

用戶數(shù)分析

這部分我覺得挺坑的，啥用戶數(shù)量分析?。看_認了使用人數(shù)后就能分析了嗎？一點參考價值都沒有。（牢騷）在單位看了各種高級員工很漂亮的用戶分析ppt，其實一點參考價值都沒有。為啥？不管怎么分析，我覺得都是不對的，跟實際場景能對應(yīng)上嗎？。還不如啥都不管直接200絕對并發(fā)開始壓，壓到死為止呢。至少能發(fā)現(xiàn)在強壓力破壞性測試下，那些模塊不穩(wěn)定了。

牢騷過后，開始分析

用戶數(shù)分析是建立在良好的監(jiān)控條件下的，在保證整體框架設(shè)計良好，數(shù)據(jù)庫設(shè)計完善的前提下，直接上線。通過監(jiān)控獲取用戶的使用情況、在線情況以及頁面訪問數(shù)量后，分析起來才有依據(jù)，這樣的分析才能令人信服。這里主要是為測試人員的場景設(shè)計服務(wù)的，如果有了令人信服的數(shù)據(jù)，然后直接作用于場景，才是有效的測試。

監(jiān)控內(nèi)容需要包含

1.使用人數(shù)監(jiān)控（共計多少人登錄系統(tǒng)）

2.在某時間段內(nèi)在線人數(shù)監(jiān)控（時間可以調(diào)整）

3.頁面訪問次數(shù)，以及在某段時間內(nèi)的訪問次數(shù)

4.服務(wù)器參數(shù)、數(shù)據(jù)庫參數(shù)變化，JVM參數(shù)變化（單位都用java）文章來源地址http://www.zghlxwxcb.cn/news/detail-557652.html

到了這里，關(guān)于Web性能測試需求分析，具體應(yīng)該怎么做？的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！