1、软件测试明确需求范围

了解该需求是为了解决用户的什么问题

功能性需求：产品必须有的功能

非功能性需求：是否美观，用户体验，稳定性，易用性等

最容易忽略的一点：明确的需求背后所隐藏的需求（例如登录，明确的需求是，正确输入用户名，密码，才能登录。隐性需求：用户名字符类型，长度，是否可为空；密码字符类型，长度等）

将问题在需求阶段暴露的成本最小

　2、画业务流程图（流程图）

根据需求中规定的业务流程

各业务流程分支的确定

由于业务原因规定不可使用的业务流程

3、功能点整理（思维导图）

业务功能：需求中所定义的实际业务直接相关的功能

数据约束：主要是用于控制在执行功能时，数据的显示范围、数据之间的关系等。

易用性需求：便于功能操作使用的一些细节，比如快捷键就是典型的易用性需求。

编辑约束：在功能执行时，对输入数据项目的一些约束性条件，比如只能输入数字。

权限需求：不同的权限所能操作的功能点的不同

4、提取测试点（测试需求文档）

根据整理的思维导图，去提取每一个功能点中的细节需求，例如新增员工，在思维导图中，最小的颗粒度就到新增员工了，但是新增员工这个功能仍然有很多的需求点，员工姓名唯一性判定，手机号码是否必填等，这些更细的需求点组合起来就形成了测试需求文档

5、确定测试范围

需求的确定，并不代表测试范围就是该需求的范围，很有可能一个需求分多个软件版本来实现，最后确定哪些需求是需要测试的。

明确哪些测试目标优先级高，哪些目标优先级低

要完成哪些相应的测试任务才能确保目标的实现

测试需求分析流程 测试需求分析要点要素分析

 1、界面元素是否满足自定义的质量标准或行业通行标准或常用使用标准等

 2、公司部门制定的Web元素描述规范 

数据分析

 1、输入域的数据

 2、已显数据的来源 

3、数据的输出

 4、数据关联 

流程分析 

1、常用的或规定的业务流程

2、各业务流程分支的遍历 

3、确规定不可使用的业务流程 

4、没有明确规定但是应该不可以执行的业务流程 

功能交互分析

 1、结合数据分析，流程分析，但是侧重点是功能实现。 

2、操作入口明确、合理 “操作入口”，指的是产品内部不同模块之间的转接元素，例如在Web产品中，按钮控件、输入框、文字链等都属于操作入口；“明确”指的是入口的视觉感是清晰的、可识别的；“合理”是指入口的出现是符合用户操作逻辑的，适时的。 

3、实现功能的步骤简洁明确 “实现功能的步骤”指的是系统界面上实现业务功能的实际操作步骤，例如：注册用户时，输入优惠代码，点击“应用”按钮，再点击“提交”。“简洁明确”是指步骤符合实际业务逻辑并足够简洁，并且不会产生步骤上的混乱。

4、交互执行的结果正确完整 按系统操作步骤执行交互响应后的界面结果或其他功能的前置条件。

用户场景分析

1、现在的软件几乎都是由事件触发来控制流程的，事件触发时的情景便形成了场景，而统一事件不同的触发顺序和处理结果就行成了事件流。 

2、模拟实际业务中形成某一事件的场景，转变成系统中该事件触发时的情景。从而检验该场景的正确性。 

质量模型分析 

1、度量需求定义的指标

（ 1）每条用户需求的定义都正确反映了用户的要求 

（2）在第一层基础上的完整性和一致性要求，即用户的所有要求都有定义且不能相互矛盾 

2、一套结构化的根据指标对需求定义进行度量的方法 

过程方法分析

 1、组织结构关系分析2

、业务流程展开模型

通过分析需求描述中的输入、输出、处理、限制之间、约束等，给出对应的验证内容（功能测试）

 通过分析各个功能模块之间的业务顺序，和各个功模块之间传递的信息和数据，对存在功能交互的功能项给出对应的验证内容（功能交互测试）

考虑到需求的完整性，要充分覆盖软件需求的各种特征，包含隐性需求的验证，比如界面的验证，注册账号的唯一性验证（界面、易用性、兼容性、安全性、性能压力）。

一般一个需求分别从点、线、面三个方面去考虑

点: 指的是对应的功能点，

线: 指的是功能点之间的关联，

面: 指安全、性能、兼容。。。等其他类型方面去考虑。

测试数据根据你的测试点而对应设计的一些数据，来验证对应的功能的

如何进行软测需求
需求分析的主要目的：依据文档提取测试点，根据测试点来编写测试用例
测试点分析：
1）分析需求描述中的输入（用户名和密码）、输出（登陆成功或失败）、处理、限制（非会员）、约束（密码组合）等，给出对应的验证内容（功能测试）
2）分析各个功能模块之间的业务顺序，和各个功能模块之间传递的信息和数据，对存在功能交互的功能项，给出对应的验证内容（功能交互测试）
3）考虑到需求的完整性，要充分覆盖软件需求的各项特征，包含隐性需求的验证，比如界面的验证，注册账号的唯一性验证（界面、易用性、兼容性、安全性、性能压力）

从需求分析开始的好处：首先，“尽早的了解被测系统”，这句经典的软件测试原则就体现出来了，早入手，早了解，至于能否深刻了解，还是看需求评审做的是否充足；第二，如果在需求分析阶段发现系统存在严重的Bug（此阶段的bug最多），或者发现不可测的地方，可以及时的进行修改，避免了后期修改bug的巨大的成本浪费。