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。正确的观念应该是赋予团队同一目标，让不同角色围绕业务需求展开工作，共同交付高质量的软件。
其次是，改变“阶段式交接”为“小步快走”的工作模式。开发和测试应该以同样优先级顺序来处理需求，这样到了交付的时候得到的是成品而非“半成品”。一方面在全局通过控制在制品数量来缩短交付时间，另一方面在局部则通过自动化的手段来进行单点的加速。
最后，则是实现了真正为团队成员赋能。赋能并非要求所有人都是全才，而是让团队成员都放心的与其他人协作、或者使用其他人提供的工具和服务。为了解除疑虑、保障协作过程的顺畅，通过标准规范的设定来提升活动的一致性，为团队效能提升带来积极的影响。
