首页 > Python自动化测试 阅读数:188

Python自动化测试的三层架构

谈到自动化测试,总少不了自动化测试分层,如图 1 所示。在自动化分层思想中,最具有代表性的就是大家熟知的“三层金字塔”结构。

图 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层的自动化测试。