AIGC在金融场景是如何落地的? 了解详情
写点什么

Netflix 的快速产品集成测试

  • 2016-08-24
  • 本文字数:3871 字

    阅读完需:约 13 分钟

Netflix 的会员体验是通过一个微服务架构实现的,而且针对八千多万会员做了个性化服务。这些服务是多个团队的工作成果,其中每一个团队都有各自建立和启动的生命周期。这就意味着,组建一支警醒且经验丰富的集成测试团队迫在眉睫,它要确保,即使每一天采取分散的方式把微服务部署出去,仍然能维持端到端的质量标准。

作为产品工程的集成测试团队,我们的章程不会和创新速度产生冲突,同时我们还要充当质量的守门人,并确保开发者能快速得到反馈。每一个开发团队都对自己交付产品的质量负责。我们的目标是在各个不同的工程小组中无缝协作,着眼于端到端的功能和团队之间的协调。这是一个精干的团队,在一家拥有两百多名工程师的公司中,我们有大批集成测试工程师。

以惊人的速度进行创新,同时确保质量,持续不断地为我们团队创造有趣的挑战。在这篇文章中,主要讲三个挑战:

  1. 测试和监控高影响力的影片(HIT’s)
  2. A/B 测试
  3. 在全球范围上架

测试和监控高影响力的影片

有很多“高影响力的影片”(HIT’s)有规律地在 Netflix 上架,比如《女子监狱》。它们有各种各样的形式和体量。有些是连续剧,有些则是独立的,有些是专门给儿童看的,有的是整季剧集同时发布,还有些是每周发布几集。这些影片中的一部分会在上架前经历复杂的 A/B 测试,每个测试单元测一项不同的会员体验。

这些影片对我们的会员来说可见度非常高,因此就要大量地测试。在上架前几周,测试就开始了,一直持续到上架当天。上架后,我们会在不同的设备平台,在所有国家范围内监测它们。

根据影片放映所处的不同阶段,测试的策略也有所不同。不同的阶段有不同的宣传策略,这让测试 / 自动化变得非常复杂。基本分为两个阶段:

  1. 影片上架前:上架前,我们必须确保影片的元数据就位,能够允许上架当天平稳运行。因为在 HIT 影片上架中牵扯到很多团队,我们需要确保所有的后端系统之间能够相互沟通,也能无缝与前端 UI 沟通。影片是通过 Spotlight 进行宣传推广的(Spotlight 是 Netflix 主页顶部那个像大型广告牌一样的显示区),既有悬念式广告也有预告片。然而,因为在 Netflix 每一层级都有个性化定制,我们必须创建复杂的测试用例,来确保正确的标题类型适用到了正确的会员画像上。而由于系统是用 flux 架构的,它就使得自动化非常难。所以这个阶段的测试大多是手动的。
  2. 影片上架后:工作并没有在上架那天结束。我们得持续监测上架的影片,确保它们的会员用户体验不在任何情况下受损。影片转变为庞大的 Netflix 目录中的一部分,对它们自己来说也是挑战。这时候我们就需要写测试来检查,这些影片是否能继续抵达它们的受众,影片的数据集成是否能保持。(比如说,一些测试能证实一个剧集的概要是否从上架那时起就没有改动过,另一些测试能证实搜索结果是否持续能返回正确的影片搜索字符串。)然而今年,单是 Netflix 自制的节目,就将上架长达 600 小时的内容,除了授权的内容,我们不再能够依赖手动测试了。此外,影片一旦上架,我们就会假设能把它做好,因为数据和推广逻辑是不变的。举例来说,电视剧集数>0,影片可搜索(不论是电影还是电视剧),等等。这就能让我们利用自动化持续监测和检查,是不是拥有相关属性的影片都能继续这样顺畅操作。

HIT 测试是充满挑战的,而且总是被截止日期驱动着。但能参与到影片上架的过程中,确保所有相关的功能和后端逻辑在上架当天正确运行,这也是很让人兴奋的经历。能够看到名人,还能得到些 Netflix 纪念品,也算是不错的福利了。:)

A/B 测试

我们做很多的A/B 测试。在每一个可能的地方,我们都有A/B 测试在运行,而且全部有相异层级的复杂度。

过去,大部分A/B 测试的确认都是自动化和手动测试的结合,自动测试是总是被用于单独的元件(白盒测试),端到端的测试(黑盒测试)则大多是手动的。鉴于我们A/B 测试的体量正在不断增加,手动验证端到端测试是不能够规模化的,于是我们开始倾向于自动化。

为A/B 测试添加自动化端到端的过程中,一个主要的挑战就在于需要自动化的元件数量之多。我们过去的办法是,将测试自动化看做是可交付的产品,然后着眼于交付由可重复利用的片段构成的最简可行产品(MVP)。我们的MVP 需求是,能够通过激活多种微服务中的REST 端点数据,维护基本的会员体验。这就给了我们机会反复寻找解决方案,而不是从一开始就寻找最完美的解决方案。

