2023年6月21日发(作者：)

每⽇构建作业⽂件_蔡珺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，/doc/ 其中2008 主要是对从版本控制⼯具（StarTeam）中下载出的源⽂件进⾏编译；是⼀个代码分析⼯具，它依照微软.NET框架的设计规范对托管代码规则进⾏分析；是代码覆盖率测试⼯具，可以有效的对测试⼈员对前⼀版本的测试覆盖度进⾏数据统计；letin是每⽇缺陷简报⼯具，通过连接TD/QC服务器，读取相关数据字段，对缺陷的状态、数量、严重程度、每⽇发现情况进⾏汇总；/doc/ 可以对微软托管代码的源代码安全扫描⼯具。⾃动化构建的基本过程为：1.轮询机制：在构建软件VBP中创建临时变量Run，检查Run的值，当Run值为1时，启动构建活动；2.增加版本标签号：检查VBP中的宏变量BuildIndex，为新⼀次的版本赋予更⾼的版本号对它进⾏标⽰；3.删除构建服务器中的⽂件夹：删除的⽂件夹包括源代码以及配置⽂件夹，删除的⽬的在于为构建创造⼀个真实⼲净的环境；4.下载出版本控制⼯具中的源代码：调⽤构建服务器中的版本控制器的命令⾏操作，从开发服务器的版本控制⼯具中将.NET的源代码以及配置⽂件下载⾄构建服务器指定路径中；5.对源⽂件进⾏编译：在构建环境中，即脱离开发环境，对下载的源代码进⾏编译，保证集成构建的正确性；6.传递WebConfig⽂件⾄测试服务器：将部署所需的配置⽂件拷贝⾄测试服务器中，并使⽤测试环境中正确配置的配置⽂件覆盖开发环境中的配置⽂件；7.单元测试，代码规则，代码安全检查：使⽤FxCop以及/doc/ ⼯具对源代码的动态链接库⽂件进⾏代码规则、代码安全性进⾏检查；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占⽤率、内存占⽤率；负载测试—包括压⼒测试、强度测试、容量测试；并发测试—指多个⽤户在同⼀时间对同⼀条数据的删除或者修改等处理；稳定性测试恢复测试—包括突然断电(系统触发正常启动;数据包要在断电的地⽅继续进⾏处理)；配置测试—如推荐配置：⼤多数⽤户所⽤的配置；安装测试—包括安装过程;卸载过程；⽂档测试—包括交给⽤户的⽂档。例如：系统帮助、⽤户使⽤⼿册、⽤户安装⼿册；可⽤性测试初始化测试—是指系统刚刚安装完成后，在数据位空的情况下，如果被调⽤的模块为空，点击调⽤模块的时候，是否进⾏容错的测试；数据完整性测试—是指当主表的某⼀条件信息被删除后，和这⼀条相关的从表的信息都应该被删除。针对以上测试类型，测试⼈员结合系统实际进⾏有选择的测试，同时应对测试⽤例中不完善的地⽅进⾏修改和补充。5.1.11记录测试结果测试⼈员在测试过程中发现缺陷时应及时记录，按照《QC缺陷管理规范》和《QC使⽤规范》的要求执⾏测试⽤例，记录并跟踪缺陷。5.1.12TestNotes完成每⽇⼯作后，测试⼈员将该版本的测试结果记录到TestNotes中，并发送给所有项⽬组成员。TestNotes的发布和填写⼯作统⼀在QCReport系统中进⾏，步骤如下：前提条件：开发组长已经成功发布BuildNotes信息；若开发组长未能够发布当前版本的BuildNotes信息，测试组长/测试⼯程师没有权限进⾏新版本的TestNotes 的创建。此时要求测试组长与开发组长进⾏沟通，即时解决问题。1.⽤户（测试组长/测试⼯程师）登录QCReport系统（⽤户名与QC⽤户名⼀致，密码初始1111）；2.点击系统页⾯左侧栏的项⽬名称；3.在页⾯右侧窗⼝中点击‘新建TestNotes’；4.此时在右侧窗⼝中，系统将⾃动加载相关缺陷图表以及缺陷统计中‘长期未关闭的’和‘Reopen两次以及两次以上’的列表信息5.在TestNotes中填写各项信息后单击‘保存’按钮需要填写的内容为：部署位置测试⼈员测试结论缺陷统计中的急待解决的问题6.确认所填信息⽆误后，单击当前TestNotes中的‘发布’按钮即可；测试组长/测试⼯程师成功发布TestNotes后，项⽬组相关⼈员将能够在邮箱中收到标有项⽬名称的TestNotes内容邮件。5.2每⽇构建原则每⽇构建活动从具备测试条件开始，持续到产品达到发布的要求后结束。整个过程需要遵循以下原则：●缺陷优先：开发⼈员针对当前版本测试⼈员提出的缺陷需要⾸先修复缺陷，再提交新增功能。测试⼈员在每⽇构建完成后优先验证已修复缺陷是否已经得到修改。●谨慎提交：为了保证构建的成功、减少破碎的构建和后续测试⼯作的正常进⾏，提交代码时应该⾮常谨慎。这就需要开发⼈员做到私有构建，即要求开发⼈员在本地环境中对代码、配置⽂件进⾏编译，进⾏多次内部构建。●⾃动构建：为了提⾼构建效率，使⽤⾃动化构建⼯具VBP来进⾏⾃动构建⼯作。●尽早构建：将⽐较复杂的集成问题提前暴露，并尽早解决，减少项⽬风险；便于从新增功能中找出缺陷，也有利于修改缺陷。●持续构建：开发⼈员在当天⼯作结束前将所有源代码以及配置⽂件提交⾄版本库，测试⼈员运⾏⾃动化构建⼯具VBP对新版本进⾏构建，构建为每天⼀次，实现版本的迭代。6.相关⽂件6.1《QC缺陷管理规范》XF/PD-0016.2《软件测试作业⽂件》XF/QD-8.2.4-B02 6.3《QC使⽤规范》6.4《VBP⾃动化构建》7.附件7.1BVTNotes模板<项⽬名称> BVTNotes(流式) # XXXX:yyyy-mm-dd hh:mi

