写点什么

自动化接口用例从 1 到 1000 过程中的实践和思考

  • 2020-03-11
  • 本文字数:4750 字

    阅读完需:约 16 分钟

自动化接口用例从1到1000过程中的实践和思考

引言

当一个新人刚加入公司的时候,我们通常告诉新人怎么去写一个自动化用例:从工程配置到如何添加接口、如何使用断言,最后到如何将一个用例运行起来。


而在实际工作和业务场景中,我们常常面临着需要编写和组织一堆用例的情况:我们需要编写一个业务下的一系列的自动化接口用例,再把用例放到持续集成中不断运行。面临的问题比单纯让一个用例运行起来复杂的多。


本人加入有赞不到一年,从写下第 1 个 case 开始,持续编写和运行了 1000 多个 case ,在这过程中有了一些思考。在本文中,和大家探论下如何编写大量自动化接口用例以及保持结果稳定。

一、执行效率

目前使用的测试框架是基于 spring ,被测接口是 dubbo 的服务。 dubbo 的架构如图(源自官网)



服务使用方的初始化需要经历以下这几个步骤:


  1. 监听注册中心

  2. 连接服务提供端

  3. 创建消费端服务代理


本地调试用例时,发现速度非常慢,运行一个用例需要 30s,而实际执行用例逻辑的时间大概在 1s 左右,主要时耗在服务消费者的初始化阶段。


测试工程中,各服务的 test 类继承了同一个基类,基类里面做了各服务的初始化的步骤。在对接的服务数目较少时,需要初始化的对象较少,对用例运行的影响并不大,但随着业务的增多,服务数目也增多,导致跑 A 服务接口的用例时把大量未用到的 B 服务、C 服务也一起初始化了,导致整体时耗大大增加。


解决办法:在运行用例时只初始化需要的服务使用方,减少不必要的初始化开销。

二、用例编写和维护

一个用例示例

以一个简单的业务场景为例:商家可以在后台创建会员卡给店铺的会员领取,商家可以对会员卡进行更新操作,这里需要有一个自动化用例去覆盖这个场景。



用例编写的基本步骤为:


  • step 1 :准备数据构造新建会员卡和更新会员卡的对象

  • step 2 :执行创建会员卡

  • step 3 :执行更新会员卡

  • step 4 :检查更新结果

  • step 5 :清理创建的会员卡


