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

一、think_time的作用是什么？

在業務基準測試中模擬用戶的思考時間，在確定性能測試結果可信后，如果發現以下問題，按下面提供的思路來定位問題。

1、響應時間不達標：查看事務所消耗的時間主要在網絡傳輸還是服務器，如果是網絡，就結合Throughput(網絡吞吐量)圖，計算帶寬是否存在瓶頸，如果存在瓶頸，就要考慮增加帶寬，或對數據的傳輸進行壓縮處理;如果不存在瓶頸，那么，可能是網路不穩定導致。如果主要時間是消耗在服務器上，就要分別查看web服務器和數據庫服務器的CPU，內存的使用率是否過高，因為過高的CPU，內存必定會造成響應時間過長，如果是web服務器的問題，就把web服務器對應上對應的用戶操作日志取下來，發給開發定位;如果是數據庫的問題，就把數據庫服務器對應上對應的日志取下來，發給開發定位。

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

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

三、性能測試的應用領域有哪些？

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

四、jmeter如何設計性能測試場景？

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

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

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

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

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

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

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

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

以上我們分享了軟件性能測試經常遇到的問題，希望本文能夠給您啟發，助您解決問題。如果您想了解更多相關信息，請您繼續關注中培偉業。