测试人员与开发人员的相爱相杀是一个永恒不变的话题，其实无论是软件测试人员还是软件开发人员，他们的目的都是一致的，那就是保证软件产品的质量，为什么“相爱相杀”中间缺的是一个高效合理的沟通方式。

1、首先得明确需求

需求是用户对产品的要求，软件开发是为了实现用户需求而完成的编程，而软件测试是为了保证开发能达到用户预期的设计，所以无论是开发还是测试，都需要参与到软件需求分析以及整理的过程中，针对同一个功能模块达到共识，在各自去完成自己的工作职责。

为了同样的目标和产品的早日交付建议测试尽早介入需求讨论直至确定阶段，在开发和测试对于一份需求文档进行理解，讨论以及整理。明确彼此的最终目标和产品方向。

2. 架构设计VS用例设计

根据需求，软件开发需要制定架构框架和主要解决方案时，测试同时开始设计用例，包括重要业务场景和复杂的逻辑流程。

测试经理/主管对主流系统架构必须了解和掌握，可以给出自己些许小建议，降低后期维护成本。项目经理与客户等应该也审阅测试用例，给出自己想法，这样多人进行相互支持，有利于弥补缺漏，这样可以在着手开发之前做到最详尽的计划，同时也会规避了很多开发过程中的一些琐碎问题，毕竟编程过程中一个小的修改或许会导致开发人员要走很多的弯路。

3. 开发编码VS测试脚本数据

根据制定好的开发说明说开始具体的功能及系统编码实现；同时测试人员得准备相关功能块或者子系统的测试数据。

建议测试人员多多学习白盒测试技术，这样写脚本或者准备数据时，可以不必周而复始麻烦开发人员来协助。开发人员也希望能尽可能配合测试人员，开放部分接口或者方法，加速彼此在单元测试级别的效率，即节省了来回折腾的成本。这样也能提高开发的效率，保证软件产品的质量，同时尽可能的缩短开发周期，对开发团队还是用户都是最好的。

4. 测试缺陷度量VS开发问题汇总

测试人员当然根据已有的规范、需求文档等对系统产品、程序，整个项目进行质量检查和控制。我们若能清理自己测试中对于问题缺陷的划分、度量，这样就能减少让开发重新修复、再现问题的时间。写测试缺陷、划分测试、给予某个问题正确的优先等级，这都能有效提高项目进度，节省彼此来回反复的成本。开发能一目了然看清每个测试步骤，所用到的测试数据，能一次复现问题，那就是好的缺陷描述列表。

另外，对于缺陷把握也适当，测试不可一股脑儿都抛给开发说有问题，除去明显需求问题外，负责人的测试可以自己去跟踪和定位问题性质。或许就是一个简单的小问题，在自己分析之后在去找相关的人员负责，而不是只要出现问题不管大小，全部抛给开发人员，这样面对没有任何分类的问题抛出，开发人员肯定心里不舒服啊，然后冤冤相报何时了呢。

5. 个人综合素质的体现

最后得强调一点，不是所有开发和测试都那么理想化的，实际情况各种不同。但最终由于个人，无论是开发亦或是测试人员的综合素质，体现了其把握、沟通、交流、工作的能力。无论是项目管理者还是参与项目的每一个人，能进行换位思考，能了解甚至掌握对方思想和技术，这样就可以相辅相成，合二为一，事半功倍。

另外作为开发人员在开发过程中对一些常见的问题可以在编程的时候自行处理掉，而测试人员在职业成长的道路上也会接触自动化测试等，所以互相学习，无论是测试还是开发都有自己的专业性，但是也不是区分的那么清楚，应该是你中有我我中有你的打开方式。