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

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

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

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

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

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

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

用 wiremock

1.找可以远程办公的公司
2.回老家考编考公或其他行业，尽量选可以接触到资源或渠道的工作

我理解的：对于服务使用方而言弱网导致的后果有两个：超时、延迟但未超时。
所以平时测试也只测这两种场景。请教下基于什么考虑要测丢包、乱序、延时波动这些场景（这应该是网络层要解决的事，应用层应该不需要测）？