过去的几个月，我们自动化团队通过结果对比发现UI测试覆盖度不够。我们开始考虑做API测试，这篇推文说明了为什么我们要构建API自动化。

UI自动化（也叫测试自动化）

这里的术语“测试自动化” 是不精确的。自动化这个术语不应该用来形容UI自动化，UI自动化只是自动化的一种子类型。UI自动化是自动化测试人员最常做的一种自动化。随着社区逐渐成熟，在自动化上，我们可以有多种选择。自动化也不再等同于UI自动化。

直到今天，UI测试仍然是大多数自动化测试工程师最喜欢做的。一提到软件测试自动化，第一个想到的就是Selenium等。在讲为什么做API级别的自动化之前，我们先看下UI自动化测试的缺点（尽管它被广泛使用）。

开发维护耗时

UI测试模仿的是终端用户。因此，脚本会执行用户在前端做的所有操作。那么就会包含加载屏幕/页面，写/读一些字段/元素，还会有大量的等待时间。即使使用一个可以高度复用的框架，要将这些操作编写成脚本，也需要花费一些时间。执行完成的结果通常是在客户端和服务端之间一系列数据的交换。如果我们只是通过POST将一个数据包从客户端传到服务端，相对而言，只需要几行代码。在单元测试层面来做会更加简单。

维护UI测试也更加笨重。因为UI测试代码经常是API测试代码几倍的量级，维护成本极高。

脆弱性

做几个月的UI自动化测试，你就会发现它极其脆弱。在好的开发实践方式的加持下，UI自动化脚本的鲁棒性会提升到一个合理的程度，但是它仍然非常脆弱。主要表现在UI元素的快速更迭，浏览器版本的升级，不同浏览器返回不同的结果等等。

在黑盒测试的时代，UI自动化是大部分人使用的唯一自动化类型。所以UI测试也没什么可以对比的基准。那时的比较主要是比较两个框架或者工具是否高效。现在与其他类型的自动化在鲁棒性上做比对，UI自动化就垫底了。

执行慢

庞大的UI自动化脚本批处理运行耗时极长。跟手工执行测试相比，它确实是快的，但是与其他类型自动化对比，它是极慢的。与API自动化做一对一的耗时对比，执行一次测试在UI自动化上耗时7分钟，而用API自动化只需要12秒（快35倍）。UI批处理执行需要花费24小时才能全部执行完，而API只需要40分钟。

执行慢的原因是UI自动化测试所固有的，设计如此。举个例子，在填写了2—50个字段后，中间还可能有点延迟，最终结果是调用一个REST API，然后获取返回值。如果我们构造请求并验证返回值，比起填写表格后发请求验证，只需要不到2%的时间。

测试覆盖率低

很多业务逻辑很难从前端复制。一些功能需要指定的详细的环境设置才能触发某行代码的执行。UI自动化对此是无能为力的。很多时候，UI自动化是无法实现的，尤其是涉及到其他硬件时，例如，一个车辆燃料补给设备在补给燃料用完时给web服务器发消息。此时，你可能就会想去通常API或者集成测试来模拟消息。

我们在API级别和单元测试级别上都做了很多对比。UI自动化覆盖率更低。例如，一个500pd（人天）的工作可以覆盖50个UI场景，在API自动化就能覆盖200-250个测试，取决于应用和自动化框架。

最后，在UI级别，你永远达不到100%的测试覆盖。想要达到100%覆盖，你需要做API级别和单元测试级别的测试，保证每行代码都被测试到。

<测试窝原创译文：译者binger>