关于测试自动化:接口测试利器

53次阅读

共计 5431 个字符,预计需要花费 14 分钟才能阅读完成。

背景

在整个软件开发生命周期中,软件测试工作始终贯通其中,包含开发过程中、代码合并前的集成测试以及上线后的继续集成测试。为保障软件品质的全面性和稳定性,开发和测试人员都须要一直反复执行以下测试工作:

  • 接口调试

接口调试是开发人员在实现开发后进行疾速自测的一种无效形式,通常能够应用一些接口调试工具,如 Postman、ApiFox 等向接口发送申请并察看返回后果,调试和解决接口实现中呈现的问题。

  • 接口自动化测试

由测试人员筹备测试数据、编写测试用例并应用 JMeter 等工具编写自动化测试脚本,自动化执行测试用例,以确保代码的品质和稳定性。

  • 接口数据 Mock

Mock 在英文中含有模拟的意思,顾名思义,数据 Mock 就是通过结构假数据来达到测试的目标。采纳 MockJS 等工具 Mock 接口数据,能够节俭数据结构的工夫,这对前期进行回归测试工作的效率晋升至关重要。

  • 接口回归测试

回归测试旨在确保软件在通过批改、增加新性能、优化性能等后依然可能失常工作,在软件的疾速迭代开发中尤为要害。在接口回归测试中,通常须要结构数据、保护数据、测试用例及接入 CI/CD 流程。

对于一个产研团队来说,若要实现上述研发过程中所有环节的需要,至多须要应用四五种不同的工具能力满足,在理论工作中带来的问题也可想而知:

  1. 复杂性减少:应用多个工具可能会导致研发流程变得更加简单,须要更多的工夫和精力来协调和治理,团队无奈在同一套零碎中进行合作,导致各种沟通不及时、配合低效。
  2. 高风险:应用多个工具也意味着须要将数据从一个工具同步到另一个工具,这可能会减少出错的危险。
  3. 高老本:每个工具都有本人的应用办法和特点,须要破费工夫来学习和把握,前期也须要破费更多的工夫来保护和更新工具,特地是在长期的我的项目中。
  4. 回归测试复杂度减少:对于须要疾速迭代的简单零碎,须要频繁地保护数据和用例,无论是脚本化保护还是手工保护,都须要破费大量的精力。业务复杂度高时,回归测试的复杂度可能会日益增高,这可能须要更多的工夫和资源来实现。
  5. “自动化”测试侧重于“自动化”执行,但保护工作仍旧是“手工”,工作量十分大。

试想一下,如果有一款工具能够实现上述所有性能,那不是能够大大简化研发流程,进步测试效率,升高保护老本和出错率?明天咱们要介绍的就是这样一个工具:AREX。

什么是 AREX

AREX 是一款开源的自动化测试平台,联合了 Postman + Mock + 比对测试 ,不仅提供了接口测试性能,更是通过 Java Agent 字节码注入技术,在生产环境录制和存储申请、应答数据,在测试环境回放申请和注入 Mock 数据,并存储新的应答,以此来达到主动录制、主动回放、主动比对,为接口回归测试提供便当,实现了从接口调试到接口数据 Mock,再到接口自动化测试和接口回归测试的闭环工作流。借助 AREX,开发和测试人员能够各取所需,协同单干,实现更高效的软件开发和测试。

接口调试(Postman)

AREX 不仅能反对 Postman 大部分的接口调试性能,还提供了接口用例性能。

接口用例性能

AREX 能够为同一个接口申请保留多个场景下的接口用例,每个用例都将主动继承以后接口申请下的配置,如 URL、申请形式及 Parameters、Header、Body 及前置脚本(Pre-request Script)等。通过继承父节点的接口申请配置,测试用例不须要一一从新定义接口的申请参数及前置脚本,后续再次调试时可间接运行接口用例,从而缩小测试用例编写的工作量和工夫。

AREX 还提供了测试用例治理性能。目前能够对测试用例增加标签(Add Tag)进行分类,前期将减少通过标签搜寻用例的性能,方便管理。另外能够为用例增加形容,进步用例可读性,让协作者更容易了解测试用例的目标和预期后果,并且能更好地把握测试内容。

导入、导出用例(开发中)

