直接在测试环境 “造” 日志，不可行吗？在成本和质量上，造日志相比日志过滤如何？
接口监控和服务监控，通过率低于设定的阀值，可能是接口和服务本身的问题，也可能是测试本身的问题，对吧？

宋老师，我没太懂这几个词：日志过滤，日志回放，接口监控，服务监控，错误预警。能讲解下吗？

不要被周围人误导，自己要有主见。测试没有天花板。

他们 “通知” 你？你误会了吧，他们是来 “协商”。

环境不稳定，那就改善环境让它尽可能稳定啊！
也不需要非常稳定啊，自动化运行有重试机制，好的重试机制是当前用例失败后并不立即重试，而是接着跑下一个用例，因为立即重试失败概率很大，失败用例每次重试都会是不同的时间段。比如设定最多重试 3 次，每次在不同的时间段全都撞上环境刚好不稳定的几率如同彩票头等奖，真全撞上了说明环境不是不稳定，是烂。
这些分布式系统本身就有抖动，你说的是你们的产品吗？如果是产品，这个抖动超出产品设计标准就是 bug，出 bug 的用例不用自动化。
case 本身不稳定，我们以前是要对 case 提 bug 的，以便督促 case 的 owner 修复。
UI 交互很恶心，这个具体怎么说呢？

楼主最后的总结非常到位，列出了 3 种类型等待的适用范围条件和利弊。同时也反映出一个问题：我们自动化测试工程师在实现和维护自动化测试的时候，应该把主要精力放在保证测试用例的业务逻辑 (包含结果验证) 正确性上，是不是不应该被所选工具提供的 workaround 分散或占用过多精力，是不是应该寻找成本更低效果更好的办法也就是真正意义上的 solution 呢？

在前年为某客户方提供测试技术咨询服务的时候，遇到过楼主的类似问题并给出过解决办法，这里分享出来。
等待，反映的是被测系统的性能表现，性能表现，既跟运行环境（这里指测试环境）有关，又跟被测系统本身有关。
我们首先应该解决测试环境问题，通过优化或升级解决等待问题更划算。比如被测系统运行期间，确保其他无关程序关闭，不装更好，只装被测系统及其依赖程序软件，即 “充分必要软测试环境” 或 “最小软测试环境”； 比如更换运算更快的 CPU，存取更快容量更大的内存，固态硬盘等，即 “最强硬测试环境”。硬件不值钱，人力才是最贵的。
测试环境不存在性能问题，则问题出在被测系统本身。如果系统反应时间慢不符合设计要求，可以提交性能缺陷，提高缺陷优先级，通过修复缺陷解决等待问题更划算。如果反应慢但符合设计需求则不是缺陷，或不符合设计需求是缺陷但放到以后再解决，这时候要不要使用等待有待商榷。某个、某些元素状态慢，是因为对应的接口执行慢（可能仍符合设计需求，前文已述），考虑使用 mock 来模拟对应接口的执行，mock 不需要等待。但使用 mock 有技术和其他成本，对比使用等待，可根据公司情况或项目具体情况做出取舍。

最后总结：尽量不用等待，消灭等待，如果可能。

UI 层自动化相比接口层自动化，适用的范围并不小，尤其是基于图片比对的自动化测试工具出现后。

周期长、业务稳定的产品的确适合做 UI 层面的自动化回归测试，遇到这种机会，希望也相信你们能越做越好。
我有一个疑问和一个不知道算不算得上的建议吧！
系统几百个页面，虽然每个页面不是所有元素都交给 PO 管理，但总共不到 100 个元素吗？有点不太能理解哦。
使用 PO 模式管理和维护元素是很有效的做法，如同骑上了快马。有没有考虑过多 PO 模式，会不会有加鞭甚至上高速的效果？

考虑用人成本是有点歪楼，技术讨论区就该考虑技术。
楼主的确提供了一种技术层面具有较高可行性的做法。

xpath 这种定位方式，尤其是相对路径方式，在实际工作中使用其实还是有待商榷。
主要原因是自动化测试团队中懂相关知识的不多，自动化实现和维护成本需要考虑。
当然，如果团队具备熟练运用相关技术的能力，实现和维护都能快速完成。
问题是这种团队时间成本这头儿是得到了控制，用人成本那头儿呢

你这个 85-90% 是通过率还是稳定性呢？你们的冒烟测试 2500+ 用例，回归用例有多少呢？

