內建質量定義

    內建質量作用在開發過程中，要求軟體生命週期之間參與的各個角色都需要實時的對軟體的質量負責。確保軟體在交付到下一環節前已經有了基礎的質量保證。其核心目的就是減少因為質量問題導致的返工，而浪費大量人力成本。

1.敏捷中的內建質量

內建質量是規模化敏捷SAFe的核心價值觀，引用下面一段話，我們看一下敏捷中定義的內建質量在講什麼內容（原文出處: ）

簡單的翻譯過來就是，產品一旦被髮布之後就有了好壞之分，透過某些檢驗方式已經無法提高或保證它的質量，所以質量檢驗必須內建在產品或服務構建的過程中，而不能在它釋出之後。

2.DevOps中的內建質量

DevOps三步工作法中，第二步就是反饋原則，其中很重要的一個實踐就是在源頭保障質量，這裡主要是指開發部門、測試部門。而在源頭保障質量的通俗說法更像是“誰汙染誰治理”。 DevOps倡導所有新的功能特性可以像流動的水一樣，迭代到使用者的終端，而水是不能逆流的，為了保證水流的質量，我們就必須在水流動的途中治理，直到最終交付到使用者的手中。這也就是DevOps建設中一個新的理念“liquid software”

內建質量實踐

1. 左移

左移是內建質量最好的實踐，把質量問題從源頭開始進行檢查。

由開發側發起的單元測試就是最典型的測試左移的案例，雖然高單元測試覆蓋率需要投入大量的成本，但是對於某些行業，如金融行業，這個實踐是必要的。另外測試左移不止是對程式碼來講的，同樣在需求評審階段，就要對需求質量進行評估，推廣到市場後是否真的能實現其價值.

隨著DevSecOps的興起，安全左移的重要性也體現出來。我們經歷過很多次類似的情況，每當我們把經過了開發測試的軟體釋出到生產線上，經常會被安全部門或者第三方監管單位找麻煩，歸根結底還是因為在開發過程中引入了某些不安全的開源元件,寫了有風險的程式碼，而這些問題可能都是開發人員技術能力之外的。試想一下，如果在開發人員的IDE中直接提示開發程式碼的安全問題，引用元件的安全問題，並引導開發人員去解決的話，是不是相當於在開發的源頭解決了安全問題呢，不但提高了軟體的整體安全質量，同樣也節省了效能。

2. 門禁

為了貫徹內建質量是否在開發體系中落實，我們需要設定一些質量度量標準，所以在軟體生命週期的每個階段設定質量門禁這種實踐孕育而生，在程式碼提交或整合時，校驗單元測試的覆蓋率和透過率，檢驗程式碼的合規性，驗證引用的元件安全性都是質量門禁的實踐。如果沒有透過質量門禁，說明內建質量沒有達到標準，上線後由於質量問題返工的可能性會增加。下述門禁是需要被關注的：

程式碼質量

單元測試覆蓋率

單元測試透過率

測試透過率

基礎設施

程式碼安全性

第三方元件安全性

開源協議掃描

等…

內建質量落地

很多DevOps的建設場景中，最終落地的依舊是工具鏈，工具鏈是打通從開發到運維基礎。為了保障內建質量的建立，兩個方面的工具鏈是不可缺少的，下面羅列了一些常用的工具，如果大家準備在軟體生命週期中增加內建質量的建設，可以參考下述工具

1. 專項工具類，解決特定質量檢查場景：

原始碼質量：SonarQube、checkmarx、fortify

單元測試：Junit

自動化測試：selenium、postman、yapi

效能測試：jmeter

安全：Xray、Dependance-check

2. 整合工具類，打通工具鏈流程，統一展示：

整合工具：Jenkins、TFS、GitlabCI、tekton、

製品管理工具：Artifactory

總結

    內建質量是精益、敏捷以及DevOps的核心原則之一，有助於避免與需求召回、返工及缺陷修復有關的延遲成本。所以內建質量，勢在必行。

更多精彩內容可以專注我們的線上課堂

微信搜尋公眾號：jfrogchina 獲取課程通知