專利名稱：安全數(shù)據(jù)庫管理系統(tǒng)測試用例生成方法
技術領域：
本發(fā)明屬于計算機軟件的測試與評估領域，主要涉及安全數(shù)據(jù)庫管理系統(tǒng)(SecureDataBase Management System，簡稱SDBMS)的測試與評估，更確切地是基于SDBMS安全策略模型的高安全等級安全數(shù)據(jù)庫管理系統(tǒng)測試用例生成方法。
背景技術：
軟件測試是檢驗軟件實現(xiàn)與其功能規(guī)約之間的一致性、并保證軟件質(zhì)量的一種有效手段。在基于安全評估標準實現(xiàn)信息安全產(chǎn)品評估的過程中，評估方對安全系統(tǒng)的安全功能實施全面、系統(tǒng)的第三方測試是評估中一個不可缺少的重要環(huán)節(jié)。但由于多種原因，目前獨立的安全功能測試在我國安全數(shù)據(jù)庫管理系統(tǒng)評估中并沒有占據(jù)重要的地位。其關鍵問題在于如何實現(xiàn)測試用例的組織與設計，目前缺乏一種系統(tǒng)的方法快速生成針對特定信息安全產(chǎn)品/系統(tǒng)(包括SDBMS)的測試用例集。
由于軟件著作權利等限制，第三方獨立測試大多采用基于規(guī)約的測試。系統(tǒng)規(guī)約來源于系統(tǒng)需求，它完整地定義了系統(tǒng)的行為?；谝?guī)約的測試可以確定輸入輸出之間的影響關系，有效保證軟件功能測試的全面性。形式化規(guī)約是系統(tǒng)規(guī)約的一種更為精確的表達形式，能更好地消除系統(tǒng)需求中的二義性。同時，形式化規(guī)約提供一種規(guī)范的表達形式，因而便于對其進行自動化處理。依據(jù)形式化安全規(guī)約自動生成測試用例將大大的減少測試工作量。目前存在的一種做法是，通過功能規(guī)約建模，按照一定的重寫規(guī)則劃分測試空間，自動生成測試用例。
然而，上述方法在針對SDBMS系統(tǒng)的測試評估中直接應用會導致一些特殊問題上述形式化功能規(guī)約重寫規(guī)則(或是啟發(fā)式)純粹只與語法相關，與語義無關，因此產(chǎn)生的測試用例缺乏針對性，難于發(fā)現(xiàn)具體系統(tǒng)中的問題。另外，SDBMS系統(tǒng)中每個操作的輸入變量空間有限，但系統(tǒng)內(nèi)部狀態(tài)空間十分龐大，幾乎是無限的。上述方法只適用于較小規(guī)模的系統(tǒng)，也不能直接應用于SDBMS系統(tǒng)的測評。
更為重要的是，對于包括SDBMS在內(nèi)的大多數(shù)信息安全產(chǎn)品，系統(tǒng)規(guī)約并不能真實地反映現(xiàn)實系統(tǒng)的行為。因為系統(tǒng)中的操作除了要完成其預定的功能外，同時必須滿足安全策略要求。安全策略描述一個信息安全產(chǎn)品(或系統(tǒng))所要保護的對象，以及采取的所有保護措施。存在不同抽象層次的安全策略，如系統(tǒng)的安全目標，與系統(tǒng)的安全策略模型等。高安全等級SDBMS中存在形式化的安全策略模型。
另一種做法是通過對非形式化的安全目標建模，建立精確的形式化安全功能模型。這種做法存在的問題是因為存在測評人員的人工建模過程，所以模型與最終的測試結果嚴重依賴于建模人員對開發(fā)者提供的非形式化的安全目標的正確理解。另外，安全目標中的安全策略粒度比較粗，需要測評人員將安全策略中的主客體與實際系統(tǒng)對象一一對應。

