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

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

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

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

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

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

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

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

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

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

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

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

嗯，它可以用中文写脚本

已发地址

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

是的，这块我也在思考，这样测试对前端框架的依赖太大了，有没有大的遗漏点目前也还不清晰，下个月项目开工我要按照这样测一遍试试水

有朋友没时间去的私聊我一下，没抢到票，很不要脸的求一张

已更新

其实我也是最近一直在看技术，结果写案例的时候发现基本功有点落后了，然后才有这种感想

恩，是啊，能找到的都是一些简单的东西，稍微深入的知识就没了

哈哈

我觉得排版还是很重要的，写文章有一个好的排版，是对读者基本的尊重。

多谢，有时间一定去读读

这个图好棒

我的问题就是，在测试资源不同时，如何有针对性的设计测试用例。

文章的内容当然也是我后来经过思考整理出来的结果，当时我期望面试者能够说出测试资源宽松和测试资源紧缺时的设计方案，即使说的不详细，起码针对这些情况会有一些不同点。但是面试者给我的答案永远是 按照需求产出用例。。。。

我感觉现在太浮夸了，都喜欢了解各种技术相关的知识，缺忽略了测试最重要的技能。

TMQ 的文章还是不错的，应该是按照他们博客平台的规范来写，然后直接就 copy 过来了，原文排版就比较正常了

[XCUITest] The capabilities 'autoAcceptAlerts' and 'autoDismissAlerts' do not work for XCUITest-based tests. Please adjust your alert handling accordingly.

看样子可能是 Appium 版本不一致，导致使用的 IOS 测试工具不一致，你是最新的版本吗？我的 Appium 版本是 1.4 的，我测试是 OK 的。

#23 楼 @da_sheng 我感觉 web 端和移动端差不多。。。。

蒲公英专家测试 + 不要脸求中奖，我们公司的应用就挂在蒲公英上面，好评

#19 楼 @jasmine_flower 这个不知道哦，我都是直接在 postman 上面写完之后，在 jmeter 再重写一遍