当我们要做一个项目时，不管项目是一个大的软件，还是一个小的功能模块，我们在执行之前都要搞清楚，这个项目是做什么的，将会实现哪些功能需求，在时间点范围内需要我们做什么，做哪些工作。所追溯的就是需求，需求分析都需要做哪些事情、怎样做，包括以下四项工作：
- 需求说明书:最清晰、明确的需求文档。详细定义了信息流和界面，功能需求，设计要求和限制，测试准则和质量保证要求。
- 软件界面交互设计图：通过文字、视觉表现、物理对象或空间、以及时间、行为设计了用户与系统沟通和连接时的展现与体验。
- 与产品、需求相关干系人沟通：对于文档确失、不明确时，加强与产品设计人员之间的沟通，获取更多的相关信息，帮助测试与开发人员了解更多的信息。
二、从需求中获取哪些信息
- 客户目标
做任何事情前，都要分析为什么，那么开发一个软件或硬件项目，首先要了解客户为什么要做这样一件事，它可以为用户解决什么问题，带来哪些价值；客户的预期需要达到什么样的程度；由于客户可能是非技术人员，帮助客户分析预期的目标是否合理，存在哪些问题或不足；
清晰的了解项目的目标才能帮助我们更好的做下一步工作。
- 技术范围
实现客户的目标，开发项目需要使用哪些技术栈，包括相关的软件及硬件外设。
可提前评估技术风险、学习相关技术内容。
- 操作展示
了解UI的显示，操作的交互过程。
三、项目目标
- 了解项目整体规划目标
- 了解本阶段需要实现目标
一.需求点
- 显性需求
功能确认：业务功能、数据约束、权限约束、编辑约束、参数约束、辅助功能、易用性需求、性能约束
场景分析：业务流程的跳转调用；数据流的跳转调用；
- 隐性需求
未明确的功能限制
未明确的功能响应
定义模糊的功能
- 风险问题
未确定需求的问题
不合理需求的问题
从测试角度识别出的其他风险
二.分析方法
业务流程图
数据流程图
功能点思维导图
一. 确定测试范围
确定版本发布的需求范围
确定各需求功能的测试优先级
确定测试的通过标准
二. 评审测试点
根据需求分析提取整理出的测试点
注：此评审量级的细度粗于评审测试用例，相当于是对测试范围的确认评审。
一. 最终确认的测试需求内容
二. 技术栈、工具需求
三. 结合需求分析，制定的测试计划
可参考以下思维导图
