测试小伙伴们，你们有遇到下图的情况吗？

　　这张图其实还算“温柔”的，其实有些情况下，某些测试人员或者开发人员脾气大的可能撕逼或者快干架。所以如何和开发有效沟通，并高效劝说开发改掉bug是一门学问，以下是我总结八年测试经验给测试新人的一些建议：

　　1、和开发人员保持友好的团队关系。这是最重要的一点！

　　我以前遇到一个开发，刚开始给他提bug时，他是各种抵触情绪加敷衍。后来我就私底下和他多接触，了解他的脾气，久而久之他也和我熟络起来，结果不仅不再有抵触情绪，甚至还帮我主动定位bug。其实人心都是肉长的，我们做事既要讲理，也要适当打打“感情牌”。注意跟开发沟通的语气，要有换位思考的意识，做事情对事不对人，对待开发要确保在解决bug的前提下尽量不伤和气。也只有这样，才能够很好的说服开发去修改Bug。当然有时候我们也会遇到强势的开发，油盐不进的那种，对我们的测试工作带来层层阻力，我也亲身经历过，但是这种开发毕竟是少数，如果真遇到了那就具体问题具体分析吧！

　　2、要确定这是一个真正的bug

　　不要出现因为配置原因或者是操作错误引起的“bug”，这样是会被开发“鄙视”的。最搞笑的是自己测错了版本，然后测出了老版本的问题，那就尴尬了。或者自己电脑网络问题，结果以为是服务器响应问题，这样的失误多了肯定降低自己在开发心中的地位。作为一名测试人员，我们应该树立在开发心中专业的形象。这样说话才有分量。遇到问题先别头脑一发热就去找开发询问，哪怕有些自己不确定了也尽可能自己想办法确认问题，确定是bug了再去找开发。一定要记住，我们可是专业的“虫师”?！

　　3、尽可能写好bug描述，方便他人就是方便自己

　　以前我工作中遇到过一个现象，就是同组的女测试每次提的bug都能比我解决的快，我当时很纳闷，就去询问开发人员，这是性别歧视还是怜香惜玉呢？结果开发只回了一句：“她解释的更清楚，你的需要反复核对才能确定！”从那以后我痛定思痛，在缺陷管理工具中会将bug的详情描述的特别清晰。而且咱们测试描述地越清晰，越具体，开发才会更加佩服你的“专业”。

　　Bug的描述尽量详细且浅显易懂，确保没有歧义，复现的步骤一定要条理清晰，你的预期结果和现有的结果，截图也要尽量标注信息且清晰。如果是特殊的测试数据，我们还需要附带这些数据。

　　对于复现率很低的问题，需要注明复现率，详细记录当时的测试环境信息。如操作系统、产品名称、版本、操作步骤、是否机器相关、是否产品相关等。

　　4、提升自己的专业技能

　　我刚入行时遇到一次特别囧的经历，有一次给团队的开发提Bug,结果新来的女前端跑来质问我，一个后台问题怎么提给了她前端。当时我才明白，我们测试打铁必须自身硬，必须具备对bug的基本定位能力，就比如刚说的Bug，如果我当时会F12看下报的是502问题，肯定就不会提交到前端开发人员那去了。

　　其实我们测试人员，首先是对业务分析的能力。要充分熟悉我们软件产品各个层面的业务，包括功能业务，代码实现逻辑，环境配置部署等。特别是做功能测试时，我们必须对所测模块的需求很熟悉，要比开发人员更熟悉。或者说一名专业的测试人员，可能比客户和PM更懂这块的规范。其次我们必须具备市面上常见的软件测试技巧，掌握主流的测试工具。比如为了更高效测试而采取的自动化测试！说到这，你应该很自然地想到也应该具备基本的代码阅读能力吧，要想成为一名优秀的测试工程师，我们应该知己知彼，知道开发是怎么个代码逻辑实现需求，从而能够更精准的定位深层次的问题。

　　5、测试应把握重点，切勿胡子眉毛一把抓

　　这点当然也是测试界特别需要注意的一点，那就是在有限的测试时间内我们应该有舍有得。我曾经在这块有过一次争的面红耳赤的经历，之前我们做过一个交通方面的OA系统，我当时为了全面保障项目质量，在产品需求之外进行了一次性能测试，结果Jmeter测出来并发100用户时系统就崩了，要知道我之前测的再小的OA系统也能承受500以上的并发。所以我当即就找PM和主要开发人员反应该问题，本来以为他们在惊讶之余会立马解决该性能问题，结果得到的答复却是：“我们这边对性能没要求，你只要保证主要的功能没问题就行”。当时初生牛犊不怕虎的我，自然不肯放过这样的低级性能问题，所以又去找总监拿主意，结果开发知道后很是生气，最后也还是按照产品需求的基本功能实现就交付了，理由是小项目时间紧，任务重，人员少，只需要保证需求的实现即可，其它性能可以放到后期版本再去考虑。

　　其实现在市面上很多公司都是初创，很多项目都是人员少时间紧，所以要求我们测试应把握重点，不要在无关紧要的地方测试过多。切勿为了无关紧要的“bug”浪费沟通成本。什么是重点，就是产品的主要功能和市面上该产品的主流要求，用户经常会用到的操作。

　　如果是需求明确的严重问题，相信只要是开发，他都会想法设法去修复它。但比如说，一些非常规操作导致的严重问题，开发人员会说，实际场景中，用户是不会这样操作的。

　　对于这些问题，沟通是很浪费成本的，可以把问题记录在日报中，反馈给测试老大或项目负责人，由他们来评估。再比如说一些个人界面建议，我们可以提交bug，但是开发不改，也不影响用户使用的，我们不用过多纠结，只需做好记录备案即可。

　　6、集中火力开炮，将遇到的问题一起问开发

　　软件开发行业每个人都很忙，特别是忙着敲代码的开发更是极少有耐心，问的多了甚至对你口吐芬芳，所以不要一发现跟预期不清楚的就去询问，因为在忙的情况下，很大程度上你抛过去的问题都会被无视。聪明的做法是把你需要问的问题做一下整理，集中起来问开发。如果这种方法还是不行，我教授你一个诀窍，那就是搬把椅子坐他身后，你看他能无视你到多久，哈哈！?

　　所以测试这门学问，不仅是要具备测试的“智商”，更要讲究点“情商”。将心比心地去换位思考，揣摩开发的内心世界，我们才能驱动开发去做他们本不愿意的事情，才能够高效地解决掉bug！

作者：有房车的直男    

来源：http://www.51testing.com/html/96/n-7798896.html