從接到性能測試的測試需求，到最終測試完成，都需要經過哪些階段呢？中培偉業《軟件自動化測試與持續集成實踐》培訓專家陸老師在這里根據自己多年的工作經驗進行了介紹：

首先要評估測試需求是否合理，并不是所有的性能測試需求都需要直接來安排測試，而是評估下是否需要做本次性能測試。產品提出需要做性能測試是基于用戶的考慮，可能并不了解實現。如果了解具體實現了后，有些看似請求量大的測試，可能并不需要做。

陸老師舉了個例子：假如一個請求，每次用戶開啟應用時都會發送到服務器，服務器則會返回給客戶端本賬號在好友中的積分排名情況。從產品的角度認為，每次應用啟動，都會觸發服務器查詢一次數據庫。這樣會數據庫會造成很大壓力。而測試再了解了具體實現后發現：針對每個用戶機器碼的排序數據是從redis服務器返回的，而redis服務器會每隔一小時請求存儲的mysql服務器來更新賬號排名信息，這樣看來mysql服務器請求頻率很低，沒有任何壓力。由于redis服務器的性能之前已經測試過類似的，沒有性能問題，所以這次并不需要對mysql服務器做壓力測試

其次，如果確定要進行性能測試，就需要評估性能測試的方案。包括環境搭建、邏輯了解、數據準備、腳本編寫、測試過程、問題定位、修改優化、回歸、出報告的時間。需要強調的是，性能測試開始的時間一定是功能測試已經通過了。否則進行性能測試會存在修改功能邏輯導致性能發生變化，性能測試就沒有任何指導意義了。

環境搭建：

這里主要指測試服務器的搭建和打壓環境的搭建。測試環境可以有開發來搭建。原則上測試服務器配置不能高于線上服務器的配置，且測試服務器部署的服務要盡量接近線上服務器，比如說線上服務器上運行了3個服務，那么測試服務器也要運行同樣類似，包括打壓腳本上的設計也要考慮（后面會講），這樣得出的結果才具有指導意義。再就是linux打壓機的部署。具體部署方法就不在此贅述了。

邏輯了解：

這里主要開始著手了解整個性能測試的業務邏輯。一般需要了解請求個數，請求參數含義等。除此之外，在這里要強調幾個新手容易忽視的問題：就是打壓測試服務器時，要和線上服務器做明確隔離。不要簡單認為所有的請求都是指向測試服務器，就認為是只向測試服務器打壓。主要分為三種情況:1、測試請求會經過跳轉鏈接到線上服務器。2、測試請求的js會異步請求線上資源。3、測試服務器會經過邏輯處理后返回給客戶端，而這里的邏輯處理可能包括到線上服務器查詢數據。

數據準備：

這里主要指性能測試有效數據的準備。為什么說是有效數據呢？舉個例子：加入你手動寫完腳本后，跑一下腳本，發現服務器返回沒有報錯。都是200的response。這是否就說明是有效的打壓呢？未必！應該回放腳本時，通過抓包工具抓包看下，對比真正使用場景中返回的response。看下內容格式是否一致。如果你的打壓腳本返回的是空的200請求或者僅僅有關鍵字，但是內容都是空的，而真正場景返回的是大小為15K的json。這說明你的打壓場景是有問題的。應該結合服務器邏輯和詢問開發。構造出可以讓服務器認為是正常的請求來處理。從而返回正常的數據。