2022.1.19 星期三 :

测试知识

测试分类

在软件的测试领域，测试主要分为：单元测试、集成测试和功能测试。
ui测试，e2e

你需要知道的软件测试类型和常识
 常见软件测试分类
功能测试类型;非功能测试类型.
上两篇同。介绍一些测试的名词解释：图形用户界面（GUI）测试，大猩猩测试，集成测试，猴子测试等。

### 开发模式
TDD: 测试驱动开发，英文为Testing Driven Development，强调的是一种开发方式，以测试来驱动整个项目，即先根据接口完成测试编写，然后在完成功能是要不断通过测试，最终目的是通过所有测试
BDD: 行为驱动测试，英文为Behavior Driven Development，强调的是写测试的风格，即测试要写的像自然语言，让项目的各个成员甚至产品都能看懂测试，甚至编写测试

TDD和BDD有各自的使用场景，BDD一般偏向于系统功能和业务逻辑的自动化测试设计；而TDD在快速开发并测试功能模块的过程中则更加高效，以快速完成开发为目的。

两者不是一个层级的东西。 BDD 包含 TDD。

实际测试

根据这些状态，来针对性写用例。
最后，从测试方法来说，有白盒、黑盒、灰盒。

当然，在平日没有必要将彼此划分的很清楚，因为我们学习覆盖率的目的是用来度量测试完整性的手段，只是验证测试效果的一种衡量标准。

还是要根据项目、测试阶段、测试方法不同，来采用不同的测试覆盖率。

前端单元测试

概述

## 单元测试管理工具

单元测试（unit testing），是指对软件中的最小可测试单元进行检查和验证。对于单元测试中单元的含义，一般来说，要根据实际情况去判定其具体含义，如 C 语言中单元指一个函数，Java 里单元指一个类，图形化的软件中可以指一个窗口或一个菜单等。总的来说，单元就是人为规定的最小的被测功能模块。单元测试是在软件开发过程中要进行的最低级别的测试活动，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。

## 单元测试框架

认为前端代码都运行在浏览器里，如何做单元测试？！对于 Javascript 来讲，当然是可以进行单元测试的，并且也通常是针对函数、模块、对象进行测试。前端单元测试框架也有不少，比如 QUnit、Sinon、Mocha 等等，单元测试的执行环境可以是我们日常使用的浏览器 ie、Chrome 等，也可以是无界面浏览器比如 PhantomJS、Headless Chrome。

QUnit

Jasmine

Mocha

## 断言库

断言库提供了用于描述你的具体测试的 API，有了它们你的测试代码便能简单直接，也更为语义化，理想状态下你甚至可以让非开发人员来撰写单元测试。我们使用 sinon-chai

sinon-chai

## 测试浏览器

PhantomJS
Headless Chrome

## 测试覆盖率统计工具

使用Karma 配套的Karma-coverage

## 依赖包 && nyc config

测试框架对比

在软件的测试领域，测试主要分为：单元测试、集成测试和功能测试。

前端的测试框架有很多：mocha, jasmine, ava, testcafe, jest，他们都有各自擅长的领域和特点，而我们采用的jest框架具有如下的一些特点：

适应性：Jest是模块化、可扩展和可配置的；
沙箱和快速：Jest虚拟化了JavaScript的环境，能模拟浏览器，并且并行执行；
快照测试：Jest能够对React 树进行快照或别的序列化数值快速编写测试，提供快速更新的用户体验；
支持异步代码测试：支持promises和async/await；
自动生成静态分析结果：不仅显示测试用例执行结果，也显示语句、分支、函数等覆盖率。

chai：断言库。
Jest ：测试框架。
mocha 语法和Jest一样describe, it，但是需要引入断言库，比如chai，assertassert.equcal(fn(), 0)。 Jest 自带断言except(fn).toBe(0)；代码覆盖率需要其他库支持。

快照测试: enyme和test-react-lib

Tips: 目前React官方推荐使用 React Testing Library + Jest 的方式测试React组件，Enzyme会出现误报的错误即：即使代码损坏，测试也会通过；即使代码正确，测试也会失败。

jest

Jest 是 Facebook 出品的一个测试框架，相对其他测试框架，其一大特点就是就是内置了常用的测试工具，比如自带断言、Mock 功能、测试覆盖率工具，实现了开箱即用。

覆盖率

见前端单元测试-覆盖率和增量覆盖率.md

