日常的工作中，每天都会与开发工程师打交道。我们服务的核心对象也是开发同学，和开发同学保持较好的合作关系，很大程度上影响了测试工作的好坏。
谈谈自己的一点看法：
1、加强开发团队对缺陷和测试人员的重视程度，规范开发测试流程，从根源上解决问题。 开发和测试的矛盾来自于缺陷，也终止于缺陷。 开发团队的领导技术觉悟，可能会直接影响到成员和测试人员的合作，如果开发团队领导对缺陷都视而不见，对测试认知度有限，开发同学就可能会对bug产生抵触情绪。 采用适当的培训来提高开发团队对测试工作的认识，可以使开发同学提高代码质量意识，更加尊重测试的工作。如果可以有一个非常明确的开发测试流程，并能够将代码质量计算 到每个人的能力考核范围内，那么测试的工作会好做很多。目前公司很多的需求跟进、代码review工作都理所当然的由测试来负责推进，这种现状其实不利于测试人员解脱出来，专注于测试 本身。
2、引入缺陷统计工具 缺陷解决周期及质量可以一目了然，提供给开发和测试同学一个渠道去查看团队成员的代码质量、缺陷频率、线上代码存在的隐患等等。 同时，对于某一个项目来说，缺陷统计工具提供的数据可以做为一个数据仓库以提供各位老大们做各种数据挖掘，比如某一个项目在引入自动化测试框架后，bug频度和数量是否了 下降，某开发团队引入code coverage工具后，首版本严重级别相同的bug数量是否有降低。
3、简化开发测试间的缺陷沟通渠道，避免无效bug。 我们可以先来个换位思考，如果我们来做开发，什么样的bug我们乐意改，什么样的bug我们最讨厌？
我大概想了想，有几下几种：
最喜欢的bug：
1）容易改的；
2）可以让代码更简洁的；
3）不需要重构的；
4）改完了有种成就感的；
5）这个bug不被发现可能影响重大的；
6）可以让我有技术成长的；
......
最讨厌的bug：
1）费了半天劲但发现是个无效bug，测试根本没搞清楚需求是什么；
2）吹毛求疵的小问题，而且很费时间的问题；
3）可能是个问题，但我从bug描述上根本看不出是什么地方出了问题；
4）我只是遗忘了一个sql脚本，结果QA给我提个P0级别bug，至于么？
5）测试库都是垃圾数据，你们为什么不清一下就总说程序有问题？
......
综上，应该尽量做到以下几点：
1）前期的需求明确，达到开发和测试认识一致是前提；
2）bug的描述尽可能清晰，优先级尽可能准确，尽可能深刻，最好深入到代码级，避免重复的bug；
3）减少随机测试带来不可重现的bug，如有可能，尽量所提bug都是可以重现的；
4）能够和开发同学说明bug的严重性和可能带来的具体风险；
5）减少对开发同学的技术依赖，建立技术尊重。比如自动化部署、独立掌握测试环境、了解一定的代码逻辑等等。
4、引用台企的一句话“Work Smart”
1）注意bug提交的时机。严重的bug如果在上线前才提出来，大家都会很窝火，开发即使不埋怨心里对测试的信任度也会打折。同时，目标对象的心情也很重要，即使你很资深，开 发人员关机了准备走，或者和女朋友约了吃饭，这个bug被处理的可能性肯定很小的。
2）对事不对人。一个标题鲜明的严重bug列表也许会让pm觉得项目问题很多，同时也会让开发很“没面子”，特别是一堆无关紧要的问题被标红和罗列成一屏幕的时候，会引起很 大的反感。这种情况应该尽量避免发生。同时，测试应该尽可能只就事论事，讨论bug尽可能理智和克制，有耐心，避免和开发同学因为bug争吵。这样才能够很好的说服开发修改 缺陷。
3）和开发搞好私人关系，做开发的朋友： 尽可能站在开发角度考虑问题，特别是开发同学遇到困难的时候，使开发同学认识到测试不仅仅是找茬，而是在协助他完成他的工作。这样既能够解决问题，又能够交个朋友， 何乐而不为？
以上仅是个人一点想法，欢迎拍砖！谢谢！
本文出自seven的测试人生公众号最新内容请见作者的GitHub页：http://qaseven.github.io/
