嵌入式系統如何進行測試？

01-03

有幾個困難：
1. 目標系統沒有開發PC上的虛擬機，不容易進行自動化測試。
2. 好多問題屬於人機操作，如何進行回歸測試？
3. 在沒有較為完善的單元測試和集成測試之前，系統測試如何安排？
4. 如何準備和實現自動化測試？

5. 與別的行業進行自動化測試相比，有沒什麼特殊之處? 比如和 ATM 機相比等等。
6. 沒有跑操作系統或基於通用 OS，因此沒有 shell 可用。

謝邀。

可以做，自動化和系統測試都可以。

首先考察下這幾個問題:

1. 人機介面有哪些，串口肯定有吧？按鍵，觸摸屏有沒有？

2. 每種人機介面輸入方式對應地有一個消息吧，底層肯定實現的有消息機制和消息循環吧？

3. 如果消息機制沒有，事務處理是在中斷服務里做的，可以人為觸發中斷嗎？可以認為中斷也是一種消息。

上面幾個問題搞清楚了以後，可以這麼實現:

1. 錄製開機後的所有消息並保存，黑盒測試人員的所有操作會被記錄下來，測出 bug 後，通過特殊的按鍵組合或者其他交互方式保存，即成為一個用例。消息最好能帶時間甚至 clock 數值。

這樣做避免了測試人員在枯燥的測試中偶爾測出 bug 卻記不得自己剛才是怎麼操作的，也避免了用文字描述不夠準確，或軟體人員重現不了時雙方的扯皮和矛盾。

2. 在系統中設計用例回放機制，即能解析上面保存的消息並重新 post 出來，這樣將大大方便軟體人員 bug 定位以及修改後的驗證。

3. 如果有精力的話，可以實現一個簡單的測試腳本解析模塊，比如腳本里寫:

repeat 10000:

keydown A

delay 300

keyup A

pendown (x, y)

……

同樣地，解析成消息 post 出去。腳本通過串口或者網路發送給系統。

這樣可以實現一些更複雜的測試，具體能實現什麼，看你們的想像力了。

隨著擴展，可以添加你們產品的主要業務對應的高級指令，約定好參數，系統解析並調用內部 api 就可以了。

唉，這些曾經是我們團隊實現的很得意的壓箱底的東西啊，免費教給你了，快給贊。

搜到一篇論文，跟我說的方法思路相同，表達更完整：

實時嵌入式系統平台自動測試工具

自動化測試可以做：

嵌入式有shell吧？shell上用外掛工具跑腳本，比如SecureCRT就支持VBS。

需要插拔、通斷、按鈕？沒問題，繼電器+串口可以實現，我們公司做USB測試，測試組的一位老員工就自己畫了個電路圖（不複雜，主要就是繼電器），找中關村幾個人過來焊了幾個測試設備，專門測USB插拔的。設備用串口控制，PC機上寫腳本就可以了。

所以，真心不複雜，單元測試和集成測試都能做。實在沒辦法，招幾個實習生過來測試就好了。

補充：

如果連shell都沒有，那麼串口總是有的吧？任何嵌入式設備不可能說一點輸出的地方都沒有，如果真是那樣，那麼這個系統設計的很有問題。手機的原型機里都是有串口調試的。一個設計合格的系統，必定預留了很多調試的介面。

首先，質量是設計出來的，而不是測試出來的。

我先說一些我的一些經驗，之後想擴展到「嵌入式系統如何保證軟體質量？」的問題。因為測試只是方法，質量才是目的。

解決問題的思路有如下幾個

很多情況下不可能完全實現自動化測試或者成本太高，那麼就通過

減少進行一次完整測試所用的時間和資源，提高人工測試的效率
將可自動測試的部分從整體中分離出來獨立測試，剩下的人工測試

將整個系統分解為多個子系統進行獨立的測試
將系統分解為設備相關和設備無關分開測試

設備無關的部分做自動化測試
設備相關的部分人工測試，每次設備條件變化時再進行獨立測試

構建多個獨立的測試程序在設備上逐個運行，每個這樣的測試程序只需得出PASS或者FAIL的結果即可.
利用高級語言及其豐富的庫提高測試效率

一些嵌入式軟體測試的個人經驗

用高級語言實現自動化測試

很多時候當手工測試已經佔用了很多時間的時候，需要將其轉換為自動化腳本。我最常用的就是基於Python的unittest，配合pexpect等工具，在加上強大的各種Python庫，來實現自動化測試。

（慢慢補充）

利用好各種工具

Wall - 永遠開著Wall，提交前永遠對Warning零容忍，別讓他破窗。
Valgrind - 內存泄露以及各種測試
如果你做的是開源項目，那麼有以下互聯網工具

GitHub這個還用說么？
travis-ci - 最有名的免費持續集成工具了，可以和GitHub綁定，每次提交都可以直接構建和測試，甚至交付
http://coveralls.io - 基於travis-ci，在測試之後可以將覆蓋率報告上傳到http://coveralls.io，將會生成覆蓋率報告。

對於公司內部，有

GitLab - 非常好的GitHub替代
持續集成（CI）

Jenkins CI -
Gitlab CI

談談嵌入式軟體的質量問題

在像IC設計這樣的硬體設計中，對正確性的要求是非常高的，因為一次性的投產費用高達數萬美元至百萬美元。而軟體因為錯了可以修改，所以有不同的質量要求。互聯網的興起從一定程度上降低了軟體質量的水平，因為只要是非關鍵系統，有bug你可以隨時升級。但是對於嵌入式來說，大部分產品賣出去就很難在升級了，比如電飯煲和家用電器這樣的產品。所以對於質量的要求高於互聯網，而低於硬體產品。

說了一段廢話，其實我想引入IC設計中的一個概念，叫做可測性設計（Design for Test）。意思很簡單，設計的時候就要為測試考慮。而不要等編碼完了之後在去想怎麼去測，這個時候測試的成本就是不可預期的了。