意义

平台搭建

-->

前端测试基于 Istanbul 优雅地搭建前端 JS 覆盖率平台
 前端精准测试探索：覆盖率实时统计工具
 前端质量提升利器-马可代码覆盖率平台

酷家乐质量保障体系 - 测试需要解决问题/场景，及方案

# 71 前端测试基于 Istanbul 优雅地搭建前端 JS 覆盖率平台
酷家乐质量效能 for 酷家乐质量效能 · 2020年05月12日 · 最后由 zhntester 回复于 2021年08月12日 · 3009 次阅读

简单到复杂的三个场景
### 1 单版本，单次测试的覆盖率统计

插件	概述
ScriptCover	浏览器插件，使用方便，但 Chrome 商店已下架；无需预插桩即可监控 browser 运行 js 代码，拿混淆后的代码毫无办法；开源，但已停止维护；
Istanbul	覆盖率统计插件，可配多种各种 UT 框架和自动化框架使用；编译时预插桩，代码在 UT 或 browser 运行时都可统计覆盖率；开源，旧版已停止维护，新版 (请搜 nyc) 维护的很好； Js 写的，可扩展；
JsCoverage	单测覆盖率统计插件，可配多种各种 UT 框架和自动化框架使用；编译时预插桩，代码在 UT 或 browser 运行时都可统计覆盖率；开源，旧版已停止维护，新版 (请搜 JsCover) 维护的很好； Java 写的，可扩展；和 Istanbul 非常的像；
karma-coverage	Karma 的插件，基于 Istanbul 写的；如果用 Karma 做自动化，使用很方便；较定制化，可模仿但不好直接扩展；

### 2 单版本，多终端多次测试的覆盖率统计
插件 | 概述
– | –
Istanbul-Middleware | 基于 Istanbul 写的中间件；需要前端代码预插桩并调用 middleware 提供的数据上传接口；可统计一个前端工程在多个终端、多种方式测试的总覆盖率；官方，开源，可扩展性强。
Istanbul | 覆盖率统计插件，可配多种各种 UT 框架和自动化框架使用；编译时预插桩，代码在 UT 或 browser 运行时都可统计覆盖率；开源，旧版已停止维护，新版 (请搜 nyc) 维护的很好； Js 写的，可扩展；
JsCover++ | 基于 JsCover 写的服务；和 Istanbul-Middleware 很相似，但更定制化；没开源。

### 3 多版本，多终端多次测试的覆盖率统计
3.1 摸透 Istanbul-Middleware 的使用方法

Git: https://github.com/gotwarlost/istanbul-middleware
根据 Git 中的说明以及对 demo 的研究，想要把 istanbul-middleware 应用到自己的前端工程，可以分为五步：
3.1.1. 部署 middleware
3.1.2. 插桩
3.1.3. 浏览器运行插桩后代码
3.1.4. 前端代码调用 middleware 提供的接口
3.1.5. 查看代码覆盖率报告
middleware 提供了看报告的页面，直接访问即可查看。

3.2. 如何改造

有赞coder - 更具体实现

本文转载自公众号有赞coder（ID：youzan_coder）。

# 72 前端精准测试探索：覆盖率实时统计工具
# 72 前端精准测试探索：覆盖率实时统计工具
# 72 前端精准测试探索：覆盖率实时统计工具
同时前端缺少像 jacoco 这样的集成测试覆盖率统计框架，无法通过集成测试收集覆盖率，对于测试阶段的质量仍然没有数据量化。

### 一、技术选型
首先，覆盖率收集的前提，需要完成代码插桩工作，插桩方法来自于两个开源覆盖率统计框架，istanbul.js 以及 istanbul-middleware (以下称 im)，提供了若干个插桩方法，而 im 其实也是在 istanbul.js 的基础上做了封装, 能力来自于 istanbul-lib-instrument

所有的插桩方法，大致分为两种类型：
运行前插桩
运行时插桩
<!–
运行前插桩：
nyc instrument
针对编译之后的 JS 文件 , 进行手动插桩 , 形成插桩后的新 JS 文件。

babel-plugin-istanbul
istanbul 提供的 babel 插件 , 能够在代码编译打包阶段直接植入插桩代码。适用于使用 babel 的前端工程，基于 react 和 vue 的工程都可以。

