简介
在本文中，我们重点讨论了实时操作系统的验证和测试程序。
测试的目的有两个。一个是显示经过验证的模型属性是否被继承到了代码中。另一个目的是发现代码的错误要检查结构覆盖率和功能等。
在测试所开发的操作系统软件后，我们将其与数字工厂保护系统（DPPS Digital Plant Protection System）软件一起嵌入测试板中，该软件模拟安全关键的反应堆保护功能。开发的系统应该满足10的-3方的故障概率（pfd failure on demand），以表明它对安全关键应用是足够可靠的。我们通过在测试板上进行必要数量的测试来证明这一点。
方法
方法分为三部分：
- 在生命周期的每个阶段进行规范和验证
- 为软件测试生成测试数据
- 进行嵌入式系统测试
2.1 软件规范和验证
我们用图形化的形式化语言来规范实时操作系统，并用模型检查来验证它。我们使用STATEMATEMAGNUM工具集，I-Logix，作为形式语言和模型检查器。STATEMATE MAGNUM是基于活动图和状态图的。
活动图用于功能描述，状态图用于系统的行为描述。状态图是一种具有数学语义的定义明确的形式语言。使用状态图，我们可以用状态和它们之间的转换来描述需求/设计阶段的行为。状态图中的过渡是五元组（源，目标，事件，行动，条件）。状态图中的箭头从源头到目标，被标记为e[c]/a，这意味着当条件c为真时，事件e触发了过渡，当过渡时，行动 "a "被执行。行动'a'可以是一个行动的列表。
STATEMATE有一个仿真工具来验证系统设计。利用仿真，我们不仅可以验证每个模块，还可以验证整个系统。
STATEMATE MAGNUM还提供ModelChecker作为形式验证工具。
模型检查可用于检查设计中关于特定属性的动态行为。重要的是要知道，模型检查与传统意义上的测试不同。与测试相反，模型检查在数学意义上是完整的。如果模型检查器证明了一个特定的属性在模型中得到了满足，那么结果就是100%正确的。如果模型检查器显示STATEMATE设计中的一个基本状态是不可达到的，这意味着没有人会找到仿真运行（只有输入变量在执行过程中可以改变），其中的跟踪路径包括特定的基本状态。因此，模型检查可以被称为穷举测试。所有这些设计信息都由工具自动翻译成模型检查器内核的输入语言。另一方面，用户必须定义要检查的属性。
我们可以从STATEMATE的代码生成器中得到一个自动生成的代码，预计它的错误会比人工实现的少。
2.2 软件测试
实时操作系统的测试以两种方式进行：在软件测试和嵌入式系统测试。软件测试的重点是RTOS软件本身，而嵌入式系统测试的重点是与嵌入RTOS的应用软件的集成。
在单元测试的情况下，我们通过对代码应用白盒测试标准来选择单元测试数据，这些代码是在实现阶段从STATEMATEMAGNUM自动生成的。我们还通过对设计阶段指定的Statecharts应用分支覆盖标准来选择单元测试数据。在集成测试的情况下，我们通过利用设计阶段指定的Statecharts来选择集成测试数据。在系统测试的情况下，我们通过利用需求阶段指定的活动图来选择系统测试数据。
2.3 嵌入式系统测试
作为这个测试的标准，我们设定了千分之一的故障要求，这被用作安全关键型核系统的可靠性测试标准。作为测试数据，我们生成随机的故障条件组合，直到它满足获得所需的故障数量。
参考资料
- 软件测试精品书籍文档下载持续更新 https://github.com/china-testing/python-testing-examples 请点赞，谢谢！
- 本文涉及的python测试开发库 谢谢点赞！ https://github.com/china-testing/python_cn_resouce
- python精品书籍下载 https://github.com/china-testing/python_cn_resouce/blob/main/python_good_books.md
形式化规范和验证程序
3.1 实时操作系统的要求
实时操作系统与一般的操作系统不同，它的逻辑正确性不仅取决于其输出的正确性，而且还取决于其输出的及时性。此外，像其他操作系统一样，必须至少提供以下三种功能：任务调度、任务分发和任务间通信。调度是决定下一个控制CPU的任务的过程。当中断发生时，它被调用，任务完成其工作，正在运行的任务被暂停。
当调度器被调用时，它扫描准备就绪状态的任务列表，根据调度策略选择任务，并将CPU控制权交给它。调度是一个切换、保存和恢复运行任务和下一个运行任务的上下文的过程。在本文中，调度员定期创建任务并使其处于准备状态。任务内通信使任务能够交换信息并相互同步。消息邮箱和消息队列被实现来执行任务间的通信。
用户代码作为一个任务被执行，有预定的执行时间和周期。操作系统可以在任何用户任务的执行过程中打断它。
3.2 实时操作系统规范和验证
实时操作系统的功能规范如图3.1所示。每个方框都包括实时操作系统的功能。线代表功能之间的通信，虚线框代表外部环境。实时操作系统包含内核、中断处理程序和任务。内核包括调度器、任务管理器、消息信箱和消息队列。任务模块有七个任务：五个任务的优先级相同，一个任务的优先级更高。最后一个被分配为空闲任务。
调度器的行为规范调度器执行基于优先级的，或者说是轮回的调度。RTOS中的嵌入式软件在其应用中有两个不同的任务。一个是监控和投票任务，另一个是行程任务。跳闸（关机）任务有最高的优先级，其他任务有相同的优先级。
图3.2显示了调度器模块内部的行为。
对于任务间的通信，我们的实时操作系统提供了消息邮箱和消息队列。
图3.3显示了任务的行为。每个任务基本上有五个状态：休眠、准备、运行、等待和ISR。休眠状态表示任务未被创建。处于休眠状态的任务可以在任务进入它的时期并花费抵消时间后被创建。处于准备状态的任务正在等待调度，而调度已经准备好运行。处于运行状态的任务在需要使用资源或花费时间时过渡到等待状态。当运行中的任务被系统打断时，将过渡到ISR状态。调度器模块被用来唤醒任务。
在规范之后，使用STATEMATE对RTOS进行仿真，如图3.4所示。
图3.4 RTOS的模拟通过ModelChecker验证的属性如下：
- 指定的RTOS是否有不可到达的状态。
- 指定的实时操作系统是否是确定性的。
- 两个或多个任务是否可以同时处于运行状态。
其结果如图3.5所示。
在Statecharts中的设计规范可以自动翻译成C代码，在后面的阶段进行测试。
4. 软件测试
4.1 单元测试
在RTOS的单元测试中，单元从Statecharts中提取出来，并分别自动转换为C代码。单元测试有两个目的：一个是识别自动转换的C代码是否正确，另一个是检查代码的行为是否与我们设计的一致。
4.2 基于状态的单元测试
我们通过应用分支覆盖标准，从Statecharts中指定的单元中提取基于状态的单元测试数据。分支覆盖标准需要覆盖所有的转换，之所以选择这个标准，是因为规范本身是基于状态和它们之间的转换。
为基于状态的单元测试生成测试数据的程序如下。
- (1) 识别要测试的单元。
- (2) 为基于状态的单元测试选择测试数据。
- 对从设计规范中提取的单元应用分支覆盖标准。
- 选择测试数据来覆盖所有的分支以满足标准。
我们使用结构测试工具ATAC（Automatic Test Analysis for C进行基于代码的测试。我们选择两个白盒测试标准：语句覆盖标准和分支覆盖标准。语句覆盖率标准是按照Reg.Guide 1.171中对核应用的建议选择的。根据Reg.Guide 1.171，我们应该在基于代码的测试中覆盖代码中的所有语句。
在这个测试中，分支覆盖标准也被选为一个更有力的标准。
为基于代码的单元测试生成测试数据的程序如下。
- (1) 识别要测试的单元。
- (2) 为确定的单元逐一生成自动代码。
- (3) 为基于代码的单元测试选择测试数据。
- 对代码应用语句和分支覆盖标准。
- 选择数据
4.2 集成测试
集成测试的目的是检查当单元结合在一起时是否有任何错误。因此，它侧重于模块之间的接口。我们选择能够检测模块间接口信息的测试数据。选择集成测试数据的过程如下所示：
(1) 绘制状态组合图。
- 确定要组合成一个模块的单元。这在图4.2中显示。模块和单元分别用圆角矩形和椭圆表示。初始单元用一个带复选标记的椭圆表示，一个最终单元用两个椭圆表示。
- 单位之间的关系用虚线表示，模块之间的关系用实线表示。
(2) 在状态组合图中，一个状态代表单元或模块，而一个过渡则代表状态之间的通信关系。通过应用分支覆盖标准，我们可以覆盖状态组合图中的所有状态和分支。因此，通过应用分支覆盖标准选择的测试数据覆盖了状态分解图中的所有符号。
4.2.1 实时操作系统的状态组合图
(1) 确定组合成模块的单元 图4.3是实时操作系统的状态组合图。有两个模块：
内核和任务模块。这些模块分别由两个和八个单元组成。
(2) 识别关系 如图4.3所示，如果任务模块得到SYS_ON信号，任务模块中的 "任务 "单元会向内核模块发送TCB_RDY信号。然后，内核模块发送RUN_TSK信号来启动目标 "任务".
4.2.2 集成测试的测试数据
我们通过对模块间的转换关系应用分支覆盖标准来选择集成测试数据，如图4.3所示。图4.4中的粗线代表了对 "任务 "模块中的 "任务1 "单元应用分支覆盖标准的一个例子。如果 "Task1 "接收到一个 "SYS_ON=T "的信号，它就发出一个 "T1_TCB_RDY=T "的信号给内核模块。然后，内核模块发出一个'RUN_TSK1=T'信号来启动'Task1'。
我们通过应用分支覆盖标准，考虑到卫星分解图中的最终状态，在内核模块和任务模块之间产生七个测试数据。
4.3 系统测试
系统测试的目的是检查它是否显示出需求说明中描述的行为。在选择系统测试数据时，我们利用活动图。选择系统测试数据的程序如下：
-
(1) 从活动图中提取场景。
-
(2) 根据场景绘制序列图。
- 活动图的一个模块可以是序列图的一个类。
- 活动图的事件和数据可以是序列图的消息。
-
(3) 根据序列的数据流确定输入数据，选择系统测试数据。
4.3.1 场景
从活动图中提取的场景可以根据中断条件进行分类。这里，我们从没有中断的例子中生成测试数据。
4.3.2 顺序图
我们在活动图的基础上构成顺序图，如图4.5所示。
4.3.2 系统测试数据的选择
我们根据顺序图中的数据流，通过识别输入数据来选择系统测试数据。一种情况如图4.5所示，输入数据被显示为一组信号： SYS_ON，和T1_TCB_RDY ~ T4_TCB_RDY，可以形式化为如下：
系统测试数据 = (SYS_ON, T1_TCB_RDY, T2_TCB_RDY, T3_TCB_RDY,T4_TCB_RDY)
如果没有中断，总共有16个系统测试数据，如表4.3所示。如果选择定义为(T,F,T,T,T)的第15个系统测试数据，预期输出将是启动 "任务6"。
嵌入式系统测试
5.1 系统规范
在前面的章节中，我们展示了包括安全关键应用的RTOS软件验证在内的开发程序。在本节中，我们展示了测试，以确定当它被嵌入到硬件中时是否工作良好，同时也检查当它与应用软件集成时是否有任何错误。测试板是为此目的而设置的。所用的测试板有一个英特尔80C196kc CPU，有RS-232端口作为接口。由于开发的PLC是针对数字植物保护系统（DPPS）的，我们对简化的DPPS功能进行建模，并自动生成代码，与RTOS软件的程序相同。
DPPS接收每个变量的四个冗余输入，然后，将它们与定义的设定点进行比较。当输入超过设定点时，它产生 "真 "值作为输出。结果被传送到下一个模块，在那里收集每四个冗余通道的结果。如果四个监测变量中有两个以上的值显示为 "真"，那么它就会发出一个跳闸信号，启动保护功能。DPPS系统软件被简化，为了方便嵌入式系统测试，只对一个监测变量进行建模。
5.2 可靠性评估
文章来源：https://www.toymoban.com/news/detail-482213.html
结论
在这项工作中，我们展示了为安全关键的核应用指定、验证和测试实时操作系统的整体程序。对实时操作系统的要求进行了分析，得出的结论是可以验证的，因为实时操作系统所需的功能是简单和确定的。在验证之后，软件被自动生成C语言，这个生成的代码被测试用于每个目的。单元测试、集成测试和系统测试作为软件测试被执行。在单元测试中，我们进行了两种类型的测试；一种是基于代码的测试，看是否有任何错误，另一种是基于状态的测试，检查开发的软件是否满足验证模型的属性。在集成测试中，我们制定了状态组合图，并通过应用分支覆盖标准生成测试数据。在这个测试中，我们检查任何两个或更多的模块是否像我们在模型中设计的那样正常通信。在系统测试中，我们从需求规范中提取场景来检查整个系统的行为。在验证和测试之后，我们将嵌入式系统作为一个原型来实现。我们生成简化的应用软件嵌入到RTOS中，然后测试整个嵌入式系统，检查它在与应用软件和硬件集成时是否正常工作。我们计算出满足可靠性标准所需的测试次数，这将给我们带来量化的可靠性。文章来源地址https://www.toymoban.com/news/detail-482213.html
到了这里，关于RTOS测试（韩国方案）的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
