那麼到底該怎麼去做性能測試呢？
1、首先要了解被測系統的結構和有關知識的儲備。
了解了被測系統，在後期性能出現異常的時候，定位就相對容易一些；而且知道在測試的過程中需要監控什麼。
一個簡單B\S系統結構圖：
該系統有一下及部分組成：
Memcached：負責做資料緩存
lucene：負責做搜尋
RabbitMQ：負責某些業務的隊列處理
從以上系統結構來看，要搭建和維護性能測試環境，需要的一些必要的知識。
對于APP：需要了解nginx的相關知識，怎麼修改配置，在哪裡看日志
對于Memcached：怎麼搭建Memcached，怎麼檢視命中率，Memcached的作用是什麼
lucene:這個lucene是幹什麼用的，要怎麼配置
RabbitMQ：MQ要如何配置，都那些業務用到了MQ。
Mysql：如何配置主從，為什麼要配置主從，主從如何同步等等
在搭建環境的過程中肯定會遇到這樣或那樣的問題，要自己找資料，或者相關的開發人員一起解決，并注意做筆記，防止以後同樣的問題再出現。
2、了解了系統結構，開始搭建測試環境，并準備資料。
測試環境盡量要和生産環境的結構保持一緻，還有配置檔案等也要保持一緻，這樣能保證性能測試的結果更加真實和接近生産環境。
資料準備一定要充足，而且資料量要大于等于生産環境，這樣能更真實的模拟生産環境。比如對一個select語句而言，10W的資料，和1000W的資料，查詢時間肯定有差别。如果資料量太小就不能反映真實情況下性能了。（可以把線上的資料導入到測試環境，但是要注意把使用者比較隐私的資料都替換掉）
如果有可能的話，測試環境的資料要比生産環境多出20%，做一些性能上邊的備援，防止發生突然的性能尖峰。
3、了解需求，找出測試點
和産品、技術溝通需要做性能測試的業務；并了解相應的業務的性能名額，如頁面的響應時間，TPS（事物處理）或者系統期望能承受多少并發等。
4、設計性能能測試用例
根據業務編寫相應的性能測試用例。
功能
線上使用者達到高峰時，使用者可以正常發帖，保證200個以内使用者可以同時發表文章。
目的
測試系統200個以内的使用者同時線上發帖。
方法
采用LoadRunner的錄制工具錄制一個郵件發送過程，然後對腳本進行優化，加上事物點，檢查點等。過程中監視B端的響應，還有網絡傳輸，web服務和資料庫伺服器的性能，并觀察伺服器相應服務的日志，檢查MQ的狀态，memcached伺服器的狀态和性能
預期結果
符合業務的預期，日志木有異常等（不詳細列舉）
5、編寫并優化腳本
根據測試用例錄制發帖的腳本，加入事物點、檢查點、參數化，并回放，確定腳本沒有問題，可以正常運作。
6、設計性能測試場景
設定一個漸進的場景10-30-60-100-150-200，這麼做的目的防止一下子上去就是200個并發，出了問題，不知道系統最佳的并發是多少。
（上邊的漸進場景不一定合理，隻做示意）
7、啟動監控，并開始跑性能測試場景
設定場景完畢後，開始在伺服器端啟動監控，然後開始啟動場景。
8、監控場景執行，監控伺服器的資源
loadrunner可以搜集一些性能測試資料，事物的pass數，fail數，error數，都要做統計。
監控伺服器的資源，可以利用nmon，也可以是用linux自帶的指令top，vmstat等。
也要監控伺服器的日志輸出，看是否有異常出現。例如：檢視mysql的慢日志，nginx的日志等。
9、搜集結果資料，分析探讨
最後對性能測試搜集的資料進行分析，找出性能測試的拐點。
10、對系統進行優化，并重複7-9步，直至測試結束
PS:性能測試不是一個人的事情，中間設計了，開發，産品，運維，QA，DBA，要大家共同協作，才能做好性能測試。
限于水準有限，用疏漏之處，多多包涵。
最新内容請見作者的GitHub頁：http://qaseven.github.io/