测验数据预备办法以及未来的开展方向

发表于:2019-05-16来历:TesterHome作者:刘春明点击数: 标签:
测验数据的预备,是软件测验作业中十分重要的环节,无论是手艺测验仍是自动化测验都避不开测验数据预备作业。今日咱们就来聊一聊测验作业中常用的测验数据预备的办法,深化了

测验数据的预备,是软件测验作业中十分重要的环节,无论是手艺测验仍是自动化测验都避不开测验数据预备作业。今日咱们就来聊一聊测验作业中常用的测验数据预备的办法,深化了解各自的优缺陷和运用场景,以及测验数据预备作业未来的开展方向。

01 常见的测验数据预备办法

我总结了一下我曾经过用过的生成测验数据的办法,首要有以下几类:

  • 依据 GUI 的测验数据生成办法

  • 依据 API 的测验数据生成办法

  • 依据 DB 的测验数据生成办法

  • 依据 MQ 的测验数据生成办法

  • 依据第三方库办法的测验数据生成办法

  • 归纳运用上述办法生成测验数据

接下来,咱们一同详细分析一下各种办法的有权点以及适用场景。

依据 GUI 预备测验数据

依据 GUI 界面进行测验数据预备,是最原始的创立测验数据的办法,这种办法其实是选用 E2E 的办法来履行事务场景,然后得到测验数据。

比方,测验用户登录功用,那么需求预备的测验数据便是用户账号,为此咱们能够经过 APP 或许 WEB 端的 GUI 页面注册新用户,然后用这个用户完结用户登录功用的测验。

这种办法的长处是简略直接,创立的数据来自于实在的事务流程,最大程度确保了数据的正确性和完整性。在许多手艺测验的场景中,这种办法被遍及选用。

可是,这种办法的缺陷也十分显着,首要体现在以下几个方面:

  • 创立测验数据的功率低,不适宜批量生成测验数据。因为经过 GUI 操作每次只能发明一条数据,而且经过手艺操作 GUI 的进程也是比较耗时。

  • 依据 GUI 的测验数据生成办法不适宜为自动化测验供给数据。因为自动化测验往往是经过代码来预备测验数据,而 GUI 办法生成测验数据的办法不太适宜封装成代码被自动化测验用例调用。因为封装 GUI 办法生成测验数据的办法,实质上是在开发 GUI 自动化测验用例,而咱们知道无论是开发作业量仍是履行功率,亦或是安稳性方面,这种办法都是不是最佳的挑选。

  • 会引进不必要的测验依靠。比方测验用户登录功用,假如依靠 GUI 先注册一个用户,那么就意味着注册功用有必要是没问题的,引进了依靠。这种状况,从数据库中找到一个已注册的账号来测验登录功用才是最佳挑选。

在前后台合作的手艺测验中,比方内容办理体系 CMS 和手机 APP 的测验,假如要手艺测验手机 APP 的文章列表功用,那么就能够选用这种办法。除此之外,依据 GUI 操作生成测验数据的场景并不多。

依据 GUI 生成测验数据的办法,有一个十分重要的价值是协助咱们在创立测验数据的进程中,找到创立数据的进程中都调用了哪些 API 以及修正了哪些 DB 的表。只要了解了这两个方面,咱们后续经过 API 或许修正 DB 办法创立测验数据时,才干确保数据的完整性。

依据 API 预备测验数据

经过调用 API 生成测验数据,是现在测验数据生成的首要办法。因为后台接口一般比较安稳,大大供给了测验数据结构的准确性和成功率。调用接口比较 GUI 操作也能够比较快速的创立测验数据,功率高。别的,因为咱们直接给 API 传递参数,经过参数的组合能够结构成某些 GUI 办法不能结构出来的测验数据。

那么,咱们怎么获取到这些 API 呢?一般引荐依照下面的次序,来查找 API 相关的信息。

  1. API 接口文档。一般老练的开发团队,都会编写 API 的接口文档,接口文档中会详细描述接口的 URI 和调用参数,这是最直接有用的办法。

  2. 经过抓包。抓包在测验中是十分常用的辅佐手法,咱们能够在操作 APP 或许 WEB 页面的时分,对操作进行抓包,经过对抓取到的恳求包,分析接口的各种参数。这也是相对高效的办法。

  3. 检查日志文件。关于现已上线的接口,咱们能够经过服务的日志,来检查接口调用进程中的 URI 和参数等内容。

  4. 阅览源码。假如前面三种办法都不能用,那么能够在 Gitlab 上检查开发人员的项目代码,经过阅览代码的办法,找到接口恳求的各种参数。

