51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 4289|回复: 17
打印 上一主题 下一主题

[讨论] 软件项目品质控制请教

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2009-4-17 14:25:58 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
今天开会,由于我犯傻了,搞得气氛不对,有一个问题我没有再提
问题的内容是关于单体测试的品质控制,我们在项目计划时,在单体测试阶段都设定了
品质目标,如bug率,现在实际进入单体测试后,每天都需要对质量进行控制,按照理论上
来讲就是每天看实际和设定的品质目标是否有差距,如果有的话,进行相应的分析,必要的时候进行调整,这个理论没有问题,但是实际上,如bug率,我们如何进行判定,bug率的单位都是bug/kloc,如果我每天都对质量进行监控,bug可以度量出来,但代码量如何进行?我们可以做的是整个项目的代码行数,但是说每天测试了多少行代码这样的说法好像也不现实,不知道那位牛人在这方面有何实际操作
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

2#
发表于 2009-4-20 15:18:40 | 只看该作者
首先说一点,QA没有必要每天都对项目状态进行监控,只需要定期检查就可以了,可以是每周、每两周,也可以是每个月或者有必要评审时
对于单体测试的质量目标,通常我们的衡量标准是代码的测试覆盖率,而且现在有很多工具可以实现对代码的测试覆盖率的统计,不需要手工计算,再则单体测试的通过标准可以设置为千行代码的bug数,这个只要在单体测试结束后的阶段评审时统计就可以了,没必要每天都统计
回复 支持 反对

使用道具 举报

该用户从未签到

3#
发表于 2009-4-20 15:23:21 | 只看该作者
另外除了衡量统计数据以外,QA在单体测试期间还有许多比较重要的工作,例如:检查项目是否制定了相应的阶段工作计划?是否按计划执行了对详细设计的评审,以及代码的走查,对评审和走查的问题是否跟踪到解决直至关闭?单体测试期间发现的问题有没有被记录?状态是否及时更新等等
回复 支持 反对

