51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

12
返回列表 发新帖
楼主: 默默巫
打印 上一主题 下一主题

软件测试完成以后,怎样进行有效深层次的数据分析?(08-11-17)(获奖名单已公布)

[复制链接]

该用户从未签到

21#
发表于 2008-11-21 09:42:45 | 只看该作者
占座先
回复 支持 反对

使用道具 举报

  • TA的每日心情

    2015-9-10 15:08
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    22#
    发表于 2008-11-21 11:13:16 | 只看该作者
    默默巫1  无限接近默默巫  
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    奋斗
    2018-2-28 18:04
  • 签到天数: 40 天

    连续签到: 1 天

    [LV.5]测试团长

    23#
    发表于 2008-11-21 11:26:32 | 只看该作者

    回复 2# 的帖子

    呵呵。阿七的报告很不错啊。我都有点不好意思拿出来了。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    24#
    发表于 2008-11-21 13:33:30 | 只看该作者
    二楼写的真好~~
    正要写报告哩~
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    25#
    发表于 2008-11-21 14:33:38 | 只看该作者
    在测试完成之后,对数据的分析,一般都是从产品的质量和产生产品的过程中间来进行考虑,数据收集分析的前提都应该
    明确我们的目的到底是什么,如果目的都不明确,那我们在分析的时候,就很难我们可以发现我们现在存在的问题,为以后
    我们的过程改进进行考虑
    从质量上考虑(一般情况下从这几点考虑)
    1.对发现的bug进行有效的原因分类,数据的收集和统计,分类不一定很细,但是要有区分,我见到过一个项目组,由于对bug票
    的分类过细(公司模版的问题),有些问题点,不知道选什么,以至于后期数据统计没有意义,不能发现问题的根本,分类的
    原则是在每个担当都能清楚之间的区分的前提下,满足最细化,对其中的数据进行统计,看占百分比比较大的前几个,看都是
    什么类型的问题,从这上面找到改进的切入点
    2.在测试阶段,对测试结果进行混入工程的分类,即这个错误是在什么时候引入的,是需求,是设计,还是编码,对这些数据
    统计,我们可以得到我们现阶段评审或测试的有效性,如果发现我们在结合测试阶段发现很多单体测试的问题,那我们要在单体
    测试上进行改进,如果我们测试的时候,发现很多应该在设计review时发现的问题,那我们要对我们review的过程进行改进
    3.对发现的bug的严重程度进行分析,看严重程度的分布是否正常,如果都是发现一些不重要的错误,对逻辑错误发现的比较少
    那在这方面也需要进行改进
    从过程上考虑
    1.测试时间与发现的bug数
    2.担当人员发现的bug/kloc
    待续

    [ 本帖最后由 张明 于 2008-11-21 17:29 编辑 ]

    评分

    参与人数 1综合技术指数 +5 收起 理由
    默默巫 + 5 参与奖励

    查看全部评分

    回复 支持 反对

    使用道具 举报

    该用户从未签到

    26#
    发表于 2008-11-21 16:35:22 | 只看该作者
    占个位置!
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    27#
    发表于 2008-11-21 17:11:11 | 只看该作者
    #2归纳的很到位,深受感染。我个人觉得,
    1、报告总结是写给谁看的,对象是谁,这个得搞清楚吧?!
    2、报告是什么性质的,功能、性能、兼容性?
    3、报告的用途,产品发布评审用?项目总结大会用?
    4、报告的重点,个人觉得一定要给出自己的结论、建议,要突出测试的价值在里面
    5、遵循公司相关文档的规范
    6、篇幅不要太长,最好图文并茂!

    评分

    参与人数 1综合技术指数 +5 收起 理由
    默默巫 + 5 参与奖励

    查看全部评分

    回复 支持 反对

    使用道具 举报

    该用户从未签到

    28#
    发表于 2008-11-22 01:37:43 | 只看该作者
    问:
    在软件测试完成后,采用工具(TD、QC)或人工收集了一些数据,形成了各种图表。
    怎样去发挥这些数据的作用,进行有效深层次的数据分析,从而改进测试流程,完善测试过程?
    答:
    本问的焦点是 对数据进行有效的深层次的分析,想要完成对测试流程改进,完成测试过程。

    个人理解:
    两个层次的事情。一是对整理数据,对测试观察产品质量的提升;二是对测试产品的几个测试周期的观察,提高对产品的测试的流程进行优化。这个流程就是分析产品BUG的周期 ,掌握产品bug的主要特性点。后面我有详细说明。

    先看看对产品的数据分析,说道这些工具,呵呵个人以为是始终是一个工具,辅助手段,结果是提高了分析的效率,对第二点没有任何影响。
    说说分析这些数据的过程,假定你已经知道这些数据是要来干什么的,对应到测试过程,就是分析数据,缺陷分析的过程。 这个过程是得到测试结论的主要依据。
    缺陷分析,对应到产品,【假定你在产品测试钱已经对产品的测试特性做了分析。】【测试特性,是产品的特性,产品的模块的功能描述】找到那些特性有缺陷,具体的缺陷分布如何?产品的模块的功能是否稳定,并针对具体的bug,解决bug的程度,bug遗留的情况,得出测试版本的质量评估。
    客观,实际,是分析人员必须具备的条件;对特性的掌握熟练是必须的,对工具的使用要求程度一般,不需要依赖具体的测试分析模板;

    接着看第二点。不在局限在某一个版本,需要对连续的几个版本进行统计分析。这个时候分析的重点是单个特性成熟分析、结论,不在是局限在产品版本中。某个特性的持续分析,整体特性的分析,就能知道整个测试工作的重点,调整测试流程的重点。 这个时候,多个产品和版本测试形成的就是一个测试流程的雏形。
    后继就是多次对测试流程的精简,优化,改进,使之使用于其他的大多数产品。

    评分

    参与人数 1综合技术指数 +5 收起 理由
    默默巫 + 5 参与奖励

    查看全部评分

    回复 支持 反对

    使用道具 举报

    该用户从未签到

    29#
    发表于 2008-11-22 10:19:32 | 只看该作者
    作为新手,还只能认真的倾听大家对这么高深的问题进行讨论,呵呵
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    30#
    发表于 2008-11-24 10:55:11 | 只看该作者

    回复 2# 的帖子

    看样子 挺好 ::xixill:::
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    31#
    发表于 2008-11-24 15:49:06 | 只看该作者
    感觉楼主想要问的问题,是对完成测试后,一些数据的挖掘,类似于一些数据仓库的功能,一种分析当前,预测未来的挖掘.
    比如说明当前测试的结果,然后挖掘分析,下轮测试,问题会集中在哪个模块,集中在什么类型的问题,然后在下轮测试中应该重点测试那些模块,多注意那些类型的问题等等.
    针对我的理解,我认为,把数据根据自己所需要的画图表\分析就可以了.其他的如每个测试人员测试的情况 ,这个是对测试人员的工作的评估,对下轮测试没有什么指向性目的.
    还有我们做软件的应该很清楚,使用数据库对数据挖掘,分类是非常重要的,所以其他的什么测试报告如何编写,,告诉项目经理测试结果,项目经理应该知道那些测试结果,这些是必须的,但是预测\风险才是测试完成后数据有效的,深层次的分析.
    至于怎么进行,可以借助一些数据集市的分析模式,出一些多纬度的报表或图表,然后根据自己的经验进行分析.

    自己的一些浅知拙见,不知道对不对,呵呵

    忘了说,这种数据挖掘是一种持续性的过程!~如果只是做完项目就走的,不实用!不过在对同一个系统,或同一类型的开发软件还可以借鉴的.

    [ 本帖最后由 ljdlx 于 2008-11-24 15:52 编辑 ]

    评分

    参与人数 1综合技术指数 +5 收起 理由
    默默巫 + 5 参与奖励

    查看全部评分

    回复 支持 反对

    使用道具 举报

    该用户从未签到

    32#
    发表于 2008-11-24 16:49:47 | 只看该作者
    占个座,好好学习
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    33#
    发表于 2008-11-25 11:21:25 | 只看该作者

    回复 1# 的帖子

    问题中提到的是深层次的分析来改善测试流程与方法,就这点说一些自己的看法.

    1. 测试案例的完成情况:
    一般测试案例都是按模块来分的, 那就可以从历史纪录中看出特定模块基本稳定的时间, 需要周期, 以及其间质量反复的程度. 如果一个高优先级的模块完成的时间较晚,耗时较长,那就可以分析是不是开始测试的时间是否可以再提前, 相应的测试案例是否可以扩充,是否遗漏了什么导致了整个测试流程耗时过长, 如果是开发小组的问题,那就要提出以求改进.

    2. 测试bug的情况:
    一般bug数量总是有一个峰值,需要看一下这个峰值是不是处于项目的后期,如果是的话,那就整个team来分析原因,应当尽量将这个峰值往前移,这里面涉及到测试前期的准备,开始的时间,力度以及与开发小组协调等等各种因素。具体情况具体分析。

    一般对于测试结果的分析只能分析出当前存在的问题,具体要进行的改进需要整个工作组(上至产品经理,下至开发人员与测试人员)进行讨论分析。
    但一般大公司是没什么办法的,因为束缚的东西太多,你反映了也到不了上层,而其他的部门又不定会做这样的分析,小公司可以考虑搞搞。
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    无聊
    2015-12-2 10:12
  • 签到天数: 5 天

    连续签到: 1 天

    [LV.2]测试排长

    34#
    发表于 2008-11-26 17:05:24 | 只看该作者
    好少人吖!!!!
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    35#
    发表于 2008-12-10 19:30:02 | 只看该作者
    CMMI3中最为重要的就是度量与分析的过程,没有好的度量,分析就无从下手,因此在进行有效深层次的数据分析之前,要先定义准确的度量项。
    度量项有公司定义的组织级度量项,也可以有测试工作自己定义的度量项,下面我列举一些度量项:
    1.bug检出率
    发现的bug数/注入的bug数+遗留的bug数×100%
    bug检出率是检测测试人员测试能力最好的一个度量项,通常系统测试阶段bug检出率应该在98%左右,其余遗留的还不能包括重大的错误。
    2.bug注入率
    bug注入率是注入阶段注入的bug数/总的bug数×100%就是bug注入率,测试过程不会有注入率。
    3.bug遗留率
    bug遗留率就是遗留到以后阶段的bug数/发现的总bug数×100%,这也是衡量测试人员执行测试有效性的一个很好的度量项,与bug检出率同时进行分析更有效。
    4.测试缺陷密度
    测试缺陷密度单单的高或低都不能说明测试的能力强弱,要与bug检出率和bug遗留率同时分析,通常的项目缺陷密度都是3.5/KLOC,如果发现的缺陷密度很高,而且bug检出率也很高,遗留率也很低,那么测试能力就是很强的了,如果发现的缺陷密度很高,而bug检出率很低,遗留率又很高,那么只能说项目的质量不过关,测试人员能力有问题。
    5.测试用例覆盖率
    测试用例覆盖率是衡量测试用例的质量的,没有一个很好的标准衡量所有的项目的测试用例覆盖率,只能根据公司的历史数据,识别出一个适合自己公司的度量项,测试用例覆盖率高了,才会不会留下死角,才能提高bug的检出率,保证产品的质量。
    6.测试用例执行效率
    测试用例执行效率是度量测试人员能力的,也是没有一个一成不变的数据去衡量,根据项目的复杂度,规模,测试用例的逻辑复杂等等因素,综合考虑测试用例的执行效率才是正解。
    7.bug分布情况
    bug分布情况是对bug分布阶段的一个分析,主要是描述整个开发过程注入bug率的分布情况,可以包括从需求开发到编码整个过程的bug注入率分析。
    根据这些度量项,与公司或者部门内部定义的基线,确定是超出了基线还是未达到基线,从而对未达到基线的问题进行问题的根源分析。
    根源分析的方法有很多,例如帕累托原理分析或者鱼骨图分析法,波士顿矩阵,头脑风暴等对问题进行分析。
    首先利用波士顿矩阵将问题的优先级进行排列,分析出哪些问题是优先级较高,哪些较低,然后对优先级别较高的问题使用帕累托原理进行分析,确定20%的精力的投入点。
    分析出问题的解决办法之后,针对每个问题制定行动计划,并且对行动进行跟踪,分析下次改进后的结果进行对比,如果有改进了,说明行动计划是有效的,并持续进行下去,如果发现没有改进,则换一种思路重新制定行动计划。
    测试完成之后不单单要对项目的测试情况进行分析,而且要对测试工作完成之后测试人员的成长情况进行分析,分析方法基本相同。
    单独的数据放在那就像废铁一样,只有通过对数据的分析得出我们想要的结果,并制定改进计划才是正道。
    稍后会把波士顿矩阵和帕累托图附上.

    [ 本帖最后由 duola1119 于 2008-12-11 08:41 编辑 ]

    本帖子中包含更多资源

    您需要 登录 才可以下载或查看,没有帐号?(注-册)加入51Testing

    x
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    36#
    发表于 2008-12-10 22:09:20 | 只看该作者
    数据分析无非是开发或者测试团队的效率
    或者评估产品的质量
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    37#
    发表于 2008-12-10 22:09:32 | 只看该作者
    数据分析无非是开发或者测试团队的效率/有效性
    或者评估产品的质量
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

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

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

    GMT+8, 2024-11-14 15:08 , Processed in 0.086110 second(s), 28 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

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