各个测试团队都有本人的测试习惯,强制迁徙到一个新的测试工具,有很大的迁徙老本。AREX 后续将陆续反对各种格局的测试用例导入、导出,届时旧工具中的泛滥用例能够一键迁徙到 AREX,无需再次新建我的项目,同时也能够将 AREX 录制到的用例导出,帮忙测试团队升高迁徙老本。

目前 AREX 正在反对 Postman 导出的用例导入,如需反对其余格局的用例导入,能够在 Github 上提交 Issue,与社区共建。

固化的测试用例也反对导出,目前反对 Postman 格局的用例(JSON 格局)。

接口回归测试(Mock + 比对测试)

AREX 采纳 Java 的 instrument 技术实现了无代码侵入的数据采集和自动化 Mock,在进行回放时会应用录制过程中采集到的数据进行 Mock,代替真正的数据拜访,并不会产生真正的内部交互(如 DB 的写入、其余第三方服务的调用),防止了回放测试中脏数据的写入。同时反对各种支流技术框架的主动数据采集和 Mock,包含数据库 redis 等,并且反对了本地工夫、缓存等数据的 Mock,回归测试时能够在测试环境完满还原生产执行时的数据环境。

如果用户对 Mock 的数据须要进一步理解,能够在回放界面找到指定的用例,查看 Mock 数据和批改 Mock 数据。

接口回归测试,不须要筹备测试用例、测试数据、接口 ASSERT,只需装置 AREX Agent,就能够全副从生产环境获取最新的申请,最新的数据,应用比对差别来验证最新的代码:

  • 反对录制生产申请应答
  • 反对录制接口的内部申请和应答,包含 http 申请、数据申请、redis 申请等
  • 反对主动比对接口应答的差别,内部申请的申请差别
  • 反对回放申请和 MOCK 内部申请

步骤一:装置 AREX 服务。

git clone https://github.com/arextest/deployments.git
cd deployments
docker-compose up -d

步骤二:将你的被测试利用生产环境的运行形式批改成如下的命令

java -javaagent:/path/to/arex-agent-0.1.0.jar -Darex.service.name=your-service-name -Darex.storage.service.host=[storage.service.host:port](storage.service.host:port) -jar your-application.jar

其中:

  • /path/to/arex-agent-0.1.0.jar 须要批改为 arex-agent-0.1.0.jar 文件在你服务器中的理论门路
  • your-service-name 须要批改为你被测利用的名称
  • [storage.service.host:port] 须要批改为数据存储服务的地址和端口号
  • your-application.jar 须要批改为应用程序的 jar 包文件名

或者在环境批改环境变量

export JAVA_OPTS="-javaagent:/path/to/arex-agent-0.1.0.jar -Darex.config.path=/path/to/arex.agent.conf"

步骤三:拜访 AREX 前端页面,在 Replay 模块,抉择到方才搭载过 AREX Agent 的服务(即上文的 your-service-name)。

步骤四:抉择回放,输出你测试环境的接口地址,开始执行所有录制的接口测试用例。

回放实现后,会生成详尽的回放报告,能够很直观地看到回放通过率、接口通过率,以及每个接口下的详情。

呈现回放失败的接口能够点击查看该接口下回放失败用例的比对后果,AREX 在最新版本中将比对后果进行了可视化展现,不便定位问题。

还有一种更简略的形式,不必装置 AREX 各种繁琐的服务组件,只需通过 ArexCli 启动本地模式:

git clone https://github.com/arextest/arex-agent-java.git 
cd arex-agent-java 
mvn clean install  
java -jar "./arex-cli-parent/arex-cli/target/arex-cli.jar"

运行后进入如下界面

反对的命令如下:

  • ls:查看录制的所有 case。

    • [option: -o/–operation] view all cases under the specified operation
  • replay:回放录制好的数据并比照差别。

    • [option: -n/–num] replay numbers, default the latest 10
    • [option: -r/–recordId] single replay available for local debug
  • watch:查看回放后果及差别。

    • [option: -r/–replayId] replay id, multiple are separated by spaces

须要留神的是,在本地模式中,AREX 应用 H2 作为本地存储保留测试数据,不再依赖配置服务和存储服务。同时,你将无奈应用 AREX 的前端界面。

接口自动化测试

AREX 的自动化测试实际上就是通过将多个接口测试用例有序地组合在一起后进行批量运行,以测试一个残缺的业务流程。

