2)性能測試環境下什么數據也沒有，所以通過導入功能測試環境的數據來充當，mysql工具中有一個很好的功能：可以將功能測試數據庫庫的表結構和數據復制到性能測試數據庫，如果性能測試數據庫中已經存在該表，就drop掉該表，執行速度很快，大大方便我們準備數據。推薦大家用SQLyog Enterprise這個工具，真的不錯。方法如下：打開mysql的數據庫，連接到功能測試庫上，點擊File——New Conections，連接到性能測試庫上，選擇你要操作的表，右擊選擇第二項——Copy Table To Diffierent Host/Database，在界面中左邊是源數據庫，也就是我們的功能測試數據庫，選擇你要復制的表，支持多選，右邊選擇目標數據庫，也就是我們的性能測試數據庫及對應的用戶，如果表已經存在，勾選選項：Drop table if exists in target ，具體要拷貝表結構和數據或者只是表結構都可以自己選擇，最后點擊copy，數據庫表結構和數據很快可以復制完。
4、錄制腳本：
淘江湖二期很多頁面是采用了異步方式調用，所以錄制完一個頁面后，通過抽取每個請求作為一個腳本。接口測試這塊采用http的方式去模擬測試，這樣方式最大的好處是腳本準備比較方便。
5、測試執行：
1)一個頁面通過加載該頁面所有的異步請求，逐步增加各個腳本的并發用戶數，調整并發用戶數，查看是否滿足預期的tps。
2)測試過程中時刻關注lr的運行情況，曲線有沒有波動很大，幾個日志信息，debug日志，超時日志和velocity日志，是否有大量日志出現。監控 java虛擬內存是否正常釋放，曲線是否平穩，而不是往上的趨勢。一般如果有問題的話，剛開始運行腳本就會出現頻繁報錯，這時需要馬上停下來查看問題原因。排查原因有很多，由于我們介入較早，有一些是因為數據庫表結構沒有建索引，或者是應用的版本沒更新導致(初期bug比較多，版本經常更新)，所以經過這次測試，深刻體會到性能測試的前提需要在sql審核通過，索引加好，功能比較穩定的前提下進行，也就是功能測試第二階段開始，此時功能相對穩定，表結構也不會怎么變化，會少走很多彎路。
3)由于這次頁面性能測試依賴的應用比較多，最多有用到13臺應用服務器，當測試某個性能點的時候，需要查看與該應用交互的應用的情況，可以用netstat -nal命令。查出來后，監控這些相關的服務器，cpu，load，日志情況等。
4)用lr監控cpu這些數據時發現有一臺服務器監控到的cpu有問題，空閑狀態cpu就已經達到60%了，具體原因也不清楚，所以換了方式采用我們這邊的一個監控cpu和load的shell腳本來做。
6、關于性能測試計劃：這次測試有11個性能點，6個接口和5個頁面，計劃中根據測試優先級高低分三個階段進行，分階段搭建測試環境和準備數據和腳本，先接口后頁面的順序執行。
7、關于性能測試日報：日報中主要記錄目前所處的測試階段，當天的測試工作，測試結果和結果分析，BugList，問題和風險，以及明天的計劃。
最后非常非常感謝云帥，像老師一樣，非常細心和耐心，教我很多很多，讓我受益很多很多，更讓我體會到了一個優秀的性能測工程師認真嚴謹的工作態度。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
