【正文】 一個隨機數(shù)，C_W_ID 是當前可用的倉庫中的一個，并且滿足 C_W_ID 不等于 W_ID。對于以上百分比的實現(xiàn)可以采用 1 到 100 的隨機數(shù) Y，當 Y=60 時，顧客的 last name 是用 NURand（255，0，999）生成的，而當 Y60 時，C_ID 是用NURand（1023 ，1，3000）生成的。Payment 的 H_AMOUNT 是 到 的一個隨機數(shù)。H_DATE 是當前的系統(tǒng)時間。二、事務(wù)實現(xiàn)具體步驟： 從 WAREHOUSE 表中選出與輸入的 W_ID 相符的項，并返回W_NAME, W_STREET_1, W_STREET_2, W_CITY, W_STATE,和 W_ZIP，并且 W_YTD+=H_AMOUNT。 從 DISTRICT 表中選擇出 D_W_ID=W_ID,D_ID 與隨機生成 D_ID 的相等的項，并返回 D_NAME, D_STREET_1, D_STREET_2, D_CITY, D_STATE,和 D_ZIP，且 D_YTD+=H_AMOUNT. 情況一：當顧客的查詢是按 C_ID 是，從 CUSTOMER 表中找到與C_W_ID,C_D_ID,C_ID 相符的項，返回 C_FIRST, C_MIDDLE, C_LAST, C_STREET_1, C_STREET_2, C_CITY, C_STATE, C_ZIP, C_PHONE, C_SINCE, C_CREDIT, C_CREDIT_LIM, C_DISCOUNT, and C_BALANCE，且C_BALANCE+=H_AMOUNT,C_YTD_PAYMENT+=H_AMOUNT, C_PAYMENT_CNT+=1。 情況二：當顧客的查詢是按 C_LAST 時，從 CUSTOMER 查詢出符合C_W_ID,C_D_ID,C_LAST 的項，并從 N/2 以上的項中返回 C_ID, C_FIRST, C_MIDDLE, C_STREET_1, C_STREET_2, C_CITY, C_STATE, C_ZIP, C_PHONE, C_SINCE, C_CREDIT, C_CREDIT_LIM, C_DISCOUNT, and C_BALANCE，且C_BALANCE+=H_AMOUNT,C_YTD_PAYMENT+=H+AMOUNT, C_PAYMENT+=1. 如果 C_CREDIT=”BC”，那么 C_DATA 也得從 CUSTOMER 表中返回，且 C_ID, C_D_ID, C_W_ID, D_ID, W_ID 和 H_AMOUNT 等歷史信息要插入到C_DATA 域中，并且只是將這些內(nèi)容插入到 C_DATA 原有內(nèi)容的左邊，而C_DATA 的原有內(nèi)容右移，超過 500 的字符被移出到 C_DATA 域外。 H_DATA 是 W_NAME 和 D_NAME 的拼接。 往 HISTORY 表中插入新項 H_C_ID = C_ID, H_C_D_ID = C_D_ID, H_C_W_ID = C_W_ID, H_D_ID = D_ID, and H_W_ID = W_ID. DELIVERY（發(fā)貨）事務(wù)的實現(xiàn)該事務(wù)模擬的是對于任意一個客戶，隨機選取一個發(fā)貨包，更新被處理的用戶的賬戶余額，并把該訂單從新訂單中刪除。這個事務(wù)的執(zhí)行頻率不高，對事物的響應時間也沒有嚴格的限制。一、數(shù)據(jù)輸入要求W_ID 是用戶輸入，其值只能為 1 或 2O_CARRIER_ID 是 1 到 10 的一個隨機數(shù)OL_DELIVERY_D 是當前系統(tǒng)的時間二、事務(wù)執(zhí)行具體步驟： 在 NEW_ORDER 表里找到 NO_W_ID= W_ID 并且 NO_D_ID=D_ID的最小的 NO_O_ID，這代表的是未發(fā)貨的最老的歷史記錄（默認 NO_OID 最小的項） ，接著將 NEW_ORDER 表里對應的這一行刪除。在 ORDER_T 表里找到匹配的 O_W_ID=W_ID, O_D_ID=D_ID, O_ID=NO_O_ID 的行，返回 O_C_ID，并將對應的顧客號的 O_CARRIER_ID進行更新。在 ORDER_LINE 里找到所有 OL_W_ID=W_ID, OL_D_ID=D_ID, OL_O_ID=C_OD ，并將 OL_DELIVERY_D 改為當前的系統(tǒng)時間，并將OL_AMOUNT 數(shù)更新。CUSTOMER 表里找到符合 C_W_ID=W_ID, C_D_ID=D_ID, C_ID=O_C_ID 的行并將 C_BALANCE 增加 ORDER_LINE 里的 OL_AMOUNT數(shù) STOCK LEVEL（庫存狀況查詢）事務(wù)實現(xiàn)該事務(wù)模擬的是用戶從固定的倉庫和地區(qū)中選取最后 20 條記錄，檢查訂單中所有貨物的庫存，計算并且把所有庫存數(shù)低于用戶指定域的商品數(shù)量。這個事務(wù)是只讀事務(wù)，執(zhí)行的頻率較低，對系統(tǒng)的響應時間不做嚴格限制和要求。一、 數(shù)據(jù)輸入要求地區(qū)編號 D_ID 和用戶查詢的商品域值下限 THRESHOLD。二、 事務(wù)具體實現(xiàn)步驟：在 DISTRICT 表中選擇與(D_W_ID，D_ID)相匹配的行，得到 D_NEXT_O_ID 的值。在 ORDER_LINE 表中選擇與條件 (OL_W_ID=W_ID, OL_D_ID=D_ID, OL_O_IDD_NEXT_O_ID, OL_O_IDD_NEXT_O_ID20)相匹配的所有的行。在 STOCK 表中選擇與條件(S_I_ID=OL_I_ID, S_W_ID=W_ID)相匹配的行，累加(S_QUANTITYthreshold)的行數(shù)。 ORDER STATUS（訂單狀況查詢）事務(wù)的實現(xiàn)該事務(wù)查詢客戶上一次訂單的狀態(tài)，是一個只讀事務(wù)，執(zhí)行頻率低，對系統(tǒng)的響應時間要求不是很嚴格。數(shù)據(jù)的輸入要求輸入倉庫編號 W_ID.地區(qū)編號 D_ID 是 1 到 10 的一個隨機數(shù)。事務(wù)具體執(zhí)行步驟：情況一（60%）：用戶是采用 C_LAST，則在 CUSTOMER 表中選擇與（C_W_ID,C_D_ID,C_LAST）相匹配的所有行。令 N 為所選擇的行數(shù)，則得到其中第 N/2 行的 C_BALANCE, C_FIRST, C_MIDDLE, C_ID 的值。情況二（40%）：用戶選擇的是 C_ID 查詢，則在 CUSTOMER 表中選擇與（C_W_ID,C_D_ID,C_ID ）相匹配的所有行。得到 C_BALANCE, C_FIRST, C_MIDDLE, C_LAST 的值。在 ORDER_T 表中選擇與條件（O_W_ID=C_W_ID, O_D_ID=C_D_ID, O_C_ID=O_ID）相匹配的且 O_ID 最大的記錄，這也是該客戶最近的一條訂單，得到對應的 O_ID, O_ENTRY_D, O_CARRIER_ID 的值。在 ORDER_LINE 表中選擇與條件（OL_W_ID=O_W_ID, OL_D_ID=O_D_ID, OL_O_ID=O_ID）相匹配的項，得到對應的OL_ID_ID,OL_QUANTITY, OL_AMOUNT,OL_OL_DELIVERY_D 的值。 測試方案在本項目的測試過程中，一個完成執(zhí)行的事務(wù)可以被定義為成功提交的事務(wù)。比如說 NEW ORDER 新訂單、PAYMENT 支付、ORDER STATUS 訂單查詢、STOCK LEVEL 庫存查詢等事務(wù)在終端顯示，也可是 DELIVERY 發(fā)貨事務(wù)成功在相應的文件中添加了正確的內(nèi)容。在未錄入 LoadRunner 腳本之前，這五個事務(wù)構(gòu)成一個完整的系統(tǒng)，各事務(wù)的選擇采用 CASE 語句實現(xiàn)，Payment:1，Neworder:2,Delivery :3， Order Status :4，Stock Level :5，用戶可以通過 1 到 5 選擇需要執(zhí)行的事務(wù)，當然每個事務(wù)執(zhí)行完畢用戶也可通過 Y/N 進行選擇是否需要繼續(xù)進行別的事務(wù)。其執(zhí)行過程可以用下圖進行說明：選擇事務(wù)1 、 支付2 、 新訂單3 、 發(fā)貨4 、 訂單狀態(tài)查詢5 、 庫存狀態(tài)查詢執(zhí)行所選事務(wù)輸入是否重新執(zhí)行事務(wù) （ Y / N ）Y退出程序N 選擇事務(wù)類型 ，等待用戶輸入 輸出事務(wù)結(jié)果 ，等待用戶輸入圖 41 事務(wù)執(zhí)行流程但是考慮到將整個系統(tǒng)同時錄入，因為 LoadRunner 錄入過程只錄入程序執(zhí)行的過程，而這五個事務(wù)全部一起錄入會導致在 LoadRunner 里自編代碼的工作量很大，所以在腳本錄入過程中便采用各個事務(wù)分別錄入的方法，這樣可以減少代碼的修改量。LoadRunner 工具支持很多的腳本協(xié)議，比如“Java Vuser”、 “Javascript Vuser”、“Microsoft .NET”、 “VB Vuser”、 “VB Script Vuser”我們可以根據(jù)不同的應用進行選擇，因為本測試程序是 C編寫的應用程序，故而選擇 協(xié)議 [4]。 圖 42 腳本協(xié)議選擇接著就是選擇需要錄入的文件所在位置，比如說錄入 NEW ORDER 事務(wù)：圖 43 錄制選擇在腳本錄入過程中，一般 vuser_init 一般都是錄入數(shù)據(jù)庫連接等的初始化，而 vuser_end 則一般錄入事務(wù)處理的結(jié)束部分，如數(shù)據(jù)庫的關(guān)閉等，但是為了方便起見，本測試是將所有的部分都錄入到 action 部分，這樣并不會對程序的執(zhí)行產(chǎn)生任何影響。圖 44 腳本錄入過程點擊停止，程序開始加載到 LoadRunner 里，另外在腳本的錄入過程中，為了使腳本錄入的代碼盡可能少，對于一些 for 語句，在 Visual Studio 編程中將其改為單行執(zhí)行，這樣在 LoadRunner 里就只會錄入一次，而對于程序的循環(huán)就在 action 函數(shù)里進行改寫。依次將五個事務(wù)都錄入，并且每個事務(wù)都是一個獨立體，都有 START TRANSACTION 和 END TRANSACTION，這樣可以保證事務(wù)的執(zhí)行完整性。比如 Payment 事務(wù)圖 45 事務(wù)開始在事務(wù)結(jié)束時采用 try ，catch 語句，圖 46 事務(wù)結(jié)束LoadRunner 不支持 Random 隨機函數(shù)，其隨機數(shù)的生成有其特有的機制，其是把某一個值替代為隨機數(shù)，方法是選中需要替代的變量值，選擇用變量來替代：圖 47 隨機變量修改（a）類型選擇為 Random Number：（b）對隨機數(shù)的屬性進行編輯，確定好每一個變量的值范圍和類型。如：（c ）接著對錄入的程序的一些值創(chuàng)建關(guān)聯(lián)，替代掉所有其對應的值，并將未錄入的程序代碼在 LoadRunner 里補充完整，運行程序，不斷改正程序里的BUG，直至正確運行。在本系統(tǒng)的測試中，測試步驟主要為：加載數(shù)據(jù) 載入腳本程序測試分析結(jié)果數(shù)據(jù)庫備份恢復數(shù)據(jù)與基準是否相符不相符輸出測試結(jié)果相符圖 48 測試步驟具體為： 執(zhí)行 Dataload 源程序，項 TPC_CWarehouse 加載初始數(shù)據(jù)，因為這個數(shù)據(jù)量比較大，每次加載都需要 1 個多小時才能完成，為了程序執(zhí)行的方便，同時也使得測試具有橫向比較性，將數(shù)據(jù)做一個備份，以備后用。 向 LoadRunner 里加載腳本并修改，執(zhí)行該腳本。 LoadRunner 里創(chuàng)建場景，對虛擬用戶進行相應的設(shè)置，開始程序的測試。 分析測試的結(jié)果，若測試結(jié)果與標準的不相符合，恢復數(shù)據(jù)，再次進行測試。 多次測試，將測試結(jié)果形成測試報告。 測試場景設(shè)置性能測試過程中，結(jié)果的正確與否，場景設(shè)置占有很大的比例關(guān)系。場景設(shè)置一般有兩類：一種是基于用戶實際使用情況的場景測試；另一種是為了特殊項目測試而設(shè)計的場景。第一種是為了驗證目的而進行，為了滿足顧客的基本需求；第二種是為了測試系統(tǒng)的擴展性、穩(wěn)定性等。對于本系統(tǒng)的場景設(shè)置，主要是為了驗證該系統(tǒng)是否能否滿足用戶的基本需求，屬于驗證性場景設(shè)置。本系統(tǒng)主要有五個獨立的事務(wù)，而對于每個事務(wù)的執(zhí)行平率，根據(jù) TPC_C 基準，其有嚴格的配比關(guān)系，表現(xiàn)為：表 41 測試事務(wù)配比要求事務(wù)類型 所占配比（%）Payment OrderStatus Delivery StockLevel NewOrder n/aNEW ORDER 事務(wù)沒有最低下限，其配比是所有是配比的剩余。TPC_C 基準的五個事務(wù)復雜程度有著很大的區(qū)別，如果不加入系統(tǒng)思考時間，則測試中就會出現(xiàn)最復雜的事務(wù)響應時間最長，但這與事實不符，因為NEW ORDER 事務(wù)是最復雜的事務(wù)，但其響應時間短才能滿足在線用戶的需求，所以必須加入思考時間。在這個測試中，思考時間可以定義為系統(tǒng)等待用戶輸入的時間。而系統(tǒng)的響應時間則是系統(tǒng)等待用戶最后一條輸入完畢到系統(tǒng)執(zhí)行完畢后者兩者之間的時間差。具體各個事務(wù)的思考時間大小如下表所示：表 41 事務(wù)思考時間Keying/think times(in seconds)Trans. nameMin. Average MaxNew order / / /Payment / / / Order status / / / Delivery / / / Stock level / / / 在測試中我們選用的是平均值。測試場景設(shè)置（方案一）：采用百分配比的方法，通過實際設(shè)置各事務(wù)所占的配比：NEW ORDER %,PAYMENT %, DELIVER