@wx497657341 #18 这不就是一条 case 吗，很合理啊，测试不就是要测试各种意外情况，难道你要测试按你想的来测，那还要测试干嘛 而且你说话也不太对劲，一看就是直男死板程序员，不会好好说话，你说的“这个功能的逻辑在需求里写得很清楚，建议先把需求吃透再测”，你这不就是在质疑人家的工作能力，就算你真有这个意思，你也不能这么说啊，情商堪忧 见了太多这种死板程序员了，不喜欢沟通只会默默敲代码，沟通能力、人际处事能力差的要死，一个好的程序员可不仅仅只是敲代码，沟通能力远远大于代码能力

明显是开发的问题啊，测试就是要跳出各种前置条件

@Thresh #24 万一用户就会这样操作的呢，这不就是一个 bug 吗，不管是交互还是没出对应提示 toast 就算用户不可能触发这个逻辑操作，开发完全可以回一个：线上用户是触发不了这个逻辑的，不用管这个问题，然后这个 bug 不置会就可以了，然而他回了个：这个功能的逻辑在需求里写得很清楚，建议先把需求吃透再测，这种谁听了不恼火

作为一名测试.我好像从来不直接跟开发吵.因为没意义.吵不出什么结果来.我都是跟开发一起和产品吵.跟产品一起和开发吵.或者看着他们两吵.然后给我一个结论.

气大伤身、更它吵没有意义 最后可能还得是你改

这是你的问题噢

写代码不是打打杀杀,是人情世故. 你说话方式欠妥,我看我也红温

@BenCoper 个人觉得这个流程不太对。。。 首先，合格的测试，应该有能力判断出当前的场景到底是不是问题，如果判断出了是问题，即便是优化类的问题，那为什么还要找开发一起看下？测试别的工作就不干了，干等着这个结果么？这个效率是不是太低了？至于问题出在需求上还是代码上，这个是开发和产品应该有能力判断出来的事情。

op 表达的不清楚 . 如果是测试对需求理解的不对 .毋庸置疑是测试的问题 如果是测试随便点,出现了预期之外的结果 ,毋庸置疑不是他的问题. 可能是需求不完善.或者你没考虑的全面. 但是无论那种情况 都不值得和测试吵起来了.

流程有问题就把产品拉进来