由于Fitnesse上所有case的執(zhí)行都是向SlimServer發(fā)送Http請求，那么我們可以針對相關Case實現(xiàn)性能測試，這樣的好處有以下三點：

1. 用于在Fitnesse上已經(jīng)構建了相關的測試場景或者業(yè)務邏輯，我們只需要利用性能測試工具去調用這些Case便可以實現(xiàn)壓力測試。

2.在準備壓力測試數(shù)據(jù)的時候，由于有些數(shù)據(jù)需要多個接口組合調用才能完成，比如下面的測試場景有兩個webservice接口，CreateMember和CreateOperator

每個Member下面有多個Operator，我們要先構建Member才能創(chuàng)建Operator，如果直接使用Jmeter的話要首先創(chuàng)建Member接口創(chuàng)建member，然后在調用CreateOperator

接口創(chuàng)建operator，其中member中的memberId還要和OperatorId做關聯(lián)，無疑要相對麻煩一些。因為我們先前已經(jīng)利用Fitnesse對CreateOperator做過功能測試，在Fitnesse

的Case中已經(jīng)完美的實現(xiàn)創(chuàng)建Operator這個場景，并且做到數(shù)據(jù)的關聯(lián)，因此我們只需要直接利用這個Case做壓力測試數(shù)據(jù)準備工作。

3.可以利用功能測試的Case實現(xiàn)壓力測試，使功能測試和壓力測試串聯(lián)起來，可以互相協(xié)助并發(fā)現(xiàn)一些功能和性能上的問題。

下圖給出一個Fitnesse接口Jmeter做壓力測試的例子：

其中紅色方框中的路徑，便是Fitnesse上面case的路徑，記得一點要加上?test，這樣便告訴Jmeter這是一個執(zhí)行Case的get 請求。

當然利用Fitnesse做接口壓力測試，也要注意，由于在Fitnesse上面書寫的Case可能沒有考慮接口的Response Time， 比如在兩個接口的組合調用中有Thread.Sleep(time)等，所以在壓力測試中對接口的Response time的檢查一定要去除這些等待時間或者其他對壓力測試結果有影響的時間因素，這個需要在功能測試中對每個接口調用時要清晰的在日志中記錄一些影響因素，便于壓力測試時的分析。