关注社区帖很久了，今天分享下自己的一次接口自动化实践，给自己做过的东西做个总结。简易流程图如下：
用例怎么维护
最直接的方式就是用 excle 维护，易于操作。一个测试用例的必要内容包括：测试用例描述、接口请求方式、URL、参数、header；除了这些还有一些可选的条件：变量、用例所属模块、断言；其中变量可以理解成广义的前置处理。
不过这次我不想用这种方式维护了，用过的都知道，随着数据的增大，后期用例的维护那叫一个哎哟喂。参考了下 httprunner 的用例编写思想，直接学习了一波。yaml 维护用例看起来没文本那种直接，但是因为是 json 格式的数据，程序最爱的格式了，维护起来那叫一个得心应手，再也不担心数据类型转换带来的痛苦了。使用介绍之：
测试报告
为了更直观的看测试结果，测试报告采用页面展示的方式，采用的 vue.js 编写，展示如下：
邮件通知结果
测试结果及时通知到对应系统负责人，引入了邮件系统，主要用的 smtplib 这个库。
Jenkins 构建流水线
构建了一个简单的流水线，完成定时构建
总结
本次分享，个人觉得都很粗糙，望社区大佬轻拍，多鼓励。旨在记录成果，文字水平太有限了，想表达的东西表达了 10% 吧，其中具体的实现，下期展开。
源码下载
https://download.csdn.net/download/kairui_guxiaobai/16093517
整个实践挺完整的，不错，特别是考虑到了用例依赖这个点，对流程类用例挺有用的。提个小建议，后续这类记录除了结果，可以加入一些背景以及思考，背景便于别人了解前因，思考便于自己发现不足，下一次做的更好。
好奇问下，用 yml 这种方式，用例编写及维护体验如何？
个人感觉相比 excel ，好处是可以支持更灵活的结构，对版本管理也更友好（excel 是二进制文件，不好看出每次改动 diff），缺点是批量处理时相对没 excel 方便，然后各种缩进容易踩坑。但实际项目只用过 yml 来做配置，没试过用 yml 写用例，想了解下实际写起来感觉如何？
谢谢大佬的建议，下篇详细写下这块东西。yml 如果手写确实回踩坑，也是这么踩过来的,可以用在线 json-yml 互换工具转换一下，我们这边大部分接口参数都是 json 格式，转换成 json 写用例是不是会不要采缩进的坑了？https://www.bejson.com/validators/yaml_editor/
有个疑问，依赖用例本质上就是一个用例里面执行了多条用例，可以引入多线程从而提速 不知道理解对不对（感觉就会形成一个用例其实被执行了多次）
柒
回复
依赖用例这边是做了一个标识判断，有标识则证明这个用例有依赖，需要先执行依赖的用例，再执行本用例。这边多线程是从读取用例后，根据用例个数按照默认 10 为区间生成线程的，用例内部的依赖这个地方确实可以可以考虑引入下多线程，这个思路很好 谢谢提醒，后续思考下这块怎么加入
柒
回复
是的，我这边执行依赖用例前会判断下依赖用例的状态。失败或者跳过的依赖用例直接跳过执行， 成功的用例会重新执行。# 可以引入多线程从而提速 不知道理解对不对（感觉就会形成一个用例其实被执行了多次） 这个怎么理解呢 可以讨论下。不过想了下依赖用例执行是有顺序要求的，多线程恐怕会打乱执行顺序影响测试结果，不知道引入协程会不会有提速的效果，没实战过
柒
回复
我明白了。理论上绝对可以按照你的想法提速。不过我这个执行用例的流程，在判断依赖用例这个逻辑上是一个一个用例去判断的。在你的提示下我会这么改：把用例执行的结果和参数进行保存，有依赖的用例就不执行直接去取数据了，这样拿空间换时间吧。
团长
回复
没事，这只是我的一个疑问，之前个人自己写的只是按照顺序执行用例通过保存结果的方式，依赖的用例直接取对应数据就行，但是应该是不能用多线程的，然后你这种的话可以多线程但是一个用例里面的依赖用例会执行多次，且依赖用例也是按顺序执行，不知道是否效率上更快
柒
回复
但从效率上来说觉得会更快的，毕竟是并发执行。从我做的业务场景来看，我觉得能不能用多线程去处理依赖用例还是需要考虑业务场景吧，一个接口被调用执行多次，每次执行的结果是不同的，需要取相同的结果就只能执行一次取保存的结果了，要是需要不同的结果是可以使用多线程去提速。
柒
回复
我不太懂反射机制。我是这么实现的：首先我根据关键字找到用例中使用了自定义函数的函数名字，然后去特定的目录去找这个函数名对应的函数（自定义函数需写在这个目录下），然后执行函数函数返回结果，然后本本用例替换结果。
我用的这个函数 eval(),不过对这两个函数不是很熟悉，使用这个函数也是当时百度找到的答案吧
请问一下，作者是用 python 做的还是 java？
