谢谢，看来需要想办法在合理范围内装饰一下简历了

确实三年的时间，成长速度很一般。不过有时候平台不大，有些东西没法开展；继续加油吧

非常感谢，

简历缺少数据支撑，太 “干” 了，字面意思，没有说服力，也没有亮点，只能说中规中矩，如果不是背景过硬的 985 211 选手，大概率会被 hr 忽略

可以的吧

3 年还在做这些事情？有点太薄了。

无中生友？

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

按照你描述的是前端某个 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 没有被自动化测试体现出来，说明开发新业务的时候对原有系统的破坏性（改造）小，这也是好事。（不过我的项目组就没有这个烦恼，开发经常改着改着就破坏原业务了 ）至于如何进一步提升所谓的价值，我确实没有相关经验。期待你的后续分享吧