Linuxeden开源社区作者
前言
携程目前很多的框架和项目都在往 Java 技术栈上进行迁移。在这个过程中我们遇到很多的挑战和困难，为此我们在原有测试体系的基础上做了大量的工作，构建了一整套卓有成效的质量保障体系。本文的开始部分会给大家介绍下目前酒店测试体系的一些情况，后面则会详细地介绍下这个体系的一部分——Java 覆盖率统计平台。
360 度质量保障体系
常见的测试体系
我们常见的测试体系一般如下图所示:
功能测试、自动化测试等这些测试阶段和行为都是围绕着被测系统进行的，所以我们可以形象地把它们的关系看作一个 360 度的环，而被测系统则被围在了环的中央，就像被保镖保护起来的重要人物一般。
那很容易想到的是，这个环上的保镖越多，围得越密，被保护的人当然就越安全。当然，保镖也是需要成本的，如果被保护的人不是那么重要，当然也就用不了那么多的保安。所以，根据被测系统的重要性以及成本的考虑，不同的公司对质量保障体系有着不同考量。
携程酒店 360 度质量保障体系
携程酒店的 360 度质量保障体系的核心就是 自动化，该体系在传统的质量体系中增加了一些“保镖”，特别的是，其中一部分“保镖”是机器人。这么做既增加了被测系统的安全性，也适当地降低了成本。同时，利用自动化，持续集成、API 测试与监控预警的质量和效率都得到了更好的保障。
单元测试
单元测试作为代码级别的质量保障手段，有其不可替代的作用。虽然，携程酒店的敏捷开发中并没有强制进行 TDD 或 BDD 这类的实践。但作为自动化测试之外有利的补充，也是要求对于自动化测试或者手工测试无法有效测试的部分，编写单元测试用例进行测试。
持续集成
目前酒店测试自动化平台和携程发布系统进行整合，每次应用在发布系统中发布，自动化测试平台都会进行测试用例的执行，并发送测试报告给测试人员。
测试人员收到报告后会对失败的用例进行分析，如果有问题就记入 Bug，如果是用例本身的问题，则修改测试用例。
目前酒店测试持续集成包含了 API、UI 以及 Job 这几种自动化测试，且除了 UI 自动化之外都实现了无码测试用例的编写，测试人员可以很便捷地编写和维护相应的测试用例
集成测试
在此阶段，测试人员主要进行的是功能测试，为了给测试人员工作提供便利，我们构建了三个平台：
- Compass，测试管理平台，测试人员在此平台可以及时了解自己的工作情况，比如本周的任务有哪些？各种自动化测试的执行情况如何等等。
- CAS，测试自动化平台，测试人员可以根据需要手动地去触发执行自动化测试用例，并得到详尽的报告。
- Click，测试工具平台，测试人员在整个测试周期中肯定会用到各种各样的工具，而在 Click 中测试人员可以很快捷地找到并使用自己需要的工具。
回归测试
在回归测试中，持续集成依然会继续进行，而且通过在早期对测试用例执行已经进行的分析，此时测试用例的质量已经得到了加强。测试自动化的实施效果应该会更显著。
性能测试
我们提供了两种性能测试方式，场景简单的性能测试，测试人员可以通过性能测试平台自助的完成性能测试；而对于场景复杂的性能测试，测试人员可以在性能测试平台中申请常规性能测试，由专业的性能测试人员完成性能测试。
监控预警
产品上线的时候，大家都是如履薄冰，为了能尽早尽快地发现发布后的问题，及时快速地定位问题，我们开发了监控预警平台，其中包括日志预警，性能预警，机器预警以及报表监控。
Java 覆盖率统计平台
为什么要做代码覆盖率
前面我们介绍酒店目前的质量保障体系，那么大家可能会注意到，在整个测试周期内会产生大量的测试用例，单元测试用例、API 测试用例、UI 测试用例、Job 测试用例、功能测试用例等等。
那么就面临着一个问题：如何量化这些测试用例的质量，如何衡量测试的完整度和有效性？
自然而然地，我们想到了 覆盖率，覆盖率表示的是测试需求和测试用例的执行进度，是度量测试完整性的一个手段，是测试有效性的一个度量，覆盖率有两种评测方法：基于需求 的覆盖率和 基于代码 的覆盖率。
基于需求的覆盖率
基于需求的覆盖率比较的直观，被测系统一共有多少功能，我们编写的测试用例，测试了多少功能，一目了然，所以平常我们测试最多使用的是基于需求覆盖的方式，但是基于需求覆盖的方式很大程度上依赖于需求文档的完整性，测试人员的设计测试用例的水平，覆盖的完整度差异还是比较大的。
基于代码的覆盖率
基于需求的覆盖率是一种黑盒测试的手段，适用于功能测试，但对于白盒测试 (比如单元测试)，或者你需要知道你的测试到底覆盖了多少的代码、多少的分支，那么它就不适用了。
这时，我们就需要使用基于代码的覆盖率，通过基于代码的覆盖率统计，你可以很清楚地了解你到底覆盖了哪些代码，没覆盖哪些代码，从而可以得到一个具体的量化指标。
同时，在执行测试用例后，可以通过代码覆盖率了解自己还有哪些功能没覆盖，补充测试用例后，代码覆盖率自然也会提高。通过代码覆盖率去完善测试用例是代码覆盖率的重要作用之一。
常见代码覆盖率统计方法
在开发覆盖率统计平台之前，我们也尝试过不同的覆盖率统计的方法，但是都不太能满足我们的需求。
IDE 中集成的覆盖率统计工具
- 需要代码权限
- 覆盖率统计结果都在本地，无法很好地管理和交流
Ant、Maven 等 Java 构建工具
- 需要代码权限，且需要修改代码配置文件
- 本地编译，运行配置复杂，需要技术门槛
- 覆盖率统计结果在本地，无法很好地管理和交流
Jenkins 等持续集成工具
- 需要引入持续集成机制
- 无法有效地进行系统测试的覆盖率统计
- 无法对覆盖率统计数据进行聚合统计
Java 覆盖率统计平台
在设计 Java 覆盖率统计平台之初，我们就设定了以下几个目标：
- 使用简单便捷
- 支持测试各个阶段的代码覆盖率统计
- 与自动化测试进行集成
- 与现有的发布和测试流程进行集成
- 覆盖率统计数据要易于查看
针对设定的这些目标，我们对现有的发布系统、自动化测试平台、Jacoco、Sonar、Gitlab 进行了整合。
Java 覆盖率统计平台的网络部署图如下：
Java 覆盖率统计平台架构图如下：
Java 覆盖率统计平台分为两部分：部署在应用服务器上的 覆盖率统计服务 和 Java 覆盖率统计站点。
覆盖率统计服务
覆盖率统计服务是 Python 编写的 WSGI 服务，为什么需要这个服务呢？主要是因为 Java 覆盖率统计平台通过 Jacoco 的 Agent 技术监控并收集应用程序的覆盖率数据。
JacocoAgent 有两种 dump 覆盖率数据的方式，tcpclient 和 file，Java 覆盖率统计平台采用的是 file 方式，这种方式需要关闭应用程序的进程后才会 Dump 数据到本地。基于这些需求，覆盖率统计服务主要实现了以下几个功能：
- 开启 / 关闭 Tomcat(携程 Java 应用一般是 Linux+Tomcat 这样部署配置)
- 修改 Tomcat 的 JAVA_OPTS 的配置
- 提供 Jacoco.exec 文件的下载接口
Java 覆盖率统计平台站点
CDPortal 是携程内部研发的持续集成和发布系统，覆盖率统计平台可以通过用户设置的 Appid 和环境，调用 CDPortal 的接口获取应用部署机器的信息以及发布的版本信息。
当用户开启应用的覆盖率统计后，覆盖率统计平台会发送命令给覆盖率统计服务配置 JAVA_OPTS，启动 Tomcat 以开始 Jacoco 的数据收集。
用户开启 Jacoco 数据收集后，可以进行自己需要执行的测试，比如 API 测试、UI 自动化、手工测试等等。
当测试完成后，用户在覆盖率统计平台关闭应用的覆盖率统计，覆盖率统计平台会发送命令给覆盖率统计服务重启 Tomcat，Jacoco 就会把收集到的数据 dump 到服务器本地。
然后覆盖率统计平台通过覆覆盖率统计服务的 Jacoco 文件下载接口把 jacoco 文件下载到覆盖率统计平台。当 jacoco 文件下载完毕后，覆盖率统计平台会从 Gitlab 中拉取应用代码并进行编译。
编译完成后，使用 SonarQube 对下载的 jacoco 文件进行分析。SonarQube 分析完毕后，覆盖率统计平台会通过 SonarQube 的 Web 接口获取覆盖率统计信息并保存到平台的数据库中。
最后，用户在平台中可以查看覆盖率统计的报告 (最新的覆盖率信息、与上次覆盖率的对比、覆盖率趋势图等等)。
Java 覆盖率统计平台功能
统计测试各个阶段的代码覆盖率
从单元测试到系统测试，整个测试生命周期内都可以进行代码覆盖率的统计。
代码覆盖率黑白名单设置
在很多情况下，我们可能只需要统计某一部分代码的覆盖率情况。Java 覆盖率平台提供了黑白名单设置功能来实现该功能。
静态代码扫描
因为平台整合了 Sonar，所以也支持代码扫描功能。使用 Sonar 扫描，可以检查开发代码中潜在的缺陷和不良的编码习惯。
一键统计
覆盖率平台与我们现有的自动化测试平台进行了整合，我们在开启覆盖率统计后，调用自动化测试平台的接口进行测试用例的执行，测试用例执行完毕后进行覆盖率分析，最后得到覆盖率统计报告。
覆盖率统计数据查看
覆盖率统计完毕后，可以通过在 Sonar 中进行代码覆盖率数据的查看。我们也会通过 Sonar 的 Api 把覆盖率数据落地到服务器的数据库中。这样我们就可以知道每次覆盖率统计的数据，进而进行覆盖率数据深入的分析。
定时任务设置
用户也可以通过设置定时任务，设置某个时刻执行哪些应用的覆盖率统计，在定时任务执行完毕后，用户会得到覆盖率统计数据的报告。
结束语
携程酒店的 360 度质量保障体系依然在演化着，朝着更全面，更智能，更效率的方向在努力。在这个提倡数据化、智能化、国际化的互联网时代，传统的测试实践已经在经受着考验。如何能在这些挑战面前保障软件的质量，如何能利用创新来提高效率和质量，这是摆在所有测试人面前的问题。
作者介绍
王幸福，携程酒店研发部资深测试开发工程师，负责酒店测试框架和测试工具的研发。技术狂热者，热衷于开源项目，利用创新去提高测试工作的效率。本文来自王幸福“携程技术沙龙——移动互联背景下的测试技术创新”上的分享。
转自 http://www.infoq.com/cn/articles/ctrip-hotel-automation-360-degree-quality-guarantee-system