日常交流:
A 测试同学：这里可能还有一种情况需要考虑，当前没有做边界处理，也没有兜底逻辑，需要补充一下，免得用户在某些环境下触发了，到时候给用户造成资损就不好了（心里：他紧急赶这块功能，会漏一些边界情况，虽然触发概率很低，我要提醒他一下，下次他也会记住的）

开发同学：嗯嗯，好的，我补充一下（心里：感谢老弟，还好你发现，不然用户资损了，我就要挨叼了）

出问题时：
领导：刚刚用户反馈了问题，咋回事？
A 测试同学：我的我的，由于时间紧急，颗粒度不够细，这种场景漏了，已经补了工单，现在就跟进这个问题并重新检查这一块
开发同学：是我这边没说清楚，这边改了东西，没有和测试说清楚影响范围，所以他没有回归这块，下次我说清楚一下，我这边先把客户问题解决，然后和测试再对齐一下这块

————————————————————————————————————————————
日常交流：
B 测试同学：这怎么回事啊，点一下就报错，点一下就报错，怎么总是改不好啊？（心里：代码怎么写的啊，其他开发怎么没这么多问题啊）

开发同学：哎，我看看，你特么的代理都没打开啊（心里：你到底会不会啊，基础配置都没弄好，就搁这儿喊）

出问题时：
领导：刚刚用户反馈了问题，咋回事？
B 同学：开发改了东西也不说，代码写的太烂了，总是出问题
开发同学：测试这里没测到，这里没测好

用增强检索 + 大模型的方式，可以把完善了的需求文档上传到知识库里，另外大模型生成测试用例的提示词就按照公司测试用例的标准去写，这样生成的测试用例会比较贴切你公司的产品，可以覆盖很多规则和细节

以前开发提测我会喊他坐过来，或者我搬把凳子坐到他旁边，来来来，朋友，看我演示一下流程
1、虽然是我演示，但是他也会在看主流程是不是通畅（因为他可能没有自测完所有步骤）
2、遇到一些很明显的问题，当场就截图并标上序号发给他
3、主流程阻塞，不用说，他自己立马就回去调整了，然后稍后又过来提测，为了防止白跑一趟，他打回重新调整时会更加认真了
4、这样的演示搞多了，和开发关系还变好了

没有强制搞什么提测流程，自测用例啥的，如果提测冒烟过程很通畅，我一般还会当场夸他做功能做的又快又好

开发：做好了一把刀给到你，可以开始测试砍瓜切菜了
测试人员 A：嗯，测完了，切菜切肉剁骨头都阔以，拿手上也很舒适，可以上线卖钱了
测试人员 B：等等，能拍蒜吗？
开发：？？

你这个账密登录的前面还有一个手机验证登录，里面也有一个这样的输入框，所以你很有可能是定位到第一个手机输入框去了，你可以 (//*[@placeholder='请输入您的手机号'])[2] 试试，实在不行就要根据父级元素 + 兄弟元素组合，找到 “密码登录” 界面里的这个手机输入框了

有饭吃，真不错

真好

我用你的代码可以跑，你是不是这个 deepseek 连不上，检查一下这个 DEEPSEEK_API_KEY 是不是错了，或者没额度了

这个试着用了一下，发现很消耗 token 啊，跑几个页面直接就是十几万的 token 没了，小公司玩不起