【正文】 選取一個發(fā)貨包，更新被處理的用戶的賬戶余額，并把該訂單從新訂單中刪除。這個事務(wù)的執(zhí)行頻率不高，對事物的響應(yīng)時間也沒有嚴(yán)格的限制。一、數(shù)據(jù)輸入要求W_ID 是用戶輸入，其值只能為 1 或 2O_CARRIER_ID 是 1 到 10 的一個隨機(jī)數(shù)OL_DELIVERY_D 是當(dāng)前系統(tǒng)的時間二、事務(wù)執(zhí)行具體步驟： 在 NEW_ORDER 表里找到 NO_W_ID= W_ID 并且 NO_D_ID=D_ID的最小的 NO_O_ID，這代表的是未發(fā)貨的最老的歷史記錄（默認(rèn) NO_OID 最小的項(xiàng)） ，接著將 NEW_ORDER 表里對應(yīng)的這一行刪除。在 ORDER_T 表里找到匹配的 O_W_ID=W_ID, O_D_ID=D_ID, O_ID=NO_O_ID 的行，返回 O_C_ID，并將對應(yīng)的顧客號的 O_CARRIER_ID進(jìn)行更新。在 ORDER_LINE 里找到所有 OL_W_ID=W_ID, OL_D_ID=D_ID, 24OL_O_ID=C_OD ，并將 OL_DELIVERY_D 改為當(dāng)前的系統(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ù)實(shí)現(xiàn)該事務(wù)模擬的是用戶從固定的倉庫和地區(qū)中選取最后 20 條記錄，檢查訂單中所有貨物的庫存，計(jì)算并且把所有庫存數(shù)低于用戶指定域的商品數(shù)量。這個事務(wù)是只讀事務(wù)，執(zhí)行的頻率較低，對系統(tǒng)的響應(yīng)時間不做嚴(yán)格限制和要求。一、 數(shù)據(jù)輸入要求地區(qū)編號 D_ID 和用戶查詢的商品域值下限 THRESHOLD。二、 事務(wù)具體實(shí)現(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ù)的實(shí)現(xiàn)該事務(wù)查詢客戶上一次訂單的狀態(tài)，是一個只讀事務(wù)，執(zhí)行頻率低，對系統(tǒng)的響應(yīng)時間要求不是很嚴(yán)格。數(shù)據(jù)的輸入要求輸入倉庫編號 W_ID.地區(qū)編號 D_ID 是 1 到 10 的一個隨機(jī)數(shù)。25事務(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 最大的記錄，這也是該客戶最近的一條訂單，得到對應(yīng)的 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）相匹配的項(xiàng)，得到對應(yīng)的OL_ID_ID,OL_QUANTITY, OL_AMOUNT,OL_OL_DELIVERY_D 的值。26 測試方案在本項(xiàng)目的測試過程中，一個完成執(zhí)行的事務(wù)可以被定義為成功提交的事務(wù)。比如說 NEW ORDER 新訂單、PAYMENT 支付、ORDER STATUS 訂單查詢、STOCK LEVEL 庫存查詢等事務(wù)在終端顯示，也可是 DELIVERY 發(fā)貨事務(wù)成功在相應(yīng)的文件中添加了正確的內(nèi)容。在未錄入 LoadRunner 腳本之前，這五個事務(wù)構(gòu)成一個完整的系統(tǒng)，各事務(wù)的選擇采用 CASE 語句實(shí)現(xiàn)，Payment:1，Neworder:2,Delivery :3， Order Status :4，Stock Level :5，用戶可以通過 1 到 5 選擇需要執(zhí)行的事務(wù)，當(dāng)然每個事務(wù)執(zhí)行完畢用戶也可通過 Y/N 進(jìn)行選擇是否需要繼續(xù)進(jìn)行別的事務(wù)。其執(zhí)行過程可以用下圖進(jìn)行說明：選擇事務(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í)行流程27但是考慮到將整個系統(tǒng)同時錄入，因?yàn)?LoadRunner 錄入過程只錄入程序執(zhí)行的過程，而這五個事務(wù)全部一起錄入會導(dǎo)致在 LoadRunner 里自編代碼的工作量很大，所以在腳本錄入過程中便采用各個事務(wù)分別錄入的方法，這樣可以減少代碼的修改量。LoadRunner 工具支持很多的腳本協(xié)議，比如“Java Vuser”、 “Javascript Vuser”、“Microsoft .NET”、 “VB Vuser”、 “VB Script Vuser”我們可以根據(jù)不同的應(yīng)用進(jìn)行選擇，因?yàn)楸緶y試程序是 C編寫的應(yīng)用程序，故而選擇 協(xié)議 [4]。 圖 42 腳本協(xié)議選擇接著就是選擇需要錄入的文件所在位置，比如說錄入 NEW ORDER 事務(wù)：28圖 43 錄制選擇在腳本錄入過程中，一般 vuser_init 一般都是錄入數(shù)據(jù)庫連接等的初始化，而 vuser_end 則一般錄入事務(wù)處理的結(jié)束部分，如數(shù)據(jù)庫的關(guān)閉等，但是為了方便起見，本測試是將所有的部分都錄入到 action 部分，這樣并不會對程序的執(zhí)行產(chǎn)生任何影響。圖 44 腳本錄入過程點(diǎn)擊停止，程序開始加載到 LoadRunner 里，另外在腳本的錄入過程中，為了使腳本錄入的代碼盡可能少，對于一些 for 語句，在 Visual Studio 編程中將其改為單行執(zhí)行，這樣在 LoadRunner 里就只會錄入一次，而對于程序的循環(huán)就在 action 函數(shù)里進(jìn)行改寫。依次將五個事務(wù)都錄入，并且每個事務(wù)都是一個獨(dú)立體，都有 START TRANSACTION 和 END TRANSACTION，這樣可以保證事務(wù)的執(zhí)行完整性。比如 Payment 事務(wù)圖 45 事務(wù)開始在事務(wù)結(jié)束時采用 try ，catch 語句，29圖 46 事務(wù)結(jié)束LoadRunner 不支持 Random 隨機(jī)函數(shù)，其隨機(jī)數(shù)的生成有其特有的機(jī)制，其是把某一個值替代為隨機(jī)數(shù)，方法是選中需要替代的變量值，選擇用變量來替代：圖 47 隨機(jī)變量修改（a）類型選擇為 Random Number：（b）對隨機(jī)數(shù)的屬性進(jìn)行編輯，確定好每一個變量的值范圍和類型。如：（c ）接著對錄入的程序的一些值創(chuàng)建關(guān)聯(lián)，替代掉所有其對應(yīng)的值，并將未錄入的程序代碼在 LoadRunner 里補(bǔ)充完整，運(yùn)行程序，不斷改正程序里的BUG，直至正確運(yùn)行。在本系統(tǒng)的測試中，測試步驟主要為：30加載數(shù)據(jù) 載入腳本程序測試分析結(jié)果數(shù)據(jù)庫備份恢復(fù)數(shù)據(jù)與基準(zhǔn)是否相符不相符輸出測試結(jié)果相符圖 48 測試步驟具體為： 執(zhí)行 Dataload 源程序，項(xiàng) TPC_CWarehouse 加載初始數(shù)據(jù)，因?yàn)檫@個數(shù)據(jù)量比較大，每次加載都需要 1 個多小時才能完成，為了程序執(zhí)行的方便，同時也使得測試具有橫向比較性，將數(shù)據(jù)做一個備份，以備后用。 向 LoadRunner 里加載腳本并修改，執(zhí)行該腳本。 LoadRunner 里創(chuàng)建場景，對虛擬用戶進(jìn)行相應(yīng)的設(shè)置，開始程序的測試。 分析測試的結(jié)果，若測試結(jié)果與標(biāo)準(zhǔn)的不相符合，恢復(fù)數(shù)據(jù)，再次進(jìn)行測試。 多次測試，將測試結(jié)果形成測試報(bào)告。31 測試場景設(shè)置性能測試過程中，結(jié)果的正確與否，場景設(shè)置占有很大的比例關(guān)系。場景設(shè)置一般有兩類：一種是基于用戶實(shí)際使用情況的場景測試；另一種是為了特殊項(xiàng)目測試而設(shè)計(jì)的場景。第一種是為了驗(yàn)證目的而進(jìn)行，為了滿足顧客的基本需求；第二種是為了測試系統(tǒng)的擴(kuò)展性、穩(wěn)定性等。對于本系統(tǒng)的場景設(shè)置，主要是為了驗(yàn)證該系統(tǒng)是否能否滿足用戶的基本需求，屬于驗(yàn)證性場景設(shè)置。本系統(tǒng)主要有五個獨(dú)立的事務(wù)，而對于每個事務(wù)的執(zhí)行平率，根據(jù) TPC_C 基準(zhǔn)，其有嚴(yán)格的配比關(guān)系，表現(xiàn)為：表 41 測試事務(wù)配比要求事務(wù)類型 所占配比（%）Payment OrderStatus Delivery StockLevel NewOrder n/aNEW ORDER 事務(wù)沒有最低下限，其配比是所有是配比的剩余。TPC_C 基準(zhǔn)的五個事務(wù)復(fù)雜程度有著很大的區(qū)別，如果不加入系統(tǒng)思考時間，則測試中就會出現(xiàn)最復(fù)雜的事務(wù)響應(yīng)時間最長，但這與事實(shí)不符，因?yàn)镹EW ORDER 事務(wù)是最復(fù)雜的事務(wù)，但其響應(yīng)時間短才能滿足在線用戶的需求，所以必須加入思考時間。在這個測試中，思考時間可以定義為系統(tǒng)等待用戶輸入的時間。而系統(tǒng)的響應(yīng)時間則是系統(tǒng)等待用戶最后一條輸入完畢到系統(tǒng)執(zhí)行完畢后者兩者之間的時間差。具體各個事務(wù)的思考時間大小如下表所示：32表 41 事務(wù)思考時間Keying/think times(in seconds)Trans. nameMin. Average MaxNew order / / /Payment / / / Order status / / / Delivery / / / Stock level / / / 在測試中我們選用的是平均值。測試場景設(shè)置（方案一）：采用百分配比的方法，通過實(shí)際設(shè)置各事務(wù)所占的配比：NEW ORDER %,PAYMENT %, DELIVERY %, STOCK LEVEL % , ORDER STATUS % 。虛擬用戶設(shè)置為 25 個，測試持續(xù)時長為 20min。測試 NEW ORDER 的配比大于 DELIVERY 十倍，是因?yàn)?DELIVERY 是批量執(zhí)行發(fā)貨操作，每次發(fā)貨平均是 10 個訂單，所以 NEW ORDER 的執(zhí)行頻率也應(yīng)該是DELIVERY 的 10 倍，這樣才不會導(dǎo)致發(fā)貨操作過程中出現(xiàn)訂單不夠的情況。通過設(shè)置，方案一的運(yùn)行概略為下圖所示。33圖 49 測試執(zhí)行過程這一方案可以通過觀察在線用戶為 25 時系統(tǒng)的 CPU 使用情況，進(jìn)而考慮給系統(tǒng)是否做增壓處理，對該系統(tǒng)作負(fù)載、壓力、并發(fā)以及安全測試。增大系統(tǒng)的壓力，以測量系統(tǒng)在不同的壓力下的性能表現(xiàn)。通過設(shè)置系統(tǒng)的在線用戶為 40，持續(xù)時間仍為 20min 再次進(jìn)行測試。測試場景（方案二）：采用面向目標(biāo)的場景設(shè)置，這個方案可以測試不同的對象目標(biāo)。其目標(biāo)類型包括每秒鐘事務(wù)數(shù)、在線用戶數(shù)以及系統(tǒng)響應(yīng)時間等。因?yàn)樵?TPC_C 基準(zhǔn)測試中，被測系統(tǒng)的性能是由每分鐘所能處理的事務(wù)數(shù)來衡的，并且這里的事務(wù)數(shù)主要是指訂單的數(shù)量，即 New order 的事務(wù)數(shù)量。所以在這個測試方案中主要就是測量系統(tǒng)是否能夠達(dá)到基準(zhǔn)的 Tmpc 目標(biāo)，如果達(dá)不到，逐級減少目標(biāo)事務(wù)數(shù)，找出該系統(tǒng)的最大的 Tmpc。所以本方案設(shè)置的目標(biāo)類型為Transactions per second. 定義 Goal 為 new order 達(dá)到 1 個，通過 25 到 50 個在34線用戶來實(shí)現(xiàn)這個目標(biāo)，并且達(dá)到目標(biāo)后繼續(xù)運(yùn)行 10min。具體設(shè)置結(jié)果如下圖所示：圖 410 目標(biāo)設(shè)置 測試結(jié)果分析測試時間 ：2022 年 5 月 10 日 測試人員：吳汾操作系統(tǒng)：Windows XP處理器：Inter(R) Pentium(R) 4 CPU 內(nèi)存： 80G事務(wù)編寫環(huán)境：Visio Studio 2022數(shù)據(jù)庫：SQL Sever 2022編寫語言：C測試工具：LoadRunner方案一測試結(jié)果分析： 35通過觀察發(fā)現(xiàn)在整個測試工程中，初始化階段 CPU 使用率較高，但當(dāng)用戶初始化完成后，系統(tǒng)的 CPU 占用率較低，保持在 20%以下，并且系統(tǒng)的在線用戶數(shù)長時間保持在 24 個，達(dá)到了系統(tǒng)設(shè)定的頂峰值，這說明這樣的壓力系統(tǒng)能夠很好地運(yùn)行。測試結(jié)果：表 42 虛擬用戶數(shù)位 25 的測試結(jié)果Transaction Name Minimum Average Maximum Std. Deviation 90 Percent TPS（avg.）Pass Fail StopAction_Transaction 1,865 1 0Delivery 346 0 0New order 417 1 0Order status 104 0 0Payment 831 0 0Stock level 167 0 0vuser_end_Transaction 0 25 0 0vuser_init_