严格讲点点点是执行。测试的精华在于用例设计，在于质量风险防范。
测试拿开发技能进行 pk 有点本末倒置。
测试的那点自动化平台需求招个开发来实现效率秒杀大多数测开。更别提现在还有 AI 这个利器。
自动化的意义是什么，表面为了提效，提效是为了什么？是提供基本的功能可用性检测的同时让测试有更多精力去深入了解业务、实现、进行探索式测试。
测试的竞争力在于对质量和风险的把控，对业务的熟悉度、程序实现、质量风险的了解度越高越有助于把控质量。

起码要了解它的原理和各个组件的作用、协作关系、基本配置。
可以不是专家不会从 0 部署，但是需要去维护、排查问题时得有头绪，这就依赖上面这些内容的了解。

App 迭代频繁不一定是功能迭代频繁，有可能是在堆功能。
如果关键功能比较稳定了，考虑对关键功能做正向流程的自动回归，自动回归脚本还可以跑兼容。这样可以节省下客户端回归与兼容测试、服务端关键接口正向回归的时间。

会的。资源有限的普通人工作和家庭没有平衡，只有取舍。

可以通过下面途径确认
1.目标地区的浏览器使用占比 https://gs.statcounter.com/。统计的时间范围建议设为最近一年内。
2.被测系统用户数据统计。如果是新系统则参考公司以往同类系统的数据，公司内部没有参考的话就以第 1 个为准。
绝大部分系统覆盖 90% 的用户就差不多了，这个比例需要和上级或负责人确认；被测系统如仅在公司内部使用，只在 chrome 最新版上进行测试，不考虑兼容。

面试遇到不少自动化和性能做了不少，但功能测试、对被测程序的理解像 shi 一样的。。
以后还是测试发展路线的话，基本功不要丢

AI 火了之后真的越来越反感所谓的 “终生学习” 了，很多时候 “终生学习” 被有意无意、狭隘地定义成了对技术的追随。
像变成了技术的奴隶，要终生追随以免自己落伍、被淘汰，驱动我们去学习的更多是落伍的恐惧而不是自发的好奇。
技术很好，但它没有提升我的幸福感，反而变成了头顶的利剑。

先和你领导了解下他想要这个平台的目的是什么，想要解决什么问题。确认了目的再了解有哪些可行方案和进行方案的对比。目的没搞清楚，可能会导致 x-y 问题。

看下安装的证书有效期是不是过了。是的话， reset charls 证书 +wins 进行新证书的信任设置 + 手机下载安装新证书。

用 wiremock