一、性能測試工具的特徵
調度能力
因為性能測試不可能由一台壓力機完成或者說大部分情況下，我們不能不可能由一台壓力機來完成，凡是對壓力真正有所要求的場景，往往是多台壓力機共同施加壓力完成性能測試；因此，性能測試工具必須有很好的調度能力， 能夠由一個主控機同時管理多台代理機完成性能測試任務 ，而不是由人去一台一台的代理機上操作來完成這個任務。
線性擴展能力
調度能力有好有壞，有些性能測試工具調度能力特別強，具備很好的線性擴展能力， 當壓力不夠的時候能夠通過增加壓力機數量的方式來線性的增加吞吐量、並發量，從而實現目標 。
穩定的並發能力
為什麼是穩定的並發能力非常重要呢？
我們在實際性能測試當中往往並不是按照教科書上面寫到的「單交易基準測試 -> 單交易負載 -> 混合交易基準 -> 混合交易負載 -> 穩定性測試 」 這個套路來進行的，實際測試當中往往需要進行對比測試。比如說我應用程式換版前後對比，或者更換作業系統版本前後對比，或者一個資料庫參數調節前調節後有一個對比。
對比測試當中的一個最重要的原則就是一次只調一個參數來對比前後的情況， 如果我要調兩個或者多個參數的話，如果發現前後性能差距很大，我很難判斷是哪個參數導致的影響。因此，性能測試每次儘量只調一個參數，這個參數是什麼呢？
這個參數就是應用程式的版本、作業系統的版本、資料庫參數等等。並且前後對比的時候，要儘量保持其他要素不變。然而，其他性能指標不變是不可能的，那麼就要控制住可控參數，觀察不可控參數的變化。
業務吞吐量跟 CPU 利用率是最重要的參數之二，他們之間又有著直接的關係，對於大部分的交易系統來說，我的吞吐量上去的話， CPU 利用率也會隨之上升，而 CPU 升高的話，吞吐量一般也會比較高。
我們的策略是對比兩個場景在 CPU 利用率相同的情況下吞吐量的差異呢？還是對比吞吐量相同的情況下 CPU 利用率的差異呢？
這種情況下，我們的策略必須是對比吞吐量相同的情況下 CPU 利用率的差異，因為吞吐量我們是可以控制的，而 CPU 我們是不能控制的 。使用工具發出來 100TPS 就是 100TPS ， 200TPS 就是 200TPS 。而 CPU 是作業系統和 CPU 共同控制的，它不在我們的控制能力範圍。
通過上面分析我們看出，對比測試的原則下面「穩定」控制吞吐量是非常非常重要的。
因此，性能測試工具，必須能夠「穩定」地控制吞吐量。 那麼什麼程度算是穩定？ 從實際測試的經驗來說，如果我的目標是每秒發送 100 筆業務，那麼 98-102 這個範圍之內是可以接受的，而實際上，大多數測試我們可以控制到 99-101 之間， 也就是說誤差範圍在 1% 以內。如果超過 2% ，甚至超過 5% 的性能測試工具，我建議就要著手分析是不是工具的問題，或者分析你測試環境的問題（比如 CPU 利用率太高導致的波動）。
單機高吞吐能力
相同資源的 PC 機如果能發更多的業務壓力，就能節省不少的環境資源，並且，壓力機數量的減少，直接影響是維護這些工具的工作量減少了，整體測試效率提高了。
二次開發的能力
測試工具考慮另一個因素是二次開發的能力。我們經常會從 web 頁面進行性能測試，因為 1 ）這個是最完整的業務流， 2 ）也是最容易實施的性能測試。然而大部分時候性能瓶頸或者說性能測試的核心不在那個頁面上，而在後台系統伺服器上面。高級的測試人員不想搭建前端的測試環境，第一，沒有必要測，第二沒有時間搭建，第三，沒有資源分配。高級測試人員希望把更多的資源儘量分配到核心伺服器上，並且直接對核心伺服器進行壓測。比如說我直接發文大批量的 SQL 查詢語句到後台核心資料庫伺服器，或者批量的報文到後台伺服器的 API 接口。
二、 典型性能測試工具的對比和選擇思路
市面上有一些流行或者不流行的性能測工具，我這裡做一個簡單介紹，這裡舉三個例子： IBM 的 RPT ， HP 的 Loadrunner ，開源的 JMeter 。
RPT
這裡為什麼舉 IBM RPT 的例子呢，因為即使是專門做性能測試的人， 也很少聽說過 RPT 這個工具，在這裡是把它當成一個反面例子來介紹的 。
第一，有 license 的嚴格限制，而且這個 license 是沒辦法破解的，你需要把你測試的主控機的磁碟信息發送給 IBM ， IBM 根據這個信息返回給你一個 license 序列號，它和你的主控機綁死了，所以你是沒辦法破解的。
倒不是說建議大家去用什麼破解版，而是說，有嚴格 license 限制的軟體很難發展好。因為用戶群體少，問題反饋少，社區不活躍，逐漸地惡性循環，這個軟體就被淘汰了。
第二，最重要的一點， RPT 沒有很好的線性擴展能力和調度能力。一台代理機能發出去每秒 200 筆業務，而兩台三台四台代理機還是只能發出每秒 200 多筆業務，這個就是沒有很好的線性擴展能力。
為什麼會出現這種情況呢？因為所有待發送的數據它並不是放在各個代理機上的，而是放在主控機上，由主控機分發到各個代理去發送，這造成了很多不必要的網絡消耗，並且主控機成了唯一的瓶頸。比如說我有 10 個代理機組成集群，他們發送的業務是有業務序號的，序號在集群內不能重複。 RPT 的做法就是生成序列號的工作僅由主控機來干。也就是說數據沒有像大數據的方式分散在各個代理機上而是集權式的管理。
Loadrunner
Loadrunner 是目前商業軟體當中最為流行的。為什麼會流行呢，首先它的 license 是可以破解的，這就導致用戶數量龐大，用戶也喜歡用，並且用它發送很高的壓力（而 IBM RPT 的 license 和並發數是相關的，花錢少是沒法設置高並發的）。這個原因非常重要，導致了用戶和軟體之間的正反饋，促使 Loadrunner 不斷地改進，最後成為一個流行的工具，反觀 RPT 有嚴格的 license 限制，用戶特別少，也沒什麼反饋，最後惡性循環後在市場上消失了。
JMeter
JMeter 作為開源領域最火爆的一款性能測試工具，在網際網路公司裡面用的比較廣，現在在金融這種領域的公司也用的比較廣。但是吞吐量控制的不是很穩定。
我這裡舉一個如何做後台性能測試的例子。我要給一個資料庫伺服器施加查詢壓力，向這台資料庫發送一萬次某個查詢語句。正常的做法是什麼呢？寫三個函數：
第一個函數 init ：創建資料庫的連接，並準備一個 SQL 語句。
第二函數 action ：負責給 SQL 語句填入參數，真正的去做查詢的動作，反覆地去做 1 萬遍。
第三函數 end ：做一些清理工作，斷開與資料庫的連接。
這三個函數中，第一個函數跟第三個函數都是只做一遍，中間的 action 函數是疊代了一萬遍。
事實上像 Loadrunner 和 JMeter 這樣的性能工具也的確是這麼實現的，而遺憾的是 RPT 就不是這麼實現的。 RPT 怎麼實現呢？我的 init 函數、 action 函數、 end 函數對於每一次交易都要執行一遍，如果執行 1 萬次查詢，這三個函數一共執行了 3 萬次，大大降低了單機執行效率。也就是說， RPT 除了線性擴展能力特別差，即使是在單機上面的性能也是非常差。相同資源的 PC 機資源（比如說 4C4G 的 PC ）一秒鐘能發 200 筆業務，而 RPT 就只能發 100 筆業務，非常浪費性能測試環境的資源，並且，不僅僅是浪費資源的問題，而且你的測試代理機一旦多起來維護管理工作將成倍增長。
結論
在選擇性能測試工具的時候一定要選擇流行的性能測試工具（ license 限制不嚴格的工具）。如果你的測試領域比較特殊，流行的測試工具不能滿足你的需求，而要選擇一個細分領域的、比較專業的性能測試工具或者要自己開發一個性能測試工具的話，文中前面介紹到的調度能力、線性擴展能力、穩定的並發能力、二次開發能力、單機高吞吐能力就是考察的重點。