周一弄个网盘共享给你

已发。

可以呀 目前就一个 demo 需要加微 我发你

可以 18570602290

https://www.cnblogs.com/yoyoketang/p/7259993.html 入门可以看看这个，可以启发下自动化架构思想;有了大概的思路，然后可以学习优秀成熟的框，比如：HttpRunner；先学会使用，在边使用边学习学习然后消化它。

请假回家一周，刚看到消息，我用的 python

不客气，应该谢谢平台给了讨论学习的机会，多讨论还是会有更多的想法

我用的这个函数 eval(),不过对这两个函数不是很熟悉，使用这个函数也是当时百度找到的答案吧

我不太懂反射机制。我是这么实现的：首先我根据关键字找到用例中使用了自定义函数的函数名字，然后去特定的目录去找这个函数名对应的函数（自定义函数需写在这个目录下），然后执行函数函数返回结果，然后本本用例替换结果。

但从效率上来说觉得会更快的，毕竟是并发执行。从我做的业务场景来看，我觉得能不能用多线程去处理依赖用例还是需要考虑业务场景吧，一个接口被调用执行多次，每次执行的结果是不同的，需要取相同的结果就只能执行一次取保存的结果了，要是需要不同的结果是可以使用多线程去提速。

我明白了。理论上绝对可以按照你的想法提速。不过我这个执行用例的流程，在判断依赖用例这个逻辑上是一个一个用例去判断的。在你的提示下我会这么改：把用例执行的结果和参数进行保存，有依赖的用例就不执行直接去取数据了，这样拿空间换时间吧。

是的，我这边执行依赖用例前会判断下依赖用例的状态。失败或者跳过的依赖用例直接跳过执行， 成功的用例会重新执行。# 可以引入多线程从而提速 不知道理解对不对（感觉就会形成一个用例其实被执行了多次） 这个怎么理解呢 可以讨论下。不过想了下依赖用例执行是有顺序要求的，多线程恐怕会打乱执行顺序影响测试结果，不知道引入协程会不会有提速的效果，没实战过

依赖用例这边是做了一个标识判断，有标识则证明这个用例有依赖，需要先执行依赖的用例，再执行本用例。这边多线程是从读取用例后，根据用例个数按照默认 10 为区间生成线程的，用例内部的依赖这个地方确实可以可以考虑引入下多线程，这个思路很好 谢谢提醒，后续思考下这块怎么加入

谢谢大佬的建议，下篇详细写下这块东西。yml 如果手写确实回踩坑，也是这么踩过来的,可以用在线 json-yml 互换工具转换一下，我们这边大部分接口参数都是 json 格式，转换成 json 写用例是不是会不要采缩进的坑了？https://www.bejson.com/validators/yaml_editor/