2023年6月21日发(作者：)

每⽇构建作业⽂件_蔡珺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，/doc/ 其中2008 主要是对从版本控制⼯具（StarTeam）中下载出的源⽂件进⾏编译；是⼀个代码分析⼯具，它依照微软.NET框架的设计规范对托管代码规则进⾏分析；是代码覆盖率测试⼯具，可以有效的对测试⼈员对前⼀版本的测试覆盖度进⾏数据统计；letin是每⽇缺陷简报⼯具，通过连接TD/QC服务器，读取相关数据字段，对缺陷的状态、数量、严重程度、每⽇发现情况进⾏汇总；/doc/ 可以对微软托管代码的源代码安全扫描⼯具。⾃动化构建的基本过程为：1.轮询机制：在构建软件VBP中创建临时变量Run，检查Run的值，当Run值为1时，启动构建活动；2.增加版本标签号：检查VBP中的宏变量BuildIndex，为新⼀次的版本赋予更⾼的版本号对它进⾏标⽰；3.删除构建服务器中的⽂件夹：删除的⽂件夹包括源代码以及配置⽂件夹，删除的⽬的在于为构建创造⼀个真实⼲净的环境；4.下载出版本控制⼯具中的源代码：调⽤构建服务器中的版本控制器的命令⾏操作，从开发服务器的版本控制⼯具中将.NET的源代码以及配置⽂件下载⾄构建服务器指定路径中；5.对源⽂件进⾏编译：在构建环境中，即脱离开发环境，对下载的源代码进⾏编译，保证集成构建的正确性；6.传递WebConfig⽂件⾄测试服务器：将部署所需的配置⽂件拷贝⾄测试服务器中，并使⽤测试环境中正确配置的配置⽂件覆盖开发环境中的配置⽂件；7.单元测试，代码规则，代码安全检查：使⽤FxCop以及/doc/ ⼯具对源代码的动态链接库⽂件进⾏代码规则、代码安全性进⾏检查；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占⽤率、内存占⽤率；负载测试—包括压⼒测试、强度测试、容量测试；并发测试—指多个⽤户在同⼀时间对同⼀条数据的删除或者修改等处理；稳定性测试恢复测试—包括突然断电(系统触发正常启动;数据包要在断电的地⽅继续进⾏处理)；配置测试—如推荐配置：⼤多数⽤户所⽤的配置；安装测试—包括安装过程;卸载过程；⽂档测试—包括交给⽤户的⽂档。例如：系统帮助、⽤户使⽤⼿册、⽤户安装⼿册；可⽤性测试初始化测试—是指系统刚刚安装完成后，在数据位空的情况下，如果被调⽤的模块为空，点击调⽤模块的时候，是否进⾏容错的测试；数据完整性测试—是指当主表的某⼀条件信息被删除后，和这⼀条相关的从表的信息都应该被删除。针对以上测试类型，测试⼈员结合系统实际进⾏有选择的测试，同时应对测试⽤例中不完善的地⽅进⾏修改和补充。5.1.11记录测试结果测试⼈员在测试过程中发现缺陷时应及时记录，按照《QC缺陷管理规范》和《QC使⽤规范》的要求执⾏测试⽤例，记录并跟踪缺陷。5.1.12TestNotes完成每⽇⼯作后，测试⼈员将该版本的测试结果记录到TestNotes中，并发送给所有项⽬组成员。TestNotes的发布和填写⼯作统⼀在QCReport系统中进⾏，步骤如下：前提条件：开发组长已经成功发布BuildNotes信息；若开发组长未能够发布当前版本的BuildNotes信息，测试组长/测试⼯程师没有权限进⾏新版本的TestNotes 的创建。此时要求测试组长与开发组长进⾏沟通，即时解决问题。1.⽤户（测试组长/测试⼯程师）登录QCReport系统（⽤户名与QC⽤户名⼀致，密码初始1111）；2.点击系统页⾯左侧栏的项⽬名称；3.在页⾯右侧窗⼝中点击‘新建TestNotes’；4.此时在右侧窗⼝中，系统将⾃动加载相关缺陷图表以及缺陷统计中‘长期未关闭的’和‘Reopen两次以及两次以上’的列表信息5.在TestNotes中填写各项信息后单击‘保存’按钮需要填写的内容为：部署位置测试⼈员测试结论缺陷统计中的急待解决的问题6.确认所填信息⽆误后，单击当前TestNotes中的‘发布’按钮即可；测试组长/测试⼯程师成功发布TestNotes后，项⽬组相关⼈员将能够在邮箱中收到标有项⽬名称的TestNotes内容邮件。5.2每⽇构建原则每⽇构建活动从具备测试条件开始，持续到产品达到发布的要求后结束。整个过程需要遵循以下原则：●缺陷优先：开发⼈员针对当前版本测试⼈员提出的缺陷需要⾸先修复缺陷，再提交新增功能。测试⼈员在每⽇构建完成后优先验证已修复缺陷是否已经得到修改。●谨慎提交：为了保证构建的成功、减少破碎的构建和后续测试⼯作的正常进⾏，提交代码时应该⾮常谨慎。这就需要开发⼈员做到私有构建，即要求开发⼈员在本地环境中对代码、配置⽂件进⾏编译，进⾏多次内部构建。●⾃动构建：为了提⾼构建效率，使⽤⾃动化构建⼯具VBP来进⾏⾃动构建⼯作。●尽早构建：将⽐较复杂的集成问题提前暴露，并尽早解决，减少项⽬风险；便于从新增功能中找出缺陷，也有利于修改缺陷。●持续构建：开发⼈员在当天⼯作结束前将所有源代码以及配置⽂件提交⾄版本库，测试⼈员运⾏⾃动化构建⼯具VBP对新版本进⾏构建，构建为每天⼀次，实现版本的迭代。6.相关⽂件6.1《QC缺陷管理规范》XF/PD-0016.2《软件测试作业⽂件》XF/QD-8.2.4-B02 6.3《QC使⽤规范》6.4《VBP⾃动化构建》7.附件7.1BVTNotes模板<项⽬名称> BVTNotes(流式) # XXXX:yyyy-mm-dd hh:mi