child_process();
}
if ( pid ) //父進程代碼
{
…
}
通過上面的代碼，我們對客戶端的產生有了清楚的認識，在進程創建后，父、子進程分道揚鑣，開始各自的壓力測試之旅。
2．系統真實數據的獲取和傳遞
上面我們討論了真實數據對壓力測試結果可信程度的重要意義，現在的問題是如何設計一個獲取數據庫中數據并傳遞給調用服務的客戶端的數據流程。這個前提是我們要對被測的服務比較熟悉，了解它的大致處理流程和涉及的數據。
以帳單的銷帳為例，它需要銷帳方式、操作員工號、涉及的每條帳單的部分信息，這些信息可以由用戶的輸入和帳單查詢服務來得到。用戶的輸入我們可以在測試程序中設定，帳單的信息我們可以在之前調用查詢服務來獲取，因為銷帳總是在帳單查詢之后進行的，所以這個流程也是符合實際情況的。接下來的問題是帳單的查詢也是需要有效的輸入參數的，我們如何獲取這些數據呢？答案自然還是從數據庫中來。在真實系統中，帳單查詢是前臺接收到用戶請求，根據用戶的電話號碼等來查詢，在這里我們可以一次從數據庫中取出一批有帳單的用戶的信息（電話號碼等）來作為查詢的輸入條件。因為這個取編號的操作不是真實系統應有的開銷，所以我們可以在模擬客戶端開始運行之前完成。
至此，我們對數據的流程有了一個大概的認識。下面就是具體實現的問題了。編號是一次性取出的，而且根據測試需要其數量是可以預先知道的，我們可以將其保存在一個大的數組中，后面我們可以看到用這種數據結構的好處。
獲得了最基本的輸入，我們就可以開始壓力測試程序內部的數據流的設計了。
3．父、子進程的工作及數據通信方式
為保證并發，每個client進程都應該是獨立的，而且自身運行必須維持一段時間，這樣才能在TUXEDO服務器一端產生大量穩定的連接，進而產生調用，形成壓力。每個client進程的工作是得到一個編號，調用帳單查詢的服務獲取對應用戶的帳單，然后整理返回結果，加入操作員信息，再調用銷帳服務，獲得返回結果。每個client重復上面的過程，重復的次數作為一個參數n，這個是可以配置的，P_NUM * n 就是需要準備的編號的數量，這兩個參數需要結合測試的要求來選擇，通過改變他們可以進行多次不同的測試。
父進程的工作是獲取編號到數組中，然后產生P_NUM個模擬的客戶端，接下來它要給這些client分發數據，使得每個client可以持續運行。上面提到的編號數組相當于一個糧食倉庫，父進程要給子進程穩定的糧食供應，使其不致于因為“饑餓”而導致停頓。分析這里的數據，還有一個特點就是每個數據都是一次性的，不能再次使用。父進程通過數組的下標可以很容易的保證數據的不重復，這也體現了數組在這種情況下的簡潔高效。在父進程輸送數據給子進程的過程中，我們考慮后采用了隊列來實現，因為要保證每個子進程獲得的數據都是唯一的，而且每個子進程最好能從一個已知的地點獲取數據，這樣便于子進程數目的伸縮，而隊列恰好能滿足這些要求。由于隊列的訪問是有控制的，大量的子進程去取可能會造成等待，但是實際測試中我們發現這種影響是很小的，在客戶端數目為1000左右時仍不明顯，因而我們可以認為隊列是高效的。當然這里的問題也可能有更好的解決的辦法，隊列相對而言比較簡單和清晰。
壓力測試程序必須返回相應的結果，例如每個調用所耗的時間等等，這里不詳細說明，可以根據實際的需要安排相關的代碼來實現。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
