在軟件性能測試中有很多問題時常發(fā)生，面對問題如何才能快速解決這就要考驗(yàn)軟件測試人員的知識儲備量了。今天我們聊聊軟件性能測試常見問題，比如說think_time的作用是什么？常見的施壓模型有哪幾種？性能測試的應(yīng)用領(lǐng)域有哪些？這些問題在軟件測試中經(jīng)常會出現(xiàn)，您是否可以從容解決呢？下面我們就來具體看看這些問題的答案，按照下面提供的思路來定位和解決問題應(yīng)該會對您有一定的幫助。

一、think_time的作用是什么？

在業(yè)務(wù)基準(zhǔn)測試中模擬用戶的思考時間，在確定性能測試結(jié)果可信后，如果發(fā)現(xiàn)以下問題，按下面提供的思路來定位問題。

1、響應(yīng)時間不達(dá)標(biāo)：查看事務(wù)所消耗的時間主要在網(wǎng)絡(luò)傳輸還是服務(wù)器，如果是網(wǎng)絡(luò)，就結(jié)合Throughput(網(wǎng)絡(luò)吞吐量)圖，計算帶寬是否存在瓶頸，如果存在瓶頸，就要考慮增加帶寬，或?qū)?shù)據(jù)的傳輸進(jìn)行壓縮處理;如果不存在瓶頸，那么，可能是網(wǎng)路不穩(wěn)定導(dǎo)致。如果主要時間是消耗在服務(wù)器上，就要分別查看web服務(wù)器和數(shù)據(jù)庫服務(wù)器的CPU，內(nèi)存的使用率是否過高，因?yàn)檫^高的CPU，內(nèi)存必定會造成響應(yīng)時間過長，如果是web服務(wù)器的問題，就把web服務(wù)器對應(yīng)上對應(yīng)的用戶操作日志取下來，發(fā)給開發(fā)定位;如果是數(shù)據(jù)庫的問題，就把數(shù)據(jù)庫服務(wù)器對應(yīng)上對應(yīng)的日志取下來，發(fā)給開發(fā)定位。

二、常見的施壓模型有哪幾種？

1、并發(fā)模式(虛擬用戶模式) 并發(fā)是指虛擬并發(fā)用戶數(shù)，從業(yè)務(wù)角度，也可以理解為同時在線的用戶數(shù)。從客戶端的角度出發(fā)，摸底業(yè)務(wù)系統(tǒng)各節(jié)點(diǎn)能同時承載的在線用戶數(shù)，可以使用該模式設(shè)置目標(biāo)并發(fā)，也就是jmeter工具里面的線程數(shù) 2、RPS 模式(吞吐量模式) RPS(Requests Per Second)是指每秒請求數(shù)。RPS 模式即“吞吐量模式”，通過設(shè)置每秒發(fā)出的請求數(shù)，從服務(wù)端的角度出發(fā)，直接衡量系統(tǒng)的吞吐能力。

三、性能測試的應(yīng)用領(lǐng)域有哪些？

能力驗(yàn)證：通過實(shí)際的測試結(jié)果證明自己系統(tǒng)的預(yù)期能力 瓶頸分析：通過一系列的測試手段發(fā)現(xiàn)系統(tǒng)的性能瓶頸(并發(fā)，負(fù)載，壓力，失效恢復(fù))性能調(diào)優(yōu)：通過一系列的技術(shù)手段優(yōu)化系統(tǒng)性能，包括響應(yīng)時間，吞吐量，資源利用率 容量規(guī)劃：為了符合未來的規(guī)劃預(yù)期(用戶數(shù)，市場占有率)，對資源做相應(yīng)的調(diào)整。

四、jmeter如何設(shè)計性能測試場景？

并發(fā)測試：基礎(chǔ)線程組(強(qiáng)調(diào)單位時間的并發(fā)，不存在絕對并發(fā))基準(zhǔn)測試：反復(fù)對比結(jié)果，驗(yàn)證調(diào)優(yōu)結(jié)果是否通過(tps是否提升，響應(yīng)時間是否下降)負(fù)載測試：持續(xù)不斷地增加負(fù)載，發(fā)現(xiàn)性能瓶頸(階梯加壓線程組，Concurrency Thread Group) 并發(fā)用戶模式的負(fù)載：不斷增加并發(fā)用戶數(shù)，發(fā)現(xiàn)瓶頸吞吐量模式的負(fù)載：不斷增加每秒請求數(shù)(rps)對服務(wù)端施壓，發(fā)現(xiàn)tps瓶頸壓力測試：tps瓶頸點(diǎn)上持續(xù)負(fù)載 穩(wěn)定性壓力測試：tps保持高壓穩(wěn)定。一般取最大tps的80%持續(xù)運(yùn)行破壞性壓力測試：目的是只需要服務(wù)端出現(xiàn)異常 失效恢復(fù)測試：出現(xiàn)異常之后，系統(tǒng)可以很快的恢復(fù) 容量規(guī)劃測試：50萬，高峰時間段2小時。

五、tps無法上升原因有哪些？

1、網(wǎng)絡(luò)帶寬 在壓力測試中，有時候要模擬大量的用戶請求，如果單位時間內(nèi)傳遞的數(shù)據(jù)包過大，超過了帶寬的傳輸能力，就會造成網(wǎng)絡(luò)資源競爭，導(dǎo)致服務(wù)端接收到的請求數(shù)達(dá)不到服務(wù)端的處理能力上限。

2、連接池 可用連接數(shù)太少，造成請求等待。連接池一般分為服務(wù)器連接池(比如Tomcat)和數(shù)據(jù)庫連接池(或者理解為最大允許連接數(shù)也行)。

3、GC 如果堆內(nèi)存分配的不合理，就會導(dǎo)致頻繁的gc，gc會導(dǎo)致線程暫停。尤其是fullgc，會造成線程長時間暫停

4、數(shù)據(jù)庫配置 高并發(fā)情況下，如果請求數(shù)據(jù)需要寫入數(shù)據(jù)庫且需要寫入多個表的時候，數(shù)據(jù)庫的最大連接數(shù)不夠，或者寫入數(shù)據(jù)的SQL沒有索引，或沒有主從分離、讀寫分離，就會導(dǎo)致數(shù)據(jù)庫事務(wù)處理過慢，影響到TPS。

5、硬件資源 包括CPU(配置、使用率等)、內(nèi)存(占用率等)、磁盤(I/O、頁交換等)

6、壓力機(jī) 單機(jī)負(fù)載能力有限，如果需要模擬的用戶請求數(shù)超過其負(fù)載極限，會影響TPS(這個時候就需要進(jìn)行分布式壓測來解決問題)

以上我們分享了軟件性能測試經(jīng)常遇到的問題，希望本文能夠給您啟發(fā)，助您解決問題。如果您想了解更多相關(guān)信息，請您繼續(xù)關(guān)注中培偉業(yè)。