每日构建作业文件_蔡珺

1.目的

规定在软件项目中实施每日构建活动的步骤和方法，通过对每日构建的步骤和构建工具的使用，保证及时正确构建版本，保证测试工作的正常进行，从而提高开发和测试的效率。同时对于每日构建中必须遵守的工作原则进行约束。

2.范围

适用于软件开发过程中的版本构建活动。

3.术语

3.1冒烟测试：Build Verification Tests，简称BVT，冒烟测试的对象是每一个新编译的需要正式测试的软件版本，目的是确认软件基本功能正常，可以进行后续的正式测试工作，这种测试强调功能的可测试性，而不对功能的正确性进行验证。

3.2自动化构建工具VBP：Visual Build Professional，简称VBP，它能帮助开发人员和项目管理人员快速创建自动的，可重复的构建过程，它的功能包括从版本控制服务器中签出代码、编译、打包、部署等工作。

3.3每日构建：Daily Build，简称DB，它是以持续集成（CI）为思想将软件开发，集成以及测试形成一个自动化过程，通过提交版本、自动化构建和自动化测试的不断循环，推进项目前进。每日构建的优势在于使PM掌握项目的进度；使开发人员尽早了解系统缺陷，解决并提高产品质量；使测试人员将系统的大集成转化为小集成，进行逐个测试。

3.4QCReport：QCReport系统是由科大讯飞教育工程中心研发，集整合BuildNote和TestNote为一体的质量流程/控制系统，其要求项目组中各成员角色（项目经理、产品经理、开发组长、开发工程师测试组长、测试工程师）能够按照严格的每日构建流程规范对项目进行严格把控，同时对单个/多个项目的质量情况能够做到全面的了解和分析。

4.职责

4.1项目经理：在每日构建过程中负责监督每日的版本构建工作，及时督促构建负责人解决构建中产生的问题以及构建中涉及到的开发问题，确保开发、测试的协调工作，同时监督每日缺陷的产生修复情况，跟踪项目的整体工作进度。

4.2开发组长：在每日构建过程中负责在每日开发工作结束后，在本地对新版本代码以及配置文件进行私有构建，保证编译的正确性。同时将最新版本的开发产物提交至版本控制、发送BuildNotes、与构建负责人及时响应并解决构建中产生的问题，督促开发人员对测试人员当天版本发现的缺陷进行及时修复。

4.3测试组长：在每日构建过程中负责构建脚本的维护和开发，对构建中产生的服务器、软件等问题进行及时解决，督促测试人员完成冒烟测试以及检查BVTNotes的正确性，为测试人员分配当天测试任务以及工作重点，及时更进项目测试进度。

4.4测试人员：在每日构建过程中首先明确当天工作任务以及工作重点，对构建成功的版本进行冒烟测试，包括对开发人员已修复的缺陷进行验证并修改缺陷状态，统计必要数据并发送BVTNotes，对冒烟测试成功的版本进行回归测试和手动测试并记录缺陷至QC中。在每天的工作完成后，发送TestNotes报告当天版本发现缺陷的情况以及当前系统的缺陷整体趋势。

5.工作程序

5.1每日构建工作流程

图1 每日构建工作流程

5.1.1缺陷修复

开发人员针对测试人员在当前版本提出的缺陷应做到及时响应，对于认可的缺陷应该立

即修改，防止缺陷再次引起新的缺陷，为日后的集成带来质量问题。同时对于有争议的缺陷应及时与测试人员，开发组长，测试组长进行沟通，已达到商讨解决的方案。

5.1.2功能开发

开发人员在缺陷修复工作完成的基础上，应尽力完成当天的开发任务，在开发组长的领导下清晰任务，对任务中有质疑以及超出能力范围的地方应及时提出。

5.1.3私有构建

为了防止集成构建失败，开发人员应该在完成他们的功能开发之后，在自己本地集成开发环境中模拟一次集成构建。对于已经完成的功能模块或功能点要进行私有构建，验证代码的规则、编译通过以及模块/功能点的完整性和正确，保证当天自动构建的成功。

5.1.4提交版本

开发人员每天根据测试结果，修复已有的缺陷，然后进行新功能的开发。通过自己的测试后，将源码和文档等产物提交到配置管理库中。

5.1.5建立版本视图

开发组长确认所有源文件都能被成功构建后，在配置管理工具中为提交的所有文件建立版本视图。

5.1.6BuildNotes

开发组长在版本视图建立后，发送BuildNotes给所有项目组成员。

BuildNotes的发布和填写工作统一在QCReport系统中进行，步骤如下：

1.用户（开发组长）登录QCReport系统（用户名与QC用户名一致，密码初始1111）；

2.点击系统页面左侧栏的项目名称；

3.在页面右侧窗口中点击‘新建BuildNotes’；

4.在BuildNotes中填写各项信息后单击‘保存’按钮；

需要填写的内容为：

✧组建列表

✧Build目的

✧开发/修改涉及范围

✧新增/修改特性

✧部署注意事项

✧已知问题列表

✧代码行数信息

5.确认所填信息无误后，单击当前BuildNotes中的‘发布’按钮即可；

开发组长成功发布BuildNotes后，项目组相关人员将能够在邮箱中收到标有项目名称的BuildNotes内容邮件。

5.1.7自动化构建与部署

测试组长收到BuildNotes后，确认构建，使用自动化构建工具VBP进行自动构建，构建的成果将从配置管理库中取得指定版本的所有源文件，在构建服务器上进行构建，得到可执行文件或文档。

在构建过程中，将对构建日志进行记录。构建的工作由测试组长或专门的构建人员负责，

构建服务器必须独立于测试服务器和开发服务器，其次保持构建服务器的纯净环境。

自动化构建的原则：

1.每日构建的执行为每天的夜里1：10，要求开发人员在这个时间点前，将当天开发

完毕的源文件以及配置文件全部上传至版本控制器中；

2.构建失败时，测试组长或构建负责人对构建工具VBP自身问题进行排查并对构建

日志进行分析；根据日志或构建工具排除问题后，确定失败原因，通知开发人员进行代码重新上传或再次编译，直至构建成功；

3.问题解决后，由开发人员将出现的问题和解决方案在BuildNotes中答复，同时，

测试人员对版本进行重新构建；

4.版本需要进行每日构建。因项目需要进行多次构建或不构建时，需要报告项目经理

并批准通过。

在自动化构建中，主要使用以下测试类型中的一种或多种组合对源代码和配置文件进行检查：

1.静态测试—通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确

性；

2.单元测试—用于检验被测代码的一个很小的、很明确的功能是否正确；

3.验收测试—系统相关的用户或独立测试人员根据测试计划和结果对系统进行测试

和接收。目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定

功能和任务；

4.代码安全检查—用于对代码在运行时,或被别人调用时产生错误的容易程度；

5.代码覆盖率统计—用于分析哪些代码/代码块从没有执行过，这通常是“死代码”