【正文】 測試場景設(shè)置（方案一）：采用百分配比的方法，通過實際設(shè)置各事務(wù)所占的配比：NEW ORDER %,PAYMENT %, DELIVERY 。而系統(tǒng)的響應(yīng)時間則是系統(tǒng)等待用戶最后一條輸入完畢到系統(tǒng)執(zhí)行完畢后者兩者之間的時間差。TPC_C 基準的五個事務(wù)復(fù)雜程度有著很大的區(qū)別，如果不加入系統(tǒng)思考時間，則測試中就會出現(xiàn)最復(fù)雜的事務(wù)響應(yīng)時間最長，但這與事實不符，因為NEW ORDER 事務(wù)是最復(fù)雜的事務(wù)，但其響應(yīng)時間短才能滿足在線用戶的需求，所以必須加入思考時間。對于本系統(tǒng)的場景設(shè)置，主要是為了驗證該系統(tǒng)是否能否滿足用戶的基本需求，屬于驗證性場景設(shè)置。場景設(shè)置一般有兩類：一種是基于用戶實際使用情況的場景測試；另一種是為了特殊項目測試而設(shè)計的場景。 多次測試，將測試結(jié)果形成測試報告。 LoadRunner 里創(chuàng)建場景，對虛擬用戶進行相應(yīng)的設(shè)置，開始程序的測試。在本系統(tǒng)的測試中，測試步驟主要為：加載數(shù)據(jù) 載入腳本程序測試分析結(jié)果數(shù)據(jù)庫備份恢復(fù)數(shù)據(jù)與基準是否相符不相符輸出測試結(jié)果相符圖 48 測試步驟具體為： 執(zhí)行 Dataload 源程序，項 TPC_CWarehouse 加載初始數(shù)據(jù)，因為這個數(shù)據(jù)量比較大，每次加載都需要 1 個多小時才能完成，為了程序執(zhí)行的方便，同時也使得測試具有橫向比較性，將數(shù)據(jù)做一個備份，以備后用。比如 Payment 事務(wù)圖 45 事務(wù)開始在事務(wù)結(jié)束時采用 try ，catch 語句，圖 46 事務(wù)結(jié)束LoadRunner 不支持 Random 隨機函數(shù)，其隨機數(shù)的生成有其特有的機制，其是把某一個值替代為隨機數(shù)，方法是選中需要替代的變量值，選擇用變量來替代：圖 47 隨機變量修改（a）類型選擇為 Random Number：（b）對隨機數(shù)的屬性進行編輯，確定好每一個變量的值范圍和類型。圖 44 腳本錄入過程點擊停止，程序開始加載到 LoadRunner 里，另外在腳本的錄入過程中，為了使腳本錄入的代碼盡可能少，對于一些 for 語句，在 Visual Studio 編程中將其改為單行執(zhí)行，這樣在 LoadRunner 里就只會錄入一次，而對于程序的循環(huán)就在 action 函數(shù)里進行改寫。LoadRunner 工具支持很多的腳本協(xié)議，比如“Java Vuser”、 “Javascript Vuser”、“Microsoft .NET”、 “VB Vuser”、 “VB Script Vuser”我們可以根據(jù)不同的應(yīng)用進行選擇，因為本測試程序是 C編寫的應(yīng)用程序，故而選擇 協(xié)議 [4]。在未錄入 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ù)可以被定義為成功提交的事務(wù)。在 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 的值。情況二（40%）：用戶選擇的是 C_ID 查詢，則在 CUSTOMER 表中選擇與（C_W_ID,C_D_ID,C_ID ）相匹配的所有行。事務(wù)具體執(zhí)行步驟：情況一（60%）：用戶是采用 C_LAST，則在 CUSTOMER 表中選擇與（C_W_ID,C_D_ID,C_LAST）相匹配的所有行。 ORDER STATUS（訂單狀況查詢）事務(wù)的實現(xiàn)該事務(wù)查詢客戶上一次訂單的狀態(tài)，是一個只讀事務(wù)，執(zhí)行頻率低，對系統(tǒng)的響應(yīng)時間要求不是很嚴格。在 ORDER_LINE 表中選擇與條件 (OL_W_ID=W_ID, OL_D_ID=D_ID, OL_O_IDD_NEXT_O_ID, OL_O_IDD_NEXT_O_ID20)相匹配的所有的行。一、 數(shù)據(jù)輸入要求地區(qū)編號 D_ID 和用戶查詢的商品域值下限 THRESHOLD。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ù)量。在 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進行更新。這個事務(wù)的執(zhí)行頻率不高，對事物的響應(yīng)時間也沒有嚴格的限制。 H_DATA 是 W_NAME 和 D_NAME 的拼接。 從 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。H_DATE 是當前的系統(tǒng)時間。對于以上百分比的實現(xiàn)可以采用 1 到 100 的隨機數(shù) Y，當 Y=60 時，顧客的 last name 是用 NURand（255，0，999）生成的，而當 Y60 時，C_ID 是用NURand（1023 ，1，3000）生成的。即作為一個從 1 到 100 的隨機數(shù) X，當X=85 的時候，顧客的選擇是 C_D_ID=C_ID AND C_W_ID=W_ID。這個事務(wù)要求高頻讀寫，所以響應(yīng)時間必須要快才能滿足在線用戶的需求。 Totalamount=sum(OL_AMOUNT)*(1C_DISCOUNT)*(1+W_TAX+D_TAX) PAYMENT（支付）事務(wù)的實現(xiàn)Payment 事務(wù)主要是更新用戶的賬戶并反映出地區(qū)和倉庫的銷售狀況。如果所有訂單都是本地的倉庫獲取，則O_ALL_LOCAL 被置為 1，否則為 0. ORDER_T 表中 O_OL_CNT 置為相應(yīng)的 OL_CNT. 對于 ORDER_T 表中的每一項 O_OL_CNT，表 ITEM 中找到符合I_ID=OL_I_ID 的項，返回 I_PRICE,I_NAME,I_DATA. STOCK 表中找到 S_I_ID=OL_I_ID 且 S_W_ID=OL_SUPPLY_W_ID,返回 S_QUANTITY, S_DIST_xx (xx 代表的是 S_DIST 的編號),S_DATA. 如果S_QUANTITY 的數(shù)超過 10，則 S_QUANTITY=OL_QUANTITYS_QUANTITY, 否則S_QUANTITY=(S_QUANTITYOL_QUANTITY)+ =SYTD+OL_QUANTITY,S_ORDER_CNT=S_ORDER_CNT+1.如果倉庫是遠方的，則 S_REMOTE_CNT 加一。 從 CUSTOMER 表中找到 C_W_ID=W_ID,C_D_ID=D_ID,C_ID 與隨機生成的相等的項并返回顧客的折扣率 C_DISCOUNT，顧客的姓氏 C_LAST，顧客當前的賬務(wù)狀況 C_CREDIT。O_ENTRY_D 是當前的系統(tǒng)時間。這一功能的實現(xiàn)可以采用隨機數(shù) 1 到 100 加以實現(xiàn)。即C_D_ID=D_ID C_W_ID=W_ID.Order_t 表中的 ol_t 是 5 到 15 中的一個隨機數(shù)，平均為 計量 order 的大小。考慮到如果 Warehouse數(shù)量過多會導(dǎo)致數(shù)據(jù)量的龐大，故而 Warehouse 的取值只能為 1 或 2.District ID 是 1 到 10 的一個隨機數(shù)，但是保證了 District 的 D_W_ID 與Warehouse 的 ID 是一樣的。tmpC 越大，說明系統(tǒng)的性能越好，系統(tǒng)對用戶的響應(yīng)時間也就越短。其主要內(nèi)容就是模仿在線用戶的訂單請求，用戶輸入一份完整的訂單（這一切在實現(xiàn)過程中都是隨機數(shù)生成） ，提交系統(tǒng)的過程。接下來將對各個事務(wù)的特征和實現(xiàn)過程進行詳細分析。 基于 TPC_C 基準事務(wù)模型的實現(xiàn)由 節(jié)對 TPC_C 的介紹可知，TPC_C 的事務(wù)模型包含了一系列的讀操作和更新事務(wù)操作頻繁交互執(zhí)行的處理過程，模擬的是一種復(fù)雜的聯(lián)機事務(wù)應(yīng)用環(huán)境的創(chuàng)建的活動。定義完這些重要的數(shù)據(jù)類型，通過表 對應(yīng)的各表的數(shù)量關(guān)系，將數(shù)據(jù)庫進行初始化。這個長度為4 的字符串通過 0 到 9999 隨機數(shù)產(chǎn)生，這就是說總共可以產(chǎn)生 10000 個編碼。unique within [x] 表示的是在小于 x 的數(shù)中取值，且每個數(shù)必須是唯一的，僅能取一次。0 1 2 3 4 5 6 7 8 9BAR OUGHT ABLE PRI PRES ESE ANTI CALLY ATION EING比如說產(chǎn)生的隨機數(shù) 245，那么 C_LAST 對應(yīng)的字符串就應(yīng)該為ABLEPRESESE。采用的算法是通過產(chǎn)生隨機數(shù)來的到字符串的長度 N，然后再隨機產(chǎn)生長度為 N 的字符串。random astring [x .. y] 隨機產(chǎn)生一個字符串，其最小長度為 x，最大長度為y，平均長度為(x+y)/2。產(chǎn)生的數(shù)的個數(shù)也會由于所要求的精度不同而發(fā)生變化。圖 36 數(shù)據(jù)加載方案以下是對整個數(shù)據(jù)加載過程的定義說明： random 表示在指定范圍隨機生成一個數(shù)。對于國產(chǎn)數(shù)據(jù)庫，有一部分廠商提供了比較高效的數(shù)據(jù)加載工具，例如可以將具有一定格式的文本數(shù)據(jù)文件加載到數(shù)據(jù)庫的表中，但同時一些廠商沒有提供或是提供的加載工具效率不高，如果采用這些加載工具就很浪費時間。 表的結(jié)構(gòu)關(guān)系TPC_C 基準數(shù)據(jù)庫的九張表通過主鍵引用聯(lián)系起來，各個表都有各自的用途，且各表之間的結(jié)構(gòu)關(guān)系（主鍵）為：圖 35 各表關(guān)系圖各張表的使用將在事務(wù)的使用中進行詳細介紹。(m, n)說明該數(shù)總共有 m 位，其中小數(shù)點后 n 位。要求生成一個長度為 N 位十進制的阿拉伯數(shù)字字符串。要求生成一個日期。要求生成一個長度為固定長度 N、字符為任意字符的文本。該類型要求生成一個最大長度不超過 N、任意長度、任意字符的變換尺寸文本，并且要求對于字符數(shù)小于 N 的需要用空格填滿。該類型要求生成 N 位數(shù)范圍內(nèi)的 ID 標識。還需要注意的是，無論 Warehouse 表記錄為多少， item 表總數(shù)為 100000 條記錄，并不隨Warehouse 的記錄數(shù)增加而變化。 基于 TPC_C 基準數(shù)據(jù)庫設(shè)計 SQL Server 2022 中表的設(shè)計通過 節(jié)的介紹，TPC_C 的邏輯結(jié)構(gòu)圖表明了 TPC_C 的總體操作流程，為了實現(xiàn)這一結(jié)構(gòu)，TPC_C 設(shè)計了九個相關(guān)的數(shù)據(jù)表，ER 關(guān)系圖如下：圖 32 TPC_C 基準 ER 圖表框里的數(shù)據(jù)表示該表存放的記錄數(shù)，倉庫數(shù) W 體現(xiàn)了數(shù)據(jù)庫中的數(shù)據(jù)規(guī)模，表間的數(shù)據(jù)表示各表中記錄條數(shù)的比例關(guān)系，k 表示 1000。通過對這五個事務(wù)進行配比的不同體現(xiàn)出事務(wù)的執(zhí)行頻率不同，而且每個事務(wù)的復(fù)雜程度不同，這就可以體現(xiàn)出事務(wù)的響應(yīng)時間的區(qū)別。DELIVERY 事務(wù)模擬的是對于任意一個客戶，隨機選取一個發(fā)貨包，更新被處理的用戶的賬戶余額，并把該訂單從新訂單中刪除。STOCK LEVEL 事務(wù)模擬的是用戶從固定的倉庫和地區(qū)中選取最后 20 條記錄，檢查訂單中所有貨物的庫存，計算并且把所有庫存數(shù)低于用戶指定域的商品數(shù)量。該事務(wù)要求高頻讀寫，所以響應(yīng)時間必須要快才能滿足在線用戶的需求。該事務(wù)執(zhí)行頻率高，要求系統(tǒng)響應(yīng)時間短。這個指標對于Price無法確定，故在本次測試中不予考慮，重點考慮的是第一個性能指標。 性價比(Price/Performance，簡稱Price/tpmC) 即測試系統(tǒng)價格（指在美國的報價）與流量指標的比值。所有交易的響應(yīng)時間必須滿足TPCC 測試規(guī)范的要求。 TPCC的測試結(jié)果主要有兩個指標： 流量指標(Throughput，簡稱tpmC) tpmC 定義: TPCC 的吞吐量，按有效 TPCC 配置期間每分鐘處理的平均交易次數(shù)測量，至少要運行 12 分鐘。 TPC_C 測試指標TPCC測試規(guī)范經(jīng)過兩年的研制，于1992年7月發(fā)布。d) 每個客戶平均一個訂單有10 項產(chǎn)品。b) 每個倉庫負責(zé)為10個銷售點供貨。1%的訂購商品不在本地庫存中，需要