一种基于建模技术的软件安全性测试方法

摘要

本发明公开了一种基于建模技术的软件安全性测试方法，通过将软件安全性缺陷测试行为需求和软件安全性功能测试行为需求转化为形式化软件安全性测试行为需求模型，并基于获得的模型生成有穷状态机特征序列生成安全性测试用例；同时，能够对于获得的安全性测试用例提取安全性缺陷，补充完善安全性缺陷库。本发明提供的方法，解决了现行标准和工程体系中安全性测试需求提取难题，保证软件安全性测试需求的覆盖率和有效性。同时，提供了从安全性测试需求提取，需求形式化描述到测试用例自动生成的测试过程系统，形成一套完成的软件安全测试方法体系和支撑系统，在提高其针对性的同时，缩短软件安全性测试周期，有助于提高软件安全性质量。

说明书

技术领域

本发明涉及软件安全性测试技术，尤其涉及一种基于缺陷建模技术软件安全性测试方法。

背景技术

随着计算机技术的发展，软件产品在越来越多的领域得到了应用，为人们的生活带来了极大的便利，也正在改变着人们的工作和生活方式，对人类政治、经济、军事、文化和科技的发展都产生了深远的影响。在软件水平快速发展的同时，随着面向对象、构件软件、分布式软件等新技术的兴起，软件的安全性也变得日益严重，并成为制约软件技术发展与应用的一个重要因素。据美国计算机危机应急小组处理中心CERT/CC(Computer Emergency Readiness Team Coordination Center)统计报道，从1998年到2009年，软件安全性危机事件增长了4724％，平均每年增长394％，且近年来一直居高不下。随之而来的是软件安全性问题造成的损失非常巨大，根据美国国家标准协会NIST(National Institue of Standards)统计，2002年用于维护存在安全隐患软件的费用就达595亿美元，同时NIST还发现，其中92％的安全性缺陷是由于软件自身的缺陷，而非网络等外围设备的缺陷所至。

目前，我国软件信息安全水平被排在最不发达的第四类国家之列。特别是国内计算机使用的软件产品都是引入或者基于国外软件；社会各个领域的大型基础软件，如操作系统，办公软件等基础软件都是依赖国外公司，这就对软件产品应用的安全性提出了严峻的考验。所以对我国而言，软件安全已成为影响国家大局和长远利益的关键问题；提高软件安全水平、保障软件系统甚至整个计算机系统的安全是一项刻不容缓的重要课题。

软件测试作为保证软件安全性的一种重要途径，对于为软件产品进行安全性评价具有重要的意义。根据国家的规划，软件测试技术将作为保证软件产品安全性的重要手段，力争使测试越早介入软件开发，从而提高软件抵御潜在风险的能力，降低软件的安全缺陷率。国家高技术研究发展计划(863计划)2008年正式将软件安全性测试与评估技术作为重点研究发展方向。国外在软件安全性测试方面的研究也取得了一定的成果。当前软件安全性测试领域内存在的主要问题：

一、现行测试标准的可行性不高。

目前国内在软件安全性研究领域中，主要参照标准为《计算机信息系统安全保护等级划分准则》(GB17859-1999)和《信息技术安全性评估准则》(GB18336-2001)。这些标准主要针对安全性评估，缺少对测试活动的规定。在软件安全性测试方面，军内相继颁布了两种测试指南。《军用软件安全性分析指南》和《军用软件测试指南》中都对软件安全性测试进行了相应的规定和说明。通过对其进行分析，可以看出现行的两种标准中存在以下问题：首先，将软件安全性测试(Software Security Test)和软件防危性测试(Software Safety Test)混合在一起实施；这样会误导软件测试需求分析人员将两种测试同时进行，这样对后续的测试工作产生根本的错误指导；其次，这种概要性测试规则在实际的测试项目中，还需要结合被测件进行相应的细化和分解，而两种指南都缺少一种分解方法或规则，但往往细化和分解工作会决定软件安全性测试的实施；最后，随着新的软件技术的出现，这些软件安全性测试规则不全面性就越发突出，所以必须对其进行定期的扩展和更新。

在国际标准方面，ISO/IEC 21827：2008，Information technology-Securitytechniques-Systems Security Engineering-Capability Maturity Model(SSE-CMM)针对整个信息系统安全性需求的过程，规定了一种能力成熟度模型，从而规范了整个安全性工程过程。但是，这个标准只是规定了系统安全性工程中的重要活动，并没有针对具体测试活动开展的过程描述，在此标准中没有对安全性测试过程进行具体的规范。而ISO/IEC24759：2008，Information technology-Security techniques-Test requirements forcryptographic modules针对加密模块的测试需求应该采用的方法进行了规范，可以指导特定领域软件的安全性测试需求的获取。ISO/IEC TR19791：2010，Informationtechnology-Security techniques-Security assessment of operational systems针对操作系统的安全性评估过程进行了规定，对评估中采用的工具，评估的阶段以及配置管理过程进行了规范。

综上所述，虽然这些标准中或多或少都涉及到了测试活动，但是对于测试过程中活动的具体实施缺少详细描述，难以指导实际的测试活动。

