《日创建和冒烟测试规程及考核办法》由会员分享，可在线阅读，更多相关《日创建和冒烟测试规程及考核办法（7页珍藏版）》请在金锄头文库上搜索。
1、日创建和冒烟测试规程及考核办法（试行）1 目的在日创建和冒烟测试的过程中，软件产品每天被完全创建并通过一系列的测试以检验它的基本运行情况。这个简单的过程可以在以下几个方面明显的节约项目的时间：l 使集成风险降到最小：项目面临的最大风险之一就是当项目成员将他们各自独立编制的代码集成在一起时，这些代码不能很好的一起运行。l 减少低质量的风险：通过每天对所有代码进行最小的冒烟测试，可以防止项目控制中的质量问题，将系统带进公认的、良好的状态，并且一直保持这种状态。l 比较容易支持对缺陷的诊断：当产品每天被创建和测试时，它可以很容易的指出为什么在那天出现了问题。可以有效缩短发现缺陷的周期。.l 支持对项
2、目进展的监控：当你每天创建系统时，系统具备和不具备某些功能是明显的，从而可以了解系统离完成还差多少。l 可以改善客户关系：客户每天都能看到系统的进展，并能及时提供反馈，真正做到让客户参与开发。2 术语解释l 开发配置管理库（以下简称开发库）：项目组自己管理使用的配置管理库；系统管理员为项目经理。l 创建配置管理库（以下简称创建库）：进行日创建的配置管理库，项目经理负责每日检入需要进行创建的源代码和文档，创建小组负责检出代码和进行创建。系统管理员为公司的配置管理员；l 公司产品配置管理库（以下简称产品库）：创建小组将通过了冒烟测试的源代码和文档从创建配置管理库中检出，并检入到产品配置管理库中。并
3、将创建的安装程序和项目日报、测试日报也检入。并进行标注，标号采用日期。l 创建编号：项目代号日期l 项目日报：项目经理对本日项目进展的报告。文件名的格式为：创建编号_PR.docl 测试日报：测试部的测试用例执行总结报告。文件名的格式为：创建编号_TR.docl 提交性质：指根据项目计划或者客户要求，在规定的时间，提交规定功能的工件。3 使用日创建和冒烟测试3.1 日创建日创建最基本的原则是每天创建产品。可以将日创建比喻为项目的心跳，如果心脏不跳动了，项目要么结束了，要么就是出了问题。为了使日创建有效，被创建的软件必须能够运行。如果软件不能用，则认为创建失败。这时调试好创建失败的软件，就成为项
4、目组最优先的工作。创建失败是指下面任何一项标准未能达到：l 成功的编译所有文件、库和其它组件l 不含有任何显示停止的缺陷，这些缺陷会阻止程序启动或者使程序运行起来会崩溃l 通过冒烟测试3.2 冒烟测试应该自始至终对整个系统进行冒烟测试。冒烟测试是防止程序退化的第一条防线，没有冒烟测试，日创建只是一个验证通过编译的方法。冒烟测试应该是优先级最高的测试任务。并且冒烟测试应该是自动化进行的，或者是按照一定标准的程序进行的。测试脚本或者测试程序在每次变更后必须得到公司的批准。冒烟测试通过的标准是测试部没有测出属于本次测试范围的A、B和C类的BUG，并且通过了安装测试。3.3 创建小组创建小组的成员必须
5、来自质量管理部。创建小组负责根据创建库中的源代码进行日创建，并在测试部的冒烟测试通过之后，将创建库中的代码检入产品库，并进行标记。标记采用日期作为编号。3.4 程序员的责任虽然日创建要求每天创建系统，但是并不要求每个开发人员每天都把新增加的程序代码放到系统中，只要保证整个系统有进展就可以了。但是对一个开发人员来说，也不能在两天以上的时间内，还没有检入任何新代码。开发人员在将自己的代码加到系统中进行创建之前需要先测试它们。开发人员可以在自己的机器上建立一个专用的创建系统来做这件事，测试由各个开发人员单独进行。或者开发人员发布一个专有的创建给测试部，而测试员只要注意这个开发人员的编码就行了。不论哪
6、种情况，其目的是确保新代码在被允许影响系统的其他部分之前，能够通过局部的冒烟测试（单元冒烟测试）。这是为了避免一个开发人员的代码有问题时，会影响到整个的创建工作。程序员在向开发库检入用于创建的新代码时，必须在检入时进行标注，标注采用检入人姓名缩写日期的方式。姓名采用和邮件地址一样的格式，即名采用缩写，姓采用全拼，日期采用8位格式。例如李云峰在2002年5月12日进行检入，要在Visual SourceSafe中使用Lable功能，在Lable框中输入：yfli-20020512。以上要求公司并不强制要求，而且本身Visual SourceSafe的权限管理机制有问题。所以开发库的管理由项目经理
7、负责，主要靠项目组内部的约定和开发纪律来约束，尺度由项目经理自行掌握。4 操作过程和说明以下为说明清楚，以2002年5月12日为日创建日期进行示例性说明1) 项目经理最迟在13日8：30之前将用于创建的源代码检入到创建库，并提交一份项目日报2) 创建小组进行日创建，将创建后的可执行文件或安装文件放在开发服务器（DevServer）上Build项目代号日期Setup目录下面，将项目日报放在Build项目代号（由公司制定）日期（8位）Report下面；日创建工作必须在13日9：30之前完成。创建完成后要通知测试部。3) 测试部最晚要在13日9：30开始对12日的创建进行冒烟测试，冒烟测试之前先要执
8、行安装测试，然后根据项目日报对本次创建的描述，进行冒烟测试。冒烟测试中发现的问题，A、B类BUG要立刻反馈给项目经理。其他BUG要每1小时，或者每5个一组反馈给项目经理或者相关的开发人员。4) 项目组要优先修改冒烟测试中出现的BUG，直到解决了问题，才可以进行新任务的工作。对于提交性质的创建，在13日11：00之前能够修改完成的BUG，可以提交创建小组，进行重新创建。重新创建的工作必须在11：30之前完成。如果重新创建，安装文件要放在原来创建目录下面的子目录RC中，例如UTP项目2002年5月12日的创建放在BuildUTP/20020512Setup中，重新创建的安装文件要放在BuildUT
9、P/20020512SetupRC中。测试部要优先对重新创建的系统进行冒烟测试，测试应在14：00之前完成。如果有在13日11：00之前不能修改完成的属于本次提交性创建的BUG，要放在13日的创建中。是否可以提交要得到客户的同意或者公司的批准。5) 如果程序本身没有问题，对12日创建的冒烟测试必须在13日12：00之前完成。对重新创建的冒烟测试要在13日的14：00之前完成；6) 如果在13日中午12：00之前能够通过冒烟测试，或者重新创建后，在14：00之前通过冒烟测试，称12日的创建是优秀的；如果是在18：00之前通过，称12的创建是合格的。否则称12日的创建是失败的。7) 如果创建是优秀
10、的和合格的，测试部将测试日报放在Report目录中。创建小组将源代码和安装程序、项目日报、测试日报检入到产品库中。8) 如果创建是优秀的，创建小组将12日创建的安装程序、项目日报、测试日报上载到FTP服务器上，FTP服务器采用相同的目录结构。如果12日创建是合格的，并且13日的创建是优秀的，则在14日上载13日创建的相关工件，否则，在14日仍上载12日创建的相关工件。9) 如果12日的创建是失败的，测试部也要将测试日报放在Report目录中，并通知总经理。在进行13日的创建时，在增加新功能之前，必须完全解决12日创建中存在的问题。如果需要解决问题在13日不能解决，要在13日的项目日报进行明确的
11、说明，并且不能将与问题相关的新代码加入到13日的创建中。如果项目组未按照规定进行工作，创建小组有权不进行新的创建。测试部有权拒绝对新创建进行测试。10) 向FTP服务器上传文件的时间是13日12：30以前，如果有重新创建，则最后时限是13日的14：00。上传之后，要发送电子邮件通知美国公司和总经理。11) 在需求分析阶段，在第一次创建开始后，日创建的频度最低要达到每3天一次。在系统设计阶段，日创建的频度最低要达到每5天一次。在编码阶段，日创建的频度最低要达到每2天一次（建议最好每天一次）。5 奖罚办法日创建和冒烟测试工作需要创建小组、项目组和测试部之间能密切配合，协同工作。进行日创建工作的目的
12、是通过项目开销的略微增加来换取集成风险的明显减少和过程可视性的改善。因此必须建立对破坏创建行为的惩罚。破坏创建的行为应该是例外，而不是惯例。保证创建正常进行是项目组的首要要考虑的问题。要杜绝破坏创建的情况在无意中发生。当某个开发者的代码在测试中出现了破坏创建的情况，项目经理应坚持让他停下其它工作，直到他把已经出现的问题改正。5.1 创建小组1） 如果在冒烟测试中发现错误是由于创建工作造成的，每出现一次，绩效系数扣0.05。这些错误包括版本的问题、平台的问题等。如果影响了按时提交，每次扣0.1。2） 如果在开发服务器上将文件放错了地方，文件命名错误或者没有按时提供，每出现一次，绩效系数扣0.05
13、。3） 如果在FTP服务器上将文件放错了地方，文件命名错误或者没有按时提供，每出现一次，绩效系数扣0.1。如果没有发送邮件，每出现一次，绩效系数扣0.05。4） 在向产品库中检入文件时，如果没有进行标注或者标注错误，每出现一次，绩效系数扣0.05。如果由于操作错误，造成重大损失的，每出现一次，绩效系数扣0.1。如果是不可恢复的损失，视情节严重情况，由公司决定具体处罚措施。5） 如果整月没有发生任何错误，当月绩效系数加0.1。5.2 测试部1） 如果由于测试人员自身原因，使冒烟测试没有在12：00之前（对重新创建在14：00之前）完成，每出现一次，绩效系数扣0.05。如果是影响有提交性质的创建，
14、每出现一次，绩效系数扣0.12） 如果没有按照规定的测试程序进行测试，并且相关的BUG被客户提出，每出现一个A类BUG，绩效系数扣0.1。每出现一个B类BUG，绩效系数扣0.05，其他BUG，每出现一个扣0.025。3） 如果没有按时提交测试日报或者测试日报中的内容不符合要求，每出现一次，绩效系数扣0.05。4） 在开发服务器上将测试日报放错了地方，文件命名错误，每出现一次，绩效系数扣0.025。5） 如果由于没有对重新创建优先进行测试，每出现一次，绩效系数扣0.05。6） 团队绩效：如果在整月当中，按照规定的测试程序进行了测试，设公司所有项目的冒烟测试的总次数为T，客户在创建中没有发现在当次
15、测试范围之内的C类以上BUG的次数为S，测试成功率KS/T100。如果创建失败，则将此次测试计入S中。a) 如果K100，绩效系数加0.2；b) 如果K95，绩效系数加0.15；c) 如果90K95，绩效系数加0.1。d) 如果85K90，绩效系数加0.05。e) 如果75K80，绩效系数减0.05；f) 如果70K75，绩效系数减0.1；g) 如果65K70，绩效系数减0.15；h) 如果60K65，绩效系数减0.2。i) 如果K60，团队绩效系数由公司根据情况处理，团队当月绩效系数最高不超过0.55.3 项目组1） 如果在开发人员未经项目经理同意，向开发库中检入文件，如果没有造成不可恢复的损失，每出现一次，绩效系数扣0.05。如果造成不可恢复的损失，项目经理可以视情节轻重，每出现一次，绩效系数扣0.1至0.3。如果是特别严重的损失，可以上报公司，停发当月绩效奖金。如果是经项目经理同意的，则开发人员不承担责任。相应责任由项目经理承担。2） 如果开发人员在向开发库中检入文件时，如果没有进行标注或者标注错误，每出现一次，绩效系数扣0.05。项目经理或者项目经理受权的配置管理员负责检查，如果开发人员承担配置管理员的工作，视项目规模当月绩效加0.05到0.15。3） 如果项目经理或者项目经理受权的配置
