【正文】 stems, currently there are many popular databases such as DB2, Oracle, SQL Sever etc. The database system39。其中功能測(cè)試的目的是驗(yàn)證系統(tǒng)是否實(shí)現(xiàn)了用戶(hù)要求的所有功能要求；而性能測(cè)試的目的是驗(yàn)證軟件系統(tǒng)是否能夠達(dá)到用戶(hù)提出的性能指標(biāo)發(fā)現(xiàn)軟件系統(tǒng)中存在的性能瓶頸，最后起到優(yōu)化系統(tǒng)的目的?？刂颇Ｐ屯聞?wù)處理模型和數(shù)據(jù)庫(kù)模型組裝動(dòng)態(tài) SQL 語(yǔ)句，然后產(chǎn)生多個(gè)并發(fā)進(jìn)程模擬大量實(shí)際用戶(hù)訪問(wèn)數(shù)據(jù)庫(kù)，以測(cè)試數(shù)據(jù)庫(kù)的運(yùn)行狀況和性能。數(shù)據(jù)庫(kù)系統(tǒng)測(cè)試作為軟件測(cè)試的一個(gè)重要分支，在詳細(xì)闡述其之前，我們有必要對(duì)軟件測(cè)試進(jìn)行一個(gè)概述。其測(cè)試工具有主要用于評(píng)估測(cè)試各種不同系統(tǒng)參數(shù)下的數(shù)據(jù)庫(kù)負(fù)載情況的模塊化、跨平臺(tái)、多線程基準(zhǔn)測(cè)試工具 sysbench。比如當(dāng)一個(gè)應(yīng)用程序升級(jí)或是重新開(kāi)發(fā)，用戶(hù)便可設(shè)置單元測(cè)試用例，驗(yàn)證這個(gè)應(yīng)用程序的數(shù)據(jù)輸出在不同的版本間是否是一致的 [10]。第二章介紹數(shù)據(jù)庫(kù)性能測(cè)試的主要方法、內(nèi)容、主要測(cè)試工具LoadRunner，為課題的設(shè)計(jì)和實(shí)現(xiàn)奠定基礎(chǔ)。（一）負(fù)載測(cè)試負(fù)載測(cè)試是模擬實(shí)際軟件系統(tǒng)所承受的負(fù)載條件的系統(tǒng)負(fù)荷，通過(guò)不斷加載（如逐漸增加模擬用戶(hù)的數(shù)量）或其它加載方式來(lái)觀察不同負(fù)載下系統(tǒng)的響應(yīng)時(shí)間和數(shù)據(jù)吞吐量、系統(tǒng)占用的資源（如 CPU、內(nèi)存）等，以檢驗(yàn)系統(tǒng)的行為和特性，以發(fā)現(xiàn)系統(tǒng)可能存在的性能瓶頸、內(nèi)存泄漏、不能實(shí)時(shí)同步等問(wèn)題。它是通過(guò)一個(gè)包含了負(fù)載測(cè)試和壓力測(cè)試的過(guò)程，分析各種交易執(zhí)行指標(biāo)和資源監(jiān)控指標(biāo)來(lái)確定系統(tǒng)并發(fā)性能的過(guò)程。（三）、響應(yīng)時(shí)間響應(yīng)時(shí)間是可以判斷一個(gè)被測(cè)應(yīng)用系統(tǒng)是否存在性能瓶頸的最直觀的要素。 LoadRunner 的特點(diǎn) LoadRunner的具體特點(diǎn)表現(xiàn)為如下兩點(diǎn)：輕松創(chuàng)建虛擬用戶(hù)采用LoadRunner 的Virtual User Generator ，可以錄入我們需要測(cè)試腳本并進(jìn)行修改，進(jìn)一步可以很簡(jiǎn)便地創(chuàng)立起系統(tǒng)負(fù)載。 LoadRunner 測(cè)試步驟LoadRunner是一個(gè)很好使用的測(cè)試軟件，欲采用其完成相應(yīng)的測(cè)試，只需要完成以下四個(gè)步驟： 第一步：使用Virtual User Generator 創(chuàng)建腳本，具體為　　選擇協(xié)議（該軟件支持的協(xié)議有很錯(cuò)，根據(jù)不同的測(cè)試程序選用不同的協(xié)議），接著創(chuàng)建腳本 　　錄制腳本，錄入過(guò)程選擇在action里 　　編輯腳本，因?yàn)槠滗浿频闹皇鞘聞?wù)的一個(gè)分支 　　檢查修改腳本是否有誤，直至正確 第二步：使用Controller 來(lái)調(diào)度虛擬用戶(hù)，具體為　　選擇欲測(cè)試腳本，并創(chuàng)建場(chǎng)景　　設(shè)置機(jī)器虛擬用戶(hù)數(shù)，運(yùn)行時(shí)間等 　　設(shè)置調(diào)度方案 　　如果模擬多機(jī)測(cè)試，設(shè)置Ip Spoofer 第三步：運(yùn)行腳本 　　分析場(chǎng)景，盡力保持系統(tǒng)沒(méi)有別的程序在運(yùn)行，這樣可以更精確地知道整個(gè)測(cè)試過(guò)程所占用的資源數(shù) 第四步：分析測(cè)試結(jié)果 TPC_C 基準(zhǔn)事務(wù)的實(shí)現(xiàn) TPC_C 基準(zhǔn)總述 TPC_C 簡(jiǎn)介基準(zhǔn) TPC_C，即 TPC BnechmarkTM C，是 TPC(Transaction Processing Performance Council)委員會(huì)發(fā)布的數(shù)據(jù)庫(kù)測(cè)試基準(zhǔn)之一，該標(biāo)準(zhǔn)第一版于 1992年 7 月批準(zhǔn)并首次發(fā)布 [5]。 下圖說(shuō)明了 TPC_C 應(yīng)用環(huán)境的邏輯結(jié)構(gòu)：CustomersCompanyWarehouse1District10WarehouseWDistrict1 District23k1 2 30k圖 31 TPC_C 基準(zhǔn)邏輯結(jié)構(gòu)TPC_C的數(shù)據(jù)模型可描述為:a) 一個(gè)大型商品批發(fā)商擁有若干個(gè)分布在不同區(qū)域的商品庫(kù)。按照TPC的定義，流量指標(biāo)描述了系統(tǒng)在執(zhí)行Payment 、Orderstatus、Delivery 、StockLevel這四種交易的同時(shí)，每分鐘可以處理多少個(gè)NewOrder交易。PAYMENT 事務(wù)更新用戶(hù)的賬戶(hù)并反映出地區(qū)和倉(cāng)庫(kù)的銷(xiāo)售狀況。在本次測(cè)試過(guò)程中，采取的方案是通過(guò)設(shè)置不同的 Vuser 數(shù)以測(cè)試系統(tǒng)的在線用戶(hù)數(shù)，進(jìn)一步得到系統(tǒng)的 TPS、響應(yīng)時(shí)間等指標(biāo)，具體測(cè)試方案詳見(jiàn) 節(jié)。 text，size N 型。本項(xiàng)目的數(shù)據(jù)庫(kù)是 SQL Server 2022.，在數(shù)據(jù)庫(kù)的建立時(shí)使用的是 SQL 腳本建表，格式是如：圖 34 SQL 腳本示例如是將所有表項(xiàng)建立完畢，各個(gè)表之間通過(guò)外鍵進(jìn)行約束，這樣就構(gòu)成了TPC_C 測(cè)試基準(zhǔn)數(shù)據(jù)庫(kù)的整體結(jié)構(gòu)。比如random[,]產(chǎn)生的隨機(jī)數(shù)就為 100，000 個(gè)而 random[1,100]產(chǎn)生的隨機(jī)數(shù)個(gè)數(shù)為 100 個(gè)。倉(cāng)庫(kù)、地區(qū)、顧客的郵編號(hào) W_ZIP,D_ZIP,C_ZIP 通過(guò)以下機(jī)制產(chǎn)生：隨機(jī)產(chǎn)生一個(gè)長(zhǎng)度為 4 的字符串，然后在末尾加上‘11111’組成。 NEW ORDER（新訂單）事務(wù)的實(shí)現(xiàn)NEW ORDER 事務(wù)是本系統(tǒng)中的一個(gè)核心事務(wù)，是一個(gè)讀寫(xiě)型事務(wù)，執(zhí)行的頻率很高，因此要求系統(tǒng)的響應(yīng)時(shí)間必須盡可能小，以滿(mǎn)足在線用戶(hù)的需求。供貨倉(cāng)庫(kù) 99%的時(shí)間是直接從就近倉(cāng)庫(kù)中獲取，1%的時(shí)間是從遠(yuǎn)方倉(cāng)庫(kù)中獲取。 OL_AMOUNT=OL_QUANTITY*I_PRICE. 如果 I_DATA 和 S_DATA 都包含有 ORIGINAL 字符串，則 brandgeneric 被標(biāo)志為 B，否則標(biāo)志為 G。Payment 的 H_AMOUNT 是 到 的一個(gè)隨機(jī)數(shù)。一、數(shù)據(jù)輸入要求W_ID 是用戶(hù)輸入，其值只能為 1 或 2O_CARRIER_ID 是 1 到 10 的一個(gè)隨機(jī)數(shù)OL_DELIVERY_D 是當(dāng)前系統(tǒng)的時(shí)間二、事務(wù)執(zhí)行具體步驟： 在 NEW_ORDER 表里找到 NO_W_ID= W_ID 并且 NO_D_ID=D_ID的最小的 NO_O_ID，這代表的是未發(fā)貨的最老的歷史記錄（默認(rèn) NO_OID 最小的項(xiàng)） ，接著將 NEW_ORDER 表里對(duì)應(yīng)的這一行刪除。在 STOCK 表中選擇與條件(S_I_ID=OL_I_ID, S_W_ID=W_ID)相匹配的行，累加(S_QUANTITYthreshold)的行數(shù)。在 ORDER_LINE 表中選擇與條件（OL_W_ID=O_W_ID, OL_D_ID=O_D_ID, OL_O_ID=O_ID）相匹配的項(xiàng)，得到對(duì)應(yīng)的OL_ID_ID,OL_QUANTITY, OL_AMOUNT,OL_OL_DELIVERY_D 的值。依次將五個(gè)事務(wù)都錄入，并且每個(gè)事務(wù)都是一個(gè)獨(dú)立體，都有 START TRANSACTION 和 END TRANSACTION，這樣可以保證事務(wù)的執(zhí)行完整性。 測(cè)試場(chǎng)景設(shè)置性能測(cè)試過(guò)程中，結(jié)果的正確與否，場(chǎng)景設(shè)置占有很大的比例關(guān)系。具體各個(gè)事務(wù)的思考時(shí)間大小如下表所示：表 41 事務(wù)思考時(shí)間Keying/think times(in seconds)Trans. nameMin. Average MaxNew order / / /Payment / / / Order status / / / Delivery / / / Stock level / / / 在測(cè)試中我們選用的是平均值。本系統(tǒng)主要有五個(gè)獨(dú)立的事務(wù)，而對(duì)于每個(gè)事務(wù)的執(zhí)行平率，根據(jù) TPC_C 基準(zhǔn)，其有嚴(yán)格的配比關(guān)系，表現(xiàn)為：表 41 測(cè)試事務(wù)配比要求事務(wù)類(lèi)型 所占配比（%）Payment OrderStatus Delivery StockLevel NewOrder n/aNEW ORDER 事務(wù)沒(méi)有最低下限，其配比是所有是配比的剩余。 向 LoadRunner 里加載腳本并修改，執(zhí)行該腳本。其執(zhí)行過(guò)程可以用下圖進(jìn)行說(shuō)明：選擇事務(wù)1 、 支付2 、 新訂單3 、 發(fā)貨4 、 訂單狀態(tài)查詢(xún)5 、 庫(kù)存狀態(tài)查詢(xún)執(zhí)行所選事務(wù)輸入是否重新執(zhí)行事務(wù) （ Y / N ）Y退出程序N 選擇事務(wù)類(lèi)型 ，等待用戶(hù)輸入 輸出事務(wù)結(jié)果 ，等待用戶(hù)輸入圖 41 事務(wù)執(zhí)行流程但是考慮到將整個(gè)系統(tǒng)同時(shí)錄入，因?yàn)?LoadRunner 錄入過(guò)程只錄入程序執(zhí)行的過(guò)程，而這五個(gè)事務(wù)全部一起錄入會(huì)導(dǎo)致在 LoadRunner 里自編代碼的工作量很大，所以在腳本錄入過(guò)程中便采用各個(gè)事務(wù)分別錄入的方法，這樣可以減少代碼的修改量。令 N 為所選擇的行數(shù)，則得到其中第 N/2 行的 C_BALANCE, C_FIRST, C_MIDDLE, C_ID 的值。這個(gè)事務(wù)是只讀事務(wù)，執(zhí)行的頻率較低，對(duì)系統(tǒng)的響應(yīng)時(shí)間不做嚴(yán)格限制和要求。 情況二：當(dāng)顧客的查詢(xún)是按 C_LAST 時(shí)，從 CUSTOMER 查詢(xún)出符合C_W_ID,C_D_ID,C_LAST 的項(xiàng)，并從 N/2 以上的項(xiàng)中返回 C_ID, C_FIRST, C_MIDDLE, 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+=1. 如果 C_CREDIT=”BC”，那么 C_DATA 也得從 CUSTOMER 表中返回，且 C_ID, C_D_ID, C_W_ID, D_ID, W_ID 和 H_AMOUNT 等歷史信息要插入到C_DATA 域中，并且只是將這些內(nèi)容插入到 C_DATA 原有內(nèi)容的左邊，而C_DATA 的原有內(nèi)容右移，超過(guò) 500 的字符被移出到 C_DATA 域外。一、數(shù)據(jù)輸入要求地區(qū)編號(hào) D_ID 是 1 到 10 的一個(gè)隨機(jī)數(shù)，顧客 60%的時(shí)間是按 Last_name來(lái)搜尋，即搜尋條件為（C_W_ID,C_LAST）,而 40%的時(shí)間是按用戶(hù)編號(hào)來(lái)搜尋的，即(C_W_ID,C_D_ID,C_ID)，顧客貨物的供應(yīng)倉(cāng)庫(kù)有 85%的時(shí)間是本地供貨，15% 的時(shí)間是遠(yuǎn)方倉(cāng)庫(kù)供貨。二、 事務(wù)的實(shí)現(xiàn)步驟 從 WAREHOUSE 表中找出與輸入的 W_ID 相等的項(xiàng)并返回 WTAX 從 DISTRICT 表中找到 D_W_ID=W_ID,D_ID 與隨機(jī)生成的 D_ID 相等的項(xiàng)，并返回 D_TAX，D_NEXT_O_ID 即下一個(gè)可用的訂單號(hào)返回并且加一。事務(wù)的實(shí)現(xiàn)分為以下部分：一、 數(shù)據(jù)輸入要求Warehouse ID 要求前后都一致，是用戶(hù)輸入的。表 31 各表數(shù)量關(guān)系圖Table Name Cardinality Typical 3 Row Typical 3 Table(in rows) Length (in bytes) Size (in 1,000 bytes)WAREHOUSE 1 89 DISTRICT 10 95 CUSTOMER 30k 655 19,650HISTORY 30k 46 1,380ORDER 30k 24 720NEWORDER 9k 8 72ORDERLINE 300k 54 16,200STOCK 100k 306 30,600ITEM 100k 82 8,200通過(guò)以上的初始化，數(shù)據(jù)的加載就算告一段落了，接下來(lái)的工作就是把各個(gè)事務(wù)進(jìn)行設(shè)計(jì)和實(shí)現(xiàn)。C_LAST 是 Customer 表中的一項(xiàng)，其產(chǎn)生采用以下機(jī)制：下表中的每一個(gè)數(shù)都對(duì)應(yīng)著一個(gè)字符串，隨機(jī)生成 0 到 999 的一個(gè)是，C_LAST 將由隨機(jī)數(shù)每一位所對(duì)應(yīng)的字符串拼接而成。 [8]在本項(xiàng)目中數(shù)據(jù)的加載主要是通過(guò) C編寫(xiě)代碼實(shí)現(xiàn)的。，N digits 型。由于本次測(cè)試采用的是單機(jī)測(cè)試，并且主機(jī)的配置不高，而實(shí)際每增加一個(gè)倉(cāng)庫(kù)，數(shù)據(jù)庫(kù)就有數(shù)以萬(wàn)計(jì)的數(shù)據(jù)加入，這將會(huì)花費(fèi)很多時(shí)間，所以Warehouse 的數(shù)目就做出限制，只有 warehouse1 和 warehouse2.具體的表如下圖所示：W a r e h o u s eW _ I D 2 * W u n i q u e I D s W _ N A M E v a r i a b l e t e x t , s i z e 1 0 W _ S T R E E T _ 1 v a r i a b l e t e x t , s i z e 2 0 W _ S T R E E T _ 2 v a r i a b l e t e x t , s i z e 2 0 W _ C I T Y v a r i a b l e t e x t , s i z e 2 0 W _ S T A T E f i x e d t e x t , s i z e 2 W _ Z I P f i x e d t e x t , s i z e 9 W _ T A X s i g n e d n u m e r i c ( 4 , 4 )W _ Y T D s i g n e d n u m e r i c ( 1 2 , 2 )D i s t r i c tD _ I D 2 0 u n i q u e I D sD _ W _ I D 2 * W u n i q u e I D s D _ N A M Ev a r i a b l e t e x t ,