从入门到不放弃：多浏览器的自动化测试（1）- 本地测试

本文将作为多浏览器自动化测试的第一篇文章，给读者从头介绍如何进行本地多浏览的自动化测试工作，包括测试的原理、测试框架的选取、测试工程的搭建和实现等。另外“从入门到不放弃”系列将给读者们带来更多从零开始的前端实践案例，诸如前端组件库设计与实施、项目自动化构建等案例，欢迎大家关注本系列的其他文章。

前端之殇

要是你碰到前端工程师朋友，那聊聊浏览器的兼容性准是没错，这和碰到英国朋友就谈天气是一个道理。大部分程序员朋友们一定会捶胸顿足，连连诉苦，不过如果对方一时语塞，或者欲言又止，请拍拍他 / 她肩膀说：

“没事，过两年出了新浏览器又是一条好汉。”

在前端界，浏览器兼容性是让工程师们头疼的问题，对于经验丰富的人来说，很清楚浏览器有哪些坑，但是对于大部分程序员，最可怕的是代码明明在这个浏览器运行得很好，但是到了另一个浏览器中就不能正常运行了。对于这部分的程序员，保障代码能正常运行的方法便是能尽早发现问题，然后将其解决。

通常情况下，发现兼容性问题的方法莫过于将程序在各个浏览器中执行一遍，但这是极其浪费人力和时间的，最省力的方法也需要在每次版本的更迭时重复一遍测试工作。对于不同的兼容性要求，测试需要的时间各不相同，若是只支持最新版本的浏览器，那么便测试 3、4 个浏览器即可，但是对于兼容性要求高的程序，有可能要测试 10 个浏览器以上。

对于中小型公司来说，如果没有专职的测试人员，这样的测试耗时是致命的。若进行严格测试，则会拖慢项目进度，倘若敷衍了事，那程序的质量便没法保证。

本文将作为多浏览器自动化测试的第一篇文章，将以项目 A 作为例子，给读者从头介绍如何进行本地多浏览的自动化测试工作，包括测试的原理、测试框架的选取、测试工程的搭建和实现等。在下一篇文章中将介绍如何使用云服务实现更多浏览器的测试工作。另外“从入门到不放弃”系列将给读者们带来更多从零开始的前端实践案例，诸如前端组件库设计与实施、项目自动化构建等案例，欢迎大家关注本系列的其他文章。

小窥测试

测试是一个庞大的主题，包括各种分类的测试，诸如黑盒测试/白盒测试、单元测试 / 集成测试 / 端到端测试等。通常程序员在测试自己的代码的时候用得最多的便是单元测试，但是因为测试也是需要代价，很多人是不喜欢写测试的，甚至是一点都不写。当然今天我们不是要讨伐诸位，而是希望读者能从文中受益，从一个测试小白可以自己动手搭建自己的测试工程。

在多浏览器的自动化测试，我们多半是进行端到端的测试工作，一小部分是大粒度的单元测试。端到端测试测试模拟用户的行为。在 Web 应用程序中，他们会启动服务器，打开浏览器，模拟用户的行为进行点击、输入、提交等动作，断言浏览器中发生了特定的事情或者是得到了期待的结果，从而让我们相信功能可以正常的运行。而单元测试根据代码单元的公共 API 运行它们。这些测试需要创建一个类的实例，使用特定的输入调用它的方法，断言被调用的方法达到了预期的效果。

在下文中我们会看到这两种测试的实践，当然有时候区分度并不大，可能无法明显地区分哪些是端对端测试哪些是单元测试，有时候他们是混合起来的，不过只要记住我们的目标是保证功能可以正常运行就足够了。

在浏览器的测试中，Selenium 可谓是最重要的工具之一。简单来说 Selenium的作用是 "Automate Browsers"——让浏览器可以自动化起来的工具。它提供了统一的接口，让用户可以使用不同的编程语言，调用其接口来模拟用户的操作，例如点击，移动等操作。基本上一切人工操作的行为都可以通过 Selenium 的 API 进行触发操作。我们将 Selenium 看作是人手的代理，帮程序员完成一切用手干的活。