新人如何學習性能測試?
首先:必須有一個良好的學習心態,學習任何知識貴在堅持,如果半途中止,學不好任何東西。其次:要有一個不懂就問的心,學習很忌諱不懂裝懂第三:要有一個良好的學習體系或者學習平台,我個人推薦BestTest軟體測試自學與分享平台的性能測試自學路線圖性能自學路線,以及網站上的學習視頻,性能測試學習路線上推薦的書籍很不錯。第四:學習順序。
第一步:學會主流的性能測試工具,比如loadrunner,畢竟面試問得多。弄清楚loadrunner的架構,掌握基本的協議比如http,學好loadrunner,參考書籍段念的《軟體性能測試過程詳解與案例剖析》,在學習loadrunner的時候切記只看不做,必須自己動手搭建一套測試環境,比如典型的論壇啊,bugfree啊之類的,自己動手親自去實踐
第二步:掌握操作系統,資料庫,中間件等監控分析思路第三步:掌握基本編程ps:這些書籍建議去看BestTest軟體測試自學與分享平台的http://www.besttest.cn/article.php?id=127上推薦的書籍最後:你會發現你已經成為了一個出色的性能測試工程師這個是我以前準備的一個學習計劃,供你參考!
任務名稱
任務要求
參考資料
考核標準
性能測試基礎知識
(*必學)
學習性能測試基礎知識
了解性能測試基本概念
對性能測試的目的、指標等有基礎了解
2工作日
性能測試工具專題
(*必學)
學習性能測試工具Jmeter
1、了解和熟悉Jmeter腳本錄製方法
2、了解和熟悉Jmeter關聯3、了解和熟悉Jmter參數化4、了解和熟悉CRMJmeter腳本處理要點
1、熟悉和掌握Jmeter腳本錄製(2天)
2、熟練和掌握Jmeter關聯(1天)3、熟悉和掌握Jmeter參數化(1天)4、完成Vodka系統JMeter腳本模版(1天)5工作日
學習jvm性能監控工具
1、學習JDK
Tools的使用
2.掌握visualvm用法(1天)
3.掌握nmon、free、top用法(2天)4.了解JDKTools使用(1天)5.了解平台的使用(1天)
6工作日
性能測試流程專題
(*必學)
學習性能測試流程知識
1、性能測試流程
2、性能測試過程中的文檔1.了解性能測試流程。(1天)
2.能新建性能測試需求、方案、報告等文檔。(1天)2工作日
性能測試中級專題
(選學)
學習Java語言基礎
1.全面了解Java語言基礎
2.了解JVM基本原理1、《Java編程思想》
2、《分散式Java應用》
3、《深入JVM虛擬機》Java編程思想學習筆記(1月)
分散式Java應用學習筆記(15天)深入JVM虛擬機學習筆記(10天)2個月
學習網站架構
1,了解負載均衡
2,了解Memcached,靜態化3,了解反向代理,資料庫優化4,……書中知識
《構建高性能Web站點》
了解網站架構常用技術,性能關注點,性能標準(1月)
1個月
學習前端性能
1,學習雅虎前端性能優化10條準則
2,思考前端性能測試框架的開發1.《高性能網站建設指南》
2.Selenium與WebDriver: Selenium Documentation1.《高性能網站建設指南》學習筆記(15天)
2.Selenium與WebDriver,能完成HelloWorld(5天)
20天
性能測試高級專題
(選學)
原理與各種前沿技術
1.各種開源框架,伺服器框架
2.熟悉各種資料庫及其性能優化原理3.熟悉Linux操作系統原理4.熟悉網路技術原理5.……(各種計算機知識)由大家發掘,我現在還在准
軟體測試火的一塌糊塗的時候,大家心裡估計在顫抖。不就是點點系統嘛,能有什麼大出息,軟體測試做幾年以後大家水平都差不多,如何才能不被快速取代,去做性能測試呀。
測試做久了就會知道,性能測試是測試人員的終極夢想,這是為什麼呢?工資高呀。我有朋友做了3年功能測試,感覺太機械,然後報培訓班學習性能測試,目前從事性能測試工作。
萬事開頭難,我從想做性能測試到現在5個年頭過去了,現在把做性能測試過程中的迷茫、堅持、到後來的被認可寫下來,紀念下那年的加班歲月。
我一直認為自己很幸運,在校期間就找了份實習工作,做金融方面的測試。銀行系統涉及到錢,所以從公司到銀行很重視測試。當然了現在互聯網時代,性能測試就更重要了。
大三暑期實習時做了軟體測試,培訓老師說軟體測試分為功能測試和性能測試,最牛逼的是做性能測試,那簡直是受萬人敬仰。
剛好學校開始選畢設課題,看到了loadrunner性能測試題目,帶著想成為行業的大拿,受到膜拜的幻想,於是乎選擇了這個課題,彷彿看到了未來做性能測試的樣子。
由於在學校老師沒教過這個,所以得自學,就連loadrunner工具也得自己在網上下載,loadrunner是大型商業軟體,小公司用的大都是開源工具,公司做銀行系統,所以性能測試是重中之重,正好有此軟體。
第一次聽培訓老師講性能,特別認真的帶著本和筆坐第一排聽。培訓老師在公司待10多年了,講的很好。「80%的交易是20%的時間完成的、tps、tps拐點、腳本、並發用戶數、最大並發用戶數、單交易場景、混合交易場景等」聽的雲里霧裡。
實習時在公司培訓班待了一周,做了個小型銀行系統,大概只有賬戶查詢、開戶、存款貸款等小模塊。系統用於是乎我就在電腦里安裝了這個系統做性能測試。
公司有配置庫,文檔包括各種類型,恰好有性能測試文檔。由於公司有2人做性能測試,常年在客戶現場出差,所以一切都得自學,帶我畢設的老師也是沒做過這方面的工作。
度娘里找答案,清一色全是loadrunner的工具使用,如何設置參數、如何錄製腳本、腳本參數化等。到了這步就木有下文了,寶寶心裡苦。
我最想看到的是錄製腳本後腳本運行成功(資料庫里有條成功數據)、如何設置場景、如何獲取有用的數據、以及如何測出瓶頸、以及如何解決瓶頸、最後出份漂亮的性能測試報告。心理想著等我哪天做完性能測試一定和大家分享有用的知識。現在回想起來,當初真是太可憐了,錄製腳本後,回放錄製的視頻,界面一直顯示登錄超時,登陸腳本都無法登錄系統,更別提之後的測試腳本了。
大四畢設做的很不好,沒人指導,自己在瞎琢磨,沒有寫過測試腳本,畢設答辯內容很空洞,勉強通過。
由於一直有做性能測試的心思,離開了第一家公司。之後找工作時拒絕了二包公司、拒絕了單純的界面測試,找了家功能測試、性能測試都涉及的。然後就一直待這家公司。
我主要做理財項目,涉及功能測試、介面測試、壓力測試、穩定性測試。
2014年銀行理財忽然賣的很火,某城商行,系統承受不了壓力,然後要做壓力測試。我作為項目組唯一的測試員,這項工作落在我頭上。真是又緊張又興奮,開心的是可以親手做性能測試了,緊張的是之前只有點基礎。
就像如開發人員初次學習寫代碼,運行helloworld一樣,我首先得錄製登錄腳本,只要這個調通其他的也就迎刃而解。
web系統,基於web(HTTP/HTML)腳本很快錄好了,可是運行顯示登錄超時,百思不得其解,領導下命令今晚必須出結果,怎麼辦,打電話求助公司的性能測試部門,他讓我在腳本里做了個關聯就可以了。
腳本調通後,運行腳本,查看日誌顯示交易成功。保險期間我寫了個select語句查詢流水表,金額、賬戶都正確,就是剛執行腳本後插入的那條數據。
終於成功了一把,最終熬到凌晨2點,設置了系統運行8小時,回家睡覺去了。第二天查詢資料庫,成功了10萬多條沒有報錯,簡直好驚喜。
由於知識有限,第二天買了本性能測試書,那段時間,只要閑下來就會錄製其他交易的腳本,學習到了腳本參數化、關聯等。那年別的項目也做性能,所以我學習了web、socket、xml協議的腳本。
測試腳本
做性能測試第一步就是寫測試腳本,一個完美的腳本是成功的一半。
腳本分為2種模式:錄製、手動編寫。
由於系統是web類型的,所以直接用工具錄製,關鍵是當初也不會寫啊。
圖片發自簡書App腳本參數化:
添加事務
圖片發自簡書Apploadrunner11以上版本不添加事務,場景執行後tps無值。
關聯關聯分為自動關聯、手動關聯,適合複核交易,通過流水號查詢交易,適用於http協議。
測試數據參數化圖片發自簡書App測試腳本中為了保證流水號的唯一性,添加時間數字+時間毫秒設置。
日誌設置
f4設置log,選擇參數等。
圖片發自簡書Ap腳本運行後,日誌框會顯示交易狀態,遇到有參數時寫print語句,日誌里可以看到參數取值是否正確。
socket腳本模版
xml腳本,保證發起報文和接收報文都是明文,接收端如果是密文,測試時先解密再測試。
圖片發自簡書App發送報文,報文長度必須正確,接收報文內容可以為空,長度數字寫大點,確保大於實際的報文長度。
公司針對測試介面有模擬工具所以可以直接錄製,也可以寫腳本。首先明白介面用的是什麼報文然後再寫腳本。
現在給大家一份性能測試報告1、測試背景
首先確保功能測試覆蓋率達到100%,缺陷通過率大於95%,其次做性能測試。銀行理財產品有銀行兜底,所以賣的很火,銀行發產品後客戶集中在一段時間搶購,導致系統壓力,出現大量失敗的交易,所以為了保證系統長期運行的穩定性,針對典型交易做性能測試。
2、測試目標
獲取系統的處理性能指標,滿足當前生產系統及未來3年的業務發展需要。
發現性能瓶頸,協助開發人員進行性能調優。
3、測試指標
平均事物響應時間ART:
響應時間遵循2、5、8s原則,本次測試響應時間小於等於8s;
並發用戶數:現在高峰日操作人數500人,20%的並發量計算,高峰日並發用戶數大於等於100
規劃未來2年高峰操作達到600人,20%的並發量,並發用戶數大於等於120
規劃未來三年操作人數達到700人,20%的並發量,用戶數大於等於140。
資源使用指標:cpu使用率小於等於80%
內存使用率小於等於80%
磁碟交換率小於等於80%
tps值:每秒處理的業務筆數,80%的交易在20%的時間完成,每天交易量10萬筆,一天8小時
tps=80%*100000/(8*3600*20%)=13.89
並發交易成功率:大於等於95%
4、選取典型交易
性能測試主要針對交易量大的交易,如購買、贖回、份額查詢。
5、測試工具
loadrunner8.1
nmon監測資源使用率,磁碟、cpu、內存等。
6、測試類型
基準測試
單交易單用戶測試,典型交易在無壓力情況下獲取單筆交易處理的耗時,為之後的並發測試提供一個數據參考,一個用戶跑5分鐘。
驗證測試腳本及測試參數的正確性。
獲取單筆交易的性能數據,主要是單筆交易平均響應時間、TPS。
並發測試主要分為:單交易多用戶測試和混合交易多用戶測試,由於最後要跑穩定性,本次只做單交易多用戶測試。
每個典型交易通過單交易多用戶迭代執行,獲取性能指標,比如TPS、ART、系統資源使用情況,根據需要進行性能調優。
tps出現拐點時,繼續測2組數據,如果這2組數據tps明顯下降,此時就測出了最大並發用戶數。
備註:交易資料庫有當前流水表和歷史流水表,所以每次跑場景前刪除當前流水表的數據。
穩定性測試多交易多用戶的並發混合模式,對被測系統進行長時間的穩定測試,獲取持續加壓下的性能指標。考察是否會出現宕機、響應時間變長、交易成功率下降、資源使用率達99%的情況。
選取單交易並發時的最大用戶並發數取中間值跑穩定性。
7、測試總結
目前我遇到的瓶頸和解決方式
1、磁碟交換率達到99%;
2、內存使用率5%左右;加大系統進程數並增加並發用戶數。
3、內存使用率高達99%;經查看系統實時刷日誌,原因是某個可有可無的參數沒配置。
4、單交易sql執行時間2s;增加索引。
5、單交易執行時間過長;每次sum金額時,交易太多,執行時間過長,增加一張表每做一條交易sum一次,分擔了壓力。
6、tps值明顯在某個時間點降低,經查詢當前流水表數據大於100萬條;這個目前無解得對資料庫進行調優。
實踐出真知,知識有限,就分享這麼多了,寫這篇文章已經用盡了我的荒洪之力。
我認為性能測試分為5個階段,如下圖:
之前剛被虐完。其實最先接觸那個項目的時候,屬於雞飛狗跳型,啥都不懂,東一榔頭西一棒槌,最後還頂著各種壓力,瀕臨崩潰的境地才完成。也有一些總結。當然真要學習,還是最好有項目練手遠比自己對照著書一步步實現,進步快得多。主要學習有一下幾點。第一,明確的需求。比如要求是多少qps,響應時間多少為合格標準。第二,合適的工具。性能測試工具很多,如成熟穩定的loadrunner,jmeter,ab,http_load.這些工具都比較強大,因工作環境限制,loadrunner用得比較多。第三,排錯能力。如果遇到qps上不去,則如何排錯?檢查壓測以及被壓機器cpu ,內存,帶寬是否達到滿負荷。伺服器帶寬是否受影響,可以ping兩個ip間的ttl,如果小於1ms,則基本可忽略不記。第四,壓測腳本。壓測的時候,基本只走正向覆蓋,所以對下行報文的判斷通過與否,以及事務開始後的關聯函數。均可忽略不計,減少響應時間。第五,設置事務響應方式。依靠增加用戶數達到qps。不能直接亂點一通。第一次做這個的時候,就是設置多個用戶數,最後導致帶寬卡死,造成大量事務阻塞,在瀏覽器中ping相關地址都失敗。這基本就是我的學習過程。不知道能不能幫到你
看了下,不是賣書就是培訓機構,忽悠新手。
可以參考下面步驟1.先學一工具如jmeter2.熟悉一種協議如http3.做一次完整性能測試流程4.熟悉各種分析方法5.會各種協議和評估方法6.會開發性能各種工具7.會被測代碼實現原理8.會定位性能問題9.很快你就專家了
能不能具體的說一下軟體測試基礎知識需要學習哪些方面,或者相應的書籍也可以。
寫的很全面啊,不過我個人覺得,試錯+總結+思考才是最重要的,而這個也是我一直教導童鞋們必須養成的好習慣
免費在線看視頻學習性能測試:
請關注91TESTing微信公眾號:QA_91TESTing【視頻教程】性能測試 - LoadRunner
【視頻教程】性能測試【視頻教程】性能測試 - Jmeter【視頻教程】性能測試個人只做過遊戲性能方面的測試,也開發過一些測試工具,個人感覺,性能測試的階段其實可以分為3層:獲取性能數據,定位性能問題,修復性能問題。
以手游的性能測試為例,首先需要了解的就是,性能測試需要測試哪些指標?在遊戲里,指標很簡單,主要就是幀率(關係到遊戲是否流暢)和內存(關係到遊戲是否閃退)。了解了這些指標以後,如果能通過一些測試工具獲取到這些數據,那麼作為一個性能測試工程師,可以說已經入門了。
幀率和內存確實能反應一定的問題,但是粒度實在是太粗了,反應不出我們的價值,下一步是什麼呢?最好是能獲取到一些數據,可以定位性能問題,比如遊戲為什麼會卡,內存為什麼會高,這個階段就需要深入遊戲引擎,或者看源碼,或者看文檔,搞清楚引擎的原理,遊戲運行的機制,最終我們可以說,遊戲會卡是因為函數A時間太長,遊戲內存很高是因為資源B佔用了大量內存,那麼恭喜你,已經進入了第二階段。
定位到性能問題以後,我們就可以把測試報告往開發桌上一拍,你看,問題我都已經找到了,照著改就行,但開發的回應一般都是:我不知道怎麼改。不要認為這是開發的水平不行,實際上,你定位到的性能問題只是一個表現,而不是問題產生的原因。資源B佔用了大量內存,可能是因為資源B是一個圖片,這個圖片有2048*2048大小,但最終的作用只是主角衣服上的一個口袋!如果能在測試報告里加上這段話,開發很自然的就會把圖片改成4*4大小,問題就迎刃而解了。
個人認為,一個優秀的性能測試人員,不僅能發現性能問題,還要能發現性能問題的原因,這樣才能最大化提升性能測試的價值,對於遊戲性能測試,需要測試人員熟悉遊戲引擎,對於移動應用性能測試,需要測試人員了解操作系統的源碼及各種實現細節,要求還是非常嚴格的。最後,如果你能把上述步驟自動化,做成性能測試的工具,一鍵解決問題,那麼你真的就可以畢業了。
很好 正打算學習性能測試
今天要開始學習性能測試了,先好好學再來分享經驗
上面那些賣廣告的這樣合適嗎?沒一點點乾貨。
都是忽悠新書的?
mark下,自己也在做性能測試,不過水平一般。
厲害
推薦閱讀:
※如何做一份精緻的性能測試報告?
※哪款網站壓力測試工具值得推薦?
※論壇防灌水設置如何測試?
※性能測試中如何設計真實的負載呢?
TAG:性能測試 |