基于模型的嵌入式软件测试技术研究

张 龙

(中国航空工业集团公司洛阳电光设备研究所,河南 洛阳 471009)

0 引言

武器装备软件的开发模式正发生深刻变革,从传统的基于文档驱动的开发模式向基于模型驱动的开发模式(以下简称“MDD模式”)转变。MDD模式是由OMG组织提出的一种软件开发框架,其核心思想是以模型,而非代码为中心的软件开发模式,来达到分离问题域、业务逻辑以及实现平台的目标。MDD模式的逐步普及,对软件开发、测试行业都带来了深刻的变革。

1 开发模式的变革

传统的基于文档驱动、代码复用的开发模式技术滞后,不能快速响应用户需求。文档驱动的开发模式,以明确的产品需求为前提,实现软件设计和编码的信息传递。但现实项目运行实践中,存在如下问题[1]:

(1)文档方面,需求获取难度较大,自然语言的传递信息容易有歧义,且文档的维护工作量大,难以保证文文、文实一致性。

(2)代码方面,设计的实现需要人工手动编码,存在人为引入错误的风险,同时代码不能支持需求和设计的早期形式化验证。

MDD模式逐步成为业界主要的软件开发框架,并受到越来越多公司的青睐,如空中客车公司、航空工业集团等。模型驱动使得软件开发人员能可视化地理解所开发的软件系统,减少沟通成本,避免传统软件文档描述的模糊性;同时支持在开发初期,验证软件行为、安全性,尽早发现软件缺陷;其自动化的代码生成功能,也极大地加速软件开发效率[2]。

2 测试面临的挑战

MDD模式是以建模为核心工作,通过建模完成需求开发、架构设计、详细设计等工作,并针对模型开展分析、评审、测试与评估等验证工作,设计、验证的数据在模型与模型之间传递,通过模型驱动软件系统的实现过程。在新模式下,传统的软件测试模式和技术已不能很好地适应MDD模式的要求,软件测试面临新的问题和挑战,主要原因如下:

(1)开发模式的不同。传统的开发模式是基于文档驱动的通过文档完成需求开发、架构设计、详细设计等工作。测试人员通过理解需求文本获取软件测试需求,来验证和评估软件的功能性、接口、安全性等指标,软件测试和开发相对分离;MDD开发模式下,是以模型为核心工作,软件需求分析、设计实现、测试工作分别整合到了软件需求模型、软件设计模型、软件测试模型中,在模型之间传递需求、设计、验证数据,软件测试和开发高度耦合。

(2)测试对象的不同。传统的测试对象主要是自然语言和编程语言,主要方法有文档审查、代码审查、静态分析、动态验证;MDD开发模式下,软件测试的对象主要是统一的形式化语言,主要方法有模型检查(MC)、定理证明(TP)、基于模型的动态测试技术、时间堆栈分析等高级验证手段[3]。

因此,对MDD开发模式下软件测试流程和软件测试技术的研究就变得十分必要和迫切。

3 基于模型的测试流程和关键技术

3.1 基于模型的测试流程

MDD模式,可将软件的测试验证工作大大前移,并在需求分析、概要设计、详细设计、代码生成等全生命周期执行基于模型的测试和迭代验证,开发和测试是螺旋前进的,互相验证,可规避如瀑布模型、V模型等某一流程的固有缺陷。其支持在开发过程的不同阶段,分别构建模型在环(需求模型、设计模型在环)、代码在环(基于模型生成的代码在环)、产品在环(基于模型生成的代码加载到处理器等产品环路)的多级软件测试过程。该验证方式区别于传统验证,具有手段单一、效率低的特点,其成本更低,效率更高,敏捷性和灵活度更好。

3.2 基于模型的测试技术

MDD模式中,针对测试需求由自然语言到模型语言的转变,测试人员需要基于统一建模语言(UML)构建具体的测试需求模型,并基于测试需求模型设计测试激励和规程,在验证的不同阶段结合测试框架自适应生成相关的测试激励,来达到分层验证的目的。上述过程贯彻MDD模式的需求分析、概要设计、详细设计阶段、代码生成阶段。整个测试过程主要的验证技术如图1所示。

图1 基于模型的软件测试技术

3.2.1 静态验证技术

在软件系统需求分析、概要设计、详细设计等早期阶段,可以进行模型的早期验证。主要技术手段有软件形式化验证技术和故障树分析法,其中形式化验证技术又分为定理证明和模型检验2种。通过模型的静态验证,可以在需求分析和设计早期,找出数据流不匹配、死循环等一系列错误,并提早进行错误定位,及时归零。

(1)定理证明为使用逻辑的语言和方法对软件中的算法、逻辑等进行规约描述,明确软件适用的公理,建立软件的推理规则,依据公理和推理规则证明软件的功能正确性。

(2)模型检查技术在具体使用时,可借助基于时间自动机模型的分析、SysML块依赖图模型的分析、基于状态事件故障树模型的分析等方法来开展。

3.2.2 测试需求模型的构建技术

