RTOS任务进行单元测试的4种策略

这篇具有很好参考价值的文章主要介绍了RTOS任务进行单元测试的4种策略。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

https://www.beningo.com/4-tactics-to-unit-test-rtos-tasks/

超过50%的嵌入式软件项目使用实时操作系统(RTOS)。不幸的是,使用RTOS会给使用现代开发技术(如测试驱动开发(TDD)、DevOps或自动测试)的开发者带来一些问题。例如,当开发者试图为他们的任务编写测试时,他们遇到的第一个问题是任务函数包含一个无限循环!任何直接调用任务函数的测试都会被认为是一个无限循环!因此,任何直接调用任务函数的测试将永远不会完成。这篇文章将探讨对RTOS任务进行单元测试的几种策略,其中包括:

  • 循环的重新定义
  • 完成信号
  • 任务排除
  • 通过OSAL使用主机线程(强烈建议)。

注意:在这篇文章中,我们将把任务和线程作为同义词。我们还将使用ThreadX作为RTOS的例子。

任务的剖析

在RTOS任务中,有几个部分用于管理任务行为。首先,初始化部分声明变量,实例化对象,初始化驱动程序,并负责将传递给任务的任何数据转换成正确的类型。接下来,有一个无限循环,执行所有任务的行为。例如,如果我们写了管理传感器的任务,我们希望任务的无限循环能定期检索和处理传感器的数据。最后,任务完成部分规定了任务完成后的情况。

典型的任务使用ThreadX可能看起来像下面的代码片段:

