2024年最全未来已来，Web前端测试这么做更高效！_为什么后端要前端来测试，那些BAT大厂的软件测试面试官到底在想些什么

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

• **不可靠；**由于测试环境的复杂性，以及过多的依赖项；它们经常会失败，导致误报。在许多情况下，可能都是一些代码问题外的原因。误报过多，召回率低，导致团队越来越不重视，最终也渐渐地不再维护。
• **很难定位/修复；**当 E2E 测试失败时，调试问题或定位问题通常很困难。因为无法直接定位到具体的代码片段问题，仍需要人工复现逐步排查，但又因为其不可靠也许根本无法复现。
• **发现错误的过程较晚；**不像单测可以在开发阶段就能执行，由于运行 E2E 测试的复杂性，大多数情况下这些测试仅在代码提交后在 CI/CD 流程中打包、部署、运行后才能执行，这种反馈延迟对现代敏捷交付团队来说代价高昂。
• **副作用；**因为 E2E 测试应该尽可能在贴近真实生产的环境中执行，其不可避免的会产生众多的副作用，如创建、更新、删除等操作，都会真实的生效和作用在我们的系统中；虽然在 BOE 环境不用过多关心影响，或者通过代理或请求过滤来避免副作用，不可否认的是它会进一步提升系统的复杂性和不可控；

适用场景

当看到仅有的优点和众多缺点时，也许你直接放弃了 E2E 测试的想法，但其存在就必定会有它的意义；

虽然对于公司内众多的中台或管理后台场景确实不适用，但它可以很好的满足组件库、官网、落地页等场景对于功能稳定可用的诉求，它非常适合于前后端交互/依赖少，无副作用产生的前端场景；

比如可以通过一个前端基座来加载组件库并渲染出预置的组件 Demo 样例，基于此进行 E2E 测试对组件进行交互验证其功能；那组件库其实就是唯一的变量和依赖项，我们可以很稳定的模拟用户对于组件的操作；此时不用担心系统依赖过多导致的不可靠和不可维护、难定位等问题，同时它也不会对系统产生任何的副作用，甚至我们都不需要关注登陆/权限的问题，可谓是一劳永逸；

1. 验收测试/Acceptance Testing

验收测试需要确保指定的操作、用户输入和用户行为流是可完成的和正常运行的，并产生了符合预期的行为结果。

如果我们要实现一个计算器，仅仅因为代码中的 addNumbers 函数返回正确的数字，并不意味着计算器界面肯定会按预期运行以给出正确的结果。如果按钮被禁用，或者计算结果没有显示怎么办？验收测试即帮助我们解决这种问题；

说起来它也是夹在单元测试与 E2E 测试中的一种测试方式，到底怎么理解呢？就我个人的理解，验收测试其实就是相当于 QA 同学所进行的工作，通过阅读产品同学的 PRD 文档，拆解成一个又一个的用户故事，并写出测试用例来挨个验证研发交付的功能；

简言之，验收测试即就是产品逻辑的测试，验证一个又一个产品逻辑是否符合预期；比如：当用户登录时调整至 A 页面，如果用户未登录则弹窗提示；点击后跳转和点击后弹窗等功能都可以作为按钮组件单测用例的覆盖范围。但是什么时候跳转，什么时候弹窗则需要一个又一个明确的用户故事来驱动和测试；

1. 视觉回归测试/Visual

Regression Testing

视觉回归测试可以说是前端领域独有的一种测试方式，它不是对编写的代码或功能进行测试，而是将代码的渲染结果与系统在生产、暂存或预更改的本地环境中的渲染版本进行比较。

这种测试通常是通过比较在无头浏览器中截取的屏幕截图来完成的，图像比较工具来检测两个截图之间的些许差异。

与验收测试和单元测试不同，它对于新的特性/内容没有什么测试的收益，因为它需要有一个原始版本截图用于对比。如果你的系统 UI 将在整个开发过程中经常有比较大的变化，你可能就需要将这些视觉回归测试的用例保存下来，以便在回归界面的视觉部分来检测和使用。

如果视觉回归或视觉的一致性是你们系统中的一个痛点，那么与迭代后需要 QA/UED 频繁回归相比，这种方法可能会为团队节省时间和精力。

1. 可访问性测试/Accessibility

Testing

可访问性测试是为了确保每个人都可以访问应用程序，这主要是为了我们的系统能更好的服务有听力或视力障碍的用户，可访问性测试主要涉及检查我们系统/APP 是否与屏幕阅读器等设备兼容。

例如我们公司的 APP 都需要很好的遵守相关规范，以保证为不同人群都能提供良好的体验，那可访问性测试也许就是能保证这个场景稳定可用的方式之一。

