【正文】 的實(shí)現(xiàn) .............................................................17 NEW ORDER（新訂單）事務(wù)的實(shí)現(xiàn) ................................................17 PAYMENT（支付）事務(wù)的實(shí)現(xiàn) ........................................................19 DELIVERY（發(fā)貨）事務(wù)的實(shí)現(xiàn) ........................................................21 STOCK LEVEL（庫存狀況查詢）事務(wù)實(shí)現(xiàn) .....................................22 ORDER STATUS（訂單狀況查詢）事務(wù)的實(shí)現(xiàn) ..............................224. 測(cè)試方案及結(jié)果分析 ..........................................................................24 測(cè)試方案 ..........................................................................................................24 測(cè)試場(chǎng)景設(shè)置 ..................................................................................................29 測(cè)試結(jié)果分析 ..................................................................................................32 系統(tǒng)瓶頸分析 ..................................................................................................385. 全文總結(jié)和展望 ....................................................................................40 全文總結(jié) ..........................................................................................................40 展望 ..................................................................................................................40參考文獻(xiàn) .................................................................................................................................................41致 謝 .......................................................................................................................................................421．緒 論 課題研究背景與意義隨著軟件業(yè)的迅猛發(fā)展，系統(tǒng)開發(fā)的結(jié)構(gòu)層次在不斷地加深，數(shù)據(jù)庫從以前一個(gè)默默無聞的后臺(tái)倉庫，逐漸演變?yōu)榻裉斓臄?shù)據(jù)庫系統(tǒng)，他在很多系統(tǒng)的設(shè)計(jì)中起著舉足輕重的作用，對(duì)于其性能的要求也越來越高，數(shù)據(jù)庫測(cè)試開發(fā)也逐漸演變出一些適合其特點(diǎn)的測(cè)試方法和工具 [7]。目前，有各種各樣的功能強(qiáng)大的數(shù)據(jù)庫測(cè)試工具，但是能正確的使用工具開發(fā)合適的腳本、創(chuàng)建測(cè)試場(chǎng)景和正確的根據(jù)自己需要的測(cè)試參數(shù)選擇合適的測(cè)試工具是需要豐富的經(jīng)驗(yàn)與技巧的。在這篇論文中作者為了能夠反映出數(shù)據(jù)庫實(shí)際的運(yùn)行性能，其設(shè)計(jì)了一種可配置數(shù)據(jù)庫性能的測(cè)試基準(zhǔn)，這種基準(zhǔn)能夠針對(duì)具體的應(yīng)用數(shù)據(jù)庫系統(tǒng)，建立吸納供應(yīng)的控制模型。這說明，在國內(nèi)我們也開始慢慢尋找出更加符合實(shí)際的標(biāo)準(zhǔn)來對(duì)數(shù)據(jù)庫進(jìn)行測(cè)試。但是為我們所熟知的 TPCC 基準(zhǔn)僅給出了數(shù)據(jù)模型、事務(wù)處理和測(cè)試指標(biāo)的定義，研究數(shù)據(jù)庫測(cè)試技術(shù)以及 TPCC 基準(zhǔn)在面向?qū)ο髷?shù)據(jù)庫中的使用也是大有裨益。所謂的軟件測(cè)試一般看來就是根據(jù)軟件開發(fā)各階段的制約和軟件的內(nèi)部結(jié)構(gòu)，精心設(shè)計(jì)很多的測(cè)試用例，包括一些極端的測(cè)試用例，這些用例的內(nèi)容包括輸入數(shù)據(jù)以及預(yù)期的輸出結(jié)果，應(yīng)用這些測(cè)試用例來不斷地運(yùn)行程序，發(fā)現(xiàn)其中不符合質(zhì)量的特性要求，亦即軟件的缺陷和錯(cuò)誤。一、系統(tǒng)測(cè)試系統(tǒng)測(cè)試包括了不同的測(cè)試組成部分，其主要目的就是充分地運(yùn)行系統(tǒng)，并進(jìn)一步驗(yàn)證系統(tǒng)各部件是否都能夠正常地完成所賦予的任務(wù)，所以當(dāng)產(chǎn)品需求和系統(tǒng)設(shè)計(jì)的文檔完成以后，系統(tǒng)測(cè)試的小組成員就應(yīng)該提前開始制定出相應(yīng)的測(cè)試計(jì)劃和設(shè)計(jì)幾個(gè)不同的測(cè)試用例，不必等到“實(shí)現(xiàn)與測(cè)試”階段完成以后在進(jìn)行。二、集成測(cè)試集成測(cè)試主要是對(duì)接口進(jìn)行的測(cè)試工作。單元測(cè)試主要側(cè)重的是邏輯覆蓋，其可以通過語句覆蓋和走讀的方式完成。QTP 是一款自動(dòng)測(cè)試工具，其通過對(duì)對(duì)象的捕捉和識(shí)別，模擬用戶的操作流程，并通過校驗(yàn)方法或結(jié)合數(shù)據(jù)庫后臺(tái)的監(jiān)控對(duì)整個(gè)數(shù)據(jù)庫的數(shù)據(jù)進(jìn)行測(cè)試。本文的實(shí)踐是基于數(shù)據(jù)庫性能測(cè)試標(biāo)準(zhǔn)和數(shù)據(jù)庫負(fù)載測(cè)試工具Loadrunner，詳細(xì)介紹了從腳本錄制修、測(cè)試場(chǎng)景設(shè)計(jì)到最后測(cè)試結(jié)果分析的整個(gè)過程，為以后對(duì) Loadrunner 工具的使用提供參考。第四章提出測(cè)試方案，并對(duì)測(cè)試的結(jié)果進(jìn)行分析，與TPC_C提供的標(biāo)準(zhǔn)進(jìn)行對(duì)比，找出系統(tǒng)的瓶頸。通常一次測(cè)試也是包括這幾種測(cè)試中的多種的。負(fù)載測(cè)試的預(yù)期結(jié)果是用戶的性能需求得到滿足。一般來說，壓力測(cè)試就是讓系統(tǒng)在極端的條件下工作，查看系統(tǒng)的表現(xiàn)，并且這種極端條件是高于系統(tǒng)用戶的需求的?？煽啃詼y(cè)試可以有效的暴露在實(shí)際使用過程中影響可靠性要求的缺陷。通常，吞吐量用請(qǐng)求數(shù)/秒或頁面數(shù)/秒來衡量。（四）、同時(shí)在線用戶數(shù)量同時(shí)在想用戶對(duì)本系統(tǒng)來說就是在同一時(shí)刻，執(zhí)行各個(gè)事務(wù)的用戶數(shù)量總和。它能夠模擬上成千上萬個(gè)并發(fā)用戶，同時(shí)向服務(wù)器發(fā)送請(qǐng)求，并記錄和分析測(cè)試結(jié)果，最終幫助企業(yè)快速、有效的查找和發(fā)現(xiàn)問題，通過使用LoadRunner，企業(yè)能最大限度地縮短測(cè)試時(shí)間、優(yōu)化性能和加速應(yīng)用系統(tǒng)的發(fā)布周期。通過這個(gè)虛擬用戶產(chǎn)生器，可以虛擬用戶并模擬真實(shí)用戶的業(yè)務(wù)操作行為。這主要是使用LoadRunner的Controller，通過不同的場(chǎng)景設(shè)置，可以組織起多用戶的測(cè)試方案，更好地對(duì)系統(tǒng)進(jìn)行全方位的測(cè)試。它模擬的是被復(fù)雜話了的聯(lián)機(jī)事務(wù)處理應(yīng)用環(huán)境的創(chuàng)建活動(dòng)，其主要是把許多系統(tǒng)組成部件和特定環(huán)境關(guān)聯(lián)起來實(shí)現(xiàn)的 [1]，這種環(huán)境具有如下的一些表現(xiàn)： 能夠并行執(zhí)行的事務(wù)是有一定復(fù)雜度的 具有可在線處理事務(wù)執(zhí)行的模式 支持多個(gè)線終端活動(dòng) 較好地協(xié)調(diào)系統(tǒng)運(yùn)行和應(yīng)用程序執(zhí)行時(shí)間 通過 ACID 特性保證事務(wù)處理的正確性。TPC_C 模仿的是一個(gè)分布在多個(gè)地區(qū)都有銷售點(diǎn)的公司，隨著公司業(yè)務(wù)的增長(zhǎng)，新的 Warehouse 和銷售地區(qū)都會(huì)隨之建立，一個(gè)倉庫管理 10 個(gè)地區(qū)，每個(gè)地區(qū)為 3,000 名客服服務(wù)，所有的倉庫管理公司的 100,000 條銷售，客戶可以提交訂單訂購商品，平均每個(gè)訂單包含 10 個(gè)訂單項(xiàng)。c) 每個(gè)銷售點(diǎn)為3000個(gè)客戶提供服務(wù) 。幾乎所有在OLTP市場(chǎng)提供軟硬件平臺(tái)的廠商都發(fā)布了相應(yīng)的TPCC測(cè)試結(jié)果，隨著計(jì)算機(jī)技術(shù)的不斷發(fā)展，這些測(cè)試結(jié)果也在不斷刷新。流量指標(biāo)值越大越好。結(jié)合 節(jié)提出的數(shù)據(jù)庫性能測(cè)試指標(biāo)，包括吞吐量/處理能力、負(fù)載、響應(yīng)時(shí)間、同時(shí)在線用戶數(shù)量、TPS 等幾項(xiàng)，TPC_C 基準(zhǔn)提供的五個(gè)事務(wù)模型各有其特點(diǎn)：NEW ORDER 事務(wù)模仿在線用戶的訂單請(qǐng)求，用戶輸入一份完整的訂單，提交系統(tǒng)。ORDER STATUS 事務(wù)查詢客戶上一次訂單的狀態(tài)，是一個(gè)只讀事務(wù)，執(zhí)行頻率低，對(duì)系統(tǒng)的響應(yīng)時(shí)間要求不是很嚴(yán)格。這個(gè)事務(wù)的執(zhí)行頻率不高，對(duì)事物的響應(yīng)時(shí)間也沒有嚴(yán)格的限制。換句話說，給數(shù)據(jù)庫加載數(shù)據(jù)時(shí)，如果給數(shù)據(jù)表 Warehouse 表裝入 l 條記錄的話，那么District 須裝入 10 條記錄，Customer 須裝入 3000 條記錄，history 須裝入 30000條記錄，Order 須裝入 30000 條記錄，NewOrder 須裝入 9000 條記錄，OrderLine 須裝入 300000 條記錄， Stock 須裝入 100000 條記錄。2. Variable text. Size N 型。 and time 型。并且，包含貨幣的數(shù)值域必須使用這樣的數(shù)據(jù)類型具有精確度為兩位小數(shù)的實(shí)型。 TPC_C 基準(zhǔn)數(shù)據(jù)錄入大多數(shù)的數(shù)據(jù)庫提供有專門的數(shù)據(jù)加載工具，這些加載工具具有快速高效的性能，比如說 Oracle 的 Sql*Loader，SQL Sever 的 DTS 等工具。random[x,y]表示從 x 到 y 的范圍中隨機(jī)選擇一個(gè)數(shù)，一般平均數(shù)為(x+y)/2?？梢允亲帜缸址部梢允菙?shù)字字符串。隨機(jī)數(shù) 59 對(duì)應(yīng) C_LAST 的值為 ESEEING。例如，隨機(jī)字符串 0970，那么郵編碼就是 30，000 位顧客，但編碼只有 10，000 個(gè)，所以平均有三位顧客是使用同一個(gè)郵編。這個(gè)環(huán)境的核心活動(dòng)是 NEW ORDER 事務(wù)，其他四個(gè)事務(wù)是在一個(gè)倉庫中進(jìn)行的 PAYMENT 支付操作、ORDER STATUS 訂單狀態(tài)查詢操作、DELIVERY 發(fā)貨操作和 STOCK LEVEL 庫存狀態(tài)查詢操作。在測(cè)試過程中，每分鐘生成的訂單數(shù) tmpC 是整個(gè)系統(tǒng)性能的重要參考和評(píng)價(jià)指標(biāo)。即 D_W_ID=W_ID.顧客編號(hào) C_ID 是用 NURand（1023，1，3000）生成的但保證顧客所選的倉庫號(hào)與 Warehouse 的 W_ID 一致并且地區(qū)號(hào)與 District 的 D_ID 一致。即當(dāng) X1 時(shí)，OL_SUPPLY_W_ID=W_ID,而 X=1 時(shí)，OL_SUPPLY_W_ID 是從可用倉庫中隨機(jī)選擇的一個(gè)，而不是 W_ID.OL_QUANTITY 是 1 到 10 的隨機(jī)數(shù)。 往 NEW_ORDER 和 ORDER 表中填入新項(xiàng)以表有新的訂單生成，同時(shí)O_CARRIER_ID 設(shè)置為 NULL。對(duì)于任意一個(gè)客戶，在固定的倉庫中隨機(jī)選取一個(gè)地區(qū)及其內(nèi)用戶，采用隨機(jī)的金額支付一筆訂單，并作相應(yīng)的歷史記錄，修改用戶的金額。當(dāng) X85時(shí)，C_D_ID 是 1 到 10 的一個(gè)隨機(jī)數(shù)，C_W_ID 是當(dāng)前可用的倉庫中的一個(gè)，并且滿足 C_W_ID 不等于 W_ID。二、事務(wù)實(shí)現(xiàn)具體步驟： 從 WAREHOUSE 表中選出與輸入的 W_ID 相符的項(xiàng)，并返回W_NAME, W_STREET_1, W_STREET_2, W_CITY, W_STATE,和 W_ZIP，并且 W_YTD+=H_AMOUNT。 往 HISTORY 表中插入新項(xiàng) 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ù)的實(shí)現(xiàn)該事務(wù)模擬的是對(duì)于任意一個(gè)客戶，隨機(jī)選取一個(gè)發(fā)貨包，更新被處理的用戶的賬戶余額，并把該訂單從新訂單中刪除。在 ORDER_LINE 里找到所有 OL_W_ID=W_ID, OL_D_ID=D_ID, OL_O_ID=C_OD ，并將 OL_DELIVERY_D 改為當(dāng)前的系統(tǒng)時(shí)間，并將OL_AMOUNT 數(shù)更新。二、 事務(wù)具體實(shí)現(xiàn)步驟：在 DISTRICT 表中選擇與(D_W_ID，D_ID)相匹配的行，得到 D_NEXT_O_ID 的值。數(shù)據(jù)的輸入要求輸入倉庫編號(hào) W_ID.地區(qū)編號(hào) D_ID 是 1 到 10 的一個(gè)隨機(jī)數(shù)。得到 C_BALANCE, C_FIRST, C_MIDDLE, C_LAST 的值。比如說 NEW ORDER 新訂單、PAYMENT 支付、ORDER STATUS 訂單查詢、STOCK LEVEL 庫存查詢等事務(wù)在終端顯示，也可是 DELIVERY 發(fā)貨事務(wù)成功在相應(yīng)的文件中添加了正確的內(nèi)容。 圖 42 腳本協(xié)議選擇接著就是選擇需要錄入的文件所在位置，比如說錄入 NEW ORDER 事務(wù)：圖 43 錄制選擇在腳本錄入過程中，一般 vuser_init 一般都是錄入數(shù)據(jù)庫連接等的初始化，而 vuser_end 則一般錄入事務(wù)處理的結(jié)束部分，如數(shù)據(jù)庫的關(guān)閉等，但是為了方便起見，本測(cè)試是將所有的部分都錄入到 action 部分，這樣并不會(huì)對(duì)程序的執(zhí)行產(chǎn)生任何影響。如：（c ）接著對(duì)錄入的程序的一些值創(chuàng)建關(guān)聯(lián)，替代掉所有其對(duì)應(yīng)的值，并將未錄入的程序代碼在 LoadRunner 里補(bǔ)充完整，運(yùn)行程序，不斷改正程序里的BUG，直至正確運(yùn)行。 分析測(cè)試的結(jié)果，若測(cè)試結(jié)果與標(biāo)準(zhǔn)的不相符合，恢復(fù)數(shù)據(jù)，再次進(jìn)行測(cè)試。第一種是為了驗(yàn)證目的而進(jìn)行，為了滿足顧客的基本需求；第二種是為了測(cè)試系統(tǒng)的擴(kuò)展性、穩(wěn)定性等。在這個(gè)測(cè)試中，思考時(shí)間可以定義為系統(tǒng)等待用戶輸入的