【正文】 于本文主要針對的是數(shù)據(jù)庫的性能測試，接下來對性能測試的內(nèi)容和指標(biāo)進(jìn)行介紹： 性能測試分類廣義的性能測試通常包括壓力測試、負(fù)載測試、疲勞強(qiáng)度測試、并發(fā)（用戶）測試、大數(shù)據(jù)量測試、配置測試、可靠性測試、安全性測試等和性能相關(guān)的測試 [10]。負(fù)載測試是站在用戶的角度去觀察在一定條件下，軟件系統(tǒng)的性能表現(xiàn)。壓力測試分為高負(fù)載下的長時(shí)間（如24小時(shí)以上）的穩(wěn)定性壓力測試和極限負(fù)載情況下導(dǎo)致系統(tǒng)崩潰的破壞性壓力測試。（四） 、可靠性測試可靠性測試指通過給系統(tǒng)加載一定的業(yè)務(wù)壓力的情況下，讓系統(tǒng)在盡量真實(shí)環(huán)境下或者仿真的使用環(huán)境下運(yùn)行一段時(shí)間，測試系統(tǒng)在這種條件下能否穩(wěn)定運(yùn)行。常見的性能測試指標(biāo)主要包含以下內(nèi)容：（一）、吞吐量/處理能力處理能力又叫吞吐量，指的是單位時(shí)間內(nèi)處理的客戶端請求數(shù)量。響應(yīng)時(shí)間一般分為最大響應(yīng)時(shí)間、最小響應(yīng)時(shí)間和平均響應(yīng)時(shí)間。 性能測試工具 LoadRunner 介紹現(xiàn)在軟件測試行業(yè)里有很多的軟件測試軟件，但是LoadRunner得到了廣泛的應(yīng)用，綜合起來，LoadRunner適用范圍很廣，它可以適用于各種體系架構(gòu)，其還是自動負(fù)載測試工具。錄入腳本的過程其實(shí)就是其記錄業(yè)務(wù)操作流程，但是這個僅是流程的某一個分支，如果需要完整地運(yùn)行程序，代碼的修改是必不可少的。創(chuàng)建真實(shí)的負(fù)載Virtual users建立起后，我們可以設(shè)定具體的負(fù)載方案，業(yè)務(wù)流程組合和虛擬用戶數(shù)量。TPC_C 是復(fù)雜聯(lián)機(jī)事務(wù)處理（OLTP）應(yīng)用環(huán)境工作量的一個衡量標(biāo)準(zhǔn)，其并不實(shí)際表示某一個企業(yè)所進(jìn)行的操作，但是其高度提煉了所有企業(yè)都必須進(jìn)行的操作，比如管理或銷售產(chǎn)品或是服務(wù)。因?yàn)檫@些功能對于系統(tǒng)的分析來說并沒有太大的作用，他們占用系統(tǒng)的資源和執(zhí)行的頻率也不會很高。b) 每個倉庫負(fù)責(zé)為10個銷售點(diǎn)供貨。 TPC_C 測試指標(biāo)TPCC測試規(guī)范經(jīng)過兩年的研制，于1992年7月發(fā)布。所有交易的響應(yīng)時(shí)間必須滿足TPCC 測試規(guī)范的要求。這個指標(biāo)對于Price無法確定，故在本次測試中不予考慮，重點(diǎn)考慮的是第一個性能指標(biāo)。該事務(wù)要求高頻讀寫，所以響應(yīng)時(shí)間必須要快才能滿足在線用戶的需求。DELIVERY 事務(wù)模擬的是對于任意一個客戶，隨機(jī)選取一個發(fā)貨包，更新被處理的用戶的賬戶余額，并把該訂單從新訂單中刪除。 基于 TPC_C 基準(zhǔn)數(shù)據(jù)庫設(shè)計(jì) SQL Server 2022 中表的設(shè)計(jì)通過 節(jié)的介紹，TPC_C 的邏輯結(jié)構(gòu)圖表明了 TPC_C 的總體操作流程，為了實(shí)現(xiàn)這一結(jié)構(gòu)，TPC_C 設(shè)計(jì)了九個相關(guān)的數(shù)據(jù)表，ER 關(guān)系圖如下：圖 32 TPC_C 基準(zhǔn) ER 圖表框里的數(shù)據(jù)表示該表存放的記錄數(shù)，倉庫數(shù) W 體現(xiàn)了數(shù)據(jù)庫中的數(shù)據(jù)規(guī)模，表間的數(shù)據(jù)表示各表中記錄條數(shù)的比例關(guān)系，k 表示 1000。該類型要求生成 N 位數(shù)范圍內(nèi)的 ID 標(biāo)識。要求生成一個長度為固定長度 N、字符為任意字符的文本。要求生成一個長度為 N 位十進(jìn)制的阿拉伯?dāng)?shù)字字符串。 表的結(jié)構(gòu)關(guān)系TPC_C 基準(zhǔn)數(shù)據(jù)庫的九張表通過主鍵引用聯(lián)系起來，各個表都有各自的用途，且各表之間的結(jié)構(gòu)關(guān)系（主鍵）為：圖 35 各表關(guān)系圖各張表的使用將在事務(wù)的使用中進(jìn)行詳細(xì)介紹。圖 36 數(shù)據(jù)加載方案以下是對整個數(shù)據(jù)加載過程的定義說明： random 表示在指定范圍隨機(jī)生成一個數(shù)。random astring [x .. y] 隨機(jī)產(chǎn)生一個字符串，其最小長度為 x，最大長度為y，平均長度為(x+y)/2。0 1 2 3 4 5 6 7 8 9BAR OUGHT ABLE PRI PRES ESE ANTI CALLY ATION EING比如說產(chǎn)生的隨機(jī)數(shù) 245，那么 C_LAST 對應(yīng)的字符串就應(yīng)該為ABLEPRESESE。這個長度為4 的字符串通過 0 到 9999 隨機(jī)數(shù)產(chǎn)生，這就是說總共可以產(chǎn)生 10000 個編碼。 基于 TPC_C 基準(zhǔn)事務(wù)模型的實(shí)現(xiàn)由 節(jié)對 TPC_C 的介紹可知，TPC_C 的事務(wù)模型包含了一系列的讀操作和更新事務(wù)操作頻繁交互執(zhí)行的處理過程，模擬的是一種復(fù)雜的聯(lián)機(jī)事務(wù)應(yīng)用環(huán)境的創(chuàng)建的活動。其主要內(nèi)容就是模仿在線用戶的訂單請求，用戶輸入一份完整的訂單（這一切在實(shí)現(xiàn)過程中都是隨機(jī)數(shù)生成） ，提交系統(tǒng)的過程?？紤]到如果 Warehouse數(shù)量過多會導(dǎo)致數(shù)據(jù)量的龐大，故而 Warehouse 的取值只能為 1 或 2.District ID 是 1 到 10 的一個隨機(jī)數(shù)，但是保證了 District 的 D_W_ID 與Warehouse 的 ID 是一樣的。這一功能的實(shí)現(xiàn)可以采用隨機(jī)數(shù) 1 到 100 加以實(shí)現(xiàn)。 從 CUSTOMER 表中找到 C_W_ID=W_ID,C_D_ID=D_ID,C_ID 與隨機(jī)生成的相等的項(xiàng)并返回顧客的折扣率 C_DISCOUNT，顧客的姓氏 C_LAST，顧客當(dāng)前的賬務(wù)狀況 C_CREDIT。 Totalamount=sum(OL_AMOUNT)*(1C_DISCOUNT)*(1+W_TAX+D_TAX) PAYMENT（支付）事務(wù)的實(shí)現(xiàn)Payment 事務(wù)主要是更新用戶的賬戶并反映出地區(qū)和倉庫的銷售狀況。即作為一個從 1 到 100 的隨機(jī)數(shù) X，當(dāng)X=85 的時(shí)候，顧客的選擇是 C_D_ID=C_ID AND C_W_ID=W_ID。H_DATE 是當(dāng)前的系統(tǒng)時(shí)間。 H_DATA 是 W_NAME 和 D_NAME 的拼接。在 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)行更新。一、 數(shù)據(jù)輸入要求地區(qū)編號 D_ID 和用戶查詢的商品域值下限 THRESHOLD。 ORDER STATUS（訂單狀況查詢）事務(wù)的實(shí)現(xiàn)該事務(wù)查詢客戶上一次訂單的狀態(tài)，是一個只讀事務(wù)，執(zhí)行頻率低，對系統(tǒng)的響應(yīng)時(shí)間要求不是很嚴(yán)格。情況二（40%）：用戶選擇的是 C_ID 查詢，則在 CUSTOMER 表中選擇與（C_W_ID,C_D_ID,C_ID ）相匹配的所有行。 測試方案在本項(xiàng)目的測試過程中，一個完成執(zhí)行的事務(wù)可以被定義為成功提交的事務(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]。比如 Payment 事務(wù)圖 45 事務(wù)開始在事務(wù)結(jié)束時(shí)采用 try ，catch 語句，圖 46 事務(wù)結(jié)束LoadRunner 不支持 Random 隨機(jī)函數(shù)，其隨機(jī)數(shù)的生成有其特有的機(jī)制，其是把某一個值替代為隨機(jī)數(shù)，方法是選中需要替代的變量值，選擇用變量來替代：圖 47 隨機(jī)變量修改（a）類型選擇為 Random Number：（b）對隨機(jī)數(shù)的屬性進(jìn)行編輯，確定好每一個變量的值范圍和類型。 LoadRunner 里創(chuàng)建場景，對虛擬用戶進(jìn)行相應(yīng)的設(shè)置，開始程序的測試。場景設(shè)置一般有兩類：一種是基于用戶實(shí)際使用情況的場景測試；另一種是為了特殊項(xiàng)目測試而設(shè)計(jì)的場景。TPC_C 基準(zhǔn)的五個事務(wù)復(fù)雜程度有著很大的區(qū)別，如果不加入系統(tǒng)思考時(shí)間，則測試中就會出現(xiàn)最復(fù)雜的事務(wù)響應(yīng)時(shí)間最長，但這與事實(shí)不符，因?yàn)镹EW ORDER 事務(wù)是最復(fù)雜的事務(wù)，但其響應(yīng)時(shí)間短才能滿足在線用戶的需求，所以必須加入思考時(shí)間。測試場景設(shè)置（方案一）：采用百分配比的方法，通過實(shí)際設(shè)置各事務(wù)所占的配比：NEW ORDER %,PAYMENT %, DELIVERY 。而系統(tǒng)的響應(yīng)時(shí)間則是系統(tǒng)等待用戶最后一條輸入完畢到系統(tǒng)執(zhí)行完畢后者兩者之間的時(shí)間差。對于本系統(tǒng)的場景設(shè)置，主要是為了驗(yàn)證該系統(tǒng)是否能否滿足用戶的基本需求，屬于驗(yàn)證性場景設(shè)置。 多次測試，將測試結(jié)果形成測試報(bào)告。在本系統(tǒng)的測試中，測試步驟主要為：加載數(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 個多小時(shí)才能完成，為了程序執(zhí)行的方便，同時(shí)也使得測試具有橫向比較性，將數(shù)據(jù)做一個備份，以備后用。圖 44 腳本錄入過程點(diǎn)擊停止，程序開始加載到 LoadRunner 里，另外在腳本的錄入過程中，為了使腳本錄入的代碼盡可能少，對于一些 for 語句，在 Visual Studio 編程中將其改為單行執(zhí)行，這樣在 LoadRunner 里就只會錄入一次，而對于程序的循環(huán)就在 action 函數(shù)里進(jìn)行改寫。在未錄入 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ù)。在 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 的值。事務(wù)具體執(zhí)行步驟：情況一（60%）：用戶是采用 C_LAST，則在 CUSTOMER 表中選擇與（C_W_ID,C_D_ID,C_LAST）相匹配的所有行。在 ORDER_LINE 表中選擇與條件 (OL_W_ID=W_ID, OL_D_ID=D_ID, OL_O_IDD_NEXT_O_ID, OL_O_IDD_NEXT_O_ID20)相匹配的所有的行。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ù)的執(zhí)行頻率不高，對事物的響應(yīng)時(shí)間也沒有嚴(yán)格的限制。 從 DISTRICT 表中選擇出 D_W_ID=W_ID,D_ID 與隨機(jī)生成 D_ID 的相等的項(xiàng)，并返回 D_NAME, D_STREET_1, D_STREET_2, D_CITY, D_STATE,和 D_ZIP，且 D_YTD+=H_AMOUNT. 情況一：當(dāng)顧客的查詢是按 C_ID 是，從 CUSTOMER 表中找到與C_W_ID,C_D_ID,C_ID 相符的項(xiàng)，返回 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。對于以上百分比的實(shí)現(xiàn)可以采用 1 到 100 的隨機(jī)數(shù) Y，當(dāng) Y=60 時(shí)，顧客的 last name 是用 NURand（255，0，999）生成的，而當(dāng) Y60 時(shí)，C_ID 是用NURand（1023 ，1，3000）生成的。這個事務(wù)要求高頻讀寫，所以響應(yīng)時(shí)間必須要快才能滿足在線用戶的需求。如果所有訂單都是本地的倉庫獲取，則O_ALL_LOCAL 被置為 1，否則為 0. ORDER_T 表中 O_OL_CNT 置為相應(yīng)的 OL_CNT. 對于 ORDER_T 表中的每一項(xiàng) O_OL_CNT，表 ITEM 中找到符合I_ID=OL_I_ID 的項(xiàng)，返回 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.如果倉庫是遠(yuǎn)方的，則 S_REMOTE_CNT 加一。O_ENTRY_D 是當(dāng)前的系統(tǒng)時(shí)間。即C_D_ID=D_ID C_W_ID=W_ID.Order_t 表中的 ol_t 是 5 到 15 中的一個隨機(jī)數(shù)，平均為 計(jì)量 order 的大小。tmpC 越大，說明系統(tǒng)的性能越好，系統(tǒng)對用戶的響應(yīng)時(shí)間也就越短。接下來將對各個事務(wù)的特征和實(shí)現(xiàn)過程進(jìn)行詳細(xì)分析。定義完這些重要的數(shù)據(jù)類型，通過表 對應(yīng)的各表的數(shù)量關(guān)系，將數(shù)據(jù)庫進(jìn)行初始化。unique wit