事情是这样的，之前做过一版接口自动化测试平台，大致流程就是前端收集 http 信息，后端使用拼装 http 后发送。因为后端使用的是 Python，所以使用 requests 库来解决。但是过程当中发现了很多请求体的数据结构的问题，有的请求需要使用 json 格式，有的需要纯字符串，json 中 dict 的嵌套等等。也导致使用人员降低了对平台调试接口的期望，依然使用 postman 来做预先的接口调试。请问除了不断去优化拼装逻辑外还有没有什么其他的解决方案？在 py 库里面看到了一个 postpy2 的 postman 兼容 Python 的库，但是这个库依然需要先将请求内容组装成一个 postman 的 collection 文件之后才能运行，而且运行的结果获取和效率还没有经过实验，这种方式可行吗？
看起来，像是你平台前端设计相关的问题？request 库基本可以发送 postman 能发的 http 请求内容的，库的能力上应该没问题。
然后接口调试不用这个平台而是用 postman ，现阶段会有什么问题呢？没太理解。调试本身就不是自动化测试，用别的工具也不阻碍用平台做自动化测试吧。
陈恒捷
回复
恩，设计上肯定有问题，但是问题始终不是很明确，是以我对 http 的理解上去做的。导致的问题就是他们在 postman 发送的请求和平台上发送的结果不一致。我是怀疑 postman 做了很多请求的优化工作，所以想是否能直接使用 postman 的库来做 Python 端的发送模块，这样只要在 postman 上面调试好了与平台就能够保持一致了。
Karaser
回复
我是怀疑 postman 做了很多请求的优化工作
不要凭感觉做事。。。你配置个 proxy ，抓下包对比下，不就知道差别是啥了么？然后 request 里面适配下就好了。个人经验，大部分情况下，问题都出现在大家基本都不怎么配置的 http header 里。
让我们换个思路，能否推动所有测试接口对 json 的兼容
在 py 库里面看到了一个 postpy2 的 postman 兼容 Python 的库，但是这个库依然需要先将请求内容组装成一个 postman 的 collection 文件之后才能运行，而且运行的结果获取和效率还没有经过实验，这种方式可行吗？
必须可以啊，前提是你做的前端界面也没问题。这就相当于脱壳的 postman 换成你给做的壳。
所有的接口测试平台 最后都会凉凉.
这边理解的是，主要是 http 不同的请求数据类型处理问题？