本文介绍了使用robotframework进行接口自动化测试时，面对数据驱动的挑战与解决方案。作者探讨了原有的构建思路，包括三层结构的设计，并分享了在处理大量数据时遇到的问题，如teardown的不适配、上层用例参数过多以及与数据驱动理念的冲突。最后，作者选择了通过ExcelLibrary实现数据驱动，用for循环遍历数据并处理执行状态，以确保测试的连续性。
一、发生背景：
接手一个云存储项目api接口自动化，原接口自动化是java框架，由于不太擅长java，感觉比较深入了解比较费时，所以准备用python的requests模块结合unittest写一套，其他系统对接人不干了，于是退而求其次着手用robotframework构建一套，后续通过jenkins一键集成运行；
二、构建思路：
按照之前python分层框架，设计为三明治分层结构；
底层：公共方法区（我简称common关键字层）
中间：动作区链接层（我定义为action关键字层）
上层：变动颜色层（我定义为testcase层）
底层写入公共请求方法区主要定义基本请求动作，基本请求动作，类聚到所有公共方法，或者所有想要使用的字符串正则等方法，底层练气，内部核心修养；
中间夹杂的我叫做动作链接区，每个动作最好拆分成独立的，留一个进出关口给其他用例使用，例如登陆的post请求，调用底层post请求方法，定义好需要活动的变量，我写的是云项目所以我基本把创建新的镜像、对象等是要是再有共同方法的放入一个动作（前提是入参和后续用例使用该动作需要的出参一致，我就提取为一个动作，抽象的我copy一下改动入口和出口位置），中间层时候我会放入一些不变的公共参数；
例如User-Agent什么伪装浏览器之类的处理，绕过系统的识别；
上层是大家都看的见的部分，抽取所有动作然后入参相互关联，形成用例；
最低0.47元/天 解锁文章
扫一扫
2376
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
