前言

基于Jacoco获取增量代码覆盖率的方案社区上已经有很多帖子了，这个帖子就不赘述了，有兴趣的可以在社区搜索或参考我的这个工程-jacoco

方案的实现大体分成两类，一类是基于jacoco的插件通过命令行生成，这种方式对于了解个中原理的童鞋来说比较轻便且排错简单，但是对于不熟悉maven或gradle的童鞋来说还是有一定门槛的，所以就出现另一种方式即将整个方案平台化，通过一些平台的封装提升方案的易用性，但是对于大多数公司来说，可能不允许做过多投入来做平台（特别在社区也有童鞋提出过领导不认可覆盖率报告的情况），因此需要一种相对折中的方案，即无需做过多改造但又可轻便实现整套方案。

Jenkins作为CICD使用最广泛的开源工具/平台，可轻易实现任务的编排，且丰富的插件体系使得它可以方便地集成各种功能，其中集成Jacoco生成覆盖率报告也是功能之一。因此我们考虑改造Jacoco插件以使得它可以支撑获取增量代码覆盖率，结合Jenkins自带的自动任务调度，就可以非常方便地实现增量代码覆盖率方案了。

实现原理

其实增量代码覆盖率的实现是比较简单的，主要就是两个点，一个是获取增量代码，另一个是过滤报告。其中获取增量代码可结合AST语法树实现，过滤报告则只需要对Jacoco的报告生成部分做少量改造即可，细节请参考这个工程-jacoco。因此我们要做的就是把这两个点直接照搬至Jacoco插件的实现即可。

获取增量代码

这一步因为在其他介绍增量代码覆盖率获取方案的帖子中已经重复介绍过很多遍，因此不再重复说明，请在社区搜索相关帖子。

替换默认Analyzer

Jacoco插件的实现是结合Jacoco，因此第一步我们需要做的就是替换默认的Analyzer，使得其在生成报告时能够插入我们自定义的逻辑，即根据变更方法来过滤报告。我们需要增加3个Analyzer，包括Analyzer,ClassAnalyzer,MethodAnalyzer,其中主要代码变更在MethodAnalyzer，代码片段如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

@Override
public void accept(final MethodNode methodNode,
                    final MethodVisitor methodVisitor) {
    filter.filter(methodNode, filterContext, this);
    if (shoudHackMethod(methodNode, JacocoPublisher.methodInfos)){
        methodVisitor.visitCode();
    }
    for (final TryCatchBlockNode n : methodNode.tryCatchBlocks) {
        n.accept(methodVisitor);
    }
    currentNode = methodNode.instructions.getFirst();
    while (currentNode != null) {
        currentNode.accept(methodVisitor);
        currentNode = currentNode.getNext();
    }
    if (shoudHackMethod(methodNode, JacocoPublisher.methodInfos)){
        methodVisitor.visitEnd();
    }
}
private boolean shoudHackMethod(final MethodNode methodNode,
                                    final List<MethodInfo> methodInfos) {
    if(methodInfos.isEmpty()){
        return true;
    }
    for (final MethodInfo methodInfo : methodInfos) {
        final String methodName = methodInfo.getMethodName();
        final String clazzName = methodInfo.getPackages().replace(".", "/")
                + "/" + methodInfo.getClassName();
        if (methodNode.name.equals(methodName)
                && className.equals(clazzName)) {
            return true;
        }
    }
    return false;
}

然后替换默认的Analyzer，入口在包hudson.plugins.jacoco下的ExecutionFileLoader。

1
2
3
4
5
6
7
8
9
10

