51Testing软件测试论坛

标题: 软件测试完成以后，怎样进行有效深层次的数据分析？（08-11-17）（获奖名单已公布） [打印本页]
作者: 默默巫    时间: 2008-11-17 13:17
标题: 软件测试完成以后，怎样进行有效深层次的数据分析？（08-11-17）（获奖名单已公布）
在软件测试完成后，采用工具（TD、QC）或人工收集了一些数据，形成了各种图表。
怎样去发挥这些数据的作用，进行有效深层次的数据分析，从而改进测试流程，完善测试过程？

感谢会员JerryYe提供此精彩问题！如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！



获奖名单
奖项
获奖名单
奖励
答案链接
一等奖
阿7
当当购物卡50元
2#
二等奖
archonwang
300论坛积分
3#
二等奖
chengxq
300论坛积分
6#
作者: 阿七    时间: 2008-11-17 16:43
标题: 占位太久...
   楼主说的数据分析! 其实可以理解为测试完成以后所要做的测试报告和总结,因为总结里会包括你之前所做的,遇到的问题,已经你做完后想提的建议等.把测试的过程和结果写成文档，并对发现的问题和缺陷进行分析，为纠正软件的存在的质量问题提供依据，同时为软件验收和交付打下基础.这是测试报告的定义.

   通常，用户对测试结论部分感兴趣，开发人员希望从缺陷结果以及分析得到产品开发质量的信息，项目管理者对测试执行中成本、资源和时间予与重视，而高层经理希望能够阅读到简单的图表并且能够与其他项目进行同向比较。此部分可以具体描述为什么类型的人可参考本报告XXX页XXX章节，你的报告读者越多，你的工作越容易被人重视，前提是必须让阅读者感到你的报告是有价值而且值得浪费一点时间去关注的。

   至于测试报告的格式,一般都有模板,这里也不多说了,只说说要注意的部分.

1    简要介绍测试中采用的方法(和工具)。

   测试方法可以写上测试的重点和采用的测试模式，这样可以一目了然的知道是否遗漏了重要的测试点和关键块。工具为可选项，当使用到测试工具和相关工具时，要说明。注意要注明软件名称,版本号等...         
                          
2  测试结果及缺陷分析

   这是整个测试报告中这是最核心的部分，这部分主要汇总各种数据并进行度量，度量包括对测试过程的度量和能力评估、对软件产品的质量度量和产品评估。举楼主提到的TD为例子,可以用td生成BUG不同状态的数量表,如图1   


Closed
Fixed
Open
Postpone
Rejected
Reopen
<total>
2008-9-9


24



24
2008-9-10


26



26
2008-9-11


26



26
2008-9-12

8
22

1

31
2008-9-13

22
8

1

31
2008-9-14

22
8

1

31
2008-9-15

22
8

1

31
2008-9-16
18
5
13
1

1
38
2008-9-17
18
16
1
3
1
1
40
2008-9-18
37
2
1
2

1
43
2008-9-19
41
6

3


50
2008-9-20
42
7
3
3


55
2008-9-21
42
7
3
3


55
2008-9-22
51

2
3


56
2008-9-23
53


3


56
2008-9-24
53

1
3


57
2008-9-25
54


3


57

                                                     (图1)

从上图 可以看出 每一天 存在的BUG数有多少, 还有多少没有修改, 有多少BUG被重新打开 等等... 而且还可以细分到人,如BUG总数里有多少BUG 是谁找到的,BUG的严重程度是什么,是否是比较显性的,是否是很隐性的,这样就可以从一个方面考察测试人员的综合素质.

此外可以用生成的BUG 走势图,更直观的分析测试流程是否正常,见下面的粗略分析 (呵呵)

[attach]47005[/attach]

open线可以看出这个项目是提交了3次版本的  11号  17号   21号 3次版本提交, 这与实际的情况一致
Fixed线也是可以看出3个波峰.其他的线也是中规中矩,
这几个指标都符合1版本80%   2版本90%   3版本98%的通过率.这是很正常,流程走的很顺的一次测试任务.



那再看下面的这张图
[attach]47006[/attach]

