每日构建作业文件_蔡珺

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.代码覆盖率统计—用于分析哪些代码/代码块从没有执行过，这通常是“死代码”或者“不完备测试”的指示信号；6.代码行统计—通过发现的缺陷与代码行统计的比值可以有效的对开发人员的工作效率做到一定的评估。

在构建服务器中根据不同项目的需要，在.NET平台下使用到工具有：VS2008，FxCop，Ncover，BugBulletin，其中1.VS2008 主要是对从版本控制工具（StarTeam）中下载出的源文件进行编译；2.FxCop是一个代码分析工具，它依照微软.NET框架的设计规范对托管代码规则进行分析；3.Ncover是代码覆盖率测试工具，可以有效的对测试人员对前一版本的测试覆盖度进行数据统计；4.BugBulletin是每日缺陷简报工具，通过连接TD/QC服务器，读取相关数据字段，对缺陷的状态、数量、严重程度、每日发现情况进行汇总；可以对微软托管代码的源代码安全扫描工具。

自动化构建的基本过程为：1.轮询机制：在构建软件VBP中创建临时变量Run，检查Run的值，当Run值为1时，启动构建活动；2.增加版本标签号：检查VBP中的宏变量BuildIndex，为新一次的版本赋予更高的版本号对它进行标示；3.删除构建服务器中的文件夹：删除的文件夹包括源代码以及配置文件夹，删除的目的在于为构建创造一个真实干净的环境；4.下载出版本控制工具中的源代码：调用构建服务器中的版本控制器的命令行操作，从开发服务器的版本控制工具中将.NET的源代码以及配置文件下载至构建服务器指定路径中；5.对源文件进行编译：在构建环境中，即脱离开发环境，对下载的源代码进行编译，保证集成构建的正确性；6.传递WebConfig文件至测试服务器：将部署所需的配置文件拷贝至测试服务器中，并使用测试环境中正确配置的配置文件覆盖开发环境中的配置文件；7.单元测试，代码规则，代码安全检查：使用FxCop以及工具对源代码的动态链接库文件进行代码规则、代码安全性进行检查；8.邮件通知和报告生成：调用VBP内置的sendmail命令以及配置好的XML格式文件对邮件的内容进行初始化并发送至指定的邮箱。

具体步骤以及工作组建请参照《VBP自动化构建》。

自动化构建工具VBP将对测试服务器中当前构建版本的web配置文件进行重写/覆盖，确保成功发布。

版本部署成功后，将由构建服务器发送一份成功邮件通知项目组所有成员，邮件的内容包括：1.构建结果（Failed/Successed）；2.版本部署的访问地址；3.测试工具统计结果/数据的详细报告，以及工具简要说明；4.缺陷简报。

5.1.8执行冒烟测试测试人员对部署后的产物执行冒烟测试，并在BVTNotes中记录各个功能的测试意见。

冒烟测试应遵循的原则在于覆盖主要功能点。

重点放在保证主要功能或主要业务路径执行正常。

对于冒烟测试未通过的版本，测试人员需要在BVTNotes中指出原因并将报告发送项目组全体成员。

报告发送后，测试人员及时与开发人员进行沟通并解决。

问题解决后，测试组长需要对新版本进行构建并再次执行冒烟测试，保证当天版本的测试进度。

5.1.9BVTNotes完成冒烟测试后，无论测试结果通过与否，测试人员都需要发送BVTNotes以通知项目组成员本次测试的结果。

在BVTNotes中需要记录构建版本中文件号、冒烟测试结果、访问路径以及测试意见。

请参照7.1 BVTNotes模板进行书写发送。

5.1.10系统测试系统测试是将已经确认的软件、计算机硬件、外设、网络等其他元素结合在一起，进行信息系统的各种组装测试和确认测试，其目的是通过与系统的需求相比较，发现所开发的系统与用户需求不符或矛盾的地方，从而提出更加完善的方案.。

它的的任务是尽可能彻底地检查出程序中的错误，提高软件系统的可靠性。

系统测试的步骤为：1.测试组长根据开发组长发出的BuildNotes中开发/修改涉及范围、新增/修改特性为测试组员分配测试重点以及测试任务；2.测试人员根据BuildNotes新增/修改特性中缺陷修复的ID号进行缺陷验证工作，及时修改缺陷的状态（Closed或Reopen）；3.完成上一版本的缺陷验证工作后，测试人员根据各自的测试重点以及测试任务在QC中执行对应的测试用例，并记录相应的缺陷；4.在执行系统测试的过程中，除了完成必须的测试用例执行外，测试人员还应该根据系统的实际应用进行发散测试，在发散测试中，应考虑到如下几点a)此软件能做什么?b)软件做的怎么样?c)软件在什么环境条件下做?根据以上三点，我们可以将发散测试的测试类型细分为：✧功能测试—包括菜单、工具栏、快捷键、下拉框、按钮、单选按钮、复选按钮、切换、链接、触发键；✧界面测试—包括登陆界面、总界面、输入界面(增、删、改、查)、处理界面、输出界面、报表界面、提示界面；✧容错测试—包括数据长度、数据类型、非法此操作；✧接口测试—包括接口测试也叫业务流程测试(包括功能模块之间、模块与模块之间、子系统之间；✧性能测试—包括TPS吞吐量、响应速度、cpu占用率、内存占用率；✧负载测试—包括压力测试、强度测试、容量测试；✧并发测试—指多个用户在同一时间对同一条数据的删除或者修改等处理；✧稳定性测试✧恢复测试—包括突然断电(系统触发正常启动;数据包要在断电的地方继续进行处理)；✧配置测试—如推荐配置：大多数用户所用的配置；✧安装测试—包括安装过程;卸载过程；✧文档测试—包括交给用户的文档。