1.2 运行时插桩
im.hookLoader：适用于服务端的文件挂载比如 node 应用。
当应用启动时，会在 require 入口处添加 hook 方法，使得应用启动时加载到的都是插桩后的代码。
im.createClientHandler：适用于客户端的 JS 挂载，比如 react 和 vue 的 js。

最后我们所使用的插桩方法：
App（node）—— istanbulMiddleware.hookLoader
Client（react & vue）—— babel-plugin-istanbul

–>

### 二、模块设计
主要分为三个模块，先通过代码插桩获得可追踪的代码，然后实时上报用户行为产生的代码行覆盖记录，最后呈现覆盖率相关信息。
2.1 代码插桩
Client 端：使用 babel-plugin-istanbul 插件，在 babel 编译阶段即可完成。
Node 端：依赖 istanbuljs 提供的能力 - istanbul-lib-hook 、istanbul-lib-instrument

2.2 数据上报
Node 端：应用发布时，写入对应的工程和分支信息，创建定时器，实时上传_global.coverage 变量，即覆盖率信息。

Client 端：客户端的上报比较特殊，客户端不像服务端，在发布后可以全局保持 coverage 变量以及定时器方法，client 端所有的数据生成和消耗都跟随页面的生命周期，所以不太可控，因此需要一个额外容器进行处理，我们选择了通过 chrome 插件来上报，通过全局管理覆盖率信息对象，以及通知下发来实现上报流程。该插件详细的工作流程如下：

#### 覆盖率服务端
两个覆盖率展示接口，新增了 ns、repo、branch 三个入参，用来区别不同的覆盖率
同时增加额外参数 history 传入该变量，标志获取的是历史覆盖率。

2.3 页面展示
全量覆盖率展示：使用istanbulmiddle原生报告生成。
增量覆盖率展示：通过gitlab接口对比master差异，分文件展示各自的覆盖率，同全量覆盖率，只是细化了，整体页面用vue + muse-ui完成。

### 三、工作流程
主要分为3部分：对应上一节说的接入、上报、展示。
通过babel插件完成客户端代码插桩，提供给node端使用的插桩插件，可以一步完成服务端的代码插桩以及定时上报功能。
配合提供的chrome插件，完成客户端的覆盖率上报任务。
覆盖率服务端负责信息的接收和存储，并返回给前端数据信息。
前端负责数据信息展示。

### 四、业务实践
目前在电商教育和行业两条业务线中已有接入,由于该工具限制在qa环境使用 , 仅限收集在qa环境测试的项目数据. 在功能测试阶段，从使用数据上来看 , 增量行代码覆盖率达到80%以上(目前的增量只到文件维度 , 未到行维度), 未覆盖的行主要包括四种: 异常捕获、防御性编码、非本次新增无需关心的代码以冗余代码 , 属于可允许的范围.

\$_PS: 不仅全量，还有增量覆盖率，以及历史覆盖率。页面ui也有，功能都有了。
但是借了chrome插件，不太聪明的亚子/或者业务场景不合适。

马可代码覆盖率平台 - 一个平台需要什么（能力）

# 73 前端质量提升利器-马可代码覆盖率平台

作者：vivo官网商城前端团队-Song Jiachao
本文根据Song Jiachao老师在“ 2021 vivo开发者大会”现场演讲内容整理而成。

二、马可平台的优势及亮点
2.1 优势及亮点
马可平台是一个完备的代码覆盖率平台，具有以下几个亮点：

支持一键接入：不挑业务，框架，对现有代码零侵入，一键即可接入；
支持增量报告：能够让使用者更加精准的了解代码覆盖率情况；
支持多种语言：马可平台不局限于前端，也能服务后端；
支持多种工具：方便用户使用，比如代码对比，gitblame等；
支持多个用户：多种报告的实时合并与查看；
支持大盘监控：通过大盘实时查看覆盖率走势，了解项目质量趋势；
支持消息通知：定时推送项目覆盖率情况；
支持独立部署：不仅支持第三方直接接入，还支持一键私有化部署。
2.2 体验
2.3 价值
通过马可平台我们就将测试关注的四个点即：修改点、影响点、测试点和测试结果，给紧密的联系起来，同时将之前的缺乏数据的评估转化成精确的，有客观依据可量化的评估。

三、马可平台的技术方案
马可平台的技术方案共有4个小部分：首先会介绍马可平台的整体架构，然后分别从接入层、服务层和展示层，三个方面加以详细的说明。