V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
Coding.NET 轻量级社交
开源项目广场
使用帮助
意见反馈
CodingNET
V2EX  ›  Coding

持续测试 | DevOps 时代的高效测试之钥

  •  
  •   CodingNET · 2021-05-31 16:55:06 +08:00 · 546 次点击
    这是一个创建于 1064 天前的主题,其中的信息可能已经有所发展或是发生改变。

    本文作者:程胜聪 - CODING 产品经理

    时代带给测试的挑战

    测试一直是软件研发过程质量的重要保障,而在传统研发模式中,测试活动总是处于软件生命周期中相对滞后的环节,相信我们对以下对话场景不会感到陌生:

    1. 规划好需求之后:

      “这个版本的 X 功能很关键,测试一定不能漏掉!”

      “好的,我们已经在需求列表中做了备注。”

    2. 开发过程中:

      “这次的功能做完了吗?”

      “开发完成了,但是还没有测完。”

    3. 临近发布日期了:

      “功能已经上线了吗?”

      “到预发布环境了,回归测试还在进行中、之后对比分析还需要时间。”

    以上提到的问题:“测了什么”、“测完了没”、和“测得快吗”,可谓是团队经常面临的“灵魂三拷问”。而随着敏捷 & DevOps 模式在软件行业的推广落地,更频繁的交付更是加重了业界对测试的担忧,测试不够高效往往成为导致交付延期的首要原因,测试环节也就成为了企业进行 DevOps 转型的最大瓶颈。

    为了应对这样的挑战,“持续测试”(或者“敏捷测试”)概念被提出并慢慢成为了业界的必然追求。持续测试能够满足以下几个核心诉求:

    1. 测了什么:不能实现 100% 回归测试覆盖的前提下,基于业务价值来划分测试子集。
    2. 测完了没:在持续交付的过程中,按需进行测试并且提供快速反馈。
    3. 测得快吗:让测试执行的足够快。

    什么是持续测试?

    来自维基百科的定义:在软件交付流水线中执行自动化测试的过程,目的是为了获得关于预发布软件业务风险的即时反馈。如下图持续交付的莫比乌斯环所示:

    诚然,上述定义充分强调了自动化测试的重要性,这是持续测试的基础。但是回到“通过持续测试获得效率提升”的最终目标上,仅仅提升测试执行方式这个单点效率,还不足以体现持续测试所带来的测试理念转变的本质。从整体测试效率的角度出发,DevOps 另外一个双生概念“敏捷”模式所描述的“迭代内测试“( in-sprint testing )或者“敏捷测试”就成为了更好的补充:持续测试应该作为一项基础和持续的活动、贯穿于整个软件交付周期之中。来自 Jenkins 社区的图片更好地体现了这一概念:

    如何实现持续测试?

    持续测试改变的是传统测试后置的工作模式,让测试活动延伸到软件开发生命周期的每个阶段。

    1. 需求规划阶段,尽早计划测试,并且策略性定义测试子集。

    首先,从需求分析的阶段就开始提前计划测试、编写测试用例,使之达成适当的需求覆盖率。对此需要有帮助地实践包括 ATDD 、BDD,尤其是 TDD 难以落地的团队可以尝试 ATDD 。其次,要有优化测试覆盖范围的意识。测试不应该盲目追求 100% 覆盖,而是基于业务风险和价值的测试策略进行测试( Risk-based Testing ),“100% 覆盖优先级高的需求”远比“80% 覆盖了所有需求”来得有价值。

    2. 迭代进行当中,推动测试左移( Shift-left ),实现测试与开发并行工作。

    测试执行应该前置到软件开发生命周期的早期,多种工程实践可以帮助团队实现左移:比如重视测试评审,通过单元测试进行基础性保障,基于接口定义的开发和自动化测试,引入代码扫描判断是否满足编码规范和工程标准。这样在迭代周期内,就能围绕着需求持续进行集成测试用例的编写,并且与开发保持进展协同,为开发提供必要的测试支持,使得测试与开发的工作实现同步进行。

    3. 迭代进行当中,以便捷的方式提供完整的测试环境和正确的测试数据。

    一直以来,接近生产的测试环境打造和脱敏数据的快速准备是团队面临的两大重要挑战。如今随着云原生技术的成熟,尤其是 Docker 技术的发展,让按需搭建和销毁环境变得可能。但是测试数据的管理仍然是个难题,基础数据如账号信息、环境信息这一类容易标准化的数据在业内已经有了比较好的解决方案,这已经是个重大进步。而业务数据由于场景多变性一直缺乏足够好的业务抽象,还处于依赖框架进行流程规范的基础阶段,基于接口定义的开发从而实现 Mock 服务也能够带来过程效率的提升。

    4. 应用部署之后,关注测试右移( Shift-right )。

    传统瀑布模式把部署作为测试的下一阶段,也就意味着应用发布上线、快速验证功能之后就是测试的结束。而持续测试则不认为发布完成测试就退出了,强调的是在版本上线后、继续关注生产环境的数据监控和预警,及时发现问题并跟进解决,将影响范围降到最低。并且利用生产上的数据可以为开发过程带来切实的价值:比如复制生产数据进行脱敏来准备测试数据,对服务访问数据进行分析的结果也可为开发过程中的测试提供优化的指引、从而调整测试并形成更好的冒烟和回归测试策略等等。右移的实践包括数据分析、灰度 /金丝雀发布、线上实时监控、用户反馈的跟踪处理流程等等。

    此外,我们在实践持续测试的过程中要关注数据的沉淀,然后基于数据指标不断优化我们的行为,从而实现 DevOps 所推崇的持续改进的团队文化。随着软件行业内敏捷和 DevOps 文化的不断传播,研发团队必然会期望实现更短的迭代周期,更有效地提高软件开发质量,更快地交付业务价值。

    CODING 秉承为企业研发团队提供一站式 DevOps 解决方案的理念,通过强大的测试管理功能,助力研发团队将测试作为基础活动贯穿于软件交付的整个过程中,大大缩短软件交付周期,让测试和研发同步迭代,实现持续测试,帮助团队将注意力回归高质量交付。

    目前尚无回复
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   5248 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 33ms · UTC 08:31 · PVG 16:31 · LAX 01:31 · JFK 04:31
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.