二、安全性测试需求的不明确。

在软件测试需求分析中，通常存在以下问题：首先，由于测试需求分析人员通常缺少专业的安全分析知识和敏锐的安全意识，所以造成安全性测试需求通常与软件功能测试需求混淆；其次，测试需求分析人员即使能够考虑到软件安全性测试需求，但是由于缺少有效的方法指导，通常也只是机械的将系统级测试需求转化为软件安全性系统级测试需求。这种测试需求通常比较宽泛，难以指导实际的安全性测试的开展。

三、缺少可行的软件安全性测试过程模型。

软件安全性测试相对于功能性测试还处于一个研究阶段，根据现有的研究基础，还没有发现国际上针对软件安全性测试过程的标准。而在国内，《军用软件安全性分析指南》和《军用软件测试指南》虽然对软件安全性测试的进行了规范，但是还没有形成一个能够应用于第三方软件测评中心实施的软件安全性测试过程模型。而实际的测试中，特别是军用、通信等安全关键软件的测试活动中却迫切需要进行针对性地测试。

发明内容

发明目的：为了克服现有技术中存在的不足，本发明提供一种基于软件安全性功能需求与安全性缺陷建模技术的软件安全性测试方法，以解决软件安全性测试需求的获取、描述、形式化表示以及有效测试用例的自动生成问题，该方法可用于有效指导软件安全性的测试。

技术方案：为实现上述目的，本发明采用的技术方案为：

一种基于建模技术的软件安全性测试方法，所述安全性测试方法包括如下步骤：

(a)基于CWE、CERT、CVE和OWASP软件漏洞数据库，确定当前阶段软件安全性典型缺陷集；

(b)软件数据流分类描述；

(c)建立通过步骤(a)获取的软件安全性典型缺陷与通过步骤(b)获取的软件数据流分类描述预对应表；

(d)基于被测件数据流图，根据步骤(c)获取的软件安全性典型缺陷与数据流预对应表，初步获取软件安全性缺陷测试需求；

(e)实现对通过步骤(d)获取的软件安全性测试需求的行为描述，得到软件安全性缺陷测试行为需求；

(f)基于剖面划分方法，获取软件安全性功能测试需求；

(g)通过步骤(f)获取的软件安全性功能测试需求行为描述；

(h)通过步骤(e)和步骤(g)获取的软件安全性功能测试行为需求状态图描述；

(i)基于有穷状态机(以下简称FSM)实现对通过步骤(h)获取的状态图的形式化描述；

(j)基于步骤(i)获取的有穷状态机生成测试用例。

所述步骤(a)具体包括如下步骤：

(a1)分别确定CWE、CERT、CVE和OWASP统计出的软件安全性漏洞数据库，所述数据库表示为V＝[V1，V2，V3，V4]；

(a2)分别设定四个漏洞数据库的权重，表示为P＝[P1，P2，P3，P4]；

(a3)根据VP＝V^TP得到漏洞数据库中典型软件安全性漏洞的排序；

(a4)选择排名在前的典型安全性漏洞，通过安全性分析确定引起安全性漏洞的软件安全性缺陷，从而得到当前阶段软件安全性典型缺陷。

所述步骤(b)中将数据流分为如下四类进行描述：

类别1：操作请求信息，即当外部实体需要对数据实体进行操作时，通过数据进程向数据实体发送的操作请求信息；

类别2：操作失败返回信息，即当数据实体需要对外部实体的错误操作进行提示时，通过数据进程向外部实体发送的提示信息；

类别3：操作成功返回信息，即当数据实体需要对外部实体的正确操作进行提示时，通过数据进程向外部实体发送的提示信息；

类别4：数据信息，即以上三个类别以外的数据流信息。

所述步骤(d)具体包括如下步骤：

(d1)确定软件所涉及数据的信息来源，对用户的访问类型进行分类；

(d2)根据不同的访问类型确定用户风险等级；

(d3)根据软件结构绘制第0层带有数据交互边界的数据流图；

(d4)抽取出第0层数据流图中的数据交互路径列表；

(d5)根据用户风险等级，确定可能存在缺陷的交互路径及其危险等级；

(d6)对步骤(d5)中确定的危险等级高的交互路径，对第0层基于数据交互边界的数据流图进行分解，抽取第1层基于数据交互边界的数据流图；

(d7)对步骤(d6)中得出的第1层基于数据交互边界的数据流图，基于步骤(c)获取的软件安全性典型缺陷与数据流预对应表，确定穿越数据交互边界的数据流信息可能存在的缺陷；

(d8)根据步骤(d7)中确定的缺陷，确定软件安全性缺陷测试需求。

所述步骤(f)具体包括如下步骤：

(f1)创建软件的UML用例图与活动图；

(f2)根据UML用例图与活动图建立安全性功能测试行为需求，建立安全性功能测试行为需求包括如下步骤：

(f2.1)确定UML用例图与活动图的资产，分析需要保护的内容；

(f2.2)根据每一种资产，进行威胁识别，采用STRIDE模型，分析可能对资产造成损害的意外事件原因；

(f2.3)根据每一种威胁，建立安全机制列表；