拥有一个通用的库是个非常有必要的开端,它让我们有能力在每次自动测试中重复利用模块和改变模块用途。举例来说,我们有一项A/B 测试会导致修改会员的MyList。一旦自动化这项,我们就会写一个添加/ 删除会员MyList 影片的脚本。这些脚本会被参数化,这样它们就能在以后可能涉及MyList 的A/B 测试中重复使用。这个方法使得我们拥有了更多可重复利用的构建模块,从而加速自动化A/B 测试。我们还通过使用尽可能多的现存自动化来获取高效率。举例来说,可以利用 Netflix Test Studio ,通过不同设备间的 UI 动作来触发测试场景,而不是自己写 UI 自动化。

当选择语言 / 平台来实现自动化时,我们的着眼点在于给产品团队快速提供反馈。鉴于此,就需要真正快速的测试套件,快速到秒的级别。我们还希望测试能尽可能简单地执行和部署。有了这样两个内在需求,就不用考虑 Java 了。如果用 Java,我们的测试将会依赖于某几个相互依赖的 Jar 文件,我们将不得不经常性地依赖管理,更新版本,并且对不同版本的 Jar 文件变动也非常敏感。那样最终会明显增加测试运行的时间。

我们决定通过 REST 端点访问微服务来实现自动化,这样就能不使用 Jar 文件,并且避免了引入任何业务逻辑。为了确保执行和部署自动化的过程简洁,我们决定采用可以在命令行中执行参数化的 shell 和 Python 脚本的组合。将会有一个单独的 shell 脚本来控制测试执行,这将调用其他的 shell/python 脚本作为可重复利用的程序。

这样的做法催生了下面这些益处:

  1. 实现了将测试运行时间(包括安装和拆除)控制在 4-90 秒之间,中间运行时间是 40 秒。如果采用 Java 为基础的自动化,我们预计中间运行时间会达到 5-6 分钟。
  2. 持续集成被简化了。我们所需的一切就是一个 Jekins Job 而已,它会将代码从我们的通用库中下载下来,执行脚本,并记录结果。对提供测试通过 / 失败统计来说,Jekins 内置的控制台日志解析也足够用了。
  3. 很容易上手。让另外一个工程师来运行我们的测试套件,就只需要进入我们的 Git 库和终端。

在全球范围上架

Netflix 2015 年最大的项目之一,就是确保为它同时在 130 个国家平稳上架准备足够快速的集成测试。这意味着,至少我们的烟雾测试套件在每个国家和语言组合中都实现自动化。这事实上就为我们的自动化产品添加了另一个功能维度。

我们的测试足够快,所以起初决定,只需将测试代码在每个国家 / 地区循环运行。结果却是,本来需要 15 秒完成的测试,现在却需要一个多小时。必须找到一个更好地解决这个问题的办法。除此之外,每一个测试日志,现在都是以前的 250 倍那么大,也就使得调查故障的任务更加繁重。为了解决这个问题,我们做了这样两件事:

  1. 利用 Jenkins 的 Matrix 插件来做并行测试,这样每个国家的测试都将是平行运行的。为了使用多个 Executor,从而避免其他 Job 在我们的测试进程中排队,进而形成竞争条件或者无限循环,我们就必须定制自己的 Jenkins slave。这是可行的,因为我们的自动化只需要运行 shell 脚本,而不必预加载二进制文件。
  2. 我们不想重构每一个测试,也不希望每一个测试运行都与其他单独的国家 / 地区冲突。因此,我们决定使用一个可选择加入的模式,这样可以继续像之前写测试一样写自动测试,并做出一个全球可用的测试,一个额外的封装会被加入到测试中。这个封装会取用测试案例 ID,国家 / 地区会作为参数,然后用这些参数执行测试,就如下图所示:

今天,Netflix 在全球范围内实现了自动化运行,覆盖了所有高优先级集成测试案例,包括监测所有影片在架地区的 HIT 影片。

未来的挑战

Netflix 的创新速度并没有放缓,它只会加快。作为结果,我们的自动化产品也要继续进化。在 Netflix 的版图中有这样一些项目:

  1. 基于工作流程的测试:这会包含将一个测试案例当做一个工作流程,或者一系列步骤,它们模拟的正是通过 Netflix 服务管道的数据流动。这样做的原因在于很容易识别出现故障的步骤,从而削减调查测试故障的预算。
  2. 警报集成:Netflix 内部贯穿着一些警报系统。一旦某个确定的警报被触发,它却不一定和执行特定的测试套件有关。这是因为测试可能依赖于并未 100%起作用的服务,从而发生故障,这给我们的结果就是不一定会对它做出反应。Netflix 需要建立一个能够听从这些警报的系统,然后决定需要运行什么测试。
  3. 混沌集成:我们目前的测试假设 Netflix 的生态系统是 100%起作用的,然而,这可能不总是对的。可靠性工程团队一直在运行混沌演习,来测试整个系统的集成。目前,在一个恶化的环境中,测试的自动化结果显示,不合格率上升到 90%。我们需要提高自身的测试自动化,从而在恶化的环境中提供相关的测试结果。

