无中生友？

你的测试数据和之前的业务流程有关系吗？有关系的话就不应该直接准备数据到 “将要执行的状态”

按照你描述的是前端某个 js 执行耗时太长导致的卡死，这种情况用 lighthouse 一跑就知道是哪个 js 导致的

这匿名的名称，搞一些好玩的就好了，什么杨过 郭靖 虚竹啥的

第一个思路的弊端是？

1、最直接的 chorme 的开发者工具，直接性能分析下，告诉当前资源消耗情况
2、前端性能监测平台，这个可能比较重，偏向于是线上监测的，web 端的我们用过有基于 skywalking 的前端监测能力，可以将用户行为分析、前端资源、和一些前端界面的常见性能指标。

lighthouse

阿里云提供了 arms 的服务，页面加载，js 报错都有相关的数据，就不需要测性能了，直接观测不是一步到位

https://www.webpagetest.org/

面试时没问怎么定位问题是前端还是后端吗

这种可以看酷家乐的技术博客 tech.kujiale.com，毕竟酷家乐是一个偏前端的公司

这种问题都需要匿名了吗

前者
偶尔也做业务测试结合上面的兄弟的意见，现在在思考如何给其他部门提供一些支持

数据量超大？接口响应成功后，页面加载渲染太慢；还是接口响应就很慢？前者是前端问题，后者是后端问题。不知道说的对不对

就是开发者工具啊，chrome 的开发者工具还不够使？

首先，需要团队正确认识自动化团队的价值，包括自动化团队本身。

总结的不错！只是第 3 条犯了循环论证的错误，跟用余弦定理证明勾股定理一样

自动化在我理解中，主要是不是用来发现 BUG。

那用来干嘛？有以下几点：

• 回归测试，上线后回归，需要耗费大量时间，并且是重复的。因此非常适合自动化
• 测试准入，自动化配合 CI，开发提交测试后，如果跑不过自动化，直接打回。
• 造数据，比如在电商场景中，需要创建一个待评价的订单，手动创建的话，需要很多步骤。但有了自动化，运行对应的用例即可。

了解；当然，确实如果辛辛苦苦写了很多自动化脚本，结果新版本一上通过率极高，但是还是有很多 bug 没能发现，这确实会” 对人生产生怀疑 “；其实不能说自动化测试发现的 bug 少，它的价值就不高。因为随着迭代的进程，bug 必然会越来越少。新业务的 bug 没有被自动化测试体现出来，说明开发新业务的时候对原有系统的破坏性（改造）小，这也是好事。（不过我的项目组就没有这个烦恼，开发经常改着改着就破坏原业务了 ）至于如何进一步提升所谓的价值，我确实没有相关经验。期待你的后续分享吧

自动化测试主要是回归测试，所以没发现的 bug 主要分为 3 类
1：新业务的 bug，也就是没被自动化覆盖的业务的 bug， 这个不属于自动化测试的锅
2： 用例不全 ，目前自动化测试主要是对测试用例的脚本翻译成自动化，所以这个是测试用例设计者的锅
3：脚本对用例覆盖不全，导致漏测，这实实在在是自动化测试的锅

感谢回复，目前我也准备在持续测试上多做些研究

你说能发现一些 bug 但是比较少；所以是不是存在其他发现不了的 bug？然后这些自动化测试发现不了的 bug 是属于前端问题还是后端问题？

你这边说到 “自动化团队的价值”，其实也就是测试的价值

测试的价值可以体现在四个方面：

1. 预防缺陷
2. 发现缺陷
3. 增强信心
4. 提供信息

题目里说的情况，“发现 bug”，只是测试价值的其中一个方面，毕竟随着测试的进行、产品质量的提升，发现的 bug 越来越少其实是合理的

所以从这个角度来看，自动化测试的价值并不是只有发现 bug，如果自动化测试没有发现 bug，说明系统的表现和行为都是符合预期的（自动化脚本没有问题的情况下），这可以为系统增强信心。同时，通过使用自动化来替代手动测试，为持续测试提供了可能性，可以更频繁地触发测试，比如在每日部署和版本部署之后进行，可以比手动更快地发现可能引入的新 bug（或者更快地保证被测功能没有受影响），并且这个信息也可以提供给更多的人（主楼里提到的 “全员抄送”），让其他利益相关方都知道自动化测试的结果，也有助于提高团队的质量意识，这些其实都体现了自动化测试的价值。

我没看懂你的留言

发现不了的 bug 也都是后端的么？