目录
1.需求的定义
需求是衡量软件测试结果的依据，它是满足用户期望或正式规定文档（合同、标准、规范）所具有的条件和权能，包含用户需求和软件需求。
1.1.用户需求
可以简单理解为甲方（付费者）提出的需求，如果没有甲方，那么就是终端用户使用产品时必须要完成的任务。
该需求一般比较简略。
一句话，没有细节，实现困难。
也会有不能实现的需求！
1.2.软件需求
或者叫功能需求，该需求会详细描述开发人员必须实现的软件功能。
文档，详细描述用户需求如何实现。规范，标准化。
大多数公司在进行软件开发的时候，产品经理（PM）会把用户需求转化为软件需求（文档）。
开发人员和测试人员工作的直接依据就是软件需求。
IEEE定义：软件需求是
- 用户解决问题或达到目标所需条件或权能(Capability)。
- 系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。
一种反映上面1或2所述条件或权能的文档说明，由产品经理写。
它包括功能性需求及非功能性需求，非功能性需求对设计和实现提出了限制，比如性能要求，质量标准，或者设计限制。
PS：软件需求规格说明书
一、用户需求：
平台支持邮箱注册。
二、软件需求：
1. 注册账号
1.1 功能概述
用户可以通过填写邮箱信息在平台注册个人用户。
1.2 用户角色
匿名用户。
1.3 前置条件
无。
1.4 输入
1.5 处理
1.5.1 基本事件流
1、用户选择注册。
2、系统展现用户协议界面，并请用户确认是否同意用户协议。
1) 若用户不同意协议，系统禁止用户注册。
2) 若用户同意协议，用户进行注册信息填写。
3、用户填写注册信息。
注册个人，填写：姓名，电子邮箱，密码，确认密码，验证码。
4、用户提交注册信息。
5、系统提示用户并向用户注册的电子邮件地址发送一封含有激活信息的电子邮件。系统并提示用户，若未收到激活邮件，可使用注册的邮箱和密码登录系统后再次发送激活邮件。
6、用户可执行激活操作，直接跳转至注册邮箱门户页面。
7、用户通过接收到的电子邮件中的激活信息激活账号，用户注册完成，流程结束。
1.5.2 扩展事件流
用户注册并激活成功后，第一次登录平台时，提示用户完善信息。
1.5.3 异常事件流
1. 若用户未收到激活邮件，可在登录界面录入电子邮件及密码后，再次发送激活邮件。
2. 每次发送的激活邮件，仅在发送邮件后起24小时之内有效，超过24小时后需重新发送激活邮件。
1.6 输出：用户注册成功
1.7 后置条件
该模块为用户登陆等的前置模块。
2.为什么有需求？
需求相当于一个标准。
只有描述清楚要做一件什么事（需求），开发人员才会对照需求进行开发，测试人员才会对照需求进行测试。
有需求才有目标。
PS：为什么需求对软件测试人员如此重要？
- 从软件功能需求出发，无遗漏地识别出测试需求是至关重要的，这将直接关系到用例的测试覆盖率。
- 对于识别出的每个测试需求点，需要采用具体的设计测试用例的方法来进行测试用例的设计。
3.测试人员眼里的需求
需求是测试人员开展软件测试工作的基本依据。
在具体设计测试用例的时候，首先需要搞清楚每一个业务需求对应的多个软件功能需求点，然后分析出每个软件功能需求点对应的多个测试需求点，然后针对每个测试需求点设计测试用例。
验证需求，保证需求正确可实现->细化需求，从需求中提炼出一个个的测试项
过程如下：
业务需求—>软件功能需求点—>测试需求点—>测试用例
以“用户登陆”为例，来阐述下整个过程：
4.如何深入了解需求？
4.1.参加需求评审会议
- 为什么做这样一个需求?
- 收益达到什么标准？
- 软件要做成什么样？
评审完需求不一定会立马做，会根据紧急程度根据情况，看啥时候开始开发/测试。
4.2.查阅文档（需求文档、技术文档）
4.3.沟通
测试人员可以找产品经理了解软件功能，找开发人员了解软件实现。
测试工程师在需求分析（验证需求的合理性和正确性）和设计阶段（站在用户的角度）就开始介入，因为这个阶段是理解和掌握软件的原始业务需求的最好时机。
只有真正理解了原始业务需求之后，才有可能从业务需求的角度去设计针对性明确，从终端用户的使用场景到端到端的覆盖率较高的测试用例集。
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
