【正文】 瓶頸，最后起到優(yōu)化系統(tǒng)的目的。評價一個數(shù)據(jù)庫僅僅通過其功能是否實現(xiàn)是遠(yuǎn)遠(yuǎn)不夠的，性能的好壞與否也是一個非常重要的指標(biāo)。目前，有各種各樣的功能強(qiáng)大的數(shù)據(jù)庫測試工具，但是能正確的使用工具開發(fā)合適的腳本、創(chuàng)建測試場景和正確的根據(jù)自己需要的測試參數(shù)選擇合適的測試工具是需要豐富的經(jīng)驗與技巧的?；谇叭说慕?jīng)驗，本文具體分析和實現(xiàn)了基于 TPC_C 基準(zhǔn)的數(shù)據(jù)庫性能測試。 國內(nèi)外數(shù)據(jù)庫性能測試的研究狀況隨著數(shù)據(jù)庫性能測試的不斷升溫，對數(shù)據(jù)庫的測試方法和內(nèi)容也是層出不窮。清華大學(xué)就曾對通用海量數(shù)據(jù)庫性能的測試和實現(xiàn) [6]進(jìn)行了研究。在這篇論文中作者為了能夠反映出數(shù)據(jù)庫實際的運行性能，其設(shè)計了一種可配置數(shù)據(jù)庫性能的測試基準(zhǔn)，這種基準(zhǔn)能夠針對具體的應(yīng)用數(shù)據(jù)庫系統(tǒng)，建立吸納供應(yīng)的控制模型。這個基準(zhǔn)包含了幾種模型，包括控制模型、數(shù)據(jù)模型和事務(wù)處理模型，其中控制模型主要是描述了數(shù)據(jù)庫的運行模式，而數(shù)據(jù)模型則描述的是用戶訪問數(shù)據(jù)庫的數(shù)據(jù)集合，事務(wù)處理模型主要是描述用戶訪問數(shù)據(jù)庫的行為模式?？刂颇Ｐ屯聞?wù)處理模型和數(shù)據(jù)庫模型組裝動態(tài) SQL 語句，然后產(chǎn)生多個并發(fā)進(jìn)程模擬大量實際用戶訪問數(shù)據(jù)庫，以測試數(shù)據(jù)庫的運行狀況和性能。這個測試標(biāo)準(zhǔn)，與目前國際上通用的固定模型測試標(biāo)準(zhǔn)如 TPC_C 等相比，更能夠客觀反映數(shù)據(jù)庫實際運行性能。這說明，在國內(nèi)我們也開始慢慢尋找出更加符合實際的標(biāo)準(zhǔn)來對數(shù)據(jù)庫進(jìn)行測試。但是這一項目僅對數(shù)據(jù)庫的正確性和可用性進(jìn)行了相關(guān)設(shè)計和實現(xiàn)，如果要想形成像 TPC_C 那樣通用的且能對數(shù)據(jù)庫的各方面性能都能進(jìn)行測試的方案，還需要進(jìn)一步的研究。東北大學(xué)就曾對 TPC_C 測試標(biāo)準(zhǔn)及其在面向?qū)ο髷?shù)據(jù)庫 [14]上的設(shè)計與實現(xiàn)一文中也指出，數(shù)據(jù)庫測試標(biāo)準(zhǔn)主要用途是數(shù)據(jù)庫的開發(fā)者通過對其系統(tǒng)的性能測試和評價，而對系統(tǒng)進(jìn)行改進(jìn)和完善，用戶根據(jù)不同系統(tǒng)的測試數(shù)據(jù)，而選擇性能優(yōu)良的系統(tǒng)。作為新生代的面向?qū)ο髷?shù)據(jù)庫系統(tǒng)，OO 數(shù)據(jù)庫系統(tǒng)可在具有復(fù)雜數(shù)據(jù)結(jié)構(gòu)的場合得到應(yīng)用，并且其也可能廣泛地應(yīng)用于在線事務(wù)處理中。但是為我們所熟知的 TPCC 基準(zhǔn)僅給出了數(shù)據(jù)模型、事務(wù)處理和測試指標(biāo)的定義，研究數(shù)據(jù)庫測試技術(shù)以及 TPCC 基準(zhǔn)在面向?qū)ο髷?shù)據(jù)庫中的使用也是大有裨益。由以上兩個方面的例子可以說明，在國內(nèi)，不管是研究新的測試標(biāo)準(zhǔn)研究在現(xiàn)有標(biāo)準(zhǔn)上增加新的應(yīng)用等方面都開展了許多工作，相信在不久的將來，國內(nèi)將會出現(xiàn)一套完整的數(shù)據(jù)庫測試方法。數(shù)據(jù)庫系統(tǒng)測試作為軟件測試的一個重要分支，在詳細(xì)闡述其之前，我們有必要對軟件測試進(jìn)行一個概述。鑒于目前國內(nèi)對軟件測試的重視程度在不斷地提高，許多軟件測試方面的材料和研究也在不斷地推進(jìn)，以前的那種對軟件測試“可有可無”的態(tài)度得到了很大的改善，他已變成了軟件開發(fā)的一個必不可少的一個環(huán)節(jié)，很多軟件開發(fā)公司都有自己的軟件測試小組。所謂的軟件測試一般看來就是根據(jù)軟件開發(fā)各階段的制約和軟件的內(nèi)部結(jié)構(gòu)，精心設(shè)計很多的測試用例，包括一些極端的測試用例，這些用例的內(nèi)容包括輸入數(shù)據(jù)以及預(yù)期的輸出結(jié)果，應(yīng)用這些測試用例來不斷地運行程序，發(fā)現(xiàn)其中不符合質(zhì)量的特性要求，亦即軟件的缺陷和錯誤。另一方面，軟件的測試是貫穿整個軟件開發(fā)的生命周期中，所以軟件的需求設(shè)計、規(guī)格說明書以及程序等都要包含測試的相關(guān)內(nèi)容。至于數(shù)據(jù)庫測試種類，從測試過程的角度可以分為系統(tǒng)測試、集成測試和單元測試。接下來對這幾種測試進(jìn)行簡要介紹。一、系統(tǒng)測試系統(tǒng)測試包括了不同的測試組成部分，其主要目的就是充分地運行系統(tǒng)，并進(jìn)一步驗證系統(tǒng)各部件是否都能夠正常地完成所賦予的任務(wù)，所以當(dāng)產(chǎn)品需求和系統(tǒng)設(shè)計的文檔完成以后，系統(tǒng)測試的小組成員就應(yīng)該提前開始制定出相應(yīng)的測試計劃和設(shè)計幾個不同的測試用例，不必等到“實現(xiàn)與測試”階段完成以后在進(jìn)行。這樣做的一個主要目的就是可以大幅提高系統(tǒng)測試的效率。其測試工具有主要用于評估測試各種不同系統(tǒng)參數(shù)下的數(shù)據(jù)庫負(fù)載情況的模塊化、跨平臺、多線程基準(zhǔn)測試工具 sysbench。這一階段的測試主要是通過數(shù)據(jù)庫設(shè)計評審來實現(xiàn)。二、集成測試集成測試主要是對接口進(jìn)行的測試工作。其主要考慮的是內(nèi)容包括數(shù)據(jù)項的修改操作、數(shù)據(jù)項的增加操作、數(shù)據(jù)項的刪除操作、數(shù)據(jù)表空、數(shù)據(jù)表滿、刪除空表中的記錄、數(shù)據(jù)表的并發(fā)操作、針對存儲過程的接口測試、結(jié)合業(yè)務(wù)邏輯做關(guān)聯(lián)表的接口測試。等價類、邊界值、錯誤猜測等是其采用的主要方法。三、單元測試對于一個軟件，要確保其功能是按照最先設(shè)計實現(xiàn)，我們可以創(chuàng)建一組測試并在開發(fā)過程中使用，這就是所謂的但也測試。單元測試主要側(cè)重的是邏輯覆蓋，其可以通過語句覆蓋和走讀的方式完成。數(shù)據(jù)庫單元測試是測試應(yīng)用程序不同組成部分間所使用的數(shù)據(jù)。比如當(dāng)一個應(yīng)用程序升級或是重新開發(fā)，用戶便可設(shè)置單元測試用例，驗證這個應(yīng)用程序的數(shù)據(jù)輸出在不同的版本間是否是一致的 [10]。隨著數(shù)據(jù)庫測試的不斷發(fā)展，現(xiàn)在在數(shù)據(jù)庫功能的測試領(lǐng)域中有許多的工具，例如 DBunit、QTP 、 DataFacory 等，其中 DBunit 是一款開源的數(shù)據(jù)庫功能測試框架，其可以使用類似于 Junit 的方式對數(shù)據(jù)庫的基本操作進(jìn)行白盒單元測試，對輸入輸出進(jìn)行校驗。QTP 是一款自動測試工具，其通過對對象的捕捉和識別，模擬用戶的操作流程，并通過校驗方法或結(jié)合數(shù)據(jù)庫后臺的監(jiān)控對整個數(shù)據(jù)庫的數(shù)據(jù)進(jìn)行測試。DataFactory 是數(shù)據(jù)自動生成工具，通過它可以生成任意的結(jié)構(gòu)數(shù)據(jù)庫，并實現(xiàn)對數(shù)據(jù)庫的填充，可以根據(jù)需要產(chǎn)生大量的數(shù)據(jù)以幫助驗證數(shù)據(jù)庫中的各種功能是否正確。 本文的主要工作鑒于目前專門對數(shù)據(jù)庫性能測試的研究還有待深入研究，現(xiàn)有的測試方法缺少了對數(shù)據(jù)庫性能的詳細(xì)評測，本文研究的創(chuàng)新點和主要內(nèi)容如下：對數(shù)據(jù)庫測試的內(nèi)容、指標(biāo)進(jìn)行更加深入詳細(xì)的歸納總結(jié)。對 TPC_C 基準(zhǔn)數(shù)據(jù)庫的設(shè)計與事務(wù)模型的實現(xiàn)進(jìn)行詳細(xì)的描述。本文的實踐是基于數(shù)據(jù)庫性能測試標(biāo)準(zhǔn)和數(shù)據(jù)庫負(fù)載測試工具Loadrunner，詳細(xì)介紹了從腳本錄制修、測試場景設(shè)計到最后測試結(jié)果分析的整個過程，為以后對 Loadrunner 工具的使用提供參考。 本文組織結(jié)構(gòu)第一章介紹課題背景、國內(nèi)外數(shù)據(jù)庫性能評測基準(zhǔn)領(lǐng)域的研究狀況以項目的主要工作等。第二章介紹數(shù)據(jù)庫性能測試的主要方法、內(nèi)容、主要測試工具LoadRunner，為課題的設(shè)計和實現(xiàn)奠定基礎(chǔ)。第三章對TPC_C做了介紹，并詳細(xì)分析和實現(xiàn)了基于TPC_C基準(zhǔn)的事務(wù)模型。第四章提出測試方案，并對測試的結(jié)果進(jìn)行分析，與TPC_C提供的標(biāo)準(zhǔn)進(jìn)行對比，找出系統(tǒng)的瓶頸。第五章對全文進(jìn)行總結(jié)和展望，指出項目的不足和改進(jìn)的空間。2．?dāng)?shù)據(jù)庫性能測試 數(shù)據(jù)庫性能測試方法及內(nèi)容數(shù)據(jù)庫測試屬于軟件測試測試中的一類，一般從以下三個方面進(jìn)行分類：從透明度分為黑盒測試和白盒測試；從開發(fā)過程可分為單元測試、集成測試、系統(tǒng)測試等；專門性的測試還包括安全性測試、性能測試和內(nèi)存測試等。由于本文主要針對的是數(shù)據(jù)庫的性能測試，接下來對性能測試的內(nèi)容和指標(biāo)進(jìn)行介紹： 性能測試分類廣義的性能測試通常包括壓力測試、負(fù)載測試、疲勞強(qiáng)度測試、并發(fā)（用戶）測試、大數(shù)據(jù)量測試、配置測試、可靠性測試、安全性測試等和性能相關(guān)的測試 [10]。通常一次測試也是包括這幾種測試中的多種的。以下簡要對這幾種測試的概念進(jìn)行具體介紹。（一）負(fù)載測試負(fù)載測試是模擬實際軟件系統(tǒng)所承受的負(fù)載條件的系統(tǒng)負(fù)荷，通過不斷加載（如逐漸增加模擬用戶的數(shù)量）或其它加載方式來觀察不同負(fù)載下系統(tǒng)的響應(yīng)時間和數(shù)據(jù)吞吐量、系統(tǒng)占用的資源（如 CPU、內(nèi)存）等，以檢驗系統(tǒng)的行為和特性，以發(fā)現(xiàn)系統(tǒng)可能存在的性能瓶頸、內(nèi)存泄漏、不能實時同步等問題。負(fù)載測試是站在用戶的角度去觀察在一定條件下，軟件系統(tǒng)的性能表現(xiàn)。負(fù)載測試的預(yù)期結(jié)果是用戶的性能需求得到滿足。這些需求指標(biāo)一般體現(xiàn)為響應(yīng)時間、交易容量、并發(fā)容量、資源使用率等。（二）、壓力測試壓力測試是在強(qiáng)負(fù)載（大數(shù)據(jù)量、大量并發(fā)用戶等）下的測試，查看應(yīng)用系統(tǒng)在峰值使用情況下表現(xiàn)狀況，從而有效地發(fā)現(xiàn)系統(tǒng)的一些功能隱患、系統(tǒng)的容錯能力和可恢復(fù)能力是否良好等等。壓力測試分為高負(fù)載下的長時間（如24小時以上）的穩(wěn)定性壓力測試和極限負(fù)載情況下導(dǎo)致系統(tǒng)崩潰的破壞性壓力測試。一般來說，壓力測試就是讓系統(tǒng)在極端的條件下工作，查看系統(tǒng)的表現(xiàn)，并且這種極端條件是高于系統(tǒng)用戶的需求的。（三）、并發(fā)測試并發(fā)測試是性能測試的最主要部分，其重點關(guān)注的是多個用戶同時訪問同一個應(yīng)用模塊或者是數(shù)據(jù)是否存在性能問題。它是通過一個包含了負(fù)載測試和壓力測試的過程，分析各種交易執(zhí)行指標(biāo)和資源監(jiān)控指標(biāo)來確定系統(tǒng)并發(fā)性能的過程。（四） 、可靠性測試可靠性測試指通過給系統(tǒng)加載一定的業(yè)務(wù)壓力的情況下，讓系統(tǒng)在盡量真實環(huán)境下或者仿真的使用環(huán)境下運行一段時間，測試系統(tǒng)在這種條件下能否穩(wěn)定運行。可靠性測試可以有效的暴露在實際使用過程中影響可靠性要求的缺陷。它介于功能測試和性能測試之間，是在功能實現(xiàn)的基礎(chǔ)上更接近模擬現(xiàn)實環(huán)境下的測試。 性能測試指標(biāo)要進(jìn)行軟件性能測試，首先需要知道軟件測試中有哪些性能指標(biāo)，否則軟件的性能測試就無從做起。常見的性能測試指標(biāo)主要包含以下內(nèi)容：（一）、吞吐量/處理能力處理能力又叫吞吐量，指的是單位時間內(nèi)處理的客戶端請求數(shù)量。通常，吞吐量用請求數(shù)/秒或頁面數(shù)/秒來衡量。（二）、負(fù)載負(fù)載分為客戶端負(fù)載和服務(wù)器端負(fù)載，客戶端負(fù)載的簡單說就是有多少個用戶在同時使用軟件，服務(wù)器端負(fù)載的就是有多少個請求同時到達(dá)了服務(wù)器端，要求服務(wù)器進(jìn)行處理。（三）、響應(yīng)時間響應(yīng)時間是可以判斷一個被測應(yīng)用系統(tǒng)是否存在性能瓶頸的最直觀的要素。響應(yīng)時間一般分為最大響應(yīng)時間、最小響應(yīng)時間和平均響應(yīng)時間。（四）、同時在線用戶數(shù)量同時在想用戶對本系統(tǒng)來說就是在同一時刻，執(zhí)行各個事務(wù)的用戶數(shù)量總和。（五）、TPS (Transactions Per Second)是應(yīng)用系統(tǒng)每秒鐘完成交易的數(shù)量，是估算應(yīng)用系統(tǒng)性能的重要依據(jù)。系統(tǒng)整體處理能力取決于處理能力最低模塊的TPS 值。 性能測試工具 LoadRunner 介紹現(xiàn)在軟件測試行業(yè)里有很多的軟件測試軟件，但是LoadRunner得到了廣泛的應(yīng)用，綜合起來，LoadRunner適用范圍很廣，它可以適用于各種體系架構(gòu)，其還是自動負(fù)載測試工具。它能夠模擬上成千上萬個并發(fā)用戶，同時向服務(wù)器發(fā)送請求，并記錄和分析測試結(jié)果，最終幫助企業(yè)快速、有效的查找和發(fā)現(xiàn)問題，通過使用LoadRunner，企業(yè)能最大限度地縮短測試時間、優(yōu)化性能和加速應(yīng)用系統(tǒng)的發(fā)布周期。此外，LoadRunner能支持廣范的協(xié)議和技術(shù)，為一些特殊環(huán)境提供特殊的解決方案 [2][3]。 LoadRunner 的特點 LoadRunner的具體特點表現(xiàn)為如下兩點：輕松創(chuàng)建虛擬用戶采用LoadRunner 的Virtual User Generator ，可以錄入我們需要測試腳本并進(jìn)行修改，進(jìn)一步可以很簡便地創(chuàng)立起系統(tǒng)負(fù)載。錄入腳本的過程其實就是其記錄業(yè)務(wù)操作流程，但是這個僅是流程的某一個分支，如果需要完整地運行程序，代碼的修改是必不可少的。通過這個虛擬用戶產(chǎn)生器，可以虛擬用戶并模擬真實用戶的業(yè)務(wù)操作行為。利用虛擬用戶，可以在Windows上同時產(chǎn)生成千上萬個用戶訪問。所以LoadRunner能極大的減少負(fù)載測試所需的硬件和人力資源。創(chuàng)建真實的負(fù)載Virtual users建立起后，我們可以設(shè)定具體的負(fù)載方案，業(yè)務(wù)流程組合和虛擬用戶數(shù)量。這主要是使用LoadRunner的Controller，通過不同的場景設(shè)置，可以組織起多用戶的測試方案，更好地對系統(tǒng)進(jìn)行全方位的測試。 LoadRunner 功能描述 LoadRunner包含很多組件，最為我們所使用的有Visual User Generator、Controller和Analysis，其中Virtual User Generator（虛擬用戶生成器）主要是用于錄制測試腳本；Controller（中央調(diào)度器）主要是通過場景設(shè)置控制模擬用戶個數(shù)和并發(fā)數(shù)，進(jìn)一步設(shè)置測試的調(diào)度方案，執(zhí)行腳本并記錄測試結(jié)果，包括缺陷報告和測試日志； Analysis（結(jié)果分析器）用于統(tǒng)計和分析測試結(jié)果，確定是否與發(fā)布的基準(zhǔn)要求相符合。 LoadRunner 測試步驟LoadRunner是一個很好使用的測試軟件，欲采用其完成相應(yīng)的測試，只需要完成以下四個步驟： 第一步：使用Virtual User Generator 創(chuàng)建腳本，具體為　　選擇協(xié)議（該軟件支持的協(xié)議有很錯，根據(jù)不同的測試程序選用不同的協(xié)議），接著創(chuàng)建腳本 　　錄制腳本，錄入過程選擇在action里 　　編輯腳本，因為其錄制的只是事務(wù)的一個分支 　　檢查修改腳本是否有誤，直至正確 第二步：使用Controller 來調(diào)度虛擬用戶，具體為　　選擇欲測試腳本，并創(chuàng)建場景　　設(shè)置機(jī)器虛擬用戶數(shù)，運行時間等 　　設(shè)置調(diào)度方案 　　如果模擬多機(jī)測試，設(shè)置Ip Spoofer 第三步：運行腳本 　　分析場景，盡力保持系統(tǒng)沒有別的程序在運行，這樣可以更精確地知道整個測試過程所占用的資源數(shù) 第四步：分析測試結(jié)果 TPC_C 基準(zhǔn)事務(wù)的實現(xiàn) TPC_C 基準(zhǔn)總述 TPC_C 簡介基準(zhǔn) TPC_C，即 TPC BnechmarkTM C，是 TPC(Transaction Processing Performance Council)委員會發(fā)布的數(shù)據(jù)庫測試基準(zhǔn)之一，該標(biāo)準(zhǔn)第一版于 1992年 7 月批準(zhǔn)并首次發(fā)布 [5]。TPC_C 是復(fù)雜聯(lián)