CODING 首届金融科技技术交流闭门会议顺利召开

[CodingNET]

近期，由腾讯云旗下一站式 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 的力量，企业将在数字化时代实现更高速的发展与更大的业务价值。