1. 我们现在是用接口来实现业务的集成测试，想问下 这种方面 是写 python 代码来的有效率，还是使用接口平台效率高
你个人的倾向和别的同事的意见都没错。通过对比并评估两种方式的小批量实现即可得到答案，需要注意的是接口测试平台的研发或二次开发成本需要考虑在内，这是以两种方式都能实现整体目标（实现业务的集成测试）为前提，离开了这个前提，效率高低都是空谈。
2. 用例都写完了，怎么更能体现价值，只在测试冒烟阶段执行？ 还是开发？生产都执行？
不存在 “更能体现价值” 之说，全面满足需求体现价值就是很好的。如果需求是只在冒烟测试阶段执行，那么在别的阶段也执行了就不是更能体现价值，这种（多余）价值也不该被认同。不该在开发和生产阶段执行，只能在测试阶段执行。

我们使用的就是题主所列的方案二。
二、对应的去修正脚本，修正完再跑版本的的自动化脚本。
第二种方案就是耗时耗力，而且有没有足够时间调试脚本。可能会不稳定。

该怎么做到呢，能具体说下吗？

我十分欣赏发帖问问题又不忘把解决办法帖出来的人，不光是分享精神，更是责任感的体现。

水平有限，不太能看懂这篇文，列几个地方希望释疑。

1. 测试数据维护-->黄金下的 3 条。
2. 将测试数据作为存在模型或者方案中，甩个模型&方案链接。模型、方案，何物？
3. 什么叫定制接口测试？理解为定制接口还是定制测试？
4. 什么叫 parameter-model 包拆分测试？没遇见过这个专业词汇啊！

很不错的分享，让后来者多了份参考

来晚了，肉已经被列强瓜分

感谢回复！
我能接受你对第一个问题的观点。
第二个问题，测试团队两周确实改不好，这是现实或事实。大家也确实努力了，加班了，应该不存在偷懒的情况。感觉做不完不是因为任务重任务多人手不够，加人估计并不能解决问题。你这边如果有相关经验，希望能指点一二。

你发的那个帖子就是讲你那个平台的吗？

我们的测试团队这样做过，存在两个问题。

1. 产品变更后，不受影响的用例会保持上个版本一样的执行结果，而受影响的测试用例 ---- 真正反映变更造成的结果的用例却没执行，得到的测试报告还有价值意义吗？
2. 给了自动化测试团队两周的时间 (开始是给一周)，没修好新版本就又出来了，又有新的用例受到影响需要修复，前两周修复过的用例再次受到影响需要重新修复，技术债务越积累越多。

接口测试平台不能让维护接口测试工作变得简单。

漏掉了题主的两个问题。

1. “也在网站论坛查过，有人说放在接口测试的时候验证，但问题是，我们现在字段过多，有好几次前端取错值或者没展示出来的情况....感觉好像对于我们来说有些不太可取 “ 是的，这种情况下接口测试不可取，原因不是验证点 (表单内容、页面元素和表单字段) 过多，而是前端也可能存在问题。所以我前文建议做 UI 自动化测试，遵照或参考我提供的流程，前端和接口出现的问题都能很好地解决。
2. ” 也有人说 UI 自动化主要是验流程，验页面的跳转，那这种表单字段等元素的展示如何验证呢？” UI 自动化测试不光是验证流程、页面跳转之类，仅验证这些严重对不起 UI 自动化测试的 ROI 投资回报率，很多公司不愿意做自动化测试就是没给管理层领导们看到满意的 ROI。那么这种表单字段等元素的展示如何验证，我跟其他答主观点类似。一种是你可以提取文本，一种是对比截图，这两种方式我都强调下，必须是实际结果和预期结果的对比。

根据题主提供的情况，我认为这个时候做 UI 自动化测试还是有价值有意义的。流程是：发现 bug---->提交 bug，指派给开发经理---->评估 triage 通过，开发经理指派给前端负责人---->前端接受，修复 bug---->重新测试确认修复---->关闭 bug，或者是，发现 bug---->提交 bug，指派给开发经理---->评估 triage 通过，开发经理指派给前端负责人---->前端驳回，指派给开发经理---->开发经理重新指派给接口负责人---->接口接受 (这里先不谈驳回)，修复 bug---->重新测试确认修复---->关闭 bug。
对于题主担心的 “现在的问题就在于主要验证的内容很多是表单内容展示的是否正确、页面某些元素展示的内容是否正确。表单字段特别的多，页面元素也多，如果一个个字段去验证的话肯定不现实”，我已经在 33 楼说过，自动化测试实现和维护成本，跟测试方案的关系最大，受验证点数量的影响较小。在适合的测试方案面前，再多的验证点 (无论是表单内容、页面元素还是表单字段) 也只是个可 “量” 化的数字，是可以直接换算出工作 “量” 的，对测试的实现和维护成本不能构成 “质” 的影响。

回归测试仍然需要考虑异常值的情况，不能只是正常的流程及数据的验证。
被测系统对异常情况的处理是完整功能的重要组成部分，不容忽视。