经过 API 结构测验数据的办法也不是完美的,首要有几个方面:

  1. 不是一切的数据创立都有对应的 API。

  2. 有时分需求次序调用多个 API。有时分测验数据之间是有相关联络的,为了确保测验数据的完整性和一致性,需求顺次调用多个 API,无形中增加了测验数据预备的杂乱性。

调用 API 创立测验数据,天然生成适宜与自动化测验相结合,在实践的测验实践中,咱们往往会把 API 封装成测验数据预备函数供自动化测验用例运用。当 API 内部逻辑有修正时,咱们仍旧能够经过封装函数来预备测验数据,对测验用例来说,是彻底通明的。

这儿所说的 API 指的是依据 HTTP 协议的 RESTful API。可是能够扩展到其他协议的各种调用接口,比方 MQTT 协议、RPC 协议等。

依据 DB 预备测验数据

经过往数据库中直接刺进数据,也是十分常用的结构测验数据的办法。详细做法是,将创立测验数据的 SQL 句子封装成一个个测验数据生成函数,当咱们创立数据时,直接调用这些封装好的函数即可。这种办法有一个十分大的长处是生成测验数据的功率十分高,能够短时刻内往数据库中刺进许多的测验数据。

以用户登录功用测验为例,当咱们调用 API 进行用户注册时,这个 API 会将用户的详细的信息刺进到 user 表和 role 表两个数据库表中。假如咱们选用数据库办法发明数据时,给 user 表和 role 表别离刺进对应的数据就完结了用户的注册。咱们还能够直接运用 DB 中已有的数据作为咱们的测验数据,然后省去了许多操作。

这儿的条件是,你有必要知道进行新用户注册时,究竟触及到了哪些数据库的表。最直接的办法便是跟开发同学索要 SQL 句子,或许检查源代码。

这种结构测验数据的办法也不是完美的,首要体现在以下几个方面:

  1. 有的测验数据预备触及到的数据表太多。导致封装和保护测验预备函数的本钱比较高。

  2. 简单呈现数据不完整和不一致。比方服务 A 某一个事务,实践会在服务 A 的数据库表 A 和数据库表 B 中别离刺进数据,而且一同会给 kafka 的某个 topic 发送数据供服务 B 消费处理后耐久化到服务 B 的数据库表 C 中。假如咱们漏掉了某个数据库表的刺进操作,或许会导致数据的不完整和不一致。

依据 DB 预备测验数据的办法,一般作为 API 办法的弥补。

依据 MQ 预备测验数据

在微服务架构中,一般会存在经过音讯中间件将多个服务进行解耦,为了削减测验作业的依靠,一般会往 kafka 中结构测验数据。

比方,两个服务是经过 KAFKA 进行音讯传递的,两个服务别离作为 kafka 的生成者和顾客。当咱们测验作为顾客的服务时,就能够编写 kafka 的 producer 代码,往 kafka 中出产测验所需求的测验数据。详细的做法与经过 DB 结构测验数据的办法相似,将 kafka 的 producer 代码封装成测验数据生成函数,当咱们创立数据时,直接调用这些封装好的函数即可。

这种做法和操作 DB 并没有实质不同,其长处和缺陷也是相似的。

依据第三方库预备测验数据

咱们的测验实践中,常常会需求生成许多随机的数据,关于这类需求,直接运用代码封装成函数生成数据。拿 python 为例,能够自己结合 random() 之类的函数随机生成数据,还能够运用 faker( 项目地址 )这样的第三方库来完成:

这类生成测验数据的办法试用的场景是,对数据自身的值不关心可是测验中又有必要需求这些参数的状况。

归纳运用上述办法预备测验数据

在实践作业中,很少运用单一的办法就能满意测验的需求,往往是归纳运用上述各种办法、一个典型的运用场景是,经过 API 生成最根底的测验数据,比方车辆的 vid,然后运用数据库和 MQ 的办法是生成契合测验需求的车辆状况数据。

我以上报车辆状况数据的测验为比方,来同享一下详细的怎么将 API 调用和 MQTT 协议的办法结合起来结构测验数据。

