內建質量，你真的瞭解麼？

內建質量定義

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

1.敏捷中的內建質量

內建質量是規模化敏捷SAFe的核心價值觀，引用下面一段話，咱們看一下敏捷中定義的內建質量在講什麼內容（原文出處:https://www.scaledagileframework.com/built-in-quality/）

簡單的翻譯過來就是，產品一旦被髮布以後就有了好壞之分，經過某些檢驗方式已經沒法提升或保證它的質量，因此質量檢驗必須內置在產品或服務構建的過程當中，而不能在它發佈以後。

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 獲取課程通知**