CODING 首屆金融科技技術交流閉門會議順利召開

近期，由騰訊雲旗下一站式 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 的力量，企業將在數字化時代實現更高速的發展與更大的業務價值。