生成验证测试包括在每个新版本上运行的一组测试，用于验证生成是否可测试，然后再将其交付给测试团队进行进一步测试。这些是核心功能测试用例，可确保应用程序稳定且没有任何明显问题。典型过程是自动化的。如果 BVT 失败，则该版本将再次分配给开发人员进行修复。BVT被称为烟雾测试或构建验收测试（BAT）
新版本主要检查两件事：
构建验证
构建验收
注意烟雾测试可能是BVT测试的子集。与BVT不同，烟雾测试并不关注更精细的细节。
基本知识：
BVT 节省了测试团队在主要功能中断时部署和测试构建的工作量。构建验证测试应设计得足够仔细，以涵盖基本功能。通常 BVT 的运行时间不应超过 30 分钟。
BVT对于检查项目完整性以及所有模块是否正确集成非常重要。模块集成测试非常重要，因为项目开发通常分为不同团队的模块。我见过许多由于模块集成不当而导致的应用程序失败的情况。
构建编译过程中的主要任务 - 代码签入，即包括与相应构建关联的所有新的和修改的项目文件。引入BVT主要是为了检查初始构建的运行状况 i.e.to 检查所有新的和修改的文件是否都包含在发行版中，所有文件格式是否正确，每个文件版本和语言以及与每个文件关联的标志。这些基本检查值得运行
在将构建版本发布到测试团队进行进一步测试之前。通过使用BVT在一开始就发现构建缺陷，您将节省时间和金钱。
在自动执行BVT任务之前，这是一个非常棘手的决定。BVT的成功主要取决于您包含在其中的测试用例。
以下是一些在 BVT 自动化套件中包含测试用例的简单提示：
请勿在 BVT 中包含不稳定模块的测试用例。对于某些未开发的功能，您无法预测预期的行为，因为这些模块不稳定，并且您可能具有这些模块的已知故障列表。在 BVT 中为此类模块包含测试用例是没有意义的。
您可以通过与项目开发和测试生命周期中涉及的所有各方进行通信来简化此任务。测试团队应列出所有关键测试用例，并从业务团队获取这些测试用例。一旦这些测试得到业务团队的批准，您就可以开始自动化BVT的这些测试。在列出关键测试用例时，应设置并遵循一些质量标准。这些标准可以通过分析项目范围和主要特征来设置。
BVT 示例：文本编辑器应用程序的 BVT 测试用例（仅限某些示例测试）：
1） 用于创建文本文件的测试用例。
2）将某些内容写入文本编辑器的测试用例。
3）文本编辑器的复制，剪切，粘贴功能的测试用例。
4）打开，保存，删除文本文件的测试用例。
这些是一些示例测试用例，可以标记为“关键”，对于应用程序中的每个微小或重大更改，这些基本的关键测试用例应作为BVT过程的一部分执行。执行 BVT 套件后会发生什么？
1） BVT 执行结果发送到项目电子邮件通讯组列表 （DL）。
2） BVT 所有者（执行和维护 BVT 套件的人员）检查 BVT 结果。3） 如果 BVT 出现故障，则 BVT 所有者必须诊断故障原因。
4） 如果 BVT 故障的原因是构建中的某些缺陷，则会在 BVT 故障通知中发送所有包含故障日志的相关信息。
5）开发人员在他的初始诊断中回复了这个DL，并给出了失败的原因，提到这是否真的是一个错误以及错误修复场景是什么。
6） 修复缺陷后，再次执行 BVT 测试套件。如果 BVT 通过，则将生成发送到测试团队进行进一步测试。
对于每个新版本，都会重复此过程。BVT 失败的原因：
BVT 故障并不总是意味着构建中存在缺陷。可能还有其他原因，例如BVT自动化套件中的错误，基础架构错误，硬件故障等。对 BVT 故障的原因进行故障排除对于采取快速和适当的操作非常重要。