1. 性能测试/Performance

Testing

性能测试很好理解，就是为了去验证我们的应用/页面的性能问题，对于客户端来说更为重要，需要去验证在各种机型/设备上的启动速度，视频播放过程中的性能甚至是耗电情况等。

对于 Web 端的性能测试而言会简单很多，参考 Lighthouse 的打分规则，通常关注以下几个常见的核心指标：

1. 跨浏览器兼容性测试/

Cross-Browser

Compatibility Testing

跨浏览器兼容性测试，也是一种前端测试特有的类型。它侧重于使用户能够在不同的浏览器上获得相同的体验，在一个浏览器上可用的功能也应该在其他浏览器上可用。它还应确保应用程序在不同的操作系统、设备和浏览器组合上正常工作。

因为移动端的出现，目前 PC 的 Web 站使用率已大大降低，开发中也基本上不需要开发者为 IE 浏览器而兼容和买单，因此其跨浏览器兼容测试的必要性也大大降低了。

如果是公司内的中后台站点，完全没必要在此浪费过多时间和精力。但是移动端的 M 站或许还需考虑跨浏览器兼容的问题，因为各种机型、系统和宿主环境的不同，可能会影响到我们站点的展示效果。

比如安卓和 IOS 的区别，刘海屏的兼容，系统自带浏览器与微信内置浏览器的区别等，仍是我们需要关注的点。

四. 测试框架/工具推荐

1. Jest 测试框架

简介

Jest is a delightful JavaScript Testing Framework with a focus on simplicity.

It works with projects using: Babel[3], TypeScript[4], Node[5], React[6], Angular[7], Vue[8] and more!

Jest[9] is a JavaScript test runner that lets you access the DOM via [jsdom]( ). While jsdom is only an approximation of how the browser works, it is often good enough for testing React components. Jest provides a great iteration speed combined with powerful features like mocking modules[10] and timers[11] so you can have more control over how the code executes.

https://jestjs.io/

React 官方推荐的测试框架之一，很多公司的前端开发框架也都已经集成了其单测能力。使用教程实在是太多了，大家感兴趣可以去搜搜并在项目中尝试去启用它。

https://reactjs.org/docs/testing.html

适用场景

Jest 框架的功能非常齐全，基本上能覆盖大多数的前端测试场景，最常用的包括以下几个场景：

A. 函数单元测试

通常用来覆盖我们项目中的 Util 方法/函数，以保证函数代码健壮性；因为 Util 也通常都是纯函数，对于单元测试非常友好。

import sum from './sum';

it('sums numbers', () => {
  expect(sum(1, 2)).toEqual(3);
  expect(sum(2, 2)).toEqual(4);
});

B. React 组件测试

官方建议使用 Create React App[12]，它已经内置包含了 可用的 Jest[13]，我们只需要添加 react-test-renderer 来渲染快照即可。

组件测试技术的范围很广，它们的范围从验证组件渲染而不抛错的冒烟测试到浅层渲染和测试一些输出，再到完整渲染和测试组件生命周期和状态变化，因此如果要完整的对一个组件进行测试可能非常复杂。

一个简单的组件渲染冒烟测试，测试挂载一个组件，并确保它在渲染过程中没有抛出异常；

import React from 'react';
import ReactDOM from 'react-dom';
import App from './App';

it('renders without crashing', () => {
  const div = document.createElement('div');
  ReactDOM.render(<App />, div);
});

浅层渲染测试

// 组件代码
function MyComponent() {
  return (
    <div>
      <span className="heading">Title</span>
      <Subcomponent foo="bar" />
    </div>
  );
}

// 测试代码
import ShallowRenderer from 'react-test-renderer/shallow';

const renderer = new ShallowRenderer();
renderer.render(<MyComponent />);
const result = renderer.getRenderOutput();

expect(result.type).toBe('div');
expect(result.props.children).toEqual([
  <span className="heading">Title</span>,
  <Subcomponent foo="bar" />
]);

C. 快照测试

快照测试即就是渲染 UI 组件之后，保存一个快照文件，之后每次修改都检测它是否与保存的快照文件相匹配。若两个快照不匹配，测试将失败：有可能做了意外的更改，或者 UI 组件已经更新到了新版本，需要我们及时更新已保存的快照。

import renderer from 'react-test-renderer';
import Link from '../Link';

it('renders correctly', () => {
  const tree = renderer
    .create(<Link page="http://www.facebook.com">Facebook</Link>)
    .toJSON();
  expect(tree).toMatchSnapshot();
});

首次执行后它会在指定目录生成一个快照文件，我们应该把它加入到代码仓库中一起提交并 Review，确保后续的更新都有一个稳定的快照用于比对。

