面向复杂软件的 Build 自动验证解决方案

发布: 2009-5-04 15:05 | 作者: 邵科峰 | 来源: 测试时代采编 | 查看: 47次 | 进入软件测试论坛讨论

安装 Build

Build 本身必须提供命令行安装模式，具体过程如下。

解压刚下载的最新 Build
启动 silent install （安装所需的配置文件必须预先定义好）
检查安装日志，确认没有错误发生
初步验证安装结果，例如文件系统，数据库，以及创建在 Websphere 应用服务器中的各种配置对象等。

Build 成功安装是执行功能测试用例的前提。如果验证程序无法检测出 Build 安装失败，则其在继续执行功能测试用例时，测试用例必然失败，验证程序虽然仍能判断 Build 是坏的，但问题定位却是错误的：某功能测试用例失败，实际则是安装失败。

为避免这种情况的发生，就要求对实际安装结果进行适当验证。通常来说，简单的日志检查并不充分，我们还要预先搞清正确的安装结果，并以此为标准对实际安装结果进行验证，如文件系统和数据库等。

执行主干功能测试用例

Build 验证只对软件的主干功能进行初步测试，不同软件的测试用例各不相同。在测试用例的自动化开发中，需要注意以下几点：

尽量选择相对稳定的系统级接口，如各模块的命令行脚本，J2EE 应用服务器的 mbean 等。这样可以使 Build 自动验证程序长时间稳定运行，而无需频繁修改。
对测试用例执行结果进行严格验证，如检查返回代码，日志文件，以及用例生成的各种对象（如数据库记录等），以此提高对坏 Build 的问题自动定位的准确度。
避免图形用户界面（GUI）的细节测试。因为在一个完整的软件开发周期中，GUI 的实现是一个渐进的过程，因此它们的自动化测试脚本也需要经常更新。这与 Build 自动验证程序的稳定性要求相背。
避免陷入底层的 API 测试，一方面底层 API 本身并不稳定，另一方面单元测试已经覆盖底层 API 的测试。

发布 Build 验证结果

构建（Build）验证服务器需要把 Build 验证结果存储到验证结果发布服务器，两者通过数据库交互，数据库结构可参考 BVT（Build Verification Test）DDL 。

清单 2. BVT DDL

				 create table BVT.RESULTS  (  ---- build id ----        BUILD_ID   VARCHAR(256)   NOT NULL,  ---- start time of BVT ----        START_TIME   TIMESTAMP,  ---- end time of BVT ----        END_TIME   TIMESTAMP,  ---- whether the build passed BVT ----        BVT_STATE   SMALLINT,  ---- result of the download build step ----        DOWNLOAD_BUILD   SMALLINT,  ---- result of the silent install step ----        SILENT_INSTALL   SMALLINT,  ---- result of the install verification step ----        VERIFY_INSTALL   SMALLINT,  ---- result of each test case ----        CASE1   SMALLINT,        CASE2   SMALLINT,  … … ---- defect number for the bad build ----        DEFECT_NO   VARCHAR(20),  ---- log.zip ----        BVT_LOG   BLOB(1000M),  ---- specific description for the build ----        NOTES   VARCHAR(2048),        primary key (BUILD_ID)  );

验证结果发布通常包含以下步骤：

将测试用例的执行结果存储到验证结果发布服务器。
将 Build 验证过程的相关日志存储到验证结果发布服务器。
将 Build 验证结果通过 email 发送给相关的测试开发人员。
如果被验证 Build 是坏的，则自动在 Bug 追踪系统（如 CMVC）中生成 Defect 。

清理测试环境

Build 验证结果发布以后，必须清理测试环境，为下一个 Build 做好准备。这个步骤非常重要，由于构建（Build）验证服务器需要在无人干预的情况下 7 × 24 小时连续运行，如果环境清理不成功，则可能引起下一次 Build 自动验证的失败，甚至导致构建（Build）验证服务器发送错误的 Build 验证报告。一般来说，有以下几种清理测试环境的方法：

调用软件本身的卸载命令。由于软件开发过程中，卸载命令本身可能并不完善，出错的可能性很大，所以该方法使用较少。
直接编程删除文件系统的相关文件，数据库中的相关对象，甚至操作系统中的相关配置。该方法可靠性较好，但需要较大的开发工作量，而且在整个软件开发周期中，可能需要经常修改环境清理程序。尤其当被验证的软件需要安装在其他软件之上的时候，环境清理问题会变得更加复杂。
准备一个干净的测试环境（如果被验证软件需要安装在其他软件之上，则可事先安装好相关的软件），然后用 Ghost（或其他备份软件）做硬盘备份，清理测试环境时只要简单的从备份映像恢复即可。

方案 3 简单可靠，而且适用于复杂软件（即被验证软件需要安装在其他软件之上）。在 Windows 上，我们可以配置一个任务计划（Scheduled Task）使得自动验证程序在备份映像恢复时能够自启动。

结束语

构建（Build）自动验证可以作为自动化开发环境的一个增强环节，通过对软件主干功能的初步测试，尽快将严重错误报给开发人员，并为测试人员过滤掉不符合要求的坏构建（Build）。本文给出的 Build 自动验证解决方案具有较强的通用性，但应用到具体软件的构建（Build）自动验证时，仍需选择适当的功能测试用例，尤其要注意对测试用例执行结果的严格验证，以提高对坏构建（Build）中的问题的自动定位的准确度。