你们是怎么跟测试打交道的？

@CinderellaCiCi

觉得重要的改掉
不重要的让测试去和老板商量优先级

楼主是做后端的？
我做了2年测试感觉前端问题是后端的几倍啊
怎么会今天上来发牢骚

1. "好像是为了追求bug数量"，
看公司的制度了，有些sx公司对测试人员有bug数量激励，不过这种sx公司应该消亡了吧。如果还有，赶紧走；
2. “或者自己对需求不理解”
* 看项目流程规范了。正规公司尤其外企，Tester都是从Requirement/Specification阶段开始一起工作的，包括参与各种会议。有些外企，反而是BA和Tester最先接触项目需求或者客户，早于开发。
* 开发概要设计或者原型出来的时候，Tester那边的Plan/Risks/Test Points基本也都成骨架了。因此，如果出现Tester对需求不理解，说明流程有问题。
* 最不济，前还有个Test Plan & Test Cases Review吧， 开发也要参与的，至少听听/大体看看case介绍，目的就是找出遗漏、case设计不合理，甚至需求理解错误的地方；
3. “根本不能这样测”
* 这个好说。因为如果是黑盒测试，或者end-2-end测试，测试人员考虑的角度就是用户角度，纯小白、纯透明角度。因为用户不会知道你咋实现的，不可能自觉的“我不能这样用”。
* 这点倒是开发和测试工作思考角度很迥然的一个地方，也最容易产生分歧的地方。

其实，本质都是为了和Requirement和Test Case对上号，“合格”出厂。
所以，沟通一下，有个track就OK，实在解决不了做不了主的就开会喽，不然头头是搞毛用的，就是拍板的。
另外，我朝对测试的不重视，流程的不规整，还有测试的薪水。。。整体上外企好一些，国内大厂好一些。

既然提出来了，说明客户有可能会按照这样操作 ，不妨参考一下
如果是可笑的bug，那就关掉或者不予解决。。。

不应该有“根本不能这样测”想法，测试的基本价值在于发现问题，并不能去局限发现问题的方法和手段。

对于提交上来Bug，开发人员的第一反应应该是确定“这是不是一个问题”，而不是去想“这个问题重不重要”或者“这个问题要不要修”。如果不是问题就标为Not a defect，解释原因，与测试沟通，关掉。如果是问题，那就再去考虑它的优先级和处理方案。“Not a defect”、“Won't fix”或“Defer”对于开发来说都是不改代码，但是它们的含义和对后期的影响是不同的。

至于怎么跟测试沟通，测试也是人，人与人应该怎么沟通就怎么沟通。“说不清楚”、“沟通困难”并不一定是对方的问题。

有发现过“自己对需求不理解，或者根本不能这样测”的这种情况，特别是对一小部分不上心的测试人员

我们的解决办法是对该类 bug 标记 invalid，invalid 一般来说是测试人员对需求理解错误或根本就没看需求。 Bug 数量的奖励 和 invalid 是相互相成的，一个奖，一个惩。就我们运行的情况看效果还不错，基本上经过一段时间后就不会出现这种问题。

B厂？
正规项目对于严重线上事故，测试要承担非常大的责任。所以重要修改都需要测试同意才可以上线。
只是这对测试的要求非常高，甚至高过开发。但B厂那些小孩儿，呵呵呵。

@lifanxi 比如改数据库数据测，根本不是这样改。有的测试人员对技术基本不了解，你跟他讲为什么或者什么原因导致的很费力。

测试水平这么差？
我们测试完全主导产品release进度，有的还负责code review.开发的人有的知识不知道了就找测试的问

测试都是大爷！
好吧 玩笑 我们测试都是认真负责的妹子
我们测试跟开发都是在一个组里 有问题直接心平气和的说清楚就好了
前面有人说由于对技术不了解 解释很费力 这也有沟通上面的问题 不要把责任都推到测试身上
我们一般填好issue/ticket单子 包括需求文档的链接/邮件/直接内容、写好代码库/分支、环境准备命令、涉及到的功能 测试步骤
而且有时候 你在开发的时候就需要想到测试怎么测试 怎么跟测试解释你的思路想法 这也算是对自己逻辑的理论验证吧 可以加快测试速度减少返工次数~

@Septembers 艾特我干嘛~

我一般采用爱抚的方式......

没什么好不愉快的。他追求bug数量，只能说明他们的考核机制制订的有问题。

找你们主管沟通下你遇到的问题，为何你觉得对方是在无理取闹，由你们主管去解决这个问题。（不然当这个主管干嘛，至于怎么解决是他的事）

我只能说，职场上，什么人都有。技术水平、处理问题的习惯、沟通技巧，你不能要求别人都与你在同一个平面和层次，要不怎么会有一些公司用各种方式评定和细化职位类别、能力层级、职级之类的？

@tanteng
测试有很多种，比如：功能测试、系统测试、压力测试、性能测试、探索性测试。

直接改数据库，把数据完全改成不可用（正常流程甚至出错流程中都不可能出现的情况）或者甚至把表都Drop掉可以看成是探索性测试的一部分。