转换成代码为:


  @Test  public void testUpdate() {    try {      /*       * 创建新建和更新的卡对象       */      CardCreateDescriptionDTO descCreate = new CardCreateDescriptionDTO();      descCreate.setName(xxxx);      //此处省略若干参数设置过程....
CardUpdateDescriptionDTO descUpdate = new CardUpdateDescriptionDTO(); descUpdate.setName(xxxxx); //此处省略若干参数设置过程.... /* * 新建会员卡 */ cardAlias = cardService.create((int) kdtId, descCreate,operator).getCardAlias(); /* * 更新会员卡 */ cardService.update(kdtId, cardAlias, descUpdate, operator); /* * 校验编辑是否生效 */ CardDTO cardDTO = cardService.getByCardAlias(cardAlias); Assert.assertEquals(cardDTO.getName(), xxxx, "会员卡更新失败"); //此处省略若干参数校验过程.... } catch (Exception e) { Assert.assertNull(e); } finally { try { if(cardAlias!=null) { cardService.deleteByCardAlias((int) kdtId, cardAlias, operator); } } catch (Exception e) { Assert.assertNull(e, e.getMessage()); } } }
复制代码


按照预期的步骤去写这个 case ,可以满足要求,但是如果需要扩展一下,编写诸如:更新某种类型的会员卡、只更新会员卡的有效期这样用例的时候,就会觉得按这个模式写 case 实在太长太啰嗦了,痛点在以下几个地方:


  • 数据准备比较麻烦,需要逐一设值

  • 数据检查部分逐字段检查,心好累

  • 每个创建相关的用例都需要清理资源,每次都需要做一次,太重复了


用例本身关注的是更新这个操作,却花了太多时间和精力在其他地方,很多是重复劳动。代码编写里有一个重要原则,DRY(Don’t Repeat Yourself),即所有重复的地方都可以考虑抽象提炼出来。

三段式用例

可以将大部分用例的执行过程简化为三个部分:


  1. 数据准备

  2. 执行操作

  3. 结果检查


用简单的三个部分来完成上述用例的改写:


数据准备


  @DataProvider(name="dataTestUpdate")  public Object[][] dataTestUpdate() {    return new Object[][]{  {cardFactory.genRuleNoCreate(...),cardFactory.genRuleNoUpdate(...)},{cardFactory.genRuleCreate(...),cardFactory.genRuleUpdate(...)},{cardFactory.genPayCreate(...),cardFactory.genPayUpdate(...)}    };
}
复制代码


执行操作+结果检查


Test(dataProvider = "dataTestUpdate")           public void testUpdate(CardCreateDescriptionDTO desc,CardUpdateDescriptionDTO updateDesc){                try {        /*      * 执行操作:创建+更新      */                    //创建会员卡                                 CardDTO cardBaseDTO = createCard(kdtId,desc,operatorDTO);          cardAlias=cardBaseDTO.getCardAlias();                           recycleCardAlias.add(cardAlias); //将卡的标识放入垃圾桶后续进行回收                                CardDTO ori = getCard(kdtId,cardAlias);        //更新会员卡                   updateCard(kdtId,cardAlias,updateDesc,operatorDTO);                                                    CardDTO updated = getCard(kdtId,cardAlias);        /*      * 结果检查      */                checkUpdateCardResult(ori,updated,updateDesc,kdtId);                        
} catch (Exception e) { Assert.assertNull(e); }
复制代码


其中可行的优化点将在下面娓娓道来。

测试数据的优化

在这个用例中,数据准备的部分使用了 dataProvider 来复用执行过程,这样不同参数但同一过程的数据可以放在一个 case 里进行执行和维护。


数据生成使用了工厂方法 CardFactory ,好处是简化了参数,避免了大量 set 操作(本身包装的就是 set 方法);另一方面,根据实际的业务场景,可以考虑提供多个粒度的构造方法,比如以下两个构造方法需要提供的参数差别很大:


  • 第一个主要用在验证创建接口的场景,检查各个传入的参数是否生效。


  public CardCreateDescriptionDTO genRuleCreate(Boolean isPost,Integer discount,Long rate,Long pointsDef,            String couponIds, Long num, Long growth,Long termToCardId,Long amount,Long points,Long trade){
复制代码


  • 第二个用在如删除的场景,所以只需要一个创建好的会员卡对象,并不是很关注创建的内容是什么。


  public CardCreateDescriptionDTO genRuleSimpleCreate(String name){
复制代码


在上面的优化过的用例中,能够执行更新操作的前置条件是需要有一个已经创建的会员卡,在实际用例编写的时候通过直接创建一个会员卡,然后执行更新完成后再回收删除这张会员卡来满足这个条件。另一种提供满足操作所需前置数据的方式是预置数据(预先生成数据)。


以下情况可以考虑预置数据的方式:


  1. 提高用例稳定性,解依赖,加快执行速度

  2. 需要对特定的类型、状态的对象进行查询

  3. 创建或者构造比较麻烦


典型的场景:比如编写查询的用例时预先创建满足条件的对象供查询用例使用。


谈到预置数据,不得不谈的一个问题是数据管理。在编写用例的时候,“我们往往需要一个____的资源”,框框里面的即是对数据的描述和要求,比如我需要一个全新的账号,一个支付过的订单号,一张免费的会员卡,来完成我们的用例。所以需要对数据进行标记而不是简单硬编码的方式在用例中使用。


如:通过特定名字的变量名和数据进行关联。


  /**只做查询卡,不做领卡删卡*/  public Long queryCardUid = DataMocker.MOCK_YZUID.get(1);  /**用户卡类操作,领卡删卡*/  public Long takeCardUid = DataMocker.MOCK_YZUID.get(6);  /**退款用*/  public Long refundCardUid =DataMocker.MOCK_YZUID.get(4);
复制代码


对数据进行标记后,会发现有一部分数据是用来验证写操作(如创建、更新),有一部分数据是查询使用。如果数据又要被写操作的 case 使用,又要被读操作的 case 使用,那么写操作的问题和异常就会影响读操作 case 的执行结果。所以,在代码工程中,可以进行约定,将读写用到的资源进行分离来降低数据的耦合:


  • 查询 case 用的账号不做更改对象的操作

  • 查询 case 用的对象不做修改、删除的操作

  • 验证增、删、改行为的资源使用特定账号,且资源最后做回收删除处理(因为资源总数有限)


最后,用例执行完成后需要清理资源。这里的清理资源采用的是一个全局的 list 的方式保存需要清理的资源信息,在用例执行过程中往里增加数据:recycleCardAlias.add(cardBaseDTO.getCardAlias());,


然后用对应的方法取其中的数据进行删除,类似垃圾桶。与原有执行完就执行清理动作相比,使用垃圾桶更加灵活,可以选择控制下清理频率。


比如每次在 AfterMethodAfterClass 中去清理。


  //统一回收  @AfterMethod  public void tearDownMethod() {
for(int i =0;i<recycleCardAlias.size();++i) { try { deleteCard(kdtId, recycleCardAlias.get(i), cardOperatorDTO); } catch (Exception e) { logger.error("clear card fail: " + recycleCardAlias.get(i)); } } recycleCardAlias.clear(); }
复制代码

对方法的适度封装

在实际编写用例的时候,有两个地方可以考虑进行方法封装,从来简化调用,方便维护:


  • 封装基本操作。如果删除操作依赖创建操作,查询操作依赖创建操作,那么创建操作可以看作是个基本操作,可以对创建操作包装一下,将注意力关注于实际需要执行和验证的地方。可以封装的东西很多,有参数封装、异常处理的封装、一些轮训、重新逻辑的封装。 createCard()getCard()deleteCard方法就是将接口、参数组装、检查等封装好的方法。

  • 封装检查方法。上述用例中的检查采用了一个检查方法代替了以往的多个 assert: checkUpdateCardResult(ori,updated,updateDesc,kdtId); ,在方法里包装了一些关键字段的比较,包括两个对象之间成员是否一致的比较。所有的更新操作的结果都需要满足:有变更的字段值变成新的值,未发生变更的值和原有一致。该方法实现了这种检查逻辑,所以写更新操作用例的同学不需要关注如何校验,而是关心如何更新,因为检查逻辑是现成的、通用的。将来检查逻辑发生变更,也只需要维护这一个方法即可。

稳定性

当大批量用例进行运行时,用例集的失败率会变得较高,几个微小的瑕疵都会造成用例的失败,此时我们需要更加关注用例的稳定性。一些实践中比较好的措施和方式:


  • 减少外部依赖。如果执行过程需要依赖其他系统的接口的话,那么其他系统发生了变更或故障就会影响自身用例的进行。可以考虑通过预先生成的数据来替代调用外部接口生成数据在用例中使用。

  • 预置数据代替创建过程。由于操作越多稳定性越低,使用预置数据而不是实时生成它,速度更快,稳定性更高。

  • 使用不同账号等进行隔离。通过隔离,用例执行失败的脏数据就不会影响其他用例。

  • 调优:超时、等待时间。线上超时时间设置的比较短,测试环境的机器配置不如线上,需要适时调大超时和等待时间来保证接口调用不会超时。

  • 防御式编程。编写测试代码时不能假设数据已存在或者没有脏数据残留,所以预先的判断和清理很重要,比如检查到数据缺失就实时修复、用例运行之前考虑清除临时数据。

  • 定位并解决不稳定的问题。有时候偶现用例失败,可以考虑给被测应用增加日志,同时持续多次运行用例多次(如 testNg 里增加 threadPoolSize=1, invocationCount=50)来复现问题,最终解决问题。

总结

对于大规模用例的编写、组织和运行的问题,文中从三个方面给出了有赞测试的实践和思考:精简初始化来提高执行速度、优化用例编写降低编写和维护成本、多种方式提高用例稳定性,希望能给大家一些启发。


2020-03-11 22:20964

评论

发布
暂无评论
发现更多内容

国内好用的API网关推荐:技术选型与企业实践指南

RestCloud

API 数据安全 API网关 集成平台 ipaas

得物新商品审核链路建设分享

得物技术

AI

DeepSeek-V3.1上线百度智能云千帆,业内首发支持思考模式下Function Calling能力

科技热闻

文心快码Zulu:项目级智能脚手架轰然降临

Comate编码助手

AI辅助编程 AI 编程 文心快码 文心快码Zulu

AI 超聚合系统,一站式 AI 功能解决方案

微擎应用市场

AI‘’

RAGFlow+TextIn:RAG 实战教程!1 分钟实现解析性能提升

合合技术团队

人工智能 大数据 算法

元图CAD:破解离散文字提取难题,释放工程设计效率新潜能

元图CAD

OCR 元图cad 提取文字 离散文字

蓝队网络流量分析脚本:自动化威胁检测与防御利器

qife122

网络安全 流量分析

ETL与iPaaS的融合方案:加速数据集成流程

RestCloud

数据处理 API ETL 数据集成平台 ipaas

轻匠招生系统:微擎云端助力教育招生全流程高效化

微擎应用市场

5 个最佳 ServiceNow 开源替代品(含价格对比)

NocoBase

开源 低代码 零代码 ITSM ServiceNow

腾讯内部测试管理工具揭秘:让用例"活"起来

优测云服务平台

测试管理工具

解析 vLLM 架构及源码系列:模型执行过程

Jason黄

vLLM源码

荣耀远航计划丨2025上半年激励成果一览

荣耀开发者服务平台

荣耀开发者服务平台 荣耀HONOR 荣耀远航计划

AI赋能驱动下的容器化应用开发范式升级

xuyinyin

获高瓴光速数千万美元投资,质变科技发布首款类人决策智能体Bloom

AI数据云Relyt

数据智能 智能体 AI Agent 决策智能 Agentic AI

震坤行商品列表API秘籍!轻松获取商品列表数据

tbapi

震坤行API 震坤行商品详情API 震坤行商品数据采集

中国通信工业协会城乡建设数字化专业委员会一行到访融云

融云 RongCloud

IT故障响应慢?ManageEngine卓豪助您3步实现问题管理!

ServiceDesk_Plus

ManageEngine卓豪

EMNLP 2025|vivo 等提出 DiMo-GUI:模态分治+动态聚焦,GUI 智能体推理时扩展的新范式

vivo互联网技术

人工智能 推理模型 多模态大语言模型 GUI Agent Test-time Scaling

你在用的内网穿透服务随时可能被关停?唯一方案在这里!

科技热闻

抖音家政小程序融合版:助力家政服务高效接入多平台

微擎应用市场

小程序 抖音

融云十周年程序员纪录片《十字路口》:三十而立,35+ 而已

融云 RongCloud

好用的思维导图网页版有哪些?这8个导图软件榜上有名!

职场工具箱

AI 思维导图 办公软件 思维导图软件 AI生成思维导图

实时平台Flink热更新技术——实现不停机升级!

袋鼠云数栈

flink sql

性能瓶颈定位更快更准:ARMS 持续剖析能力升级解析

阿里巴巴云原生

阿里云 云原生 Arms

京东工业商品详情API秘籍!轻松获取商品详情数据

tbapi

京东工业数据采集 京东工业商品详情API 京东工业API

真正的产品迭代,源于更好的理解用户需求

Feedalyze

产品运营 产品迭代 用户反馈 用户需求 企业发展

新华三 Polaris X20000 登顶 MLPerf Storage v2.0,ScaleFlux 助力实现高性能表现

ScaleFlux

超简单!手把手教你玩转ClaudeCode,无魔法不会员!

王磊

阿里云 Milvus 节省计划来袭:4 折抵扣按量账单,59 元起玩转向量检索!

阿里云大数据AI技术

自动化接口用例从1到1000过程中的实践和思考_文化 & 方法_有赞技术_InfoQ精选文章