Starteam使用规范.docVIP

STARTEAM使用规范 密　　级：I级 文档编号： 项目代号：Test 版本控制 版本号 日期 修改人 说明 V0.1 2005-1-22 邓炜春 创建 参考文档 《Change Request 填写规范.doc》 《starteam填写规范草稿.xls》 编写背景 Border Protector产品在开发和测试过程中，依赖Starteam 进行Bug的交流和修正，Starteam的良好管理，有助于推动Border Protector在后续两个月的集成和回归测试的顺利展开。同时，通过制定BP Starteam的使用规范，推动其它产品和项目对Starteam Bug管理系统的规范化使用。 本文档重点在于Starteam的使用，关于Starteam的安装、备份和管理，请参见《Starteam的安装、备份和管理》。 下面，本文档将从： View和Folder的创建； Change Request填写说明； Bug生命周期管理； 测试和开发填写注意事项； 进行讲述，完善Bug管理。 View 和Folder的创建 View的创建是Bug管理的第一步，在测试计划制定时，需要考虑测试的版本和过程，从而在不同的测试阶段，Bug输入到阶段性的View中，方便对Bug进行总结和分析。View的创建体现了软件版本规划的清晰性，可以对每个milestone设置一定的软件质量要求，比如优先级为High的Bug不能超过3个。View的创建也体现在有不同branch时的清晰性，不同branch的软件版本，实现的功能要求是不同的，没有必要把所有Bug都归属于某一个branch下面，这样会对bug的重现和管理造成混乱。 就BP而言，View的创建可以按照版本号进行规划，从开始的BP 1.0到BP Alpha 1.1再到BP PRODUCT 1.2版本迈进，下一步可以推进到BP Product 1.3 或者以上。但是View的推进一方面是软件功能的增加变化，另一方面也需要按照前一个View Bug的收敛程度创建。如果上一个View的收敛程度不够，即软件版本的可靠性和稳定性不够，会对将来的View产生深远的影响，会出现比较多诡异难以复现的Bug。 Folder的创建体现了软件本身模块划分的清晰性，因为开发人员负责不同的模块，测试人员也负责测试不同的模块，对于这些模块Bug管理的有序性和可评估性有着重要的作用。良好的Folder划分能加速Bug的修复、验证和总结分析。对于两种情况，需要特殊考虑，第一是功能模块交叉的Bug，第二是稳定性的Bug，很难把这些Bug归到那个模块中，所以需要单独建立Folder，有开发负责人、测试负责人和产品经理一同讨论分析以决定Bug的最终归属。 Change Request填写说明 Change Request的结构： 目前限于STARTEAM功能上的局限性，仅有以下几个选项可以利用： CR Number 系统自动分配，因为Change在数据库中就是一个表，所以CR是各个产品项目分享递增的； Status 状态 含义 责任人 下一跳 New 新建Bug 开发 Open到具体模块开发人员 Open Bug分派 开发 In Progress，Cannot Reproduce，As Designed，Documented，Is Duplicate，Deferred In Progress 处理Bug 开发 Fixed，Deferred Cannot Reproduce 不能复现 测试 Verify Cannot Reproduce ， Open让开发确认重现的场景 As Designed 软件本身设计就是这样 产品经理，开发负责人，测试负责人 Open 与软件设计不符 Documented 暂时搁置 Verify As Designed Documented 暂时搁置，作为参考 产品经理，开发负责人，测试负责人 Open 问题比较严重，不能搁置 Deferred 下一版本解决 Verify Documented Deferred 推迟到下一版本 产品经理，开发负责人，测试负责人 Verify Deferred Is Duplicate 重复 测试 Open 测试坚持现象有所不同 Verify Is Duplicate Fixed 已经修复 测试 Verify Fixed 验证已修复 Open 没有完全修复，能复现 Verified Fixed 已验证修复 测试，测试负责人 Close（Fixed）达到产品开发的milestone，形成基线版本 Open 回归测试中Bug重新出现 Verified As Designed 已验证设计如此 产品，测试 Close（As Designed）