各类测试要不要做，测试的期望结果是什么，都是可以在做测试计划时由项目经理、开发、测试一起来确定的。

当然，现实中肯定会遇到不靠谱的人，包括不靠谱的测试，也包括不靠谱的团队、不靠谱的领导。这时如何去沟通、如何去共同推进问题的解决，是一个更泛化的问题。但是有一个基本原则就是多想想“我能做什么去改变我不喜欢的现状”。

我会根据QA的颜值去处理

哈哈，如果你碰到产品参与交付测试的时候给你提出N多奇奇怪怪的bug，你更要吐槽了。我之前的公司，产品参与测试后的结果就是:1、所有产品自己没想到的都认为是bug；2、所有产品在需求商定后的需求改动都认为是bug(哪怕是3分钟前他要求的改动)；3、(因为产品要求必须和原型一毛一样，像素级)觉得产品做出来不好看的，提开发的bug.......类似这种，楼主你觉得跟你们的测试比起来怎么样？

在我这无法复现

虽然bug对我们开发人员没影响，也不扣工资

lz这种逻辑感觉不是很好

我以前东家测试的都比较牛逼 无论是技术理论还是动手能力
当时两个资历差不多的 一个测试一个研发去面试鹅厂 前者轻松进去 后者技术面被卡住了。。

@ufo22940268 我不是说这样就无所谓了

简单来说:
如果是bug,改,别管他怎么操作出来的.能复现的必须改,不能复现的慢慢来.
如果是测试的"建议",或者他觉得应该修改产品需求.那就转给产品.

珍惜测试人员，在一些小公司，没有测试人员，开发要自己做测试，那个才叫痛苦。
测试人员确保了质量，在上线前帮你测出了bug，帮你分担了责任。

他认为需求要改一下，提个bug，“这里建议XXXX”，这是产品的事情吧。

实际上项目组所有人都有对产品提建议的权利和责任，应该多多提倡。

”这里建议XXX“ 不完全是产品的事情。

是不是产品的事情取决于他提什么样的建议了。
若是真正意义上的“建议”，你可以认为他是在为产品操心，他只是想让产品做的更好，你鼓励与否，这个看你们。
但还有一种建议是“修改可能造成这个bug的原因”，难道你知道bug原因之后，以及某些地方可能会存在逻辑缺陷引发出更多的bug时，虽然这个bug还没发生，而你又没有权限去操作页面逻辑，那么你会不提建议吗？

分几个bug提， 这个属于不好表达的一类bug吧。本着尽责的出发点，全部列出自然会让你们更容易判断。 毕竟两点一线，直捣黄龙。

提bug之前先“嘴遁”确认一下，这样大家都感觉挺好的。

遇到过死脑筋的 解释了原因后还认为是bug

我不会和测试一起打交道的,我只会和交道一起打测试.

开发兼测试

测试和运维都是开发的重要(hao)搭(ji)档(you)，虽然前者一直在提bug，后者老不让你上生产，但最能帮开发分忧的也是他们，帮你减少线上bug少出生产事故的是他们，帮你提高系统鲁棒性稳定性，出事故时能有退路的也是他们，有这个心情和测试撕逼，不如约好一起去暴打产品狗（玩笑）

测试不了解需求，就推动他去了解需求。测试不了解系统，就介绍系统让他对总体结构有所认知。测试提建议型的ticket，就完善分级分类，优先级高的，blocking的解决，suggestion的improvement的可以即时做掉也可以延后。总之就是要协助测试让他能更顺畅地发挥他的作用，而不要“应付“他。

不如说无论是对测试还是运维还是产品还是设计，从协助对方的角度出发，一切好谈。毕竟团队里的每个成员的总体方向是一样的，你说呢？

@ipconfiger
同意 爱抚+1
另外, QA 部门有些建议并不是为了凑数.
虽然提升产品用户体验是产品部门的事, 但多思考难道是坏事嘛?

个人感觉把提交bug的数量作为测试绩效考核的测试团队都是不懂开发和技术的。
例如鄙公司，测试都是手测，提的bug多，组长就认为工作好，还时不时自作主张提个改进需求，泥马客户都没提的东西。管项目也是搞笑，有时候用测试来催开发干活，督促进度。。。
所以如果是这种大环境上问题，改进个人方面的沟通也没多大用。

@lifanxi 中移动的iOS客户端，在点击获取验证码按钮后，按home键，再次进入，发现时间倒数是暂停的。这类问题属于什么？

对你们的测试需要进行培训，告诉他什么是他的工作内容，需要他来管的，什么不是。

建议什么的，应该先指派给产品/策划，不应该提了个建议，但是指派到开发那边去。

说到底还是流程的问题（单大部分小公司根本不关心这个）。

我一直认为QA工程师，先要是工程师，然后再会测试，写的代码比开发还好才配得上。

你们的测试人员太烂，辞掉重新招吧。你们公司要是不舍得招这样的人测试，你为难你现在的测试同事干啥。