依据软件业务逻辑、接口数据元素、接口约束、FTA故障树、FMEA软件失效模式等分别识别软件功能测试需求,性能、接口、边界、安全性等非功能性测试需求,以此确定测试需求的内容、范围及边界。

对软件测试需求进行建模主要有软件功能性测试需求建模、非功能性测试需求建模。多数情况下,功能性测试需求模型可由软件需求进行分解、合并后得到,使用UML语言中的用例图、活动图、状态图、时序图等对功能性测试需求建模。非功能性测试需求获取较为困难。以安全性需求为例,一般有如下方式。

(1)基于FTA的软件故障树分析识别软件安全性要求。

使用FTA方法从软件需求中提取软件故障树信息,从而识别出导致软件安全或不安全的基本事件、基本路径、影响范围和对象等软件安全性要求。

(2)基于FMEA的软件失效模式分析识别软件安全性要求。

使用FMEA方法从软件需求中提取软件潜在失效模式及后果信息,将潜在失效模式描述为Input-Process-Outpt形式的导致软件不安全的功能逻辑需求,识别为软件安全性要求。

(3)软件安全性要求规约。

对于使用FTA、FMEA方法得到的软件安全性要求信息,再使用形式化规约方法,将自然语言转化为形式化的UML语言,用以将安全性要求描述出来,并转化为一组与软件安全性需求有关的对象、属性、参数和指标,从而为安全性需求建模提供直接输入。

3.2.3 测试规程描述和生成技术

依据软件功能性测试需求模型、非功能性测试需求模型,识别软件全部的基本事件、基本路径、异常路径,生成测试用例集。

(1)依据基本逻辑生成测试用例规程。

依次对照功能性测试需求模型、非功能性测试需求模型,提取模型数据文件中面向相关功能、过程的逻辑信息、状态迁移条件、时序信息等过程信息,结合逻辑信息、状态迁移条件、时序信息生成测试用例规程。

(2)依据接口元素模型生成测试用例输入。

依次对照功能性测试需求模型、非功能性测试需求模型,提取模型数据文件中面向相关功能、过程的数据源、数据目的、接口约束等信息,结合测试框架,生成测试输入。在测试用例输入数据的生成方面,可借助传统的测试用例数据生成方法,如等价类、边界值,生成面向工程实践的最优解。

3.2.4 测试驱动和测试框架构建技术

针对功能性、非功能性测试用例模型,利用建模工具如Rhapsody、Scade构建支持单个用例运行的软件测试驱动,并提前设置测试用例的预期结果,自动判读是否执行通过;利用建模工具构建软件测试框架,支持测试用例的批量运行和批量判读。测试框架可理解为贯穿基于模型的整个测试过程的软件架构,其支持软件测试用例的自动化批量执行、自动判读,在Rhapsody、Scade工具中可使用功能结构图、类图等对软件架构建模。

3.2.5 测试充分性评估方法

测试充分性评估方面一般使用测试需求的覆盖率分析、结构覆盖分析(SC覆盖、DC覆盖、MC/DC覆盖)、数据耦合覆盖和控制耦合覆盖分析等方法,辅以软件最坏运行时间(WCET)和堆栈内存分析等方法保证基于模型的软件测试的充分性要求。具体有如下要求。

(1)测试需求的覆盖率分析,应开展如下分析: ①针对每一条标识的高层需求都有一条或多条测试用例通过追踪矩阵来对应,该追踪矩阵用于验证高层需求是否被实现; ②针对每一条测试用例在追踪矩阵里都有一条或多条高层需求相对应; ③测试用例应包括正常和鲁棒性测试。如通过SCADE Suite MTC覆盖率的评审来证明SCADE 模型对高层需求的覆盖率满足要求;基于需求的测试可能不能完整地达到模型覆盖率要求,因此模型覆盖率可以通过附加验证来达到要求,如分支覆盖。

(2)SC覆盖和DC覆盖分析基于源代码进行,使用Testbed、SCADE MTC工具分析和人工分析相结合的方法。

(3)针对代码在执行基于需求的测试,覆盖率未达到时,应执行附加分析,含以下4种情况: ①需求不充分。比如缺鲁棒性需求,需求需要修改或完善,从而产生附加的测试用例/规程。 ②测试不充分。应当补充测试用例/规程。 ③附加代码。附加代码可以保留在源代码中,但不能在目标代码中,软件生成过程(如:通过编译或链接去除)应保证其不会出现在目标代码中。 ④非激活代码。应当做一些组合的测试和分析来证明非激活代码不会被意外地执行或工作。

4 结语

本文结合开发模式的变革介绍了软件测试的趋势,并详细介绍了基于模型的测试流程以及基于模型的测试技术。通过在实际的武器装备软件测试中推广使用,表明其相较于传统测试技术,更能适应于MDD开发模式的需要,同时其需求传递误差小,测试效率更高,能更快速地响应用户需求。但相较传统的测试技术,基于模型的软件测试技术在工程实践中仍处于成长阶段,需要进一步的研究,如文中提到的形式化验证技术、基于模型的测试用例生成技术等。