干货 | 携程酒店360度Java质量控制

作者简介

王幸福，携程酒店研发部资深测试开发工程师，负责酒店测试框架和测试工具的研发。技术狂热者，热衷于开源项目，利用创新去提高测试工作的效率。

一、前言

携程目前很多的框架和项目都在往Java技术栈上进行迁移。在这个过程中我们遇到很多的挑战和困难，为此酒店测试在原有的测试体系的基础上做了大量的工作，构建了一整套卓有成效的质量保障体系。所以，在本文的开始部分会给大家介绍下目前酒店测试体系的一些情况，后面则会详细的介绍下这个体系的一部分-Java覆盖率统计平台。

二、何为360度质量保障体系

我们常见的测试流程一般如下图所示，功能测试，自动化测试等这些测试阶段和行为都是围绕着被测系统进行，所以我们可以形象的把它们的关系看作一个360度的环，而被测系统则被围在了环的中央，就像被保镖保护起来的重要人物一般。

那很容易想到的是，这个环上的保镖越多，围得越密，那么被保护的人当然就越安全。可是，保镖也是需要成本的，如果被保护的人不是那么的重要，当然也就用不了这么多的保安。所以，根据被测系统的重要性以及成本的考量，不同的公司对质量保障体系有着不同考量。

常见的测试保障体系

携程酒店测试的质量保障体系在传统的质量体系中增加了一些 “保镖”，不同的是，其中一部分增加的“保镖”是机器人。这样既增加了被测系统的安全性，也适当的降低了成本。无疑携程酒店的360度质量保障体系的核心就是自动化。也只要有这样，无论是持续集成,API测试以及监控预警，利用自动化都达到了质量和效率的双重保障。

携程酒店360度质量保障体系

1. 单元测试

单元测试作为代码级别的质量保障手段，有其不可替代的作用。虽然，携程酒店的敏捷开发中并没有强制进行TDD或BDD这类的实践。但作为自动化测试之外有利的补充，也是要求对于自动化测试或者手工测试无法有效测试的部分，需要编写单元测试用例进行测试。

2. 持续集成

目前酒店测试自动化平台和携程发布系统进行整合，每次应用在发布系统中的发布，自动化测试平台都会进行测试用例的执行，并发送测试报告给测试人员。测试人员收到报告后会对失败的用例进行分析，如果有问题就记入Bug，如果是用例本身的问题，则修改测试用例。目前酒店测试持续集成包含了API，UI以及Job这几种自动化测试，且除了UI自动化之外都实现了无码测试用例的编写，测试人员可以很便捷的编写和维护相应的测试用例

3. 集成测试

在此阶段，测试人员主要进行的是功能测试，为了给测试人员工作提供便利，我们构建了三个平台：

Compass，测试管理平台，测试人员在此平台可以及时了解自己的工作情况，比如本周的任务有哪些？各种自动化测试的执行情况如何等等。

CAS，测试自动化平台，测试人员可以根据需要手动的去触发执行自动化测试用例，并得到详尽的报告。

Click，测试工具平台，测试人员在整个测试周期中肯定会用到各种各样的工具，而在Click中测试人员可以很快捷的找到并使用自己需要的工具。

4. 回归测试

在回归测试中，持续集成依然会继续进行，而且通过在早期对测试用例执行已经进行过分析，此时测试用例的质量已经得到了加强。测试自动化的实施效果应该会更显著。

5. 性能测试

我们提供了两种性能测试方式，场景简单的性能测试，测试人员可以通过性能测试平台自助的完成性能测试，而对于场景复杂的性能测试，测试人员可以在性能测试平台中申请常规性能测试，由专业的性能测试人员完成性能测试。

6. 监控预警

产品上线的时候，大家都是如履薄冰，为了能尽早尽快的发现发布后的问题，及时快速的定位问题，我们开发了监控预警平台，其中包括日志预警，性能预警，机器预警以及报表监控。

三、Java覆盖率统计平台

1. 为什么要做代码覆盖率

