【正文】 ..........224. 測試方案及結(jié)果分析 ..........................................................................24 測試方案 ..........................................................................................................24 測試場景設(shè)置 ..................................................................................................29 測試結(jié)果分析 ..................................................................................................32 系統(tǒng)瓶頸分析 ..................................................................................................385. 全文總結(jié)和展望 ....................................................................................40 全文總結(jié) ..........................................................................................................40 展望 ..................................................................................................................40參考文獻 .................................................................................................................................................41致 謝 .......................................................................................................................................................421．緒 論 課題研究背景與意義隨著軟件業(yè)的迅猛發(fā)展，系統(tǒng)開發(fā)的結(jié)構(gòu)層次在不斷地加深，數(shù)據(jù)庫從以前一個默默無聞的后臺倉庫，逐漸演變?yōu)榻裉斓臄?shù)據(jù)庫系統(tǒng)，他在很多系統(tǒng)的設(shè)計中起著舉足輕重的作用，對于其性能的要求也越來越高，數(shù)據(jù)庫測試開發(fā)也逐漸演變出一些適合其特點的測試方法和工具 [7]。數(shù)據(jù)庫的測試同其他軟件測試一樣，包含性能測試和功能測試兩種。這個基準包含了幾種模型，包括控制模型、數(shù)據(jù)模型和事務(wù)處理模型，其中控制模型主要是描述了數(shù)據(jù)庫的運行模式，而數(shù)據(jù)模型則描述的是用戶訪問數(shù)據(jù)庫的數(shù)據(jù)集合，事務(wù)處理模型主要是描述用戶訪問數(shù)據(jù)庫的行為模式。由以上兩個方面的例子可以說明，在國內(nèi)，不管是研究新的測試標準研究在現(xiàn)有標準上增加新的應(yīng)用等方面都開展了許多工作，相信在不久的將來，國內(nèi)將會出現(xiàn)一套完整的數(shù)據(jù)庫測試方法。這樣做的一個主要目的就是可以大幅提高系統(tǒng)測試的效率。數(shù)據(jù)庫單元測試是測試應(yīng)用程序不同組成部分間所使用的數(shù)據(jù)。 本文組織結(jié)構(gòu)第一章介紹課題背景、國內(nèi)外數(shù)據(jù)庫性能評測基準領(lǐng)域的研究狀況以項目的主要工作等。以下簡要對這幾種測試的概念進行具體介紹。（三）、并發(fā)測試并發(fā)測試是性能測試的最主要部分，其重點關(guān)注的是多個用戶同時訪問同一個應(yīng)用模塊或者是數(shù)據(jù)是否存在性能問題。（二）、負載負載分為客戶端負載和服務(wù)器端負載，客戶端負載的簡單說就是有多少個用戶在同時使用軟件，服務(wù)器端負載的就是有多少個請求同時到達了服務(wù)器端，要求服務(wù)器進行處理。此外，LoadRunner能支持廣范的協(xié)議和技術(shù)，為一些特殊環(huán)境提供特殊的解決方案 [2][3]。 LoadRunner 功能描述 LoadRunner包含很多組件，最為我們所使用的有Visual User Generator、Controller和Analysis，其中Virtual User Generator（虛擬用戶生成器）主要是用于錄制測試腳本；Controller（中央調(diào)度器）主要是通過場景設(shè)置控制模擬用戶個數(shù)和并發(fā)數(shù)，進一步設(shè)置測試的調(diào)度方案，執(zhí)行腳本并記錄測試結(jié)果，包括缺陷報告和測試日志； Analysis（結(jié)果分析器）用于統(tǒng)計和分析測試結(jié)果，確定是否與發(fā)布的基準要求相符合。1%的訂購商品不在本地庫存中，需要其它地區(qū)的倉庫發(fā)貨。 TPCC的測試結(jié)果主要有兩個指標： 流量指標(Throughput，簡稱tpmC) tpmC 定義: TPCC 的吞吐量，按有效 TPCC 配置期間每分鐘處理的平均交易次數(shù)測量，至少要運行 12 分鐘。該事務(wù)執(zhí)行頻率高，要求系統(tǒng)響應(yīng)時間短。通過對這五個事務(wù)進行配比的不同體現(xiàn)出事務(wù)的執(zhí)行頻率不同，而且每個事務(wù)的復雜程度不同，這就可以體現(xiàn)出事務(wù)的響應(yīng)時間的區(qū)別。該類型要求生成一個最大長度不超過 N、任意長度、任意字符的變換尺寸文本，并且要求對于字符數(shù)小于 N 的需要用空格填滿。(m, n)說明該數(shù)總共有 m 位，其中小數(shù)點后 n 位。產(chǎn)生的數(shù)的個數(shù)也會由于所要求的精度不同而發(fā)生變化。unique within [x] 表示的是在小于 x 的數(shù)中取值，且每個數(shù)必須是唯一的，僅能取一次。接下來將對各個事務(wù)的特征和實現(xiàn)過程進行詳細分析。即C_D_ID=D_ID C_W_ID=W_ID.Order_t 表中的 ol_t 是 5 到 15 中的一個隨機數(shù)，平均為 計量 order 的大小。如果所有訂單都是本地的倉庫獲取，則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 加一。對于以上百分比的實現(xiàn)可以采用 1 到 100 的隨機數(shù) Y，當 Y=60 時，顧客的 last name 是用 NURand（255，0，999）生成的，而當 Y60 時，C_ID 是用NURand（1023 ，1，3000）生成的。這個事務(wù)的執(zhí)行頻率不高，對事物的響應(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)相匹配的所有的行。在 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 的值。圖 44 腳本錄入過程點擊停止，程序開始加載到 LoadRunner 里，另外在腳本的錄入過程中，為了使腳本錄入的代碼盡可能少，對于一些 for 語句，在 Visual Studio 編程中將其改為單行執(zhí)行，這樣在 LoadRunner 里就只會錄入一次，而對于程序的循環(huán)就在 action 函數(shù)里進行改寫。 多次測試，將測試結(jié)果形成測試報告。而系統(tǒng)的響應(yīng)時間則是系統(tǒng)等待用戶最后一條輸入完畢到系統(tǒng)執(zhí)行完畢后者兩者之間的時間差。TPC_C 基準的五個事務(wù)復雜程度有著很大的區(qū)別，如果不加入系統(tǒng)思考時間，則測試中就會出現(xiàn)最復雜的事務(wù)響應(yīng)時間最長，但這與事實不符，因為NEW ORDER 事務(wù)是最復雜的事務(wù)，但其響應(yīng)時間短才能滿足在線用戶的需求，所以必須加入思考時間。 LoadRunner 里創(chuàng)建場景，對虛擬用戶進行相應(yīng)的設(shè)置，開始程序的測試。LoadRunner 工具支持很多的腳本協(xié)議，比如“Java Vuser”、 “Javascript Vuser”、“Microsoft .NET”、 “VB Vuser”、 “VB Script Vuser”我們可以根據(jù)不同的應(yīng)用進行選擇，因為本測試程序是 C編寫的應(yīng)用程序，故而選擇 協(xié)議 [4]。情況二（40%）：用戶選擇的是 C_ID 查詢，則在 CUSTOMER 表中選擇與（C_W_ID,C_D_ID,C_ID ）相匹配的所有行。一、 數(shù)據(jù)輸入要求地區(qū)編號 D_ID 和用戶查詢的商品域值下限 THRESHOLD。 H_DATA 是 W_NAME 和 D_NAME 的拼接。即作為一個從 1 到 100 的隨機數(shù) X，當X=85 的時候，顧客的選擇是 C_D_ID=C_ID AND C_W_ID=W_ID。 從 CUSTOMER 表中找到 C_W_ID=W_ID,C_D_ID=D_ID,C_ID 與隨機生成的相等的項并返回顧客的折扣率 C_DISCOUNT，顧客的姓氏 C_LAST，顧客當前的賬務(wù)狀況 C_CREDIT。考慮到如果 Warehouse數(shù)量過多會導致數(shù)據(jù)量的龐大，故而 Warehouse 的取值只能為 1 或 2.District ID 是 1 到 10 的一個隨機數(shù)，但是保證了 District 的 D_W_ID 與Warehouse 的 ID 是一樣的。 基于 TPC_C 基準事務(wù)模型的實現(xiàn)由 節(jié)對 TPC_C 的介紹可知，TPC_C 的事務(wù)模型包含了一系列的讀操作和更新事務(wù)操作頻繁交互執(zhí)行的處理過程，模擬的是一種復雜的聯(lián)機事務(wù)應(yīng)用環(huán)境的創(chuàng)建的活動。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。圖 36 數(shù)據(jù)加載方案以下是對整個數(shù)據(jù)加載過程的定義說明： random 表示在指定范圍隨機生成一個數(shù)。要求生成一個長度為 N 位十進制的阿拉伯數(shù)字字符串。該類型要求生成 N 位數(shù)范圍內(nèi)的 ID 標識。DELIVERY 事務(wù)模擬的是對于任意一個客戶，隨機選取一個發(fā)貨包，更新被處理的用戶的賬戶余額，并把該訂單從新訂單中刪除。這個指標對于Price無法確定，故在本次測試中不予考慮，重點考慮的是第一個性能指標。 TPC_C 測試指標TPCC測試規(guī)范經(jīng)過兩年的研制，于1992年7月發(fā)布。因為這些功能對于系統(tǒng)的分析來說并沒有太大的作用，他們占用系統(tǒng)的資源和執(zhí)行的頻率也不會很高。創(chuàng)建真實的負載Virtual users建立起后，我們可以設(shè)定具體的負載方案，業(yè)務(wù)流程組合和虛擬用戶數(shù)量。 性能測試工具 LoadRunner 介紹現(xiàn)在軟件測試行業(yè)里有很多的軟件測試軟件，但是LoadRunner得到了廣泛的應(yīng)用，綜合起來，LoadRunner適用范圍很廣，它可以適用于各種體系架構(gòu)，其還是自動負載測試工具。常見的性能測試指標主要包含以下內(nèi)容：（一）、吞吐量/處理能力處理能力又叫吞吐量，指的是單位時間內(nèi)處理的客戶端請求數(shù)量。壓力測試分為高負載下的長時間（如24小時以上）的穩(wěn)定性壓力測試和極限負載情況下導致系統(tǒng)崩潰的破壞性壓力測試。由于本文主要針對的是數(shù)據(jù)庫的性能測試，接下來對性能測試的內(nèi)容和指標進行介紹： 性能測試分類廣義的性能測試通常包括壓力測試、負載測試、疲勞強度測試、并發(fā)（用戶）測試、大數(shù)據(jù)量測試、配置測試、可靠性測試、安全性測試等和性能相關(guān)的測試 [10]。對 TPC_C 基準數(shù)據(jù)庫的設(shè)計與事務(wù)模型的實現(xiàn)進行詳細的描述。三、單元測試對于一個軟件，要確保其功能是按照最先設(shè)計實現(xiàn)，我們可以創(chuàng)建一組測試并在開發(fā)過程中使用，這就是所謂的但也測試。接下來對這幾種測試進行簡要介紹。作為新生代的面向?qū)ο髷?shù)據(jù)庫系統(tǒng)，OO 數(shù)據(jù)庫系統(tǒng)可在具有復雜數(shù)據(jù)結(jié)構(gòu)的場合得到應(yīng)用，并且其也可能廣泛地應(yīng)用于在線事務(wù)處理中。清華大學就曾對通用海量數(shù)據(jù)庫性能的測試和實現(xiàn) [6]進行了研究。關(guān)鍵詞：數(shù)據(jù)庫 SQL Sever LoadRunner 性能測試The Implementation of Database System Performance Testing Based on TPC_C BenchmarkAbstractDatabase system is a system monly used in web sy