(f2.4)根据安全机制列表，对应《信息技术安全评价通用准则》提取安全性功能测试需求。

所述步骤(h)具体包括如下步骤：

(h1)基于软件安全性缺陷，对通过步骤(e)和步骤(g)获取的软件安全性缺陷测试行为需求和软件安全性功能测试行为需求，进行行为预防机制、行为检测机制和行为响应机制分析；

(h2)对步骤(h1)中的三种机制，分别描述三种机制的三个阶段行为，即前置条件、处理行为和后置条件；

(h3)分别将测试需求行为模型中的行为预防机制、行为检测机制和行为响应机制的三个阶段行为映射为UML状态图中的三个顶层复合状态；

(h4)依据典型安全性缺陷在每个阶段行为中的处理过程，将三个阶段分别映射为UML状态图中的行为预防状态子图、行为处理状态子图和行为响应状态子图，即形式化软件安全性测试行为需求模型。

所述步骤(i)具体包括如下步骤：

(i1)将步骤(h4)中获得的UML状态图存储为XMI文本格式；

(i2)依据文本转换算法将XMI格式的状态图转换为SCXML格式，即FSM的文本表示。

所述步骤(j)具体包括如下步骤：

(j1)对FSM进行预处理，所述预处理包括非完全FSM的完全化、非精简FSM的最小精简化和连通性说明，具体分为如下步骤：

(j11)为规约中没有出现的输入增加定义，达到FSM的完全化；

(j12)去除FSM中的冗余状态，使用等价的精简FSM取代原FSM；

(j13)对FSM中所有状态可达性和可复位性进行检查和说明；

(j2)构造有穷状态机的UIO树，并基于UIO树为FSM中的每个状态s_j生成UIO特征序列，具体分为如下步骤：

(j2.1)从FSM的初始向量出发，通过定义路径向量和扰动函数，产生新的结点，构造UIO树；

(j2.2)遍历整个UIO树，对每一个单一向量叶结点，将从树根到该叶结点所形成的输入/输出序列连接为该单一向量初始向量对应状态的UIO序列；

(j2.3)对每个状态，选取最短的一个UIO序列为其特征序列；

(j3)基于UIO特征序列，对FSM的每一个状态迁移生成使用测试序列表示的测试用例，UIO特征序列将作为测试序列生成时的状态验证序列，生成的测试序列覆盖FSM的每一个状态迁移。该步骤又具体分为如下步骤：

(j3.1)对FSM中的每个状态迁移(s_i，s_j；x/y)，使用Dijikstra算法确定s₀到s_i的最短路径，得到s₀到s_i最短输入/输出序列；

(j3.2)依次连接s₀到s_j的输入/输出，得到每个状态迁移(s_i，s_j；x/y)的测试用例(reset/null).SP(s_i).(x/y).UIO(s_j)；

所述步骤(j3)中，s₀，s_i，s_j表示FSM的状态；(s_i，s_j；x/y)表示从状态s_i迁移到状态s_j，其中输入为x，输出为y；reset表示将FSM复位到初始状态；SP(s_i)表示初始状态到状态si的最短输入/输出序列。

有益效果：本发明提供的基于建模技术的软件安全性测试方法，有效解决了现行标准和工程体系中安全性测试需求提取的难题，保证软件安全性测试需求的覆盖率，从而从根源上保证软件安全性测试的测试有效性。同时，提供了从安全性测试需求提取，需求形式化描述到测试用例自动生成的测试过程模型和系统，形成一套完整的软件安全测试方法体系和支撑系统，在提高软件安全性测试的针对性的同时，也缩短了软件安全性测试周期，有助于从测评角度推动软件安全性水平，提高软件安全性质量，具有较高的社会和经济效益。

附图说明

图1为本发明的流程结构图；

图2为测试需求行为模型的图形化实例示意图；

图3为测试需求行为模型的图形形式示意图；

图4为某媒体资源管理系统的用例图；

图5为某媒体资源管理系统的登录活动图；

图6为三次错误登录限制时序场景示意图；

图7为形式化软件安全性测试行为需求模型示意图；

图8为行为响应状态子图；

图9为有穷状态机示意图；

图10为UIO树示意图。

具体实施方式

下面结合附图对本发明作更进一步的说明。一种基于建模技术的软件安全性测试方法，所述安全性测试用例获取方法包括如下步骤：

(a)基于CWE、CERT、CVE和OWASP软件漏洞数据库，确定当前阶段软件安全性典型缺陷集；

(b)软件数据流分类描述；

(c)建立通过步骤(a)获取的软件安全性典型缺陷与通过步骤(b)获取的软件数据流分类描述预对应表；

(d)基于被测件数据流图，根据步骤(c)获取的软件安全性典型缺陷与数据流预对应表，初步获取软件安全性缺陷测试需求；

(e)实现对通过步骤(d)获取的软件安全性测试需求的行为描述，得到软件安全性缺陷测试行为需求；

(f)基于剖面划分方法，获取软件安全性功能测试需求；

(g)通过步骤(f)获取的软件安全性功能测试需求行为描述；

