codeToId 觉得可以尝试，之前接口就是我写她们用的模式，所以更注重用例入参设计的简单性，虽然内部是做了转换的，但是这部分通用没有抽去出来。

后面这个我大致理解了，会找个例子去实践一下，感谢~

第一点，之前在另一个项目中试写过几个功能的接口测试用例给她们的测试使用，形式是她们给出要测试的业务流程和基本数据，我来实现，她们的诉求是造数据能不能只给出看到 code 值（页面上实际展示的编码），id 界面上看不到，也不知道是什么，所以采取的方式是我会通过编码先调用查询接口，查出后面操作需要的一些字段值再进行后续的操作。所以管理 id 不是很适用于我们现在的测试，大程度是管理不起来的。

到后面有需要那就把配置项改为不是人写上去，而是程序自动生成和记录即可。

但是我对这个 id 值或是一些非目标测试项，但是需要传入的值自动生成和记录这一点，觉得很棒，能问下你这边指的思路也是通过调用接口去生成吗？但是抽取出来？是之前没有想到过的一点，可能更局限于某个接口需要，而忽略了通用性，是抽取出来类似通用组件去使用吗？

这个是老系统持续重构的常见问题，严格不是技术问题，而是取舍。最低成本当然是统一架构后再直接基于新架构写接口用例，但这样价值也最低，因为重构过程中用不上。如果重构也希望有自动化协助，那就要增加成本（新老架构各写一套用例）。

关于这一点，上面提到过的，现在的开发测试比有一点高，个人角度是非常想把 api 自动化这块做起来的，但是在需要保证正常功能测试迭代之外可以自由分配的时间中，无法实时跟进项目迭代开发的产出速度，所以能付出的成本是将已经翻新的部分从优先级高到底来实现接口自动化，在架构切换中我认为还是相对有效果的，因为在业务层也随之做了一些升级，那么新产出的一个代码，并且需要持续更新几个迭代甚至更久，还是有很多可预料的问题的。

至于接口调用实际使用协议的差异，其实本质上所有协议都是数据传输加接收。框架设计得好数据应该是抽象的模型（比如 model 层），具体协议可以直接基于模型写生成方法（如 json、xml、yaml 等），请求发送也是类似，统一命名为 send 方法，使用者只需要用这个方法即可。至于实际用的是 http 还是别的协议，由负责维护这个接口的同学写具体实现即可。我理解并不是不能做，而是这么做框架设计会变得复杂一些，所以需要像上面说的，衡量投入产出比。

关于最后一点，“其实本质上所有协议都是数据传输加接收” 这一点我时间认同的，有两点疑问，一个是抽象出来的 model 是包括了 url、header，请求内容和期望的吗？现在只是基于 testng 将请求内容和期望外加描述信息做了一个抽取，请求的 url 是单独的一个配置，能具体描述下 model 的全貌吗？另外，你这边指的 send 方法类似于 httpClient 中的 execute 这种感觉吗？

关于第一点我完全赞同，所以本身也认为不是一个很好的方式，也尝试过 dump 数据库重置的操作，只有我一个人一个数据库时还能相对好的隔离操作，但是一旦想要其他人介入，那么数据隔离设计上会比较繁琐，因为不一定能在使用时很好的用约定来约束数据隔离。
关于第二点，其实也不算是手工测试要使用，只是现在我们一个大的产品线是按照功能模块再次分组的，那么我的理解是一个产品一个接口测试项目的，然后功能模块按照包区分，那么最终在未到合并主干回归的场景时，是会需要分模块自己执行下各自模块的 api 接口测试用例，因为相对已经投入使用的 gui 是这样的，当然 api 的执行效率要比较 gui 高的多，但是假设在 api 的不断累积后，这个在我们公司这个产品是一个比较明朗的需求，所以会想要前置的设计好解决办法，如果是每次都执行一次所有的接口测试用例的话，那么 dump 的可行性会稍微高那么一点。