分析：
Open线 也是出现了3个波峰,但是不是按照 " 高-中-低 " 的方式排列,而是 3个相同差不多的波峰,这就说了3个可能 .
   一  可能是测试人员不合格,在测试第1版本的时候没有全力测试  
   二  可能就是开发提交版本的时候,修改的部分引起了其他模块的异常,要么修改了需求,要么程序写的非常糟糕,可以要求打回去重写.  
   三  就是需求老是在变,而且各部门没有沟通好..
Fixed线  可以看到 开发人员一直在修改BUG ,这样对项目,对测试 ,对开发都是很闹心的事情,而且这样的版本发布,也是提心吊胆的...

3 特定类型bug分析总结


对一些测试得出的比较典型的和严重程度教高的BUG 要列举出来.这样可以让开发人员再下次版本设计的时候可以注意到.   
举例: 一些输入框不允许html代码的输入,而且这样的操作会影响到这个网站的安全,那么就要提出来,以至使开发人员在全网站把类似的代码屏蔽或者转换掉.因为测试人员测试的东西比较有限,可能发现不全,开发人员关注的层面是代码面,了解的程度比你深,而且他们还可以用批量的方法查找,替换.


4 残留缺陷与未解决问题(延迟的BUG)

编号：BUG号
缺陷概要：该缺陷描述的事实
原因分析：为什么会引起缺陷，缺陷的后果，目前不解决BUG的原因.以及这些问题如果发出去了会造成什么样的影响,影响是不是大?是否可控等...
预防和改进措施：弥补手段和长期策略

5 测试结论

报告到了这个部分就是一个总结了，对上述过程、缺陷分析之后该下个结论，此部分为项目经理、部门经理以及高层经理关注了.
1． 测试执行是否充分（可以增加对安全性、可靠性、可维护性和功能性描述）
2． 对测试风险的控制措施和成效
3． 测试目标是否完成
4． 测试是否通过
5． 是否可以进入下一阶段项目目标

6 建议
1．对系统存在问题的说明，描述测试所揭露的软件缺陷和不足，以及可能给软件实施和运行带来的影响
2．可能存在的潜在缺陷和后续工作
3．对缺陷修改和产品设计的建议
4．对过程改进方面的建议

