我觉得底层覆盖度高的话，上层不需要全覆盖，覆盖其中一个就好了。

例如你提到的三个类型的用户，如果在接口层面都是一样的逻辑，只是用户类型这个字段不一样，那就 API 覆盖三个类型，UI 只覆盖一个类型就够了。

始于 ui，终于 db：数据准备 >> ui 测试（数据录入及验证 -> 触发起始站）>> 接口测试（拦截 request&response 及验证）>> db 测试（ui 输入作为查询条件进行数据验证）
所谓 db 是指数据持久化的存储介质，不仅限于数据库，也可以是文件等形式
这应该一个 case 能搞定三合一的

#2 楼 @quqing 我想做的事情就是不同层的测试之间单元化，去耦合。 如果纵向测试（从 ui 到接口到 db）感觉效率和覆盖率都比较低～

#1 楼 @chenhengjie123 嗯 这样是比较好的 确实应该金字塔形，ui 覆盖的不需要太多。 但毕竟 ui 层才是最终用户用到的， 感觉在注册这么重要的流程最好还是 ui 也覆盖下比较好～ 想了想一些测试还是基于 priority 的，有的地方宁可冗余点吧。 也没啥好方法能一定 100% 保证质量也最大化效率～

#3 楼 @stephen753 分层支持解耦。。。从灵活性考虑，如果支持既能耦合又能解耦，岂不是更灵活

#4 楼 @stephen753 我觉得其实最终还是投入产出比的问题吧。

另外，我觉得 @quqing 的这个方式成本有点高，毕竟原来一条 UI 自动化用例能完成的事情，现在变成 UI + 接口 + db ，而且覆盖度其实还是和 UI 的一致（例如接口中 request 缺少某些字段时服务端的处理，如果是在 UI 操作的话不一定能覆盖到）。对于这种情况我比较偏向于用 stub（挡板）的方式。

举个例子：
UI 的，不和服务器耦合，而是直接拦截它的请求，然后直接给对应的返回。因为这里我们关注的点在于 UI 的逻辑层，即界面操作最终的输出（request）是否正确，以及界面对于服务器响应数据的展现是否正确。

接口的，就是单独的接口测试了。当然接口测试最好还是能直接触及到数据库，确认接口的逻辑是否正确，也方便多用例时用例间的相互影响。

个人理解，分层覆盖的意思不仅仅是说不同层级之间用例的比例，关键点是每一层有自己单独的测试，也有合起来的系统测试。而且很明显的，系统测试的覆盖度会不如每一层自己的单独测试。

至于覆盖度的衡量，在没有很好的方法的情况下，我觉得代码覆盖率是一个不错的参考指标。

以上是一些个人观点，大家有不同意见也可提出~

#6 楼 @chenhengjie123 可能我没说清楚，分层可以有每一层独立的 case，互不干扰，例如我只想做 db 的，没问题可以解耦支持，我只想做接口的，也没问题。问题是现实情况比较复杂，有时候需要找出关联性，例如：由于分层覆盖率问题，可能只在 UI 发现了一个问题，通过建立内在联系，也可以发现深层次的原因。所以我想表达的思想是 “支持分层解耦比绝对分层解耦更灵活”

#7 楼 @quqing 恩 我实现的方式其实是 ut 层， www 层， UI 层。
然后 UI 层的数据是用 www 层 http call 造的数据， 不是直接 mock 的 response。 感觉不同层之间都用 mock data， 很容易和真实 data 不一样。

要真是分层的话，Pact 测试是比较合适的选择，服务都能分开测试