LinkedIn:移动APP开发中的自动化测试与持续部署流水线

最近,有很多人问我关于“移动应用开发中的自动化测试如何做?持续集成和部署流水线从哪里开始?”的问题,觉得有必要写一写。恰好这个周末在家无意间看到Linkedin的做法,觉得非常有意思,尤其是截屏做对比测试的做法,在移动应用中比较少见, 在这里与大家分享。原文地址在这里

几个月前,LinkedIn发布了新的移动 APP,支持多种平台,包括  Native App和 Html5。

brand new mobile experience on a wide variety of platforms, including native apps and HTML5 webapps. 在这背面,我们在客户端大量使用了JavaScript和HTML 5,在服务器端也严重依赖于Node.js。为了能够快速地开发、测试和发布,我们构建了一个持续集成自动化流水线。本文中,我讲述如何做移动应用的持续集成工作。

概述

下面是LinkedIn移动应用的总体架构。

图1 LinkedIn 移动应用架构

我们所支持的各种平台 (iPhone, Android, mobile web)主要使用JavaScript和HTML向我们的Node.js 移动服务器发送RESTful请求。而这个服务器通过RESTful调用从LinkedIn平台上获取数据。关于我们的移动架构,你可以在这里这里了解到更多的内容。

持续集成流水线

我们的移动持续集成流水线一共包括五个阶段:

  1. Unit tests: 通常少于10秒,用于测试独立的模块和单元
  2. Fixtures tests: 通过使用静态或模拟数据对客户端应用进行测试。
  3. Layout tests: 通过截屏并与基线图像进行对比,测试客户端应用的Layout。
  4. Deployment: 自动部署到一个试运行环境中。
  5. End-to-end tests: 在试运行环境中进行端到端的测试。

 

前面的阶段通常比后面的阶段要快,而且在后一个阶段开始之前,必须保证前面的100%通过。

单元测试及覆盖率

我们使用Hudson做我们的持续集成服务器,让它在每次提交之后就执行单元测试。我们用

JsTestDriver 做测试框架,因为它是能够支持持续集成的仅有的几个JavaScript单元测试框架之一。另外,它还可以计算测试覆盖率:

图2. JsTestDriver中的代码覆盖率

 

Fixtures tests

我们可以通过配置让客户端向一个nginx服务器发送请求,它会以JSON文件格式返回test fixtures。由于这些测试完成与模拟数据打交道,所以只要出错,就可以认为是客户端的bugs。而且,这些模拟数据的使用令测试执行得更快。

我们还可以在测试过程中配置nginx,用来查看客户端是如何处理不同的HTTP状态码的。你可以看一下我们用的nginx规则,用于确保我们的客户端代码能优雅地处理HTTP500错误,或204等等。

Layout tests

这种fixtures环境也让我们可能运行layout tests,它可以自动地验证界面渲染是否正确,而不需要人用肉眼来看。我们使用WebKit Layout 和Rendering 来做无标题栏(抬头)的浏览器截屏。当界面开发完成后,这个截屏就被标记为基线。更进一步,我们只要根据这个基础PNG文件进行对比,就可以发现回归问题。

这些工具fixtures会让那些引起UI变化的随机数据最少化。有一少部分情况下,渲染总是动态的,比如时间戳,在截屏之前,我们执行特定的JavaScript用静态数据来取代动态的数据。PNG的比较,我们也增加了一些容忍度,因为在某些情况下,WebKit会生成稍有不同的PNG文件。

部署与端到端测试

​当layout tests全部通过以后,一个产品构建就会自动化的部署到试运行环境中,并运行端到端的测试。这些测试会在整个架构上执行全路径,并试图捕获在之间的测试中可能遗漏的任何集成问题。我们在生产环境上也运行端到端的测试,使我们可以快速地识别任何live site的问题,比如某个服务器宕机了,或者负载平衡器出了问题。我们使用Selenium WebDriver 和 TestNg.来创建端到端的测试。我们成功地使用 iPhoneDriver 让这些测试可以运行在一个iPhone模拟器之上。我们想用AndroidDriver,但是最近,被CSS selectors的一个问题阻塞了。WebDriver团队刚刚修复完。而Selenium-WebDriver的测试可以使用很多种语言来写,而我们用Java,因为对它的支持比较广泛。这里有一些Selenium-WebDriver测试的例子。

我们使用JSCoverage来分析端到端测试的覆盖率:

图3. JSCoverage: 红色是没有被端到端测试执行到的代码

 

小结

通过所有这些移动持续集成的阶段,我们的测试覆盖率为75%,这使我们能捕获到很多bugs,尤其是单元测试和fixtures tests。这些测试的一个要点是快速:当新代码提交后,通常不到5分钟就可以找到。在发现漏到开发中后面阶段(比如试运行和生产环境)的问题来说,端到端测试也是有帮助的。

在不久的将来,随着团队更趋于测试驱动开发(TDD),我们会在流水线的最后增加一个阶段:向生产环境部署。这样,就达成了持续部署的目标。

 

Published by

乔梁

乔梁,百度项目管理部高级架构师

One thought on “LinkedIn:移动APP开发中的自动化测试与持续部署流水线”

Leave a Reply

Your email address will not be published. Required fields are marked *