试试前端自动化测试！（基础篇）

前言

这篇文章是前端自动化测试系列的开始，自动化测试系列会从理论走向实践，真正带领大家学会使用前端自动化测试框架，并能在业务中落地。

看完整个系列，还不会使用自动化测试工具为生产提效，请来找我！

点赞数过一百，下周更新前端自动化测试与 React 的结合，如何在 React 项目中落地，欢迎大家多多点赞评论收藏！你们的赞赏是我写作最大的动力！

之前发沸点说掘金发文只发精品文，阅读量最少 3k，看看这次行不行。

悄悄说一句，文末有福利！

众所周知的原因，前端作为一种特殊的 GUI 软件，做自动化测试困难重重。在快速迭代，UI 变动大的业务中，自动化测试想要落地更是男上加男 🐶。

近期的学习过程中，翻阅了众多前端自动化测试相关的文章，大多数都在讲如何使用自动化测试框架对前端代码进行测试，很少讲解为什么要引入自动化测试，引入自动化测试有哪些好处，哪些项目适合引入自动化测试，但这些才是真正我们想要知道的。

考虑到各位读者爸爸们可能没有接触过自动化测试的内容，这篇文章就从基本概念和基础用法入手，为大家讲解自动化测试的内容。

开始之前，先进行一下前戏（可能比较长，不喜欢的可以快进 🐶）：

情景还原

小王是国内一家大厂的前端开发。就在述职前一周，产品经理给了一个需求，要求在老项目上加上新的功能。

小王打开老项目代码，定睛一看，心头一紧 —— 要改的组件已经长达 800 多行，快速扫一眼，发现还没有注释。 小王哭了，但产品经理要求 3 天内实现新功能，没办法，只能硬着头皮写了。

小王准备开始写了，对新功能大致做了一下技术分析，发现与老代码的耦合比较厉害，于是就开始一边写，一边阅读和修改老代码。

老代码又臭又长，小王发现有一段代码不知道为什么要对输入文本做处理，觉得是一段没有用的代码，还影响到自己添加新功能，于是小王把这段代码删掉了。

新功能按期完成，小王经过了简单的手工自测，没有问题，于是就发送了提测邮件，等待测试反馈，开开心心准备述职去了。

对新功能的测试也顺利通过，小王将新功能发布上线，结束了这周的工作，回家享受周末了。

小王早早地洗漱完上床睡觉了，突然大半夜老板打电话过来：小王，快起来，出 BUG 了，影响了 1w+ 的用户，快起来看看什么问题！

小王猛地起身，从背包里取出电脑，开始排查 BUG 出现的原因，一顿 debug 之后，发现竟然是自己删掉的那段老代码导致了 BUG！

小王又一次哭了，修复好 BUG，紧急发布上线。

“下周一就述职了，今天出这么个 BUG，年终奖肯定没了，普调估计也悬。还要写 case 报告抄送大部门，丢人丢到家了。”

但是如果公司的老项目引入了自动化测试，后来的故事就完全不一样了：

情景反转

小王准备开始写了，对新功能大致做了一下技术分析，发现与老代码的耦合比较厉害，于是就开始一边写，一边阅读和修改老代码。

老项目的前端开发为了保证项目能够正常运行，编写了单元测试和集成测试的代码，在 README 里要求维护的同事要在添加/修改了代码之后跑一遍测试用例。

老代码又臭又长，小王发现有一段代码不知道为什么要对输入文本做处理，觉得是一段没有用的代码，还影响到自己添加新功能，于是小王把这段代码删掉