一套接口自动化代码如何适配测试环境

陈恒捷 9
2022-08-29 21:11:30 未知地区 1F
回复

你上面提的，我理解已经挺全了。大部分情况下，不同环境的核心差异是 url 不同、数据不同，以及少量的被测系统逻辑差异（一般是被测系统配置项差异带来的）。

url 这个，抽离到环境配置文件里就好。
数据不同这个，如果可以重复用，就也抽离到环境配置；如果不能重复用，那就补充每个环境从零进行数据构造的逻辑，到用例的 setUp 里面。
被测系统配置项不同引发的差异（比如某些逻辑开关可能会有差异），这块就不建议脚本去适配了，直接弄个单独的检查脚本，让测试执行前，检查确认这些被测系统配置项尽可能一致就好。把不同点抽取出来单独配置就行。

另外，线上环境不建议搞自动化测试，要弄也要有完善的经过测试的 teardown。。。把相同的部分梳理提取出来，找到共性1.相同部分的写到配置文件里，比如各种 url
2.不同的部分写到具体的测试用例脚本里，
String org = “”;
if (环境1 ){
org = “a”;
}
if (环境2 ){
org = “b”;
}
if (环境3){
org = “c”;
}

简单粗暴直观好用主要是 baseurl，数据库配置、基础数据 (登录用户、产品信息等)，要实现可配置、参数化简单来说就是要找到代码的可移植性，我们这边一般都是做好初始化。这样初始化就分两种情况了，第一种初始化的数据是系统必带的，那就相当于每个环境都是一致。如果初始化数据没有就考虑到造数~，从 0 到有构建一套所需的测试环境太赞了用 metersphere 啊，我现在还没发现比 ms 更好的接口平台和方案，腾讯自己搞的那个都没 ms 好。用 itest 呀 看看这就明白 itest 的创新 https://testerhome.com/topics/30495
MS 没一点创新 不如用 postman ，起步 4C8G ，，itest 1c2g 就够 这个逻辑比较简单，对于一个开发来说最多不超过两天就能干完，剩下的体力活是往数据库里填数据。

不需要高并发，不需要稳定性，不需要大数据，也不需要实时数仓，也不需要缓存，mq，各种逻辑复杂的设计，实现起来就三层架构和实体关系设计就行。

首先要思考你这个东西怎么用，就像产品一样先得有个初略的 PRD。
自己随便在纸上画画或写写提纲，这个是指导你写任何代码（产品，框架，工具和测试代码）的出发点。
当然，在往左移就是业务需求（测试需求）。
想清楚怎么用，比如有个界面：

可根据筛选条件查询接口列表
根据筛选条件和选中的接口执行用例。
查看用例执行结果。

这样就可以抽象出来几个实体：

接口：你也可以拆的再细一点，接口是一个实体，接口实例是另一个实体（包含属性环境，端，url，地区等）
环境：包含（类型线上/线下/预发/预发多套/项目，机器，分组等）
终端：终端类型，名称等
地区：城市，区域等。
结果：接口，接口实例 ID，关联用例，用例执行结果（成功/失败）

然后识别出实体之间的关系：

接口环境多对多。
接口终端多对多。
接口地区多对多。
接口和结果多对多。

然后设计你的表结构：
（可能还需要配置也，配置接口在不同条件下的具体参数）

然后根据筛选项去设计你的逻辑：

比如一个接口实例包含：环境，端，url，地区.
根据前端筛选（环境，端，地区）很容就从数据库查出数据了。
然后把查出来的这一批数据放入执行队列里执行。
技术有点老，性能不够高；建议用 spring boot 微服务，前后端分离部署ms 很好解决了接口测试集成的痛点，这个就吊打 pm 了，你们那个我还真没看出解决了什么痛点，你不妨说说如果 2 开，确实要选技术，只是用只要好用就 OK 。选型的话，不二开和技术无关，只和能不能解决需求有关，别急，我们新版就会出来
前后端，这些都不是事，，也不是什么高深技术，坐等新版
loadrunner 10 年前的技术了，现在不一样有人用得欢吗还吊打 pm ??好自大，哪个平台不能接口集成 .https://testerhome.com/topics/30495 我这里写得清清楚楚，自己看。不要动不动上来喊口号。各个工具都有各个优势，都可以讲出来，动不动一句话，喊口号，不知是什么心太 。我这所以回贴是因为你说的 MS ，太牛 B 了，天下无敌，我有必要让别人知道还有别选择。期待新版 itest