Web性能測試分析操作流程？
一般需要確認這樣幾個問題：
項目：項目是新項目還是老項目。
需求文檔：有沒有需求文檔，需求文檔中有沒有對于數據量、人數等進行描述。有沒有特殊的性能需求。
歷史文檔：如果是老項目，那肯定有之前的測試文檔了。尤其是有些項目的測試工具比較奇葩，如果有性能測試方案，那測試起來就方便很多。
設計人員：需要找設計人員確認數據庫設計表（要過來），使用了什么樣的技術（比如ajax），有沒有用到緩存技術（一般都用），有沒有什么需要注意的地方（比如調用外部接口的程序等）。
需求人員：需要找需求人員確認一下實際環境是什么樣子的，包括現場環境（操作系統、數據庫、中間件，網絡帶寬，服務器配置），使用人數、在線人數。了解整個系統是要做什么的。性能測試的時候也需要了解業務，才能更好的去分析需求。
根據以上內容，初步的問題確認就完成了。然后性能測試的步，該項目是否有可測性就可以開始分析了。
項目可測性
對于領導分配項目，首先要進行可測性驗證。因為設計人員、測試經理不一定能正確評估性能測試。有些項目僅僅是設計人員覺得某個模塊存在瓶頸，需要并發壓一下，（出于多測比不測強的心理）然后，找到測試經理的時候就是要求進行整體性能測試了。所以在跟設計人員確認問題的時候，設計人員肯定會詳細講述那個模塊需要著重測試。
以上是舉個例子，下面描述下常見不測項目。
1.使用人數過少的項目（10人以內），這樣的項目在功能測試的時候如果有問題就能發現了，不需要再申請做性能測試。
2.使用人數很多，但是在線用戶數很少的（比如論壇），公司論壇可能使用人數是全體職工，公司沒有強制要求必須上論壇，那可能就不需要進行性能測試。
3.BI項目：BI項目針對前臺頁面基本上不需要測試性能，因為性能瓶頸主要在數據庫，可以直接優化sql。
4.統計查詢：統計查詢功能一般是領導使用。一般一個系統也就1個領導在用，所以也不涉及性能。
5.接口部分：有時候項目會用到一些外部接口，這些接口需要做并發測試，但是頁面不需要做。
以上不一定符合實際情況，僅僅做參考。性能測試其實就是并發測試，所以主要關注的是用戶在某一段時間的使用數量，所以判斷可測性的時候可以用這個作為參考。
分析完項目的可測性后，確定這個項目確實有值得測試的地方，下一步就要針對項目內容進行深入測試。
數據量分析
如果是老項目，那很好辦了，看看主表放了多少條數據，用了多少年，每年都有多少條數據，一個漂亮的分析就產生了。諸如年50000條數據每年依次遞升10%，共計500000條數據等。那往后在推3年、5年，約需要制作xxxx條數據。
如果是新項目，那就慘了，因為沒有參考，那咋整呢？我是這么考慮的，參考依據來自于需求人員，問問他大概多少數據量。因為現在的電子商務，一般來說都是將紙質轉化成電子，如果有可能，需求人員是可以跟業務人員確認數據量的。還有一種方式就是可勁加數據，加到撐。什么叫撐呢，頁面打開慢了，查詢速度慢了就成了。然后開始優化sql，至少sql本身沒有什么優化的余地了，那數據量分析也就到這了。（前提：這個是有前提的，時間得富裕，沒時間的話都是扯淡）
用戶數分析
這部分我覺得挺坑的，啥用戶數量分析啊？確認了使用人數后就能分析了嗎？一點參考價值都沒有。（牢騷）在單位看了各種高級員工很漂亮的用戶分析ppt，其實一點參考價值都沒有。為啥？不管怎么分析，我覺得都是不對的，跟實際場景能對應上嗎？。還不如啥都不管直接200絕對并發開始壓，壓到死呢。至少能發現在強壓力破壞性測試下，那些模塊不穩定了。
牢騷過后，開始分析
用戶數分析是建立在良好的監控條件下的，在整體框架設計良好，數據庫設計完善的前提下，直接上線。通過監控獲取用戶的使用情況、在線情況以及頁面訪問數量后，分析起來才有依據，這樣的分析才能令人信服。這里主要是為測試人員的場景設計服務的，如果有了令人信服的數據，然后直接作用于場景，才是有效的測試。
監控內容需要包含
1.使用人數監控（共計多少人登錄系統）
2.在某時間段內在線人數監控（時間可以調整）
3.頁面訪問次數，以及在某段時間內的訪問次數
4.服務器參數、數據庫參數變化，JVM參數變化（單位都用java）
北京Python測試開發基礎班
北京app專項測試培訓班
北京測試開發培訓班
北京web安全測試實戰班
北京性能測試培訓課程