接口测试框架的形成过程

流水账式的接口测试脚本

在编写不少流水账式的接口测试脚本后,发现其中存在大量重复的代码
思考:能不能把公共的操作单独抽离出来,抽象到一个common文件中,在其他文件继承或导入文件进行使用

  • 如何区分哪些是公共的部分?
    一般哪些是公共部分?
    公共部分与非公共部分的边界是什么?

提供common文件的通用性

如不写死测试系统,通过传入参数指定测试系统

加入测试报告

加入测试报告模块,把测试结果储存在测试报告当中,而是都使用print打印

加入测试驱动框架

加入unittest或pytest测试驱动框架来驱动各个模块,更好地组织测试脚本

加入日志

为了更好地定位和分析问题,加入日志模块

加入断言

针对复杂断言,引入jsonpath断言、Xml断言、Xpath断言、hamcrest断⾔、Json schema校验

引入POM

为了更好地区分业务操作,方便脚本维护,引入POM

引入参数化

利用无人值守时间,节省时间。
自动验证返回结果,提高效率。

  • 读取数据库的数据

  • 读取文件数据

引入持续集成

为了CI/CA集成,引入持续集成模块

......

不要把测试框架看得太高大上了,不是只有像selenium、appium、httprunner才叫测试框架,你可以从一个简单地测试框架开始做起。

测试框架是在编写大量测试脚本地过程中不断抽象封装出来地,然后不断完善,是一个循环往复地过程。

原文地址:https://www.cnblogs.com/Uni-Hoang/p/14051872.html