最近刚换完坑说下感受，仅供参考，祝愿早点拿到合适的 offer
1.每次面试其实很多问题是相同的，提前准备好相应的东西，做过的东西提前做个总结，高频问题可以提前准备下答案
2.前期要先面一下没那么想去的地方练练手，每次面完问下反馈，大多好一点的面试官会反馈真实的问题，然后再总结
3.不要怀疑自己，面试很多时候也很看缘分和业务匹配度，所以投递尽量选业务匹配度高一些的
4.不要急躁，一开始最好一天一个，面完总结，到后面可以一天多个逐个增加
5.算法题还是可以刷一刷，差不多每个类型刷几道，这样遇到后就算不能马上写出来也会有相应思路

除非是依赖有时效的 token 信息这种，不然肯定单独维护的

最近学会一件事，就是 90% 的人干的事情其实是没有意义的，包括产品开发测试，90% 的活其实是没有意义的，简单的说就是这个需求做还是不做，测还是不测，都没意义。所以别自己内耗

头像是您孩子么，很可爱

我感觉不绝对吧，老板可能是给一个方向或者很初步的想法，他也不知道怎么做，怎么可以按老板的完全执行呢

这简直不是天堂么，先在学习有 AI 这种学起来快多了啊，先学完代码基础啊，乘着这段时间把代码水平夯实一下，至于他们说的工作中用，你随便找个网站不也可以么

现在这个和磐石集成后相对来说确实还可以

拆需求内容，哪些是涉及到兼容的，哪些不是，涉及兼容的才跑全部，不涉及的海外看流量较高的站点，其余站点抽样，比较敏感的比如站点币种这些看看，不是所有的都要看

每个公司不同，但是总的来说也是按照下面的流程去塞内容吧
项目立项/迭代初评
需求/埋点评审
测试依赖项确认
迭代估时
技术评审
测试用例评审
提测（冒烟/集成）
产品/视觉验收
发布前功能对比
BI 埋点验收
发布
生产验收及回归
埋点监控与多语言检查
线上问题处理

要先预估一个并发数啊，阶梯也有预估的并发数吧

进入页面会调用 a,b,c,d 四个接口，目前已知信息：
1.a 目标 qps 为 Ta,b 的目标 qps 为 Tb，c 的目标 qps 为 Tc，d 的目标 qps 为 Td
2.对应为每个接口当前的平均响应时长为 Ra,Rb,Rc,Rd
3.当前各接口的峰值 qps 为 Na,Nb,Nc,Nd
如何设计当前的压测场景，并预估下目标的并发数是多少

generate_names 这里面把你的返回打印出来看是个啥啊，和你的请求参数数据类型这些是不是对得上，看着 403 的话大概率你参数不对

我们这种重构都是开发改完，主流程跑完，测试测完后接口 DIFF 和流量回放通了才行的，不然鬼知道有什么坑等着你呢

正常来说主流程冒烟不过就直接打回，结果来一个直接不冒烟了，那不绝了么

我的天，这是多想不开

是所有功能还是只是做简单的页面轮询

主动离职和被裁不一样吧，突然说要裁了，然后还要牛马一样的确保交接满意，这多少有点圣人的标准要求别人了

1，写 BUG 的时候会提页面链接正常，但是你会提某个元素 XPTH 路径么？
2，很多时候这种页面的 BUG 的元素里面的值我自己都不知道他应该是什么，比如一个酒店或者景点的封面图，他就是一个图的链接，我也是要调外部接口才知道值是什么，但是我人眼看得出来这个图不属于这个酒店或者景点 AI 怎么判断呢
3，大模型怎么理解你的操作步骤和预期结果，因为这里面有你具体的业务知识，给他配一个知识库么？

自动化很关键一个指标是可靠性，特别是巡检类的，经常有本应该成功的失败了，或者本应该失败的没卡住，那对业务来说这就是鸡肋，首先会让人觉得这个不可靠，一次两次会人工确认，次数多了谁还看呢

1.任何接口测试都依赖契约的，首先想做相关的肯定得有相应的契约文档或者契约平台这些，如果没有先搭基建或者自己整理文档，接口测试也是业务相关的，首先你得知道业务的入参组合，返回情况才可能写的出来 case 和断言
2.在 1 都清楚了后，你可以 POSTMAN 也可以其他的工具调也是测接口
3.在 2 的基础上再想用平台也行，用脚本也行啥都行让他自动跑，做巡检，做发布的线上流量 DIFF，做流量回放（依赖完善的日志体系）等等
4.在前面都通了在想着和 CI/CD 流程做集成

没有，我是想知道提效的占比确认主要做啥，当全是提效没得业务了就要凉了，提效很多时候是要自证价值，自证价值就很难受了

提效和实际业务测试的比例大概是多少

1.原流程不合理的优化下流程，短期来说这个是最快的
2.原基建缺失的增加基建
3.原项目没有知识沉淀的增加知识沉淀

最近也是做这个相关的，我的问题是，你怎么让大模型知道你要点哪里，因为对于用户来说他的语言是自然语言，没有知识库的话那么大模型他怎么知道描述的是什么

这让我想起了之前试过的一个东西 midscene