{


    void Task_Sensors(ULONG ThreadInput)
    {
        // SECTION 1: Initialization
        (void) ThreadInput;
     
        SensorData_t SensorRawData;
        SensorData_t SensorData;
        SensorData_t pSensorDataTx = &SensorData;
     
        Sensor_Init();
     
        // SECTION 2: Tasks main function / behavior / purpose
        while(true)
        {
            SensorRawData = Sensor_Sample();
            SensorData    = SensorProcess(SensorRawData);
     
            (void)tx_queue_send(SensorTxQ, (void *)&pSensorDataTx, TX_WAIT_FOREVER);
     
            tx_thread_sleep(TASK_SENSORS_PERIOD_MS);        
        }
     
        // SECTION 3: TasK Completion Activities
    }

我发现,编写周期性任务的开发人员希望他们的任务能够无限期地运行,而没有考虑如果任务运行到完成会发生什么。

看看这个任务,你可以看到,如果一个开发者想在测试中对Task_Sensors进行调用,他们会遇到几个问题。因此,让我们来看看这些问题,并按照我经常看到的开发人员在达成最直接和最好的解决方案之前所尝试的各种策略。

参考资料

  • 软件测试精品书籍文档下载持续更新 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

循环的重新定义

经常看到工程师部署的第一个战术是循环重定义。循环的重新定义是指根据代码是生产代码还是测试代码,对任务中的无限循环进行操作。例如,Task_Sensor的代码将被改写为如下内容:


    void Task_Sensors(ULONG ThreadInput)
    {
        // SECTION 1: Initialization
        (void) ThreadInput;
     
        SensorData_t SensorRawData;
        SensorData_t SensorData;
        SensorData_t pSensorDataTx = &SensorData;
     
        Sensor_Init();
     
        // SECTION 2: Tasks main function / behavior / purpose
        while(LOOP_STATE)
        {
            SensorRawData = Sensor_Sample();
            SensorData    = SensorProcess(SensorRawData);
     
            (void)tx_queue_send(SensorTxQ, (void *)&pSensorDataTx, TX_WAIT_FOREVER);
     
            tx_thread_sleep(TASK_SENSORS_PERIOD_MS);        
        }
     
        // SECTION 3: TasK Completion Activities
    }

这个想法是,开发人员可以创建有条件编译的代码,以控制循环是永远运行还是一次。这段代码通常看起来像下面这样:

    #ifdef PRODUCTION
        #define LOOP_STATE true
    #else
        #define LOOP_STATE false
    #endif

除了编译后的代码外,构建时还必须定义或不定义PRODUCTION宏。

一般来说,这不是使RTOS任务可测试的好方法,有几个原因。首先,我们正在测试的代码正在改变。我们的任务在测试过程中的行为会与运行时的行为不同。第二,我们正在添加有条件编译的代码,这通常不是很干净。第三,在定义宏的过程中,有可能出现人为错误。最后,虽然循环的重新定义对于Task_Sensor来说似乎很有吸引力,但测试任务的相互作用会变得过于复杂。事实上,如果我们需要循环运行三到四次会发生什么?我们现在需要为LOOP_STATE定义独特的定义。

完成信号

完成信号是对循环重定义思想的修改,允许任务无限期地运行,直到收到任务应该停止执行的信号。在这种情况下,任务代码被修改为删除宏定义,转而使用循环变量,如下图所示:

    void Task_Sensors(ULONG ThreadInput)
    {
        // SECTION 1: Initialization
        (void) ThreadInput;
        bool   isRunning = true;
     
        SensorData_t SensorRawData;
        SensorData_t SensorData;
        SensorData_t pSensorDataTx = &SensorData;
     
        Sensor_Init();
     
        // SECTION 2: Tasks main function / behavior / purpose
        while(isRunning)
        {
            SensorRawData = Sensor_Sample();
            SensorData    = SensorProcess(SensorRawData);
     
            (void)tx_queue_send(SensorTxQ, (void *)&pSensorDataTx, TX_WAIT_FOREVER);
     
            tx_thread_sleep(TASK_SENSORS_PERIOD_MS);        
     
            isRunning = Task_GetDesiredRunState(TASK_SENSOR);
        }
     
        // SECTION 3: TasK Completion Activities
    }

正如你所看到的,在任务结束时,我们检查该任务是否仍在运行。这就解决了运行多个循环的问题,并通过删除宏来清理代码。然而,我们现在已经为任务的运行引入了复杂性,并为内存损坏或单一事件干扰(SEU)打开了机会,以改变isRunning的状态并完成我们的任务。

任务在生产中运行到完成似乎不是什么大问题,但不是所有的实时操作系统都能优雅地处理这个问题。例如,如果你允许FreeRTOS的任务运行到完成,内核就会窒息并停止执行所有的代码!

任务排除法

当我们不测试我们的任务时,任务排除就发生了!我们不需要测试任务!而不是试图从测试线束中调用任务,我们创建测试来运行任务本身的代码。 任务排除要求我们重写我们的函数,使其看起来像下面这样:

    void Task_Sensors(ULONG ThreadInput)
    {
        // SECTION 1: Initialization
        (void) ThreadInput;
     
        Task_SensorInit();
     
        // SECTION 2: Tasks main function / behavior / purpose
        while(true)
        {
            Task_SensorRun();
     
            tx_thread_sleep(TASK_SENSORS_PERIOD_MS);        
        }
     
        // SECTION 3: TasK Completion Activities
    }
     
     
    /**********************************
     * Placed in a different module
     **********************************/
     
    void Task_SensorInit(void)
    {
        SensorData_t SensorRawData;
        SensorData_t SensorData;
        SensorData_t pSensorDataTx = &SensorData;
     
        Sensor_Init();
    }
     
    void Task_SensorRun(void)
    {
        SensorRawData = Sensor_Sample();
        SensorData    = SensorProcess(SensorRawData);
     
        (void)tx_queue_send(SensorTxQ, (void *)&pSensorDataTx, TX_WAIT_FOREVER);
    }

老实说,上面的代码就是任务应该有的样子。这段代码非常干净,也很容易理解。但问题是,我们是通过尝试使用一种不太理想的技术来达到这个目的的。

我们现在在Task_Sensors中看到的任务代码非常简单,任务排除会说我们不需要测试它。因此,相反,我们将在我们的测试线束中测试Task_SensorInit和Task_SensorRun函数。毕竟,这些函数被保存在一个单独的模块中,所以我们可以将任务代码从测试线束中排除,实现我们所期望的100%的代码覆盖,对吗?

任务排除的问题是,在我们在目标上运行应用程序之前,我们永远不会测试任务代码。不幸的是,我们也欺骗自己,认为我们的测试覆盖了所有的代码。

优点是我们可以根据需要从测试中调用任务中的函数。我们已经实现了这一点,并避免了需要处理无限的while循环的问题。代码更加简洁,我们也没有创建一堆条件性编译语句。

虽然这种技术可以使测试任务代码更容易,但从技术上讲,它不是在测试任务代码。相反,它是一种变通方法。为了测试你的任务代码,你应该尝试在你的主机上创建一个线程或任务,并在那里运行这些代码。

通过OSAL使用主机线程(强烈建议)。

测试RTOS任务的真正问题与大多数任务有while语句的事实无关。相反,这个问题来自于开发者对测试的思考和方法。到目前为止,我们所研究的所有策略都假定我们想直接从我们的测试线束中调用Task_Sensors。这就是问题所在。在我们的测试线束中,我们想创建一个运行的Task_Sensors任务或线程,而不是进行函数调用!这就是问题所在!

我们测试困境的根本原因是,开发人员没有利用操作系统抽象层(OSAL)。相反,他们直接进入RTOS的API并使用这些API。虽然调用RTOS APIs很快,而且似乎是一个很好的方法,但它是将RTOS与应用程序代码紧密地耦合在一起。这种耦合使得测试正确使用任务或线程的应用程序代码变得非常困难。

最佳的方法是将RTOS的细节隐藏在操作系统抽象层(OSAL)的后面。例如,如果你检查我们到目前为止所看到的各种版本的Task_Sensors,你会发现我们正在使用ThreadX tx_queue_send API来发送消息到队列。因此,我们应该把这些细节放在OSAL后面,这样我们的任务就会像下面这样:

    void Task_Sensors(ULONG ThreadInput)
    {
        // SECTION 1: Initialization
        (void) ThreadInput;
        bool   isRunning = true;
     
        SensorData_t SensorRawData;
        SensorData_t SensorData;
        SensorData_t pSensorDataTx = &SensorData;
     
        Sensor_Init();
     
        // SECTION 2: Tasks main function / behavior / purpose
        while(true)
        {
            SensorRawData = Sensor_Sample();
            SensorData    = SensorProcess(SensorRawData);
     
            (void)OSAL_Q_Send(SensorTxQ, (void *)&pSensorDataTx, OS_WAIT_FOREVER);
     
            tx_thread_sleep(TASK_SENSORS_PERIOD_MS);        
        }
     
        // SECTION 3: TasK Completion Activities
    }

OSAL_Q_Send是一个抽象,我们的应用程序代码使用它来发送队列中的数据。应用程序不应该关心我们是否在使用ThreadX、FreeRTOS、pthread或任何其他RTOS或任务调度器。根据我们想要编译代码的系统,会提供一个实现文件。这样做有很多好处,比如说:

  • 应用程序不与实时操作系统相联系
  • 测试可以使用主机的线程框架
  • 应用程序是可移植和可重复使用的
  • 避免了临时性的和黑客式的测试方法进行测试。

对于许多对使用DevOps和自动测试线束感兴趣的开发者来说,你可能至少有针对你所选择的RTOS和pthread的实现,pthread是Linux的POSIX线程库。不幸的是,我们如何使用pthread以及设计和构建OSAL已经超出了今天的范围,但我们将在未来探讨这些话题。

现在,如果你有兴趣看一些OSAL的例子,我推荐你看一下CMSIS-RTOS-V2和NASA的Aeronautics GSC-18730-1。有可能,对于你的需求来说,这些都是过剩的,但它们是完全实现OSAL的好例子。我建议探索它们,并慢慢设计和建立你的OSAL,你可以在你所有的应用程序中使用。

小结

有几种策略可以让开发者用来对任务或线程进行单元测试。正如我们在今天的文章中所看到的,大多数开发人员可以部署的战术都是针对未能将其任务架构为使用OSAL的变通方法。一旦有了OSAL,任务代码就可以通过提供抽象层背后的必要功能,使用任何RTOS或本地线程库进行测试。OSAL层有助于:

  • 简化测试策略
  • 保持代码的清洁
  • 提高灵活性、可移植性和重用性

如果你想测试你所有的代码,那么通过OSAL来利用pthread是最好的方法。文章来源地址https://www.toymoban.com/news/detail-493956.html

到了这里,关于RTOS任务进行单元测试的4种策略的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 《创践——大学生创新创业实任务》 单元测试_ 笔记

    绪论 1、判断题: 本课中讲到,创业是一种人生态度。 选项: A:对 B:错 答案: 【对】 第一章 单元测试 1、多选题: 晶体管是一种固体半导体器件,这个用来代替真空管的电子信号放大元件,是电子工业的强大引擎,被媒体和科学界称为“20世纪最重要的发明”。它是由谁发

    2024年02月01日
    浏览(63)
  • C# 中的单元测试,如何使用单元测试进行程序测试和调试?

    单元测试是一种软件测试方法,用于测试单个功能或方法是否按预期工作。在 C# 中,可以使用 .NET 框架中的单元测试工具来编写和运行单元测试。 下面是使用 Visual Studio 内置的单元测试框架来创建一个简单的单元测试的步骤: 在 Visual Studio 中创建一个新的类库项目。 在新项

    2024年02月15日
    浏览(63)
  • 微控制器实时操作系统实践2了解RTOS任务

    超级循环编程范式通常是嵌入式系统工程师最先接触到的编程方法之一。用超级循环实现的程序有一个单一的顶层循环,在系统需要执行的各种功能之间循环。这些简单的while循环很容易创建和理解(当它们很小的时候)。在FreeRTOS中,任务与超级循环非常相似--主要区别在于

    2024年02月08日
    浏览(48)
  • 【RTOS】快速体验FreeRTOS所有常用API(2)任务管理

    快速体验FreeRTOS所有常用API(1)工程创建 快速体验FreeRTOS所有常用API(2)任务管理 快速体验FreeRTOS所有常用API(3)同步与互斥 快速体验FreeRTOS所有常用API(4)队列 快速体验FreeRTOS所有常用API(5)信号量、互斥量 快速体验FreeRTOS所有常用API(6)事件组 快速体验FreeRTOS所有常

    2024年01月15日
    浏览(40)
  • 软件测试--应用JUnit进行单元测试

    JUnit是一个开源的Java编程语言的单元测试框架,最初由 Erich Gamma 和 Kent Beck 编写。Junit测试是一种白盒测试工具。JUnit是一套框架,继承TestCase类,就可以用Junit进行自动测试了。具有JUnit经验对于应用“测试驱动开发(TDD)”的程序开发模型是非常重要的。 JUnit本质上是一套框

    2023年04月12日
    浏览(42)
  • SpringBoot下进行单元测试

    工程升级SpringBoot之后,突然发现之前写的几个简单的单元测试类无法正常执行了,因为SpringBoot工程的配置方式与之前还是有比较大的差异。 而且之前直接使用Junit来写单元测试,这一次打算直接升级到SpringBoot的Test方式。 1、引入依赖包 之前是直接引用junit依赖包,需要更改

    2024年02月08日
    浏览(47)
  • 如何进行单元测试

    单元测试是指对软件中最小可测单元进行检查和验证;c语言中单元指一个函数,java中指一个类。图形化软件中可以指一个窗口或者一个菜单。总的来说,单元就是认为规定最小的被测试模块。 首先是一个前端单元测试的根本性原由:JavaScript 是动态语言,缺少类型检查,编

    2024年02月06日
    浏览(41)
  • 如何进行单元测试?

    单元测试是软件开发中的一个重要环节,它可以确保每一个单元(如函数、模块)的功能正确性,以此保证整个系统的稳定性和可靠性。在 JavaScript 和 Vue.js 中,最常用的单元测试工具包括 Jest 和 Vue Test Utils。 以下是一个简单的使用 Jest 和 Vue Test Utils 进行 Vue 组件单元测试的

    2024年02月09日
    浏览(55)
  • 使用phpunit进行单元测试

    本教程假定您使用 PHP 8.1 或 PHP 8.2。您将学习如何编写简单的单元测试以及如何下载和运行 PHPUnit. PHPUnit 10 的文档 在这。 1.PHP 存档 (PHAR) 我们分发了一个 PHP存档(PHAR),其中包含使用PHPUnit 10所需的一切 。只需从这里 下载 并使其可执行: 2.Composer 您可以使用 Composer 将 PHPU

    2024年02月12日
    浏览(37)
  • 现代C++编程实战25-两个单元测试库:C++里如何进行单元测试

    你好,我是吴咏炜。 单元测试已经越来越成为程序员工作密不可分的一部分了。在 C++ 里,我们当然也是可以很方便地进行单元测试的。今天,我就来介绍两个单元测试库:一个是 Boost.Test [1],一个是 Catch2 [2]。 单元测试库有很多,我选择 Boost 的原因我在上一讲已经说过:“

    2024年02月07日
    浏览(41)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包