回复 2# 的帖子
呵呵。阿七的报告很不错啊。我都有点不好意思拿出来了。 二楼写的真好~~正要写报告哩~ 在测试完成之后，对数据的分析，一般都是从产品的质量和产生产品的过程中间来进行考虑，数据收集分析的前提都应该
明确我们的目的到底是什么，如果目的都不明确，那我们在分析的时候，就很难我们可以发现我们现在存在的问题，为以后
我们的过程改进进行考虑
从质量上考虑（一般情况下从这几点考虑）
1.对发现的bug进行有效的原因分类，数据的收集和统计，分类不一定很细，但是要有区分，我见到过一个项目组，由于对bug票
的分类过细（公司模版的问题），有些问题点，不知道选什么，以至于后期数据统计没有意义，不能发现问题的根本，分类的
原则是在每个担当都能清楚之间的区分的前提下，满足最细化，对其中的数据进行统计，看占百分比比较大的前几个，看都是
什么类型的问题，从这上面找到改进的切入点
2.在测试阶段，对测试结果进行混入工程的分类，即这个错误是在什么时候引入的，是需求，是设计，还是编码，对这些数据
统计，我们可以得到我们现阶段评审或测试的有效性，如果发现我们在结合测试阶段发现很多单体测试的问题，那我们要在单体
测试上进行改进，如果我们测试的时候，发现很多应该在设计review时发现的问题，那我们要对我们review的过程进行改进
3.对发现的bug的严重程度进行分析，看严重程度的分布是否正常，如果都是发现一些不重要的错误，对逻辑错误发现的比较少
那在这方面也需要进行改进
从过程上考虑
1.测试时间与发现的bug数
2.担当人员发现的bug/kloc
待续
[ 本帖最后由 张明 于 2008-11-21 17:29 编辑 ] 占个位置!:) #2归纳的很到位，深受感染。我个人觉得，:)
1、报告总结是写给谁看的，对象是谁，这个得搞清楚吧？！
2、报告是什么性质的，功能、性能、兼容性？
3、报告的用途，产品发布评审用？项目总结大会用？
4、报告的重点，个人觉得一定要给出自己的结论、建议，要突出测试的价值在里面
5、遵循公司相关文档的规范
6、篇幅不要太长，最好图文并茂！:lol 问：
在软件测试完成后，采用工具（TD、QC）或人工收集了一些数据，形成了各种图表。
怎样去发挥这些数据的作用，进行有效深层次的数据分析，从而改进测试流程，完善测试过程？
答:
本问的焦点是 对数据进行有效的深层次的分析，想要完成对测试流程改进，完成测试过程。
个人理解：
两个层次的事情。一是对整理数据，对测试观察产品质量的提升；二是对测试产品的几个测试周期的观察，提高对产品的测试的流程进行优化。这个流程就是分析产品BUG的周期 ，掌握产品bug的主要特性点。后面我有详细说明。
先看看对产品的数据分析，说道这些工具，呵呵个人以为是始终是一个工具，辅助手段，结果是提高了分析的效率，对第二点没有任何影响。
说说分析这些数据的过程，假定你已经知道这些数据是要来干什么的，对应到测试过程，就是分析数据，缺陷分析的过程。 这个过程是得到测试结论的主要依据。
缺陷分析，对应到产品，【假定你在产品测试钱已经对产品的测试特性做了分析。】【测试特性，是产品的特性，产品的模块的功能描述】找到那些特性有缺陷，具体的缺陷分布如何？产品的模块的功能是否稳定，并针对具体的bug，解决bug的程度，bug遗留的情况，得出测试版本的质量评估。
客观，实际，是分析人员必须具备的条件；对特性的掌握熟练是必须的，对工具的使用要求程度一般，不需要依赖具体的测试分析模板；
接着看第二点。不在局限在某一个版本，需要对连续的几个版本进行统计分析。这个时候分析的重点是单个特性成熟分析、结论，不在是局限在产品版本中。某个特性的持续分析，整体特性的分析，就能知道整个测试工作的重点，调整测试流程的重点。 这个时候，多个产品和版本测试形成的就是一个测试流程的雏形。
后继就是多次对测试流程的精简，优化，改进，使之使用于其他的大多数产品。 作为新手，还只能认真的倾听大家对这么高深的问题进行讨论，呵呵
回复 2# 的帖子
看样子 挺好 ::xixill::: 感觉楼主想要问的问题,是对完成测试后,一些数据的挖掘,类似于一些数据仓库的功能,一种分析当前,预测未来的挖掘.比如说明当前测试的结果,然后挖掘分析,下轮测试,问题会集中在哪个模块,集中在什么类型的问题,然后在下轮测试中应该重点测试那些模块,多注意那些类型的问题等等.
针对我的理解,我认为,把数据根据自己所需要的画图表\分析就可以了.其他的如每个测试人员测试的情况 ,这个是对测试人员的工作的评估,对下轮测试没有什么指向性目的.
还有我们做软件的应该很清楚,使用数据库对数据挖掘,分类是非常重要的,所以其他的什么测试报告如何编写,,告诉项目经理测试结果,项目经理应该知道那些测试结果,这些是必须的,但是预测\风险才是测试完成后数据有效的,深层次的分析.
至于怎么进行,可以借助一些数据集市的分析模式,出一些多纬度的报表或图表,然后根据自己的经验进行分析.
自己的一些浅知拙见,不知道对不对,呵呵
忘了说,这种数据挖掘是一种持续性的过程!~如果只是做完项目就走的,不实用!不过在对同一个系统,或同一类型的开发软件还可以借鉴的.
[ 本帖最后由 ljdlx 于 2008-11-24 15:52 编辑 ] 占个座,好好学习
回复 1# 的帖子
问题中提到的是深层次的分析来改善测试流程与方法,就这点说一些自己的看法.1. 测试案例的完成情况:
一般测试案例都是按模块来分的, 那就可以从历史纪录中看出特定模块基本稳定的时间, 需要周期, 以及其间质量反复的程度. 如果一个高优先级的模块完成的时间较晚,耗时较长,那就可以分析是不是开始测试的时间是否可以再提前, 相应的测试案例是否可以扩充,是否遗漏了什么导致了整个测试流程耗时过长, 如果是开发小组的问题,那就要提出以求改进.
2. 测试bug的情况：
一般bug数量总是有一个峰值，需要看一下这个峰值是不是处于项目的后期，如果是的话，那就整个team来分析原因，应当尽量将这个峰值往前移，这里面涉及到测试前期的准备，开始的时间，力度以及与开发小组协调等等各种因素。具体情况具体分析。
一般对于测试结果的分析只能分析出当前存在的问题，具体要进行的改进需要整个工作组（上至产品经理，下至开发人员与测试人员）进行讨论分析。
但一般大公司是没什么办法的，因为束缚的东西太多，你反映了也到不了上层，而其他的部门又不定会做这样的分析，小公司可以考虑搞搞。 :lol 好少人吖！！！！:L 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 编辑 ] 数据分析无非是开发或者测试团队的效率
或者评估产品的质量 数据分析无非是开发或者测试团队的效率/有效性
或者评估产品的质量
页:
1
[2]
