|
问题(1):在测试各阶段的文档后是否需要“评审”后再放纳入需求跟踪与变更控制中?而这样的评审显然不是同行评审,那应该是什么样的评审流程或标准呢?
个人觉得,测试各阶段的文档的评审还是要的,只是这个评审的人是测试经理了,如果在ST阶段,STP文档是由此测试经理定的话,具体针对此文件的评审,应该可以由同级其它项目的测试经理来评审(只是个人意见,具体是否这样,还应该让明白的人来讲一下). 具体这个测试文档的评审标准与流程,应该主要还是看有经验的测试人员来判断吧,也许可以开个评审会议(与同行评审的过程一样).
每个测试文档应该是物理上被通过配置管理的工具(CVS,VSS等)来进行管理,而测试文档(STP,ITP,UTP等)内的内容与开发文档(SRS,HLD,LLD等)应该是说被逻辑上纳入需求跟踪中,而实现这个逻辑相关性的物理体现,则是RTM表. (参考周峰老师上课讲过的需求跟踪逻辑关系图) 需求管理工具,商业化的实现有DOORS,TESTDIRECTOR等.针对需求跟踪来讲,如果觉得开发能力不错,可以自己开发出来,实现应该不会很难,只要你理清楚了需求跟踪的逻辑关系了,可以用WEB+数据库搞定.
这里你要明白需求管理有需求分配,需求评审,需求基线,需求跟踪,和变更控制这五个内容.(查看第一册P269)
问题(2):通过这么久的学习,我始终不是很明白需求管理,配置管理,缺陷管理,同行评审在整个流程中是如何运用的,或是说如何体现的?
需求管理->DOORS实现,需求管理中的需求跟踪则可以用RTM文件来进行实现
配置管理->CVS,VSS,CLEARCASE实现,配置管理主要就是对整个项目的文档和代码进行管理
缺陷管理->BUGZILLA,QC,JIRA,MANTIS,CLEARQUEST实现,这个主要用QC就得了,从各个阶段的需求项直接可以跟踪到具体的测试用例里,我特喜欢这个,嘿嘿
同行评审在流程各阶段都可以用呀,它有正规检视,技术评审,走读三种方式呀,假如要对一个文档进行评审,则可以从配置库中读取出这个被基线化了的文档在自己的电脑上进行评走读,然后向配置库中提交你所发现的问题与其它相关信息.
妈呀,终于写完了,其它同学老师一块讨论一下,共同学习! 其实我也对测试文档的评审这一块有点疑问的,是不是就和我讲的差不多?还是怎么样?
[ 本帖最后由 AlexanderIII 于 2006-10-12 23:25 编辑 ] |
|