在軟件測試中和大家談一下有關項目性能測試體驗及實例
感想一
進入性能測試虛擬小組后，有幸跟著悟石元壯參與了一次項目的實踐，感覺做下來收獲蠻多的，把它總結下來。
一、創建文件夾
1.在執行性能測試的服務器上創建項目的名稱，如 D:\項目名稱，下面創建四個文件夾，分別為data，image，result 和 script，分別用戶存放性能數據，圖像，腳本和執行結果。
這樣做是便于歸類查找瀏覽，通常一臺服務器上會存放好多個項目的執行。
二、編寫腳本
這個提出來我主要是想說明下這次項目的腳本是在FF下跑的，是由于在性能測試執行階段還不支持ie下打開界面。
FF下錄制腳本主要設置如下：
new一個腳本的時候主要設置application type和 programe auguments 選擇win32 applications和 firefox.exe所在的目錄，如D:\Program Files\Mozilla Firefox\firefox.exe
三、關注的參數
1、尋找并發用戶數：
（1）首先通過遞增用戶找到load接近4，cpu接近75%時的壓力下的并發用戶數
（2）用這個并發用戶數去執行1h/2h的性能測試
（3）用這個并發用戶數去進行12h的穩定性測試
2、根據預期pv確定事務數：
每秒平均值 =( (總PV量*80%)/(24*60*60*40%))/服務器數量=pv/s，每秒的峰值為每秒平均值×1.6得出。（不過關于這個計算模型還有待改進的地方，并不是每條產品線的產品都是這么適用的）
pv/s等價轉化到tps，得出需要滿足的事務數
3、響應時間，需要小于0.5s
4、cpu：閥值為75%
5、load：閥值為4
6、內存：查看是否能正確釋放內存，存在內存泄漏等。
四、安裝監控工具
1、由于服務器上沒有成功安裝rstated工具，lr中就取不到load和cpu這些數據，所以替補的方法是安裝record-load.sh腳本，來采集load和cpu數據。
數據都是存放在cpu_load.list文件中。由于這個腳本沒有提供平均值的計算功能，執行完成后需要復制出來在excel中計算平均值，已經提建議給性能測試組他們會改進腳本。
2、安裝jconsole監控java內存，穩定性測試需要開這監控。需要在服務器中配置一項：
在/home/admin/dianping/bin jbossctl文件中
JAVA_OPTS=”$JAVA_OPTS -Djava.awt.headless=true”
JAVA_OPTS=”$JAVA_OPTS -Dsun.net.client.defaultConnectTimeout=10000″
JAVA_OPTS=”$JAVA_OPTS -Dsun.net.client.defaultReadTimeout=30000″
之后添加JAVA_OPTS=”$JAVA_OPTS -Djava.awt.headless=true -Dcom.sun.management.jmxremote.port=1090 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -Djava.rmi.server.hostname=*.*.*.*”
就ok了。打開jconsole后，主要查看內存——對內存使用情況和內存池”ps old gen”中的情況。能否正常釋放內存。
五、規范和模板
1、可以參照——性能測試腳本制作和場景設置規范.doc
2、腳本，測試結果，事務也有相應的命名規范，腳本命名為（應用名稱+性能點名稱），事務命名（性能點名稱），
測試結果命名規則為（應用名稱+性能點名稱+執行腳本時間+并發用戶數+運行時間）
3.模板——性能測試報告模板.doc和性能測試設計方案模板.doc
六、查看日志
1、查看debug日志（debug.log ）：查看是否有報錯信息
2、查看超時日志（filter.log）：查看是否超時。這里超時的判斷看是否大于200ms，超時的概率有個計算公式：超時的概率=超時日志中超時的數目/事務數
事務數可以在lr中的結果中有個查看總的事務數。超時的概率的閥值為10萬分之1。大于這個概率的時候需要開發去查找超時的原因。
七、linux命令
1.我這次主要用到如下的linux命令：ls，cd ，cd .. ，su ，vi，tail -f ，ctrl+z。當然還有很多其他的命令，之后再去實踐了。
八、性能測試期間遇到的問題和心得：
1、錄制腳本碰到的疑惑：腳本中發表點評的內容顯示成“?????????, ?????????”—— 這個就是輸入的文字只是中文顯示不出來，這樣顯示沒有問題；
2、對性能測試的各個參數點及對應的標準需要非常熟悉，這樣好比有了一個預期結果和一個參照標準，執行測試過程中可以很快查出某個點的性能問題；
3、shell腳本中建議增加一項LOAD和CPU的平均值的計算功能。
最后，還是要感謝下性能測試小組的同學給予的幫助，謝謝悟石和元壯，在這個項目中給我耐心的講解和解釋，讓我了解很多性能測試知識。
感想二
最近有幸和云帥參與了新江湖的性能測試，這個項目中，由于測試時間緊，性能點多，我們從開發提交測試后就進行性能測試。提早介入測試導致我們后來遇到很多問題。我主要的工作是協助云帥，申請性能測試服務器，驗證搭建好的性能測試環境和功能，準備性能測試數據，后期我參與了好友最近更新的相冊這個性能點的執行，下面說下具體是怎么做上面的事情的：
1、申請性能測試服務器：
先找總的開發負責人給出本階段性能點所需要信息，包括性能點，服務名，Hsf版本號，數據源，data-pool設置，jdk版本號，apache版本號，jboss版本號，jvm設置，代碼庫路徑，壓測頁面鏈接，依賴系統和該性能點對應的開發負責人。收集完這些信息后我們可以向悟石他們申請機器啦。申請時除了上面最后三點，其他內容都需要提供。這樣做是為了之后讓scm參照上面的信息部署環境。
2、驗證搭建的環境/功能：
1）驗證jdk、apache、jboss的版本：可以通過拷貝文件valid-env，執行check.sh來快速驗證jdk、apache、jboss的版本�；蛘咄ㄟ^如下的方法來依次驗證。
a、jdk版本查看 先通過jbosscle文件查找到使用的JAVA_HOME地址，然后根據目錄查找 /opt/taobao/java/bin/java -version 或者 /opt/taobao/java/bin/java1 -version；
b、apache版本查看 /opt/taobao/install/httpd/bin/httpd -version；
c、jboss版本查看 jboss啟動日志jboss_stdout.log中有，只要看前面幾行就能查找到。
2）證數據庫配置：數據庫的配置，一般存放在應用下的conf目錄下，orcle-***-ds.xml/mysql-***-ds.xml文件里。檢查它是否連接了正確的數據庫schema，連接數是否正確。
3）查看apache的訪問日志是否屏蔽掉。查看conf目錄下，httpd.conf文件里——CustomLog這個配置項。
4）驗證功能：需要確保所要測試的性能點的功能及相關功能正確。執行幾個主流程查看或者跑一下接口是否通。
3、準備測試數據：
1）向DBA討教了如何快速準備大量的性能測試數據。兩種方法。寫存儲或者設置autoincrement。我這次主要用的是后者。將表的主鍵設置 autoincrement，這樣可以通過insert into 表(字段1，字段2…) select value1，value2… from 表執行一次可以成倍增長當前的數據。這種方法簡單快捷，如果只是為了純粹增加表的數據流這個方法還是比較好的。當然除了數據庫的方法還可以通過接口去插數據，在lr中執行下也是不錯的選擇。
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，問題和風險，以及明天的計劃。
最后非常非常感謝云帥，像老師一樣，非常細心和耐心，教我很多很多，讓我受益很多很多，更讓我體會到了一個優秀的性能測工程師認真嚴謹的工作態度。
接下來我會以一個實例來更好的和大家了解一下性能測試這塊的
月初曾經到X省做電力公司的性能測試項目,由于之前并無任何的測試經驗以及性能測試項目經驗.所以這
次的性能測試之行心中充滿了太多的疑問以及不確定.
項目的背景：
電力公司的一個資產管理系統已經研發完畢,由于需要做推廣工作,故此在推廣之前需要做性能測
試,目的有三:
1、找出系統的性能瓶頸
2、對性能進行優化工作
3、確保系統在推廣后的效果
項目人員組成：
項目經理： 負責項目的溝通協調。公司對外的接口。
測試小組： 負責所有測試工作的計劃、執行及相關工作的安排分配。
平臺小組： 協助測試小組工作。保證測試環境平臺的適用性。
前兩個屬于性能測試的工作范疇；后一個屬于和開發商以及客戶一起共同努力產生的效果。
測試工作一共進行了兩周，大部分的時間都用在了和客戶溝通以及和開發商溝通上了。在項目初
期，由于經驗上的缺乏，沒有和客戶就業務上問題用專人、專時來討論，導致了在做需求的時候，我們
花費了大量人力、時間進行了重復的溝通，這導致了工作效率上降低。在第一周經�？梢钥匆娢覀兊臏y
試小組和平臺小組的內部以及外部溝通經常會就一個業務問題進行反復的討論。在項目后期，深刻的理
解了在進行專門的業務溝通會是十分必要的。
其實在整個項目中，之前自己一直認為在測試方面會花費較多的時間，后來才發現其實了解需求
、熟悉業務、了解應用、設計測試用例、做測試計劃。。。這些才是真正消耗時間的地方。在這種地方
做項目，各方面都需要進行協調。不是你一來，你就可以順順利利的開展工作。包括系統的應用對象（
最終實際的客戶），系統應用的主管（主管項目推廣的領導），還有機房的管理人員（平常的工作很需
要他們的支持），軟件開發商（由于軟件的性能他們自己心中最清楚，所以性能測試的很關鍵的部分是
要獲得軟件開發商的支持），中國IT室驗實內部小組的
溝通（平臺小組和測試小組的溝通，兩個小組為何成立，這里暫時不說）。
兩個星期的工作，實際上是很辛苦的，由于本人并不是負責項目，所以并沒有真正感受到項目經理的那種壓力以及各方的工作的協調。
其實不管是軟件項目還是開發項目，人在很大程度上是眾要的，技術有時候并不能給你很大幫助，但是你必須得具備基本的技術能力。
看來在國內，至少很多項目的成功與否還是得靠人�？客獠亢蛢炔康娜�。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
