背景：新公司的新部门，刚经历组织架构调整，几块业务线拆分组合起来的部门。老大让我负责接口自动化这块，目标是需要一套接口脚本适配多岛端环境（测试、预发、真线、以及部分地区有个性化差异）
现状：初期统计了下几块业务的现状数据，参差较大，很多是没开始做接口；其次，部门业务链路长，上下游关系复杂；目前的技术栈是用 testNG 和 jmeter 结合使用的
问题：想着除了接口覆盖率提升外，核心是要适配多环境。所以求助，在适配过程中，除了改造 url 外，对于接口入参数据如何改造？（测试环境有的数据 可能预发/真线没有 所以肯定是要动态去构造 ）
现在没啥思路，求各位大神指点一二。
你上面提的，我理解已经挺全了。大部分情况下，不同环境的核心差异是 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，地区.
- 根据前端筛选（环境，端，地区）很容就从数据库查出数据了。
- 然后把查出来的这一批数据放入执行队列里执行。
October
回复
如果 2 开，确实要选技术，只是用只要好用就 OK 。选型的话，不二开和技术无关，只和能不能解决需求有关，别急，我们新版就会出来
前后端，这些都不是事，，也不是什么高深技术，坐等新版
loadrunner 10 年前的技术了，现在不一样有人用得欢吗
阿根
回复
还吊打 pm ??好自大，哪个平台不能接口集成 .https://testerhome.com/topics/30495 我这里写得清清楚楚，自己看。不要动不动上来喊口号。各个工具都有各个优势，都可以讲出来，动不动一句话，喊口号，不知是什么心太 。我这所以回贴是因为你说的 MS ，太牛 B 了，天下无敌，我有必要让别人知道还有别选择。