比方咱们要测验云端对车辆上报的报警数据的处理是否契合要求。首要,咱们需求经过调用注册 Vechile ID 的接口来注册一台车而且获得车辆证书,经过调用这个接口咱们能够得到一个车辆的 ID 以及证书数据。再结合 MQTT 协议发生车辆的报警数据。

为了结构测验数据的愈加快捷,咱们往往是对上面的操作进行封装。用封装后的办法发生测验数据。

02 预备测验数据的机遇

前面介绍了预备测验数的办法,那么应该在什么时分创立好所需求的测验数据。是在测验用例履行中创立测验数据(On-the-Fly 办法)仍是在测验履行前就预备好测验数据(Out-of-Box 办法)。

其实,创立测验数据的机遇要依据实践的需求来。首要参阅一下几个要素:

  1. 创立测验数据所需求的时刻。假如创立数据需求花很长时刻,那么最好选用 Out-of-Box 办法,在测验履行之前就预备好,以削减整个测验履行的时刻。

  2. 测验数据是否需求常常改动。假如测验数据不需求常常改动,那么最好选用 Out-of-Box 办法。假如事前生成数据在测验用例中会失效,比方具有有用期的数据,那么就适宜选用 On-the-Fly 办法,在测验履行中创立。

  3. 测验数据是否存在于许多体系。假如测验数据需求在许多体系中都要创立各自的部分,各自又有许多依靠联络,那么就适宜 Out-of-Box 办法。因为在测验用例履行中创立,会导致测验代码比较臃肿,不行明晰。

  4. 结构测验数据的服务是否安稳。在不太安稳的服务中结构测验数据,会发生许多结构测验数据失利的状况。这种状况下选用 Out-of-Box 办法仍是比较正确的。

接下来,咱们详细看一下 On-the-Fly 办法和 Out-of-Box 办法各自的特色,以及适用场景。

实时创立(On-the-Fly)

实时生成测验数据的办法,指的是在测验用例代码履行进程中即时创立测验数据。比方,测验车辆驾驭中,不能履行长途操控指令的场景。在测验履行中,能够经过封装的 MQ 办法设置测验车辆的车辆状况处于驾驭中,接下来就能够测验长途履行指令了。

On-the-Fly 办法发明的测验数据一般是对每一个测验用例起作用的,不同的测验用例都有自己专属的测验数据。像这种车辆状况数据就适宜选用 On-the-Fly 办法发明,这种状况数据一般是每个测验用例都不同。这种结构测验数据的优点是,防止测验数据在测验用例履行前被修正而发生非预期的测验成果。这样的测验数据运用完之后,一般在测验用例完毕之后,康复成原始数据,防止影响其他测验用例。

在自动化测验开展前期,测验实践中一般都会这种办法,也是比较好的办法。他处理了测验用例之间数据之间搅扰的问题,也防止了测验完之后的脏数据问题。可是跟着软件架构的开展,以及测验频率的进步,这种办法的坏处也逐步显示出来了,首要有以下几个方面: 首要,有的测验数据比较耗时。 在测验用例履行进程中实时创立测验数据,会导致测验用例履行的时刻被拉长。假如测验用例特别多,测验频率又特别高,那么测验时刻就变得特别长,这显着不适宜现在互联网软件的迭代节奏。为了处理测验耗时的问题,能够选用 Out-of-Box 办法。 其次,测验数据自身之间杂乱的相关性导致结构困难。 许多时分,你为了测验某一个场景,需求结构一堆相相关的测验数据,也是倾向事务链后台的测验数据,这个问题越显着。

比方,要测验被授权人对车履行长途操控指令的场景。会需求车主账号、被授权人账号、车辆 ID、车辆 ID 与车主账号绑定,车主给被授权人授权车辆等前置数据。假如在测验用例履行中预备这些测验数据,那肯定是溃散的。假如每一个测验用例都这么做,一定会导致测验时刻变得十分长。为了处理这个问题,能够考虑将一部分安稳的数据事前创立好,比方车主账号、被授权人账号、车辆 ID 以及授权联络等数据。

微服务架构的盛行导致成功生成测验数据的安稳性下降现在许多互联网运用选用微服务架构,不同功用划分为更多的微服务独立开发和布置,许多时分测验环境里边,这些微服务并不是 100% 可用的。也便是说,不是任何时分结构测验数据都能成功。比方你测验的微服务 B,需求依靠微服务 A 结构数据,而这时分正好微服务 A 不行用,这就 block 了微服务 B 的测验。

