51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 4252|回复: 8
打印 上一主题 下一主题

[讨论] review设计文档

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2006-6-15 13:03:34 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
想和大家讨论一下你们公司是否有review设计文档或者code的举动。在review过程中,似乎效果不是非常明显,一般人不太愿意或者说有足够的时间去看别人写的东西,review是帮助大家找出不足的地方,这个过程会花费较多的时间和精力,但review又不能不进行,不晓得大家如何解决这个问题的
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

2#
发表于 2006-6-15 13:32:28 | 只看该作者
的确,在评审过程中需要花费较多的时间和精力,但有时候似乎效果不是非常明显,觉得评审似乎意义不大.但不能因为这样我们就放弃评审.我们要在前期就要尽量保证我们软件产品的质量.对于需求文档就要开始参与评审,不让前一阶段的缺陷遗留到下个阶段中去,已至于缺陷被放的越来越大和越来越多.导致修改这些缺陷所需的成本也越来越高,项目进度也会因为要过多修改这些缺陷而受到影响,也直接影响到了软件产品的质量.所以虽然表面上我们好象发费了大量的时间去对文档评审,但实际上我们是在早期就去除缺陷,用最少的成本修改缺陷,来提高软件质量.其实评审也是需要事先准备,计划和做好进度安排的.要例出评审点和检查点.参与评审的专家也要有足够的技术能力和经验,不然会把评审变成一种学习,找不出有价值的缺陷.评审一方面是在找出文档中和代码中错误,也可以用做对新人的一种培训和学习,看看人家写的文档和代码的优缺点.

[ 本帖最后由 xiaonan 于 2006-6-15 13:35 编辑 ]
回复 支持 反对

使用道具 举报

该用户从未签到

3#
发表于 2006-6-15 18:07:25 | 只看该作者
说说我们的搞法吧
1、做项目计划时候,要给评审留出时间,安排计划;
      假设你估算的产出50页设计文档,而本公司的评审速率一般来说是5页/小时,这就是说,你要给每个评审员10小时的时间去评审这个东西;
2、培训评审主持人,使评审主持人像管一个项目一样去管理一次评审
      事先要有评审计划;把关评审材料使其具备评审条件;跟踪评审员保证预审效果;评审会议做好主持;做好评审收尾工作;
3、总结经验,给出合用的检查单和有指导意义的质量数据
回复 支持 反对

使用道具 举报

该用户从未签到

4#
 楼主| 发表于 2006-6-16 13:11:41 | 只看该作者
谢谢两位版主,如果时间比较紧的项目往往就把review省略掉了,后来又发现很多的不统一,实在是造成了不少的困扰,可能还是开发过程的规范问题吧。那review的时间也是安排在schedule里的是吗?
看来我们的项目要好好改进改进方式了
回复 支持 反对

使用道具 举报

该用户从未签到

5#
发表于 2006-6-19 13:00:19 | 只看该作者
是的
如果时间确实紧  与其不分重点 毫无目的性的应付性全面评审
还不如在计划时候就缩小评审范围
保证重点内容的评审效果
回复 支持 反对

使用道具 举报

该用户从未签到

6#
发表于 2006-12-6 14:55:28 | 只看该作者
我们公司是关键代码是小组汇审,其他是开发人员自审,经理随机抽查
回复 支持 反对

使用道具 举报

该用户从未签到

7#
发表于 2006-12-8 16:15:27 | 只看该作者
评审的效果是有的,但是成本也是高的。一堆人围在一块评审,就是N倍的投入。也正是这个原因,在效果和成本的性价比下,初期就让很多项目组放弃了。

如果能建立典型,有做评审的,在项目后期的效果明显好在哪,节省的bug修复、沟通交互等。典型带动下,会有人跟随的--谁有案例借我参考参考:)
回复 支持 反对

使用道具 举报

该用户从未签到

8#
发表于 2006-12-8 18:01:18 | 只看该作者
楼上的又是要度量啊 呵呵
回复 支持 反对

使用道具 举报

该用户从未签到

9#
发表于 2006-12-9 14:54:55 | 只看该作者

评审的效果还是很好的,拿我公司之前评审测试用例举个例子吧

关键是有没有一个制度把评审的活动规范化和制度化,不是谁一时高兴就提了建议大家一堆人拿着用例开始头脑风暴了,结果最后效率的确很低很低
1、需要有一个内部的工作流程确定什么时候需要召开什么内容的评审
2、评审必须有专人来主持,并且定出评审规范,否则瞎评可不行
3、为了提高评审效率,我们经理一般会预先把用例内容划分一下,每个测试人员自己先单独看一遍,然后按照用例格式、书写规范、设计流程这些内容,每个人各自归纳出来一个问题清单
4、之后开大组会的时候会把发现的问题讨论,然后负责当前测试用例书写的人回去修改测试用例
5、修改完毕之后,经理把之前独立检查用例的人员角色都调整一下,每个人再回去看用例的不同地方
6、再开一次大家交换意见,然后这个模块的用例就pass了


我们这么做的效果非常好,改变了以前每个人只了解自己测的模块内容的情况,现在就算把测试人员轮岗,测试的结果出入也不会特别大
回复 支持 反对

使用道具 举报

本版积分规则

关闭

站长推荐上一条 /1 下一条

小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

GMT+8, 2024-11-8 19:27 , Processed in 0.067124 second(s), 23 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

快速回复 返回顶部 返回列表