接口和用例流程分开比较好。原因如下：

1. 实际上，大部分的接口都较为复杂，如果写在用例里面去描述会比较难于编辑
2. 接口存储时可以有一些默认参数，因此在用例描述中只需要对一些流程相关参数做修改即可（这个逻辑是双刃剑，因为会导致一些实际实施中的理解成本）
3. 接口的描述可以通过 swagger、goreply、代码扫描等方式来做统一的收集，也方便基于接口做 mock 等方案，参考 apipost、yapi 或者类似工具能力。

但实际上，要先考虑你公司的接口是属于哪种类型的接口。我认为接口测试角度来看分为两种类型的测试，1：数据型接口，2：流程型接口
所有的测试方案或者接口平台大多数做的能力是围绕这两种类型的接口测试做更深的组合来实现接口测试平台的价值和意义，所以做接口平台除了考虑接口存储外，还要看这个逻辑。

• 数据型接口更偏重于参数组合和返回结果的多样性，举例：搜索服务等，这类接口之前社区也有很多好的方案，可以研究基于 fuzz 随机测试做接口参数组合，同时定义好规则对返回值做验证。
• 流程型接口更偏重于接口与接口之间的流程参数的转换调用，偏重资源管理，举例：公有云资源服务类 API 接口和大多数据的业务流程接口 这类接口其实测试的是业务逻辑在接口调用过程中的串联组合，所以我自认为现有最合适的方案是 MBT 的方案，毕竟这个方案对整个流程的描述只要正确，生成的用例就绝对可靠，但是说实话市面上比较好用的 MBT 的工具和方案我暂时没有看到过，基于 graphwalker 的描述方案更偏重图，而不在测试流本身的描述。

你这个问题中，我认为倾向于你的接口类型是流程型接口，所以依然结论是建议把接口描述收拢在平台的一个功能中

赞~同意文中全部观点

多谢看了，也试了，由于只有一些大 response body 体会出现截断。最后发现升级到最新 27 天的 1.3.0_RC5 这个问题已经 fix，建议大家别用 1.2.0 版本。还是有一些抓包小问题。

接口返回长度长的时候，有没有遇到文本被截断的情况，怎么解决的？

python 很多 adb 库，都是封装了 adb 命令行，我倒是觉得如果是为了自动化稳定性的角度来看，要合理的使用 adb 的协议来处理才更好。否则尤其是 windows 上，手机挂上 5 台以上，会因为 adb 命令进程太多而导致各种不稳定情况出现。

其实 jmeter 的接口测试封装的思路就很好，但是那套 ui 和设计逻辑实现的太复杂、太不友好了，操作起来和设计起接口来是不够方便的。
另外，jmeter 为了通用性设计做了很多过度设计，不过整体来看，jmeter 的思路和方向都是很完美的，可能再细节上别考虑太多通用，比如 if 控制器啥的，如果都用到这个功能了，干嘛不通过代码实现呢？或者伪代码的脚本来实现。

之前有同事无意卸载了手机里面的 uiautomator.apk，最后查看了你的代码实现才发现必须要通过 python -m uiautomator2 init 重新安装才行。
这块还是注明一下吧。
另外，你报错还是要友好点，希望能把这些问题比如 http 端口没有正常映射以及发送 http 请求时候的错误做一些简单的封装。
总体来说，很好的 weditor

做接口测试的时候，代码都有模式可遵循的。其实可以把模式抽象一下，成为一个可以用尽量少代码实现的流程控制器，同时抽象数据准备、接口调用和验证提供一些通用可组合模块，然后配合上必须要写的代码（我说的刀刃上的代码，比如特殊请求或者特殊数据的构造封装等）。我有一个之前在阿里云的 OpenAPI 上实践过的体系，效率会大大提高，维护成本大大减少。
https://tech.daojia.com/post/nocodeapitest.html

感觉还只是一个框架，传递的只是一种 API 测试的基础方案。如何只写必要的代码完成 API 接口测试（无论是 HTTP 还是 Dubbo，所有的调用代码都是有迹可循的，而且所有的参数拼装代码和 assert 验证代码也都是有迹可循的），能否把代码写在必要的刀刃上，而不是大段的调用、参数设置和验证？

休假完回来的同学，可以看过来，到家服务是下一个 5~10 年的绝佳赛道。