测试就 2 点 1 、测试预期是否符合 2 、测试意外是否规避 看你描述的就是开发的锅。没有处理意外情况

你的接口只返回成功的情况吗，不返回异常的 code 嘛

在过去工作经验中，很多开发和测试遇到的问题，追溯源头，都是产品带来的。抛开人的问题，应该是新功能和旧的框架融合的问题。功能越多，越容易出错。功能很大部分决定了后续事情的发展，后面的人只能在沼泽地里改善，有经验的人会一开始就不接那个功能

开发，应该参与测试用例的评审，并把测试用例作为自己的工作输入之一！

心态得变下。内部系统你这还可以，放网上大家用的不要相信用户的操作。

测试就是干这个的，要是是需求问题，拉上产品吵，别的你就打哈哈改好了，哪有程序没 bug 的，早点发现在测试阶段大家都开心（前提大家都是正常人）

要是测试没提 BUG ，到了用户端出了问题的话，估计就变成 SB 测试这种 BUG 都测不出来。

跟人的沟通意愿有关系，语言本来就是 你一句我一句的，有些人脑子就是笨，听不懂就把自己的逻辑一直重复讲，不听别人说话。 还有能不能拎的清边界。

你和他平级，吵架很正常。 就问题单来说，有个项目经理应该审核一下问题单的质量。 如果剩下了这个审核角色，直接流到你这边。 那必须有个回溯质量的过程，无效问题单数要能影响他绩效才能扼制浪费研发时间的事情发生。 [至少他应该来和你先沟通，后提单]

你这有点生在福中不知福啊，我都是让测试没事多跑跑，尽量跑出问题来。