首先要确认创建自动化平台的目的是什么？面向哪些群体？可以解决哪些问题？
目前我的理解目的有两点：一个是系统性回归验证；二是提高测试效率
面向群体：可以面向测试、开发、产品：可用于测试验证、开发调试、产品验收等
解决问题：保证系统性稳定，发现因回归策略不严谨导致的问题；提供测试效率、间接提高开发提测质量（降低开发调试门槛）、提高产品的实际验收率（降低产品验收门槛）

系统性回归测试大多是政治任务，暂且不谈，说一下效率问题：
自动化平台将接口页面化，面向不同的用户，参数的默认值一般是没有的，参数多达 10 多个 20 个的时候，因为要多次使用，用起来就会很麻烦。
场景一：如果是一般性接口（不涉及接口签名和加密）暂无代码基础的人，测试人员在 postman 上大多都会整理好的接口，并保存有一套测试数据，每次请求只要改一下关心的参数即可，每次不用逐一填写。

场景二：如果是涉及到签名和加密的，因为每次签名数据不一致，这时候用 postman 就没有那么便捷，暂无代码基础的人这时就会使用自动化平台完成测试，但是每次（至少是首次）打开页面都要逐一填写参数，使用起来不够便捷，也不利于开发调试、产品验收；而有代码能力的人一般都会自己开发，自己维护一套测试数据，使用时也是只修改关心参数即可。

总的来说，如果用户使用自动化平台，效率没有明显提高或没有为使用者提供便利，一般使用率都不高。

我司今年也搞了一个自动化平台，因政治任务需要对部分接口添加用例，完成用例定时自动执行。因自动化平台对请求参数格式做了规定，然后为了添加用例，我需要另外写了一段代码来获取到自动化平台规定的请求格式，才能添加用例。而费时费力添加的用例也是之前在上线前不会去验证的东西，这里也不是说不该去回归验证这些功能，是考虑到自动化用例维护的投入产出比。

我理解的自动化平台设计原型，尽可能还原 * 原本接口的功能，如果对原接口有做封装，因尽量减少对原接口的影响，同时提供某种便利（比如可以将请求格式定义为 josn、可以隐藏签名和加密、其他参数的整合关联等）。

设计可以分两块：一模块用于用户系统功能性回归，二模块用于测试过程中数据构造。
一、系统性回归测试，由相关测试人员负责添加用例，需要对测试数据做合理的拆分，数据和账号的解耦，保障同一接口的数据可以应对测试环境和生产环境的不同账号
二、测试数据构造，对接口参数设定默认值，尽可能减少不必要参数输入，传入关键/关心的参数（进行覆盖），即可进行请求，一键请求，可以方便测试验证功能、开发进行调试、产品进行验收。根据业务需求针对高频操作的业务场景再做封装（上下依赖接口一起执行）等
同时备以详细的日志，展示请求接口的真实数据和接口返回的原始响应等。

代码和用例分离，请求体可以通过字段 + 参数的组合方式，方便灵活拼接。
用例存放在本地数据库，由例标题、主要参数的值、预期值等组成，非紧要参数可以直接放在代码中或直接作为某个字段的值。
对 response 验证，除接口返回值外，还有对数据库验证。