构建（Build）验证只对软件的主干功能进行初步测试，具有频率高和重复性强的特点，所以各软件产品的 Build 验证都力图实现 100% 自动化。本文给出了一种在不影响现有远程 Build 服务器的前提下，实现面向复杂软件的 Build 自动验证的解决方案，该方案具有一定的普遍性意义。
Build 验证测试（Build Verification Test）是测试过程的第一步，通常只对软件的主干功能进行初步测试，通过验证的 Build 才能转给功能测试人员进行大规模的细化测试，以此确保功能测试人员不会由于安装坏 Build 而浪费时间。
在持续集成的软件开发过程中，构建（Build）服务器一般每天都会编译最新的源代码并构建新的 build，这就要求 Build 验证也以同样的频率紧随进行。另一方面，由于软件的主干功能通常比较稳定，所以 Build 验证的重复性较强。正是因为这两个特点，各软件产品的 Build 验证都力图实现 100% 自动化。
相对 Build 的手工验证，自动验证能够带来以下好处：
- 让 Build 验证人员从枯燥的，简单的重复性测试中解脱出来。
- 自动验证的执行速度比手工验证更快，允许开发人员在最短的时间内获知新 Build 中存在的严重问题，并进行及时修复，功能测试人员也能更快获取值得信赖的新 Build 。
- Build 自动验证系统 7 × 24 小时工作，不受白天黑夜以及人员假期的影响。当 Build 验证人员和开发（及功能测试）人员在时区和国度上存在差异的时候，手工验证就容易滞后。
但是，Build 验证的自动化在前期需要较大的开发工作量。另外，如何使得 Build 自动验证系统能够长期稳定运行，也是一个棘手的问题。任何一个环节的错误（例如，软件安装测试后的环境清理），都会造成系统崩溃。虽然不同软件的 Build 自动验证的具体实现五花八门，但本文力图提取其中的不变部分，给出一个具有一般性意义的 Build 自动验证解决方案。此方案已被用于 Websphere Business Monitor 的 Build 自动验证，实际运行结果证明其能在无人干预的情况下长期稳定运行。
Build 验证的自动化解决方案
源代码配置管理服务器和构建（Build）服务器是自动化开发环境的一个基本子集，构建（Build）服务器定期编译最新源代码，并生成面向测试人员的 Build 。为了在自动化开发环境中增加 Build 自动验证的功能，这个基本拓扑需要被进一步扩展。如图 1 的红框部分所示，我们添加了构建（Build）验证服务器和验证结果发布服务器。
图 1. 带 Build 自动验证的自动化开发环境
构建（Build）验证服务器
构建（Build）验证服务器运行 Build 自动验证程序。如何启动 Build 自动验证程序？一般来说，有以下两种方案：
- 由构建（Build）服务器触发。构建（Build）服务器每次生成新的 Build 之后，主动启动构建（Build）验证服务器上的 Build 自动验证程序。
- 由构建（Build）验证服务器触发。构建（Build）验证服务器定时轮询构建（Build）服务器，一旦发现新的 Build，则马上下载验证。
考虑到构建（Build）服务器的重要性，Build 自动验证应该尽量避免对它的影响。方案 1 显然要求修改构建（Build）服务器上的构建脚本，而方案 2 则对其没有任何影响，所以我们选择方案 2 。
文章来源于领测软件测试网 https://www.ltesting.net/