CN1752945A - 安全数据库管理***测试用例生成方法 - Google Patents

Abstract

本发明首次提出了一种用于生成安全数据库管理***测试用例的***化、可操作的方法，包含如下步骤：1)生成测试规约，依据描述***操作功能的形式化规约与操作的安全公理要求生成***中各个操作的测试规约；2)生成测试模板，按照一定的重写规则对测试规约进行等价变换，将其表示成析取范式形式，从而将操作的测试规约等价表示为一组测试模板；3)类型划分，对***中存在的类型进行启发式等价变换，进一步细分每个测试模板所代表的测试空间；4)生成测试向量，检验各测试子域，并将其实例化，生成相应的测试向量。该方法以被测***的安全模型为依据，测试的结果具有完备性、科学性、可重复性和内在一致性。

Description

安全数据库管理***测试用例生成方法

技术领域

本发明属于计算机软件的测试与评估领域，主要涉及安全数据库管理***(SecureDataBase Management System，简称SDBMS)的测试与评估，更确切地是基于SDBMS安全策略模型的高安全等级安全数据库管理***测试用例生成方法。

背景技术

软件测试是检验软件实现与其功能规约之间的一致性、并保证软件质量的一种有效手段。在基于安全评估标准实现信息安全产品评估的过程中，评估方对安全***的安全功能实施全面、***的第三方测试是评估中一个不可缺少的重要环节。但由于多种原因，目前独立的安全功能测试在我国安全数据库管理***评估中并没有占据重要的地位。其关键问题在于如何实现测试用例的组织与设计，目前缺乏一种***的方法快速生成针对特定信息安全产品/***(包括SDBMS)的测试用例集。

由于软件著作权利等限制，第三方独立测试大多采用基于规约的测试。***规约来源于***需求，它完整地定义了***的行为。基于规约的测试可以确定输入输出之间的影响关系，有效保证软件功能测试的全面性。形式化规约是***规约的一种更为精确的表达形式，能更好地消除***需求中的二义性。同时，形式化规约提供一种规范的表达形式，因而便于对其进行自动化处理。依据形式化安全规约自动生成测试用例将大大的减少测试工作量。目前存在的一种做法是，通过功能规约建模，按照一定的重写规则划分测试空间，自动生成测试用例。

然而，上述方法在针对SDBMS***的测试评估中直接应用会导致一些特殊问题：上述形式化功能规约重写规则(或是启发式)纯粹只与语法相关，与语义无关，因此产生的测试用例缺乏针对性，难于发现具体***中的问题。另外，SDBMS***中每个操作的输入变量空间有限，但***内部状态空间十分庞大，几乎是无限的。上述方法只适用于较小规模的***，也不能直接应用于SDBMS***的测评。

更为重要的是，对于包括SDBMS在内的大多数信息安全产品，***规约并不能真实地反映现实***的行为。因为***中的操作除了要完成其预定的功能外，同时必须满足安全策略要求。安全策略描述一个信息安全产品(或***)所要保护的对象，以及采取的所有保护措施。存在不同抽象层次的安全策略，如***的安全目标，与***的安全策略模型等。高安全等级SDBMS中存在形式化的安全策略模型。

另一种做法是通过对非形式化的安全目标建模，建立精确的形式化安全功能模型。这种做法存在的问题是：因为存在测评人员的人工建模过程，所以模型与最终的测试结果严重依赖于建模人员对开发者提供的非形式化的安全目标的正确理解。另外，安全目标中的安全策略粒度比较粗，需要测评人员将安全策略中的主客体与实际***对象一一对应。

发明内容

针对上述问题，本发明的目的在于提供一种基于SDBMS安全策略模型的测试用例生成方法。该测试方法的基本前提要求包括：

1.一个SDBMS安全策略模型：

该模型的正确性经形式化工具证明。一个典型的形式化SDBMS安全策略模型中具备以下要素：(1)状态集(STATES)，描述***合法状态；(2)安全公理集(ANXIOMS)，安全公理是模型中定义的一组性质，某个***状态S是安全的当且仅当它满足这些性质；(3)操作集(OPS)，***状态的转换由***操作实现，每个操作都是受控的，只有在其产生一个安全状态时，才允许其执行，即它满足模型中的所有性质；(4)安全定理集(THEOREMS)，可以证明的抽象安全模型所满足的一些安全性质。

2.待测SDBMS产品一套：

该产品依据前述SDBMS安全策略模型实现，两者经开发者确认保持一致。

3.待测SDBMS的高层规约，以及该产品的具体接口定义文档。

本发明所提供的基于SDBMS安全模型的测试用例生成方法是基于以下的构思：形式化安全策略模型是生成SDBMS安全功能测试用例的基础，生成测试用例方法的基本思想是确定测试状态空间，并对测试空间(包括输入状态空间以及中间状态空间)进行划分。因为根据测试理论中的统一假设(unified hypothesis)思想，每个划分中的所有输入与状态的表现应该相同。因此在每个划分中选取其中的一个或几个实例进行测试。

本方法中包括两类测试空间的划分策略：一类是子域划分。将测试空间划分成测试子域。每个子域由一个抽象的测试模板描述；另一类是类型划分。将变量所属的类型值划分，测试模板被实例化为具体的测试用例。

具体来说，该方法包括以下四个步骤：

步骤一：生成测试规约。因为生成测试用例的前提是精确、完整的形式化测试规约，所以在步骤一中必须依据描述操作功能的形式化规约与操作的安全公理要求等生成测试规约。

步骤二：生成测试模板。步骤二通过测试规约重写对测试规约所限定的测试空间进行子域划分。子域间互不相交，并且每个测试子域对应一个测试模板。

步骤三：类型划分。步骤三提供与步骤二不同的划分方式——类型划分。类型划分在测试子域的基础上进一步划分测试空间。

步骤四：生成测试向量。综合上述两种划分方式，步骤四中检验各测试子域，并将其实例化，生成相应的测试向量，构成一个完整的测试用例。

下面以Z语言描述的SDBMS模型为例说明上述四个步骤的内容，该步骤思想可以自然地应用于其他形式化语言描述的SDBMS模型，此处Z语言仅用于说明本发明内容，对本发明不构成任何限制。

步骤一：生成测试规约

SDBMS***中一个操作的测试规约全面、准确地反映了该操作的行为。具体来说，SDBMS安全模型操作集中某个成员操作op的测试规约由以下三部分构成：

(1)操作op在SDBMS模型中的基础定义：

操作op在SDBMS模型中的基础定义的声明部分包括操作的输入变量集合ins，输出变量集合outs，以及操作前后的中间状态变量集合Δstate。操作基础定义中的谓词部分可按语义分为两类：一类是操作op发生的预条件约束，标记为P；另一类是该操作所导致***状态变化，标记为Q。它们的含义是：当且仅当预条件约束P满足时，操作op执行，正确执行后导致***的状态变化满足Q。例如，以Z语言shcema形式表示的操作op的基础定义为：

操作的形式化定义必须满足一致性要求与完整性要求。一致性要求指操作的预条件约束是可满足的；完整性要求指不存在任何遗留的定义域，它的操作结果没有定义。若在操作基础定义上补充操作约束不满足时的描述，增添如上述定义操作non_op，Success，与Fail。则构成如下形式的操作：

因为pre op_full＝true，操作op_full为一个一致且完整的操作。

(2)SDBMS模型中与操作相关的安全公理(集)：

SDBMS安全策略模型中的大多数操作都必须满足特定的安全公理(集)。例如某个SDBMS安全策略模型要求数据对象上的***、删除操作应该满足基于角色的访问控制模型中的静态约束与动态约束。操作op必须满足的安全公理集表示为函数axioms(op)。安全公理通常表现为谓词约束，它与***定义的安全策略直接相关，反映***所要求的安全性质。本方法将安全性质约束与操作自身语义约束区分，使得SDBMS安全策略模型结构更清晰。

加入安全公理约束后的操作op的基础定义及补充定义分别调整为op′与non_op′：

类似的，加入安全公理约束后完整的操作表示为：

(3)***相关中间状态变量中存在的固定约束：

实际上，操作op除了受预条件P约束外，还必须满足一些与操作非直接相关的约束。这些约束限制***中间变量之间的关系，只有满足这些固定约束的状态才可能是一个合法的***状态。因此操作op发生的前状态隐含着这些约束。若以符号TCB表示这些固定约束，则操作规约实际上应该是：

操作op的基础定义及补充定义可进一步调整为op″与non_op″：

完整的操作表示为：

因为***任何状态都必须满足TCB约束，状态

TCB在实际***中是不可达的。若SDBMS安全模型中存在类似的初始化定理并予以证明，则考虑到操作的完整性要求，操作op的完整定义仍然等价于op_full′。

综上所述，对于SDBMS安全策略模型中的操作op，根据是否存在经证明的初始化定理，上述三部分组成其测试规约op_test可以最终表示为如下形式：

$\mathrm{op}\_\mathrm{test}\widehat{=}\mathrm{op}\_{\mathrm{full}}^{\′\′}$ 或 $\mathrm{op}\_\mathrm{test}\widehat{=}\mathrm{op}\_{\mathrm{full}}^{\′}$

步骤二：生成测试模板

操作的测试规约准确地描述了操作的行为特征，同时也限定了该操作的测试空间。但在生成针对该操作的测试用例前，必须先将该测试空间划分，成为一系列互不相交的测试子域空间。我们按照特定的重写规则对测试规约中的谓词约束部分进行等价变换，将其化简成析取范式(DNF)形式，从而将操作op的测试规约op_test等价表示为一组测试模板。

等价变换所使用的重写规则无法一一列举，其中主要的几个规则包括：

(1)存在量词消除规则(单点规则)：

(2)全称量词消除规则：

(3)分配律规则：

重写后的测试规约表示为n个测试模板的析取式：

其中第i个测试模版op_templatei为单纯合取式，表示为 按照所代表的语义分为三类：p_i表示第i个测试模版的约束，它是一个谓词或多个谓词的合取式，

q_i表示操作执行后第f个测试模版的状态变化，

r_i为第i个测试模版的输出结果集，

生成的测试模板集合{op_template_i}，(1≤i≤n)满足下述两点性质：

①i，j：1..n·i≠j|pi∧p_j＝false。

性质①说明测试模板集合每个测试模板的约束之间无交集，生成的测试模板将测试空间划分成互不相交的一组测试子域，每个测试模板代表一个测试子域。性质②说明测试模版集合是完整的，覆盖了被测操作的所有测试空间。即该操作的预条件为永真式，pre op_test＝true。

需要指出的是，上述规则应用次序与数目可能不同，给定的测试规约经过等价变换后得到的析取范式(DNF)不是唯一的。并且等价变换可能会为操作引入一些间接输入变量。

步骤三：类型划分

大多数情况下，步骤二中生成的测试模板的数目非常有限，步骤三通过类型划分对每个测试模板进行启发式等价变换，进一步细分测试空间。首先澄清一下与类型划分概念。

设A是一个非空类型，如果存在一个A的子集族π(πP(A))满足以下条件：

(1)

(2)π中任意两个元素不交

(3)π中所有元素的并集等于A

则称π为类型A的一个划分，且称π中的元素为划分块。π中所有元素的并集称为类型A的π划分表示。

SDBMS安全策略模型上的划分归结为下述四种情况。

情况1：预设值划分：

若类型T中存在一系列特殊预设值s₁，s₂，…s_n，则类型T的预设值划分将类型划分π为：π＝{{s₁)，{s₂}，…，{s_n}，{t：T|t≠s₁∧t≠s₂∧…∧t≠s_n}}，根据划分π，类型T可表示为T＝{s₁}∨{s₂}∨…{s_n}∨{t：T|t≠s₁∧t≠s₂∧…∧t≠s_n}。

类型中的特殊值是***预设，与该类型中的其他值相比存在较为特殊的意义，应该单独测试。并且由于这些值不存在交集，所以类型中每个特殊值都是类型空间划分中的一个子集，满足划分的定义要求。

情况2：函数值划分：

若存在由类型T到类型V上的函数f：T→V，且类型V为有限集，ran(f)＝{v₁，v₂，…v_n)。则类型T的函数值划分π为：π＝{{t：T|f(t)＝v₁}，{t：T|f(t)＝v₂}，…，{t：T|f(t)＝v_n}}。若类型V虽为无限集，但存在重要的划分π₀＝{{s₁}，{s₂}，…，{s_n}}，则类型T存在扩展的函数值划分：π′＝{{t：T|f(t)∈s₁)，{t：T|f(t)∈s₂}，…，{t：T|f(t)∈s_n}}。

SDBMS模型中每个类型上都可能存在一些函数，函数值相同的一组变量代表具备某种相同性质的一类值，而不同的函数值在模型中可能对应不同的行为，因此可以根据不同的函数取值将类型中的变量划分为不同的子集进行测试。

情况3：集合划分：

若类型T上存在多个数据集合，分别表示为ts₁，ts₂，…ts_n，即对于任何1≤i≤n，满足ts_i＝ρ(T)。则类型T的集合划分可以如下递归表示：

1)

2)对于任何1＜i≤n：

3)类型T最终可以表示为：T＝T_test(n)。

与函数类似，SDBMS模型中类型上每个数据集合代表具备某种相同性质的一类值，集合划分最大限度的考虑了这些性质的组合情况。由于大多数数据集合是构成***状态的一部分，通常集合划分只适用于输入变量。

情况4：数据划分：

这种情况涉及一些常见的数据类型，如整数类型，自然数类型，布尔型等等。这些数据类型的特殊取值是与类型相关的固有特殊值，例如，布尔类型上存在的数据划分为{true，false}。数据划分形式上与预设值划分十分近似，主要的区别在于数据划分应用于成员己知的类型，而预设值划分应用于成员数目与内容不确定的类型。

理论上说，若某类型上存在函数则应该采用函数划分；若存在集合则应该采用集合划分；依此类推。若同一个类型同时存在上述多种划分，则需要计算它们的综合划分。综合划分的计算取决于这些划分之间的关系。若划分A中的任一划分块与划分B中的任一划分块相交，称两个划分正交类关系；同一个类型上的正交类关系的两个划分的综合划分结果为所有分属A、B的划分块之间的交集的并集。若划分A中的任一划分块都属于划分B中的某个划分块，称两者间存在重叠类关系。重叠类关系的两个划分的综合划分等价于B的划分。还有一类介于正交类与重叠类之间，即部分划分块相交，部分划分块重叠。该类关系综合划分计算也是两种的综合。

可以想象若某个类型上存在的正交类划分较多，且每个划分中包含大量的划分块，则很有可能出现测试空间划分的组合***。因此需要对划分应用某些原则进行取舍。此处我们给出了两种正交类划分取舍原则：

(1)优先m-选-n原则(m≥n)。若类型T上存在m个正交划分π_i(1≤i≤m)，将其按照重要性非降次序排列，优先m-选-n原则计算其中前n个划分的综合划分。

类型T按不同的划分可分为表示为T_test_i(1≤i≤m)，其长度为|π_i|。按照重要性非降次序排列后，前n个划分为π_i(1≤i≤n)。类型T上优先m-选-n原则的综合划分P为：

综合划分的长度最大为： $\mathrm{num}=\underset{1\≤i\≤n}{\mathrm{\Π}}\left(\right|{\mathrm{\π}}_i\left|\right),$ 其内容为：

(partion_i∈π_i)

(2)正交m-选-n原则(m≥n)。若类型T上存在m个正交划分π_i(1≤i≤m)，正交m-选-n原则计算的综合划分包含其中任何n个划分的综合划分的划分块。

类型T按不同的划分可分为表示为T_test_i(1≤i≤m)，其长度为|π_i|。按照划分长度非递增顺序排列后，前n个的划分记为πi(1≤i≤n)。令P表示类型T上正交m-选-n原则的综合划分。P′表示类型T上任何n个划分的综合划分，P′中的任何一个划分块p′_i(p′_i∈P′)，在综合划分P中至少存在一个划分块p_i(p_i∈P)，满足：p_jp′_i。

将类型T上正交划分的m-选-n取舍原则的综合划分表示成析取范式。综合划分的长度为 $\mathrm{num}=\underset{1\≤i\≤n}{\mathrm{\Π}}\left(\right|{\mathrm{\π}}_i\left|\right).$ 其内容为：

(partioni∈π_i)

计算出的综合划分既可以直接应用于对输入变量的划分，也可以间接的应用于内部状态空间的划分。因为归根结底，内部状态是由内部变量集合及其所对应的取值构成。

步骤四：生成测试向量

实际上SDBMS模型中的被测操作的测试空间划分是步骤二所述的子域划分与步骤三所述的类型划分的综合。一个完整的测试向量是待测SDBMS产品测评的依据。具体的说，测试向量是一组向量之和，即由输入向量、当前状态向量、输出向量、与状态变化向量构成的四元组：(IN，pre_STATE，OUT，post_STATE)。

输入向量由操作op的输入变量集与每个变量取值构成，输入变量取值依赖于具体的测试模板与类型划分块，它是测试空间划分的实例化。除输入向量之外，操作op的执行结果还取决于与测试时***内部状态变量的值，只有在已知***状态下才能确定某输入向量所产生的输出向量与状态变化向量的值。对于某个内部状态，某个类型划分块与测试模板之间的关系可能是三种：划分块完全满足测试模板，即划分块中任选一个成员都可以作为划分实例化输入；划分块完全不满足测试模板，即划分块中的任何一个成员都无法满足测试模板；或划分块部分满足测试模板。即划分块中的部分成员可满足测试模板，部分无法满足。此时结果是否满足测试模板依赖于具体的输入。

虽然所有的内部状态变量最终可归结为单类型集合，复合类型集合，与类型函数等几种，也可以通过类型划分方法对其进行划分，但存在两个问题：一是由于内部状态变量的数目过大，这种划分将导致状态***。二是状态的可控性问题，并不是任何合法的状态都是可达的。即使是可达状态，计算出路径也是一个NP问题。因此，我们选取某些特殊已知状态为测试预设状态，例如包括初始状态，以及与间接输入类型相关的状态集(必须是某己测操作的后状态)。具体的状态生成、选择及遍历方法在现有技术文献中已有大量详细的记载，本领域的一般技术人员都能够了解，因此本说明书中就不再具体解释。

对于测试模板

若给定某输入向量IN＝(INs，VALs)，与***状态pre_STATE，可以计算出逻辑变量(p_k∧pre_STATE)[VALs/INs]的值，若其为真，则该测试用例的预期输出结果为r_k，状态变化为q_k；生成的测试向量为：(IN，pre_STATE，r_k，q_k)。否则不生成测试用例。因为pre op_test＝true，所以对于任何一个状态与输入向量，不论是操作成功或是失败的，必然有一个测试模板使该逻辑变量为真，从而生成相应的测试向量。

本发明的技术效果在于，本发明首次提出了一种用于生成安全数据库管理***测试用例的***化、可操作的方法，有助于对该类***的安全功能进行科学、全面、准确的测试。该方法以被测***的安全模型为依据，测试的结果具有完备性、科学性、可重复性和内在一致性。与现行的手工随机测评方式相比，其能更好地发现***实现的缺陷，大幅度提高了测试质量。该方法结合形式化辅助工具使用，能够减少测试过程中的重复劳动，降低生成大量测试用例所付出的代价，有利于实现测试自动化。

具体实施方式

下面以中国科学院软件研究所信息安全国家重点实验室研发的LOIS安全数据库管理***为例，详细说明本发明提供的安全数据库管理***测试用例生成方法。

该***的SDBMS模型中自主授权相关的操作有两种模式：一种是直接授权给用户，另一种是先授权给角色，再由用户激活角色。直接授权操作GrantPermToUser是管理操作，要求被授权的用户存在，未被授予过该权限。它依赖于多个操作，如创建用户的操作、创建安全标签的操作、创建数据对象的操作、连接操作等。在执行对该操作的测试之前，应该确保已经执行过对以上操作的测试。并且***中限定任何类型用户不能向***管理员、安全管理员和审计管理员授权。该操作改变了***状态中的访问控制矩阵，其具体描述如下：

补充完整性后操作规约为：

操作GrantPermToUser应满足公理GrantPermToUser_axiom，即授权者曾经被授予该权限，并且被允许传播该权限：或者授权者是该对象特权的属主。所有对象特权的分类如下：

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:\mathrm{USERS}\·(\mathrm{trans}-\mathrm{user}(T,o?,p?,g,\mathrm{true})\∈\mathrm{access}-\mathrm{matrix}))$

∨(owner(database-osi(session-database(trans-session(T))))＝trans-user(T)

∧p？∈dbOwnerPrivs)

经过步骤一后，操作GrantPermToUser的测试规约test_GrantPermToUser完整的表达式为：

$\mathrm{test}\_\mathrm{GrantPermToUser}\widehat{=}\mathrm{GrantPermToUser}\_{\mathrm{full}}^{\′}$

            ((﹁GrantPermToUser﹁GrantPermToUser_axiom)∧Fail))

对测试规约应用重写规则并变换成析取范式形式。其中操作成功部分共有8个测试模版，分别为：

(Transition·cur-trans-class(T)＝osi-class(o？)

∧ $(\∃g:\mathrm{USERS}\·(\mathrm{trans}-\mathrm{user}\left(T\right),o?,p?,g,\mathrm{true})\∈\mathrm{access}-\mathrm{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?,\mathrm{trans}-\mathrm{user}\left(T\right),a?)\∉\mathrm{access}-\mathrm{matrix}$

∧access-matrix′＝access-matrix∪{(u？，o？，p？，trans-user(T)，a？)}

∧re！＝ok)

∨(Transition·cur-trans-class(T)＝osi-class(o？)

∧ $(\∃g:\mathrm{USERS}\·(\mathrm{trans}-\mathrm{user}\left(T\right),o?,p?,g,\mathrm{true})\∈\mathrm{access}-\mathrm{matrix})$

∧ $(\∃d:\mathrm{DOMAINS}\·\mathrm{domain}-\mathrm{osi}\left(d\right)=o?)$

∧owner(o？)＝trans-user(T)

∧p？∈dmOwnerPrivs

∧u？∈user-exists

∧﹁user-adm(u？)

∧o？∈osi-exists

∧ $(u?,o?,p?,\mathrm{trans}-\mathrm{user}\left(T\right),a?)\∉\mathrm{access}-\mathrm{matrix}$

∧access-matrix′＝access-matrix∪{(u？，o？，p？，trans-user(T)，a？)}

∧re！＝ok)

∨(Transition·cur-trans-class(T)＝osi-class(o？)

∧ $(\∃g:\mathrm{USERS}\·(\mathrm{trans}-\mathrm{user}\left(T\right),o?,p?,g,\mathrm{true})\∈\mathrm{access}-\mathrm{matrix})$

∧ $(\∃t:\mathrm{MREAL}-\mathrm{IDS}\·\mathrm{real}-\mathrm{osi}\left(t\right)=o?)$

∧owner(o？)＝trans-user(T)

∧p？∈tbOwnerPrivs

∧u？∈user-exists

∧﹁user-adm(u？)

∧o？∈osi-exists

∧ $(u?,o?,p?,\mathrm{trans}-\mathrm{user}\left(T\right),a?)\∉\mathrm{access}-\mathrm{matrix}$

∧access-matrix′＝access-matrix∪{(u？，o？，p？，trans-user(T)，a？)}

∧re！＝ok)

∨(Transition·cur-trans-class(T)＝osi-class(o？)

∧ $(\∃g:\mathrm{USERS}\·(\mathrm{trans}-\mathrm{user}\left(T\right),o?,p?,g,\mathrm{true})\∈\mathrm{access}-\mathrm{matrix})$

∧ $(\∃t:\mathrm{MVIEW}-\mathrm{IDS}\·\mathrm{view}-\mathrm{osi}\left(t\right)=o?)$

∧owner(o？)＝trans-user(T)

∧p？∈viOwnerPrivs

∧u？∈user-exists

∧﹁user-adm(u？)

∧o？∈osi-exists

∧ $(u?,o?,p?,\mathrm{trans}-\mathrm{user}\left(T\right),a?)\∉\mathrm{access}-\mathrm{matrix}$

∧access-matrix′＝access-matrix∪{(u？，o？，p？，trans-user(T)，a？)}

∧re！＝ok)

∨(Transition·cur-trans-class(T)＝osi-class(o？)

$\⫬(\∃g:\mathrm{USERS}\·(\mathrm{trans}-\mathrm{user}\left(T\right),o?,p?,g,\mathrm{true})\∈\mathrm{access}-\mathrm{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?,\mathrm{trans}-\mathrm{user}\left(T\right),a?)\∉\mathrm{access}-\mathrm{matrix}$

∧access-matrix′＝access-matrix∪{(u？，o？，p？，trans-user(T)，a？)}

∧re！＝ok)

∨(Transition·cur-trans-class(T)＝osi-class(o？)

∧ $\⫬(\∃g:\mathrm{USERS}\·(\mathrm{trans}-\mathrm{user}\left(T\right),o?,p?,g,\mathrm{true})\∈\mathrm{access}-\mathrm{matrix})$

∧ $(\∃d:\mathrm{DOMAINS}\·\mathrm{domain}-\mathrm{osi}\left(d\right)=o?)$

∧owner(o？)＝trans-user(T)

∧p？∈dmOwnerPrivs

∧u？∈user-exists

∧﹁user-adm(u？)

∧o？∈osi-exists

∧ $(u?,o?,p?,\mathrm{trans}-\mathrm{user}\left(T\right),a?)\∉\mathrm{access}-\mathrm{matrix}$

∧access-matrix′＝access-matrix∪{(u？，o？，p？，trans-user(T)，a？)}

∧re！＝ok)

∧(Transition·cur-trans-class(T)＝osi-class(o？)

∧ $\⫬(\∃g:\mathrm{USERS}\·(\mathrm{trans}-\mathrm{user}\left(T\right),o?,p?,g,\mathrm{true})\∈\mathrm{access}-\mathrm{matrix})$

∧ $(\∃t:\mathrm{MREAL}-\mathrm{IDS}\·\mathrm{real}-\mathrm{osi}\left(t\right)=o?)$

∧owner(o？)∈trans-user(T)

∧p？∈tbOwnerPrivs

∧u？∈user-exists

∧﹁user-adm(u？)

∧o？∈osi-exists

∧ $(u?.o?,p?,\mathrm{trans}-\mathrm{user}\left(T\right),a?)\∉\mathrm{access}-\mathrm{matrix}$

∧access-matrix′＝access-matrix∪{(u？，o？，p？，trans-user(T)，a？)}

∧re！＝ok)

∨(Transition·cur-trans-class(T)＝osi-class(o？)

∧ $\⫬(\∃g:\mathrm{USERS}\·(\mathrm{trans}-\mathrm{user}\left(T\right),o?,p?,g,\mathrm{true})\∈\mathrm{access}-\mathrm{matrix})$

∧ $(\∃t:\mathrm{MVIEW}-\mathrm{IDS}\·\mathrm{view}-\mathrm{osi}\left(t\right)=o?)$

∧owner(o？)＝trans-user(T)

∧p？∈viOwnerPrivs

∧u？∈user-exists

∧﹁user-adm(u？)

∧o？∈osi-exists

∧ $(u?,o?,p?,\mathrm{trans}-\mathrm{user}\left(T\right),a?)\∉\mathrm{access}-\mathrm{matrix}$

∧access-matrix′＝access-matrix∪{(u？，o？，p？，trans-user(T)，a？)}

∧re！＝ok)

上例中第四个测试模版补充完整后，可以表示为如下形式：

$\mathrm{test}\_\mathrm{template}4\widehat{=}\left[\mathrm{signature}\right|\mathrm{cur}-\mathrm{trans}-\mathrm{class}\left(T\right)=\mathrm{osi}-\mathrm{class}(o?)$

∧ $(\∃t:\mathrm{MREAL}-\mathrm{IDS}\·\mathrm{real}-\mathrm{osi}\left(t\right)=o?)$

∧owner(o？)＝trans-user(T)

∧p？∈tbOwnerPrivs

∧u？∈user-exists

∧﹁user-adm(u？)

∧o？∈osi-exists

∧ $(u?,o?,p?,\mathrm{trans}-\mathrm{user}(T,)a?)\∉\mathrm{access}-\mathrm{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:\mathrm{USERS}\·\mathrm{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中的函数owner、trans-user、osi-class、cur-trans-class、user-admin等均可以以类似方法再细化。将测试模版4生成的所有函数细化后得到的标准形式如下：

依据步骤二要求，该模板可以表示为：

按语义及表达形式可以区分出操作输入应满足的约束为：

∧t∈real_exist∧clss∈CLASSES∧p？∈tbOwnerPrivs

∧u？∈user_exist∧u？≠sysadmin∧u？≠audadmin∧u？≠secadmin

∧ $(u?,o?,p?,u1,a?)\∉\mathrm{access}-\mathrm{matrix}$

操作导致的状态变化为：

$q_4\widehat{=}\mathrm{access}-{\mathrm{matrix}}^{\′}=\mathrm{access}-\mathrm{matrix}\∪\left\{(u?,o?,p?,u1,a?)\right\}$

操作导致的输出结果为：

$r_4\widehat{=}\mathrm{re}!=\mathrm{ok}$

其中，直接输入变量为：o？，p？，u？，a？，分别属于类型OSI，PRIVILEGES，USERS，与BOOLEAN。间接输入变量为：T，u1，t，clss，分别属于类型TRANSACTIONS，USERS，TUPLES与CLASSES。直接输出变量：re！，间接输出变量：access-matrix。

在操作模板确定后，接下来针对输入变量类型确定应用类型上的划分。其中输入变量u？表示被授权的用户，属于类型USERS。该类型上存在三个特殊值，分别为：***管理员sysadmin，审计管理员audadmin，与安全管理员secadmin。因此类型USERS上的特殊值划分为：π₀＝{u＝sysadm，u＝secadm，u＝audadm，u≠sysadm∧u≠Sec adm∧u≠audadm}。划分块数目为4。

类型USERS上存在四个函数，分别为：

user-adm：USERS-|→BOOLEAN，值域为{true，false}

user-status：USERS-|→BOOLEAN，值域为{true，false}

user-kind：USERS-|→SKIND，值域为{Sys，See，Aud，Common}

user-class：USERS-|→CLASSES，值域特殊值为{SysHigh，SysLow，Trusted}。

类型USERS上的四个函数划分分别为：

π₁＝(user-adm(u)：true，user_adm(u)＝false}，π₂＝{user_status(u)＝true，user-status(u)＝false}，

π₃＝{user_kind(u)＝sys，user_kind(u)＝Sec，user_kind(u)＝Aud，user_kind(u)＝Common}，

π₄＝{user_class(u)＝SysHigh，user_class(u)＝SysLow，user_class(u)＝Trusted，

user_class(u)≠SysHigh∧user_class(u)≠SysLow∧user_class(u)≠Trusted}。

它们的划分块数目分别为2，2，4，4。

类型USERS上存在一个集合user_exists，其集合划分为 ${\mathrm{\π}}_5=\{u\∈\mathrm{user}\_\mathrm{exists},u\∉\mathrm{user}\_\mathrm{exists}\},$ 类型划分数目为2。

由于上述划分中函数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，所以划分π₀与π₁是从属关系。两者的综合划分等价于π₀。

因为函数user-status存在如下约束：user-status(sysadmin)＝true，user-status(audadmin)＝true，user-status(secadmin)＝true。所以划分π₀与划分π₂之间存在部分从属关系，部分正交关系。其综合划分数目为3+1×2＝5。类似的，划分π₀与划分π₃之间存在部分从属关系，部分正交关系。(π₀，π₁，π₂，π₃)的综合划分数目为3+2×4＝11。划分π₄与π₀，π₂，π₃均是正交关系，(π₀，π₁，π₂，π₃，π₄)的综合划分数目为11×4＝44。

由于上述函数的定义域上存在如下限制：domuser-status＝user-exists，dom user-adm＝user-exists。dom user-kind＝user-exists，dom user-class＝user-exists。π₁，π₂，π₃，π₄与π₅之间存在从属关系，其综合划分数目为44+1＝45。

类似的，类型PRIVILEGES上的综合划分数目为16，类型OSI上的综合划分数目为4，类型BOOLEAN上的数据划分数目为2。

多个类型上的综合划分构成了输入向量集。因为类型PRIVILEGES上的划分与类型OSI上的划分相关，操作test_GrantPermToUser的输入向量数目为45×16×2＝1440。在步骤四中，对于某预设状态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)，状态变化向量 $\mathrm{post}\_\mathrm{STATE}\widehat{=}\mathrm{access}-{\mathrm{matrix}}^{\′}=\mathrm{access}-\mathrm{matrix}\∪\left\{(u?,o?,p?,u1,a?)\right\}.$ 最终测试向量为(IN，pre_STATEi，OUT，post_STATE)。

以上通过具体的实施例描述了本发明所提供的方法，本领域的技术人员应当理解，在不脱离本发明的精神和实质的范围内，可以对本发明进行修改或等同替换。

Claims (6)

1、一种安全数据库管理***测试用例生成方法，包含如下步骤：

1)生成测试规约，依据描述***操作功能的形式化规约与操作的安全公理要求生成***中各个操作的测试规约；

2)生成测试模板，按照一定的重写规则对测试规约进行等价变换，将其表示成析取范式形式，从而将操作的测试规约等价表示为一组测试模板；

3)类型划分，对***中存在的类型进行启发式等价变换，进一步细分每个测试模板所代表的测试空间；

4)生成测试向量，检验各测试子域，并将其实例化，生成相应的测试向量。

2、如权利要求1所述的方法，其特征在于，所述的测试规约包括：

操作在***安全模型中的定义；

***安全模型中与操作相关的安全公理集；

***相关中间状态变量中存在的固定约束。

3、如权利要求1所述的方法，其特征在于，所述的步骤2)中生成的测试模板的集合将操作的测试空间划分成互不相交的一组测试子域，每个测试模板代表一个测试子域，并且所述的测试模板集合是完整的，覆盖了被测操作的所有测试空间。

4、如权利要求1所述的方法，其特征在于，所述的类型划分种类包含以下划分方式中的一种或几种：预设值划分、函数值划分、集合划分、数据划分，且某个类型上的划分是根据上述划分计算的综合划分。

5、如权利要求4所述的方法，其特征在于，在所述的类型划分过程中，若某个类型上存在多个正交划分，则可以对这些划分应用一定的取舍原则，减少所生成的测试用例数目。

6、如权利要求1所述的方法，其特征在于，所述的测试向量包括：输入向量、当前状态向量、输出向量、状态变化向量。