使用道具 举报

  • TA的每日心情
    郁闷
    2018-8-3 13:59
  • 签到天数: 12 天

    连续签到: 1 天

    [LV.3]测试连长

    4#
    发表于 2009-4-20 16:55:19 | 只看该作者
    我没有那方面的经验。但我觉得你们还是被自己制定的流程束缚了手脚。
    我提倡的是尽量的简化过程,只要抓住几个要点就可以了。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    5#
     楼主| 发表于 2009-4-20 17:55:56 | 只看该作者

    回复 2# 的帖子

    你说的,我是清楚地,这个只是理论上的操作,但是在实际的过程中,如果QA不去监督,等项目真的出了问题了,以及很长时间了,这样及时性将会折扣,所以QA需要对每天的bug率等等数据进行关注,即时发现异常点,及时告知项经理,但是在实际的操作中,就出现了我上面的问题,不知道别的公司是如何操作的
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    6#
     楼主| 发表于 2009-4-20 17:57:35 | 只看该作者

    回复 4# 的帖子

    kuailederen,我以前也想简化流程,可是一旦简化了,发现有效性和可控制性就降低
    也是我最近的困惑阿
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    7#
    发表于 2009-4-20 22:53:21 | 只看该作者
    看到你用了单体测试这个词眼而不用单元测试。我想你应该是做对日外包的吧。

    我猜想是不是小日本要bug数的一个增长曲线图啊。小日本好像叫什么***依赖性曲线图。具体什么我忘记了。

    以前,小日本很喜欢这个图的。除了要buglist之外,就天天要这个图看。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    8#
     楼主| 发表于 2009-4-21 08:56:20 | 只看该作者

    回复 7# 的帖子

    呵呵
    我们公司是对日外包,只有日本鬼子才叫单体测试阿,我以前还没有注意
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    9#
    发表于 2009-4-21 09:47:29 | 只看该作者
    原帖由 chengxq 于 2009-4-20 17:55 发表
    你说的,我是清楚地,这个只是理论上的操作,但是在实际的过程中,如果QA不去监督,等项目真的出了问题了,以及很长时间了,这样及时性将会折扣,所以QA需要对每天的bug率等等数据进行关注,即时发现异常点,及时告知 ...

    每天的bug率为什么是QA监督而不是QC?感觉角色有点混乱呢?
    另外每天监督单元测试的bug率的意义是什么?每周统计一次的话会出现什么严重后果?
    本来bug率统计的意义就是用来衡量单元测试的整体工作效率的,用这个拆开了去计算每天的工作量感觉并不能把握住实质。
    莫不如看QC的bug统计曲线(总体的,新发现的,修正的等等),从这个来推断产品的质量趋势才更好吧

    产品的质量并不是靠QA一个人来保证的,是全员的责任,但我从你的描述上看,似乎就是你一个人在监督整个项目的质量,一旦你不监督了,那么项目就会失控,那你可真够累的
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    10#
     楼主| 发表于 2009-4-21 12:21:05 | 只看该作者

    回复 9# 的帖子

    呵呵,大家讨论一下挺好的
    可能我上面表述的不是很好,其实QA只是收集一下数据而已,而QC负责相应的分析和监控工作
    对日外包,可能大家都不知道规模不是很大,单元测试一般也就一到二周,如果每周进行监控的话
    那后期的返工等对于项目组来说很难接受的
    所以我现在想知道对于这种规模不是很大的项目,在单元测试应该控制什么,当然这局限于QA人员
    我想知道的操作方式
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    11#
    发表于 2009-4-21 18:15:49 | 只看该作者
    我们公司除了我这个51毕业的和一个51版主外,估计就没人知道bug数/KLOC是啥意思……
    我那个郁闷啊!!!
    我最近也在思考这个问题,品质控制如何建立起来?希望得到大家的帮助!谢谢了。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    12#
    发表于 2009-4-23 10:49:11 | 只看该作者
    原帖由 chengxq 于 2009-4-20 17:55 发表
    你说的,我是清楚地,这个只是理论上的操作,但是在实际的过程中,如果QA不去监督,等项目真的出了问题了,以及很长时间了,这样及时性将会折扣,所以QA需要对每天的bug率等等数据进行关注,即时发现异常点,及时告知 ...

    对于楼主说的这个问题,我还是觉得每天尽行监控实在是工作量太大,对于小型项目也不能够天天进行监控吧,周期似乎太短了,这样做也不见得能很好的保证质量啊。测试是一个过程,今天可能发现的问题多,但是明天又很可能发现的问题少啊,这和很多因素有关啊。对于那个模块的bug比较多bug率比较大也很容易通过bug管理工具来掌握啊,我觉得天天监控有点不现实。不论项目大小,都需要有个合适的检查周期!
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    13#
    发表于 2009-4-23 11:17:32 | 只看该作者
    难怪看不懂“单体测试”,汗~~~ 原来是小日本的东西。。。 bug/kloc 不适用于WEB的应用程序吧?我的项目是WEB的,UT 是程序员和测试员共同做的,没有搞什么bug/kloc。。。 SQA也是定期检查,不过项目内部有ISQA。。。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    14#
     楼主| 发表于 2009-4-24 11:48:32 | 只看该作者

    回复 12# 的帖子

    是的啊
    这就是我为什么发这个贴的原因阿,理论上说百分之80的错误发现在百分之20的模块,所以
    每天的监控有局限性阿,但是好像也没有别的好的方法,所以我想知道各位高人在公司是如何
    操作的啊
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    15#
     楼主| 发表于 2009-4-24 11:50:05 | 只看该作者

    回复 11# 的帖子

    呵呵,这很难搞,不过我建议先制定开发的流程,然后让相关人员去承认它,使用它,最好是
    现在执行过程的文档化,还有先从配置管理入手
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    16#
    发表于 2009-4-24 16:55:11 | 只看该作者
    我想首先我们每天测试都有测试Case消化的预计,发现的BUG是和Case有直接关系的,而Case也有测试用例的密度,就可以建立相互的关系了,Case检出BUG率,和单位千行代码中发现的BUG数,不知道你觉得这样能否解决你的问题。

    不仅如此,代码量的统计一般在单元测试之前肯定有统计,不然过渡不到这个阶段,因为首先肯定需要评审用例密度,这时候肯定需要代码行数。

    [ 本帖最后由 mgs2-007 于 2009-4-24 17:01 编辑 ]
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    17#
     楼主| 发表于 2009-4-24 17:20:15 | 只看该作者

    回复 16# 的帖子

    楼上的没有注意我上面发的帖子
    如果通过测试case和发现bug建立关系的时候,对于整体来说是有意义的,但是就针对每个画面或每天的消化case来说是没有意义的,原因是分之80的错误发现在百分之20的模块
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    18#
    发表于 2009-4-27 15:30:28 | 只看该作者
    回复 17# 的帖子
    2/8原理用在单元测试你觉得真的很准确吗,什么是单元测试??
    是否考虑一个模块内80错误分布在20的代码更合适呢,所以……
    你这样的理解,每个模块的测试用例,bug数的基线还有什么用处???

    [ 本帖最后由 mgs2-007 于 2009-4-27 15:32 编辑 ]
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

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

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

    GMT+8, 2024-11-23 13:45 , Processed in 0.080683 second(s), 27 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

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