我目前正在編寫一個JMeter插件來測試修復程序，這個錯誤似乎只發生在我們的Web應用程序處於高負載狀態時。使用簡單的Web服務的Web應用程序壓力/負載測試
作爲一般的解決辦法，允許負載/壓力測試寫入測試Web應用程序，我想添加一個簡單的RESTful Web服務調用的測試的特定部分。這樣做的主要原因是繞過瀏覽器，因爲我們感興趣的是測試這是業務邏輯和數據庫訪問層（傳統內聯SQL）。
這將是值得花時間和精力還是可以使用JMeter的測試要求身份驗證和使用JavaScript和Ajax大量複雜的Web應用程序。
編輯
這些試驗的目的是測試業務邏輯和數據訪問層是如何處理高負載的情況下，以確保沒有錯誤或併發問題。這是一個傳統的jsp web應用程序（即在90年代中期編寫的），主要是內嵌的sql，它正在轉移到DAL層。
您從露出一種特殊的API得到一些好處只是負載測試：
現在剩下的就是估計創建這樣的API需要多少工作，以及這些好處是否值得。
與直行到業務邏輯的問題在於，你永遠不能肯定你沒有在是把你的服務器上的額外負載的表示層的問題。並且自行測試業務邏輯可能意味着錯失了可能的性能問題（例如，如果很多HTTP會話中有很多對象，那麼您的服務器可能會將大部分時間花費在垃圾回收器中，因爲堆太小），所以我建議創建一個複雜的測試計劃，其中包含所有對服務器的調用。
實現這一目標最簡單的方法是使用JMeter的HTTP代理服務器，啓動瀏覽器，並讓HTTP代理記錄您的測試計劃。
查看如何開始使用代理開始Basic JMeter Proxy Step By Step。
這將記錄從瀏覽器到服務器的所有調用（您對JavaScript本身不感興趣，因爲這發生在瀏覽器上，所以不會影響服務器負載，儘管AJAX調用會） 。
由HTTP代理創建的測試計劃將對所有值進行硬編碼，因此您可能必須通過它來確定每次調用哪些值不同（例如，如果您有創建選項返回新ID ，後續請求需要使用服務器返回的ID
要獲取這些值，您可以將Regular Expression Extractors添加到您的請求中，並分配一個變量名稱，然後在隨後的請求中將其重新用作請求參數。請求參數並識別需要由其中需要從先前頁解析可以有點乏味值取代，但並不難。
例如，如果你是網頁包含在返回HTML
<input type="hidden" name="recordId" value="abcqwer123" />
這就需要在接下來的請求中使用，你可以使用下面的正則表達式來提取它的recordId：
name="recordId"\s+value="([a-z0-9]+)"
另一個要記住的一件事是確保您使用廣泛的測試數據（例如，如果模擬大量用戶登錄，則需要確保不是每個測試都使用相同的userId運行，因爲緩存可能意味着諸如數據庫查找之類的繁重操作只能在第一次運行時完成。爲了簡化使用多個帳戶，您可以使用CSV Data Set Config將值列表加載到一個隨每次迭代而變化的變量中。
我最後的建議是看看運行JMeter在Distributed Mode。這是您在許多遠程客戶端上啓動Jmeter-server的地方，然後它們都會執行相同的測試。這確保了測試客戶端自己通過沒有足夠的CPU核心或網絡帶寬來創建大量的同時請求而造成瓶頸。
謝謝，但我並不真正對性能測試感興趣，而是在系統負載下測試DAL中發生的併發性和錯誤。但是如果我們需要優化性能，這將值得考慮，我們也可能會這樣做。 – eaglestorm
您可以使用JUnit Sampler並重新使用數據訪問和業務層的現有測試，而不是編寫REST服務並通過JMeter調用它。
爲什麼我不喜歡創建一個特殊的API來測試是因爲需要確保在創建發佈版本時在構建過程中刪除了特殊的API，或者爲了不創建後門。但是，如果安全起見，這可能是一個附加功能，使與第三方系統的集成更容易。 – beny23
是啊，好處就是這些就是爲什麼我正在考慮它，並希望我可以保持它到一個簡單的配置標誌和servlet，所以它沒有太多的工作。 – eaglestorm
@ beny23唯一的安全風險是來自DOS攻擊，它不會暴露任何數據，如果您想確保它不會進入發佈版本，您也可以使用靜態常量作爲c風格預處理器標誌。 – eaglestorm