軟體單元：在基於模型的軟體設計中，軟體單元指軟體架構中最小的單元。而軟體架構劃分的顆粒度視情況不同而定，最大粒度為各功能模組之間耦合度最低，即單個模組所涉及的變數對其他模組的影響度最小，非不可剝離出去的變數。如bms系統中的高壓上下電模組和診斷事件管理模組，前者的輸入訊號bms系統故障狀態**於後者的輸出，但該變數剝離出去，對前者無功能影響。
按照軟體架構劃分好的單元，如果做軟體單元測試，再將其細分，有必要嗎？
a：非有無必要，而是無意義。該單元已經是最小的軟體模組，屬於完整的單個功能，內部的變數是有邏輯關聯的。如果再拆分成更小的單元，類似於乙個加法計算，這樣的測試測完之後，還得對整個單元進行測試，才能說該單元模組測試充分了。還有一點，像更小的單元，開發人員在除錯時已經完成了。
如何做單元測試？
a：充分理解單元模組的需求，基於軟體需求進行測試。注意：單元測試非白盒測試，不需要去關注模型內部的執行邏輯。把單元模組視為乙個黑盒，按照需求，給定輸入條件驗證輸出結果對其進行驗證。用黑盒測試的方法設計測試用例，用白盒測試方法補充用例，驗證程式結構是否有未覆蓋到的邏輯路徑。
單元測試是否要關注模型的結構覆蓋率？
a1：no. 乙個模型單元，基於需求設計的測試用例難以覆蓋模型中的各個分支和語句（同時，軟體中出於設計考慮，會留下本就無法達到的分支和語句），而基於需求，並不清楚軟體內部的結構，且複雜的內部結構，難以通過人工設計用例來滿足覆蓋要求。故無法根據需求來設計滿足結構覆蓋率要求的用例。而需要借助工具完成，如simulink中本身能自動生成用例去跑結構覆蓋率測試。
a2：yes. 模型的結構覆蓋率測試是對基於黑盒測試方法設計測試用例的有效補充測試。
2018/10/7更新：
單元測試的目標：測試軟體單元是否與軟體規格說明書相符？包含兩個層面：1）是否實現了所需功能？（預期）；2）是否出現軟體規格說明書中沒有說明的功能？（非預期）
單元測試與整合測試的功能劃分：單元測試的物件是較小的軟體單元，當軟體分模組並行開發時，對單個較小單元進行測試，發現錯誤的概率更大，同時開發人員進行軟體除錯的難度更小。
單元測試 單元測試文章收藏
前言 前段時間公司計畫做自動化測試，自己也打算圍繞幾個點做相關調研，現在想想呢？其實對自動化測試的概念都還不是十分清晰，當時主要還是圍繞 單元測試 向qa小夥伴學習了一段時間，現由於公司重組，學習中斷，這裡簡單記錄一些單元測試好文，留待後續參考.什麼叫自動化測試？自動化測試覆蓋率？覆蓋率如何做到的？...
單元測試之Django單元測試
每個應用，自帶tests.py 整合在django的專案檔案裡，更多是開發人員寫django自動的測試執行 3.1 前後置方法執行特點 django.test.testcase類主要由前 後置處理方法和test開頭的方法組成 特點 繼承於django.test.testcase 測試用例都是test...
單元測試（三） 建立多執行緒單元測試
junit本是不支援多執行緒的，乙個單元測試case主程序跑完，其他new出來的執行緒都會gg思密達。此篇mark乙份在junit中執行多執行緒的方法。net.sourceforge.groboutils groboutils core 5test slf4j public class device...