针对不同研发阶段的测试目的，测试活动分为需求测试、组件/单元测试、集成测试、系统测试、验收测试、Alpha测试、Beta测试、UAT测试等级别。
5.9.1 需求测试
软件测试双V模型要求测试工程师在需求阶段就开始制定系统测试计划，考虑系统测试方法，但这还不够。全面的质量管理要求在每个阶段都要进行验证和确认的活动。因此在需求阶段，测试工程师还需对需求本身进行测试。

这个测试是必要的，因为在许多失败的项目中，70%～85%的返工是由于需求方面的错误所导致。因需求错误导致大量返工，造成进度延迟，缺陷发散甚至项目失败，这是一件极其痛苦的事情。因此测试工程师需在软件生产源头-需求就开始测试。
需求测试（Requirement Test）的重点是检查需求规格说明书中是否存在描述不准确、定义模糊、需求用例不正确、语言存在二义性等问题。主要从以下几个方面考虑。
1. 完整性
每一项需求都必须将所要实现的功能描述清楚，为开发人员设计和实现这些功能提供所有必要的需求依据。
2. 正确性
每一项需求都必须准确地陈述其要开发的功能。
3. 一致性
一致性是指与其他软件需求或高层（系统、业务）需求不相矛盾，或者与项目宣传资料一致。
4. 可行性
每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。
5. 无二义性
对所有需求说明书的读者都只能有一个明确统一的解释，由于自然语言极易导致二义性，所以尽量把每项需求用简洁明了的用户语言表达出来。
6. 健壮性
需求说明中是否对可能出现的异常进行了分析，并且对这些异常进行了容错处理。
7. 必要性
必要性可理解为每项需求都是用来授权编写文档的“根源”。要使每项需求都能回溯至某项客户的输入，如需求用例或其他来源。
8. 可测试性
每项需求都能通过设计测试用例或其他的验证方法来进行测试。
9. 可修改性
每项需求只应在软件需求规格说明书中出现一次。这样更改时易于保持一致性。另外，使用目录表、索引和相互参照列表方法将使软件需求规格说明书更容易修改。