为了处理上面的问题,事前预备测验数据的 Out-of-Box 办法,就有了用武之地。

提前预备(Out-of-Box)

Out-of-Box 办法,指的是在测验用例履行前,就现已预备好了所用的悉数或许部分测验数据,而不是在测验用例中施行创立。因而,履行测验用例时分,能够节约不少预备测验数据的时刻,一同也防止因为依靠的测验数据预备服务不行用导致测验被 block 的状况。

那么 Out-of-Box 办法是否也存在缺陷呢?

最首要的问题是 “有用性” 问题,便是有测验履行中发现测验数据不行用的危险。比方,测验被授权人长途履行车控指令的场景,当你履行测验时,发现被授人的身份现已被车主账号删掉了,这样就导致测验用例履行失利,也就不能顺利完结测验了。

由此可见,这些完成创立好的测验数据,有或许在测验用例履行时现已不行用了,因为这些数据有或许现已进行了非预期的修正。比方,在其他测验用例履行时,运用了这个测验数据,并修正了这些数据的状况。

为了处理这个问题,咱们一般选用优化测验办理流程,让不同的测验人员、测验事务都有自己独立的测验数据,而且计算在 confluence、jira 或许其他公共渠道上,咱们严格遵守,不要乱用测验数据。

别的,Out-of-Box 办法不适宜预备,只能被运用一次的测验数据,只会运用一次的测验数据仍是选用 On-the-Fly 办法预备比较适宜。

实践作业中,咱们一般是选用 On-the-fly 和 Out-of-box 这两种办法相结合的办法来预备测验数据。咱们能够依据测验意图的不同,将测验数据划分为 “固定数据” 和 “易变数据”。比方某些测验场景中,车辆 ID、车辆 Profile、车主账号等信息是相对安稳、不常常改动的数据,那么咱们能够将这些测验数据称为 “固定数据”,这类数据适宜选用 Out-of-box 办法创立。可是在某些测验场景中,比方车辆 ID 的刊出,车辆 Profile 的改动测验,那么车辆 ID、车辆 Profile 就不能叫做 “固定数据” 而是应该叫做 “灵敏数据”,这类数据适宜选用 On-the-fly 办法预备。

归纳运用这两类办法,能够满意大部分测验数据预备的场景。能够处理预备测验数据耗时长、预备测验数据成功率不高级问题。

03 结构测验数据的痛点及应对

前面,咱们分析了两种预备测验数据的机遇以及各自的优缺陷。那么咱们实践作业中,预备测验数据的作业有哪些痛点,咱们又该怎么处理呢?

调用封装函数的杂乱性

前面说到封装 API 到一个函数,然后调用这个函数来结构测验数据的办法。可是这种封装办法会有问题,便是假如参数十分多,那么你调用它来结构数据时,就要预备这些参数。假如这些参数是根本类型的话还好,假如参数自身也是目标的话,或许就会愈加费事了,因为你要创立这些目标。而创立这些目标,有或许要继续调用其他封装的函数,然后牵连出一系列函数调用的操作。

比方,调用这样一个封装了注册车辆 vid 的函数:

由此可见,每次运用封装的函数预备测验数据时,咱们要给函数传递一切的参数。其实大多数测验场景下,一切参数都能够给一个默许值,用这个函数预备测验数据时,只需求给那些有明确要求的参数传值,其他参数坚持默许值即可。这样封装的函数就变成这样:

这样,大大削减了调用封装函数的本钱。当测验用例中只需求一个特定 vin 的车辆时,只需求给 register_vehicle 传递参数 vin 的值,其他的测验用例不关心的参数都能够坚持默许值。

封装函数的版别办理

一般咱们封装函数是给一切的测验项目一同运用的,这样才干最大化封装函数的价值。同享封装函数的办法一般是将其打包,然后在其他项目中引证。假如你的测验项目是运用 Python,那么能够将封装的函数用 setuptools 打包上传到公司的 Pypi 渠道,在测验的项目顶用 pip 装置。假如你的测验是运用 Java,可用 Maven 将封装函数打成 Jar 包并上传到公司的私有库房,在测验项目中的 pom.xml 中引进 jar 包就好了。

现在的互联网运用版别迭代更新特别快,导致封装函数也要对应的迭代更新。这就会发生数据预备函数的包晋级更新比较频频,包的版别号就要跟着改动。所以引证了这些数据预备函数包的项目,就要更新包的版别。给运用者带来了一些费事。