(h)通过步骤(e)和步骤(g)获取的软件安全性功能测试行为需求状态图描述；

(i)基于有穷状态机实现对通过步骤(h)获取的状态图的形式化描述；

(j)基于步骤(i)获取的有穷状态机生成测试用例。

所述步骤(a)包括如下步骤：

(a1)分别确定CWE、CERT、CVE和OWASP统计出的排名前二十位的典型软件安全性漏洞数据库，所述数据库可以表示为V＝[V1，V2，V3，V4]；

(a2)设定四个漏洞数据库的权重可以表示为P＝[P1，P2，P3，P4]；

(a3)根据VP＝V^TP可以得到漏洞数据库中典型软件安全性漏洞的排序；

(a4)选择如表1所示的排名前11个典型安全性漏洞，通过安全性分析确定引起安全性漏洞的软件安全性缺陷，从而得到当前阶段软件安全性典型缺陷；

表1

所述步骤(b)中将数据流分为如下四类进行描述，并对各个类别进行定义解释：

类别1：操作请求信息；

类别2：操作失败返回信息；

类别3：操作成功返回信息；

类别4：数据信息。

定义1：操作请求信息(InforOp：Information for Operation)，即当外部实体需要对数据实体进行操作时，通过数据进程向数据实体发送的操作请求信息；通常包括登录，注册，查询，增加，删除，上载，卸载等操作信息。

定义2：操作失败返回信息(ReInforInc：Return Information for Incorrect Operation)，即当数据实体需要对外部实体的错误操作进行提示时，通过数据进程向外部实体发送的提示信息；通常包括：权限错误，身份验证错误，数据存储错误，数据读取错误等返回信息，这种信息通常和外部实体的操作请求信息对应。

定义3：操作成功返回信息(ReInforCor：Return Information for Correct Operation)：即当数据实体需要对外部实体的正确操作进行提示时，通过数据进程向外部实体发送的提示信息；通常包括：口令提示信息，操作数据信息等。这种信息通常也是和外部实体的操作请求相对应。

其它的数据流信息都称为数据信息(DInfor：Data Information)。这样就可以将数据流分为以上四类。

所述步骤(c)包括如下步骤：

通过步骤(a)和步骤(b)，分别对得到的安全性典型缺陷进行分析，初步确定其可能存在的数据流的种类，建立缺陷与数据流预对应表，如表2所示。

表2

在表2中，其中“1”表示行和列之间具有一定的关联关系，空表示行和列之间不具有关联关系，这张表也不是确定的，随着安全性技术的发展，需要安全专家定期进行会商修订。

所述步骤(d)包括如下步骤：

(d1)确定软件所涉及数据的信息来源，对用户的访问类型进行分类；

(d2)根据不同的访问类型确定用户风险等级；

(d3)根据软件结构绘制第0层带有数据交互边界的数据流图；

(d4)抽取出第0层数据流图中的数据交互路径列表；

(d5)根据用户风险等级，确定可能存在缺陷的交互路径及其危险等级；

(d6)对步骤(d5)中确定的危险等级高的交互路径，对第0层基于数据交互边界的数据流图进行分解，抽取第1层基于数据交互边界的数据流图；

(d7)对步骤(d6)中得出的第1层基于数据交互边界的数据流图，基于步骤(c)获取的软件安全性典型缺陷与数据流预对应表，确定穿越数据交互边界的数据流信息可能存在的缺陷；

(d8)根据步骤(d7)中确定的缺陷，确定软件安全性缺陷测试需求。例如对于某媒体资源管理系统的检索操作，可以得到其软件安全性需求如表3所示。

表3

其中NULL表示不能预判断该数据流中可能存在哪种缺陷。

所述步骤(e)包括如下步骤：

定义4：软件安全性缺陷测试需求(SSDTR：Software Security Defect TestingRequirements)：也叫软件安全性反向测试测试需求AST(Adversarial Security TestingRequirements)，这种需求是以软件中可能存在的安全性缺陷(SSD：Software SecurityDefects)为对象，提取SSD可能被非法用户利用后对软件进行的非法操作。

定义5：软件安全性功能测试需求(SSFTR：Software Security Function TestingRequirements)：类似于传统的软件功能测试需求，指用户提出的在软件运行环境下使用何种安全措施来抵御可能的非法操作，这种需求通常和安全性目标相关。

在系统的设计运行环境下使用何种安全保护措施来抵御可能的攻击，所以在安全评估中我们并不是去判定系统是否能够抵抗所有攻击，而是判断系统是否符合其设计安全目标。

定义6：软件安全性缺陷测试行为需求(SSDTBR：Software Security Defect TestingBehavior Requirements)：这种需求是将可能利用SSD的安全性威胁具体化，从而以威胁执行场景的方式描述需求。

定义7：软件安全性功能测试行为需求(SSFTBR：Software Security Function TestingBehavior Requirements)：这种需求也就是指用户提出的需要得到保证的安全性机制的具体行为，类似于经典的软件功能性测试行为的描述。

(e1)需求的表格化表示

需求的表格化表示由四部分组成：

(e1.1)前缀标识部分：这部分主要说明SSTBM中描述SSD测试行为的类型、其SSTBM标识、SSD被覆盖的路径和潜在的非法用户；