前面我们介绍酒店目前的质量保障体系，那么大家可能会注意到，在整个测试周期内会产生大量的测试用例，单元测试用例，API测试用例，UI测试用例，Job测试用例，功能测试用例等等。那么就面临着一个问题：如何量化这些测试用例的质量，如何衡量测试的完整度和有效性。自然而然的，我们想到了覆盖率，覆盖率是度量测试完整性的一个手段，是测试有效性的一个度量，覆盖率有两种评测方法：基于需求的覆盖率和基于代码的覆盖率。

基于需求的覆盖率比较的直观，被测系统一共有多少功能，我们编写的测试用例，测试了多少功能，一目了然，所以平常我们测试最多使用的是基于需求覆盖的方式，但是基于需求覆盖的方式很大程度上依赖于需求文档的完整性，测试人员的设计测试用例的水平，覆盖的完整度差异还是比较大的。

基于代码的覆盖率虽然看起来就不那么直观，你很难一眼就看出来覆盖的代码对应的是什么功能，但是它却比需求覆盖率更为实在，你覆盖了哪些代码，没覆盖哪些代码都是比较清楚的，可以得到一个量化的数据。

需求覆盖率和代码覆盖率是一个相辅相成的关系，在执行测试用例后，可以通过代码覆盖率了解自己还有哪些功能没覆盖，补充测试用例后，代码覆盖率自然也会提高。通过代码覆盖率去完善测试用例是代码覆盖率的重要作用之一。

2. 常见代码覆盖率统计方法

在开发覆盖率统计平台之前，我们也尝试过不同的覆盖率统计的方法，但是都不太能满足我们的需求。

常见代码覆盖率统计方法的不足

3. Java覆盖率统计平台简介

在设计Java覆盖率统计平台之初，我们就设定了以下几个目标：

• 使用简单便捷
• 支持测试各个阶段的代码覆盖率统计
• 与自动化测试进行集成
• 与现有的发布和测试流程进行集成
• 覆盖率统计数据要易于查看

针对设定的这些目标，我们对现有的发布系统，自动化测试平台，Jacoco，Sonar，Gitlab进行了整合。基本的思路就是利用Jacoco的jacocoagent获取到覆盖率统计的exec文件，在服务器上对覆盖率统计文件利用Sonar进行分析，进而我们再通过Sonar的接口获取到具体的覆盖率统计的数据。

Java覆盖率统计平台的网络部署图

Java覆盖率统计平台架构图

4. Java覆盖率统计平台功能介绍

1）统计测试各个阶段的代码覆盖率

从单元测试到系统测试，整个测试生命周期内都可以进行代码覆盖率的统计。

2）代码覆盖率黑白名单设置

在很多情况下，我们可能只需要统计某一部分代码的覆盖率情况。Java覆盖率平台提供了黑白名单设置功能来实现该功能。

3）静态代码扫描

因为平台整合了Sonar，所以也支持代码扫描功能。使用Sonar扫描，可以检查

开发代码中潜在的缺陷和不良的编码习惯。

4）一键统计

覆盖率平台与我们现有的自动化测试平台进行了整合，我们在开启覆盖率统计后，调用自动化测试平台的接口进行测试用例的执行，测试用例执行完毕后进行覆盖率分析，最后得到覆盖率统计报告。

5）覆盖率统计数据查看

覆盖率统计完毕后，可以通过在Sonar中进行代码覆盖率数据的查看。我们也会通过Sonar的Api把覆盖率数据落地到服务器的数据库中。这样我们就可以知道每次覆盖率统计的数据，进而进行覆盖率数据深入的分析。

6）定时任务设置

用户也可以通过设置定时任务，设置某个时刻执行哪些应用的覆盖率统计，在定时任务执行完毕后，用户会得到覆盖率统计数据的报告。

四、尾声

携程酒店的360度质量保障体系依然在演化着，朝着更全面，更智能，更效率的方向在努力。在这个提倡数据化、智能化、国际化的互联网时代，传统的测试实践已经在经受着考验。如何能在这些挑战面前保障软件的质量，如何能利用创新来提高效率和质量，这是摆在所有测试人面前的问题。