基于AADL的IMA系统健康监控的测试方法与流程
本发明涉及软件测试技术领域，更具体的说是涉及一种基于aadl的ima系统健康监控的测试方法。
背景技术：
故障管理(faultmanagement，fm)是ima系统系统的重要功能之一，其主要负责在系统运行过程中所发生故障的检测、定位、隔离及消除工作。健康监控软件是故障管理的重要组成部分，由操作系统提供，负责监控系统中硬件、操作系统软件及应用软件的错误和故障。健康监控软件的基本功能是要检测到故障，为了测试健康监控软件的功能，需要激发故障，当故障出现时，观察健康监控软件是否监测到故障，从而达到测试的目的。
目前面向ima系统的测试方案，主要采用软件模拟或仿真技术，通过对ima系统系统建模后，通过数字仿真的方法解决软件开发阶段的资源分配问题，而现有的仿真测试环境均是面向ima应用软件的测试环境，缺乏针对ima故障管理，特别是对于ima进程级、分区级和模块级的三层的故障管理机制，缺乏包括故障管理的建模、用例生成、故障触发、响应采集等一系列的测试方法。
因此，如何实现ima故障管理的健康监控软件的完整测试是本领域技术人员亟需解决的问题。
技术实现要素：
有鉴于此，本发明提供了一种基于aadl的ima系统健康监控的测试方法，针对ima故障管理中的健康监控功能，提出相应的测试需求，使用aadl对ima系统故障管理进行建模，为ima系统测试环境提供故障管理信息，通过对ima故障管理测试用例进行分析，通过修改程序代码和配置实现故障触发，从而验证健康监控功能。
为了实现上述目的，本发明采用如下技术方案：
一种基于aadl的ima系统健康监控的测试方法，包括以下步骤：
步骤1：分析ima系统健康监控和故障处理的测试需求；
步骤2：采用aadl语言和错误模型附件ema根据测试需求，建立aadl故障模型；
步骤3：由所述aadl故障模型生成测试用例，采用所述测试用例触发ima系统故障；
步骤4：监控所述ima系统运行状况，获得测试结果；所述测试结果指ima系统的故障响应及响应动作结果是否与预期结果相符，如果结果相符，则说明健康监控的配置和运行状况良好。所述故障响应为恢复动作。
优选的，所述步骤1中所述测试需求从所述ima系统的配置表、分区配置表和健康监控代码中获得。
优选的，所述步骤2中建立aadl故障模型的具体过程如下：
步骤21：提取所述测试需求，获得故障类型、所需的健康监控层次、针对相应故障做出的故障响应；
步骤22：利用所述ima系统中的配置表根据所述ima系统的进程、所在分区或所在模块配置相应的所述故障响应，从而获取所述配置表中定义的发生故障的故障位置，所述故障位置包括进程位置、分区位置或模块位置；如果在进行发生故障则为进程级故障，所述进程级故障指所述ima系统软件程序中的变量、信号或通道等；
步骤23：进行状态转换推断，根据配置表、分区配置表和健康监控代码，推断初始状态、故障发生时状态和发生后预期的状态改变过程，并进行记录；
步骤24：根据所述ima系统的结构将故障的传播端口和连接的路径列入所述aadl故障模型的内部，进行所述aadl故障模型内的错误传播建模；
步骤25：确定所述故障类型的故障属性，获得故障概率和错误通过所述路径进行传播的传播概率；
步骤26：根据所述故障类型、所述健康监控层次、所述故障响应、所述故障位置、所述状态转换、所述传播端口、所述路径、所述故障属性和所述传播概率，采用所述aadl语言和所述错误模型附件ema中对应的元素进行描述建立所述aadl故障模型。
优选的，所述健康监控层次包括进程级、分区级和模块级，分别进行建模测试。
优选的，所述步骤3中的所述测试用例采用tc＝{a,e,a′,m}的四元组表示，所述a和a′分别表示所述ima系统故障发生前的结构和状态集、故障处理后的结构和状态集；e＝{e0,...,ep}表示a中触发的故障集；m表示a的运行环境；a进一步分解为a＝{pa,sa}，在所述分区级的测试中，a是分区内应用程序任务及任务状态的集合：其中，pa代表所述应用程序的分区任务集合，sa＝{s0,...,sn}是任务状态集合；在所述模块级的测试中，pa表示被测分区或分区集，sa表示分区状态。
优选的，采用所述测试用例触发所述ima系统故障实现错误激励，所述错误激励包括两种方法，一种是针对所述ima系统程序的所述错误激励，对所述ima系统的代码采取插入故障代码的方式触发；另一种是针对所述ima系统逻辑配置表的所述错误激励，对所述代码进行修改的方式触发；所述ima系统的进程运行在分区中，所述配置表包括面向整个模块的系统配置和面向模块中的单个分区的分区配置，通过修改所述系统配置或所述分区配置，分别.激励相应的所述分区内的分区级错误或进程级错误。
经由上述的技术方案可知，与现有技术相比，本发明公开提供了一种基于aadl的ima系统健康监控的测试方法，采用aadl错误模型附件对ima系统故障管理的测试需求进行建模，针对可以监控到的错误类型建立aadl故障模型，根据aadl故障模型进行有针对性的错误类型的错误激励，并且根据多种激励方式产生相应的测试用例，利用测试用例触发ima系统故障，获得测试结果，判断ima系统健康监控是否准确可靠。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。
图1附图为本发明提供的ima系统健康监控的测试方法流程图；
图2附图为本发明提供的错误状态转换示例示意图；
图3附图为本发明提供的故障管理结合关系示意图。
具体实施方式
下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
本发明实施例公开了一种基于aadl的ima系统健康监控的测试方法，包括以下步骤：
s1：分析ima系统健康监控和故障处理的测试需求；测试需求从所述ima系统的配置表、分区配置表和健康监控代码中获得；
s2：采用aadl语言和错误模型附件ema根据测试需求，建立aadl故障模型；
s21：提取测试需求，获得故障类型、所需的健康监控层次、针对相应故障做出的故障响应；
s22：利用ima系统中的配置表根据ima系统的进程、所在分区或所在模块配置相应的故障响应，从而获取配置表中定义的发生故障的故障位置，故障位置包括进程位置、分区位置或模块位置；如果在进行发生故障则为进程级故障，进程级故障指ima系统软件程序中的变量、信号或通道等；
s23：进行状态转换推断，根据配置表、分区配置表和健康监控代码，推断初始状态、故障发生时状态和发生后预期的状态改变过程，并进行记录，保存至aadl故障模型；
s24：根据ima系统的结构将故障的传播端口和连接的路径列入aadl故障模型的内部，进行aadl故障模型内的错误传播建模；
s25：确定故障类型的故障属性，获得故障概率和错误通过路径进行传播的传播概率；
s26：根据故障类型、健康监控层次、故障响应、故障位置、状态转换、传播端口、路径、故障属性和传播概率，采用aadl语言和错误模型附件ema中对应的元素进行描述建立aadl故障模型；
s3：由aadl故障模型生成测试用例，采用测试用例触发ima系统故障；
健康监控层次包括进程级、分区级和模块级，分别进行建模测试；
测试用例采用tc＝{a,e,a′,m}的四元组表示，a和a′分别表示ima系统故障发生前的结构和状态集、故障处理后的结构和状态集；e＝{e0,...,ep}表示a中触发的故障集；m表示a的运行环境；a进一步分解为a＝{pa,sa}，在分区级的测试中，a是分区内应用程序任务及任务状态的集合，其中，pa代表应用程序的分区任务集合，sa＝{s0,...,sn}是任务状态集合，包括初始状态、执行状态、挂起状态和执行任务状态等；在模块级的测试中，pa表示被测分区或分区集，sa表示分区状态；
s4：监控ima系统运行状况，获得测试结果；测试结果指ima系统的故障响应及响应动作结果是否与预期结果相符，如果结果相符，则说明健康监控的配置和运行状况良好。故障响应为恢复动作。
为了进一步优化上述技术方案，采用测试用例触发ima系统故障实现错误激励，错误激励包括两种方法，一种是针对ima系统程序的错误激励，对ima系统的代码采取插入故障代码的方式触发；另一种是针对ima系统逻辑配置表的错误激励，对代码进行修改的方式触发；ima系统的进程运行在分区中，配置表包括面向整个模块的系统配置和面向模块中的单个分区的分区配置，通过修改系统配置或分区配置，分别.激励相应的分区内的分区级错误或进程级错误。
实施例
错误模型附件ema用于对构件、连接的错误时间和错误概率等方面的属性进行建模，用于描述系统模型运行的可靠性信息，其描述了在发生不同故障的情况下导致系统处于不同的错误状态的信息。ema为aadl定义了多个关键字用于描述系统的故障、故障传播及相关属性，为了进一步描述故障及传播条件和关系，ema还增加了故障/错误的变换和属性字段，实现了规定状态转换的条件的描述。
错误模型附件ema中可以包含单个构件的故障信息，包括构件的故障状态、故障状态转换的路径和故障的随机参数。构件间的关于故障影响关系的可靠性信息包括故障传播的输入与输出条件和构件的故障状态转换条件。除此之外，aadl故障模型还关注了故障的发生概率，可以据此灵活地选取模型的规模。aadl故障模型类型中，故障状态定义为初始化状态和非初始化状态；故障事件可以包括内部故障事件和传播事件。aadl故障模型可以实现由故障事件引起的故障状态的转换路径以及故障传播的路径。aadl故障模型类型是这些属性项目的列举，而错误模型附件ema中的故障模型实现表示这些属性项目的动作或者关系，可以对应多个实现。同时，发生概率属性指定了故障事件的发生概率的随机参数。使用错误模型附件ema进行可靠性建模时需要考虑到某一个构件出现故障事件时对其他构件的影响，这时就需要考虑到故障传播的影响。
故障传播主要是确定ima系统内部产生的数据故障是如何在软件系统内传播的，即故障传播现象及规律。在信号的级别对软件系统进行故障传播分析，这里的信号是指软件系统内各模块间传递的参数和信号(包括消息型和事件型信号)以及系统从外界环境获取的参数。通常软件提供的某一项具体任务或服务是由相互作用的多个软件模块所构成的，这几个模块可能位于相同的分区中，也可能位于不同的分区中，当故障在其中出现时，就有可能传播到其他的与其交互的分区(或功能模块)中。由上述的故障传播的定义可得到相应的基于aadl的错误模型附件的aadl故障模型中的故障传播。
图2所示为错误状态转换示例，为存在一个分区中的错误模型附件的抽象表示，其主要定义了以下的故障模型类型：
(1)初始故障状态：无故障；
(2)故障状态：重启进程、重启分区、忽略、关机；
(3)故障事件：即上面定义的截止时间溢出、应用错、数值错误、非法访问；
(4)故障传播：无接收数据、错误接收数据、无发送数据、错误发送数据。
故障模型实现规定了状态转换的条件。其中包括以下几个部分：
(1)故障状态转换：由无故障的初始状态，经过故障事件的激励转变为相应的故障状态。如无故障-截止期限溢出-分区重启、无故障-应用错误-进程重启、无故障-非法请求-忽略。这些信息需要通过读取配置软件(蓝图)中的信息来完成相应的转换过程。故障状态转换模拟了健康监控过程中从初始无故障状态到故障发生以及相应的恢复动作的过程。
(2)故障发生概率：针对每一种错误定义了相应的故障发生概率。如截止期限溢出的发生概率即为1*10-4。
(3)故障输入与输出(guardin和guardout)：表示故障传播输入和输出的条件，通过规定的故障传播规则(此模型中，当输入端口1和端口2只有一个无数据输入时会进行标记；如果两个输入端口均为无数据输入或者一个是无数据输入而另一个是非法数据输入，则引入的是无数据输入；如果两个输入端口输入的都是非法的数据，则引入非法数据)，将当前构件端口收到的其他源发送的故障传播输出或故障状态，根据规则映射到当前构件的传播输入事件。
(4)描述故障状态转换的触发事件产生的条件(guard_event)：如果两个输入端口有一个无数据输入，那么输出端口1没有正常的数据输出；同理，这样的情况下输出端口2也没有正常的数据输出。
在针对ima故障管理做测试时，需要在不同级别针对被测构件的不同状态分别进行测试。在图3中，故障集em为测试中可注入的故障集合，例如{故障1，故障2，...}，那么注入的组合故障集合包括多种故障组合形式，例如组合故障集合e＝{{故障1，故障2}，{故障1，故障3}，...}，可以表示为
故障属性可表示为如下所示多个维度的表达方式：
e＝{cl,cd,ct,cp}
其中，cl代表故障属性描述中属性单元的故障位置：cl∈{var,messsage,channel,signal}，cd代表相应失效的故障域类型，有值域和时域类型：cd∈{value，time}。ct代表故障的触发方式，包括时间型和事件型：ct∈{time,event}。cp表示故障的持续性，其中包括瞬态故障、间歇故障和永久故障：cp∈{transient,inttermittent,permanent}。
故障属性描述中属性单元cl代表故障位置，cd代表相应失效的故障域类型，有值域和时域类型，ct代表故障的触发方式，cp表示故障的持续性。故障类型cd和故障位置cl说明要注入什么类型故障和在何处注入故障，故障持续时间cp说明了故障的作用域，另外，可以根据故障触发方式ct控制故障相对于某事件或状态满足时注入故障，可生成的测试用例如表1所示。
表1ima系统分区故障管理用例表
采用测试用例中定义的触发方式触发ima系统故障，在进行错误激励的过程中，需要针对故障的特点和运行规律，约定一套故障规约的描述方法，对ima中的错误激励和测试过程中有关故障的事件进行定义，并对测试过程中的状态和转换关系进行描述，作为故障仿真和测试方法的实现依据。
在式中，e＝{e0,...,ep}触发的故障集又可以看作是故障元件fa和故障事件ia的集合，故障集包括截止期到、内存非法操作、非法请求、栈溢出和操作数错等，其可以定义为：
e＝{fa,ia}
上式中定义触发关系集ta表示初始状态、故障元件、故障事件与结束状态之间在故障仿真中的触发关系，可表示为
ta＝sa×fa×ia×s′a
其中，sa指初始状态，sa′指结束状态。在ima系统中，分区具有四种操作模式，分别为：空闲模式(idle)、正常模式(normal)、冷启动模式(cold_start)和热启动模式(warm_start)，它们之间的转换也具有确定的转换规则。同样地，进程也具有四种状态，分别为休眠态(dormant)、就绪态(ready)、运行态(running)和等待态(waiting)通过进程调度，它们能在四种状态之间进行转换。
测试过程需要与系统的运行状态在某种程度上的同步。因此，测试行为执行的时刻需要参考负载运行中的特定状态或事件，由确定的系统状态、输入/输出事件来触发相应的错误激励。由于ima系统与传统软件相比具有时空隔离、操作系统通用等特殊性，错误激励的方式与传统航电软件也是有区别的，这里可以概括为两大类错误激励的方法：一种是针对程序的错误激励方式，这种类似于传统航电软件对应的程序变异的方法；另一种是针对配置表(蓝图)的错误激励方式，修改系统以及分区的配置，这样可以激励相应的分区级或进程级的错误。
在ima系统中，触发关系表现为状态、故障、输入输出共同影响的结果，如在分区级故障恢复动作中，对于分区超时这样的故障，分区处于初始化的状态时，可以执行忽略的操作，但如果处于正常工作的状态时就需要关闭或者重启该分区，这是操作系统的要求和开发人员或系统集成人员进行配置的共同作用。
健康监控在不同的状态检测到相同的故障时，会体现为不同的触发关系，例如：对于分区级的分区超时故障，当分区处于初始化状态时可以直接忽略，但是在其他的情况下就需要重启该分区。这里的触发关系即可表示为tignore＝(timed,initial,blueprint,∞)。
健康监测测试方法：
面向ima故障管理的测试，要求被测软件激发故障的过程可以被控制，同时满足实时性和嵌入式的指标。ima系统需要在运行中激发故障，同时控制软件的执行。这样才能在代码或指令级别上重复注入的相同故障，即故障重现。实时嵌入式软件动态二进制故障触发需要动态插装引擎，无代码的软件动态触发使用了系统的函数调用，有代码的动态二进制故障触发使用调试器，而调试器同样需要系统提供的调用。无代码动态调试器会将语句级别的断点通过计算转化为指令级别的中断，因此，本质上无代码的二进制故障触发与有代码的二进制故障触发都是会暂时中断或阻塞程序的运行，它们的故障触发依赖故障触发引擎。
根据故障属性e＝{cl,cd,ct,cp}定义，完整描述一个故障触发操作的信息需要表达故障发生的位置cl，需要触发的故障值cd，所触发故障的持续性时间cp，以及决定触发故障激发时刻的ct。因此，故障触发描述原语中设计了故障触发操作模板，对故障触发操作的静态信息进行统一描述与封装。
故障触发的方式主要分为基于代码的方式和基于蓝图的方式，其中基于代码的方式又可以细分为直接激励和基于故障传播的间接激励。在进程级的层次上，每个分区内部软件的运行方式和传统的嵌入式软件是没有差异的，可以使用一些传统的故障触发的方式，比如接口变异、代码变异、断言违背等；另一种方式是寻找arinc653协议的操作系统接口函数进行直接的调度修改。同时，在更高一个层次上，通过控制该进程所在的分区的活动情况，也可以产生相应的错误。而在分区级的层次上，则可以通过修改配置表中该分区分配的内存，使其小于需求的最小值来实现。同时，这两种激励方式都可以通过模型来完成。
a)触发事件类型
在分区内和分区间通信的过程中，触发事件是系统的外部输入/输出信号或内部驱动信号。仿真测试模型触发事件形式包括消息和数值两种类型。仿真测试模型指实际对被测系统实施测试时，模拟故障发生的机制。
消息类型事件一般指事件在通讯系统中以消息的形式存在，在到达目的地后被放到触发事件队列中。事件队列用来识别和响应同时在多个通道上传输的触发事件，多个来源的事件流进同一管道，并采取先进先出(fifo)的机制。事件队列为每一个事件提供一个独特的位置，同时还保存最近发生事件的历史记录，从而允许应用程序处理同时发生在多个通道上的事件。消息类型事件主要存在仿真测试模型之间、仿真测试模型与被测系统之间用于传输消息通讯、同步控制或状态转换的一类数据，其操作方式主要以队列类型操作方式完成消息的“写”与“读”操作，“写”将把新写入的消息添加到相应硬件通道存储的队列尾端，而“读”操作将返回硬件通道存储队列的最前端消息。
数值类型指仿真测试模型之间以及与被测软件之间的具有明确取值的那些数据，其操作方式主要以采样方式完成“写”与“读”操作，“写”操作将把对硬件的写入值覆盖以前的值，而“读”操作将返回最后一个写入硬件通道的数据。按照传输数据类型分别对消息性和数据型两种事件进行定义如下：
从数据传输的角度来看，一个消息型事件具有以下基本特性：消息源、消息目的、消息类型和消息内容。ima系统对实时性要求比较严格，因此会出现很多的同步、轮转和优先级抢占的机制，因此消息型时间设dm为一个消息型数据，则：
dm＝(in,out,tm,vm)
上式中：
in：消息源，产生消息或发起消息传输的实体；
out：消息目的，接收消息的实体；
tm：消息类型，消息的类型包括控制命令、信号量等；
vm：消息内容，消息的具体内容，符合消息类型要求；
在ima健康监控的测试过程中，可以对分区之间或者进程之间的消息以及对采样或者队列端口的连接关系进行修改，以触发相应的故障类型。例如，priv_violation(优先级混乱)的错误，这是进程和分区调度时都会遇到的问题。依赖于调度信息和信号量输入的指令，将优先级不同的两个分区的相应端口对应顺序进行对调，可以激励分区调度紊乱的错误；而寻找调度有关的代码段是另一种方式，通过修改相关代码页可以实现同样等级的故障触发。
一个数值型事件具有以下基本特性：数据源、数据目的、数据类型、数据值、数据的时间标签和传输介质。设dv为一个数值型事件，则：
dv＝(sv,ev,tv,vv,fv,mv)
上式中：
sv：数据源，产生数据或发起数据传输的实体；
ev：数据目的，接收数据的实体；
tv：数据类型，数据类型的计算机表示，整型、浮点、字符等；
vv：数据值，数据取值的具体内容，满足数据类型要求；
fv：时间标签，记录数据进行传输的开始与完成时刻，用于测试分析；
mv：传输介质，数据传输经过的io接口类型。
对于数值型事件特性，涉及数值的故障都可以用这种方法进行激励。修改数据的上述六项属性在激励的过程中均可以产生数值错误(numeric_error)这样的故障。同时，一个进程、分区或模块如果和其他进程、分区或模块耦合程度较高，有比较大的概率引起故障传播。
b)故障描述方法
在ima系统中，输出结果受状态、故障、输入共同影响，如在分区级故障恢复动作中，对于分区超时这样的故障，分区处于初始化的状态时，可以执行忽略的操作，但如果处于正常工作的状态时就需要关闭或者重新启动该分区，如果需要的话还要进行重构的动作，这是操作系统的要求和开发人员或系统集成人员进行配置的共同作用。健康监控在不同的状态检测到相同的故障时，会体现为不同的触发关系，例如：对于分区级的分区超时故障，当分区处于初始化状态时可以直接忽略，但是在其他的情况下就需要重新启动该分区。这里的触发关系即可表示为：
tignore(timed,initial,blueprint,∞)＝true
测试需求主要指的是在ima系统中配置的健康监控可以检测并处理的错误类型。由于需要建模的错误不仅仅是一个在系统中出现的点，还可能牵扯到系统的架构、错误发生时的状态以及对其他部分的影响，因此需要使用一定的语言进行表达。借鉴错误模型的形式化表达方式，可以对ima错误的测试需求进行形式化的统一表达，从而为建模进行一些前期的工作。
例如，ima系统中的截止时间溢出(deadline_missed)故障，在层次结构上属于进程级，那么依据故障四元组表示方式里的“错误”，它可以表示为：
fdeadline_missed＝{loop,∞,100ms,permanent}
而分区级的故障需要考虑一些更底层的概念，如分区配置错误(partition_config_error)属于分区级错误，可以表示为：
fpartition_config_error＝{part1_mod,event,10ms,transient}
同时，还需要考虑故障发生时系统的状态，这个状态也分为不同的层次，在进程级的故障一般情况下需要考虑的是进程所处的状态，但是分区的状态在很多情况下也是需要考虑的。分区级的故障一般会根据分区所处的不同状态选择相应的故障处理动作，这些动作都是在健康监控表中可以进行定义的。
在建模过程中需要输入和输出，这也是故障传播的先决条件，而数值型和事件型的输入和输出分为分区内的通信方式和分区间的通信方式。其中分区内的信号量、黑板、消息队列等属于消息类型的事件，用于处理系统调度和功能相关的结构，这样可以以进程端口的形式进行表达，如
dm＝(in,out,tm,vm)＝(process1,process2,semaphore,synchronization)
可以表示这个消息是由process1发送到process2，是一个信号量的消息类型，作用是进行同步，当然也可以用来互斥(exclusive)，而且对于进程1来说属于output，对于进程2来说属于input，如果进程1因为内部的问题或者在传输信号时出现了问题，而传输到进程2时对该进程造成了影响，那么就可以说在这个过程中发生了故障传播。错误隔离也是健康监控设计时的重要理念之一。
分区间的输入和输出主要包括采样和队列，提供了对不同实时性要求的通信方式的解决方案，分区对外的接口主要是可配置的端口，类比于进程间通信更加突出了端口的概念，因此同样类比于进程端口的概念，使用分区端口将通信进行表示，如：
dm＝(in,out,tm,vm)＝(partition1,partition2,queue,rtmessage)
表示分区1向分区2传输一个队列，发送了一组获得的实时数据。
这样，可以把用自然语言描述的故障过程通过抽象画的方式进行更深层系的表达，使其具有一定的通用性和标准性，为建立错误模型提供了条件。
c)故障触发方法
通过对被测软件的代码采取插入故障代码的方式或者对原来的代码进行修改，可以在指定的代码段激发故障。基于代码的激励可以通过对两类代码的修改来完成。
(1)对应用软件的代码进行修改或者插入。
如截止期到达(deadline_missed)的故障可以通过以下方式进行激励：在代码中寻找循环语句，将其循环结束条件去除或者设为不可达；或在代码中合适的地方插入无限循环的语句，使得该进程在截止期内不能执行完毕。
(2)调用或者插入代码的相应应用程序接口(api)。
还是截止期到达的故障，同理，在ima标准提供的应用程序接口中，存在时间延迟等接口可以产生该故障。这里可以使用timed_wait函数，强制进程挂起指定时间，从而造成截止期故障。
(3)通过故障传播的方式。
如果程序中的某些参数依赖于其他的进程或者分区而它自己的修改受到一定限制，那么故障传播需要的参数可以在错误传播的前一个子节点进行修改和故障激励，从而引发这个分区的故障。在本例中一个非常显而易见的方式就是通过修改被激励错误分区的前一个分区的截止时间，使其在规定时间内不能完成指定的任务，它的时间溢出会影响到被测分区的时间调度，从而激励时间溢出的错误。
特别需要注意的是，应用层中存在一些健康监控相关的代码，如错误处理(error_handler)进程中的各个函数以及相关的处理程序，不能作为基于代码方式错误激励的对象，根据软件测试原则，被测代码需要保持完整性，健康监控测试中这些代码作为被测代码，如果被修改，则会丧失测试的意义。因此选择错误激励的位置时需要注意避开健康监控相关的代码。
d)构建故障模式库
在故障模式库构建完成后，面向故障管理的测试过程就可以由库中的行为进行选择或组合，形成相应的测试用例，对所有健康监控可处理的错误的激励就构成了对健康监控测试过程的覆盖率。而这些故障的激励方式也可以进行控制，如果需要以时间进行触发，那么可以在测试用例的判断条件里添加计时器，使得相应的错误在精确的运行时间片段内得到触发；如果需要以事件进行触发，则可以在测试用例的判断条件里添加触发该错误的事件，使得需要触发的错误伴随指定的事件进行同步或者互斥的触发结果。
对ima系统中的健康监控实施测试。为了能够触发预定义的各种软件故障，这里需要查询故障模式库，找到匹配的故障代码，并将故障代码写入被测配置相关的分区应用程序代码中。测试环境会将测试模型中的健康监控及响应生成到测试配置信息文件中。由于该信息直接来源于被测应用程序及模块配置表，因此可以看作是对被测对象的复制。
在执行对故障管理功能的验证过程中，需要从测试用例库中寻找合适的代码，插入到被测应用程序中，测试环境则按照时间的激励顺序进行这几类错误的激励，当向分区不断地传递参数t时，分区中代码依据错误传播的原理执行相应的故障激励。
通过查找测试用例库，从中选取模型中相应测试类型的基于错误激励的测试用例的代码，插入到分区二中，使得从分区一每次传输到分区二的递加的参数可以在不同的周期产生不同的错误。
测试开始运行后，按照配置的调度时间，分区一和分区二开始时间轮转运行。
测试执行过程中，时间调度信息可以由动态运行情况获得，而内存调度情况可以由两个分区分别输出各自的内存地址，以查看内存状况，其中cs(codesegment)是代码段寄存器，放代码段的段地址他里面的内容和ip里面的内容和起来就可以找到当前执行的指令，而ds(datasegment)是数据段段寄存器放数据段的段地址，根据段地址*16d+偏移量就可以得到物理地址。
随着系统的运行过程，设定的错误激励开始启动。当运行周期为2、8、12、15、18时，分别产生除零、内存混乱、应用程序错、时间溢出和非法操作系统调用的错误，系统分别给出了忽略、重启该分区、忽略、忽略、关闭该分区的错误恢复动作。此时可以看到，除了关闭该分区，其他错误都对系统的持续运行没有带来很大的影响，但是当运行到第18个周期时分区二被关闭，只剩下分区一在活动。说明相应的错误用例被正确执行，达到了用户预设的要求。
由此，可以证明测试方法有效地激励了预期的错误。在本例中，测试方法有效地对健康监控及故障管理进行了测试。
本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。
对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。
- 还没有人留言评论。精彩留言会获得点赞！