private IBundleCoverage analyzeStructure() throws IOException {
        
    File classDirectory = new File(classDir.getRemote());
    if (!classDirectory.exists()) {
        return null;
    }
    final CoverageBuilder coverageBuilder = new CoverageBuilder();
    final Analyzer analyzer = new Analyzer(executionDataStore,
            coverageBuilder);
    ...

修改插件前端

由于需要实现代码对比，因此需要一个基线代码信息的输入入口，因此我们需要在插件前端增加相关入口。修改hudson/plugins/jacoco/JacocoPublisher/config.jelly:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

<table width="78%">
<col width="39%"/>
<col width="39%"/>
<tr>
    <td>Path to class directories (e.g.: **/target/classDir, **/classes)</td>
    <td>SshRepo (e.g.: git@127.0.0.1:angrytest/test.git)</td>
    <td>Basic Tag (e.g.: dev_20180917)</td>
</tr>
<tr>
    <td>
    <f:textbox field="classPattern"  default="**/classes"/>
    </td>
    <td>
        <f:textbox field="sshRepoPattern"  default=""/>
    </td>
    <td>
    <f:textbox field="basicTagPattern"  default=""/>
    </td>
</tr>
</table>

修改报告发布机制，修改hudson.plugins.jacoco下的JacocoPublisher:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

// 变更方法
methodInfos = new ArrayList<MethodInfo>();
String baseTag = "";
if (!basicTagPattern.equals("") && !sshRepoPattern.equals("")) {
    baseTag = basicTagPattern;
    String tagPath = filePath + DiffAST.SEPARATOR + baseTag;
    logger.println("开始clone历史版本：" + baseTag);
    try {
        GitClone.cloneFiles(sshRepoPattern, baseTag, tagPath);
    } catch (GitAPIException e) {
        e.printStackTrace();
    }
    logger.println("clone历史版本：" + baseTag + "结束");
    if (methodInfos.isEmpty()) {
        DiffAST.diffBaseDir(filePath.toString(), tagPath);
        logger.println("变更方法数为：" + methodInfos.size());
    }
} else {
    baseTag = "kdbczdtag";
}

使用效果

更新后的插件前端如下图：

以工程-springboot-crud-demo为例，两个tag（20200121_01和20200121_02）之间的变更只涉及一个方法。

在新增入口输入基线代码,执行Job日志中会出现增量代码相关日志：

查看覆盖率报告只显示变更代码部分：

若两个输入框都为空，则显示所有代码报告：

插件安装方式

插件工程地址：https://github.com/AngryTester/jacoco-plugin

打包命令：mvn clean package -Dmaven.test.skip=true

通过Jenkins安装官方Jacoco插件（这一步的主要目的是安装Jacoco插件依赖的其他插件），然后删除Jenkins主目录plugins下的jacoco：

将上面打包后target目录下的jacoco.hpi复制至Jenkins主目录下plugins目录，重启Jenkins即可。

why

自动化测试追求的是无人值守，因此执行过程的监控就是鸡肋，但是在遇到以下场景时情况可能就有所不同：

• 除了实时日志外希望输出更丰富的执行过程内容

• 需要给领导汇报自动化测试工作

其中第二点尤为关键，对于不熟悉自动化测试的领导来说，可视化的执行视图对于领导来说会显得更友好且直观。

难点

对于Chrome和Firefox这类可运行在Linux环境下的前端自动化测试来说，已有前人种树，直接乘凉即可。可直接使用docker-selenium，因此难点主要在于只能运行于Windows环境下的IE浏览器。

方案

整体方案包括Selenium Grid+UltraVNC+noVNC+websockify。操作步骤如下：

• Selenium Grid的环境配置无需赘述。

• 安装UltraVNC。

• 安装NodeJS。

• 安装相关依赖

  1 2 3

  npm install ws npm install optimist npm install @novnc/novnc

• 下载noVNC,解压至node_modules文件夹。

• 下载Wesockify,解压至node_modules\noVNC文件夹。

• 配置UltraVNC，去掉密码要求。进入UltraVNC安装目录找到配置文件，在配置文件中增加配置AuthRequired=0，然后将UltraVNC密码设置为空。

• 修改vnc.html，在body最后增加如下内容：

  1 2 3 4 5 6 7 8

  <script> window.onload=function(){ var timer = setTimeout(() => { clearTimeout(timer) document.getElementById("noVNC_connect_button").click(); }, 500); } </script>

• 运行如下命令:

  1	node C:\Users\Administrator\node_modules\noVNC\websockify-js-master\websockify\websockify.js --web C:\Users\Administrator\node_modules\noVNC 9000 localhost:5900

效果

通过http://服务器IP:9000即可浏览器访问服务器实时页面效果。

1. JaCoCo agent运行数据的4种输出模式

参考JaCoCo官方文档：

The JaCoCo agent collects execution information and dumps it on request or when the JVM exits. There are three different modes for execution data output:


File System: At JVM termination execution data is written to a local file.
TCP Socket Server: External tools can connect to the JVM and retrieve execution data over the socket connection. Optional execution data reset and execution data dump on VM exit is possible.
TCP Socket Client: At startup the JaCoCo agent connects to a given TCP endpoint. Execution data is written to the socket connection on request. Optional execution data reset and execution data dump on VM exit is possible.

一共有三种模式可以输出运行数据，分别是：

• 文件模式：JVM终止时会将运行数据写入一个本地文件。
• TCP Socket Server模式：可以通过外部工具Socket连接到JVM获取实时运行数据。JVM终止时运行数据重置并导出。
• TCP Socket Client模式：启动时agent会连接到提供的一个TCP终端。运行数据会持续往这个socket连接写入。JVM终止时运行数据重置并导出。

2. 各种模式的使用场景

三种模式并无本质区别，可根据实际使用场景选择。

比较常见的是使用TCPServer模式，在JVM启动命令中增加如下配置：

1

-javaagent:/opt/pmo/jacocoagent.jar=includes=*,output=tcpserver,port=2014,address=*

即在JVM启动同时在2014端口启动另外一个TCPServer，然后使用官方的cli工具dump即可将运行数据导出到本地文件。

以上模式在传统部署模式下比较方便，但是在容器化部署环境中，由于TCPServer需要单独占用一个端口，对于一些实用ingress的方案中，只能通过域名方式将端口映射到宿主机上，但是dump工具不支持连接ingress暴露的域名，因此这种方式不适合，因此需要考虑采用其他模式。

文件模式会将文件导出在JVM所在服务器，即处于容器内部，这种显然也不符合实际需求，因此考虑采用TCPClient模式。

3. TCPClient模式配置

3.1 启动TCPServer:

核心代码片段如下：

1
2
3
4
5
6

       // 导出文件绝对路径
private static final String DESTFILE = "jacoco-server.exec";
       // 启动的服务器IP，注意实际使用中修改为IP，不要用localhost
private static final String ADDRESS = "localhost";
       // 启动的服务器端口
private static final int PORT = 6300;

3.2 增加启动配置

1

-javaagent:/opt/pmo/jacocoagent.jar=includes=*,output=tcpclient,port=6300,address=10.25.74.82

在JVM停止时就会自动将运行数据导出到第一步中指定的路径。

Sprint不是小的瀑布模型

将Sprint理解为小瀑布是最常见的误区，例如以前一个版本持续2个月，现在将其划分为4个小版本，每个版本持续2周，但是工作方式还延续之前瀑布模式的做法，遵循严格的需求-开发-测试的流转，可预见的是测试的压力会比之前大瀑布的时期更大。

其他误区

• 敏捷就是快，版本更新很快，甚至每天都有新版本

将版本更新速度视为敏捷开发核心，是完全错误的。不是发现一个bug，就改一个发布一个，而是收集反馈，统一修订后，再发布新版本。这里是指发布，而在开发过程中频繁提测是允许的。

• 敏捷意味着不需要文档

不需要利用率太低，可读性差，格式复杂死板，更新太频繁的文档。需要图形化，模块化，可视化程度高，逻辑详细完整准确，容易传播的文档。敏捷非常推荐活文档，例如遵循BDD原则开发的测试文档。

• 敏捷是快速开发，迭代版本的BUG多一点是正常的

每个交付的产品，必须是集成测试通过的。宁可交付产品数量少，也不能降低质量。

• 采用敏捷方法的开发组/项目不需要制定计划

敏捷项目需要经常制定计划，但是不需要试图超前制定项目计划，通常这也是不可能的。

• 敏捷项目的范围可以随时改变

变更可以等到下一次迭代开始，当前正在进行中的迭代不能变更

精益的历史

来源于1890年代的欧洲的手工艺生产，1910年代的美国福特公司用于工业生产，1950年代的日本丰田公司发扬光大，1990年代美国提出精益管理。

精益开发原则

• 消除浪费

• 构建完整性

• 强化学习

• 尽可能晚做决策

• 尽可能早交付

• 尊重授权团队

• 全盘优化

KANBAN原则

• 可视化工作流

• 限制在制品数量

• 管理工作流

• 保证流程规范清楚明确

• 加强合作

Scrum VS KANBAN

极限编程

XP，我们一般称为极限编程，是最轻量级的开发流程。最主要的精神是：在客户有系统需求时，给予及时满意的可执行程序，所以最适合需求快速变动的项目。

它强调：客户所要的是可工作的执行代码，所以把鱼撰写程序无关的工作降至最低，并要求客户与开发人员最好以side-by-side的方式一起工作。

XP的价值观

• 简单

• 沟通

• 反馈

• 勇气

• 尊重

XP的12个实践

• 计划游戏

• 小版本发布

• 隐喻

• 测试驱动开发

• 重构

• 结对编程

• 代码集体所有

• 持续集成

• 可持续的开发速度

• 客户测试

• 编码规范

XP的角色

• XP教练

• XP客户

• XP程序员

• XP测试员

• XP跟踪员

四场仪式

Scrum中共有四场仪式，分别是计划会,站会,评审会,回顾会。

计划会

计划会的目标是创建冲刺计划（Sprint Backlog），又可以细分为：

• 从Product Backlog中选择要处理的事务

• 选定的用户故事则为Sprint目标

• 将用户故事拆分为Tasks

计划会也是一个时间盒，通常一个月的Sprint计划会时间不宜超过8个小时（即一个工作日）。

在实际实施中，通常会按照以下两个步骤操作：

• 按照Product Backlog中排列的优先级从高到低对条目进行估算，不用全部估算完，估算的条目数够用即可

• 按照团队以往的交付速率，选取按照平均速率团队在一个Sprint中能够完成的条目加入到Sprint Backlog

估算

在我们以往的实施经历中，估算一直是一个难题，由于对故事细节的理解不清晰，估算通常与实际相差很大。但就个人经验来说，估算的目的并不是为了精确估算，而是通过这种形式能够促使开发团队能够尽量去理解故事细节，另外通过开发团队提问，产品负责人澄清的方式，也能够帮助产品负责人下次写出更清晰的用户故事。

估算有以下几个要点：

• 估算不是承诺，不存在事后追责

• 相对估算，即可以选择一个大小适中的用户故事作为1个故事点的参照，其他用户故事可参考进行相对估算。

• 也可使用理想时长作为估算单位，所谓理想时长是指全身心投入的时长（我们经常举的例子是把所有伸懒腰倒茶喝水上厕所的时间全部不计算进去）

对于用户故事特别多的情况，有一种叫做快速排序的方法，具体操作是：

• 将所有用户故事按照估算大小排好，大小差不多的可以放在同一列。

• 按照斐波那契数列直接给所有用户故事赋上故事点数。（1/2,1,2,3,5,8,13…）

个人理解选取斐波那契数列而不选用连续自然数的原因是因为强调是估算，故事越大的时候估算必然是越不准的，所以无需纠结1-2点的误差。

估算故事点的主要意义除了促使开发团队提前理解用户故事和帮助产品负责人写出更好的用户故事，还有另外一个比较重要的意义是估算团队交付速率，团队交付速率可用于：

• 预测项目完成日期

• 计划下个Sprint的交付能力

理想的情况团队交付速率应该前期呈上升趋势，到一定时间开始趋于平稳。

站会

站会也是一个时间盒，通常每日站会时间不超过15分钟，站会的主要目的是开发者之间的信息同步，信息同步的主要价值以个人经历来说，在于识别目前存在的瓶颈，最典型的是一个简单问题可能导致某一个项目成员的进度停滞，而通过信息同步，其他项目成员帮助其快速解决遇到的瓶颈。

团队成员应该将团队目标作为主要目标，可能自己钻研能够帮助到自己的成长，但是在团队目标面前，应该优先考虑团队目标的达成。

站会上通常每个人会回答以下3个问题：

• 上个Daily Scrum到现在，我做了什么

• 到下个Daily Scrum之前我准备做什么

• 我遇到了什么问题

评审会

评审会也是一个时间盒，通常一个月的Sprint评审会时间不超过4个小时。评审会的主要内容是Scrum团队给客户演示增量并接收客户反馈，从而更好为之后的迭代改进提供输入。

评审会体现的是敏捷中的适应性。

回顾会

回顾会也是一个时间盒，通常一个月的Sprint回顾会时间不超过3个小时。回顾会的主要内容是Scrum团队回顾当前迭代过程，分析存在的异常，总结改进措施作为下一个迭代的待办项。

在以往实施经历中，通常会把回顾会的气氛搞得相对轻松些，回顾会不是追责会，需要让大家畅所欲言。

Scrum中的三种角色

• Product Owner-PO，关注于商业价值

• Scrum Master-SM,Scrum专家

• Development Team-DT，技术人员

Scrum团队的特点

• 自组织。自组织确保了充分发挥团队主观能动性。

• 跨职能。跨职能确保了团队拥有充分的技能能够高效完成工作。

敏捷团队没有额外的角色（例如项目经理），没有岗位名称，一切以消除职级差异为主。

Scrum的工作地点

• 相同地点办公（确保渗透式沟通，所以渗透式沟通有点”耳濡目染”的意思，即不经意间接收到信息）

• 面对面沟通

• 可变化的价值

SM的职责

• 对过程负责（不对解决方案负责，也不对人负责）

• 确保Scrum被正确理解及贯彻

• 教练以及问题解决

• 清除障碍

• 保护团队

• 促进各项活动开展

PO的职责

• 对Product Backlog负责（交付价值）

• 创建产品条目

• 对产品条目进行排序

• 澄清需求

DT的职责

• 完成Sprint Backlig

• 自组织

• 估算

• 更新信息发射源，所谓信息发射源是指所有能够提供团队成员能够接收到信息的一切介质，最常见的就是看板。

• 报告

• ETC…

定义

用户故事是由Product Owner编写的，描述对用户有价值功能。

故事三要素

角色:谁

功能：要什么

价值：为什么要

好的用户故事的特征

• Independent，独立性确保了排序的可行性

• Negotiable，可协商体现从用户价值出发，待办列表不等同于合同，根据用户需求的关注点可动态变化

• Valuable，有价值是待办项的基本属性

• Estimate-able，可估算代表团队已经清楚了工作内容和工作量大小

• Small，足够小确保待办列表能够在一个迭代中完成

• Testable，可测试代表团队已经清楚如何对待办项进行验收，即清楚了验收标准

User Stroy & Task

在实际实施过程中，可能会遇到一些并不会对用户直接产生价值，但是又不得不做的事，例如技术预研。这类技术类事务，我们的做法是将其区分于用户故事，以任务的形式存在于待办列表中。但是这种做法可能走入另一个极端，将所有技术类事务全部设置为任务，例如单元测试实施，静态扫描问题修复等等，建议还是应该尽量将所有事项往用户故事上靠，通过设置故事的验收标准来将任务需要达成的目标融入用户故事中。

前言

Backlog,中文通常译作待办列表，在Scrum中，又细分为Product Backlog(产品待办列表)和Sprint Backlog(迭代代办列表)。Sprint Backlog通常作为Product Backlog的子集。

User Stroy

产品待办列表和迭代待办列表中的待办项在Scrum中称呼为User Stroy(用户故事)，用户故事的格式通常如下：

As A…,I want to…,so that…，作为一个角色，我想要功能，以便于商业价值。

用户故事的描述的格式体现了从用户价值出发，从非技术的角度描述了故事最终体现的商业价值。

Product Backlog的基本特征

Product Backlog可以理解为产品想做的所有事。具体表现形式为一组排序的features列表，可能在敏捷实施过程中动态调整（包括调整优先级或者增删修改），且永远不会完成（若Product Backlog为空了则代表产品生命周期已完结）

其中排序作为Product Backlog的重要特征，可以根据价值高低进行调整。Product Owner承担了创建待办项和排序，澄清的职责。

待办列表内容描述应该尽量从非技术性的角度出发，且应该保证Product Backlog中的各个条目的相互独立性。总结来说，Scrum中的Product Backlog中的条目特征可以总结为INVEST:

• Independent，独立性确保了排序的可行性

• Negotiable，可协商体现从用户价值出发，待办列表不等同于合同，根据用户需求的关注点可动态变化

• Valuable，有价值是待办项的基本属性

• Estimate-able，可估算代表团队已经清楚了工作内容和工作量大小

• Small，足够小确保待办列表能够在一个迭代中完成

• Testable，可测试代表团队已经清楚如何对待办项进行验收，即清楚了验收标准

Product Backlog的粒度会根据不同的类型而不同，其中越靠近当前迭代的用户故事粒度会小一些，越远的用户故事可能为Epic(史诗级故事)，在后续再进行细化。

Product Backlog梳理

Product Backlog梳理的主要工作内容包括增加新的条目和细化条目，为持续性活动，不超过10%的开发时间。

Sprint Backlog

Sprint Backlog通常作为Product Backlog的子集。基本特征与Product Backlog基本一致，其他附加特征如下：

• Sprint Backlog由开发团队拥有，Product Backlog由Product Owner拥有。即开发团队可决定 Sprint Backlog的内容，Product Owner可决定Product Backlog的内容。

• 责任分摊，即Sprint Backlog的责任由开发团队公共分摊。

• 团队负责测量Sprint绩效。

使用场景

在自动化测试过程中可能遇到无法通过被测系统自身提供的功能对自动化测试产生的数据进行销毁的情况，通过直接执行DDL销毁数据在数据关系比较复杂的情况下可能带来未知异常，因此可以考虑使用容器作为数据源，通过容器的起停来达成测试数据自动初始化和销毁的目的。

镜像制作流程

• 启动mysql容器并将数据目录映射至宿主机

1

docker run --name mysqldock -e MYSQL_ROOT_PASSWORD=123456 -d -p 3306:3066 -v /data:/var/lib/mysql mysql