说明这名员工就属于有能力没潜力的类型，这样的员工是否去留主要考虑 2 个方面
1.组织的发展阶段，如果现在组织还在扩展阶段，需要应对当前业务需求压力比较大，人员不够，那就还是留，同时尽量引导，威逼利诱让他进步。
2.如果公司当前处于稳定期，业务压力不算很大，组织可以考虑优化，就结合团队成员画像，综合比较团队人员能力，如果综合来看他处于中下游，那就轮换。
作为管理者你的第一原则是要保证你的团队是不断进步，保持战斗力。所以永远去找那些能力处理当前团队中上的人员，让无法适应发展的人员有更好的去处。

管理是横向比较的，个例很难评估

正解

你提了吧？提了。
你催了吗？催了。
有证据吗？有。
好的，下一位，跟你没关系了，那个前端，来我办公室喝喝茶，咱们来探讨下你工作的排期。

说实话这种开发还是比较少的，碰到了该怼就怼，不要怂，代码是你写的，我只是帮你把 BUG 找出来，你不谢谢我就算了，还不耐烦？线上出了问题谁负责，要学会转移矛盾，让产品和他去扯，让 PMO 和开发 leader 和他去扯，有事尽量在群里说，不要私聊，让大家他看看是什么嘴脸。

看你们公司流程，如果是严重有影响系统的及时沟通挺合理的，遇到这种艮的开发就上报。不严重的 bug 提交系统等修复完验收就行了，有啥流程就跟着走，觉得有好的意见提就行了。

楼上说的对，漏侧不可避免。
记得追加测试用例，扩充测试用例库。

你不要心虚，感觉楼主还是刚入职的新人一样。是你工作范围内的，该提的 bug 就提，提完之后如果有类似的 bug 管理平台，研发改状态了就验收回归，没改你就不管，到时候根据 bug 的遗留数量和验证程度来出报告，是不合格就直接测试不通过，自然会有研发的负责人或者产品问具体是什么情况导致的测试不通过。项目延期啊，线上出 bug 这类跟你都无关，你按照流程来正常工作就行。对方态度不好，你态度就公事公办。所有不给好脸色的同事我都不惯着。

看领导，领导偏他你离职（除非不提 bug 也发工资），领导正常继续提。

我个人觉得用例设计是需要一定的思考，不然容易设计不全。慢慢来吧

产品能发现的漏测说明是主流程上问题，或者是比较容易发现的问题。由于是新手，还是多积累经验，多想多测吧~~不要气馁

我遇到的大多开发（不止前端）对 bug 的态度都是积极修复的。
如果遇到这种不耐烦的情况，是不是可以找开发聊聊，为什么他会有这种情绪？

难道上线的时候没有测试报告么？就算没有，上线的时候也需要跟领导 or 产品去勾兑一下遗留未解决的缺陷 是否可以接受吧

我现在遇到的就是这种。现在我直接提 BUG，你爱改不改，领导问起来改了没，就在群里直接 @ 问

用例评审，大家都评审过了还漏测，就说明大家都有问题，就不要纠结于拉人背锅了，降低漏测是大家一起来干的事儿。

汽车相关的范围也太大了，整车这么多个功能组件，测试要点也不一样。首先得熟悉下整车通信的 CAN 总线协议，不同模块的测试内容可能也不一样。比如自动驾驶，可以仿真软件在环 SIL，也可以搭硬件在环 HIL，技术栈偏嵌入式一点，要对硬件比较了解。比如车载数据终端，要不断的把车的数据传到云端处理，云端可能就涉及到大数据处理和安全方面的测试，包括后面的一系列应用（手机 APP 之类）技术栈偏互联网一点。

我也是测试新手，可以给楼主一点建议：
1.漏测多半是用例设计时未考虑到，可以增加更多的时间去设计用例（可以用 Xmind 设计用例，再用工具转换成需要的）
2.用例评审环境，拉上研发，PD 等人进行用例评审 (这个很重要，主要是对用例查漏补缺)
3.探索性测试，经验问题，随着时间积累，会越来越了解所负责的产品，随之漏测的出现概率也会越来越低；总结就是多问，多去了解产品。

不要方, 大不了被开除换一家

漏测不可避免的，下次把业务场景多想想，尽量写全面，搞搞测试用例评审，一些不容易复现的特殊场景，做下标记等等

我觉得一楼说得很对，其实从开发角度看，能不被打断是最好的。

如果很严重的 bug，影响你的测试进度或者领导很容易问责，但开发还是不愿意修的，就向上反馈，让你的 leader 协助推进处理。如果你 leader 都推进不了的话，你就更推进不了了。

然后给领导验收的时候，可以顺便同步下一些已知但未修复的 bug，这样也不会存在领导发现后再问你有没有测试出来的尴尬问题。

新能源近期是火热赛道，据我所知，今年年终发的多

有流程参考流程，没有流程就加个流程。你提了还出问题，问题就不在你了。

非验证阻塞主流程的 bug 可以不用直接沟通，直接提交缺陷平台里，挂的名字是他，超过修复期限影响的是他的 kpi，而且你挂上去了也有证据表示测出来了，领导也不会问你测没测到过吧？

感觉整体流程都有问题，一个需求没结束，另外一个需求的优先级居然比修 bug 高。楼主也及时发现了这些问题，建议你梳理下全部问题早点反馈给上级，看看能不能推动跨部门的流程改进（如果实在推不动，那明确测试领导是不是可以接受这种带问题上线且没有开发及时修复的情况，能接受你就不存在背锅。）
我觉得这个过程中上级对信息的知晓非常重要，你要确认你发现的这些问题上级是知道的，负责的上级会协助你或者他直接去反馈了。

对了，我也遇到过类似情况，当时我换个环境一切就明朗了，哈哈哈哈。惹不起我还躲不起吗。

什么意思，没听明白