基於目標TPS的效能測試，如何通過手動設定場景進行測試？

一．效能測試中的TPS

眾所周知，TPS（即Transactions Per Second的縮寫）是效能測試中的一項重要指標，用於衡量被測系統的效能，TPS高則說明系統處理速度快，TPS低則說明系統處理速度慢，可能需要做效能優化。通常TPS只是反應測試結果，測試出多少就是多少，然而很多時候我們需要事先指定TPS的目標值，通過測試來驗證目標值是否達，那麼該如何進行測試呢? 加我VX：atstudy-js 回覆“測試”，進入 自動化測試學習交流群~~

二．基於目標的效能測試

Loadrunner在新建測試場景時，就可以選擇手動場景還是基於目標的場景，如下圖所示：

目標型別可以選擇tps、hits per second等：

設定好目標後，直接執行就可以了，執行完成可以看到目標是否達到了。這個過程都是自動完成的，其內部是如何實現的，對於我們來說完全是個黑盒子。本文介紹的是如何通過手動設定場景來完成基於TPS目標的測試，重點介紹目標TPS是如何計算出來的。

三．測試場景的設定

我們還是選擇手動設定loadrunner的測試場景，通常會有單交易場景測試和混合交易場景測試，下面是2個示例：

無論是單場景還是混合場景，目標TPS的計算原理都是一樣的。

四．場景公式

在上面的場景例子中，我們需要重點關注4個欄位：

·虛擬使用者數量(簡稱vu)

·目標tps

·Pacing

·Thinktime

所有場景的 thinktime 都是 0 秒，pacing 和 thinktime 在概念上有聯絡也有區別。

Thinktime 比較常用，易理解，這裡不多介紹，下面重點說一下 pacing。Pacing 是 loadrunner

中的一個設定選項，如下圖所示：

Pacing 指 action 迭代的延遲時間，選項一是迭代不延遲，選項二是在上一次迭代結束後多長時間開始下一次迭代，選項三是每次迭代從開始到結束的時間間隔。

選項三實際上是設定每次迭代的期望完成時間，例如設定pacing為60秒，表示action這個事務要求在60秒內執行完成，如果action執行了4秒，那麼後面的56秒會等待，直到60秒後再開始下一次迭代；如果action執行了120秒，那麼執行結束後會立即開始下一次迭代。前者我們可以稱之為“包含住”，因為執行時間小於pacing時間，後者稱為“未包含住”，因為執行時間大於pacing時間。只要action的平均響應時間“包含住”了，目標TPS就可以達到。

理解上面的原理很重要，下面我們看一個例子。

假設有如下的測試結果：

vu為1時action的響應時間只要小於等於2秒pacing，理論tps應該都是0.5，換句話說只要action響應時間在pacing內，響應時間再快，tps不會增加。

vu為 10 時，action的響應時間仍小於2秒，在pacing範圍內，“包含住”了，達到5個TPS。同理，vu為20時，action的響應時間仍小於2秒，在pacing範圍內，“包含住”了，達到10 個TPS。在action的響應時間未超出pacing之前，tps和vu存在正比關係。

vu為100時，action響應時間為10秒，不在pacing2秒範圍內，“未包含住”，理論的50個tps就不可能達到了。

通過以上分析，我們可以得出vu、pacing、目標tps三者之間的關係，即：

在action的響應時間未超出pacing之前，目標tps=vu/pacing通過該公式，可以較精確的測試出系統的tps，通過大量的測試試驗，結果也是和公式吻合的。

目標tps根據需求得到，設定一個pacing就知道需要測試多少vu。減少pacing和增加vu都可以增加目標tps。建議的做法是先設定pacing，然後再設定vu，pacing的取值基本都是10秒，或者是10秒的倍數。pacing確定後就不再改變，要想增加目標tps，只能調大vu。

五．總結

本文介紹了基於目標tps的效能測試方法，希望通過本文，能讓大家對tps的設定有更深入的瞭解，在做效能測試時做到目標清晰，有章可循。

最後：

可以我的個人V：atstudy-js，可以免費領取一份10G軟體測試工程師面試寶典文件資料。以及相對應的視訊學習教程免費分享！，其中包括了有基礎知識、Linux必備、Mysql資料庫、抓包工具、介面測試工具、測試進階-Python程式設計、Web自動化測試、APP自動化測試、介面自動化測試、測試高階持續整合、測試架構開發測試框架、效能測試等。

這些測試資料，對於做【軟體測試】的朋友來說應該是最全面最完整的備戰倉庫，這個倉庫也陪伴我走過了最艱難的路程，希望也能幫助到你！