(e1.2)测试SSD测试行为前部分：即SSD测试行为预防机制，主要描述软件系统在需要覆盖的SSD被激活之前所应该具有的状态和行为，包括防止SSD测试行为的前置条件、防止SSD测试行为前软件系统可以进行的预防措施以及防止SSD测试行为的后置条件；

(e1.3)测试SSD测试行为过程部分：即SSD测试行为处理机制，主要描述软件系统怎样对基于SSD的非法访问进行检测，包括测试SSD测试行为过程的前置条件、测试SSD测试行为过程的检测场景、测试SSD测试行为过程的检测结果和测试SSD测试行为过程的后置条件；

(e1.4)测试SSD测试行为后部分：即SSD测试行为响应机制，主要描述在正确地检测完SSD测试行为后软件系统应该具有的状态和行为，从而防止SSD测试行为再次被执行。这部分包括测试SSD测试行为后前置条件、测试SSD测试行为后响应场景、测试SSD测试行为后响应行为以及测试SSD测试行为后后置条件。

例如对于访问控制缺陷，可以基于缺陷的测试需求行为的表格表示为表4。

表4

以这种表格形式的文字表述具有较强的可扩展性和灵活性，用户可以根据需要对其进行裁减，文字形式非常便于与用户之间的交互。

(e2)表格化转化为图形化表示

(e2.1)图形化实例如图2所示。

(e2.2)根据上一节得到的表格形式，图形横向顺序分为测试SSD测试行为前、测试SSD测试行为过程和测试SSD测试行为后部分，并且加入纵向划分边界线；这种顺序划分描述直接可以继承表格形式的语言描述部分；

(e2.3)在横向的基础上，将其纵向顺序划分为：前置条件、处理行为和后置条件三部分；其中前置条件表示应用程序在进行相应处理行为之前应该处于的状态；处理行为表示系统对安全机制行为、SSD测试行为以及SSD发生后的响应行为的相应处理过程；后置条件表示应用程序分别在这些行为过程发生后具有怎样的状态和应该采取的处理过程。

这种横向顺序划分描述，相对于纵向抽取稍显复杂。它不能直接继承表格形式的语言描述部分，由表4可见前置条件和后置条件可以直接继承，每部分剩余的行为就组成了中间的处理行为，最后加入划分分界线。这样也就完成了纵向的划分，到此也就将表格形式划分为多个独立的模块。

(e2.4)由上自下将各个模块连接起来，从而形成最终的图形化描述形式，例如，根据步骤(e1.4)获取的表格描述形式，可以得到其图形化如图3所示。

到此就完成了表格的图形化，这种基于图形表示的模块化划分非常直观，便于进一步生成软件安全性测试用例。

所述步骤(f)包括如下步骤：

(f1)创建软件的UML用例图与活动图；

如附图所示，给出了某媒体资源管理系统的用例图(图4)以及登录活动图(图5)。

(f2)根据UML用例图与活动图建立安全性功能测试行为需求，建立安全性功能测试行为需求包括如下步骤：

(f2.1)确定UML用例图与活动图的资产，分析需要保护的内容；

(f2.2)根据每一种资产，进行威胁识别，采用STRIDE模型，分析可能对资产造成损害的意外事件原因；

(f2.3)根据每一种威胁，建立安全机制列表；

(f2.4)根据安全机制列表，对应《信息技术安全评价通用准则》提取安全性功能测试需求。

上述基于剖面划分方法，获取软件安全性功能测试行为需求的过程中，首先需要建立的是UML用例图，再根据UML用例图建立活动图。UML用例图是捕获应用需求的主要手段，也是进行功能需求分析的主要方法，它是站在系统使用者角度描述系统可以处理的各种用例，通常一个系统功能至少需要一个用例进行描述，因此用例的集合就是系统的全部功能。而软件测试就是验证系统能否满足需求，即用例集合。使用UML用例图对被测软件系统的各个功能模块进行建模，为使用活动图对软件系统进行分解打下基础。

用例能够表现软件的功能需求，为了进一步细化用例，就需要获得软件系统执行的基本流程、异常流程、以及其它的流程，这些流程正是系统处理客户请求时的主要和次要执行场景，活动图可以很直观、方便地描述这些流程。

使用活动图对各个用例进行动态建模，以此来对应用程序进行第一层的分解，然后根据需要可以对活动图中的动作节点创建更深层次的活动图，如此迭代可以对整个软件系统进行逐层分解。但是创建活动图的主要目标是研究软件系统的组成，获取软件的资源、边界信息和数据流，而不是为了确定软件的工作原理，对软件系统的分解必须围绕这一目标进行。在完成目标的情况下，分解的层次不需要太深，那样会导致活动图太过复杂，不易进行下一步地分析。

在创建UML用例图与活动图的过程中，都包括资产的确定、威胁的识别以及安全性机制的确定，其区别在于分析的对象不同，例如在创建UML用例图中分析的对象为登录用例，而在活动图中分析的对象为登录用例中的验证用户信息活动。

