• 针对部分已开发的系统
• 分析完成的功能部分，进行测试特性分析，与开发进行评审和确认后，再进行测试用例的编写
• 参与开发的新功能的需求分析
• 不确定的部分，与客户负责人进行确认
• 针对有项目Demo和页面设计的项目
•  分析项目的Demo和页面设计，进行测试特性分析，与开发进行评审和确认后，再进行测试用例的编写
• 参与开发的新功能的获取和需求分析活动
• 不确定的部分，与客户进行沟通确认
• 针对有产品需求输出的项目
• 客户一般会提交个需求意向给产品经理，产品经理根据与客户的沟通，拟定需求列表
• 测试可以根据需求列表进行测试特性分析，再与开发和产品经理进行反复的确认
• 测试用例需要在转测试前，经过开发的评审
• 在与开发沟通的过程中，可以随时根据获取的新需求，修改和不出测试用例

    获取测试需求方式，还有以下途径：

• 参考同行业和竞争对手的类似产品
• 假如是做即时通讯工具，在编写测试用例的时候，可以看看“QQ”，“MSN”等类似成熟相关的产品。从而发现自己产品的不足，提供产品的竞争力。
• 参加需求相关会议
• 测试人员参与开发与产品经理、客户的需求讨论会，获取对每个功能点的理解和认识，理清思路，达成需求共识。
• 测试人员参与开发周会，在周会上，开发会讲一些与需求相关的内容，如对需求的理解，变更，限制和约束等。
• 测试人员将获取的需求信息进行记录和分析，形成测试的部分参考文档。
• 整理需求疑问向相关负责人进行沟通和确认
• 测试人员根据开发讨论会后的理解，测试过程中可能碰到的问题（如：边界值、输入数据类型等等）和需求不明确的问题，整理需求疑问，与相关的模块负责人进行沟通和确认，并给出详细解释和说明。
• 项目内部用例评审
• 测试人员根据对项目的理解，编写测试用例要点，测试组内部评审修改后，可以组织项目组的开发人员进行评审，然后根据评审意见进行修改。经过多次修改和评审以后，测试用例要点会更全面一些。
• 邮件和产品经理确认部分争议问题
• 测试人员与开发人员、项目组成员，在需求问题上讨论不一致，可以将争议的问题写成邮件，发给产品经理和客户负责人来拍板，确定那种需求合理，到底如何做？并抄送给项目组的全体成员，方便大家都了解产品经理和客户的意见。最后编写测试用例的时候，以产品经理或客户的邮件内容为准。