漏掉了题主的两个问题。

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

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

对于 1，也认同你的观点。我说的核心点是自动化不能完全取代回归测试，所以不要以通过自动化完全取代回归测试为出发点开展自动化。
对于 2，我不是很认同。我觉得要做到是很有挑战，而且确实要非常准确评估，会非常难。但并非完全不可以。对于被测系统相对不是非常复杂，改动点不是非常巨大的情况下，大方向的评估还是可以做到的，这种评估本身其实也能让自己更好地缩小回归范围。至少可以避免开发做完改动，随口说一句 “影响范围：建议全功能都回归下” 时，自己很难做判断。

另外，code review 这个职责确实是开发本身的职责，但不代表测试不可以参与，或者测试不能用这个工具。有些改动不大，逻辑比较清晰的改动（比如 sql 查询条件加一个 isDel 的判断条件，或者加个 try catch 保障一些已知异常不至于让整个程序垮掉），通过 code review 评估风险不大后，直接快速上线，也是可行的？

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

“主要是接口测试的没问题，前端页面取错值，或者没展出出来”
“我们接口目前其实也只做了基本的一些断言，详细的字段校验还真没做”
你这两句回复可以看出，你们的接口测试并没有真正做。
换句话说，你们产品出的问题并没有定位清楚，可能出在前端，可能出在接口，也可能二者都有。

不太能认同这样的观点。

1. 自动化测试实现和维护成本，跟测试方案的关系最大，受验证点数量的影响较小。这里验证点不是指用例，而是指用例中需要断言的部分，即验证的部分。
2. 做到熟悉项目的代码对于测试团队是不现实的，即便是自动化测试团队。测试团队更难做到从开发改动点倒推影响范围，开发团队做的到吗，应该也不能吧。如果你说的是通过 code review 的方式保证质量，那么 code review 本身就是开发组的工作而不是测试组的工作。 对您 2.2 的观点表示认同。

“需要把前端页面字段，跟后端返回数据，之间的对应关系整理出来” ---- 这个是 dev 的工作，不是 tester 的工作。
测试不需要整理这些对应关系就可以考虑测试自动化。

不可以直接从数据库取数据然后跟 ui 展示的数据对比哦，因为数据库里的数据也许就是错的呢！
正确的方式是将期望结果和实际结果做对比，是不是听起来像是照搬教科书里的话，呵呵

说明这个测试不合格，还需努力强化软硬技能

再牛逼的测试也拦不住一个烂开发写的 bug

为什么要截图提取啊，那成本太高了，不能够直接提取文本吗，这种可以做的简单也可以做的复杂，复杂的可以 UI 的数据和接口的数据和数据库的数据都同步验证，根据时间和人力来选择某个难度吧

之前接口做过测试吗？如果接口没做过测试，那可能接口返回的就有问题，那你还得从数据库去取数据呢

接口不确定正确的话，直接从数据库取数据，然后和 ui 的对比，出错了再让他们自己看时接口的错误还是 ui 显示的错误

这种情况要做自动化，就需要把前端页面字段，跟后端返回数据，之间的对应关系整理出来。
关系整理出来了，再考虑如何自动化。
可以从契约测试入手。

不要为了用什么工具而看哪个业务能用上，应该反过来思考。比如我这个数据验证好麻烦，是不是有什么办法优化一下，再去比较各个方案的优劣，放能落地。

返回的字段很多，数据有变动，用接口验证，jsonschema 效验啊

啊，但这还不是得定位获取前端的各个字段的文字，。。。再去对比接口返回的么吗，楼主不是就是不想这么弄每个字段么

你这种属于历史预留问题，其实验证很简单，UI 自动化校验的时候同时调用信息展示接口验证，这个我是以前验证那些展示很多字段，而且开发不知道啥时候改一改很容易改错的那种

可以调别的接口辅助验证吗？
比如新增成功，调详情接口的返回值，取关键字参数取做断言，成功表示后端代码是没有问题的，如果前端展示问题，也是前段取错值的原因

并没有想过用 UI 自动化来发现新 bug 或者验证 bug，只是每次迭代都有必要的任务，确认此次迭代完主流程方方面面，边边角角还是没问题，内容重复繁多。我们这个系统主要的就是表单数据，没有什么 UI 的影响，web 端基本就是验证数据了，接口返回的数据之前接口测试的时候也抠过，所以现在主要就是覆盖到自动化了

！！！！！调信息展示的接口这个可行！实现起来感觉也会简单一点。前端的代码已经缝缝补补不成样了，改一点到处错的那种，怕了怕了

