去哪儿网持续集成之自动化测试解决方案

郑希文

加入去哪儿前，就职于百度质量部，负责个性化推荐相关系统的质量保证和技术改进工作。

2014年4月加入去哪儿，目前整体负责平台事业部系统质量保证组相关工作，始终致力于工程效率和自动化测试等工作方向。

背景和目标

去哪儿网作为一家互联网公司，为了适应风云变幻的市场和业务，时刻都可能在进行服务的线上发布。在如此频繁的迭代频率下，如何保证质量成为技术团队最大的挑战。传统的“ dev 开发提测， qa 测试上线”的流程显然力不从心，自动化测试势在必行。目前，业务团队的 dev 和 qa 根据系统功能建立起自动化 case 集合，以接口自动化 case 为主。在拿到一定收益的同时，也遇到了问题，具体如下：

1、起初在流程上要求：开发在提测前必须跑一遍自动化 case ，保证 case 都通过后才能提测； qa 在项目上线前也必须执行自动化 case 来保证回归测试的覆盖。然而，由于各种主观客观的原因，比如在一些发布时间要求很紧张的项目里，并不能保证每个项目都跑自动化 case 。自动化的效果大打折扣，项目存在漏测的风险。我们在 review 线上故障的时候发现，有些问题如果执行了自动化 case 是可以提前发现的。

2、由于自动化 case 维护无法和程序迭代保持同步，导致 case 频繁的失效。 qa 需要花大量的人力把 case “追回来”，极大的增加了 case 的维护成本。

3、如果自动化 case 的价值得到团队内成员的认可，它应该作为项目发布上线的必要条件。然而我们发现，仍然存在“有自动化 case 失败且未确认原因，就发布上线”的情况。

针对上面的问题，为了持续高效的保证服务迭代的质量，我们急需一套完整系统的自动化测试解决方案。该方案需要具备以下特性：

1、自动化 case 执行不靠人工，可以自动发起执行，

2、自动化成为发布过程中的强流程，

3、第一时间发布自动化测试结果。

根据上述背景和目标，基于持续集成的思想，在兄弟团队的支持和配合下，我们实现了一套完整的自动化测试解决方案，具体如下：

一、beta 发布触发自动化测试执行：

既然人触发自动化不靠谱，我们就通过程序触发。现在的方案是：开发服务 autotest_trigger ，当监听到消息中心 beta 发布的消息后，自动触发自动化 case 的执行。具体步骤如下：

1、准备工作：工程师需要在平台上进行自动触发相关配置，主要是回答这样一个问题：哪些被测工程 beta 发布后，在哪个环境上跑哪些自动化 case ，之后，系统处理流程如下：

2、 autotest_trigger 监听消息中心的消息，当监听到特定的 beta 发布消息后，进行后面的处理，

3、从项目管理平台上获取项目相关信息，包括：工程、分支、项目人员等，

4、根据配置，在自动化环境上部署被测工程，并触发自动化 case 的执行，

5、监听自动化平台相关状态，直到拿到自动化执行的结果，并将结果进行发布。

需要强调的是，第一步的配置工作非常重要，因为并不是所有的 beta 发布都会触发自动化。autotest_trigger 维护了“被测工程——自动化测试工程——自动化测试环境”的对应关系，并提供 web 页面进行配置。程序根据这个配置触发相应的自动化执行。同时，如果有新的被测工程想引入我们的机制，直接在界面上加个配置即可，将接入成本降到最低。配置页面如下：

autotest_trigger 服务提供如下的监控页面，目的是直观展现每次触发自动化测试执行的状态：

二、自动化结果的强流程控制：

在工程效率组支持下，实现了可配置的自动化测试“阻断”机制。如果一个被测工程配置了自动化测试的线上发布“阻断”，并且有自动化 case 失败，在线上发布的时候被强制终止流程，待 case 通过后才能继续发布。需要说明的是，通过“阻断”的条件可以灵活调整，比如“90%的 case 通过”，但建议这个地方配置成100%。另外，针对一些特殊场景提供了“跳过”机制，即高级工程师有权限“跳过阻断”；但跳过不是终点，项目发布后， qa 需要针对本次跳过行为进行 review ，对自动化 case 进行优化和调整。综上，“阻断”机制的加入让自动化成为工程发布中的必要环节，有效提升了自动化的效果，把好上线前的最后一关。具体阻断配置页面如下：

