1、首先得明确需求

　　测试到最后发现某模块根本没有按照需求来做，或者开发理解的不一样，这在平时项目工作中太普遍了。

　　个人建议测试尽早介入需求讨论直至确定阶段，在开发和测试对于一份需求文档进行理解，人各有思，当然会产生问题。通过会议，或者直接面对面交流，可以很有效的规避两方产生的不同意见和见解。使得最终大家都朝商榷的需求去实现系统产品，完成项目。

　　2. 架构设计VS用例设计

　　开发在制定架构框架和主要解决方案时，测试同时开始设计用例，包括重要业务场景和复杂的逻辑流程。一般用例都是客户验收会审阅。架构也最多是研发总监、项目经理可能会过目。

　　个人建议测试经理/主管对主流系统架构必须了解和掌握，可以给出自己些许小建议，降低后期维护成本。项目经理与客户等应该也审阅测试用例，给出自己想法，这样多人进行相互支持，有利于弥补缺漏。

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

　　开发实现系统，写代码；同时测试人员得准备测试数据或者编写部分脚本辅助。

　　个人建议测试人员多多学习白盒测试技术，这样写脚本或者准备数据时，可以不必周而复始麻烦开发人员来协助。开发人员也希望能尽可能配合测试人员，开放部分接口或者方法，加速彼此在单元测试级别的效率，即节省了来回折腾的成本。

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

　　这里我把测试放前，表明这块儿是最容易产生矛盾和增加成本的节点。

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

　　另外，对于缺陷把握也适当，测试不可一股脑儿都抛给开发说有问题，除去明显需求问题外，负责人的测试可以自己去跟踪和定位问题性质。有些缺陷不是问题，也许就是个小疏漏或UI错误等，可以完全给出自己想法和建议修正点。这样开发工作会减轻，也体现了测试人员的技术含量。当然有效降低了彼此反复争议某个缺陷是否如何重现、是否能算一个问题之类的时间、精力。

　　5.测试报告和结果

　　问题缺陷理清楚了，测试若讲最终报告和测试结果也能详细、清晰地整理出来，让开发方面易懂，让客户和上层领导了解项目质量情况。那一份文档就可以完成所有事宜。测试方只要拿出干净的结果和报告，进行阶段汇报即可。

　　个人建议根据内部规范或者行业标准，测试结果应该包括测试场景、测试方法、测试数据、测试结论等核心组成部分；报告则给出最终的评审度量总纲即可。

　　6. 领导对两方的支持

　　很明显一个优秀的PM或部门大佬，会有自己手段来安抚开发和测试的关系，我们开发和测试切记不是敌对找茬儿和挑刺的关系，而是一个为高质量项目、产品共同努力的优秀团队。领导在开发和测试产生重大分歧时，必须进行梳理和调节，给出自己的想法，使得大家目标统一，意见想法都一致。

　　7. 个人综合素质的体现

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

　　故而现在测试开发、开发测试，已经越来越模糊其界限，在技术、方法日益更新的今天，提高自身业务水平和技术能力，就可以节省各种成本。