如何实现工具无关化？——关于自动化测试脚本的设计

news2024/11/27 2:21:36

问题的提出

最近几年来，我的自动化测试工具之旅大致是这样的，最早用的是QTP，然后是RFT（IBM的功能测试自动化产品），之后也经历了Selenium，Watir等。再后来还是一些商业工具，主要是偏web自动化及移动自动化，如sahi， appnium， Keynote DeviceAnywhere，SeeTest，HP UFT等，这一系列的变化，让人痛苦的不是学习的过程，也不是各种编程语言的转换，最痛苦的是我们的自动化测试脚本要因为工具的变化而需要重写。因为无法重用，我们或是维护多种自动化工具脚本，或是将自动化测试脚本为最近使用的工具进行重写编写，有太多的时间和经历花在这些事情上。

在这里插入图片描述

我们怎么解决这类问题呢？试想，如果我们能够有这样一个平台，如果提供统一的自动化编程API，而且独立于某种工具，那该有多好。所以本文的目的要设计这样一个平台，能够对自动化测试人员提供统一的编程接口，能够适应测试工具的变化，而无须修改已经基于此平台编程好的自动化测试脚本。

如何实现工具无关化

首先，我们要考虑工具无关化，如果要实现工具无关化，那么对于使用者（自动化测试脚本实现者）一定是使用一致的api，一致的测试元素，一致的数据访问方式。那么我们先要考虑一下测试元素的一致性。

这里我们先假设未来的待测试应用都是web应用或是mobile应用，而mobile应用我们使用的都是hybrid应用。对于测试元素来讲，最重要的是如何能够识别它，我们在识别元素的时候，都会找到一个唯一id或属性来标识它。来看我们上边假设的应用，我们可以使用xpath来做为唯一id来识别元素。你可能根据自已实际场景来设计和定义它。除此之外，为了能够操作元素，我们需要知道它的名字，因此我们还需要为它命名。除此之外，我们还需要使用一个类型字段来区别不同工具之间可能对测试元素有些特别的要求，我们通常使用type字段来标识它。所以我们从逻辑上来看，一个工具无关的测试元素大致看起来是这样的。

对于测试数据来讲，我认为，每个数据都是有一个列和一个值组成，所有数据看起来比较简单。

数据有一点需要注意一下，如果我们要实现数据驱动的自动化测试，我们就需要在此平台提供处理多行数据能力。

有了测试对象和测试数据之后，我们需要了解我们的待测试应用，我们的平台需要对待测试应用使用之前进行一些配置，使用时还要进行一些初始化等工作，使用完我们还会对些进行一些清理销毁等工作。如此一来，我们的平台需要考虑如何进行测试设置工作，因为未来我们平台面对可能各种不同的测试工具，那么在这里我们也需要在些考虑好一致的接口。所以此部分看来如下所示：

对于测试元素的操作，我们通常会使用类似 click，setValue 等一些点击、填值的操作，我们同时还会检查一些测试元素是否在页面中存在，也会检测一个测试元素是否展示在屏幕上。我们可以将些部分统一归结为 action。所以对象的 action 看起来如下所示：

除了 action 之外，我们的平台还要提供 checkpoint 功能，此功能是为了能够让我们脚本有能力判断最近测试结果是通过还是失败。即有一个 checkpoint 失败了，整个测试脚本就是失败状态。Checkpoint 的功能使用起来极其简单，我们需要为其输入两个参数，一个为 expect，一个为 actua，二者进行比较并返回比较结果。这里需要强调的一点是，我们设计 checkpoint 时，要使其能够为其二个参数可以自适应到各种数据类型，因为我们实际应用时，有时会使用两个布尔值进行判断，有时可能会使用两个字符串进行判断，也可能我们可能直接将两个对象传过来进行比较。所以这里我们要让其能够自适应。

讲到这里，我们的平台还需要至少要有的一个功能是 report，我们的 report 要能够展示测试脚本最终是通过了还是失败了。同时能够记录每个步骤的状态，能够截屏。当然，如果 report 能够提供更多的 metric 数据就更好了，方便未来计算 ROI。

到这里我们都是讲的都是对外提供的统一的 API，从使用的角度，这些已经基本够用了。但是对于工具来讲，我们要实现工具无关化，可能会简单一些，但是实际做的时候还是比较麻烦的。因为我们需要针对我们平台支持的每一套测试工具编写接口，使其在外边看起来是一样的。所以平台这边说起来是简单的，但实现工作量还是比较大的，因为每套工具都有其复杂性，再次封装后并提供统一的简单易用接口并非总是那么容易。所以编写接口的人，必须是对其封装的工具是极其熟悉的，并且有丰富的实际应用经验，因为这样才能为使用者写出他们真正所需的接口。