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

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

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

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

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

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

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

用 wiremock

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

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

第一个问题不是命名问题，而是用法有问题，失败提示已经很直白了。
建议去翻下下面这本书，你的疑问在这里都有答案。另外失败提示要认真看，不要看到是英文就有畏惧。

大头兵时签了无限期的合同。签了两次 3 年的，第 3 次就签无限期的了，前提是毕业至今都没跳过槽

请教下大佬，集成测试除了下面这些外，还需要考虑哪些场景？
作为调用方：
通讯异常：a.延迟 b.超时
协议级别异常：常见异常（如 http 响应 5xx、4xx 状态码）
业务级别异常：a.已知的非成功状态码 b.未知的异常状态

作为提供服务方：
参数校验
用户身份鉴权
过载处理（熔断、限流等）
向后兼容

metersphere

搞清楚自家项目与第三方 sdk 的交互流程，针对集成点和自家项目负责实现的逻辑进行测试。

忍不住想问句 “男朋友的故事是真的吗”