1、校验
这个很好了解，如果没有校验，单纯的执行接口的话，那就谈不上测试了。所以支持对返回值校验是一个必须的功能。
2、数据隔离
数据隔离就是指具体的请求接口、参数、校验等数据做到与代码相隔离，便于维护，一旦需要调整接口用例、新增接口用例时可很快速的找到位置，隔离的另一个好处就是可复用，框架可以推广给其他团队，使用者可以使用相同的代码，只需要根据要求填写各自用例即可测试起来。
3、数据传递
做到数据隔离可维护后，数据传递是另外一个更重要的需求。
数据传递是指接口用例之间可以做到向下传参，例如我们通过创建订单接口创建一个订单，该接口会返回一个订单号，接下来我们要进行调用查询订单的接口，从返回的数据中与创建订单用例中的数据进行校验，此时第二个接口的请求数据是需要从第一个接口用例中的返回中提取的。这样的例子比比皆是，所以支持数据传递是又一个必不可少的功能。
4、动态函数
实际用例场景中我们可能会有随机生成一个手机号、字符串加密等需求，在数据与代码隔离之后，此时我们就需要代码可以支持做到识别对应关键字时可以执行对应的函数进行填充。例如在数据中填写phone()时，具体执行时会被替换成137XXXXXXXX，填写random(5)时，会被替换成一个五位的随机数。等等。
5、可配置
有时，我们的需求是用例不单单只能在一个环境上执行，可能需要同一份接口用例可以在QA、预发、线上等多个环境都可以执行。所以框架需要做到可配置，便于切换，调用不同的配置文件可以在不同的环境执行。
6、日志
日志包含执行的具体执行接口、请求方式、请求参数、返回值、校验接口、请求时间、耗时等关键信息，日志的好处一来是可以便于在新增用例有问题时快速定位出哪里填写有问题，二来是发现bug时方便向开发反馈提供数据，开发可以从触发时间以及参数等信息快速定位到问题所在。
7、可视化报告
用例执行后，就是到了向团队展示结果的时候了，一个可视化的报告可以便于团队成员了解到每次自动化接口用例执行的成功数、失败数等数据。
8、用例驱动
1.用例的驱动模式，涉及到怎么存放测试数据，怎么描述用例，又如何复用；
2.考虑到效率的话还要支持并发；
3.当然测试报告不能光记录成功和失败，还有用例执行耗时，接口调用耗时，、场景的通过率等各项数值的统计。
9、数据隔离
1.用例是否能复用应该跟用例的设计有关系，跟框架关系不是很大。
2.并发的话在接口自动化方面倒不是必须的，当然有是更完美的。
3.报告确实是越强大越好，有老板关心的数据，有开发关心的数据是最好不过了。
