10 月 22 日,2021 届 DevOps 国际峰会在北京顺利召开,来自国内外的顶级技术专家共同畅谈 DevOps 体系与方法、过程与实践、工具与技术。CODING 测试及研发流程管理产品总监程胜聪(Diego)在大会现场接受了 CCTV《态度》栏目组的专访,也在 DevOps 最佳实践及解决方案专场为大家分享了他的主题——DevOps 时代的高效测试之路。
测试正在成为持续交付的最大瓶颈
业界对于测试的焦虑由来已久。从 2017 年开始,行业开始对测试困境形成共识,即测试不够快成为导致交付延期的主要原因。之后,行业开始强调自动化测试,提出打造快速反馈环、流水线工作流和工程文化等理念。
在这种背景之下,Diego 认为,持续测试是 DevOps 时代的高效测试之钥。测试作为一项基础的、持续的活动,理应贯穿于整个软件交付周期之中。持续测试改变的是传统测试后置的工作模式,让测试活动延伸到 SDLC 的每个阶段。
高效测试需要以自动化为实践基石
从一项对于测试时间花费的调研中可以得知,测试执行占了总时间的四成。因此如果要提升整体测试效率,首要的就是通过自动化来提升测试执行的效率。然而,测试团队发现即使在 CI 中配置好自动化代码库,由于待执行的用例集合是固定的,随着自动化测试覆盖率提升、自动化代码越来越多,运行时间越来越长,于是运行频率却越来越低,效果并不如人意。
Diego 指出,只是默默地写自动化代码是不够的,自动化测试需要"更聪明地执行"。如果能够人工地将需求(Req)、用例(Case)以及自动化函数(Func)关联在一起,灵活确定测试子集会让测试变得更加自由。如果某个自动化函数运行失败,则可以迅速定位到某个有问题的需求,团队再根据问题的优先级和影响,来判定是否能够继续发布。
新的时代,新的流程
在新的时代,提倡新的流程。持续测试并不仅仅只是自动化测试、还有对流程的全局优化,这需要我们从单点(执行)效率的提升延伸到全局效率的提升。工具/技术改进过程效率(efficiency),而流程会指向正确的结果(effectiveness)。
那么,DevOps 时代需要什么样的测试流程?
首先,Diego 认为敏捷宣言的四个“高于”清晰的指出了研发应该关注于为用户带来价值的行为和结果,而不是过程中的产物。
然而尽管协作很重要,却不意味着流程、文档、计划不重要。只要软件的复杂度还在,有助于软件顺利交付的流程、文档、计划都是必要的。只是需要相应变化、与时俱进——转为轻流程、简洁文档、尽早计划,或“演进式”的流程/文档/计划。
DevOps 需要更轻,更强调角色协作的流程。测试团队首先需要围绕需求开展测试,策略性定义子集,并且确定基于风险的测试策略。其次,团队需要推动测试左移,让测试与开发并行工作。在这个阶段,需要完成的工作包括单元测试、测试评审、代码扫描,以及基于接口定义的开发和自动化测试。最后,还需要实践测试右移,让“测试永不退出”—— 在部署之后,还需要进行线上的实时监控,保证问题得到快速发现和处理。
此外,DevOps 还需要健壮的规范和快速的反馈。Diego 认为:研发“一致性”是效能提升的基础,规范能够降低协作中的人为产生的主观复杂度、避免不必要的上下文理解。而快速反馈不仅仅是减少手工操作的“劳力花费”、更重要的是减少成员的“心力损耗”,让成员可以专注于自己的工作,不必要在不同平台之间来回切换。软件开发的艺术成分应该被关进笼子里,而在软件开发中并不需要艺术的部分,例如机械的判断选择、和协同所需操作,应趋向于科学化和量化。
腾讯云内部落地实践的分享
最后,Diego 向现场观众分享了腾讯云 CODING 团队内部的落地实践,展现研发一体化的高效测试是如果实现的。
在研发过程中,存在各种各样的活动。研发团队中的不同角色,如产品、开发、测试以及运维一般都只关注自己所负责的活动,然后不同角色活动之间也存在关联,协作产生的活动便形成一个完整的工作流。在此基础之上,加入准入准出规范可以让协作更加健壮,而自动操作则让流动更加高效。CODING 正是基于这样的逻辑,来为研发流程的高效管理设计出 CODING Compass 这一产品。
然而,DevOps 不应该只是研发团队自嗨的领域,我们还需要跟业务价值连接起来。通过把研发活动映射到业务人员所熟悉的阶段:计划、开发、测试、部署,并且保持对 Lead Time(前置时间)、Process Time(处理时间)、% of Completeness &Accuracy(完成&准确百分比) 等指标的关注和持续改进,形成价值流管理。
接下来,Diego 向大家介绍了腾讯云 CODING 团队是如何将测试活动嵌入其中的。
首先,迭代规划阶段会围绕着需求开展测试,策略性的定义测试子集。测试与开发紧密协作,同时认领同一需求任务。而当迭代 Backlog 确定下来之后,也就表示测试范围定下来了,测试计划就可以创建,而需求的验收标准也就可以直接转换为功能点用例。
而在迭代进行时,测试和开发并行进行工作,在开发人员编码单测的同时、进一步细化用例使之完整,并及时进行评审。在写自动化用例的时候,我们可以利用 CODING 平台的帮助实现自动化用例与功能用例的关联。
从而,当从测试计划中发起测试执行,关联的自动化用例会被指定执行。
通过践行研发一体化的高效测试,团队的高频发布得到了坚实的支撑,月均成功发布次数 400+,需求的测试覆盖度 96%,而且覆盖主干的自动化用例集通过持续重构基本上维持在 1400 的数量(冒烟自动化用例必须要在 15 分钟内执行完毕)。
最后,Diego 总结道:CODING 之所以能实现高效的测试,3 个方面理念的转变是尤为关键的。
首先是打破职能筒仓、实现目标共享。在过去开发和测试人员的目标通常是割裂、甚至相互对立的,开发人员看重写了多少行代码,测试人员则关注发现了多少个 bug。正确的观念应该是赋予团队同一目标,让不同角色围绕业务需求展开工作,共同交付高质量的软件。
其次是,改变“阶段式交接”为“小步快走”的工作模式。开发和测试应该以同样优先级顺序来处理需求,这样到了交付的时候得到的是成品而非“半成品”。一方面在全局通过控制在制品数量来缩短交付时间,另一方面在局部则通过自动化的手段来进行单点的加速。
最后,则是实现了真正为团队成员赋能。赋能并非要求所有人都是全才,而是让团队成员都放心的与其他人协作、或者使用其他人提供的工具和服务。为了解除疑虑、保障协作过程的顺畅,通过标准规范的设定来提升活动的一致性,为团队效能提升带来积极的影响。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。