2.5 提倡分层自动化测试

谈到自动化测试，总少不了自动化测试分层，如图2-1所示。在自动化分层思想中，最具有代表性的就是大家熟知的“三层金字塔”结构。虽然现在随着微服务架构的流行，传统的三层金字塔结构在很多业务场景下演变成了五层金字塔结构，但无论是几层结构，强调的是自动化分层“重要先行”的思想，以及测试活动应该要贯穿于产品研发过程的全生命周期，而不只是一个孤立的环节。

传统的自动化测试更关注UI层的自动化测试，而分层的自动化测试倡导产品的不同阶段（层次）都需要自动化测试，下面以测试三层金字塔为例详述。

1．UI测试

这是大部分同学理解的自动化测试，UI指的就是用户可以用肉眼看到的界面。不论是Web端、PC端还是移动端，原理都是一样的：即基于页面元素的识别和定位来模拟用户行为。

对于UI层自动化测试的开展，一般并不建议做大规模的应用，主要是由于以下几个原因导致的：

UI界面变化频繁，计划根本赶不上变化。

初期见效太慢，基本上大家都希望用了自动化测试技术就能立马看到效果，但事实总是相反的，自动化测试的效果是在后期体现的。

前端的开发不规范，导致很多元素识别和定位较为困难。

UI层自动化测试是不是就不用了？答案是否定的！保持一个客观、公正的态度是非常重要的，至少从大部分公司的实践经验来讲，UI层自动化测试可以应用到主流程的冒烟测试中。比如电商系统，可以应用到主流程上做每日的UI层自动化回归测试，用来保证线上系统功能的正常。所以用与不用关键在于它的适用范围，只有在合适的范围内使用了合适的技术才会表现出最好的效果。

2．集成/接口测试

集成/接口测试是现在在企业中应用最广泛的自动化测试之一，它的优点在于规避了UI层自动化测试的缺点，一旦形成较为稳定、完整的框架后基本上是比较通用的，并且接口测试关注的重点更多在于数据（数据处理、数据状态、数据传递），不论是在Web端还是移动端都可以使用。缺点也很明显，就是对测试工程师的编码能力要求较高，一般接口自动化测试都会用Python、Java等语言开发，这也是让很多测试工程师止步的重要原因。

3．单元测试

单元自动化测试对测试工程师的编码能力要求较高，要求测试工程师能看懂业务的实现代码，这样才能针对被测代码编写单元测试代码。单元测试关注的重点更多在于代码的实现与内部逻辑关系。对于不同产品的开发技术栈，都会有对应的单元测试框架，如Java有JUnit、testNG，C#有NUnit，Python有UnitTest、Pytest等。

可以看出，在分层自动化测试中，不同层面的自动化校验关注的重点是不一样的：

单元测试的关注重点在于代码的内部实现逻辑是否正确，例如一个if分支或一个for循环的实现。

中间层的集成、接口测试更加关注的是一个函数、类（方法）所提供的接口数据是否正确。

最上层的UI层自动化测试更贴近真实用户，关注的重点则是用户的操作行为是否正确。

有些人会想，为什么用正三角形来表示金字塔？为什么不可以是长方形或倒三角形？正三角形体现了分层自动化测试倡导各层投入的比例关系。如果一个产品从没有做单元测试与接口测试，只做UI层的自动化测试是不科学的，也很难从本质上保证产品的质量。如果妄图实现全面的UI层的自动化测试，更是一个劳民伤财的举动，投入了大量人力和时间，最终获得的收益可能会远远低于所支付的成本。因为越往上层，其维护成本越高，尤其是UI层的元素会时常发生改变。所以，我们应该把更多的自动化测试放在单元测试与接口测试阶段进行。

既然UI层的自动化测试这么劳民伤财，那么我们只做单元测试与接口测试好了。也不行，因为不管什么样的产品，最终呈现给用户的是UI层。所以，测试人员应该把更多的精力放在UI层。也正是因为测试人员在UI层投入了大量的精力，所以我们有必要通过自动化的方式“部分解放”重复的劳动。

这也正好回应了自动化测试分层强调的是自动化分层“重要先行”的权重思想，以及测试活动应该要贯穿产品研发过程全生命周期，而不仅仅只是针对某一环节。

知识补充

在金字塔中三种测试的比例要根据实际的项目需求来确定。在《Google测试之道》一书中，对于Google的产品，70%为单元测试，20%为集成、接口测试，10%为UI层的自动化测试。