具体是这样的：我用 pytest+allure 编写接口测试，pytest 用例的执行顺序默认按照用例的编写顺序，但生成的 allure 报告中的用例展示顺序是按用例名称顺序展示的，并不是用例的执行顺序，为此，我在写用例的时候只能在用例名称上加上编号，例如"test_A1a1_login"、"test_A1a2_stulist"这种，但后期维护中发现了问题，比如我想在两条用例中新增新的用例，那么这个命名就很别扭了，所以我想有没有既不改动太多原 case 的情况下 (因为我搜了很多资料，有的建议再原 case 中增加各种装饰器啥的，但这样就会让 case 变得杂乱、不纯粹) 还能解决 allure 报告展示顺序的问题。
我查了很多，GPT 也是时靠谱时不靠谱，实践后都没成功，希望佬儿哥们指点一下。
这个问题被解决了！定义两个用于生成编号的生成器
具体是这样的：在此之前为了 allure 报告的展示顺序，我是在编写 case 的同时手动添加的编号，这样就会导致在编写 case 时费时费力，在后期维护过程中也不能很好的解决在用例中间插入新用例的编号如何选取的问题。为此，经过不断地实践，确定了目前的方案：定义两个用于生成编号的生成器函数，一个是用于不同测试板块的编号"module_id()"，另一个是用于生成各个测试用例的编号"case_id()"，然后在测试用例中，在 allure.feature() 中添加测试板块编号，在 allure.story() 中添加测试用例编号，去除之前版本中的@allure.title() 和测试用例中的编号 (意义不大，那就能省则省。直接上图，直观些：
原测试用例如下：
升级后用例如下：
升级后 allure 测试报告如下
从以上描述可以看出我们即优化了测试用例的编写，又控制住了 allure 报告中的用例展示顺序。
当然，如果有佬儿哥佬儿姐有更好的解决方案，还希望可以多多指点。
题外话：此前有关注过我的小伙伴可能知道我将接口自动化的搭建过程总结过两篇文章，将从 0 摸索的过程详细的记录了下来，这本就是一个有趣的不断发现问题，解决问题的过程，距上次升级，又有了一些沉淀，我打算将此次更新过程再总结发布出来，此次升级大致的内容如下：
1.升级测试模块和测试用例的编号形式 (如上)；
2.解决接口依赖情况下依赖参数如何做数据驱动的问题；
3.解决各个用例中部分内容重复编写的问题，例如每个用例中都会写 allure 报告信息收集的代码、接口响应时间和 status_code == 200 的断言语句。最终效果是同一用例由原 18 行缩减至 10 行，同样的测试脚本由原 3600 行缩减至 2800 行。
4.增加对接口返回数据的数据类型断言功能；
除此之外还有一些测试脚本的目录优化等内容，如果感兴趣的伙伴可以关注一下。在自我总结之余，我更希望的也是可以收到小伙伴们的各种指导意见，下次见~
你的 pytest 框架需要标记上执行顺序
@pytest.mark.run(order=1)
这样子 allure 就会按照这个 order 对结果进行排序了
刚试了一下，我这边用 order 是可以让用例按照运行顺序排序的
ZW
回复
我用例中添加了 feature 和 story，我希望 allure 的报告中也先按照用例定义的 feature 顺序排序，然后同一 feature 下按照用例定义的 story 顺序排序，目前使用 order 只能让最里层的用例 (#1、#2 这些) 顺序排序，至于 feature 和 story 还是乱的。我贴张图可能会清楚些：
杨腾
回复
如果在 order 中手动编序号那我感觉和我直接在用例名称里添加序号无异了，后续维护时在用例中间添加新用例的话这个 order 是不是还需要重排
这个问题被解决了！定义两个用于生成编号的生成器
具体是这样的：在此之前为了 allure 报告的展示顺序，我是在编写 case 的同时手动添加的编号，这样就会导致在编写 case 时费时费力，在后期维护过程中也不能很好的解决在用例中间插入新用例的编号如何选取的问题。为此，经过不断地实践，确定了目前的方案：定义两个用于生成编号的生成器函数，一个是用于不同测试板块的编号"module_id()"，另一个是用于生成各个测试用例的编号"case_id()"，然后在测试用例中，在 allure.feature() 中添加测试板块编号，在 allure.story() 中添加测试用例编号，去除之前版本中的@allure.title() 和测试用例中的编号 (意义不大，那就能省则省。直接上图，直观些：
原测试用例如下：
升级后用例如下：
升级后 allure 测试报告如下
从以上描述可以看出我们即优化了测试用例的编写，又控制住了 allure 报告中的用例展示顺序。
当然，如果有佬儿哥佬儿姐有更好的解决方案，还希望可以多多指点。
题外话：此前有关注过我的小伙伴可能知道我将接口自动化的搭建过程总结过两篇文章，将从 0 摸索的过程详细的记录了下来，这本就是一个有趣的不断发现问题，解决问题的过程，距上次升级，又有了一些沉淀，我打算将此次更新过程再总结发布出来，此次升级大致的内容如下：
1.升级测试模块和测试用例的编号形式 (如上)；
2.解决接口依赖情况下依赖参数如何做数据驱动的问题；
3.解决各个用例中部分内容重复编写的问题，例如每个用例中都会写 allure 报告信息收集的代码、接口响应时间和 status_code == 200 的断言语句。最终效果是同一用例由原 18 行缩减至 10 行，同样的测试脚本由原 3600 行缩减至 2800 行。
4.增加对接口返回数据的数据类型断言功能；
除此之外还有一些测试脚本的目录优化等内容，如果感兴趣的伙伴可以关注一下。在自我总结之余，我更希望的也是可以收到小伙伴们的各种指导意见，下次见~
好认真，写了那么多。后面我一定回来看贴学习