作为回归的话应该不需要再考虑异常值的情况了吧，主要还是正常的流程及数据的验证~

要是招人也就不至于从别的组借人了 时间上不允许我有这么多校验哈哈哈哈哈

我们接口目前其实也只做了基本的一些断言，详细的字段校验还真没做，实在没时间

虽然说 UI 自动化是保证主流程通就可以了，但是你这这种如果字段很多，那就真的需要校验了，我以前用的一个办法是 UI 自动化跑到这个界面，然后同时调一个信息展示的接口，然后我取接口字段和前端的展示信息做个对比。当然最好的办法就是去看前端的代码也是可以的

我最初的想法就是用来检验各个字段的异常值的提示文案哈哈

根据金字塔模型，接口>UI
接口主要能够涵盖我们的系统的业务运转不报错，最大价值就是回归测试，最近面试听说扯淡话题接口自动化能够发现 20% 以上问题，那说明基本业务功能没测过，系统极不稳定。
UI 测试别想得太复杂，个人应用最大价值就是验证前端界面布局有否异常。

至于说到前端数据展示必须手工构造数据验证后对应如表单数据对应后端字段，特别接口返回数据多层嵌套取数据上，必须手工去抠，后续结合在自动化覆盖。

那你公司还招人吗哈哈，我们项目停了，这种的完全是前端人员经常传错值导致，这都能错，肯定会有很多奇葩前端的页面显示有问题，需要多注意了，这种是测试阶段就需要发现的，后面迭代又不会影响太多之前的改动，说实话是只能用 Ui 去覆盖，但是这样的检验就太多了。，

现在跟你面临差不多一样的问题，但是我还比你惨。因为都没有接口自动化测试。现在都想去看接口自动化测试了~

两端功能通了，能跑就行。这些验证的问题测试提出来了就是有问题，没提就是没问题....... 又卑微又惨

取错值应该是联调的问题，两端做完都互相不管了吗

需要先把接口测试做好，保证接口返回的内容没有问题的情况下，将接口获取的数据和页面展示的数据对一个对比。这中间的工作量比较大，楼主如果想做需要做好心理准备。

为啥不行，单独对前端表单展示做下验证就行，怎么好用怎么来，这种死逻辑最适合自动化验证了。
表单记得用 PO 形式分离。

主要是接口测试的没问题，前端页面取错值，或者没展出出来，这种问题就很尴尬

我只能自己慢慢搞了 本来只有我一个人，后面半路找别的组借了个人，还拖了半个月才进组，然后人家以前做的项目都没现在这个复杂繁琐，上手比较慢，导致中间会出差漏，上头直接来一句：以后归你负责，我只问你，你要盯着他一点。我.......现在就有种找了个机器，我发号施令，他帮我点点点的感觉。只能按您说的，挑重点慢慢来~~~

bug 的回归肯定是手工测的，也是通过修改的代码影响的范围去进行测试。但是我们每次迭代都要求将主要业务流程全跑一遍，并验证前端数据啥的展示的对不对，每次这个回归都测到怀疑人生，内容太多，我们一共就两个人，另外一个还是半路进组，我还得盯着他是不是该测得都覆盖到了 (这个是经理要求我问我盯着......)，耗时又耗力....

嗯 ，其实你是有能力却头疼，无非就是人力的问题； 找领导协调资源，将你的方式说一下，你可以示范一个项目，其他人员你也可以协助； 将这个工作做好，毕竟是团队作战；如果人力也不给，那你只有跳重点的 一步步便利了，

1、不要想着用 ui 自动化、接口自动化测试完，就不用再去测。这些自动化实践中作用更多是确保没有非常明显突出的问题，要达到自动化测试完就不用再测，校验点会非常多，编写和维护成本也高

2、楼主的核心目标其实是减少回归测试工作量，提高效率。个人觉得，相比用各种自动化，更建议可以尝试下面 2 个方向：
2.1 熟悉开发的代码，掌握从开发改动点倒推影响范围的能力，缩小自己的回归范围。既然有能力做 ui 自动化，那熟悉下项目的代码应该不至于非常难。
2.2 根据线上业务情况，精简回归用例，找准重点。确认哪些地方出问题风险高、用户量大、必须回归后才能上线，哪些地方风险低，发现后修复也可以。

ui 测试最好不要全部的字段都验证，太繁琐了，这是接口测试要做的事情，建议挑一些关键的字段校验。ui 测试重点是验证流程逻辑、跳转逻辑