RTOS任務進行單元測試的4種策略

產品設計出來之後啊，大家使用的時候覺得反過來使用更加便捷。但是屏幕顯示是反的。那怎麼辦那？？？？？修改硬體費時費工，那能否軟體實現那？？？？？如果純軟體使用那就太費系統資源了。於是就想到了使用全志R528 自帶的G2D功能（硬體加速功能）。使用它進行旋轉，後又發現uboot階段系統沒有G2D導 ...

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

釘釘或微信號: pythontesting 微信公眾號：pythontesting