V模型 / V 和 V 模型 / 验证和确认模型

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

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

我们什么时候选择这个模型

由于以下原因，我们会选择 V 和 V 模型

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

在进一步深入研究这个模型之前，首先我们将了解需求

要求

这是一个从客户那里收集的文件；在这里，我们有两种不同的需求文件，如下所示

• CRS/BRS
• SRS/FS

CRS/BRS

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

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

SRS/ FS

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

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

功能需求的特征

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

V 和 V 模型流程

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

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

第一阶段

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

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

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

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

第二阶段

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

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

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

阶段 3

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

• 审查 HLD
• 编写集成测试文档

阶段 4

一旦测试团队完成对 HLD 的审查，开发人员编写代码并开发应用程序，测试团队将执行以下任务

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

第五阶段

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

执行单元测试后，将应用程序发送给测试团队，他们将在其中执行多个测试，例如 功能测试，集成测试，系统测试和验收测试。

测试完成后，应用程序最终将交付给客户。

注意
如何在 V 和 V 中处理需求变更？
每当需求发生变更时，相同的过程将继续进行，并且文档将被更新。

V 和 V 模型的优点和缺点

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