不同的嵌入式開發人員和團隊對質量的定義可能會有很大的不同。因為每個人對質量都有自己的定義，所以團隊必須以一種不僅記錄而且可以測量的方式定義質量。在這篇文章中，我們將探討幾個可測量的軟件度量，這些度量可以用來定義軟件質量。

　　遵守行業最佳實踐(標準)

　　嵌入式系統行業有很多標準，這些標準的側重點可能略有不同，從簡單的風格標準到為開發人員提供C語言子集的MISRA-C等標準。按照規定的標準開發軟件可以保證避免常見的陷阱，提高軟件的質量。

　　MISRA-C是嵌入式開發人員遵循的一種非常常見的編碼標準。靜態代碼分析器可以用來驗證標準中大約90%的指令，但有些指令是無法通過工具驗證的。為了確保符合標準，開發人員需要定期執行代碼檢查，并手動檢查其余指令。達到標準是確保軟件達到最低質量水平的一個好方法。

　　最小化圈復雜度

　　McCabe圈復雜度度量是一個簡單的測量，可以對任何確定通過該函數的路徑數的函數執行。值小于等于10的函數被認為是易于測試和維護的簡單函數。然而，超過10條之后，測試所需的路徑數量開始變得更加復雜、困難，并且易于開發和維護，這可以用來表明代碼質量較低。事實上，隨著復雜度接近大于20的數字，幾乎不可能正確測試函數。如果你不能正確地展示一個功能，它是如何工作的？

　　測量復雜性也可以是一個自動化的過程。有一些免費的工具，比如CCCC和Eclipse metriculator插件，可以用來測量圈復雜度。還有一些IDE，比如Understand，可以用來收集關于代碼庫的度量信息。成功測量這一指標的關鍵是：首先，決定進行測量;第二，在將新代碼檢查到代碼庫之前執行測量。它也應該在持續集成服務器上執行。

　　沒有警告的編譯

　　警告是編譯器告訴嵌入式開發人員他們正在做一些看起來不太正確的事情的方式。考慮到大多數編譯器都會讓開發人員在代碼中做一些可怕的事情，事實上，編譯器是在警告開發人員，這意味著開發人員應該注意!編譯時沒有一個警告的代碼是一個易于衡量的指標，它表明軟件達到了其他軟件可能無法達到的質量水平。仍然可能存在bug或其他質量問題，但至少代碼本身在語義上是正確的。

　　代碼測試覆蓋率

　　在我們行業的開發周期中，最大缺陷之一是開發代碼覆蓋率為100%的測試。事實上，問題不在于100%的代碼覆蓋率;這只是理解測試實際上覆蓋了多少代碼!如果一個團隊知道他們的測試用例覆蓋了85%的軟件，這是一回事。然而，大多數團隊甚至不知道這一點。代碼覆蓋率可以作為衡量軟件質量水平的一個重要指標。顯然，與僅測試到50%的產品相比，測試到85%的產品更堅固，質量更高。開發人員可以測量這個值，并將其用作代碼質量的內部度量。

　　編碼確認

　　代碼驗證與測試覆蓋率類似，不同的是，我們不是測量覆蓋了多少代碼，而是測量測試實際通過或失敗的百分比。例如，我們可以根據以下因素生成數值：

　　正在執行的測試

　　通過測試

　　需求覆蓋率

　　使用這些指標，我們可以根據測試執行的成功程度，生成0到10之間的數值。然后，這為我們提供了一個評估指標，如果我們沒有達到所需的代碼驗證級別，我們可以返回并改進測試過程，直到達到所需的級別，這也對應于所需的代碼質量級別。

　　結論

　　為了擁有高質量的軟件，“質量”一詞需要由開發團隊定義。該定義應該包括可測量的指標，這些指標可以在整個嵌入式開發過程中輕松跟蹤和監控。在本文中，我們探討了一些高級定義，這些定義應該是創建高質量代碼庫所遵循的最低標準和過程。實現這些指標將幫助你不僅提高總體代碼質量，還可以消除和防止軟件缺陷。