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

标签：Task 策略单元测试 void RTOS SensorData 任务测试代码

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是最好的方法。

标签：Task,策略,单元测试,void,RTOS,SensorData,任务,测试,代码
From： https://www.cnblogs.com/testing-/p/17460629.html