-
基于缺陷分布的质量目标分解和质量预测体系
2007-12-20 21:15:43
-
统计分析常用图标介绍
2006-12-07 21:23:23
作者：罗耀秋
• 1--点图
Minitab->Graph->PLOT 选择两列即可
Excel->Insert->Chart->XY (Scatter)
主要用于判断两个因素之间的相关性。一般有四种情况：
正相关 负相关
曲线相关 不相关
• 2—折线图[时间序列图]
Excel->Insert->Chart->Line
主要用于趋势分析。它是一种时间序列关系。处理数据时候，有时为了使数据更具有表现力和区分度，可能要根据数据的特征分成不同的组进行比较。如新项目和新项目比，大项目和大项目比，软件项目和集成项目分开比。
• 3—因果图[鱼骨图]
人员
方法
测量
机器
环境
材料
任务拖延
获取的市场信息不多
估算方法不对
高层指示错误
项目经理定位不合理
项目经理能力不够
项目经理对计划重视不够
计划管理工具落后
缺少历史数据
版本功能需求不清
制定计划的资源不足
开发经理定位不合理
开发经理能力不够
开发经理对计划重视不够
任务管理工具落后
任务目标描述不清
任务之间配合出问题
员工士气不高
员工业务能力不够
考核制度奖罚不明
研发工具落后
研发资源不足
可参考的技术资料太少
临时任务过多
项目组业务能力不够
跟踪监督不力
员工没有及时反映问题
员工没有及时准确报告任务完成情况
可以用MiniTab或者Visio画，主要用于和头脑风暴结合启发思维。
注：
1、需注明是针对什么具体问题进行的鱼骨图分析，应与过程流程图中的输入因子对应。目的是列出所有可能导致问题产生的潜在原因，要避免遗漏。
2、可以与头脑风暴结合起来，先头脑风暴找因果，然后map到鱼骨图来，或者用鱼骨图启发头脑风暴的参与者思考问题
目前也有能够绘画精美鱼骨图的工具，大家也可以直接用office图表方式直接汇制。
[Minitab->Stat->Quality Tools->Cause-And-Effect-Diagram]
• 4—柱状图
Minitab->Graph->Histogram
主要用于观察事件出现的频度。如本例中165和175CM的人出现的频度最高。
• 4—柱状图-续[描述性统计图]
Minitab->Stat->Basic Statistics->Display Descrīptive Statistics
这个比单纯的柱状图包含更多的信息。如正态性检验、均值、方差、标准差、中位数、四分位数等。
• 5—条形图
Excel->Insert->Chart->Column
主要用于观察多个事件出现的频度。
• 6—柏拉图
Minitab->Stat->Quality Tools->Pareto Chart
基于80-20原则找出关键的多数。
• 7—饼图
Excel->Insert->Chart->Pie
主要看数据的分布情况。
• 8—控制图
Minitab->Stat->Control Charts->Individuals
测试缺陷分析务实篇[2]
2006-12-01 21:10:34
作者：罗耀秋 MSN: luoyear@netease.com E-Mail：luoyear@163.com
- 利用缺陷的阶段分布模型进行质量预测
假设我们为bug管理系统建立了“一、利用缺陷引入-发现矩阵分析”中描述的缺陷引入-缺陷发现阶段信息，那么我们可以对相似的项目的缺陷阶段分布进行度量，形成该类型项目的缺陷分布的过程模型。它给予我们的信息是：只要是这种类型的项目，按照相似的过程方法进行研发，那么其质量表现也是相似的。
我们之所以作这样的假设，是有一个前提，就是我们研发过程是高度一致的，并且过程的表现也是稳定的。这样，我们得出的过程能力模型才具有可信度。
下面是一个如何运用测试分布模型进行质量预测的例子：
如果需求阶段发现了10个缺陷，就可以预计到设计阶段我大概要清除70个缺陷，依次可以估计到后阶段各个环节的缺陷数，作为我们该阶段工作的交付准则。并且，可以预测到产品发布后的使用表现会出现大约2个故障泄露到用户手中。
这种分析预测模型的建立，要求组织的测试/评审过程比较稳定。即组织整体达到CMMI三级成熟度，同时在VAL和VER（验证和确认）过程域的达到CMMI四级的成熟度级别，即量化管理级别。
- 利用泄漏的下游缺陷回溯过程有效性
经验告诉我们，越到后端发现的缺陷，用于问题复现、问题定位和bug修复的时间就越多。那么我们是不是可以在项目研发的更前端发现这些缺陷呢？有什么方式让我们识别项目研发前端哪些活动没有充分投入、或者没有运用合适的工程/技术方法导致这些问题被泄露到下游呢？
其实，我们有很简便的方法可以达到这个目的。从团队的典型项目中运用一定的抽样原则抽样出某个阶段的若干个缺陷，从技术、流程、工程方法、费效比方面去分析其更适合、更经济的清除方法。然后把这些方法固化到我们日常的项目实施过程中，逐步就可以降低上游对后端的缺陷泄露。
下面以对一个项目的系统测试阶段发现的故障为例进行过程有效性回溯分析：
从上表可以看出，真正需要遗留到系统测试阶段才能发现的故障只有7%，大部分故障应该在集成测试和设计评审过程中就应该发现的。
导致在集成测试过程中未能充分发现这些缺陷的原因主要有：
1、测试环境不具备，导致部分测试项必须到系统测试阶段才具备测试条件；
2、测试设计中某些测试项的缺失，需要加强测试设计的评审工作；
3、回归测试过程中，开发部只是对测试故障进行验证，而对bug fix波及的范围缺乏分析和验证；
这样，针对这些分析结论，我们就可以制定针对性的整改措施。如：
- 加强开发部的故障波及分析及波及分析验证工作；
- 项目计划中加强对测试需求的关注，提前采购和协调必要的测试环境；
- 每次回归对泄露的缺陷开发部都作相应的复盘，并根据复盘结果，完善单元测试和集成测试的测试设计；
- 利用缺陷分类来进行缺陷的根源分析
对于测试出来的BUG进行缺陷分类，按照BUG的类型分布，找出那些关键的缺陷类型，进一步分析其产生的根源，从而针对性的制定改进措施。
下面以一个项目的系统测试故障为例进行分析：
从系统测试故障来看，有较多故障是由接口原因造成的，细分有以下几种原因：
1、跨项目间的接口，接口设计文档的更改没有建立互相通知的机制，导致接口问题到系统测试时候才暴露出来；
2、部门内部跨子系统的接口，由于本项目设计文档按功能规划编写的，而不是按照产品组件，一般由主要承接功能工作的组编写该文档，接口内容可能不为其他开发组理解并熟悉，导致因接口问题而出错；
3、系统设计基线化后，更改系统接口，没有走严格的变更流程，进行波及分析，导致该接口变更只在某个子系统中被修改，而使错误遗漏下来；
那么我们可以针对性的制定改进建议：
1、对接口文档的评审一定要识别受影响的相关干系人，使他们了解并参与接口设计的把关；
2、对基线化的接口设计文档的变更一定要提交变更单给ＣＣＢ决策，并做好充分的波及影响分析，以便同步修改所有关联的下游代码；
3、概要设计文档按子系统规划，详细设计文档按模块规划，通过相关组参加评审协调接口设计；
以上例子的缺陷分类只是为了描述方便，本身描述并不尽合理。实际定义缺陷分类可能有很多个维度，如发现活动、引入活动、缺陷来源、缺陷类型、严重程度等。只要满足自己的缺陷管理、缺陷分析需求即可。
- 缺陷收敛趋势分析
项目管理中一项非常重要但也十分困难的工作是衡量项目的进度、质量、成本等，统称为项目的状态，以确定项目是否能按期保质完成。这方面，测试提供了两个非常重要的参数，一个是缺陷数量的趋势，另一个是缺陷修复的趋势。（注：此节所说的测试均指代系统测试）
缺陷趋势就是将每月新生成的缺陷数、每月被解决的缺陷数和每月遗留的缺陷数标成一个趋势图表。一般在项目的开始阶段发现缺陷数曲线会呈上升趋势，到项目中后期被修复缺陷数曲线会趋于上升；而发现缺陷数曲线应总体趋于下降；同时处于OPEN状态的缺陷也应该总体呈下降趋势，到项目最后，三条曲线都趋向于零。如：
项目经理会持续观察这张图表，确保项目健康发展，同时通过分析预测项目测试缺陷趋于零的时间。在一定的历史经验的基础上分析使用这一图表会得到很多有价值的信息，比如说，可分析开发和测试在人力资源的配比上是否恰当，可以分析出某个严重的缺陷所造成的项目质量的波动。对于异常的波动，如本来应该越测试越收敛的，却到了某个点，发现的故障数反而呈上升趋势，那么，这些点往往有一些特殊事件的发生。如：
- 在该时间段送测的回归版本增加了新的功能，导致缺陷引入；
- 该回归版本开发部没有进行集成测试就直接送测？等等。
当然，这个统计周期也可以根据我们的项目实施情况进行。如按照回归版本的版本号进行统计、按周进行统计等。也有公司把缺陷收敛情况当作判断版本是否可以最终外发的一个标志。
小结：
通过对测试缺陷分析，能够给予我们很多改进研发和测试工作的信息。
当然，这种分析来源于一个前提，我们需要规划一个好的Bug管理系统，满足我们这些分析的信息需要。另外，我们的研发过程是稳定的，其质量表现大体是一致的，这样数据反映的趋势才具备可信度。
测试缺陷分析务实篇[1]
2006-12-01 21:09:28
作者：罗耀秋 MSN: luoyear@netease.com E-Mail：luoyear@163.com
摘要：
测试活动作为IT项目和产品开发一个重要的环节，通过发现产品或组件的缺陷，并反馈给开发组修复验证这些缺陷，从而在一定程度上保证了外发产品的质量。对这些测试活动发现的缺陷进行深入的分析，可以有助于我们进行质量预测、进行过程改进、量化的衡量产品质量。
关键词：
测试分析、过程改进、质量预测、过程能力、缺陷
正文：
项目研发过程中，我们通过单元测试、集成测试、系统测试发现了大量的缺陷。我们把这些Bug输入到Excel或者其他测试管理系统中，跟踪其解决。一旦Bug fix完成后，大多数情况下我们就把这份bug list束之高阁，偶尔能想到的用途就是拿出来衡量测试组的绩效，或者用来评估开发组的质量表现。
一般来说质量分析有以下集中情况
- 利用缺陷引入-发现矩阵分析
缺陷有发现阶段和引入阶段两个重要指标，发现阶段和引入阶段可以是软件生命周期的各个阶段，根据这两个阶段可以绘制出一个矩阵，从而分析出软件开发各个环节的开展质量，找到最需要改进的环节。
开始例子分析之前先解释一下缺陷引入-发现矩阵的一些概念。
矩阵的每行表示该阶段或活动发现的各阶段产生的缺陷数；矩阵的每列表示该阶段或活动引入的缺陷泄露到后续各环节的缺陷数。
缺陷移除率定义为：缺陷移除率=(本阶段发现的缺陷数/本阶段引入的缺陷数)*100%。如需求阶段一共引入了15个缺陷，需求评审时候只发现了2个，设计过程中发现了10个，编码和单元测试阶段发现了两个，还有一个直到系统测试阶段才被发现。这样，需求阶段的缺陷移除率=2/15*100%=13%。它反映的是该活动阶段的缺陷清除能力。
反过来还有一个概念，缺陷泄露率，就是有多少本阶段引入的缺陷没有在本阶段发现而是被泄露到后阶段环节才被发现。其计算公式为：缺陷泄漏率=（下游发现的本阶段的缺陷数/本阶段注入的缺陷总数）*100%。显然，它等于[1-缺陷移除率]。它反映的是本阶段质量控制措施落实的成效。
下面是一个分析例子：
从上表可以看到，编码过程的缺陷大部分依赖系统测试发现。单元测试和集成测试活动开展不够深入。我们可以进一步分析这些系统测试出来的测试缺陷，是不是可以被更前端的评审/测试/设计讨论活动所替代。详细见“四、利用泄漏的下游缺陷回溯过程有效性”
另外，我们看到，需求阶段引入的缺陷绝大部分是在设计阶段发现的。这可能是我们大部分项目的一个现实，需求不稳定、需求不明确，很多东西需要在设计过程中才能明确下来。也许从这个分析结果中给我们一个启示，我们在设计评审时候，也需要重新审视我们的需求规格说明书，必要时候利用需求追踪矩阵这样的规矩方法来辅助我们发现上游需求的缺陷。把这样的机制固化起来，作为我们标准研发过程的一个要素或者过程指导书。
当然，实际规划“缺陷引入-发现矩阵”时，可以依据自己的管理要求，对缺陷的发现活动和引入阶段进行细分或初分，并且在Bug系统中提交时，需要准确的填写这些属性字段。
- 利用缺陷的分布进行分析
可以选某个阶段的测试缺陷进行分析，按照这些缺陷对应的产品组成部分来汇总这些数据。利用这样的分布，可以找出我们产品/项目的高危模块来。这些模块导致了我们产品的主要缺陷。主要用到的分析手段是数据透视表和柏拉图。让我们看看下面的例子：
这是一个简单的OA系统，它只有5个子系统。我们把这些子系统各有多少缺陷列出来，找到了改善质量的关键模块是后台交易模块。
像上图，这是一个较为复杂的MIS系统，有近20个功能块。这个时候，可以利用柏拉图识别出占80%问题的那少数模块，针对其采取强于其它产品组成部分的质量控制措施。
需要指出的是：采用缺陷分布只是分析的第一步。它只不过提供了你分析影响产品质量的那些重点模块，其信息不足以给出更深层次的原因。需要针对这些高危模块进行进一步的分析，识别缺陷的产生根源。
当然，也有人认为绝对数去衡量缺陷的分布并不合适，所以有些人也会把缺陷按照严重程度对应一定的权重系数折算成分析意义上的标准故障。如上表，折算系数为，严重*10，关键*5，一般*3，次要*1，优化*0。
这种分析需要我们的bug系统建立产品组件的概念，使得缺陷填报人能够正确的填报每个缺陷的产品组件位置。
基于Project的项目管理度量规划[2]
2006-12-01 21:00:26
基于Project的项目管理度量规划[1]
2006-12-01 20:56:11
罗耀秋，字无介，号馨园主人。湖南浏阳人。好旅游、音乐、垂钓、美食、足球。 10多年质量管理，外包管理，培训管理及招募管理经验，对敏捷，CMMI/ISO/TL9000/6Sigma/PMP/PrinceII/测试咨询等有一定的了解。 邮件：luoyear@163.com，微信：luoyaoqiu，新浪微薄：http://weibo.com/luoyaoqiu
标题搜索
我的存档
数据统计
- 访问量: 203691
- 日志数: 56
- 图片数: 3
- 书签数: 2
- 建立时间: 2006-12-01
- 更新时间: 2012-12-07