發(fā)明內(nèi)容
針對上述問題，本發(fā)明的目的在于提供一種基于SDBMS安全策略模型的測試用例生成方法。該測試方法的基本前提要求包括1.一個SDBMS安全策略模型該模型的正確性經(jīng)形式化工具證明。一個典型的形式化SDBMS安全策略模型中具備以下要素(1)狀態(tài)集(STATES)，描述系統(tǒng)合法狀態(tài)；(2)安全公理集(ANXIOMS)，安全公理是模型中定義的一組性質(zhì)，某個系統(tǒng)狀態(tài)S是安全的當且僅當它滿足這些性質(zhì)；(3)操作集(OPS)，系統(tǒng)狀態(tài)的轉換由系統(tǒng)操作實現(xiàn)，每個操作都是受控的，只有在其產(chǎn)生一個安全狀態(tài)時，才允許其執(zhí)行，即它滿足模型中的所有性質(zhì)；(4)安全定理集(THEOREMS)，可以證明的抽象安全模型所滿足的一些安全性質(zhì)。
2.待測SDBMS產(chǎn)品一套該產(chǎn)品依據(jù)前述SDBMS安全策略模型實現(xiàn)，兩者經(jīng)開發(fā)者確認保持一致。
3.待測SDBMS的高層規(guī)約，以及該產(chǎn)品的具體接口定義文檔。
本發(fā)明所提供的基于SDBMS安全模型的測試用例生成方法是基于以下的構思形式化安全策略模型是生成SDBMS安全功能測試用例的基礎，生成測試用例方法的基本思想是確定測試狀態(tài)空間，并對測試空間(包括輸入狀態(tài)空間以及中間狀態(tài)空間)進行劃分。因為根據(jù)測試理論中的統(tǒng)一假設(unified hypothesis)思想，每個劃分中的所有輸入與狀態(tài)的表現(xiàn)應該相同。因此在每個劃分中選取其中的一個或幾個實例進行測試。
本方法中包括兩類測試空間的劃分策略一類是子域劃分。將測試空間劃分成測試子域。每個子域由一個抽象的測試模板描述；另一類是類型劃分。將變量所屬的類型值劃分，測試模板被實例化為具體的測試用例。
具體來說，該方法包括以下四個步驟步驟一生成測試規(guī)約。因為生成測試用例的前提是精確、完整的形式化測試規(guī)約，所以在步驟一中必須依據(jù)描述操作功能的形式化規(guī)約與操作的安全公理要求等生成測試規(guī)約。
步驟二生成測試模板。步驟二通過測試規(guī)約重寫對測試規(guī)約所限定的測試空間進行子域劃分。子域間互不相交，并且每個測試子域對應一個測試模板。
步驟三類型劃分。步驟三提供與步驟二不同的劃分方式——類型劃分。類型劃分在測試子域的基礎上進一步劃分測試空間。
步驟四生成測試向量。綜合上述兩種劃分方式，步驟四中檢驗各測試子域，并將其實例化，生成相應的測試向量，構成一個完整的測試用例。
下面以Z語言描述的SDBMS模型為例說明上述四個步驟的內(nèi)容，該步驟思想可以自然地應用于其他形式化語言描述的SDBMS模型，此處Z語言僅用于說明本發(fā)明內(nèi)容，對本發(fā)明不構成任何限制。
步驟一生成測試規(guī)約SDBMS系統(tǒng)中一個操作的測試規(guī)約全面、準確地反映了該操作的行為。具體來說，SDBMS安全模型操作集中某個成員操作op的測試規(guī)約由以下三部分構成(1)操作op在SDBMS模型中的基礎定義操作op在SDBMS模型中的基礎定義的聲明部分包括操作的輸入變量集合ins，輸出變量集合outs，以及操作前后的中間狀態(tài)變量集合Δstate。操作基礎定義中的謂詞部分可按語義分為兩類一類是操作op發(fā)生的預條件約束，標記為P；另一類是該操作所導致系統(tǒng)狀態(tài)變化，標記為Q。它們的含義是當且僅當預條件約束P滿足時，操作op執(zhí)行，正確執(zhí)行后導致系統(tǒng)的狀態(tài)變化滿足Q。例如，以Z語言shcema形式表示的操作op的基礎定義為操作的形式化定義必須滿足一致性要求與完整性要求。一致性要求指操作的預條件約束是可滿足的；完整性要求指不存在任何遺留的定義域，它的操作結果沒有定義。若在操作基礎定義上補充操作約束不滿足時的描述，增添如上述定義操作non_op，Success，與Fail。則構成如下形式的操作 因為pre op_full＝true，操作op_full為一個一致且完整的操作。
(2)SDBMS模型中與操作相關的安全公理(集)SDBMS安全策略模型中的大多數(shù)操作都必須滿足特定的安全公理(集)。例如某個SDBMS安全策略模型要求數(shù)據(jù)對象上的插入、刪除操作應該滿足基于角色的訪問控制模型中的靜態(tài)約束與動態(tài)約束。操作op必須滿足的安全公理集表示為函數(shù)axioms(op)。安全公理通常表現(xiàn)為謂詞約束，它與系統(tǒng)定義的安全策略直接相關，反映系統(tǒng)所要求的安全性質(zhì)。本方法將安全性質(zhì)約束與操作自身語義約束區(qū)分，使得SDBMS安全策略模型結構更清晰。
加入安全公理約束后的操作op的基礎定義及補充定義分別調(diào)整為op′與non_op′ 類似的，加入安全公理約束后完整的操作表示為 (3)系統(tǒng)相關中間狀態(tài)變量中存在的固定約束實際上，操作op除了受預條件P約束外，還必須滿足一些與操作非直接相關的約束。這些約束限制系統(tǒng)中間變量之間的關系，只有滿足這些固定約束的狀態(tài)才可能是一個合法的系統(tǒng)狀態(tài)。因此操作op發(fā)生的前狀態(tài)隱含著這些約束。若以符號TCB表示這些固定約束，則操作規(guī)約實際上應該是 操作op的基礎定義及補充定義可進一步調(diào)整為op″與non_op″
完整的操作表示為 因為系統(tǒng)任何狀態(tài)都必須滿足TCB約束，狀態(tài) TCB在實際系統(tǒng)中是不可達的。若SDBMS安全模型中存在類似的初始化定理并予以證明，則考慮到操作的完整性要求，操作op的完整定義仍然等價于op_full′。
綜上所述，對于SDBMS安全策略模型中的操作op，根據(jù)是否存在經(jīng)證明的初始化定理，上述三部分組成其測試規(guī)約op_test可以最終表示為如下形式op_test=^op_full′′]]>或op_test=^op_full′]]>步驟二生成測試模板操作的測試規(guī)約準確地描述了操作的行為特征，同時也限定了該操作的測試空間。但在生成針對該操作的測試用例前，必須先將該測試空間劃分，成為一系列互不相交的測試子域空間。我們按照特定的重寫規(guī)則對測試規(guī)約中的謂詞約束部分進行等價變換，將其化簡成析取范式(DNF)形式，從而將操作op的測試規(guī)約op_test等價表示為一組測試模板。
等價變換所使用的重寫規(guī)則無法一一列舉，其中主要的幾個規(guī)則包括(1)存在量詞消除規(guī)則(單點規(guī)則) (2)全稱量詞消除規(guī)則 (3)分配律規(guī)則
重寫后的測試規(guī)約表示為n個測試模板的析取式 其中第i個測試模版op_templatei為單純合取式，表示為 按照所代表的語義分為三類pi表示第i個測試模版的約束，它是一個謂詞或多個謂詞的合取式， qi表示操作執(zhí)行后第f個測試模版的狀態(tài)變化， ri為第i個測試模版的輸出結果集， 生成的測試模板集合{op_templatei}，(1≤i≤n)滿足下述兩點性質(zhì)①i，j1..n·i≠j|pi∧pj＝false。
性質(zhì)①說明測試模板集合每個測試模板的約束之間無交集，生成的測試模板將測試空間劃分成互不相交的一組測試子域，每個測試模板代表一個測試子域。性質(zhì)②說明測試模版集合是完整的，覆蓋了被測操作的所有測試空間。即該操作的預條件為永真式，pre op_test＝true。
需要指出的是，上述規(guī)則應用次序與數(shù)目可能不同，給定的測試規(guī)約經(jīng)過等價變換后得到的析取范式(DNF)不是唯一的。并且等價變換可能會為操作引入一些間接輸入變量。
步驟三類型劃分大多數(shù)情況下，步驟二中生成的測試模板的數(shù)目非常有限，步驟三通過類型劃分對每個測試模板進行啟發(fā)式等價變換，進一步細分測試空間。首先澄清一下與類型劃分概念。
設A是一個非空類型，如果存在一個A的子集族π(πP(A))滿足以下條件(1) (2)π中任意兩個元素不交(3)π中所有元素的并集等于A則稱π為類型A的一個劃分，且稱π中的元素為劃分塊。π中所有元素的并集稱為類型A的π劃分表示。
SDBMS安全策略模型上的劃分歸結為下述四種情況。
情況1預設值劃分若類型T中存在一系列特殊預設值s1，s2，…sn，則類型T的預設值劃分將類型劃分π為π＝{{s1)，{s2}，…，{sn}，{tT|t≠s1∧t≠s2∧…∧t≠sn}}，根據(jù)劃分π，類型T可表示為T＝{s1}∨{s2}∨…{sn}∨{tT|t≠s1∧t≠s2∧…∧t≠sn}。
類型中的特殊值是系統(tǒng)預設，與該類型中的其他值相比存在較為特殊的意義，應該單獨測試。并且由于這些值不存在交集，所以類型中每個特殊值都是類型空間劃分中的一個子集，滿足劃分的定義要求。
情況2函數(shù)值劃分若存在由類型T到類型V上的函數(shù)fT→V，且類型V為有限集，ran(f)＝{v1，v2，…vn)。則類型T的函數(shù)值劃分π為π＝{{tT|f(t)＝v1}，{tT|f(t)＝v2}，…，{tT|f(t)＝vn}}。若類型V雖為無限集，但存在重要的劃分π0＝{{s1}，{s2}，…，{sn}}，則類型T存在擴展的函數(shù)值劃分π′＝{{tT|f(t)∈s1)，{tT|f(t)∈s2}，…，{tT|f(t)∈sn}}。
SDBMS模型中每個類型上都可能存在一些函數(shù)，函數(shù)值相同的一組變量代表具備某種相同性質(zhì)的一類值，而不同的函數(shù)值在模型中可能對應不同的行為，因此可以根據(jù)不同的函數(shù)取值將類型中的變量劃分為不同的子集進行測試。
情況3集合劃分若類型T上存在多個數(shù)據(jù)集合，分別表示為ts1，ts2，…tsn，即對于任何1≤i≤n，滿足tsi＝ρ(T)。則類型T的集合劃分可以如下遞歸表示1) 2)對于任何1＜i≤n 3)類型T最終可以表示為T＝T_test(n)。
與函數(shù)類似，SDBMS模型中類型上每個數(shù)據(jù)集合代表具備某種相同性質(zhì)的一類值，集合劃分最大限度的考慮了這些性質(zhì)的組合情況。由于大多數(shù)數(shù)據(jù)集合是構成系統(tǒng)狀態(tài)的一部分，通常集合劃分只適用于輸入變量。
情況4數(shù)據(jù)劃分這種情況涉及一些常見的數(shù)據(jù)類型，如整數(shù)類型，自然數(shù)類型，布爾型等等。這些數(shù)據(jù)類型的特殊取值是與類型相關的固有特殊值，例如，布爾類型上存在的數(shù)據(jù)劃分為{true，false}。數(shù)據(jù)劃分形式上與預設值劃分十分近似，主要的區(qū)別在于數(shù)據(jù)劃分應用于成員己知的類型，而預設值劃分應用于成員數(shù)目與內(nèi)容不確定的類型。
理論上說，若某類型上存在函數(shù)則應該采用函數(shù)劃分；若存在集合則應該采用集合劃分；依此類推。若同一個類型同時存在上述多種劃分，則需要計算它們的綜合劃分。綜合劃分的計算取決于這些劃分之間的關系。若劃分A中的任一劃分塊與劃分B中的任一劃分塊相交，稱兩個劃分正交類關系；同一個類型上的正交類關系的兩個劃分的綜合劃分結果為所有分屬A、B的劃分塊之間的交集的并集。若劃分A中的任一劃分塊都屬于劃分B中的某個劃分塊，稱兩者間存在重疊類關系。重疊類關系的兩個劃分的綜合劃分等價于B的劃分。還有一類介于正交類與重疊類之間，即部分劃分塊相交，部分劃分塊重疊。該類關系綜合劃分計算也是兩種的綜合。
可以想象若某個類型上存在的正交類劃分較多，且每個劃分中包含大量的劃分塊，則很有可能出現(xiàn)測試空間劃分的組合爆炸。因此需要對劃分應用某些原則進行取舍。此處我們給出了兩種正交類劃分取舍原則(1)優(yōu)先m-選-n原則(m≥n)。若類型T上存在m個正交劃分πi(1≤i≤m)，將其按照重要性非降次序排列，優(yōu)先m-選-n原則計算其中前n個劃分的綜合劃分。
類型T按不同的劃分可分為表示為T_testi(1≤i≤m)，其長度為|πi|。按照重要性非降次序排列后，前n個劃分為πi(1≤i≤n)。類型T上優(yōu)先m-選-n原則的綜合劃分P為 綜合劃分的長度最大為num=Π1≤i≤n(|πi|),]]>其內(nèi)容為 (partioni∈πi)(2)正交m-選-n原則(m≥n)。若類型T上存在m個正交劃分πi(1≤i≤m)，正交m-選-n原則計算的綜合劃分包含其中任何n個劃分的綜合劃分的劃分塊。
類型T按不同的劃分可分為表示為T_testi(1≤i≤m)，其長度為|πi|。按照劃分長度非遞增順序排列后，前n個的劃分記為πi(1≤i≤n)。令P表示類型T上正交m-選-n原則的綜合劃分。P′表示類型T上任何n個劃分的綜合劃分，P′中的任何一個劃分塊p′i(p′i∈P′)，在綜合劃分P中至少存在一個劃分塊pi(pi∈P)，滿足pjp′i。
將類型T上正交劃分的m-選-n取舍原則的綜合劃分表示成析取范式。綜合劃分的長度為num=Π1≤i≤n(|πi|).]]>其內(nèi)容為 (partioni∈πi)計算出的綜合劃分既可以直接應用于對輸入變量的劃分，也可以間接的應用于內(nèi)部狀態(tài)空間的劃分。因為歸根結底，內(nèi)部狀態(tài)是由內(nèi)部變量集合及其所對應的取值構成。
步驟四生成測試向量實際上SDBMS模型中的被測操作的測試空間劃分是步驟二所述的子域劃分與步驟三所述的類型劃分的綜合。一個完整的測試向量是待測SDBMS產(chǎn)品測評的依據(jù)。具體的說，測試向量是一組向量之和，即由輸入向量、當前狀態(tài)向量、輸出向量、與狀態(tài)變化向量構成的四元組(IN，pre_STATE，OUT，post_STATE)。
輸入向量由操作op的輸入變量集與每個變量取值構成，輸入變量取值依賴于具體的測試模板與類型劃分塊，它是測試空間劃分的實例化。除輸入向量之外，操作op的執(zhí)行結果還取決于與測試時系統(tǒng)內(nèi)部狀態(tài)變量的值，只有在已知系統(tǒng)狀態(tài)下才能確定某輸入向量所產(chǎn)生的輸出向量與狀態(tài)變化向量的值。對于某個內(nèi)部狀態(tài)，某個類型劃分塊與測試模板之間的關系可能是三種劃分塊完全滿足測試模板，即劃分塊中任選一個成員都可以作為劃分實例化輸入；劃分塊完全不滿足測試模板，即劃分塊中的任何一個成員都無法滿足測試模板；或劃分塊部分滿足測試模板。即劃分塊中的部分成員可滿足測試模板，部分無法滿足。此時結果是否滿足測試模板依賴于具體的輸入。
雖然所有的內(nèi)部狀態(tài)變量最終可歸結為單類型集合，復合類型集合，與類型函數(shù)等幾種，也可以通過類型劃分方法對其進行劃分，但存在兩個問題一是由于內(nèi)部狀態(tài)變量的數(shù)目過大，這種劃分將導致狀態(tài)爆炸。二是狀態(tài)的可控性問題，并不是任何合法的狀態(tài)都是可達的。即使是可達狀態(tài)，計算出路徑也是一個NP問題。因此，我們選取某些特殊已知狀態(tài)為測試預設狀態(tài)，例如包括初始狀態(tài)，以及與間接輸入類型相關的狀態(tài)集(必須是某己測操作的后狀態(tài))。具體的狀態(tài)生成、選擇及遍歷方法在現(xiàn)有技術文獻中已有大量詳細的記載，本領域的一般技術人員都能夠了解，因此本說明書中就不再具體解釋。
對于測試模板 若給定某輸入向量IN＝(INs，VALs)，與系統(tǒng)狀態(tài)pre_STATE，可以計算出邏輯變量(pk∧pre_STATE)[VALs/INs]的值，若其為真，則該測試用例的預期輸出結果為rk，狀態(tài)變化為qk；生成的測試向量為(IN，pre_STATE，rk，qk)。否則不生成測試用例。因為pre op_test＝true，所以對于任何一個狀態(tài)與輸入向量，不論是操作成功或是失敗的，必然有一個測試模板使該邏輯變量為真，從而生成相應的測試向量。
本發(fā)明的技術效果在于，本發(fā)明首次提出了一種用于生成安全數(shù)據(jù)庫管理系統(tǒng)測試用例的系統(tǒng)化、可操作的方法，有助于對該類系統(tǒng)的安全功能進行科學、全面、準確的測試。該方法以被測系統(tǒng)的安全模型為依據(jù)，測試的結果具有完備性、科學性、可重復性和內(nèi)在一致性。與現(xiàn)行的手工隨機測評方式相比，其能更好地發(fā)現(xiàn)系統(tǒng)實現(xiàn)的缺陷，大幅度提高了測試質(zhì)量。該方法結合形式化輔助工具使用，能夠減少測試過程中的重復勞動，降低生成大量測試用例所付出的代價，有利于實現(xiàn)測試自動化。
具體實施例方式
下面以中國科學院軟件研究所信息安全國家重點實驗室研發(fā)的LOIS安全數(shù)據(jù)庫管理系統(tǒng)為例，詳細說明本發(fā)明提供的安全數(shù)據(jù)庫管理系統(tǒng)測試用例生成方法。
該系統(tǒng)的SDBMS模型中自主授權相關的操作有兩種模式一種是直接授權給用戶，另一種是先授權給角色，再由用戶激活角色。直接授權操作GrantPermToUser是管理操作，要求被授權的用戶存在，未被授予過該權限。它依賴于多個操作，如創(chuàng)建用戶的操作、創(chuàng)建安全標簽的操作、創(chuàng)建數(shù)據(jù)對象的操作、連接操作等。在執(zhí)行對該操作的測試之前，應該確保已經(jīng)執(zhí)行過對以上操作的測試。并且系統(tǒng)中限定任何類型用戶不能向系統(tǒng)管理員、安全管理員和審計管理員授權。該操作改變了系統(tǒng)狀態(tài)中的訪問控制矩陣，其具體描述如下
補充完整性后操作規(guī)約為 操作GrantPermToUser應滿足公理GrantPermToUser_axiom，即授權者曾經(jīng)被授予該權限，并且被允許傳播該權限或者授權者是該對象特權的屬主。所有對象特權的分類如下dbOwnerPrivs＝＝{ConnectDatabase，CreateDomain，CreateTable，CreateView}dmOwnerPrivs＝＝{CreateonDomain，DroponDomain，UseDomain，DropDomain}tbOwnerPrivs＝＝{CreateRule，DropRule，SelectTable，Insert，Delete，DropTable}viOwnerPrivs＝＝{SelectView，DropView}公理GrantPermToUser_axiom的形式化描述為Transition·GrantPermToUsercur-trans-class(T)＝osi-class(o？)∧(∃g:USERS·(trans-user(T,o ,p ,g,true)∈access-matrix))]]>∨(owner(database-osi(session-database(trans-session(T))))＝trans-user(T)∧p？∈dbOwnerPrivs) 經(jīng)過步驟一后，操作GrantPermToUser的測試規(guī)約test_GrantPermToUser完整的表達式為
test_GrantPermToUser=^GrantPermToUser_full′]]> ((﹁GrantPermToUser﹁GrantPermToUser_axiom)∧Fail))對測試規(guī)約應用重寫規(guī)則并變換成析取范式形式。其中操作成功部分共有8個測試模版，分別為
(Transition·cur-trans-class(T)＝osi-class(o？)∧(∃g:USERS·(trans-user(T),o ,p ,g,true)∈access-matrix)]]>∧((owner(database-osi(session-database(trans-session(T))))＝trans-user(T))∧p？∈dbOwnerPrivs)∧u？∈user-exists∧﹁user-adm(u？)∧o？∈osi-exists∧(u ,o ,p ,trans-user(T),a )∉access-matrix]]>∧access-matrix′＝access-matrix∪{(u？，o？，p？，trans-user(T)，a？)}∧re！＝ok)∨(Transition·cur-trans-class(T)＝osi-class(o？)∧(∃g:USERS·(trans-user(T),o ,p ,g,true)∈access-matrix)]]>∧(∃d:DOMAINS·domain-osi(d)=o )]]>∧owner(o？)＝trans-user(T)∧p？∈dmOwnerPrivs∧u？∈user-exists∧﹁user-adm(u？)∧o？∈osi-exists∧(u ,o ,p ,trans-user(T),a )∉access-matrix]]>∧access-matrix′＝access-matrix∪{(u？，o？，p？，trans-user(T)，a？)}∧re?。給k)∨(Transition·cur-trans-class(T)＝osi-class(o？)∧(∃g:USERS·(trans-user(T),o ,p ,g,true)∈access-matrix)]]>∧(∃t:MREAL-IDS·real-osi(t)=o )]]>∧owner(o？)＝trans-user(T)∧p？∈tbOwnerPrivs∧u？∈user-exists∧﹁user-adm(u？)∧o？∈osi-exists∧(u ,o ,p ,trans-user(T),a )∉access-matrix]]>∧access-matrix′＝access-matrix∪{(u？，o？，p？，trans-user(T)，a？)}∧re！＝ok)∨(Transition·cur-trans-class(T)＝osi-class(o？)∧(∃g:USERS·(trans-user(T),o ,p ,g,true)∈access-matrix)]]>∧(∃t:MVIEW-IDS·view-osi(t)=o )]]>∧owner(o？)＝trans-user(T)∧p？∈viOwnerPrivs∧u？∈user-exists∧﹁user-adm(u？)∧o？∈osi-exists∧(u ,o ,p ,trans-user(T),a )∉access-matrix]]>∧access-matrix′＝access-matrix∪{(u？，o？，p？，trans-user(T)，a？)}∧re！＝ok)
∨(Transition·cur-trans-class(T)＝osi-class(o？)⫬(∃g:USERS·(trans-user(T),o ,p ,g,true)∈access-matrix)]]>∧((owner(database-osi(session-database(trans-session(T))))＝trans-user(T))∧p？∈dbOwnerPrivs)∧u？∈user-exists∧﹁user-adm(u？)∧o？∈osi-exists∧(u ,o ,p ,trans-user(T),a )∉access-matrix]]>∧access-matrix′＝access-matrix∪{(u？，o？，p？，trans-user(T)，a？)}∧re?。給k)∨(Transition·cur-trans-class(T)＝osi-class(o？)∧⫬(∃g:USERS·(trans-user(T),o ,p ,g,true)∈access-matrix)]]>∧(∃d:DOMAINS·domain-osi(d)=o )]]>∧owner(o？)＝trans-user(T)∧p？∈dmOwnerPrivs∧u？∈user-exists∧﹁user-adm(u？)∧o？∈osi-exists∧(u ,o ,p ,trans-user(T),a )∉access-matrix]]>∧access-matrix′＝access-matrix∪{(u？，o？，p？，trans-user(T)，a？)}∧re?。給k)∧(Transition·cur-trans-class(T)＝osi-class(o？)∧⫬(∃g:USERS·(trans-user(T),o ,p ,g,true)∈access-matrix)]]>∧(∃t:MREAL-IDS·real-osi(t)=o )]]>∧owner(o？)∈trans-user(T)∧p？∈tbOwnerPrivs∧u？∈user-exists∧﹁user-adm(u？)∧o？∈osi-exists∧(u .o ,p ,trans-user(T),a )∉access-matrix]]>∧access-matrix′＝access-matrix∪{(u？，o？，p？，trans-user(T)，a？)}∧re！＝ok)∨(Transition·cur-trans-class(T)＝osi-class(o？)∧⫬(∃g:USERS·(trans-user(T),o ,p ,g,true)∈access-matrix)]]>∧(∃t:MVIEW-IDS·view-osi(t)=o )]]>∧owner(o？)＝trans-user(T)∧p？∈viOwnerPrivs∧u？∈user-exists∧﹁user-adm(u？)∧o？∈osi-exists∧(u ,o ,p ,trans-user(T),a )∉access-matrix]]>∧access-matrix′＝access-matrix∪{(u？，o？，p？，trans-user(T)，a？)}∧re?。給k)上例中第四個測試模版補充完整后，可以表示為如下形式
test_template4=^[signature|cur-trans-class(T)=osi-class(o )]]>∧(∃t:MREAL-IDS·real-osi(t)=o )]]>∧owner(o？)＝trans-user(T)∧p？∈tbOwnerPrivs∧u？∈user-exists∧﹁user-adm(u？)∧o？∈osi-exists∧(u ,o ,p ,trans-user(T,)a )∉access-matrix]]>∧access-matrix′＝access-matrix∪{(u？，o？，p？，trans-user(T)，a？)}∧re！＝ok]可以對測試模版中的謂詞進一步化簡，表示成標準形式。下面以owner(o？)＝trans-user(T)為例，解釋細化過程。
(owner(o？)＝trans-user(T))∧TCB ⇔(∃u1:USERS·owner(o )=u1]]>∧trans-user(T)＝u1∧dom owner∈osi_exist∧dom tran-user∈tran_exist∧ran owner∈user_exist∧ran tran-user∈user_existu1∈USERS∧o？∈osi_exist∧u1∈user_exist∧T∈tran_exist∧owner(o？)＝u1∧trans-user(T)＝u1u1∈user_exist∧o？∈osi_exist∧T∈tran_exist 模板4中的函數(shù)owner、trans-user、osi-class、cur-trans-class、user-admin等均可以以類似方法再細化。將測試模版4生成的所有函數(shù)細化后得到的標準形式如下
依據(jù)步驟二要求，該模板可以表示為 按語義及表達形式可以區(qū)分出操作輸入應滿足的約束為 ∧t∈real_exist∧clss∈CLASSES∧p？∈tbOwnerPrivs ∧u？∈user_exist∧u？≠sysadmin∧u？≠audadmin∧u？≠secadmin ∧(u ,o ,p ,u1,a )∉access-matrix]]>操作導致的狀態(tài)變化為q4=^access-matrix′=access-matrix∪{(u ,o ,p ,u1,a )}]]>操作導致的輸出結果為r4=^re!=ok]]>其中，直接輸入變量為o？，p？，u？，a？，分別屬于類型OSI，PRIVILEGES，USERS，與BOOLEAN。間接輸入變量為T，u1，t，clss，分別屬于類型TRANSACTIONS，USERS，TUPLES與CLASSES。直接輸出變量re！，間接輸出變量access-matrix。
在操作模板確定后，接下來針對輸入變量類型確定應用類型上的劃分。其中輸入變量u？表示被授權的用戶，屬于類型USERS。該類型上存在三個特殊值，分別為系統(tǒng)管理員sysadmin，審計管理員audadmin，與安全管理員secadmin。因此類型USERS上的特殊值劃分為π0＝{u＝sysadm，u＝secadm，u＝audadm，u≠sysadm∧u≠Sec adm∧u≠audadm}。劃分塊數(shù)目為4。
類型USERS上存在四個函數(shù)，分別為user-admUSERS-|→BOOLEAN，值域為{true，false}user-statusUSERS-|→BOOLEAN，值域為{true，false}user-kindUSERS-|→SKIND，值域為{Sys，See，Aud，Common}user-classUSERS-|→CLASSES，值域特殊值為{SysHigh，SysLow，Trusted}。
類型USERS上的四個函數(shù)劃分分別為π1＝(user-adm(u)true，user_adm(u)＝false}，π2＝{user_status(u)＝true，user-status(u)＝false}，π3＝{user_kind(u)＝sys，user_kind(u)＝Sec，user_kind(u)＝Aud，user_kind(u)＝Common}，π4＝{user_class(u)＝SysHigh，user_class(u)＝SysLow，user_class(u)＝Trusted，user_class(u)≠SysHigh∧user_class(u)≠SysLow∧user_class(u)≠Trusted}。
它們的劃分塊數(shù)目分別為2，2，4，4。
類型USERS上存在一個集合user_exists，其集合劃分為π5={u∈user_exists,u∉user_exists},]]>類型劃分數(shù)目為2。
由于上述劃分中函數(shù)user-admin存在如下約束user-admin(sysadmin)＝true，user-admin(audadmin)＝true，user-admin(secadmin)＝true。且u∈user-existsou≠sysadm∧u≠secadm∧u≠audadmuser-admin(u)＝false，所以劃分π0與π1是從屬關系。兩者的綜合劃分等價于π0。
因為函數(shù)user-status存在如下約束user-status(sysadmin)＝true，user-status(audadmin)＝true，user-status(secadmin)＝true。所以劃分π0與劃分π2之間存在部分從屬關系，部分正交關系。其綜合劃分數(shù)目為3+1×2＝5。類似的，劃分π0與劃分π3之間存在部分從屬關系，部分正交關系。(π0，π1，π2，π3)的綜合劃分數(shù)目為3+2×4＝11。劃分π4與π0，π2，π3均是正交關系，(π0，π1，π2，π3，π4)的綜合劃分數(shù)目為11×4＝44。
由于上述函數(shù)的定義域上存在如下限制domuser-status＝user-exists，dom user-adm＝user-exists。dom user-kind＝user-exists，dom user-class＝user-exists。π1，π2，π3，π4與π5之間存在從屬關系，其綜合劃分數(shù)目為44+1＝45。
類似的，類型PRIVILEGES上的綜合劃分數(shù)目為16，類型OSI上的綜合劃分數(shù)目為4，類型BOOLEAN上的數(shù)據(jù)劃分數(shù)目為2。
多個類型上的綜合劃分構成了輸入向量集。因為類型PRIVILEGES上的劃分與類型OSI上的劃分相關，操作test_GrantPermToUser的輸入向量數(shù)目為45×16×2＝1440。在步驟四中，對于某預設狀態(tài)pre_STATEi與輸入向量IN＝(u？＝alice，p？＝Insert，o？＝10481112，a？＝true)，利用工具計算出謂詞(fest_GrantPermToUser∧pre-STATEi)[u？/alice，o？/1048l112，p？/Insert，a？/true]的值。其值為‘true’，所以生成測試向量。其中輸出向量OUT＝(re！＝ok)，狀態(tài)變化向量post_STATE=^access-matrix′=access-matrix∪{(u ,o ,p ,u1,a )}.]]>最終測試向量為(IN，pre_STATEi，OUT，post_STATE)。
以上通過具體的實施例描述了本發(fā)明所提供的方法，本領域的技術人員應當理解，在不脫離本發(fā)明的精神和實質(zhì)的范圍內(nèi)，可以對本發(fā)明進行修改或等同替換。
權利要求
1.一種安全數(shù)據(jù)庫管理系統(tǒng)測試用例生成方法，包含如下步驟1)生成測試規(guī)約，依據(jù)描述系統(tǒng)操作功能的形式化規(guī)約與操作的安全公理要求生成系統(tǒng)中各個操作的測試規(guī)約；2)生成測試模板，按照一定的重寫規(guī)則對測試規(guī)約進行等價變換，將其表示成析取范式形式，從而將操作的測試規(guī)約等價表示為一組測試模板；3)類型劃分，對系統(tǒng)中存在的類型進行啟發(fā)式等價變換，進一步細分每個測試模板所代表的測試空間；4)生成測試向量，檢驗各測試子域，并將其實例化，生成相應的測試向量。
2.如權利要求1所述的方法，其特征在于，所述的測試規(guī)約包括操作在系統(tǒng)安全模型中的定義；系統(tǒng)安全模型中與操作相關的安全公理集；系統(tǒng)相關中間狀態(tài)變量中存在的固定約束。
3.如權利要求1所述的方法，其特征在于，所述的步驟2)中生成的測試模板的集合將操作的測試空間劃分成互不相交的一組測試子域，每個測試模板代表一個測試子域，并且所述的測試模板集合是完整的，覆蓋了被測操作的所有測試空間。
4.如權利要求1所述的方法，其特征在于，所述的類型劃分種類包含以下劃分方式中的一種或幾種預設值劃分、函數(shù)值劃分、集合劃分、數(shù)據(jù)劃分，且某個類型上的劃分是根據(jù)上述劃分計算的綜合劃分。
5.如權利要求4所述的方法，其特征在于，在所述的類型劃分過程中，若某個類型上存在多個正交劃分，則可以對這些劃分應用一定的取舍原則，減少所生成的測試用例數(shù)目。
6.如權利要求1所述的方法，其特征在于，所述的測試向量包括輸入向量、當前狀態(tài)向量、輸出向量、狀態(tài)變化向量。
全文摘要
本發(fā)明首次提出了一種用于生成安全數(shù)據(jù)庫管理系統(tǒng)測試用例的系統(tǒng)化、可操作的方法，包含如下步驟1)生成測試規(guī)約，依據(jù)描述系統(tǒng)操作功能的形式化規(guī)約與操作的安全公理要求生成系統(tǒng)中各個操作的測試規(guī)約；2)生成測試模板，按照一定的重寫規(guī)則對測試規(guī)約進行等價變換，將其表示成析取范式形式，從而將操作的測試規(guī)約等價表示為一組測試模板；3)類型劃分，對系統(tǒng)中存在的類型進行啟發(fā)式等價變換，進一步細分每個測試模板所代表的測試空間；4)生成測試向量，檢驗各測試子域，并將其實例化，生成相應的測試向量。該方法以被測系統(tǒng)的安全模型為依據(jù)，測試的結果具有完備性、科學性、可重復性和內(nèi)在一致性。
文檔編號G06F9/44GK1752945SQ20051008676
公開日2006年3月29日 申請日期2005年11月2日 優(yōu)先權日2005年11月2日
發(fā)明者張敏, 馮登國, 徐震, 呂雙雙, 陳馳, 黃亮 申請人:中國科學院軟件研究所