Netflix的快速产品集成测试

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

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

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

测试和监控高影响力的影片（HIT’s）\\t
A/B测试\\t
在全球范围上架\

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

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

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

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

\\t

影片上架前：上架前，我们必须确保影片的元数据就位，能够允许上架当天平稳运行。因为在HIT影片上架中牵扯到很多团队，我们需要确保所有的后端系统之间能够相互沟通，也能无缝与前端UI沟通。影片是通过Spotlight进行宣传推广的（Spotlight是Netflix主页顶部那个像大型广告牌一样的显示区），既有悬念式广告也有预告片。然而，因为在Netflix每一层级都有个性化定制，我们必须创建复杂的测试用例，来确保正确的标题类型适用到了正确的会员画像上。而由于系统是用flux架构的，它就使得自动化非常难。所以这个阶段的测试大多是手动的。

\\t\\t
\\t
影片上架后：工作并没有在上架那天结束。我们得持续监测上架的影片，确保它们的会员用户体验不在任何情况下受损。影片转变为庞大的Netflix目录中的一部分，对它们自己来说也是挑战。这时候我们就需要写测试来检查，这些影片是否能继续抵达它们的受众，影片的数据集成是否能保持。（比如说，一些测试能证实一个剧集的概要是否从上架那时起就没有改动过，另一些测试能证实搜索结果是否持续能返回正确的影片搜索字符串。）然而今年，单是Netflix自制的节目，就将上架长达600小时的内容，除了授权的内容，我们不再能够依赖手动测试了。此外，影片一旦上架，我们就会假设能把它做好，因为数据和推广逻辑是不变的。举例来说，电视剧集数＞0，影片可搜索（不论是电影还是电视剧），等等。这就能让我们利用自动化持续监测和检查，是不是拥有相关属性的影片都能继续这样顺畅操作。

\\t\

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脚本作为可重复利用的程序。

\\\\

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

\\t

实现了将测试运行时间（包括安装和拆除）控制在4-90秒之间，中间运行时间是40秒。如果采用Java为基础的自动化，我们预计中间运行时间会达到5-6分钟。

\\t\\t
\\t
持续集成被简化了。我们所需的一切就是一个Jekins Job而已，它会将代码从我们的通用库中下载下来，执行脚本，并记录结果。对提供测试通过/失败统计来说，Jekins内置的控制台日志解析也足够用了。

\\t\\t
\\t
很容易上手。让另外一个工程师来运行我们的测试套件，就只需要进入我们的Git库和终端。

\\t\

在全球范围上架

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

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

\\t

利用Jenkins的Matrix插件来做并行测试，这样每个国家的测试都将是平行运行的。为了使用多个Executor，从而避免其他Job在我们的测试进程中排队，进而形成竞争条件或者无限循环，我们就必须定制自己的Jenkins slave。这是可行的，因为我们的自动化只需要运行shell脚本，而不必预加载二进制文件。

\\t\\t
\\t
我们不想重构每一个测试，也不希望每一个测试运行都与其他单独的国家/地区冲突。因此，我们决定使用一个可选择加入的模式，这样可以继续像之前写测试一样写自动测试，并做出一个全球可用的测试，一个额外的封装会被加入到测试中。这个封装会取用测试案例ID，国家/地区会作为参数，然后用这些参数执行测试，就如下图所示：

\\t\

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

未来的挑战

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

\\t

基于工作流程的测试：这会包含将一个测试案例当做一个工作流程，或者一系列步骤，它们模拟的正是通过Netflix服务管道的数据流动。这样做的原因在于很容易识别出现故障的步骤，从而削减调查测试故障的预算。

\\t\\t
\\t
警报集成：Netflix内部贯穿着一些警报系统。一旦某个确定的警报被触发，它却不一定和执行特定的测试套件有关。这是因为测试可能依赖于并未100％起作用的服务，从而发生故障，这给我们的结果就是不一定会对它做出反应。Netflix需要建立一个能够听从这些警报的系统，然后决定需要运行什么测试。

\\t\\t
\\t
混沌集成：我们目前的测试假设Netflix的生态系统是100％起作用的，然而，这可能不总是对的。可靠性工程团队一直在运行混沌演习，来测试整个系统的集成。目前，在一个恶化的环境中，测试的自动化结果显示，不合格率上升到90％。我们需要提高自身的测试自动化，从而在恶化的环境中提供相关的测试结果。

\\t\

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

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

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

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