exports[`renders correctly 1`] = `
<a
  className="normal"
  href="http://www.facebook.com"
  onMouseEnter={[Function]}
  onMouseLeave={[Function]}
>
  Facebook
</a>
`;

1. 自动化测试套件

简介

是公司内部存在一个基于 Puppeteer 实现的产品 U，它是一个面向 Web 自动化测试的平台，适用于 Web E2E 测试场景，支持用例编写、实时预览、接入流程，提供详细的测试报告。目前并没有对外开放，但是大家可以使用原生的 Puppeteer 实现。

A. E2E 测试

可以在线的实现用例编写、调试、执行和发布的能力，非常方便。

B. 兼容性测试

可以通过引入一些通用的开源库进行浏览器的兼容测试：比如是否有未编译的 ES6+ ， 是否存在未处理的 css 属性，甚至可以模拟低版本的浏览器。

C. 视觉回归测试

可以通过浏览器将页面进行截图，从而进行图片 Diff 比对实现对于 Web 站的视觉回归分析；

图片	图片	图片

D. 性能测试

可以在无头浏览器中接入了 Web 性能测试中常用的工具 —— Lighthouse；我们可以通过暴露的 zAP I 很方便的进行性能相关指标的检测。

五. 对于前端测试的一些建议

1. 从业务场景出发，

无需照搬流程与模式

网上有无数的前端测试最佳实践，但我们没必要去照搬照学，因为它不见得是我们项目的最佳实践。

如何构建最适合我们项目的前端测试计划，或许你需要先思考这几个问题：

A. 决定前端测试的预算和投入

要实现前端测试，无疑要投入更多的研发人力和成本在其中，因为要支持单测导致研发工期翻倍是再正常不过的事情。因此到底能在项目中分出多少人力用于前端测试，是我们首先要考虑的问题。

如果项目处于初期，需要快速的功能迭代和打磨，研发人力已经非常紧缺了，这时投入去做前端测试显然是不合时宜的。如果项目比较稳定，且需要长期稳定的人力投入在回归和测试过程，那在前端测试投入精力会是个好选择；

B. 决定前端测试的覆盖范围

从前端测试相关类型介绍就可以知道，前端测试领域非常宽广，各式各样的场景都可以用自动化测试来覆盖，通常我们应该从项目的功能场景出发去思考。

如果项目是插件、工具函数、工具包，那么就适合单元测试；

如果项目是组件库，可以考虑结合单元测试和 E2E 测试去覆盖；

如果是承载大流量的官网、落地页，那么就非常适合 E2E 测试、视觉回归测试、可访问性测试、性能测试、兼容性测试等；

如果项目是中后台的管理系统，首先希望你已经思考了前一个问题，其次这个场景可能更适合单元测试和验收测试等；

1. 先行动起来，

不急着追求覆盖率

通常在测试计划制定时，都会拍脑袋说一个指标，比如要求代码覆盖度达到 80%以上。但对于大多数的 Web 前端测试的场景，追求一个非常高的覆盖度没有太多意义，因为我们大多数代码都是渲染逻辑和样式。

如果一定要求 80%，开发者无疑会认为这是浪费时间。到底多少合适，没有正确的答案，只能视情况而定。

所以归根到底，我们对前端代码中错误的风险的容忍度如何？如果某些非核心功能，修改问题所需的时间与编写额外测试的成本相比，到底哪个成本更高？

因此我的建议是没必要追求一个固定的覆盖率，我们可以选择核心的模块和功能来先进行测试的覆盖，又或者是逻辑分支较多比较复杂的逻辑，我们可以用单元测试驱动我们去开发。

总之在必要的时候先行动起来吧，我们可以暂时弱化目标；

1. 以有测试为荣，

但不以无测试为耻

我们应该重视前端测试，但没必要神话前端测试；

如果有充分的前端测试辅助，可以避免掉很多的人为错误和疏忽导致的线上事故，对于新人也能给予足够的保护和支持。我们应该鼓励和支持前端测试的建设，并以此为荣。

但如同上面预算和投入中讨论的，如果我们的项目仍处于频繁变更的时期，那我们应该花更多的时间去做产品业务的打磨，技术方案的讨论、代码规范与 CR 流程的建立、团队技术能力的培养，而不是投入大量成本在前端测试中。

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

打磨，技术方案的讨论、代码规范与 CR 流程的建立、团队技术能力的培养，而不是投入大量成本在前端测试中。

[外链图片转存中…(img-aflMKCda-1714984254358)]
[外链图片转存中…(img-Hq5Mbi3w-1714984254358)]

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！