51Testing软件测试论坛

标题: 软件项目品质控制请教 [打印本页]

作者: chengxq 时间: 2009-4-17 14:25
标题: 软件项目品质控制请教
今天开会，由于我犯傻了，搞得气氛不对，有一个问题我没有再提
问题的内容是关于单体测试的品质控制，我们在项目计划时，在单体测试阶段都设定了
品质目标，如bug率，现在实际进入单体测试后，每天都需要对质量进行控制，按照理论上
来讲就是每天看实际和设定的品质目标是否有差距，如果有的话，进行相应的分析，必要的时候进行调整，这个理论没有问题，但是实际上，如bug率，我们如何进行判定，bug率的单位都是bug/kloc，如果我每天都对质量进行监控，bug可以度量出来，但代码量如何进行？我们可以做的是整个项目的代码行数，但是说每天测试了多少行代码这样的说法好像也不现实，不知道那位牛人在这方面有何实际操作

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

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

作者: kuailederen 时间: 2009-4-20 16:55
我没有那方面的经验。但我觉得你们还是被自己制定的流程束缚了手脚。
我提倡的是尽量的简化过程，只要抓住几个要点就可以了。

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

作者: chengxq 时间: 2009-4-20 17:57
标题: 回复 4# 的帖子
kuailederen，我以前也想简化流程，可是一旦简化了，发现有效性和可控制性就降低
也是我最近的困惑阿

作者: yangxiaowen0622 时间: 2009-4-20 22:53
看到你用了单体测试这个词眼而不用单元测试。我想你应该是做对日外包的吧。

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

以前，小日本很喜欢这个图的。除了要buglist之外，就天天要这个图看。

作者: chengxq 时间: 2009-4-21 08:56
标题: 回复 7# 的帖子
呵呵

我们公司是对日外包，只有日本鬼子才叫单体测试阿，我以前还没有注意

作者: yolander 时间: 2009-4-21 09:47

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

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

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

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

作者: MarsNoNo 时间: 2009-4-21 18:15
我们公司除了我这个51毕业的和一个51版主外，估计就没人知道bug数/KLOC是啥意思……
我那个郁闷啊！！！
我最近也在思考这个问题，品质控制如何建立起来？希望得到大家的帮助！谢谢了。

作者: xsnzhq 时间: 2009-4-23 10:49

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

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

作者: shunfyu 时间: 2009-4-23 11:17
难怪看不懂“单体测试”，汗~~~ 原来是小日本的东西。。。 bug/kloc 不适用于WEB的应用程序吧？我的项目是WEB的，UT 是程序员和测试员共同做的，没有搞什么bug/kloc。。。 SQA也是定期检查，不过项目内部有ISQA。。。

作者: chengxq 时间: 2009-4-24 11:48
标题: 回复 12# 的帖子
是的啊
这就是我为什么发这个贴的原因阿，理论上说百分之80的错误发现在百分之20的模块，所以
每天的监控有局限性阿，但是好像也没有别的好的方法，所以我想知道各位高人在公司是如何
操作的啊

作者: chengxq 时间: 2009-4-24 11:50
标题: 回复 11# 的帖子
呵呵，这很难搞，不过我建议先制定开发的流程，然后让相关人员去承认它，使用它，最好是
现在执行过程的文档化，还有先从配置管理入手

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

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

[ 本帖最后由 mgs2-007 于 2009-4-24 17:01 编辑 ]

作者: chengxq 时间: 2009-4-24 17:20
标题: 回复 16# 的帖子
楼上的没有注意我上面发的帖子
如果通过测试case和发现bug建立关系的时候，对于整体来说是有意义的，但是就针对每个画面或每天的消化case来说是没有意义的，原因是分之80的错误发现在百分之20的模块

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

[ 本帖最后由 mgs2-007 于 2009-4-27 15:32 编辑 ]

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)