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