概述一下性能測試流程?
- 1.分析性能需求。挑選用戶使用最頻繁的場景來測試。確定性能指標,比如:事務通過率
- 為100%,TOP99%是5秒,最大并發用戶為1000人,CPU和內存的使用率在70%以下
- 2.制定性能測試計劃,明確測試時間(通常在功能穩定后,如第一輪測試后進行)和測試環境和測試工具
- 3.編寫測試用例
- 4.搭建測試環境,準備好測試數據
- 5.編寫性能測試腳本
- 6.性能測試腳本調優(腳本增強)。設置檢查點、參數化、關聯、集合點、事務,調整思考時間,刪除冗余腳本
- 7.設計測試場景,運行測試腳本,監控服務器
- 8.分析測試結果,收集相關的日志提單給開發
- 9.回歸性能測試
- 10.編寫測試報告
如何確定系統最大負載?
通過負載測試,不斷增加用戶數,隨著用戶數的增加,各項性能指標也會相應產生變化,當出現了性能拐點,比如,當用戶數達到某個數量級時,響應時間突然增長,那么這個拐點處對應的用戶數就是系統能承載的最大用戶數
你們系統哪些地方(哪些功能)做了性能測試?
選用了用戶使用最頻繁的功能來做測試,比如:登陸,搜索,提交訂單
你們的并發用戶數是怎么確定的?
1)會先上線一段時間,根據收集到的用戶訪問數據進行預估
2)根據需求來確定(使用高峰時間段,注冊用戶數,單次響應時間等
你們性能測試在什么環境執行?
參考答案:我們會搭建一套獨立的性能測試環境進行測試
你們性能測試什么時間執行?
基準測試:功能測試之后,系統比較穩定的時候再做。
負載測試:夜深人靜,系統沒人用的時候
怎么分析性能測試結果?
首先查看事物通過率(錯誤率),然后分析其他性能指標,比如,確認響應時間,事務通過率,CPU等指標是否滿足需求;如果測試結果不可信,要分析異常的原因,修改后重新測試(復測)。
現在我也找了很多測試的朋友,做了一個分享技術的交流群,共享了很多我們收集的技術文檔和視頻教程。
如果你不想再體驗自學時找不到資源,沒人解答問題,堅持幾天便放棄的感受
可以加入我們一起交流。而且還有很多在自動化,性能,安全,測試開發等等方面有一定建樹的技術大牛
分享他們的經驗,還會分享很多直播講座和技術沙龍
可以免費學習!劃重點!開源的!!!
qq群號:310357728【暗號:csdn999】

在確定性能測試結果可信后,如果發現以下問題,按下面的思路來定位問題
問題一:響應時間不達標
查看事務所消耗的時間主要在網絡傳輸還是服務器,如果是網絡,就結合Throughput(網絡吞吐量)圖,計算帶寬是否存在瓶頸,如果存在瓶頸,就要考慮增加帶寬,或對數據的傳輸進行壓縮處理;如果不存在瓶頸,那么,可能是網路不穩定導致。如果主要時間是消耗在服務器上,就要分別查看web服務器和數據庫服務器的CPU,內存的使用率是否過高,因為過高的CPU,內存必定會造成響應時間過長,如果是web服務器的問題,就把web服務器對應上對應的用戶操作日志取下來,發給開發定位;如果是數據庫的問題,就把數據庫服務器
對應上對應的日志取下來,發給開發定位。
問題二:服務器CPU指標異常
分析思路:就把web服務器
對應上對應的用戶操作日志取下來,發給開發定位。
問題三:數據庫CPU指標異常
分析思路:把數據庫服務器對應上對應的日志取下來,發給開發定位。
問題四:內存泄漏
分析思路:把內存的heap數據取出來,分析是哪個對象消耗內存最多,然后發給開發定位。
問題五:程序在單用戶場景下運行成功,多用戶運行則失敗,提示連不上服務器。
原因:程序可能是單線程處理機制
如何識別系統瓶頸?
從TPS指標分析
,TPS即系統單位時間內處理事務的數量。觀察當前隨著用戶數的增長期系統每秒可處理的事務數是否也會增長
如何判斷系統的性能是變好了還是變壞了
通過基準測試
對比性能指標
你們的性能測試需求哪里來?
1:客戶提供需求
2:運維提供需求(負責服務器的穩定性)
3:開發提供需求
如何實現200用戶的并發?
在腳本對應的請求后添加集合點(絕對并發)
相對并發:線程組
設置200線程數
什么情況下要做關聯,關聯是怎么做的?
當腳本的上下文有聯系,就用關聯。
比如登錄的token關聯,增刪改查主鍵id關聯
有驗證碼的功能,怎么做性能測試?
1、將驗證碼暫時屏蔽,完成性能測試后,再恢復
2、使用萬能的驗證碼
你們性能測試做的是前臺還是后臺?
BS項目:測試的是后臺服務器的性能和瀏覽器端性能;
APP項目:手機端和服務器端的性能都做
性能測試指標有哪些
響應時間
吞吐量
cpu
內存
io
disk
如何腳本增強?
1、做參數化
2、做關聯
3、添加事務
4、添加斷言
5、添加集合點(jmeter的同步定時器
)
6、添加思考時間(jmeter的統一隨機定時器和固定定時器)
如何找到并發數、平均響應時間
、tps的最佳平衡點?
先回顧下基礎,性能測試
常用的指標有三個:并發、響應時間、tps
并發:跑道里參加賽跑的人數(這里的并發是廣義的并發,即同一個時間段內對系統發起的請求數量)
響應時間:也就是平均每個事務的處理時間
tps:每秒處理的事務數
需求指標
:分為單指標和多指標
單指標
:一般是單測試tps,或者根據并發測試
響應時間,或者根據響應時間測試并發,只考慮單指標的很少
多指標:要同時考慮多個指標,比如tps + 響應時間(<1s)
這個題,意思就是要找到這三個指標同時最佳值的點,即:不能只追求并發數大,而忽略tps,所以,這是一個多指標性能需求,假設是這樣的:要求響應時間
1秒以內,并發數要盡可能的多,tps要盡可能的大。

是不是依舊有點懵逼?先畫一個簡單的示意圖,方便大家理解:隨著并發數增加,響應時間肯定是越來越高,所以,上面紅線是響應時間;
隨著并發數增加,tps是先升高到峰值,然后下降(也可能是一直平穩,或者平穩一段時間再下降),所以,上面藍線是tps;
紫色表示并發用戶數;
最后,給大家一個福利,分享軟件測試學習資料包!包含軟件測試入門-進階-高級課程,項目實訓, 思維導圖
等,可以自行下載!還可加入測試交流群,不定期發布名企內推信息!
該怎么去找這個最佳平衡點呢?
1.盡可能多的做不同并發數下的壓測,記錄下響應時間(1s以內)和最大tps,當然,服務器端,各個服務器的資源利用率在可接受范圍內(每個公司不一樣,我們是90%以內);
2.然后根據獲取到的不同并發下的指標數據(并發數、tps、響應時間),畫出上圖,關注右側的交點,即tps下降的地方和響應時間的交點,這個點的tps最大,如果響應時間在1s以內,此時并發數也是比較大的,這個點就可以認為是三個指標都不錯的平衡點(當然,我這里把tps放在第一位優先考慮了,這個就看大家最在乎哪個指標了,排個優先級);如果響應時間大于1s,最佳平衡點就往左找,找到響應時間為1秒的點,此時對應的tps和并發值
,就是最佳平衡點。總之,測試采樣越多,獲取的平衡點
就越準確。
另外,如果是用loadrunner
作為并發工具,并發過程中是可以增加或者減少并發用戶數的,就不用必須壓完一次,再調整并發數繼續壓,但是,loadrunner并發過程中調整了并發數,還是要盡可能跑久一點,比如10-15min。
最后感謝每一個認真閱讀我文章的人,看著粉絲一路的上漲和關注,禮尚往來總是要有的,雖然不是什么很值錢的東西,如果你用得到的話可以直接拿走!

軟件測試面試文檔
我們學習必然是為了找到高薪的工作,下面這些面試題是來自阿里、騰訊、字節等一線互聯網大廠最新的面試資料,并且有字節大佬給出了權威的解答,刷完這一套面試資料相信大家都能找到滿意的工作。
?

