近期，由騰訊雲旗下一站式 DevOps 開發平臺 CODING 和中國 DevOps 社群主辦的深圳第十一屆 Meetup 圓滿結束，會上三位專家分享了自己獨到的行業見解，騰訊雲 CODING DevOps 產品經理陳信州，在會上釋出了題為《WePack 產品團隊測試實踐探索》的精彩演講。與往屆不同，本次活動 CODING 新增了金融科技技術交流閉門會議環節，邀請了騰訊、平安銀行、深圳農商行、OPPO 金融、南方基金、大疆等數十位行業大咖蒞臨騰訊濱海大廈共享 DevOps 盛宴。
▲ 參觀騰訊濱海大廈展廳合影
▲ 閉門會議現場
以下為閉門會議亮點內容分享——
DevSecOps，DevOps 模式下軟體開發的安全之鎖
網際網路時代，網路資訊保安是永恆的話題，本次閉門會議便以“安全”開篇展開討論。
在眾行業中，金融行業對於安全有著更高的訴求。蒞臨閉門會議的金融企業嘉賓率先向大家介紹了所屬金融企業在安全領域的探索。隨著 DevOps 在金融企業的落地，其快速交付能力與傳統安全模式形成鮮明衝突，使得安全性成為快速交付的瓶頸。這促使該金融企業不得不加緊由 DevOps 向 DevSecOps 轉型的步伐。通過將應用安全思維模式逐步左移到開發團隊，從而進一步提升交付效率，加強風險控制，減少返工成本。
在 DevSecOps 實踐上，金融企業的特點之一是購買市場上專業安全工具。通過將 Fortify、Checkmarx 等安全掃描工具接入到研發流程中，讓安全充分滲透到 DevOps 流程的每個階段和檢查點。其次是文化薰陶，通過加強 DevSecOps 培訓和考核，構建配套的評價機制。從而打造一支真正成熟的 DevSecOps 團隊。
如何來衡量團隊的 DevSecOps 的成熟度呢？參會的一家金融企業主要做了以下工作：
通過制定培訓時間和修復安全漏洞的能力等衡量指標，將 DevSecOps 成熟度分為數個等級，構建了完善的 DevSecOps 成熟度度量模型；團隊中所有的開發人員必須達到一級水平；團隊中的 Security Champion，至少達到三級水平到五級水平；並且保證工具掃描出來的高危漏洞在釋出進入產品前被及時解決；一旦評審通過的 DevSecOps 團隊，會根據成熟度級別簡化相應的安全掃描和稽核流程，使得開發團隊可以更快更安全地交付產品 。
其他金融企業的嘉賓也表示會在開發流程中嵌入安全方面的能力，並施行嚴格的流程管控，配備專業的應用安全團隊對漏洞進行管理。
測試 or 開發，測試用例到底應該由誰來寫？
談到測試時，大家最為關注的就是測試用例的歸屬，到底誰來寫？是測試人員、開發人員還是產品經理？在實際的討論中發現，三者因為服務的產品、專案不同，都有可能承擔撰寫測試用例的角色。金融企業業務複雜性高，往往會碰到開發或測試同學對業務理解不夠深入的情況，測試用例往往由 BA 或者業務人員撰寫。而 DevOps 推薦是由開發人員進行測試用例撰寫。開發人員作為需求的實現者，通過撰寫測試用例的方式，闡述自己對於功能需求的理解，再由產品和測試同學進行評審，更好地在測試用例中呈現出功能需求與開發邏輯。當然，在場的很多嘉賓反映，當前大多數企業的現狀是由測試人員來寫測試用例的，因為作為該環節的責任人和專業人士，能更清晰地展示測試脈絡，更迅速地抓住測試重點。
另外，關於單元測試的覆蓋率，在場嘉賓也是各抒己見。總的來說，相比網際網路行業，金融行業業務變化緩慢，對業務穩定性要求更高、因此對單元測試覆蓋率要求也更高。而網際網路行業業務迭代快，對單元測試維護成本高，因此相比金融行業，網際網路行業對單元測試覆蓋率要求並不高。但是，測試最終目的是保證產品質量，依據實際業務情況判斷並優化測試手段才是正確的選擇。
在 DevOps 過程中，如何合理使用度量？
“測試缺陷等級怎麼清晰定義，沒定義的清晰的話又會扯皮。”
“提測之後開發自己又發現了問題，很難確認正向和負向。”
“度量是一個深淵，哪怕說不作為績效考量，作為開發同學還是會很介意，甚至進行造假。”
一提起度量，各家都是滿腹苦水。在推動 DevOps 的過程中，為保障產品或專案質量，質量度量往往被視為通用的考核方式，受產品、專案、開發階段、行業屬性、企業文化的影響，度量指標構成都有所不同。本次閉門會議，嘉賓也對所屬企業的度量質量建設以及面臨的問題進行了討論。相比理論，實際工作中，一方面產品、專案很多內容難以被量化，另一方面即使定義清晰的指標，由於“人”的參與，會被過分關注，再加上度量往往和績效關聯，這讓度量變得愈發敏感與複雜。
會上，大家也分享了一些優質實踐。
-
由於每個團隊的能力水平不同，建議在團隊正常執行半年後，再設立團隊考核指標的基準。提倡自我縱向對比，不暴露和批評差的團隊，通過趣味、獎勵等方式鼓勵大家提升整體的產品質量。
-
在過程中，可以通過逃逸、質量事故進行度量。在研發階段，主要以低階質量缺陷為依據，再通過提測打回率、缺陷密度、漏測率等綜合指標評判程式碼質量。
-
度量指標的制定應該結合業務價值、測試及需求覆蓋率等關鍵因素，並劃分優先順序。為避免副作用，不建議單獨地以區域性指標為考核標準，度量指標應整體綜合運用。
其實，度量的最終目的是服務產品、專案和客戶，帶來全域性的正向改變。因此，希望大家以終為始，不要盲目做度量。
通過大家的交流我們發現其實每個企業對於 DevOps 都有不同的理解，也正是這樣，各行各業圍繞 DevOps 催生出一系列優質的實踐。相信藉助 DevOps 的力量，企業將在數字化時代實現更高速的發展與更大的業務價值。