對 Web Flow 應用程式進行負載測試與其他 Web 應用程式的負載測試類似——我們將使用負載測試工具來模擬不斷增加的併發客戶端訪問級別，以捕獲關鍵的效能統計資料。

在使用 Web Flow 時，負載測試有幾個重要的考慮因素：

1. 負載測試必須維護獨立的“Cookie 儲存區域”，以便每個客戶端請求都可以攜帶獨立的 HTTP 會話。
2. 我們需要一種機制來從初始響應中提取唯一的 Flow Execution Key，並將其用於自定義同一 Flow 會話中的後續請求。

Apache JMeter 是一個開源的效能測試工具，可以滿足以上兩個考慮因素。

對於 1)，我們在每個測試組的根目錄下新增一個 HTTP Cookie 管理器（HTTP Cookie Manager）來執行 Web Flow 功能。Cookie 管理器確保每個模擬客戶端請求都有自己獨立的 Cookie，與其他客戶端請求無關，從而允許 Servlet 容器透過 jsessionid Cookie 來跟蹤獨立的 HTTP 會話。

對於 2)，我們在啟動流程的 HTTP 請求元素（HTTP Request Element）之後立即新增一個正則表示式提取器（Regular Expression Extractor）。該提取器的目的是解析 HTTP 響應，使用我們提供的正則表示式定位特定的文字，並將其作為變數提供給後續的 HTTP 請求元素使用。下面是正則表示式提取器的一個配置示例：

引用名稱（Reference Name）：flowExecutionKey 正則表示式（Regular Expression）：name="_flowExecutionKey" value="(.*)" 模板（Template）：$1$ 匹配編號（Match No.）：0

使用上述配置後，我們就可以在後續屬於同一流程會話的 HTTP 請求元素中嵌入變數 ${flowExecutionKey} 了。

現在，我們用它來對 Web Flow 進行負載測試。為了正確地執行具有代表性的 Web Flow 功能，我建立了一個示例 Web Flow 應用程式，模擬了一個包含 6 個步驟的購物車流程，收集使用者的送貨地址、配送選項、信用卡資訊、賬單地址、訂單確認資訊，以及最後的訂單摘要。該流程中的各個步驟包括資料繫結和驗證、檢視狀態（view states）、動作狀態（action states）、決策狀態（decision states）以及子流程狀態（sub-flow states）——這些都是我們在典型的 Web Flow 應用程式中會期望找到的東西。然而，該應用程式使用了存根（stubs）而不是實際的資料庫訪問程式碼，以避免在整體統計資料中包含這些數字。在此測試中，我們希望只關注 Web Flow 本身。

構建應用程式並建立 JMeter 指令碼後，我添加了一個聚合報告（Aggregate Report）元素，用於記錄不同負載水平下測試的效能統計資料。

在我的執行 Ubuntu 的聯想 T60 雙核筆記型電腦上，使用 Apache Tomcat 5.5 作為 Servlet 容器，並配置為最多支援 150 個併發連線，我觀察到了以下結果：

實際的負載測試應該在真實的硬體上，並且基於真實的用例進行。沒有其他方法可以替代。然而，我們可以從上述數字中得出一些結論。

上述數字表明，在執行核心 Web Flow 功能時，即使併發使用者數顯著增加，吞吐量仍然保持穩定。90% 使用者的響應時間保持在一秒以內。最差的響應時間會隨著負載的增加而上升，但考慮到用於測試的硬體不足，這並不令人意外。

使用上述技術，您可以對自己的 Web Flow 應用程式進行負載測試。

swf-shoppingcart-regexp.txt