接口测试 关于小白对数据驱动的一点疑惑，望各位大佬解答一下
最近在做接口自动化时遇到了一些问题，例如某个接口的请求体大概如下：
{
"id": 10086,
"name": "auto_test_upstream",
"node": [
{
"ip": "1.1.1.1",
"type": "pod",
"unit":"service1"
}
],
"healthcheck":"false"
}
根据用例的不同，也可以是这样:
{
"id": 10086,
"name": "auto_test_upstream",
"node": [
{
"ip": "1.1.1.1",
"type": "VM",
"name":"myhost"
}
],
"healthcheck":"false"
}
{
"id": 10086,
"name": "auto_test_upstream",
"node": [
{
"ip": "1.1.1.1",
"type": "VM",
"name":"myhost"
}
],
"healthcheck":{
"successCode":"200",
"successFrequency":"10",
}
}
我的疑问就是，在请求参数会根据你的选择动态变化的时候，怎么做数据驱动？
动态变化也只是路径分支，可以在请求前对 type 做下判断，然后针对 name 和 unit 不同的请求方式或者处理方式。healthcheck 也是同理，false 直接接收，true 或非 false 时获取字典类型的值，数据接收方式的区别。
就用不同的 json 当数据驱动
不同的请求参数对应着不同的用例，那么可以配置多个 JSON 数据，但这种类似于 “写死” 的数据，不是特别灵活；那么，请求参数为什么会变化，了解变化规则，就可以动态生成参数，相对灵活一些。希望对你有所帮助。
做数据驱动与"请求参数会根据你的选择动态变化"无关
"请求参数会根据你的选择动态变化"，虽不清楚你想表达的意思，但还是认为跟数据驱动无关。
你最好先解释下这句话，这种情况具体怎么影响到你做数据驱动了呢？
对
青熬芒果
回复
青熬芒果
回复
一个是重在输入前，一个重在输入后，如题例其实是接口脚本对数据的接收处理，而数据驱动则是在脚本完备后构造多种场景数据参数来对多路径进行验证，分界点是参数化后。个人浅见
变化的参数都是对应不同的业务场景，可以提取出来业务字段给参数化。
将通用内容存到模板，基于参数化字段结合模板生成 xx 业务场景的请求报文。希望这篇文章能帮到你，https://mp.weixin.qq.com/s/UQTdRL4rYKVwgyCbggk_gA