dump 数据库的问题是在于这种场景：
最终接口测试用例的组织形式不会是每次所有的都走一遍，因为针对不同测试阶段可能会需要选择业务模块等，然后执行部分测试用例，或者是错误重试、调试等等。那么就可能存在 A 同学和 B 同学同时都要执行模块 01 的用例，或者是 A 同学和 B 同学需要分别执行模块 01 和模块 02，那么我理解数据库将之前 dump 出来的数据再重置的时间节点在开始执行接口测试用例之前，或者是执行完成接口测试用例之后，那么如果接口用例还在执行的时候，数据触发了重置，那么肯定会对结果产生影响。因为现在是整个数据库重置，那么可能后面的的一个接口 api01 是更新一张表的 status 字段，更新是成功的，但是这个时候数据库被重置了，那么又将字段重置回到原来值，那么就无法得出正确的结果。

当然，如果说是每次执行都是讲所有的接口测试用例都跑一边，或者一旦有人触发执行了部分用例时，不能发起其他执行请求或者是请求等待，那么不会有什么问题。但是数据库表还是颇多的，一次重置约 3min 左右。

另外还有个痛点是，现在系统相当于是三种不同架构模式的，就是①部分界面采用的是 vue+springboot（该部分有 controller 层），②部分界面为 dorado+springboot（该部分无 controller 只有 service 层），③最老的一部分是 dorado+dubbo，而新增订单还是用后面一种方式编写的，暂时第③部分职能调用 dorado 转接过的接口，即 xml 格式，有很多框架生成的属性，而现在让我测的是第②部分，也很头大，因为趋势是最终会到方案①，所以我才会想数据和接口隔离开吧，不要通过接口造数据不然一套接口测试工程也比较的乱，因为针对不同接口调用方式什么的都不同。o(╥﹏╥) o

是的，这个问题已困扰我很久了，难点在前置的数据怎么准备，如何做到数据闭环，可重复利用，且能并发时相互解耦，每个环境不需要太多的人为造数据、改数据，而是真正的一些通用提取。尝试过一些方案，没有很好的效果吧。

嗯嗯，这点之前倒是没有太关注，表的更新字段问题导致的不稳定性，不过我个人认为，造数据例如新增，指定了列名的话，不去更改表的列名，只是新增列属性的话还是影响较小的，当然新增的属性字段是关键必填的话，那么确实很麻烦了。

嗯嗯，mark，学习中，会吸收一下新的思想，感觉会有收获。

关于 1：例如我调用新增订单的时候，我需要选择一些额外的系统信息（必填项），例如用户、店铺、商品等等，那么如果这些是前置造好的话，那么每个环节新增用户生成的 id 什么的都不一样，所以才会不好配置，因为这些属性太多了；但是如果我为了新增订单，每次再去新增用户、店铺、用户等信息那么我觉得链路过长了。
关于 2：service 是一般不暴露的，所以要在部署环境调用，现在的情景是我们 90% 的代码是没有抽去 controller 这一层的。我之前一直认为接口测试做到 controller 层的请求的，而不是直接去调用 service 层，因为对于一些业务流程，相当于我又组装了部分的 controller 逻辑，但是上级一直认为 service 也是方法，可以在同环境调用，那么也能做成接口测试，而实际上，过于复杂的 bean 之类的入参，让我在设计用例的时候，一直很矛盾。关于 service 层是用单元测试覆盖，这一点我完全认同。

其实每个接口多少都有这个问题，在复用性的角度上暂时我也没有很好的思路

说实话，从公司（上层）的角度，只关心卖的多就好，不会关注你测试如何如何，只会就是口头上支持你做，但是现在 1:7 的比例和需求不明确还要耗费不少时间细化需求，在公司测试层面，真的感受不到这个事情的重要，但是作为个人吧，还是想要提升自己，想要是这种复杂程度的也能有做起来一点，有可靠性的话，那么会是我测试上的一大步。

推动开发给一些东西可能也是我的难处吧，业务迭代下，上层的最终目标还是要求你功能快点开发，测试先功能测试测好，所以有些接口和数据库表上的输出一直就是比较难推动给出吧 o(╥﹏╥) o

逻辑分支多指的是可能前面一顿操作猛如虎，【处理 8】接口的入参有十几种情况，那么在我看来其实就是十几种不同入参，想要断层在这个结点上，而不是为了造数据【处理 1】-【处理 7】一顿调用
前置接口能测试问题当然是好事情，侧重不一样吧，可能我局限于仅仅关注单个接口【处理 8】了，那么在我看来在【处理 1】-【处理 7】中会出现的问题不是我的测【处理 8】这个接口的重点吧