這是一篇測試相關的筆記。我們軟件開發最終都離不開測試的，可以通過測試來發現很多問題。在這之前先扯談一波：
在這給還沒找工作的朋友提個醒，能找開發的職位就別找測試的職位，除非你真的很喜歡測試。親身經歷，做測試很不好受。測試其實有兩類，一種是自己去測自己測的東西，另一種是去測別人做的東西。如果是第一種，我倒是很願意做，因為我們本質上還是開發工程師，大概80%的工作時間在做開發，20%的工作時間在測自己開發的東西。這個測試的時間值得花，可以通過測試來發現我們在開發過程中沒有注意到的點。如果是第二種，我們本質上就是測試工程師了，大概80%的時間在測別人的東西，20%的時間在想著怎麼測別人的東西。如果是這一種的話，那我們就只能當別人的配角了。
找工作時，有一點要注意：有些職位寫著嵌入式軟件工程師，實則測試工程師，這個得問清楚。
迴歸正題，下面開始我們的這篇筆記：
幾個開源的測試框架
框架（framework）是一個框子——指其約束性，也是一個架子——指其支撐性。是一個基本概念上的結構，用於去解決或者處理複雜的問題。 框架這個廣泛的定義使用的十分流行，尤其在軟件概念。比如我們套用一些測試框架來測試我們寫的一些功能函數，的出來的測試結果大概是這樣子的：
從輸出結果中看，我們可以清晰地看出測試的情況。下面分享幾個開源的測試框架：
1、 Unity測試框架
這裡的Unity並不是那個遊戲開發工具 ，而是一個開源的測試框架。Unity測試框架的項目鏈接：
<code>https://github.com/ThrowTheSwitch/Unity/releases/<code>
目前更新到v2.5.0：
Unity 是一個輕量級的測試框架，它使用 C 語言實現， 代碼本身很小 。其代碼中大多數是宏定義，所以實際編譯後的代碼會更小， 比較適合在嵌入式測試應用。
2、 CuTest測試框架
CuTest項目鏈接：
<code>https://sourceforge.net/projects/cutest//<code>
CuTest是一款微小的C語言單元測試框，只有2個文件，CuTest.c和CuTest.h，全部代碼加起來不到一千行。麻雀雖小，五臟俱全，測試的構建、測試的管理、測試語句，都全部包含在內。
3、 Embedded Unit測試框架
Embedded Unit項目鏈接：
<code>https://sourceforge.net/projects/embunit /<code>
Embedded Unit是個純標準c構建的單元測試框架，主要用在嵌入式c的單體測試上，其主要特點是不依賴於任何C的標準庫，所有的對象都是靜態分配。
4、 gtest 測試框架
gtest項目鏈接：
<code>https://github.com/google/googletest/releases/tag/release-1.8.0/<code>
gtest 是 google 公司開發的一個開源的單元測試框架，基於 C++開發，可以對 C++語言和 C 語言進行單元測試。 gtest 有以下特點：
- 提供強大的斷言集，支持布爾型、整型、浮點型、字符串以及所有實現了比較運 算符和輸出運算符的自定義類的判斷；
- 提供斷言擴展功能，當所需要的斷言在 gtest 中沒有提供時，可以使用 gtest 提供 的方法進行擴展；
- gtest 會自動收集我們的測試用例，開發者不需要對測試用例進行組織；
- 提供死亡測試的功能，用於測試代碼在特定情況下異常崩潰的情況；
- 可將公共的用例初始化和清理工作放入測試夾具中，由 gtest 自動調用；
- 使用參數化自動生成多個相似的測試用例
Unity的使用分享
這裡分享Unity在STM32平臺上的移植與使用（keil工程）。移植的過程很簡單，一般這些測試框架都是打印的方式把測試結果輸出。在STM32中 ，我們一般是通過串口輸出到串口上位機，所以我們在移植Unity的時候，處理好這個問題就可以用在STM32上了。
首先，把Unity源碼目錄下的unity.c、unity.h、unity_internals.h三個文件複製至我們的工程目錄下，並把unity.c添加到我們的keil工程中，然後添加文件路徑：
我們打開unity_internals.h文件，發現其有包含一個頭文件unity_config.h：
這個文件是配置文件，我們與平臺相關的特性放在這個文件中。而這個文件Unity源碼中並未提供，所以需要我們自己建立，我這邊新建的unity_config.h文件的內容如下：
主要在這裡面放了硬件相關的頭文件包含以及兩個必要的宏定義。第一個宏定義用於重定向輸出至串口，第二個宏定義就是我們的串口初始化。
在unity_internals.h中我們發現unity_config.h文件被條件編譯屏蔽掉了，我們需要定義宏把它打開：
最後在我們的main.c中包含頭文件unity.h即可使用unity測試框架。在unity_internals.h中有很多可修改的配置，比如在不同的平臺中，整數的長度是不一樣的，在 Unity 中，允許開發者設置整數的長度。如果沒有設置， Unity 指定的默認值是 32 位。我們的STM32就是32位的，所以我們不需要修改。
下面開始編寫測試用例。 在 Unity 中，每個測試用例是一個函數， 該函數沒有參數和返回值。下面我們來測試一個閏年判斷函數：
在測試函數中用到 TEST_ASSERT_TRUE 和 TEST_ASSERT_FALSE ， 是 Unity 實現的兩個斷言， 用於判斷 布爾型表達式的值為真或為假。這些測試框架一般都是用斷言來進行測試的，包括以上分享的幾個框架都是如此。本例中只用到了兩個斷言，在 Unity 中還有很多斷言，如下是部分斷言列舉：
Unity 默認需要實現用例初始化函數 setUp 和用例清理函數 tearDown，這兩個函數均沒有參數和返回值。 在閏年判斷函數的測試用例中，由於不需要初始化和清理操作，實現的兩個函數如下：
在編寫了測試用例後， 接下來就可以在 main 函數中運行測試用例。在 Unity 中，使用宏 RUN_TEST 運行測試用例，參數為要運行的測試用例的函數名稱。主函數如下：
UNITY_BEGIN函數就是UNITY初始化函數，我們的串口初始化也是在這裡面被調用的：
RUN_TEST函數用於運行我們的測試用例。UNITY_END函數就是返回我們的測試結果。最終，運行得到如下結果：
假如，我們把測試閏年的測試函數里的2000改為2001：
那麼輸出結果就變為：
可以從結果看出沒有通過的用例相關的代碼所在行。在進行這樣子的測試之前，我們當然得要明白我們的功能函數的功能及其預期輸出，我們才能去進行測試用例的設計及進行測試。
以上就是關於Unity測試框架的使用分享，這只是這個測試框架的基本使用。有興趣的、有用得上的朋友可以自己進行深入研究及使用。
相關書籍
第一本書：《軟件單元測試入門與實踐》周立功
這個Unity測試框架是我在周立功周工幾個月前出版的新書《軟件單元測試入門與實踐》中看到的。之前剛出版的時候，他們有送書活動，我申請了一本紙質版書籍，沒來得及看，最近仔細翻了一下，發現還實用，又學到了很多新東西。這不只是一本講測試的書，也是一本教我們如何調高軟件質量的書。書中有理論和實踐大概各佔一半，介紹了很多實用的工具和技巧。
前面幾章很詳細地介紹了一些測試相關的知識，比如黑盒測試、白盒測試、灰盒測試、靜態測試，動態測試等。介紹了靜態測試工具：pc-lint 編碼規則檢查工具與 SourceMonitor 代碼結構檢查工具。其中pc-lint可以集成到keil中進行使用。從某種意義上說，PC-Lint 是一種更加嚴格的編譯器，它除了可以檢查出一般的語法錯誤外，還可以檢查出那些雖然符合語法要求，但很可能是潛在的、不易發現的錯誤。
後面幾章分享一些實用工具的使用，比如Unity測試框架、cmake自動構建工具、持續集成系統 gitlab 等。
第二本書：《測試驅動的嵌入式C語言開發》尹哲翻譯
這本是在周工那本書的參考文獻裡的其中一本。
這是老外寫的書。看目錄好像還不錯，有空的時候可以當做課外書來讀。
以上就是本次的筆記分享，希望各位喜歡！本筆記的keil工程及以上兩本書的電子檔可私聊我獲取。
閱讀更多 嵌入式大雜燴 的文章