在计算机领域，资产是指任何对用户有价值的东西，包括计算机硬件、通信设施、数据库、文档信息、软件、信息服务和人员等。在软件安全性测试领域，资产主要是指软件系统及其相关的数据和信息，即从软件安全方面考虑，需要保护的内容。在确定资产的过程中，测试者根据系统的UML用例图和活动图提取系统的相关资产，在UML用例图中，资产主要包括用例、用例的参与者、活动和数据流信息等；在活动图中，资产主要包括数据库、文档信息、数据信息、活动等。

威胁是指可能对资产造成损害的意外事件的潜在原因。在威胁识别的过程中，测试者可以根据STRIDE模型，分析资产可能受到的威胁、识别威胁，STRIDE模型主要包括以下六种威胁：

身份欺骗(Spoofing)：身份欺骗是指攻击者冒充其他用户访问系统，或者是恶意服务器冒充合法服务器。身份欺骗最常见的例子是恶意用户冒充合法用户对软件系统进行非法访问。

篡改数据(Tampering)：篡改数据是指恶意用户恶意修改系统数据。例如用户在未授权的情况下修改系统数据，或者通过非法手段修改他人数据。

否认(Repudiation)：否认是指用户否认从事某项活动，而系统也没有方法证明他从事了该项活动。例如，用户在系统中进行了非法操作，但是系统缺少日志，因而无法证明用户进行该项操作。

信息泄露(Information Disclosure)：信息泄露是指系统内部的信息暴露给未授权用户。例如，用户能够访问到他本应该没有权利访问的文件。

拒绝服务(Denial of Service)：拒绝服务是指系统拒绝合法用户的服务请求。例如，系统无法访问。

特权提升(Elevation of Privilege)：特权提升是指用户使用非法手段获得更大的系统权力，从而能够破坏甚至摧毁整个系统。

安全性机制是针对威胁识别过程中确定的每一种威胁，相应的减轻威胁的方法，对应于STRIDE模型，减轻各种威胁的安全机制可以总结如表5所示。

表5

《信息技术安全评价通用准则》(简称CC)是评估系统安全性的基本准则，CC定义了11个公认的安全功能需求类，其中每个类又包含子类。这些安全功能需求是表示软件安全要求的标准方式，也是提取软件安全性功能行为需求的依据。针对CC的11种安全功能需求，可以建立如表6所示的安全机制与CC的安全功能需求的对照表。

表6

通过表5和表6能够容易地找出每个威胁对应的CC中的安全功能需求，然后查看安全功能需求的子类，可以提取软件需要的软件安全性功能行为需求。

所述步骤(g)包括如下步骤：

(g1)根据步骤(f)获取的安全性功能需求进行功能细化描述。

根据图3所示，该登录过程只需要鉴别失败和秘密的规范两个子类。由此得到登录过程的安全性功能需求，如表7所示。

表7

根据表7得到安全性功能需求包括系统是否使用复杂的密码策略；系统在输入错误到达一定次数时，是否具有锁死账户的机制；以及系统在输入错误时，是否提供具体的错误信息。

(g2)根据步骤(g1)获取的安全性功能需求，描述已经非常详细，可以创建相应的时序行为场景，本例以“系统在输入错误到达一定次数时，锁死账户”需求为例说明。图6为三次错误登录限制时序场景。这一步不同的安全策略可能产生不同的时序场景，例如四次错误登录后就限制10分钟以后不能再进行登录操作，但是这些都是满足“系统在输入错误到达一定次数时，锁死账户”需求的不同安全策略。

所述步骤(h)包括如下步骤：

(h1)基于软件安全性缺陷，对通过步骤(e)和步骤(g)获取的软件安全性缺陷测试行为需求和软件安全性功能测试行为需求，进行行为预防机制、行为检测机制和行为响应机制分析。

测试行为预防机制即测试行为前部分，主要描述软件系统在需要覆盖的软件安全性缺陷被激活之前所应该具有的状态和行为；测试行为检测机制即测试行为过程部分，要描述软件系统怎样对基于软件安全性缺陷的非法访问进行检测；测试行为响应机制即测试行为后部分，主要描述在正确的检测完软件安全性缺陷测试行为后软件系统应该具有的状态和行为，从而防止软件安全性缺陷测试行为再次被执行。

(h2)对步骤(h1)中的三种机制，分别描述三种机制的三个阶段行为，即前置条件、处理行为和后置条件。

测试行为预防机制中包括防止软件安全性缺陷测试行为的前置条件、防止软件安全性缺陷测试行为前软件系统可以进行的预防活动以及防止软件安全性缺陷测试行为的后置条件；测试行为检测机制中包括测试软件安全性缺陷测试行为过程的前置条件、测试软件安全性缺陷测试行为过程的检测场景、测试软件安全性缺陷测试行为过程的检测结果，即测试软件安全性缺陷测试行为过程的后置条件；测试行为响应机制中包括测试软件安全性缺陷测试行为后前置条件、测试软件安全性缺陷测试行为后响应场景、测试软件安全性缺陷测试行为后响应行为以及测试软件安全性缺陷测试行为后后置条件。

