1. 你们 token 不会自动延长有效时间吗？也就是说如果有请求把这个 token 带过来，就会把它的有效时间重置为默认时间（一般都是 30 分钟）？ 这样如果你的用例都是一直正常在跑，除非有些用例等待时间超过了三十分钟（这样的话要考虑换成异步处理），否则不应该出现超时的问题。
2. 用例过多，可以考虑 pytest 的插件改造成并发运行，提高执行效率。

这是一个常见的问题，不知大家有什么比较好的解决方法

最简单的方法：让开发将 token 有效时间延长。

把登录写成类方法，每执行一个测试类 就执行一次登录接口，获取 token

token 的过期时间，体现在业务层面就是：

1. 如果我已经离开，或者结束操作了，会不会在一个安全的时间内，把我的 token 给失效了，以防止有人盗用？
2. 如果我一直在操作，或者没有退出并且距离上次操作的时间不那么久，会不会 token 失效导致我需要重新登录，打断我的操作体验？

所以这两个场景是相关联的，既要保证有效时间内继续保活，也要保证超过有效时间之后能正确失效。

按楼主的例子，如果你的用例一直在执行，等同于客户一直在操作，那么到了后面突然失效了，就是没有保障到第二点，就有可能是 bug 了。

1、找开发延长，或者整个不过期的 token
2、问开发过期时间，然后写个过期后重新获取 token 的方法

你们这 token 时效是有多短？用例没跑完就过期了
有两种办法
1、在脚本里随时获取最新的 token
2、 找开发，让给一个超长时间的 token

同意 5 楼的说法，你平常使用你们系统的时候也是用着用着就要登陆吗？ 还是你传入 token 的方式与实际不一致呢？

我在 beforeclass 都获取一次

定时获取最新的 token;
每次执行用例前获取一次 token

可以在获取完 token 后将 token 写入.env 文件，并在获取 token 的时候加入重试机制，token 过期时从接口重新获取否则直接从.env 文件取

可以根据具体的 token 过期规则写一个方法获取 token，可以访问数据库的话可以直接从数据库获取或者请求登陆 API 获取，每次执行前通过这个方法获取 token

如果一直在用，token 为啥会过期（正常如果用户一直在操作，你给我过期，那不是直接重定向到登录了，这明显不符合正常操作流程），我觉得 5 楼说的就挺符合了

5 楼说的是一个值得关注的点，还有可能就是自动化执行期间，用户被被人登录了，造成自动化获取的 token 失效

除了上述所说方法外，还可以在捕获到未登录的异常时进行一次登录接口调用

没错，我们的自动化其实就都遇到过，有些是账号配置有问题，跑着跑着被其他 job 给踢了；另一种情况也遇到过，就是某些接口其实没有做 token 的刷新，导致有效时间没有重置，也就发现了某些 bug