软件测试完成以后，怎样进行有效深层次的数据分析？（08-11-17）（获奖名单已公布）
在软件测试完成后，采用工具（TD、QC）或人工收集了一些数据，形成了各种图表。怎样去发挥这些数据的作用，进行有效深层次的数据分析，从而改进测试流程，完善测试过程？
感谢会员JerryYe提供此精彩问题！如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！
获奖名单奖项获奖名单奖励答案链接
一等奖阿7当当购物卡50元2#
二等奖archonwang300论坛积分3#
二等奖chengxq300论坛积分 6#
占位太久...
楼主说的数据分析! 其实可以理解为测试完成以后所要做的测试报告和总结,因为总结里会包括你之前所做的,遇到的问题,已经你做完后想提的建议等.把测试的过程和结果写成文档，并对发现的问题和缺陷进行分析，为纠正软件的存在的质量问题提供依据，同时为软件验收和交付打下基础.这是测试报告的定义.通常，用户对测试结论部分感兴趣，开发人员希望从缺陷结果以及分析得到产品开发质量的信息，项目管理者对测试执行中成本、资源和时间予与重视，而高层经理希望能够阅读到简单的图表并且能够与其他项目进行同向比较。此部分可以具体描述为什么类型的人可参考本报告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 走势图,更直观的分析测试流程是否正常,见下面的粗略分析 (呵呵)
open线可以看出这个项目是提交了3次版本的11号17号 21号 3次版本提交, 这与实际的情况一致
Fixed线也是可以看出3个波峰.其他的线也是中规中矩,
这几个指标都符合1版本80% 2版本90% 3版本98%的通过率.这是很正常,流程走的很顺的一次测试任务.
那再看下面的这张图
分析：
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 编辑 ]
不当之处，欢迎指正
此等问题。杀手问题。。。:L============================================================================
：下午答贴。
我所理解的这个题目的标题，本来是分为几个层面的
[*]测试结论技术分析：这个一般都包含了对应的专业技术知识，例如：基于测试类型的专业知识的开发语言和平台、数据库、网络、协议等等[*]测试结论的非技术分析：一般都是流程、管理的方式方法等内容现就这些做个简单的汇总说明。
============================================================================
测试分析本来就是一个很宽泛的话题，一般都会对测试的过程、方法、技术、流程、对象、结果等等内容分门别类，这里所列的仅仅是其中一点，仅供参考。
技术分析（客观性较强）
做技术分析是一个资深测试人员的必修课。我们从拿到一份测试的汇总数据和相关的bug及bug说明列表时，需要做这类技术分析，用以说明bug产生的技术原因。（我想，楼主可能想要知道的主要是这方面的内容）
针对某种特定测试类型的技术分析，一般包含如下内容：
[*]功能测试分析[*]性能测试分析[*]安全性测试分析[*]。。。 。。。每种类型的分析还分为覆盖分析、缺陷技术分析等内容。现以缺陷技术分析为例说明。
常见的一些针对bug的技术分析内容如下，在 2# 帖子里有较多表述了。
[*]缺陷数量统计[*]缺陷分级统计[*]缺陷分布统计[*]缺陷优先级统计[*]缺陷发现与修复时间统计报表[*]缺陷收敛分析[*]典型缺陷产生原因分析（主要是基于编码技术、或是相关的平台应用技术）
非技术分析（主观性较强，适合管理）
非技术分析一般由管理人员来实施。用于分析缺陷产生和生命周期中的客观性原因，如流程对修复周期的影响，测试方法对效率等内容的影响等等。
常见的一些非技术分析类型如下：
[*]流程分析，用于优化开发过程，精简和细化流程分工，提升整体效率。这里的流程分析还可以继续划分为开发流程分析、测试流程分析及管理流程分析，当然，如果有必要还可以进一步深入，比如，就配置管理的目前流程进行优化，以使其更适应当前的具体情况。[*]测试方法分析，这个我想对广大的测试人员来说，有效的前段分析等手段可以提炼一定的方法出来，从粗放型到细致，按不同的需要合理划分。这里主要片中的管理层面的内容。[*]标准优化。这是非技术分析中的另一块内容。将目前的适应性标准列入其中，根本上还是为了解决了效率和效能的问题。
以上意见仅供参考使用。
[ 本帖最后由 archonwang 于 2008-11-21 16:13 编辑 ]
不再观望
我也试试…… 期待各位精彩的回答，我们现在使用的测试管理工具是TD，目前测试员反映自己编制测试用例，但仍由本人来测试，感觉没什么意义，故也没有将测试用例导入TD，实际测试的结果也没有在TD里添加，而只是将测试过程中发现的问题直接加入缺陷模块。在缺陷添加完后也没有去进一步分析，只是在开发人员更改完成进入下一版本后，再重新测试，若再发现问题，则再次添加，而没有去细分是否是上次遗留问题，还是版本升级后出现的新问题，等等。 只是想占个位
我们在项目管理中，很多时候按照组织级的要求收集了很多数据，然后按照组织级的数据进行生成图表，然后就结束了
所以我们的最主要的是，要让相应的人员清楚地知道，为什么收集数据，收集收据的目的是什么，收集数据有什么作用，如果对收集的数据进行分析这才是最主要的，如果我们担当者明确知道收集的数据的作用后，这样才能主动地收集数据，分析收据，对自己的过程和工作产品的把握才会清楚，否则流于表面。
数据进行分析，相应的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 编辑 ] 占位。。等待强淫。。
回复 1# 的帖子
占位。晚上回家写。 其实我感觉分析主要还是看目的，这次的主要目的是什么，人员因素、模块问题分布、问题种类、阶段BUG清除率等等等等，所以感觉目的引导方案。 :Q :L 占位，先想想 软件测试完成，我们公司要对取得的数据分析。我们对数据分析分为两种目的：
目的一是针对项目组的
目的二是针对测试人员的
目的一的分析：
缺陷密度，与历史数据进行比较，预测目前项目的质量，以及测试是否充分
缺陷收敛曲线，随着项目的进展，可以看到测试现状，了解测试是否充分；
各模块缺陷分布，关注缺陷出现多的模块（按群集原理，发现缺陷多，说明残存缺陷也多）；
缺陷原因分布，看有哪些因素导致了缺陷；
缺陷严重程度分布，看是否严重的缺陷比例过大。
测试通过率和修复率，分析软件的质量
目的二的分析：
每个测试人员的有效缺陷率
每个测试人员发现缺陷的效率=有效缺陷数/测试执行时间
每个测试人员的严重缺陷率、重要缺陷率
遗留缺陷率，与历史数据比较，分析软件质量，以及测试人员工作质量
[ 本帖最后由 ceceily 于 2008-11-19 14:30 编辑 ] 占位的好多...
留坐标的人
不发表看法，俺只留下坐标，方便以后来看，下面的别骂！ 占个位置等待达人出现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项及其后各项测试内容的测试结果和发现。 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测试资源消耗
总结测试工作的资源消耗数据，如工作人员的水平级别数量、机时消耗等。 :D 不晓得中不中哦~ 全部新业务：
。画出业务流程
。提取基本正向流程、分支流程及反向流程
。提取流程穿过的业务画面，填写全部的界面参数及系统内置参数（其他画面输入）
。填写每个画面的必输项
。提取业务规则
。从常用规则库提取适用规则
。使用业务原语描述测试模板
。计算参数表适配模板得出用例优化压缩空间
。根据风险原则选取
老业务回归：
。查出配置管理系统本次变更的程序模块、库表、值域选择等的变化
。计算变更影响分析
。提取需要复测的功能列表
。提取影响这些功能列表的业务流程
。提取测试用例模板
。修正模板（如果界面修改）
。修正参数（如果值域修改）
。修正规则参数（与业务规则修改相关）
。修正模板中比对部分（如果修改输出表达）
。修正模板中业务数据查询核对（如果修改数据库）
。自动提交复测
网络上看到的，转.
6楼的写的自身感受不错． 开会:lol
页:
[1]
2