(h3)分别将测试需求行为模型中的行为预防机制、行为检测机制和行为响应机制的三个阶段行为映射为UML状态图中的三个顶层复合状态。

(h4)依据典型安全性缺陷在每个阶段行为中的处理过程，将三个阶段分别映射为UML状态图中的行为预防状态子图、行为处理状态子图和行为响应状态子图，即形式化软件安全性测试行为需求模型，如图7所示，给出了映射后的访问控制缺陷的UML状态图。

使用UML状态图对测试需求行为模型进行描述，测试需求行为模型可以用图形化形式表示出来，以方便测试人员了解其结构和内部流程。但这种图形形式不是规范化的，不利于作为交流和自动生成测试用例的基础，因此需要使用UML图对其进行规范描述。由于测试需求行为模型图形和状态图较为类似，因此使用状态图对其进行描述。

UML状态图中可以包含多个状态层次，在描述中使用顶层状态图的复合状态描述测试需求行为的三种机制，使用状态子图描述机制中的处理过程。

在状态子图描述中，需要对行为机制的前置条件、处理行为和后置条件进行细化，使其分别对应一至几个子状态，再根据需求行为模型中的关系依次相连。以行为响应状态子图为例，如图8所示。

如果需要，可以将步骤(h4)中三个子图中的前置条件、处理过程和后置条件部分进一步细化为二级子图。对于处理行为比较复杂的行为机制，可以将处理行为再次映射为一个复合状态，而其内部处理过程使用二级子状态图进行描述。

所述步骤(i)包括如下步骤：

(i1)将步骤(h4)中获得的UML状态图存储为XMI文本格式。

XMI使用XML提供元数据信息交换的标准方法，规范了如何从UML模型生成XML文档。现有不少UML建模工具都支持将UML模型直接存储为XML格式，如MagicDraw UML。

(i2)依据文本转换算法将XMI格式的状态图转换为SCXML格式，即FSM的文本表示。

SCXML是一种基于Harel状态表的状态变迁语言，提供了通用状态机的描述方法，可以用来表示FSM。其元素对应关系如表8所示，对SCXML文本进行解析即可得到FSM图形格式。

表8

  FSM  SCXML  状态集  <State>  转换  <Transition>  初始状态  <Initial>  目标状态  <Target>  ……  ……

例如，对于有四个状态的系统来说，可以得到其有穷状态机如图9所示。

所述步骤(j)包括如下步骤：

一个确定性FSM可以定义为一个七元组M＝(S，X，Y，δ，λ，D，S₀)，其中：S＝(s₀，s₁，...，s_n)，s₀表示系统初始状态(initial state)；X是有限字符输入集合；Y是有限字符输出集合；δ：D →S是状态迁移函数，λ：D →Y是输出函数；D是M的属性，

基于FSM的测试用例为测试序列，它是指一个输入/输出序列，比如：一个测试用例tc＝(i₁/o₁)(i₂/o₂)...(i_k/o_k)，tc表示测试用例，i表示输入，o表示输出。它反应了对系统执行一段输入序列后，应该得到的预期输出序列是什么。测试用例的长度指测试序列的长度，测试用例集，指一系列测试用例组成的集合，TC＝{tc₁，tc₂，...，tc_p}，TC表示测试用例集。

本发明中测试用例(测试序列)/测试用例集采用基于FSM的UIO特征序列的方法生成。UIO特征序列是指对一个FSM，状态s在输入p₁下其输出是p₂，而任意其他状态在p₁的输入下输出都不是p₂，则称p₁/p₂为状态s的UIO序列，记作UIO(s)＝p₁/p₂。UIO序列可以是一组连续的输入/输出，用于唯一识别一个状态。

该步骤具体包括如下步骤：

(j1)对FSM进行预处理，所述预处理包括非完全FSM的完全化、非精简FSM的最小精简化和连通性说明。

基于FSM的软件测试一般要求规约状态机是完全的，确定的，精简的和强连通的等。因此测试用例生成方法的应用是有前提条件的，比如：基于UIO特征序列的测试用例生成方法要求规约有限状态机的每一个状态具有UIO序列，而要保证其条件必须使得有限状态机模型是最小的、完全的和强连通的。当构造的测试模型FSM不满足前提假设时，需对模型进行改进，使其满足。该步骤又具体分为如下步骤：

(j1.1)为规约中没有出现的输入增加定义，达到FSM的完全化；

对于部分定义的状态机，软件规约中没有出现的输入，可以通过对输出函数和迁移函数增加定义，使得未定义状态不产生输出或指向新定义的错误状态来达到FSM的完全定义。

例如，假设s是一个非完全定义的状态，x是未定义的输入符号，增加定义为δ(s，x)＝s或者指向一个错误状态，λ(s，x)＝null。

(j1.2)去除FSM中的冗余状态，使用等价的精简FSM取代原FSM；

非精简FSM中至少存在两个等价的状态，它的存在严重限制了UIO特征序列的生成。通常情况下，两个等价的状态存在表明系统存在设计缺陷，一定可以通过等价转换得到一个精简并一致的FSM。

(j1.3)对FSM中所有状态可达性和可复位性进行检查和说明；

