V 型

V-model/ V 和 V model /Verification and Validation model

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

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

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

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

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

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

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

它代表软件需求规范或功能规范；在这里，所有的细节都被转换成细节文档，开发人员和测试工程师都可以理解。

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

需求应该是In-Details，这意味着它具有关于模块、组件和功能规范的所有细节，并且在Proper flow 中，这意味着它应该是按顺序排列的。
需求应该用简单的语言编写，每个人都容易理解。
要求应该是可测量的或可数的。

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

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

第一阶段

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

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

第二阶段

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

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

第三阶段

HLD完成后，开发者开始为应用创建LLD（Low-level design），同时测试人员将对HLD进行以下测试：

第四阶段

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

第五阶段

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

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

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

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

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

优点	缺点
在这里，每个阶段都存在审查，这就是为什么我们可能会在应用程序中遇到较少数量的错误。	这是一个有点昂贵的过程，因为初始投资很高，因为从开始阶段本身就需要测试团队。
V 模型提供了 Parallel 可交付成果，这意味着两个团队可以像这里一样一起工作；开发和测试团队并行工作。	这是一个耗时的过程，因为如果发生需求变化，我们需要更改每个文本文档。
此模型有助于提供健壮或稳定的产品。	在这方面，由于测试用例和所有其他文档，我们需要做更多的文档工作。
在这个模型中，测试工程师对产品有更多的了解，因为测试涉及产品开发的每个阶段。	V 模型不适用于面向对象的项目。
文本文件可以重复使用。	一旦应用程序处于测试阶段，我们就无法返回并替换功能。