现在只做到没有依赖的情况 可以数据驱动，要是业务有依赖就要编码了

嗯嗯，看来目前这样实现是不太可能，只能依据目前的结构进行了

根据你业务来 最好配置单独环境 数据全部自己造 接口全业务流

嗯嗯，可能自己各方面不是太成熟，慢慢再摸索下

cookie 可以找找有没有全局管理的方法。偶尔报错，应该是有些参数写死了，和开发确认下哪些是动态生成，需要从哪接口获取，然后保证接口执行顺序，做个参数化传递。

虽然不怎么理解，但是我认为，确实是自己写的脚本本身的质量问题，看，昨天还好的，今天又挂了，又得分析，解决，，，

无状态？？不太理解

嗯嗯，真的很头疼，明明昨天正常的，今天一跑，就挂，就是很疑惑，明明都没有问题

自动化测试从设计开始，就应该先追求无状态。

setup 和 teardown 这两个环节了解下, 个人觉得接口测试的质量是在这两个部分,设计的好坏直接关系到用例的强壮型.

如果是接口依赖跑不通，说明是你上个接口断言没做好，断言不充分。java testng 相互依赖的接口是可以配置依赖关系的，python 的不清楚

好吧，我再想下怎么设计用例吧

我这边接口自动化已经跑了 2 个月了 基本很少出现 bug

哦哦，好吧。谢啦

嗯嗯，有业务相关，就是不能稳定跑，各种问题。。我也就是发发牢骚，谢啦各位

如果是业务相关的，依赖基本上是跑不掉吧？
我这边的接口三四层依赖的都有呢，但是能稳定地跑就行了啊，你做自动化的目的不就是为了稳定回归么

啊，直接跑就行啊，用的 robotframework，传参可以是自己生成的也可以从数据库里读取，没有什么依赖性的问题啊

接口自动化，你这边是一跑就可以？可能是我用例设计得问题吧，我再研究研究。例子我想了下，具体得我还真不太好举出来，各种情况导致得 case 失败吧，主要是依赖性接口得问题。既然你这边没有遇到过，那就算了，我也就是发个牢骚。

测试环境跑的话生成 cookie 有什么浪费的，大不了清 redis 缓存呗，或者让开发把请求 cookie 限制去掉。不明白接口自动化有什么健壮性可言，建议你举个具体的例子让我们看看究竟不稳定在哪块，是不是你的设计用例有问题

比如说，是有有效期得问题：存在依赖关系得接口，比如登录吧生成一个 cookie，总不能让实时生成就太浪费了；这只是一个例子，而且大多数比这个复杂

主要是输入参数有依赖性，输出参数也不太稳定了

比如说，是有有效期得问题：存在依赖关系得接口，比如登录吧生成一个 cookie，总不能让实时生成就太浪费了；这只是一个例子，而且大多数比这个复杂

全蛋啊，我真的没有答案，马赛克是不想信息泄露被公司哪个看到了就不太好了，求指点

参数不稳定 -- 是输入参数不稳定，还是输出参数不稳定？

数据恢复啊

楼主你心里已经有答案了，何必来问，来问又何必打这么多马赛克