7 阿七 (签名专用) 嘿嘿!~```



[ 本帖最后由 阿七 于 2008-11-21 10:48 编辑 ]
作者: archonwang    时间: 2008-11-17 16:55
标题: 不当之处，欢迎指正
此等问题。杀手问题。。。


============================================================================
[2008-11-21]：下午答贴。

我所理解的这个题目的标题，本来是分为几个层面的
现就这些做个简单的汇总说明。
============================================================================
测试分析本来就是一个很宽泛的话题，一般都会对测试的过程、方法、技术、流程、对象、结果等等内容分门别类，这里所列的仅仅是其中一点，仅供参考。

技术分析（客观性较强）
做技术分析是一个资深测试人员的必修课。我们从拿到一份测试的汇总数据和相关的bug及bug说明列表时，需要做这类技术分析，用以说明bug产生的技术原因。（我想，楼主可能想要知道的主要是这方面的内容）

针对某种特定测试类型的技术分析，一般包含如下内容：
每种类型的分析还分为覆盖分析、缺陷技术分析等内容。现以缺陷技术分析为例说明。
常见的一些针对bug的技术分析内容如下，在 2# 帖子里有较多表述了。

非技术分析（主观性较强，适合管理）
非技术分析一般由管理人员来实施。用于分析缺陷产生和生命周期中的客观性原因，如流程对修复周期的影响，测试方法对效率等内容的影响等等。
常见的一些非技术分析类型如下：


以上意见仅供参考使用。

[ 本帖最后由 archonwang 于 2008-11-21 16:13 编辑 ]
作者: dqar    时间: 2008-11-17 17:40
标题: 不再观望
我也试试……
作者: 513cecilia    时间: 2008-11-17 21:59
期待各位精彩的回答，我们现在使用的测试管理工具是TD，目前测试员反映自己编制测试用例，但仍由本人来测试，感觉没什么意义，故也没有将测试用例导入TD，实际测试的结果也没有在TD里添加，而只是将测试过程中发现的问题直接加入缺陷模块。
在缺陷添加完后也没有去进一步分析，只是在开发人员更改完成进入下一版本后，再重新测试，若再发现问题，则再次添加，而没有去细分是否是上次遗留问题，还是版本升级后出现的新问题，等等。
作者: chengxq    时间: 2008-11-18 10:25
只是想占个位
我们在项目管理中，很多时候按照组织级的要求收集了很多数据，然后按照组织级的数据进行生成图表，然后就结束了
所以我们的最主要的是，要让相应的人员清楚地知道，为什么收集数据，收集收据的目的是什么，收集数据有什么作用，如果对收集的数据进行分析这才是最主要的，如果我们担当者明确知道收集的数据的作用后，这样才能主动地收集数据，分析收据，对自己的过程和工作产品的把握才会清楚，否则流于表面。

数据进行分析，相应的SPC会有比较全面的介绍，这里不在介绍，可能LZ想知道这方面的内容，可是参照相应的书籍和资料，因为个人感觉问题的重点不在这里。

明确数据收集的目的
首先要让我们的担当者明确为什要收集数据，是对我们的哪个过程，那个产品进行评价和分析，举个例子进行说明，我想对我的测试发现的bug来对我们的测试进行结果进行分析，那我就知道了目的是为了我们工作产品的确认

如何收集数据，收集什么数据
我们在收集数据的时候，一定要保证我们收集的数据的前提是一致的，如果我们的前提一旦不一致，那我们对结果的分析有效性将会大大的降低，如有些测试的bug是第一次已经测试完了，现在是第2次测试，有的现在还是第一次，那么我们的测试收集上来的数据有效性如何，分析的可行度有多高，对于收集数据，如果像上例，对bug进行分析，那我们肯定要收集每个画面的bug，画面的KLOC（当然还有，主要看你收集数据的目的是干什么）

如何进行分析
每个公司现在都有相应的分析机制，指导如何进行分析，如上例，对工作产品的分析（这只是为了想说明问题，故简单说了一个例子，实际的肯定会复杂的多），现在多用X-R图进行分析，根据过去的历史数据进行分析，看它的bug/kloc是够过高，是否过低，如果高了，那要分析为什么高，都是什么类型的错误，根据2-8原则，这种类型的错误还有很多，那如何解决，如果过低，那我们看是否用例不足，用例的覆盖度是否满足，用例的有效性是否满足等。
我相信一个成熟的公司，对我们的每个过程都有相应的流程规定，对收集数据，分析都有相应的培训和介绍，项目组执行就可以了，但是就像上面所说。担当者自己要清楚，我现在在干什么，我什么要这么干
PS：我以前的一个公司，我在这个公司待了2年，这2年内换了5，6次review票的模版，n次的bug模版，而且模版都是不一致的，就看界面上都是面目全非，每更换一次都要对项目组进行相应的培训，项目组那个郁闷啊！我想这个是否对，呵呵，另外，换模版的根本目的是因为新的模版，能够生成更多的图表进行分析。当时的实际情况时，项目组数据一填就完事，根本就不会去分析，我想现在的根本目的是否可以通过更改模版能解决，这里我只是强调的是，不要追求新，我们应该追求的实用，我们将模版的作用告诉项目组，然后执行，看看执行的效果，然后告诉它模版的好处，让他去慢慢的接收，执行，如果可以给项目组一起分析，让他们更好的接收，而不是不段的更改模版

结语
我想为了让我们的数据收集更加的有效，最根本的是让我们的项目组，能够清楚地知道他们要收集什么数据，为什么要收集，如何进行分析，以及如何制定相应的措施，如果我们的项目组对这些不但很清楚，而且也是那么做的，我想，我们的过程是有效的，我们以后慢慢的进行改进!数据收集要做实每一步，而不是求新，今天搞一个图表，明天搞一个模版,这个是不对的。

PS：刚才我说到在进行bug分析的时候，要和历史数据进行比较，但是我遇到过一个项目经理，他说他这是维护的项目，没有历史数据，所以不能进行分析，我当时的回答是，数据是靠收集的，所以现在收集是没有问题的，但是对于没有历史数据进行分析，我当时的建议，把数据收集出来，然后生成图表（这还是举bug 的例子的X-R图），如bug/kloc，我们现在每个画面进行比较，不合历史数据进行比较，如果哪个画面过高或过低，我们按照异常点进行处理，如果大家都在一定区间内，那我们就认为虽然现在可能还有问题，但是我们现在的过程性能就是应该这个数据，我现在也只能接受。
所以问题的根本不是收集数据，而是为什么收集数据，如果明白这个，我想就差不多了

可能这个对LZ的问题没有多大的效果，我只是想说明点问题，呵呵，目的不是为了评奖，呵呵
关于更加有效，可能更多的是从EPG角度考虑的，的确需要改进，但不能过急！但是项目组或测试组对现在流程，对
现在数据收集的目的等很明确，那就已经是中国软件之福了！华丽的图表不如实用的表格，注重实用！

[ 本帖最后由 chengxq 于 2008-11-18 10:27 编辑 ]
作者: Mr_Jo.    时间: 2008-11-18 11:51
占位。。等待强淫。。
作者: tengmy    时间: 2008-11-18 12:38
标题: 回复 1# 的帖子
占位。晚上回家写。
作者: mgs2-007    时间: 2008-11-18 15:32
其实我感觉分析主要还是看目的，这次的主要目的是什么，人员因素、模块问题分布、问题种类、阶段BUG清除率等等等等，所以感觉目的引导方案。
作者: ruifengkeji    时间: 2008-11-18 15:42
作者: 如夏之晴    时间: 2008-11-19 13:48
占位，先想想
作者: ceceily    时间: 2008-11-19 14:25
软件测试完成，我们公司要对取得的数据分析。
我们对数据分析分为两种目的：
目的一是针对项目组的
目的二是针对测试人员的
目的一的分析：
    缺陷密度，与历史数据进行比较，预测目前项目的质量，以及测试是否充分   
缺陷收敛曲线，随着项目的进展，可以看到测试现状，了解测试是否充分；
    各模块缺陷分布，关注缺陷出现多的模块（按群集原理，发现缺陷多，说明残存缺陷也多）；
     缺陷原因分布，看有哪些因素导致了缺陷；
     缺陷严重程度分布，看是否严重的缺陷比例过大。
     测试通过率和修复率，分析软件的质量
      
目的二的分析：
       每个测试人员的有效缺陷率
       每个测试人员发现缺陷的效率=有效缺陷数/测试执行时间
       每个测试人员的严重缺陷率、重要缺陷率
       遗留缺陷率，与历史数据比较，分析软件质量，以及测试人员工作质量

[ 本帖最后由 ceceily 于 2008-11-19 14:30 编辑 ]
作者: 月野幻儿    时间: 2008-11-19 15:43
占位的好多...
作者: wei54688    时间: 2008-11-20 09:42
标题: 留坐标的人
不发表看法，俺只留下坐标，方便以后来看，下面的别骂！
作者: lsyjy4666    时间: 2008-11-20 14:43
占个位置等待达人出现
作者: 测试之王    时间: 2008-11-20 14:44
标题: 51testing转来的哦
软件测试分析报告应该包括哪些内容？

1.1编写目的
说明这份测试分析报告的具体编写目的，指出预期的阅读范围。

1.2背景
说明：

a.被测试软件系统的名称；

b.该软件的任务提出者、开发者、用户及安装此软件的计算中心，指出测试环境与实际运行环境 之间可能存在的差异以及这些差异对测试结果的影响。

1.3定义
列出本文件中用到的专问术语的定义和外文首字母组词的原词组。

1.4参考资料
列出要用到的参考资料，如：

a.本项目的经核准的计划任务书或合同、上级机关的批文；

b.属于本项目的其他已发表的文件；

c.本文件中各处引用的文件、资料，包括所要用到的软件开发标准。列出这些文件的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。

2测试概要
用表格的形式列出每一项测试的标识符及其测试内容，并指明实际进行的测试工作内容与测试计划中预先设计的内容之间的差别，说明作出这种改变的原因。

3测试结果及发现
3.1测试1（标识符）
把本项测试中实际得到的动态输出（包括内部生成数据输出）结果同对于动态输出的要求进行比较，陈述其中的各项发现。

3.2测试2（标识符）
用类似本报告3.1条的方式给出第 2项及其后各项测试内容的测试结果和发现。
作者: 测试之王    时间: 2008-11-20 14:45
4对软件功能的结论
4.1功能1（标识符）
4.1.1能力
简述该项功能，说明为满足此项功能而设计的软件能力以及经过一项或多项测试已证实的能力。

4.1.2限制
说明测试数据值的范围（包括动态数据和静态数据），列出就这项功能而言，测试期间在该软件中查出的缺陷、局限性。

4.2功能2（标识符）
用类似本报告4.l的方式给出第2项及其后各项功能的测试结论。

．．．．．．

5分析摘要
5.1能力
陈述经测试证实了的本软件的能力。如果所进行的测试是为了验证一项或几项特定性能要求的实现，应提供这方面的测试结果与要求之间的比较，并确定测试环境与实际运行环境之间可能存在的差异 对能力的测试所带来的影响。

5.2缺陷和限制
陈述经测试证实的软件缺陷和限制，说明每项缺陷和限制对软件性能的影响，并说明全部测得的性能缺陷的累积影响和总影响。

5.3建议
对每项缺陷提出改进建议，如：

a．  各项修改可采用的修改方法；

b．  各项修改的紧迫程度；

c．  各项修改预计的工作量；

d．  各项修改的负责人。

5.4评价
说明该项软件的开发是否已达到预定目标，能否交付使用。

6测试资源消耗
总结测试工作的资源消耗数据，如工作人员的水平级别数量、机时消耗等。
作者: 测试之王    时间: 2008-11-20 14:45
不晓得中不中哦~
作者: 疯都疯了    时间: 2008-11-20 15:30
全部新业务：
。画出业务流程
。提取基本正向流程、分支流程及反向流程
。提取流程穿过的业务画面，填写全部的界面参数及系统内置参数（其他画面输入）
。填写每个画面的必输项
。提取业务规则
。从常用规则库提取适用规则
。使用业务原语描述测试模板
。计算参数表适配模板得出用例优化压缩空间
。根据风险原则选取

老业务回归：
。查出配置管理系统本次变更的程序模块、库表、值域选择等的变化
。计算变更影响分析
。提取需要复测的功能列表
。提取影响这些功能列表的业务流程
。提取测试用例模板
。修正模板（如果界面修改）
。修正参数（如果值域修改）
。修正规则参数（与业务规则修改相关）
。修正模板中比对部分（如果修改输出表达）
。修正模板中业务数据查询核对（如果修改数据库）
。自动提交复测


网络上看到的，转.
6楼的写的自身感受不错．
作者: wanglihui2009    时间: 2008-11-21 09:33
开会
作者: 默默巫1    时间: 2008-11-21 09:42
占座先
作者: 阿七    时间: 2008-11-21 11:13
默默巫1  无限接近默默巫  
作者: archonwang    时间: 2008-11-21 11:26
标题: 回复 2# 的帖子
呵呵。阿七的报告很不错啊。我都有点不好意思拿出来了。
作者: hmilyjch    时间: 2008-11-21 13:33
二楼写的真好~~
正要写报告哩~
作者: 张明    时间: 2008-11-21 14:33
在测试完成之后，对数据的分析，一般都是从产品的质量和产生产品的过程中间来进行考虑，数据收集分析的前提都应该
明确我们的目的到底是什么，如果目的都不明确，那我们在分析的时候，就很难我们可以发现我们现在存在的问题，为以后
我们的过程改进进行考虑
从质量上考虑（一般情况下从这几点考虑）
1.对发现的bug进行有效的原因分类，数据的收集和统计，分类不一定很细，但是要有区分，我见到过一个项目组，由于对bug票
的分类过细（公司模版的问题），有些问题点，不知道选什么，以至于后期数据统计没有意义，不能发现问题的根本，分类的
原则是在每个担当都能清楚之间的区分的前提下，满足最细化，对其中的数据进行统计，看占百分比比较大的前几个，看都是
什么类型的问题，从这上面找到改进的切入点
2.在测试阶段，对测试结果进行混入工程的分类，即这个错误是在什么时候引入的，是需求，是设计，还是编码，对这些数据
统计，我们可以得到我们现阶段评审或测试的有效性，如果发现我们在结合测试阶段发现很多单体测试的问题，那我们要在单体
测试上进行改进，如果我们测试的时候，发现很多应该在设计review时发现的问题，那我们要对我们review的过程进行改进
3.对发现的bug的严重程度进行分析，看严重程度的分布是否正常，如果都是发现一些不重要的错误，对逻辑错误发现的比较少
那在这方面也需要进行改进
从过程上考虑
1.测试时间与发现的bug数
2.担当人员发现的bug/kloc
待续

[ 本帖最后由 张明 于 2008-11-21 17:29 编辑 ]
作者: bsit09    时间: 2008-11-21 16:35
占个位置!
作者: weifei1031    时间: 2008-11-21 17:11
#2归纳的很到位，深受感染。我个人觉得，
1、报告总结是写给谁看的，对象是谁，这个得搞清楚吧？！
2、报告是什么性质的，功能、性能、兼容性？
3、报告的用途，产品发布评审用？项目总结大会用？
4、报告的重点，个人觉得一定要给出自己的结论、建议，要突出测试的价值在里面
5、遵循公司相关文档的规范
6、篇幅不要太长，最好图文并茂！
作者: mmvviitt    时间: 2008-11-22 01:37
问：
在软件测试完成后，采用工具（TD、QC）或人工收集了一些数据，形成了各种图表。
怎样去发挥这些数据的作用，进行有效深层次的数据分析，从而改进测试流程，完善测试过程？
答:
本问的焦点是 对数据进行有效的深层次的分析，想要完成对测试流程改进，完成测试过程。

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

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

接着看第二点。不在局限在某一个版本，需要对连续的几个版本进行统计分析。这个时候分析的重点是单个特性成熟分析、结论，不在是局限在产品版本中。某个特性的持续分析，整体特性的分析，就能知道整个测试工作的重点，调整测试流程的重点。 这个时候，多个产品和版本测试形成的就是一个测试流程的雏形。
后继就是多次对测试流程的精简，优化，改进，使之使用于其他的大多数产品。
作者: hushiping2222    时间: 2008-11-22 10:19
作为新手，还只能认真的倾听大家对这么高深的问题进行讨论，呵呵
作者: xiangshui    时间: 2008-11-24 10:55
标题: 回复 2# 的帖子
看样子 挺好 ::xixill:::
作者: ljdlx    时间: 2008-11-24 15:49
感觉楼主想要问的问题,是对完成测试后,一些数据的挖掘,类似于一些数据仓库的功能,一种分析当前,预测未来的挖掘.
比如说明当前测试的结果,然后挖掘分析,下轮测试,问题会集中在哪个模块,集中在什么类型的问题,然后在下轮测试中应该重点测试那些模块,多注意那些类型的问题等等.
针对我的理解,我认为,把数据根据自己所需要的画图表\分析就可以了.其他的如每个测试人员测试的情况 ,这个是对测试人员的工作的评估,对下轮测试没有什么指向性目的.
还有我们做软件的应该很清楚,使用数据库对数据挖掘,分类是非常重要的,所以其他的什么测试报告如何编写,,告诉项目经理测试结果,项目经理应该知道那些测试结果,这些是必须的,但是预测\风险才是测试完成后数据有效的,深层次的分析.
至于怎么进行,可以借助一些数据集市的分析模式,出一些多纬度的报表或图表,然后根据自己的经验进行分析.

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

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

[ 本帖最后由 ljdlx 于 2008-11-24 15:52 编辑 ]
作者: ljmy9488    时间: 2008-11-24 16:49
占个座,好好学习
作者: weever    时间: 2008-11-25 11:21
标题: 回复 1# 的帖子
问题中提到的是深层次的分析来改善测试流程与方法,就这点说一些自己的看法.

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

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

一般对于测试结果的分析只能分析出当前存在的问题，具体要进行的改进需要整个工作组（上至产品经理，下至开发人员与测试人员）进行讨论分析。
但一般大公司是没什么办法的，因为束缚的东西太多，你反映了也到不了上层，而其他的部门又不定会做这样的分析，小公司可以考虑搞搞。
作者: james.zhong    时间: 2008-11-26 17:05
好少人吖！！！！
作者: duola1119    时间: 2008-12-10 19:30
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 编辑 ]
作者: www.itest100.cn    时间: 2008-12-10 22:09
数据分析无非是开发或者测试团队的效率
或者评估产品的质量
作者: www.itest100.cn    时间: 2008-12-10 22:09
数据分析无非是开发或者测试团队的效率/有效性
或者评估产品的质量



欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/) Powered by Discuz! X3.2