楼主这个问题最优解应该是引入一个数据仓库，提前生成好需要的数据。

测试用例的编写有一个很重要的原则，只做一件事 。而这件事之外的事，应该在其他时候做。

比如楼主的例子，测试问卷的前提是要创建一个问卷，这个流程如果是串行的，那么就让这个自动化用例变得臃肿了，并且在做自己想要的事（测试问卷）的时候，额外增加了一件事（创建问卷）而这个过程的不稳定会导致后续的验证都无法执行。

如果把这个流程改成预先生成一批各式各样的问卷，要测试的时候直接拿这个问卷来测，而无需实时创建，那么这个问题就解决了。同时由于有了问卷池，那么即使创建问卷的功能有问题，也不会影响测试问卷这个功能。

楼主的问题 2 也是同类型的问题，不同的场景对应的底层问题就是数据的不同（或者状态不同）。通过一个数据仓库覆盖这些场景的数据就可以解决大批量串行流程构造前置条件的问题。

至于 api 管理这个层面，我个人认为应该是把这些 api 服务化，而不是一个一个的脚本。

恩，比自己封装的时候方便一些

谢谢！所以这块的核心，还是一个 provider 和 consumer 的监督，相当于在传统的 Mock 基础上增加了监督接口的功能。

恩，网上太多都是把 pact 的 demo 贴出来，估计自己都不懂这个是要做啥的，刷刷流量而已，所以才会有这个疑问，谢谢你贴的地址，我去看看。

这块我们是打算做一个配置化的 Mock 平台来处理，而每个请求的相应会根据字段规则的不同来路由返回的结果，这样能够可视化配置，减少维护的成本，而且没有对代码做了侵入性的修改，不过一切都还在理论阶段，所以专门开一个帖子来了解一下，你这么说我大概有了一些概念了。

这个问题太常见了，流程不规范，经常会有这个问题

确实是的，主要是基于 DOM 元素的 Selenium 方案测试起来脚本的维护成本太高，收益低。
而这种方式稳定，但是确实需要测试人员有较高的技术水平

嗯，它可以用中文写脚本

已发地址

是的，这样其实对测试人员要求非常高，至少开发的框架必须要有一定程度的熟悉，而且测试的时候，基本上要把开发的代码通读一遍。