通常情况下，规约描述的FSM都是连通的，软件实现FSM也可以认为是连通的，因为软件功能流程具有设计的连通性。而且，如果软件实现存在不可达的某状态，我们也不需要对其进行测试，因为这段功能实现处于“死”状态，程序永远不可能执行到功能对应的代码上去。因此可以在检查软件基础上认定FSM的状态之间都是可达的。如果FSM中所有状态是可达的，且是可复位的，那么该FSM是强连通的。

(j2)构造FSM的UIO树，并基于UIO树为FSM中的每个状态s_j生成UIO特征序列；

UIO树是指从精简FSM的初始向量出发，通过定义扰动函数产生的一系列新节点所组成的树，基于UIO树生成FSM的UIO序列是一种效率较高的UIO序列生成方法。该步骤又具体分为如下步骤：

(j2.1)从FSM的初始向量出发，通过定义路径向量和扰动函数，产生新的结点，构造UIO树；

初始向量是由FSM的初始状态组成的路径向量。通过对其定义扰动函数，可以产生一系列新节点，生成对应UIO树，树的深度可以通过满足基本剪枝条件进行限制。每个状态的UIO序列是由树根到唯一单一向量节点的路径构成。

路径向量是由状态对组成的集合，PV＝{v₁/v′₁，v₂/v′₂，...v_k/v′_k}，初始向量为IV(PV)＝{v₁，v₂，...，v_k)}；当前向量为CV(PV)＝{v′₁，v′₂，...，v′_k}。如果|PV|＝1，那么该向量为单一向量；如果路径向量的当前向量势为1，那么该路径向量为同种类向量。

扰动函数的输入域和输出域都为路径向量，定义为：Pert(PV，a/b)＝PV′＝{v_i/v″_i|v″_i＝δ(v′_i，a)∧λ(v′_i，a)＝b∧v_i/v′_i∈PV}。

例如，对步骤(i2)获取的有限状态机M，其生成的完全UIO树如图10所示。

(j2.2)遍历整个UIO树，对每一个单一向量叶结点，将从树根到该叶结点所形成的输入/输出序列连接为该单一向量初始向量对应状态的UIO序列。

根据步骤(j2.1)获取的UIO树，可以得到各个状态的UIO特征序列如下：

●状态A：

UIO(A)＝(0/1)(0/0)(0/0)；UIO(A)＝(0/0)(1/0)(1/0)(0/0)；

●状态B：

UIO(B)＝(0/1)(1/0)(0/1)；UIO(B)＝(0/0)(1/0)(1/0)(0/1)；

UIO(B)＝(1/0)(0/0)(1/0)(0/1)；UIO(B)＝(1/0)(1/0)(0/0)(1/0)(0/1)；

UIO(B)＝(1/0)(1/0)(0/0)(1/0)(1/0)(0/1)；UIO(B)＝(1/0)(0/0)(1/0)(1/0)(0/1)；

●状态C：

UIO(C)＝(1/0)(0/0)(1/0)(0/0)；UIO(C)＝(1/0)(0/0)(1/0)(1/0)(0/0)；

●状态D：

UIO(D)＝(1/0)(1/0)(0/0)(1/0)(0/0)；UIO(D)＝(1/0)(1/0)(0/0)(1/0)(1/0)(0/0)；

(j2.3)对每个状态，选取最短的一个UIO序列为其特征序列；

继续上述例子，可以得到最短特征序列为：

UIOmin(A)＝(0/1)(0/0)(0/0)；

UIOmin(B)＝(0/1)(1/0)(0/1)；

UIOmin(C)＝(1/0)(0/0)(1/0)(0/0)；

UIOmin(D)＝(1/0)(1/0)(0/0)(1/0)(0/0)。

(j3)基于UIO特征序列，对FSM的每一个状态迁移生成使用测试序列表示的测试用例，UIO特征序列将作为测试序列生成时的状态验证序列，生成的测试序列覆盖FSM的每一个状态迁移。该步骤又具体分为如下步骤：

(j3.1)对FSM中的每个状态迁移(s_i，s_j；x/y)，使用Dijikstra算法确定s₀到s_i的最短路径，得到s₀到s_i最短输入/输出序列；此处假设FSM是可复位的。如果此FSM不可复位，则可以利用FSM的自引导序列确定系统当前状态，然后再利用Dijikstra算法找到当前状态到迁移头状态的最短路径。

(j3.2)依次连接s₀到s_j的输入/输出，得到每个状态迁移(s_i，s_j；x/y)的测试用例(reset/null).SP(s_i).(x/y).UIO(s_j)；

所述步骤(j3)中，s₀，s_i，s_j表示FSM的状态；(s_i，s_j；x/y)表示从状态s_i迁移到状态s_j，其中输入为x，输出为y；reset表示将FSM复位到初始状态；SP(s_i)表示初始状态到状态si的最短输入/输出序列。

继续步骤(j2)中的例子，根据步骤(j2)得到的UIO特征序列，可以得到有限状态机M的测试用例如表9所示。为有限状态机M各个迁移的测试用例

表9

以上所述仅是本发明的优选实施方式，应当指出：对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。