自动化工具 接口自动化如何能有效的构建和管理测试数据?

cooker · 2019年12月24日 · 最后由 Vanessa 回复于 2019年12月25日 · 1074 次阅读

最近在做接口测试自动化,遇到一个问题,就是某些系统业务逻辑复杂,依赖性较强,接口之间存在数据依赖(例如上一步的接口产生了某些数据,可能通过响应返回,也可能存在数据库中),另外涉及创建等接口数据需要一直更新,不然就用不了。主要有如下问题:
1、测试数据如何构造更有效:业务依赖强,通过流程性一步步构建数据链条太长,且效率应该不高;通过数据库直接构造,数据库表和业务的逻辑关系确实也复杂,完全梳理清楚有不小的工作量。(目前使用比较简单的 testng 数据驱动,但用例多了之后,测试数据维护在 excel 就不太方便了,另外目前系统整体的数据字典其实是不清晰的,或者说是没有维护的。)
2、如果能通过上述 1 构造测试数据,如何能和自动化用例形成有效的关联,数据和用例能一一对应上?我的理解是需要有一个中间环节,管理用例 - 触发数据构造 - 保证数据和用例之间的关联,这样整体的复杂度就上升了一个层次。
综上,请教各位大佬是否有比较好的实践或者建议,构造复杂业务下的接口自动化?谢谢。

共收到 4 条回复 时间 点赞

“通过数据库直接构造” 不可取。
最好还是走流程生成,哪怕效率低一点。
提取关键流程接口,封装关键字或者方法,用例驱动部分把所有预处理操作放入 before 中。数据部分把每个用例分为预处理包含的数据和当前用例包含的数据。
另外,再复杂的接口能慢到哪儿去。。。对于慢的查询类或者有第三方的,mock 大法祭出来

用例多了,按类整理或者流程整理呀。都放一起能不乱吗...

数据都搞不清楚怎么去下手呢,从一个个小的功能入手,把每个功能的数据都抓出来整理,这些事情还是要做,不然其他都是空谈,不想用重新生成的方式。你就要一点点去把生成的过程弄清楚

脱离场景只对接口做自动化,虽然很省事,但是用例维护后期起来很麻烦。二个是在数据库构造数据就要在用例里写 sql,表结构一变化脚本大概率就要 gg。我曾经 2000 多个用例因为表结构变化全部 gg,写了个处理字符串的方法把多的字段剔除,少的补上,但我的用例全部是基于构造数据的 sql 设计的,sql 都变了用例可靠性还有多少,无法再维护。
失败的经验一大堆,总结起来就一句话,产品如果不配做自动化咋样都做不起来。

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册