引子：项目前期测试人员未参与到项目中，开发人员只了解自己的功能业务、测试与开发的沟通常因需求理解不一致而向项目经理确认需求的情况；基于以上的劣势，现提出一些个人的看法：
在进行软件测试时，首先确定我们的目标。我们需要开发1个高质量的软件系统吗？如果是肯定的，我们不妨来设计一个大家可以接收的需求挖掘和评审方法。
一、项目前期项目组参与需求调研工作的必要性
在项目立项后，相关项目负责人进行需求调研与需求整理。俗话说：“三个臭皮匠顶个诸葛亮！”在需求调研时，整个项目团队参与到需求调研的研讨会中个人认为是很有必要的。就需求获取有1个小方法：
1）需求方向项目开发组以小组的讲解的方式提出需求，并讲解系统中的每个线上业务以及线下业务。
2）需求人员记录好每条需求，其它干系人记录好不清楚或不明确的的需求；等待需求人员讲解系统的需求完毕。
3）每个人把有异议或不清楚的需求拿出来讨论。
项目组参与需求调研的好处：1、每个人的经验不一样对需求的理解不一致，可以发现很多隐性需求（因为用户不了解系统实现的过程，需求转换为一个系统，系统中必然或多或少会有一些隐性问题的存在）2、项目组参与到需求调研可以让项目组成员对系统的全局有个深入认识，开发人员在开发过程能更好把握程序实现细节；测试人员根据一些测试经验可以对系统的需求合理性、准确性作进一步的学习和校验。
二、需求评审的方法
项目相关责任人整理好需求并编写成文档后，测试人员对需求进行评审。
在评审前1）选择2个经验相当的测试人员2）测试人员在评审前先仔细阅读一遍需求说明文档。此刻开发进行需求评审，2人一起同时对每条需求的看法进行沟通，如果意见一致，这条需求则标记为通过，遇到意见不一致时，标记此条需求待定；当整篇需求审查完毕后，对意见不一致的需求进行讨论并得出这条需求的正确结论并修改需求通知需求相关责任人。
三、开发人员对系统需求转换功能点的重要性
开发组进行概要设计时需要把整个系统的流程以图表的形式进行分解，展示系统的整个业务逻辑。如果开发人员对系统模块的关联性熟练掌握，对数据的流向和数据准确性就有了1个很好的把控。
详细设计时详细设计文档中把1个功能模块的功能点的实现进行详细说明，某个功能点从哪里获取哪个字段，某个字段的修改对下个模块有什么影响，这些细节性规则需在详细设计文档中备注说明。
如果开发人员对整个系统或自己的模块有了一个全局的认识，代码的可靠性和稳定性自然提上去了。
四、测试人员掌握需求后，须吧需求转换为系统测试的测试点
现在开始来分解分解系统，分解系统的思路是：线---à点---à面
我们首先来抓住主“线”--即系统都有1个主流程和多个分支流程，首先保证各个流程是否畅通，
其次我们关注的重点是系统的核心功能点的某个功能点的特殊逻辑校验正确性、以及核心功能点的数据流向是否准确、修改基础数据中的某个字段或某条数据是否可用对其它模块的影响，保证基本功能“点”均正确。然后考虑异常流程、组合功能、数据显示、数据刷新方式、提示信息、操作优化等问题“面”面俱到的测试。
确定好测试思路后，开始测试点的设计，在测试用例或测试点设计前，采用结对方式分解系统。
1）由其中1个测试人员对系统的测试点进行讲解，第2个测试人员记录。
2）由另一个测试人员对系统的测试点进行讲解，第1个测试人员进行记录；然后把2个人的测试点进行对比、整合。把测试点转化为详细测试用例或转化为详细用例图标去展示系统测试点。
五、变开发边测试的常见应用
当开发人员开发好1个功能模块后，发布到测试环境中，测试人员对1个个模块的功能点进行逐个测试，当一个大模块集成了好几个小模块后，对这个大模块中几个小模块之间的数据流向、数据准确性、数据显示刷新进行测试；依次类推下去直到整个系统集成成1个完整的系统，在这个测试过中我们做了单个模块的测试以及模块模块与模块之间的测试，这就是集成测试的过程。
六、系统测试为主开发修改Bug不断完善系统的过程
经过前几轮的集成测试，系统的质量已有了一定的保障，此时系统已集成成一个完整的系统，现在咱们拿一些真实数据，分别取几组正确数据、几组错误数据来走系统的主流程、分支流程来考察整个系统的数据流、业务规则准确性等；发现问题及时反馈并修复直到系统上线。
利用以上的各种方式提高交流、沟通、观点分享整合的基础上充分提高工作效率来达到提高软件质量的一个目的。在这里测试为项目组服务、为软件质量服务、为用户满意度服务，测试与开发进行高度沟通共同实现项目的成功而努力。
版权声明：本文出自 zhifei.xie 的51Testing软件测试博客：http://www.51testing.com/?254536
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。
