本文根据宋家超老师在“2021vivo开发者大会”上的演讲内容整理而成。公众号回复【2021VDC】获取互联网技术分会场相关信息。1.背景1.1项目特点随着互联网技术的快速发展，越来越多的公司将敏捷开发流程引入到项目迭代中，因此越来越多的项目具有三个特点：1）迭代周期短：各种逆向，按schedules，每周一个小版本，两周一个大版本，甚至有的项目天天发布，惨不忍睹。2）需求变更频繁：我们的产品经理不是在推翻自己，就是在推翻自己的路上，所以我们经常和产品经理开玩笑：来来来，你来信，保证永远不改你的要求再上来。这时，产品经理发誓：“好吧好吧，你把这个需求改了，我保证给你写个书面声明，下次再也不改了。”但是没有效果，需求还是变化的很频繁。当然，这不能怪产品经理。面对瞬息万变的市场环境，我们有时需要使用这种试错法来快速找到合适的解决方案。3）系统复杂度高：前端不再是画一个页面那么简单，从目前的前端招聘信息可以看出。分布式、微服务、中间层、各种架构，让本就复杂的业务变得更加复杂。随着项目的这些特点越来越明显，我们的开发和测试面临的挑战也越来越大。1.2问题所以我们遇到了一些问题如下：造成这些问题的原因有两个：测试人员：他们不知道开发代码在哪里变化，影响点在哪里，所以很难用一个精确的测试计划，来改进测试效率，所以为了保险起见，开发者只能测试所有相关功能：无法完全了解每一行代码的执行情况，很难通过执行数据分析出哪些代码有用，哪些代码是没用，哪些代码测试通过了验证，哪些代码没有经过验证，所以我们迫切需要一个可以很方便的看到代码变化和执行状态的平台，这个平台就是集成的代码覆盖率平台。1.3解决方案所谓集成代码覆盖率平台，是指在集成测试过程中收集代码覆盖率并上报给系统进行综合展示的平台。1.4难点既然有解决方案，为什么现在市场上很少有这样的产品？我们在研究这方面的时候，发现了两个非常大的技术难点。第一个难点是：数据合并难。我们都知道，所有的前端测试都是在每一端进行的，测试产生的数据都留在每一端。很难收集和组合留在每个终端中的数据。第二个难点是：数据故障快。前端代码发布非常频繁。测试期间，一天可能发布多次版本。虽然版本是同一个文件，但是里面的内容可能完全不一样，会导致之前收集的覆盖率完全失效。.通过不断的尝试，我们终于解决了这两个问题，于是Marco代码覆盖平台诞生了。2.Marco平台的优势和亮点2.1优势和亮点Marco平台是一个完整的代码覆盖平台，有以下亮点：支持一键接入：无业务、无框架，零侵入已有代码，一键接入；支持增量报告：使用户更准确地了解代码覆盖率；支持多种语言：Marco平台不局限于前端，也服务于后端；支持多种工具：方便用户使用，如代码对比、gitblame等；支持多用户：实时合并查看各种报表；支持市场监测：通过市场实时查看覆盖趋势，了解项目质量趋势；支持消息通知：定时推送项目覆盖率支持独立部署：不仅支持第三方直接接入，还支持一键私有化部署。2.2体验2.2.1详情页下图第一点：当前版本更改了哪些文件，我们会通过树状结构图将所有更改的文件展示在第一区，让用户一目了然当前版本一目了然改变了多少文件下图第二点：当前文件在哪里改变了，我们通过代码对比直观的把每个文件的改变点展示在第二区，方便用户看一目了然文件中的哪些代码行被更改了？下图第三点：当前变更是否经过测试验证。我们刚刚在第二点标记了文件的哪些行发生了变化。那么第三点就是更改更改的代码标记是否已经过验证。有了这三个标志，我们将变化点和测试过程完美结合，让测试结果一目了然。2.2.2趋势图通过项目趋势图，可以清楚地看到项目覆盖率的变化趋势，了解项目质量的变化趋势。2.2.3概况目前，Marco平台已稳定运行近3个月，服务项目39个，生成报表133个。2.3Value通过Marco平台，我们将测试关注的四个点：修改点、影响点、测试点和测试结果紧密联系起来，同时将之前缺乏数据的评价转化为准确客观的依据可量化的评估。三、Marco平台的技术方案Marco平台的技术方案由4个小部分组成：首先介绍Marco平台的整体架构，然后从三个方面进行详细说明：接入层、服务层和展示层。.3.1总体架构图Marco平台分为三层：接入层、服务层和展示层；接入层：我们的目标是一键接入、多语言适配、区分环境、智能上报。目前已经完成了对web端的适配，其他技术栈也在适配中，比如小程序、Node.js、Typescript等。同时我们也规划了其他语言的接入方式，让Marco平台成为所有语言的代码覆盖平台。服务层：主要处理各种报表，如报表管理、用户管理、项目管理等功能。展示层：主要是服务层的扩展，通过可视化的方式提供更方便的报表查看和管理功能。3.2数据流图通过数据流图，我们将一个报表从接入层到服务层再到表现层串联起来，形成一个完美的闭环。3.3接入层接入层主要是接入和上报；对于接入：我们提供各种语言的接入方案、接入规范和接入指导。对于报告：主要有各种语言的采集方案、报告数据标准和报告方案。3.3.1accessinstrumentation维度：通常我们将instrumentation分为语句覆盖、函数覆盖、分支覆盖、行覆盖四个维度。插入过程Marco'sinstrumentation这是Marco平台的部分代码，jsinstrumentation，主要做了三件事；第一步：获取文件的相对路径。为什么是相对路径？因为Marcocodecoverage是一个平台，所以我们需要获取相对路径，这样文件路径关联的是项目而不是打包机。第二步：调用istanbul-lib-instrument进行插桩我们并没有完全重写插桩代码，而是借助开源的力量，让Marco平台更加轻量和通用。第三步：添加自定义参数这些参数非常重要，表示当前报表的重要信息。这样我们就简单的完成了js语言的插桩适配，其他语言也可以参考这个思路。3.3.2上报上报是收集和发送的过程。对于采集：主要获取两条信息，coverage信息和project信息，两者缺一不可。对于发送：每个端会有很大的差异，我们提供一些建议。比如在web中可以监听Visibilitychange事件，在小程序中可以监听onShow和onHide事件。如果在Node等其他服务器中，可以通过定时任务上报。3.4服务层Marco的服务层提供了很多功能，这里我们选择报表管理和用户管理，介绍这两个典型的功能。3.4.1报告管理报告的三要素：首先，一个完整的报告需要具备三个基本要素：覆盖信息、项目信息、文档信息。覆盖信息包括：语句、分支、函数、行四种覆盖。项目信息包括：项目配置、分支信息、文件哈希、构建时间。文件信息包括：文件地址、文件内容、Git信息。通过在接入层采集覆盖信息和项目信息，再关联Git平台的文件信息，可以将Marco打造成一个支持多用户、多报表的覆盖平台。3.4.2在合并过程的前一步中，我们收集了覆盖率。接下来说说Marco平台是如何合并报表的。我们先考虑两种情况：第一种情况：文件没有变化；就是我们下图左边的部分，在文件没有改变的情况下，有两个测试。小梅和小花分别生成了两条举报信息。在这种情况下如何合并它们？第二种情况是：文件发生变化；同一个文件，文件内容发生了变化，变化文件的行号不能一一对应。就变成了第6行，这两行其实是一样的，但是因为删掉了其他行，所以这一行的行号也变了。如何合并这种情况？带着以上两个问题，我们来梳理一下上报合并的流程。比较复杂的是比较报表构建时间。构建时间对比会有三种结果，对应不同的merge过程。3.4.3变更内容的获取主流的git托管平台都提供了API接口来返回Git信息。比如可以通过Gitlab的compare接口获取两个分支的比较信息，通过解析Information返回的信息，我们就可以知道文件的变化内容。3.4.4用户管理为了让Marco平台尽可能简单，我们使用通用的Oauth登录方式进行登录。这样不仅解决了登录问题，也解决了代码权限问题。它确实有多种用途，当然，我们在设计登录的时候，充分考虑了主流的Git平台，比如Gitlab，Github，Gitee等，也就是说，托管在这些平台上的代码都可以连接到Marco代码覆盖平台单击一下。3.5展示层这是Marco平台报表展示的细节，支持实时刷报表和代码对比。通过对比，我们可以看到文件内容的详细变化，以及内容的覆盖范围。3.5.1代码比对Marco平台如何比对代码？我们使用了一个叫做jsdiff的开源库，通过它我们可以比较两个文件之间的差异信息。比较的结果是一个对象数组，是一个对象数组，数组包含4个内容：count：行数；值：具体代码；添加：是否添加；Removed：是否删除。通过解析这个数组，我们可以将比较结果逐一还原到页面中。比如右下角就是我们通过这个数组还原出来的结果。4.总结与规划至此，马可码覆盖平台的技术方案基本讲完了。对于Marco代码覆盖平台，我们接下来有两个比较大的计划。1）一是丰富各种语言的接入：前端包括小程序、Node.js、Typescript；其他语言包括Go、Java等。2）二是开源：我们将把整个Marco平台打包开源，拥抱开源社区，希望和大家一起共建Marco平台。以上是我们对代码覆盖率的一些探索。代码覆盖率可以看作是测试质量的指标，提供了相对合理客观的数据。然而，100%的代码覆盖率并不意味着100%没有错误。代码覆盖率和用例之间没有明确的对应关系。与其一味追求代码覆盖率，不如想办法设计更多更好的用例，使用例和代码覆盖率相辅相成，提高项目质量。作者：vivo官网商城前端团队-宋家超
