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 的力量，企业将在数字化时代实现更高速的发展与更大的业务价值。