在以后的博文中,我们将在更深的层面探索和讲述前行中的挑战和其他的主动行为。在转变为快速的持续发展的进化系统过程中,Netflix 自由和负责的文化,扮演着重要的角色。在未来还有更多的实验,更多新的挑战要去面对。如果全新的挑战,让你感受到和我们一样的兴奋,也欢迎加入Netflix

查看英文原文 Product Integration Testing at the Speed of Netflix


感谢陈兴璐对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ @丁晓昀),微信(微信号: InfoQChina )关注我们。

2016-08-24 17:211933

评论

发布
暂无评论
发现更多内容

美团增量数仓建设新进展

Apache Flink

大数据 flink 实时计算

云桌面五大优势,开启智慧校园云端新时代!

青椒云云电脑

桌面云 云桌面

云桌面办公的三个优点

青椒云云电脑

桌面云 云桌面

企业网络安全守护神-行云管家堡垒机!

行云管家

运维 网络安全 数字化 堡垒机

隐语小课|两方安全计算 ABY2.0 高效的 2PC 协议

隐语SecretFlow

大数据 AI 数据安全 隐私计算 开源社区

基于静态编译构建微服务应用

阿里巴巴云原生

阿里云 云原生

中国人民大学周禹教授:数智人本主义-人力资源数智化驱动有质量增长

用友BIP

zone.js由入门到放弃之一——通过一场游戏认识zone.js

OpenTiny社区

前端 js

Flink_state 的优化与 remote_state 的探索

Apache Flink

大数据 flink 实时计算

云桌面如何工作?

青椒云云电脑

桌面云 云桌面

合约跟单带单模式量化交易系统软件开发[源码搭建示例]

V\TG【ch3nguang】

量化交易系统开发 合约跟单 量化交易源码

如何将IP定位SDK添加到您的 Android 应用程序

郑州埃文科技

软件 sdk

DEFI/LP质押流动性挖矿奖励发放模式系统开发

V\TG【ch3nguang】

DeFi流动性挖矿

官宣定档!望繁信科技数聚·源力 2023 PRO_大会诚邀您参加!

ToB行业头条

亿级月活的社交APP,陌陌如何做到3分钟定位故障?

TakinTalks稳定性社区

阿里云故障洞察提效50%,全栈可观测建设有哪些技术要点?

TakinTalks稳定性社区

公有云、私有云和混合云的云桌面有什么区别?

青椒云云电脑

桌面云 云桌面

什么是云桌面?

青椒云云电脑

桌面云 云桌面

用友发布《大型企业项目数智化转型白皮书》

用友BIP

Termius Beta for Mac(跨平台SSH客户端) 7.34.1中英文版

mac

ssh客户端 苹果mac Windows软件 Termius

云桌面系统解决方案

青椒云云电脑

云桌面 云桌面解决方案

腾讯云升级发布新一代云数仓产品 CDW ClickHouse,万亿规模数据分析毫秒级响应

腾讯云大数据

数仓

让大数据平台数据安全可见-行云管家

行云管家

大数据 数字化 数据安全 大数据平台

开发者必看:深度解读隐语密态计算设备 SPU

隐语SecretFlow

大数据 AI 隐私计算 开源社区 密态计算

数字孪生智慧粮仓Web3D可视化管理系统

2D3D前端可视化开发

智慧粮仓 智慧粮库 智慧粮仓管理系统 数字孪生粮仓 粮仓三维可视化

R语言之基本包

timerring

R 语言

Blender中有哪些有趣的插件

Finovy Cloud

blender Blender制作 Blender制作教程 Blender Apps blender软件资讯

如何从用户视角搭建可观测体系?阿里云ECS业务团队的设计思路

TakinTalks稳定性社区

国内哪家云桌面厂家比较靠谱

青椒云云电脑

云桌面 云桌面厂家

提高生产力的低代码开发工具

高端章鱼哥

软件开发 低代码 开发工具 JNPF

阿里云 X 森马 AIGC T恤设计大赛开启! 穿什么由你定,赢Airpods,作品定制联名T恤

Serverless Devs

阿里云 Serverless 云原生

  • 扫码添加小助手
    领取最新资料包
Netflix的快速产品集成测试_DevOps & 平台工程_fazal allanabanda_InfoQ精选文章