在我剛知道性能測試時 想象能做性能測試的人都是工作了好些年（不再年輕），桌面上擺著兩臺電腦，每臺電腦的屏幕都不斷地在翻滾著數據信息，而他們能在閃爍的數據中發現異常數據。后來，我才知道，是我黑客帝國看多啦！

早前看到身邊的人做性能測試都是用LoadRunner，讓我一度以為沒有這個工具就無法做性能測試，會了這個工具就能做性能測試，于是自己去啃這方面的書（家里LoadRunner的書超過4本）。經過血淋淋的教訓，我知道，是我想多啦。

再后來自己加入了性能測試培訓班，以為上了培訓班，我就會做性能測試啦。后來，我知道，沒有實踐的理論都是空談。

想做什么，最快途徑是到能做的環境中去，環境很重要。

再后來因工作所需，開始接觸了百萬、千萬的數據性能測試（暫時沒有億級別的，期望公司客戶快速發展業務，給我個億用戶/數據，讓我也能得瑟下），才知道性能測試真實面目，不受工具限制，不受理論限制，不受所謂的指標限制。

那么性能測試一般有多少步驟呢？本人總結了常用的8點（網上能找到更多，我加了些自己的理解。）

1）獲取最常用場景

已有面向廣大用戶的系統，只要使用就能提取到性能測試點。

最直接的方式：自己可以去操作下。如：視頻網站，首頁（訪問量占總訪問量的50-70），內容詳情頁，各子導航等。

已有面向少數客戶的系統，最快速的方式看下數據庫表量，找出數據量大的表去問項目經理 數據是怎么產生的，也能獲取到性能測試點。

如果不能訪問數據庫，則可以找使用系統的客戶聊聊（找聊的人數不少于角色人數），聽聽他們是如何使用的 也能知道最常用的功能是什么。

如果是未上線的，就更好辦啦，找項目經理/產品經理/技術負責人聊聊唄，聽聽他們對系統的規劃、設想和設計。

2）獲取最終性能目標

方式一：客戶有明確要求。

先恭喜你，遇到一個有預期的客戶。但也得提醒你注意，客戶預期是否合理。

方式二：現有資源限制，想知道最大承載量。

方式三：啥都沒有的。

從我目前的經歷來看，這個最常見來著。（是不是也可以證明我經歷少呢，無從得知，歡迎討論）

這樣的情況，只要自己用客戶提供環境/公司環境，自己搭建一套最小系統，看最小系統的承載量啦。

3）設計性能測試用例

主寫：測什么場景，用什么測，收集什么信息，用例執行達標的方式是什么。

其次：規劃下用例執行順序。

好吧，規劃執行順序像測試策略啦，但個人總覺得一提到測試策略就是高大上、繁瑣的趕腳（請原諒我的淺薄），不適合我的笨腦瓜，還是直接簡潔方式適合我，就放在測試用例設計中吧。

4）搭建測試環境和造數據

在很多公司這個都是研發或運維的事情，我個人意見：測試人員自己做來的好。

好處：等需要調整環境時自己可以直接上手，不需要去請教研發和運維呀，大大節省了溝通成本和縮短修改的時間。

建議使用Jenkins得到系統部署包，最好能用docker 直接得到測試鏡像（如有興趣可以看我的部署專題）

存儲過程、shell腳本可以實現造數據。

能自己搞定的，盡量自己搞定，不依賴他人，才是活的更好，工作也是如此的。

5）將word形式的測試用例改成可執行的用例

怎么寫腳本需要看你選的是什么工具來做性能測試。

如一個URL頁面的性能測試，我通常就用開源ab,webench。（關于市面上云性能測試服務，但有去驗證下，再來發表意見）

6）執行用例

這里有一點要提醒，常見的就是1個用例執行2小時，4個用例就是執行8小時，然后就認為自己一天能完成性能測試的執行，可往往第1個用例要花費雙倍以上的時間（環境配置的微調）

7）收集結果

不是測試執行后才考慮這個問題，是在測試用例設計時就考慮好的，到執行時確認收集的結果是正確即可。

8）編寫性能報告

在網上只有一搜索性能測試報告模版查到的就會是一個很多頁數的模版。

個人不建議用這樣的模版來匯報性能測試結果，我一般只有測試項對應著的性能測試指標，且用圖表的直觀地表達出性能上升期、峰值、穩定期。

當然也有人會問我：你的結果是怎么得出的，這時我才會解析測試結果是怎么來的。

我很少講術語，可能是我太懶吧，也或許是我對講術語沒底氣，望沒有術語的這篇文章能給你帶來收獲，歡迎拍磚，糾正。