为了处理项目对封装函数的依靠问题,咱们能够将其做成 Restful API,这样运用者就免去了频频更新这些依靠包的费事。而且 Restful API 天然生成的跨渠道支撑,让调用方不管是用 Java 写测验用例仍是 Python 写测验用例,都能够得到完美的支撑。接下来咱们就详细介绍一下依据 Restful API 的测验数据预备计划。

04 一致测验数据生成渠道

前面介绍了创立测验数据的首要办法、创立测验数据的机遇,以及测验数据生成中的痛点。跟着测验技能的开展,测验数据预备技能与架构也需求逐步进化,来满意互联网微服务架构的开展趋势以及快速迭代的特色。

现在业界,将测验数据预备的作业进行渠道化,逐步成为测验数据预备计划的开展方向。而 Restful API 的测验数据预备计划,正好适宜渠道化的开展方向。咱们能够将依据 Java 开发的数据预备函数用 Spring Boot 包装成 Restful API,或许将依据 Python 开发的数据预备函数用 Flask 或许 Django REST framework 包装成 Restful API。

这样一来,测验人员能够经过 Restful API 调用来预备测验数据了,因为 HTTP 协议是跨渠道的,所以简直一切的测验结构都能够直接运用这些 Restful API 预备测验数据。因为运用 Restful API 供给测验数据,这样便利咱们将供给各类测验数据的服务整合到一同,构成 “一致测验数据生成渠道”。结合 Swagger 供给的界面化文档,能够便利看到接口调用的办法,而且能够直接在界面上调用接口生成数据。既满意自动化测验的需求,也能满意手艺测验的需求。

现在为止,咱们将测验数据预备作业进行了服务化,下图便是一个一致测验数据生成渠道的 Restful API 界面。

一致测验数据渠道 Restful API UI 界面

" 一致测验数据渠道 " 从供给的测验数据特性来分,能够分为实在数据和 Mock 数据。实在数据便是封装微服务的接口,在事务体系中实践发生实在的事务数据用作测验数据。Mock 数据是指经过 mock 技能发生非实践事务中的数据、这类数据一般用于处理服务依靠问题。

供给实在数据

下面经过 Flask Web 结构来介绍怎么经过封装事务操作供给实在的测验数据实践。

比方,我要测验长途操控车辆的 API,其中有一个测验用例是验证在车辆在行进中时不能进行长途操控。针对这个测验用例,咱们需求的测验数据有被操控车辆的 ID 以及车辆状况。下面以预备车辆 ID 的 Restful API 为例,介绍详细的完成办法。

首要,运用 pipenv 创立虚拟环境,装置好 Flask 结构。

下面这段代码是封装了事务接口 api/1/in/vehicle/profile 的代码片段。

在这段代码中,供给默许参数,只需求传递测验感兴趣的参数就能够,不感兴趣的数据坚持默许值即可。结合 flasgger 供给的 swag_from 装修器,给接口编写文档,让封装的接口易懂和易用。

供给 Mock 数据

什么状况下需求 Mock 数据,比方:服务 A 调用服务 B 的 Restful API,传递给服务 B 数据,服务 B 会依据数据状况回来给服务 A 一个 ACK 值。当服务 B 没有 Ready 时分,咱们就需求模仿服务 B 的行为。

其实发生这种 Mock 数据,与前面介绍的发生实践事务数据,办法上并没有不同。只是在 Restful API 的 response 结构上,前者结构发生的数据来自与实在的事务接口,而 Mock 的数据是依据测验需求假造的。模仿前面说到的服务 B 的行为,以 Flask 计划为例,便是:

经过操控上面 ack 的内容,就能够模仿服务 B 的各种 Response 了。假如将这个 ack 的内容存入数据库中,让 get_ack 函数从数据库中获得 ack 并回来。再写一个接口用于往数据库中写入 ack,那么就能够在自动化测验中随意操控 ack 的回来内容了。

05 总结

本篇文章咱们梳理了测验数据预备的各种办法,并分析了各自的优缺陷及适用场景。测验数据预备的机遇上看,关于不常改动的数据适宜选用提前预备的办法,关于常常改动的数据在测验用例中预备更好。对测验作业中数据预备的痛点进行了分析并给出了应对计划。最终,给出了处理测验数据生成痛点的终极处理计划——" 一致测验数据生成渠道 "。


原文转自:TesterHome