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

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

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

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

環(huán)境搭建：

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

邏輯了解：

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

數(shù)據(jù)準備：

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