三、自动化结果的展现和推送：

为了让项目相关人员在第一时间就能收到自动化结果的通知，系统目前提供了三种通知的方式：即时通讯工具消息、邮件和项目管理平台展现。在推送通知的时候：通过醒目的文字或颜色标示自动化的结果，让看到的人一目了然；将通知推送给项目的开发、测试和配置管理员，保证所有关注结果的人都能收到消息。具体如下：

即时通讯消息：

邮件通知：

项目管理平台自动化测试结果展现：

四、为了实现上述功能，方案整体架构图如下：

消息中心：当 beta 发布成功后，消息中心会发出消息，供下游服务消费使用

自动化触发服务：监听消息中心的消息，当 beta 发布成功后，调用环境管理平台的接口触发自动化的执行；

环境管理平台：统一维护测试环境的平台，并对外提供接口完成自动化触发、环境信息查询等功能；

质量管理平台：管理自动化触发相关配置；实现“发布阻断”功能；

项目管理平台：提供项目中被测工程、人员等信息；展现自动化测试的结果；

配置管理服务：提供 git 工程相关信息查询接口。

难点和亮点

一、当 beta 发布相对频繁、而自动化 case 数量比较多的情况下，会发生自动化执行排队的情况。为了加快自动化的速度实现了两个功能：首先，基于 Jenkins 的排队机制，如果当前要触发的 build 和等待的 build 行为一致（被测工程、分支、自动化工程等信息），则撤销当前这次触发，等待之前 waiting 的 build 结果即可；在部署自动化环境的时候，使用“不强制部署”模式，当发现要部署的工程版本和当前机器上的版本一致的时候，跳过本次部署，加快整体部署速度。

二、根据用户实际需求，提供两种部署方式“基于 beta 发布”和“基于项目管理平台信息”：在实际应用的过程中，针对部署方式主要收集到两种需求：一些同学反馈：“我的 beta 发布发了哪些工程，就在自动化环境上部署哪些工程”；还有一些同学反馈：“发 beta 后，应该把项目管理平台上所有工程都部署到自动化环境上，这样才能覆盖完整的项目需求”。根据这两种反馈，分别实现了“基于 beta 发布”和“基于项目管理平台信息”两种部署方式，并可通过上面的配置页面进行配置。需要说明的是，“基于项目管理平台信息”方式对于非 beta 发布的工程可能会出现代码未 merge 主干的问题，导致编译失败。

三、一般来说 qa 组内都是多人共用一套自动化测试环境，如何保证在多项目测试的时候环境不被污染？ autotest_trigger 在部署自动化环境前，会获取当前环境的服务集合，并按需“刷一遍环境”，具体做法是：对于本次项目涉及的工程，用项目分支进行部署；对于本次项目不涉及的工程，用当前线上最新版本进行部署。这样既保证了测试环境和线上环境的一致性，又解决了环境污染的问题。当然，当环境中工程比较多的时候，上述方案的时间成本比较高，并加大了部署失败的风险。后续会考虑将这个功能也配置化，用户可以按需配置，在可靠性和效率之间进行平衡。

成果和展望

目前，该方案已经在公司多个事业部推广使用。只要在 autotest_trigger 上配置了的被测工程，可以保证在每一个项目中都会被自动化 case 验证，堵住了以前可能漏测的口子。同时，由于自动化 case 和工程迭代同步，项目中发现的 case 问题都在项目内解决，之前大规模“补 case ”的情况基本看不到了，从一定程度上减轻了大家维护 case 的成本。

综上所述，基于持续集成的思想，针对之前遇到的问题，我们建立起从代码迭代、到自动化测试、到线上发布前验证的完整闭环，让工程师编写的自动化 case 在项目中发挥最大的作用，有效保证服务迭代的质量和效率。未来我们努力的方向包括：针对接口自动化测试，努力让 case 跑的更快、结果报告更加直观友好；除了接口自动化测试，后续还会考虑接入其他形式的自动化测试工具，只要该工具提供了明确的使用场景和调用方式。

在持续提高工程质量和效率的道路上，我们不会停止脚步！