这个模型的出现是为了克服瀑布模型的缺点。在此模型中，测试从需求阶段本身开始。

在这个模型中，首先，所有活动 都向下进行 ，在某个时间点，它开始向上 移动，以 在测试过程中重复使用测试文档并形成 V 形。因此，它被称为 V模型 。

当我们选择这个模型时

我们选择V和V模型的原因如下：

• 对于大型和复杂的应用程序，这里，大意味着 n 个模块和复杂指定了模块之间的大量依赖关系。
• 它也用于长期项目。

在进一步了解此模型之前，首先，我们将了解要求：

需求

它是从客户那里收集的文件;在这里，我们有两种不同类型的需求文档，如下所示：

• CRS/BRS
• SRS/FS

CRS/BRS

CRS 或 BRS 代表 客户需求规范或业务需求规范 。对于CRS，详细信息将由BA（业务分析师）用简单的商业（英语）语言编写，开发人员和测试工程师无法理解。

让我们看一个 Gmail 应用程序的客户需求规范示例：

SRS/FS

它代表 软件需求 规范或 功能规范 ;在此，所有详细信息都转换为详细文档，开发人员和测试工程师都可以理解。

让我们看一个 Gmail 应用程序软件需求规范的示例示例：

功能需求的特征

• 需求应该是“ 详细 ”，这意味着它包含有关 模块、组件和功能规范 的所有详细信息，并且在 “正确”流程 中，这意味着它应该按 顺序 排列。
• 要求应该用每个人都易于理解的简单语言编写。
• 要求应该是可衡量的或可数的。

V 和 V 模型流程

整个V模型分两阶段执行，完整的 审核 过程在验证阶段完成，整个 测试过程 在 验证阶段 完成; 这就是为什么它也被称为 验证和确认 模型。

其中验证和确认过程包括不同的阶段：

第 1 阶段

它将从收集CRS（客户需求规范）文档开始，由业务分析师从客户那里收集，测试工程师将检查以下方案：

• 审查基于以下依据的CRS
  • 不正确的要求
  • 缺少要求
  • 需求冲突
• 编写验收测试文档

注意：在所有阶段中，测试文档都包括测试计划和测试用例。

一旦测试工程师团队审查了CRS并发现了任何错误或缺陷，他们就会将其发送给开发团队以修复错误。修复错误后，开发团队更新 CRS 并同时开发 SRS 文档。

第 2 阶段

完成 CRS 后，SRS 被发送给测试团队进行审查过程，开发人员开始为应用程序创建 HLD（高级设计）。测试团队将在以下场景中测试 SRS：

• 根据CRS审查SRS
  • 每个CRS都转移到SRS
  • CRS 未正确转换为 SRS
• 编写系统 测试文档

一旦测试团队审查了SRS的每个细节，并且CRS已正确转换为SRS，我们将进入下一阶段。

第 3 阶段

HLD完成后，开发人员开始为应用程序创建LLD（低级设计），同时，测试人员将在HLD上检查以下测试：

• 回顾 HLD
• 编写集成测试文档

第 4 阶段

测试团队审查完HLD后，开发人员编写编码并开发应用程序，测试团队将执行以下任务：

• 审查LLD
• 编写功能测试文档

第 5 阶段

编码部分完成后，开发人员将进行一轮单元测试，也称为白盒测试，并检查代码的每一行并确保代码正确。

执行单元测试后，应用程序将发送到测试团队，在那里他们执行多项测试 ，例如功能测试、集成测试和系统测试以及验收测试。

一旦测试部分完成，应用程序将最终交付给客户。

注意：

如何处理V和V中的需求变化？

每当需求发生更改时，相同的过程将继续，并且文档将更新。

V和V模型的优缺点

让我们看看 V 和 V 模型的优缺点：