关于软件开发与测试流程图的问题？

烟水寒

附件中的软件开发与测试流程图是我自己画的，
还有部分问题希望向各位老师同学请教：
问题（1）：在测试各阶段的文档后是否需要“评审”后再放纳入需求跟踪与变更控制中？而这样的评审显然不是同行评审，那应该是什么样的评审流程或标准呢？
问题（2）：通过这么久的学习，我始终不是很明白需求管理，配置管理，缺陷管理，同行评审在整个流程中是如何运用的，或是说如何体现的？

如果图中还有什么问题希望大家多多指教，谢谢！

AlexanderIII

问题（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 编辑 ]

jason_zhang82

辛苦你拉，最近老师比较忙啊，不过我想他们一定会抽空给你解答的。
帮你顶了。

夏雪

LZ好用功，辛苦了

skinapi

首先一定要明确开发和测试的流程不是唯一的，这里画的也就只能算是一种可能的流程，可以对照V&V模型来看一下。

烟水寒

先谢谢各位的解答了，就是因为需求管理的内容比较多，需求分配,需求评审,需求基线,需求跟踪,和变更控制这五个内容.(查看第一册P269)，所以我才对求需求管理，配置管理，缺陷管理，同行评审在应用上的共同部分很混乱，有时候感觉都可以用一样，总有那么点不清楚的。
另外有老师告诉我测试计划等文荡没必要在开发评审后才进行，而是开发文档完了就开始写测试计划，这点我不是很同意，希望大家可以讨论下。

天网

测试计划是一个活动，《测试计划》文档只是其活动的输出工作产品。在计划活动中，做计划的人需要沟通、协调、确定很多方面的内容，如组织架构、测试中的一些原则标准等，这些内容是可以和开发并行进行的，并不需要等到开发文档评审了才开始。

其他问题有空再解答：）

hong12345

其实我们现在准备面试时还是有些迷糊，感觉这些流程是正规的，只是公司的运作有些不一定会按照这个来走，所以还是要到公司具体做了才能消化其中的内容sdlkfj1

天网

问题（1）：在测试各阶段的文档后是否需要“评审”后再放纳入需求跟踪与变更控制中？而这样的评审显然不是同行评审，那应该是什么样的评审流程或标准呢？
   
    答:测试各阶段也需要进行相关的需求跟踪活动,主要是把各阶段的分析设计产生的测试项\测试子项\测试用例逐级进行跟踪,保证每个环节的测试活动结束后,需求和设计能保证将被验证到,这是属于需求跟踪部分;而测试文档评审通过后,纳入到配置管理中,变更受控,这是属于配置管理流程.
    同行评审是邀请工作产品的作者的同行来对工作产品进行评审来发现其中缺陷的一种活动,测试相关文档的评审也是同行评审,只是这里评审的工作产品是测试文档而已.

天网

问题（2）：通过这么久的学习，我始终不是很明白需求管理，配置管理，缺陷管理，同行评审在整个流程中是如何运用的，或是说如何体现的？


答:看了你后面的讨论，感觉你可能主要是把这几部分交叉的内容没搞明白。我下面就把它们的关系理一下：
      需求管理的内容涵盖对需求的配置管理、需求的缺陷跟踪、需求的评审等。但配置管理、缺陷管理、同行评审等并不仅限于对需求这个对象，还包括对软件其他工作产品的相关管理。   

      需求管理包含：需求分配,需求评审,需求基线,需求跟踪,和变更控制。
              其中： 需求分配是在需求分析阶段，将原始需求或者上级需求分配到各项目组；
                        需求评审是各项目组针对分配下来的需求或者经过需求分析后的需求规格进行评审，这个评审可以走同行评审的规范流程；
                       需求基线是评审通过后的需求文档、需求项被纳入配置库、列为配置项进行配置管理，建立起需求基线，后续的开发应该以这个需求基线为基准；
                      需求变更控制是指基线化后的需求如果要变更的话就要走配置管理中的变更控制流程了，这时需求已经成了配置项，它的变更和其它配置项一样是受控的；
                     需求跟踪要求在系统开发测试各阶段，将该阶段工作产品（需求项、HLD各模块、LLD函数、测试项、测试子项、测试用例等）和上一阶段工作产品进行跟踪，保证在该阶段活动结束后，所有需求得到了实现和确认。这是在每个开发测试环节都应该做的一项工作。
                    
                     缺陷管理是对软件工作产品中的缺陷从测试发现到修复到验证确认的一个过程，其中不仅指代码中的缺陷，也包括文档如需求文档中的缺陷。

烟水寒

找了很久，发现还没看见周老师的回答^_^
今天回过头来看，收获还是很大。