利用 AREX 工具进行接口自动化测试的一大劣势在于,无需手动编写大量的测试用例,海量的线上实在申请即可轻松满足覆盖率,你能够抉择间接固化曾经录制好的接口用例,或通过强制录制的形式固化你所须要的接口用例。

AREX 固化用例

AREX 能够将搭载过 AREX Agent 的利用在线上实在产生的申请,包含其 Mock 数据通过肯定的采样频率进行录制。如果须要将某些重要用例固化下来,作为之后回归测试必须执行的我的项目,只需在回放报告中,找到须要的用例,点击保留,抉择目标目录,即可将用例固化下来,体现为惯例的测试用例(区别在于报文头里边有 arex-record-id 标识)。

AREX 强制录制

如果某些重要的测试用例没有录制下来,则能够通过手动强制录制来实现固化。

在 AREX 接口测试界面中,点击 action.record 图标,在申请 Header 中增加 Key: arex-force-record,Value: true,点击 Send 发送申请。返回报文的 Header 中会生成 Record ID,Key:arex-record-id,Value: 录制 ID。点击 Save 即可保留该条录制用例。

通过 AREX 录制或强制录制固化下来的测试用例,相较一般的测试用例会多一个 Mock 数据的模块,即 AREX 在录制过程中 Mock 到的所有数据(左侧是 Mock 到的主接口及内部调用的申请报文,右侧是对应的响应报文)。

AREX 当初反对对 Mock 数据进行编辑批改。比方你须要验证本地环境下开发的新性能,如果对 Mock 的数据不称心,则能够手动批改以满足新性能的需要。

自动化测试 Pipeline

CI/CD 是当初测试团队的标配,反对接入 CI/CD 是必须的性能。AREX 反对放出 WEB Hook 接口,由内部零碎(比方 Jenkins)触发执行。

  1. 在 AREX 中创立一个测试工作,创立测试用例和测试环境,确保测试工作可能在 AREX 中失常运行。
  2. 在 Jenkins 中创立一个新的 Job(工作),用于触发 AREX 测试工作。
  3. 在 Jenkins 的 Job 配置中,增加一个“Execute shell”步骤,用于执行 CURL 命令,调用 AREX 的 Web Hook 接口。CURL 命令能够通过以下形式来结构:
curl -H "Content-Type: application/json" -X POST -d '{"test_id":"test_task_id"}' https://arex-webhook-url

其中,arex-webhook-url 是 AREX 的 Web Hook 接口 URL,能够在 AREX 点击 Start replay 开启回放测试时获取。

  1. 配置 Jenkins Job 的触发器,使得 Job 能够在特定的条件下主动运行。例如,能够设置为每次提交代码到源代码仓库时触发。
  2. 运行 Jenkins Job,查看测试工作是否被触发,并且测试后果是否失常。

通过上述步骤,咱们能够将 AREX 集成到 Jenkins 中,实现自动化测试和继续集成。

接口测试左移

传统软件测试流程通常包含需要评审、编写测试用例、筹备测试脚本、开发提测后执行测试、提交问题、回归测试等步骤。这种流程存在的问题在于,测试人员处于十分被动的状态,往往须要期待开发人员实现代码开发、正式提测后能力发展测试工作,从而影响整个开发流程。

特地是在麻利开发和继续交付等开发模式广泛应用的时代,互联网产品的迭代周期变得更短、速度更快、频次更高,这也为传统软件测试带来了更大的工夫压力。

为解决这一问题,测试左移成为一种更加被动的测试策略。测试左移的次要思维是,通过在代码开发的晚期阶段进行测试,让测试人员更有主动权,可能更早地发现和解决问题,从而缩小谬误和故障对于前期开发工作的影响。这样,测试人员就不会因为品质差或危险高而每次都推延上线,同时也能保障产品在线上的品质。

在软件开发中,开发人员通过触发 CI 流程,应用 AREX 进行代码签入前的测试。这样做的目标是为了在代码 CheckIn 之前,提前发现并解决问题,缩小对于前期开发工作的影响。如果在问题验证过程中确定是 BUG,开发人员会进行修复。如果变动是因为代码变更导致的失常后果,开发人员会将差别标识为疏忽。测试团队可能看到被标识为疏忽的节点及其变动,从而同步获知代码变动的影响面。这样做能够让开发人员更加被动地解决问题,同时也能够进步软件的品质和稳定性。

正文完
 0