“码农翻身”一直讲开发技术，今天换个角度，从测试人员角度看看他们是怎么和开发“斗智斗勇”的，多些互相理解，多些沟通，团队最终还是要和谐共处。

文章的作者是松心耐雪， 公众号“心花绽放测试窝”。

虽说我们一直提倡开发与测试要和谐，但由于工作性质的不同，开发与测试必定存在对立面。所以对于测试来说，在BUG管理层面，最大的“敌人”应该算是开发了。

遇到能力差的或者不配合测试的开发则会相当累：

• bug会比较多。

• 修复bug的效率又很慢，极大的消耗了测试的精力。

• 测试在项目中往往没有话语权，所以对这些开发无可奈何。

那么不能改变这种情况的话，就只能用一些方法和开发“斗智斗勇”了。

下面会举一些常见的场景和应对办法：

开发说这个bug改不了

这是开发最喜欢的借口了，一般只是因为怕麻烦不愿意改而忽悠你。针对这种情况，通常有以下解决步骤：

1. 追根究底问清楚为什么改不了。

2. 咨询其他相熟的开发是不是真的改不了类似的问题。询问时要有技巧，不用透露人物事件，只需要针对问题本身。

3. 如果不是就可以向他透露点别人给予的修改方法，帮助他修改，

4. 如果真的改不了那就和开发讨论一下有没有其他方式去实现。

5. 叫上产品人员一起讨论是否可以改一下需求，以规避掉这个bug。

通过这样的死缠烂打的方式多试几次，你的“执着”会激起开发心中小小的波澜，他再也不敢把你当小白来忽悠了。

开发不分主次的改bug

这也是一种很常见的问题：当你提交了一堆bug给开发，开发往往都会先改简单的bug，而有些严重阻塞测试的bug却不改，这就会导致工作时间未能充分利用做测试，还要陪着开发加班。

站在开发的角度去想如果bug很多，肯定要多修复一些bug，那自然挑简单的修复，这涉及到了他们的一些考评指标。所以提bug的时候需要注意技巧，优先把重要的bug先提给开发，一些不重要的放在第二天去提交。让开发觉得今天bug不是很多，从而可以专心于修改重要的bug，他可以完成他的工作，测试也能以保证测试进度。

这是一种很好的策略，因为你就算一天提了100个bug，对于开发来说也不是一天能改完的，何不以主次的方式分几天提，让开发没有办法选择性去改bug，这样就达到了“操纵”修复BUG进度的目的。

下班前，开发提交修复版本

我想这是测试最痛恨遇到的事情吧，因为这意味着开发完成了自己的工作可以下班了，而你却要留下下来加班去做版本测试验证。如果bug都修复了还好，如果还有许多bug未完全修复，又要等到第二天找开发，而第二天开发修复的时间又会有空闲，然后再下班提交验证版本，从而进入恶性循环。

遇到这样的情况，第一种方法需要测试人员发挥主观能动性。在下班前2个小时去盯着开发bug有没有修复，还需要多久才能修复？今天能不能修复，让自己心里有个数，如果已经改完部分bug可以让他先提交测试版本，之后他改的bug可以到明天再提交。如果大部分都没改完那基本上今天也不太可能提交测试版本。

当然遇到一些不配合的开发索性就玉石俱焚（看到主人写到这里，为啥小编偶内心这么激动呐?），下班前提交一些bug（之前说留一些bug不提的另一个好处）让他加班改，然后测试也陪着加班，当开发改完提交估计也很晚了，就算再提交测试版本也有理由说第二天再测试，这样心理上也算得到了安慰。

当然介于测试在工作时总会处在弱势方，当遇到不仁的开发，那么适当释放点不义的小邪恶也没啥大问题。突然想到一句话：你不尊重我我尊重你，你再不尊重我我还是尊重你，你再再次不尊重我我就削死你！有些规则就是在博弈间诞生的。

当然这只是权宜之计，最好的方法还是要有一定的管理约束，或许把这个现象告诉你领导，让他说句话可能比你纠结100天还有用噢。例如，规定下班前1小时不允许提交测试版本或者开发要等测试验证通过后才能下班，而大多数测试是没有那么大决定权的，所以只能用这种办法尽量去减少加班吧。

除了以上3种情况之外测试与开发之间还有各种各样的矛盾。

• 测试会抱怨开发能力差到处都是bug，

• 开发会抱怨测试提了一大堆无法重现的bug；

• 测试会觉得开发拿那么多工资就应该做出好的项目，

• 开发会觉得测试什么都不懂就会瞎点和提bug。

其实多相互理解一下，站在对方的立场上去想想，也许就没有那么多矛盾了。所谓的“斗智斗勇”无非就是通过一些手段去化解这些矛盾，在不损害对方的情况下也保护了自己。有时候争吵和抱怨并不能解决问题，这时候需要这样的智慧去圆滑的处理问题。

所以"硬"技术是测试的立身之本，而"软"技能却是测试的成功之匙。  

    

（完）        

码农翻身，用故事讲解技术本质， 更多精彩文章，请移步《》