大吵一架，开发跟测试真的是水火不容的吗？

测试和开发应该是一边的，工作中大部分矛盾来自不合理的项目排期管理和有限的研发资源之间的矛盾，排期紧张或者需求变更导致矛盾被迫转移到了开发和测试之间

开发和测试的利益完全看公司怎么管理和设计奖惩制度的。

测试独立出来成为一个职能的目的，就是用不同于开发人员的视角（尽可能的贴近用户）来对程序功能做测试。
本质上是为了尽可能避免项目进入到投产阶段之后才发现问题，轻则导致返工，重则造成损失。

按我的理解，正常情况下，测试帮你把 bug 测出来了，是好事情。
如果是程序逻辑上的问题，那你确实要感谢他；
如果是产品设计上的问题，那你们应该一起找产品，讨论设计是不是真的不合理，不合理的话怎么修改设计；

除非你们公司属于那种被测出来 bug 就要扣绩效的，那我建议你跟管理层反馈一下这个制度的不合理，或者干脆换一家公司。

做了这么多年开发，我还真没怎么跟测试吵过架，倒是经常和产品撕逼。

我告诉你，有些用户的操作比测试人员还无厘头

测试的目的不就是帮你查漏补缺，堵死预期外的路径？只测正常路径功能是否实现，那需要测试吗？

这次我站测试。1.看描述没有提紧急 bug ，你最好的做法是商量看能不能关掉或者有时间再改 2.“根本没吃透”，指望测试吃透有点强人所难了，你说的话是有点阴阳怪气，有时间跟他说怎么回事，没时间就转产品

我和客户吵过，我和领导吵过，但从来没有和测试吵过，我认为是伙伴，就跟狙击手有个观察手一样。
测试是帮助开发找出问题的，是让产品完善的。
测试可以提 case ，但如果不是问题，开发可以解释。
如果有争议，可以开多人评审会议，集体讨论，领导拍板一下。

测试不就是瞎点吗？要是都按流程来那还有什么 bug 呢？既然有前置条件你就拦截啊，没有弄完前置条件为什么要进行下一步呢？你的问题比较大，用户管你这的那的

和 lz 的情况有点相反，有种测试更无奈，每让她测一个功能都让开发给她讲一遍测试流程和测试点，这不应该她自己读需求然后自己设计吗？倒不是怕费劲，问题是这种流程如果是开发告诉她了，那还要测试干嘛呢，开发自己就测完了，测试就是应该按照自己的方式去测才能测出问题啊

@BenCoper to 30,等你写完 jira,我已经改好了

@wayfarer +1

没 UI 啊 就靠狗产品那个破原型？

不要两人讨论，至少三人

测试用例里面包括正常用例和异常用例，正常用例我相信开发自测的时候都能覆盖到，那么测试关注的重心肯定在异常用例上，本来就是来搞破坏的，所以除了正常功能点验证后，测试肯定是随便点的，这个叫做探索性测试，根据测试人员对业务的熟悉程度以及长期使用项目或产品的感觉，专门就会做集成测试或者说重点关注有关联的地方，因为单一开发只会关注自身开发的功能模块，比较少关注和其他开发一起集成的功能。
不知道你们的研发流程怎么样，按理说，需求设计测试用例都需要评审的，在全员认知一致的情况下，很少需要争吵，毕竟需求有争议是可以找产品经理明确的。

@mumbler 这算啥, 我们公司开发给测试吵哭过, 开发还有过周末拉男朋友来公司加班帮忙改代码

下次直接拉上产品🤣

老段子，测试本来就是为了用户不遵守规则，而导致系统崩溃或者造成无法使用吗？
一个测试工程师走进一家酒吧，要了一杯啤酒；
一个测试工程师走进一家酒吧，要了一杯咖啡；
一个测试工程师走进一家酒吧，要了 0.7 杯啤酒；
一个测试工程师走进一家酒吧，要了-1 杯啤酒；
一个测试工程师走进一家酒吧，要了 232 杯啤酒；
一个测试工程师走进一家酒吧，要了一杯洗脚水；
一个测试工程师走进一家酒吧，要了一杯蜥蜴；
一个测试工程师走进一家酒吧，要了一份 asdfQwer@24dg!&*(@；
一个测试工程师走进一家酒吧，什么也没要；
一个测试工程师走进一家酒吧，又走出去又从窗户进来又从后门出去从下水道钻进来；
一个测试工程师走进一家酒吧，又走出去又进来又出去又进来又出去，最后在外面把老板打了一顿；
一个测试工程师走进一家酒吧，要了一杯烫烫烫的锟斤拷；
一个测试工程师走进一家酒吧，要了 NaN 杯 Null ；
一个测试工程师冲进一家酒吧，要了 500T 啤酒咖啡洗脚水野猫狼牙棒奶茶；
一个测试工程师把酒吧拆了；
一个测试工程师化装成老板走进一家酒吧，要了 500 杯啤酒并且不付钱；
一万个测试工程师在酒吧门外呼啸而过；
一个测试工程师走进一家酒吧，"< script >alert("要了一杯酒");< /script >"
一个测试工程师走进一家酒吧，要了一杯啤酒';DROP TABLE 酒吧；
测试工程师们满意地离开了酒吧。
然后一名顾客点了一份炒饭，酒吧炸了。

这个很简单啊，看是不是真的测试问题。如果是的话就 bug 回复清楚，写明不修复就行了。这点事我都不会和他有任何线下或者其他方式的交流。如果真的是那种用户很容易触发的异常流程，还是做好权限管理和异常检测吧。大不了弹个框啥的挡住就可以了。

流程不健全，就会导致沟通不足，产研测对需求的理解不在一个点上，出现这种事太常见了。
而且说实话对于研发来说，测试从来都不是你的敌人，少一点对抗的心态比较好。

测试没问题，实际用户就是瞎用。你不能说用户瞎用出 bug 是用户的问题吧，最后不还得自己改 bug 吗