何时覆盖 UI 自动化测试

项目层面

不是所有项目都适合写E2E测试，我们一般从以下几个方面判断一个项目是否适用 UI 测试。

项目的开发、维护周期越长越适合覆盖 UI 测试。因为编写测试会消耗不少时间和精力，如果不是长期维护的项目没有必要进行这些投入。同样的，UI 测试更擅长发现由于代码变更而产生的 bug 而不是首次开发时的 bug，而更长的项目周期往往意味着更多的代码变更，UI 测试所起到的作用也就越大。

如果项目的迭代频率低，版本之间的时间间隔非常长并且有充足的测试时间和人力资源，那么细致的人工测试会更加细致且可靠，这主要是因为自动化测试依赖的断言系统往往只能保证功能可用而不是好用。

但大部分项目的迭代频率较高，而且开发任务重的时候留给测试人员的时间也会被压缩，这时候就需要在每个版本转测之前覆盖一定量的 UI 自动测试，保证交付版本至少可用。

以本书重点讨论的 Web UI 测试为例，测试用例往往需要依靠 css/xpath 选择器作为定位元素的依据。如果界面的 dom 结构、class name/id 等属性经常发生变化，那么维护测试用例的成本就会上升。

与之对应的是如果界面在代码实现层面有良好的模块化/组件化设计，那么测试用例中也有对应的方法最大化复用降低用例维护成本。相关内容我们将在本书的“框架选择标准 - 模块化与复用” 和 “测试用例编写指南 - 合理组织选择器”章节中详细讨论。

一个中/大型项目中往往涉及许多不同类型的业务场景，例如交互复杂的表单输入、静态页面、与后段API交互的动态内容展示等。我们将列举几个 UI 测试擅长的场景以供参考。

一些弱交互甚至无交互的静态的展示类型页面会和项目中的其它代码存在耦合，全局性的代码改动可能导致这类功能受到影响。但为了这种潜在的风险要求每个版本人工浏览、检查所有的静态页面是否有异常的变更则显得枯燥难耐。

这种时候可以在 UI 测试中通过浏览器截图等API将对应页面截图保存，然后与之前版本截图进行自动对比，通过图片是否一致来判断新版本的变更是否破坏了最终展示，亦或者图片的不一致是否和预期相符。

如果项目有一定的浏览器兼容性要求，那么用一套 UI 测试用例覆盖多种浏览器是一种非常高效的手段。不过对此类场景有需求的读者需要注意所选择的测试框架/技术方案是否支持多浏览器执行。相关内容我们将在本书的“框架选择标准 - 浏览器控制方式”章节中进行比较。

以许多产品中都涉及的表单操作为例，如果产品中包含一个4步、共10个必填字段的表单，那么人工填写的成本就比较高了。当类似的交互场景越多、越复杂，就会有更高的人工成本投入其中，而用自动化的 UI 测试进行替换所带来的收益也就越大。

但是需要注意的是和其它所有测试一样，如果你的测试流程有数据写入，那么在测试结束后应该清除写入的数据，保证再次运行时又是一个一致的环境。相关内容我们将在本书的“接入持续集成 - 测试的独立性与重复执行”章节中详细讨论。