缺陷管理

什么是缺陷？

软件缺陷的定义
IEEE 1983 of IEEE Standard 729中对软件缺陷做了一个标准的定义：

• 从产品内部看，软件缺陷是软件产品开发或维护过程当中所存在的错误、毛病等各类问题。
• 从外部看，软件缺陷是系统所须要实现的某种功能的失效或违背。

软件缺陷是指存在于软件（程序、数据、文档）中的那些不符合用户需求的问题。

• 软件未达到需求规格说明书代表的功能。（计算器说明书通常声称该计算器将准确无误地进行加、减、乘、除运算。若是测试人员或用户选定了两个数值后，随意按下了“+”号键，结果没有任何反应。）
• 软件出现了需求规格说明书指明不会出现的错误。（假如计算器说明书指明计算器不会出现崩溃、死锁或者中止反应，而在用户随意按、敲键盘后，计算器中止接受输入或没有了反应。）
• 软件的功能超出了需求规格说明书指明的范围。（若在进行测试时，发现除了规定的加、减、乘、除功能以外，还可以进行求平方根的运算，而这一功能并无在说明书的功能中规定。）
• 软件未达到需求规格说明书虽未指明而应该达到的目标。（若在测试过程当中发现，每当计算器重启后，计算值就出现误差，但软件需求规格说明书未能指出在此状况下应如何进行处理。）
• 软件测试人员认为软件难以理解、不易使用、运行速度慢、或者最终用户认为很差。（测试人员或最终用户发现计算器某些地方很差用，好比，按键过小、显示屏在亮光下没法看清等。）

所以软件缺陷就是软件产品中所存在的问题，最终表现为用户所须要的功能没有彻底实现，没有知足用户的需求。
因此，缺陷不只仅是程序出了bug。缺陷>=bug。

软件缺陷的表现形式

• 功能、特性没有实现或部分实现。
• 设计不合理，功能特性不明确，逻辑不清楚或存在矛盾。
• 产品实际结果和所指望的结果不一致。
• 没有达到需求规格说明书所规定的性能指标等。
• 运行出错，包括运行中断、系统崩溃、界面混乱等。
• 数据不正确、精度不够、不完整或格式不统一。
• 用户不能接受的其余问题，如存取时间过长、界面不美观。
• 硬件或系统软件上存在的其余问题

软件缺陷产生的缘由

软件缺陷产生是不可避免的，形成软件缺陷产生的缘由主要概括以下：

• 需求解释或者记录错误
• 用户需求定义错误
• 设计说明存在错误
• 编码说明、程序代码有误
• 硬件或者软件系统上存在错误
• 其余，如文档错误、内容不正确或拼写错误

需求说明书：需求说明书的错误或不清楚引发的错误，是缺陷第一大的来源；
设计文档：设计文档描述不许确、以及与需求说明书不一致，是缺陷的第二大来源；
编码：纯粹是由编码的问题引发；
其余：系统集成、测试等引发；

传话游戏

营长对值班军官:明晚大约八点钟左右,哈雷慧星将可能在这个地区看到,这种慧星每隔七十六年才能看见。命令全部士兵着野战服在操场上集合,我将向他们解释这一罕见的现象。若是下雨的话,就在礼堂里集合,我为他们放一部有关慧星的影片。 值班军官对连长:根据营长的命令,明晚八点哈雷慧星将在操场上空出现若是下雨的话,就让士兵穿着野战服列队前往礼堂,这一罕见的现象将在那里出现。 连长对排长:根据营长的命令,明晚八点,非凡的哈雷慧星将身穿野战服在礼堂中出现。若是操场上下雨的话,营长将下达另外一个命令,这种命令每隔七十六年才会出现一次。 排长对班长:明晚八点,营长将带着哈雷慧星在礼堂中出现,这是每隔七十六年才会有的事。若是下雨的话,营长将命令慧星穿上野战服到操场上去。 班长对士兵:在明晚八点下雨的时候,著名的七十六岁的哈雷将军将在营长的陪同下身穿野战服开着他那辆"慧星"牌汽车通过操场前往礼堂。

软件缺陷的根源

缺陷根源：指形成缺陷的根本因素，以寻求软件开发流程的改进、管理水平的提升，软件缺陷根源如上。

• 交流不充分：客户与开发人员、开发人员与测试人员等，沟通太少。
• 软件的复杂性：功能复杂、开发复杂、测试复杂。
• 开发人员的错误：对需求的理解、开发压力、能力与经验。
• 需求的变化：需求说明书、设计文档、程序的变动。
• 进度压力：项目周期比较紧，好比由原定3周改成1周。

软件缺陷修复的费用

软件在从需求、设计、编码、测试一直到交付用户公开使用后的过程当中，都有可能产生和发现缺陷。随着整个开发过程的时间推移，更正缺陷或修复问题的费用呈几何级数增加。
某些缺陷检测方法的成本比其余方法要高。最经济的方法应该是找出缺陷的成本最低，而在其余方面同别的方法并没有二致。后一个条件很重要，由于查找缺陷的成本受到了不少因素的影响，例如特色的缺陷检测技术所能找到的缺陷总量，缺陷被发现时所处的开发阶段，以及经历因素以外的其余因素。
大部分研究都发现，检查比测试的成本更小。NASA软件工程实验室的一项研究发现，阅读代码每小时可以检测出的缺陷要比测试高出80%左右（Basili and Selby 1987），另外一个组织则发现使用测试来检测缺陷的成本是检查的6倍（Ackerman，Buchwald and Lewski 1989）。后来，IBM的一项研究又发现，检查发现一个错误只须要3.5个工做时，而测试则须要花费15~25个工做时（Kaplan 1995）。

软件缺陷的信息

为了便于缺陷的定位、跟踪和修改，要对所发现的缺陷，按照缺陷的严重程度、优先级、发现阶段、修复阶段、缺陷的性质、所属功能模块、系统环境等方面进行分类和统计。

缺陷状态

编号	缺陷状态	描述
1	提交（submited）	已提交的缺陷
2	打开（open）	确认“提交缺陷”，等待处理
3	拒绝（rejected）	拒绝“提交缺陷”，不须要修复或不是缺陷、重复缺陷、没法重现
4	修复（resolved）	缺陷被修复
5	关闭（closed）	确认缺陷已修复，将其关闭
6	推迟（later）	能够在之后解决，但要肯定修复日期或版本

软件缺陷的信息

编号	属性名称	描述
1	缺陷ID	惟一的缺陷ID，能够根据该ID追踪缺陷
2	缺陷状态	缺陷状态指缺陷经过一个跟踪修复过程的进展状况
3	缺陷标题	描述缺陷的标题
4	缺陷的严重程度	对软件产品的影响程度，分致命、较严重、严重、通常、低
5	缺陷的优先级	缺陷修复的前后顺序，即哪些缺陷优先修正，哪些稍后修正
6	缺陷所属模块	缺陷所属的项目和模块，要能较精确的定位至模块
7	缺陷记录者	提交缺陷的人员姓名
8	缺陷提交时间	缺陷提交的时间
9	缺陷处理人	处理缺陷的处理人
10	处理结果描述	对处理结果的描述，描述处理状况和代码修改说明
11	缺陷处理时间	缺陷处理的时间
12	缺陷验证人	对被处理缺陷验证的验证人（回测者）
13	验证结果描述	对验证结果的描述（经过、不经过）
14	缺陷详细描述	缺陷的重现步骤
15	缺陷环境说明	对测试环境的描述
16	必要的附件	如涉及到附件的或错误现象的图片等

为了便于缺陷的定位、跟踪和修改，要对所发现的缺陷，按照缺陷的严重程度、优先级、发现阶段、修复阶段、缺陷的性质、所属功能模块、系统环境等方面进行分类和统计。

缺陷分类（bug类型）

系统缺陷

• 因为程序所引发的司机，异常退出。
• 程序死循环。
• 程序错误，不能执行正常工做或重要功能，是系统崩溃或资源不足。

数据缺陷

• 数据计算错误。
• 数据约束错误。
• 数据输入、输出错误。

严重地影响系统要求或基本功能的实现，且没有办法更正（从新安装或者重启不属于更正的方法）。

数据库缺陷

• 数据库发生死锁。
• 数据库的表、缺省值为加约束条件。
• 数据库链接错误。
• 数据库中的表由过多的空字段。

接口缺陷

• 数据通讯错误。
• 程序接口错误。

功能缺陷

• 功能没法实现。
• 功能实现错误。

严重地影响系统要求或基本功能的实现，且没有有合理的办法更正（从新安装或者重启不属于更正的方法）。
安全性缺陷

• 用户权限没法实现。
• 超时限制错误。
• 访问控制错误。
• 加密错误。

兼容性缺陷

• 与需求规定配置兼容性不符合。

性能缺陷

• 未达到预期的性能目标。
• 性能测试中出错，致使没法继续进行测试。

界面缺陷

• 操做界面错误。
• 打印内容、格式错误。
• 删除操做未给出提示。
• 长时间操做未给出提示。
• 界面不规范。

用户操做不方便或者遇到麻烦，但不影响执行工做功能的实现。

软件缺陷严重性与优先级

软件缺陷分类：严重性

严重等级	描述
5-Critical	系统瘫痪、异常退出、死循环、严重的计算错误等
4-VeryHigh	频繁的死机，系统大部分功能不可用
3-High	a.功能点没有实现，或不符合用户需求b.数据丢失
2-Medium	a.影响一个相对独立的功能　　b.仅仅在特定条件上发生c.与产品需求定义不一致　　　d.断断续续的出现问题
1-Low	表面性错误（如错别字）

软件缺陷分类：优先级

优先级别	描述
5-Urgent	最高优先级。在这个错误影响下，系统几乎不可用。
4-VeryHigh	高优先级。错误对这套系统的能力产生严重的影响。
3-High	中优先级。若是这个错误存在与系统中，会制约开发和测试的活动的进行，若是先前没有修复它，那么须要在发布前修复它。
2-Medium	低优先级。不会延迟发布，可是会在之后修正这个错误。
1-Low	最低优先级。时间和资源容许时修正。

缺陷修改说明

再来聊聊缺陷修改中碰到的一些状况。
开发人员拒绝修改的缺陷

• 程序员没法重现或者现象难以捕捉
• 没有明确的报告以说明重现缺陷的步骤
• 程序员没法读懂的缺陷报告
• 用户不多使用或者不符合用户使用习惯的操做出错
• 由不受信任的测试人员提出

不是全部缺陷都会修改

• 市场的压力使得产品最终发行有时间限制
• 测试人员错误理解或者不正确操做引出的缺陷(FAQ)
• 错误的修改影响的模块较多，带来的风险较大(遗留)
• 修改性价比过低
• 缺陷报告中提出的问题很难重现

bug

说完了缺陷，让咱们深刻缺陷中，来聊聊bug。

什么是bug

• bug泛指软件程序的漏洞和缺陷。
• 测试工程师或用户发现与提出的，软件能够改进的细节部分、或者与需求文档存在功能误差的实现。
• 测试工程师主要职责就是发现bug，提交bug信息给研发人员，研发人员修复bug。

案例
例如登陆时，要求输入帐号密码。
输入正确的帐号密码:
结果提示：用户名/密码不存在
再三确认帐号密码是否错误，能够从新再注册一个帐号进行登陆
如新帐号也是帐号不存在，此登陆已是bug了！

bug的类型
想要肯定bug的类型，须要对产品有较深的理解。
禅道系统中对bug定义划分以下：

• 代码错误(研发代码有误，功能未实现)
• 设计缺陷
• 界面优化
• 性能问题
• 配置相关
• 安装部署
• 安全相关
• 标准规范
• 测试脚本
• 其余(功能类、界面类、性能类、易用性类、兼容性类、其余)

bug等级划分

根据bug等级划分为三级或四级。
等级越高，可能被修复的等级也越高，公司也会根据测试提交的bug数量以及bug等级做为绩效考核标准。
判断bug的等级，以下分类：

• 致命错误
  • 常规操做缺引发系统崩溃、死机、死循环
  • 形成数据库泄露的安全问题，如恶意攻击形成的帐户私密信息泄露
  • 涉及金钱隐患，金钱计算bug(如金额不足，还能够购买产品，对公司金额形成重大损失
• 严重错误
  • 重要功能未实现，如点击注册无反应，没法登陆
  • 很是规操做（误操做）致使程序崩溃、死机、死循环
  • UI界面的严重问题
  • 密码明文显示，数据库泄露
• 普通错误
  • 不影响产品运行，不会影响故障，但对产品外观界面影响较大，如删除了好友，好友却未消失
  • 功能没法正常显示功能
  • 操做界面错乱
  • 查询数据错误
  • 页面未作输入格式限制
  • 删除错误未给与提示

缺陷报告

接下来，聊聊缺陷报告，那什么是缺陷报告？什么是报告缺陷呢？

报告缺陷的重要性

软件缺陷的描述是软件缺陷报告的基础部分，须要使用简单、准确、专业的术语来描述缺陷。不然，它就会含糊不清，可能会误导开发人员，影响开发人员的效率，也会影响测试人员自身的声誉，准确报告缺陷是很是重要的。

• 清晰准确的软件缺陷描述能够减小开发人员退回来的缺陷数量，能够节省开发人员和测试人员的时间。
• 提升软件缺陷修复的速度，使项目组可以有效地工做。
• 提升测试人员的可信任程度，能够获得开发人员对有效缺陷的及时响应。
• 增强开发人员、测试人员和管理人员的协同工做，让他们更好的工做。

报告缺陷注意事项

尽可能确保缺陷能够重现。

• 若是提交的缺陷没法重现，会影响开发人员的工做效率。

简洁、准确、完整。

• 测试人员在提交缺陷报告时，要站在开发人员的角度上思考问题，要确保开发人员能迅速定位问题，而不会产生理解上的歧义。

一个缺陷一个报告，有的测试人员喜欢在一个缺陷报告里提交多个缺陷，这种习惯不提倡，缘由有如下两点：

• 不便于分配，好比缺陷报告有2个缺陷，分别属于不一样的开发人员，到底该分配给谁呢？
• 不便于验证，好比一个缺陷报告里面有2个缺陷，缺陷1已经解决，缺陷2尚未解决，那么这个缺陷报告该不应关闭呢？

缺陷报告书写规范
标题：应保持简短、准确，提供缺陷的本质信息。

• 尽可能按缺陷发生的缘由与结果的方式书写。
• 避免使用模糊不清的词语，例如：“功能中断，功能不正确，行为不起做用”等。应该使用具体文字说明缺陷的症状。
• 为了便于他人理解，避免使用俚语或过度具体的测试细节。
  复现步骤：应包含如何使别人可以很容易的复现该缺陷的完整步骤。为了达到这个要求，复现步骤的信息必须是完整的、准确的、简明的、可复现的。常见问题：
• 包含了过多的多余步骤，且句子结构混乱，可读性差，难以理解。
• 包含的信息过少，丢失了操做的必要步骤。

复现步骤的正确书写方式：

• 提供测试的环境信息。
• 简单地一步步引导复现该缺陷，一个步骤包含的操做不要多。
• 每一个步骤前使用数字对步骤编号。
• 尽可能使用短语或短句，避免复杂句型句式。
• 复现的步骤要完整、准确、简短。
• 将常见步骤合并为较少步骤。
• 按实际须要决定是否包含步骤执行后的结果。

实际结果：是执行复现步骤后软件的现象和产生的行为。

• 实际结果的描述应向标题信息那样，要列出具体的缺陷症状，而不是简单地指出“不正确”或“不起做用”。

指望结果：描述应与实际结果的描述方式相同。一般须要列出指望的结果是什么。
附件：对缺陷描述的补充说明，能够是如下一些类型：

• 缺陷症状的截图。
• 测试使用的数据文件，166 199 188

其它：

• 选择合适的缺陷严重性属性。
• 按相应的规定，填写相应的字段信息。

避免常见的错误：

• 避免使用我、你等人称代词，能够直接使用动词或必要时使用“用户”代替
• 避免使用情绪化的语言和强调符号；
• 避免使用诸如“彷佛”、“看上去可能”等含义模糊的词汇，而须要报告肯定的缺陷结果；
• 避免使用自认为比较幽默的语句，只需客观地描述缺陷的信息；
• 避免提交不肯定的测试问题，本身至少须要重现一次再提交。

反面的示例：

• 上海人：哪能查询到的结果和查询条件不搭噶的。
• 北京人：哥们好不容易输入一堆我的详细信息后，点击保存后全瞎了。

缺陷处理流程

缺陷跟踪

新提交的缺陷为新建状态，确认有效后为打开状态，经开发人员修改后，缺陷变为已修复（待验证）状态。此时就须要测试人员对缺陷进行回归测试，验证问题是否修复。

• 若是问题仍然存在，则测试人员将该缺陷的状态修改成从新打开。
• 若是问题已经修复，则测试人员将该缺陷的状态置为关闭状态（验证经过），同时添加回测说明如“该缺陷已解决”。

还有一种状况：开发人员认为缺陷在当前版本能够暂不修改，而考虑在后续版本中再作修正，缺陷的对应状态为延期。对于这种状况，项目负责人应召集开发人员、测试人员和其余项目相关人员进行讨论，若是讨论结果为赞成则延期，若是不一样意，则从新打开缺陷。

缺陷统计

• 对软件问题的功能域分布进行分析，找出系统的薄弱环节。
  • 要详细采集每一个功能模块或系统构件的缺陷数据，并按功能、错误类型、严重程度等分类。
  • 二八定理：80%的软件问题老是发生在大约20%的功能模块中。
• 对缺陷的注入阶段的分布进行分析，并与历史数据相比较。应按不一样的开发阶段详细采集缺陷的数据。
• 应对软件缺陷类型进行分析，以便针对各自的特色，先修复严重缺陷。
• 应动态采集每一个测试周期中发现的缺陷数，并有效地控制缺陷的修复率。
• 应密切观察缺陷的状态，并及时跟踪其状态的变化，以检查测试和开发人员的工做状况。

bug统计
缺陷按活动分布：

缺陷密度

基本的缺陷测量是以每千行代码的缺陷数(个/KLOC)来测量的。称为缺陷密度，其测量单位是defects／KLOC。可按照如下步骤来计算一个程序的缺陷密度：

• 累计开发过程当中每一个阶段发现的缺陷总数。
• 统计程序中新开发的和修改的代码行数。
• 计算每千行的缺陷数=1000*缺陷总数/代码行数。

例如：一个132.2万行的源程序总共有210个缺陷，那该程序的缺陷密度是：

缺陷密度 = 1000 * 210 / 1322000 = 0.15个/KLOC

PS：KLOC，千行代码
缺陷数据分析

• 缺陷数据分析关注的问题
• 缺陷数据分析的重要性
• 缺陷数据分析的数据指标

缺陷数据分析关注的问题

• 正在测试的软件哪一个模块的问题最多
• 测试人员中谁报告的软件缺陷最多
• 各种缺陷所占的数量百分比分别是多少
• 开发人员能及时修复软件缺陷吗
• 开发人员一次正确修复缺陷的百分比是多少
• 正在开发的软件可否在计划的时间内正常发布

缺陷数据分析的重要性

• 统计未修复的缺陷数目（特别是严重性高的缺陷），预计软件是否能够如期发布。
• 分析缺陷的类型分布，发现存在较多缺陷的程序模块，找出缘由，进行软件开发过程改进。
• 根据测试人员报告缺陷的数量和准确性，评估测试有效性和测试技能。
• 根据报告的缺陷修复是否及时，改进软件开发与测试的关系，使测试与开发更有机的配合。

缺陷数据分析的数据指标

• 天天/周报告的新缺陷数目。
• 天天/周修复的缺陷数。
• 累计报告的缺陷数目。
• 累计修复的缺陷数。
• 不一样严重性类型的缺陷数。
• 程序模块与发现的缺陷的对应关系。

经常使用缺陷识别方法

• 经过技术文档识别缺陷
• 设计和分析文档
• 用户使用手册，帮助手册
• 经过行业标准规范识别缺陷
• 与专业人员来沟通识别缺陷

注意：不得站在本身主观意识去判断缺陷

来列举一些例子：

• 页面大小
  • 在B/S结构的软件系统中，当一个页面元素太多，未做精简时，在打开该页面时可能须要较长的加载时间，这对于软件性能是一个不小的影响，既增长了服务器的压力，又容易引发用户的反感。例如：
    • 图片未经压缩、格式不正确。好比采用BMP。
    • 代码冗余，存在太多无用代码。
    • 页面元素太多，太过复杂。
• 界面文字
  • 页面信息描述不清楚，有语病，错别字。简单语言复杂化，描述不正确，不符合当前页面。错误的帮助信息，乱码等。
• 容错处理（功能缺陷）
  • 容错处理在软件系统中占据十分重要的地位。所谓容错，就是容忍错误的能力。当用户在使用软件过程当中发生错误后，软件应该能给出引导信息，指应用户进行正确的操做。例如：
    • 用户输入错误，系统无提示，无响应，用户不能清晰知道系统不处理的缘由。
    • 给出信息提示，用户接受后没法继续操做，不给用户“改过自新”的机会。
    • 用户输入不合法的信息后，系统给出提示，用户肯定后，系统仍能处理错误的信息。
    • 取消功能不能取消，好比删除，系统给出提示，是否肯定删除，用户否定后仍执行了删除。
• 性能缺陷
  • 这里所说的性能问题不需专业的工具就能发现的问题，这类问题在日常作黑盒测试的时候就能发现。例如：
    • 打开文档，10秒应该能够完成的，却花了3分钟。
    • 启动软件，CPU长时间100%，内存消耗过多。
    • 5个用户能够正常使用，20个用户使用时系统崩溃。打开一个登陆页面花了1分钟。
    • 完成一个查询功能，花了2分钟。

接下来，就考验我的情商环节了，由于一不当心，可能面临挨打的风险！接下来的一些列举项，一般都由专业的人员完成，好比UI的设计师，DBA，人家是专业，你在人家的领域当心指手画脚啊，好比你跟UI说这个页面设计的真丑，那UI的小暴脾气上来，不用小拳锤胸口咋地！

你要是跟DBA说什么SQL有问题：

• 数据转换
  • 软件中的功能主体通常由等组成。例如：增长、修改、删除、查询。
    • 没法增长记录，好比点击新增，页面自动关闭。
    • 增长记录后无显示，但提示增长成功。
    • 增长记录后显示不正确，显示为乱码，信息显示不全。
    • 增长记录后多出记录。
    • 没法修改记录。修改后不能自动更新，需手工更新。
    • 没法删除记录，没法所有删除。
    • 删除不成功，但相应的记录已被删除。
    • 没法查询、查询结果错误。
• UI用户界面
  • 色彩：色彩的搭配无序、混乱是软件图形界面设计的大忌，图形界面应尽可能设计得温和些。这类缺陷主观类强，我的美感占据主动，所提交的缺陷通常严重程度不可定得过高。例如：
    • 总体页面色彩单调，无变化，仅使用一种色彩，且篇幅较大，可提交建议性的缺陷，即便是简单的界面，宁肯采用无色，也不可以使用鲜艳的单色，如红色，黄色、绿色等。
    • 背景色与界面字体色彩相近，不能清晰区分，色彩搭配混乱、复杂，且不符合软件标准。
• 功能结构布局
  • 功能结构布局主要从界面的功能区域划分来考虑。相同的、相似的功能应该放在邻近的区域。例如：
    • 记录添加功能界面，添加按钮未放在醒目的位置。
    • 导航功能位于界面的右则。
    • 总体功能区域分布混乱。
• 图片
  • 图片选用不合理，与当前软件类型不符，没法正确体现当前界面功能性含义。图片不规范、不清晰。例如：
    • 图片色彩过于艳丽或黯淡，模糊不清。
    • 图片变形。
    • 图片不符合当前界面的主题，图片与描述性文字不符。
• 字体
  • 字体在软件界面中尤为重要，字体的使用要符合软件开发规范。例如：
    • 字体过大，与其余页面信息脱节，没法造成主体。
    • 字体太小，没法看清楚。
    • 字体不符合当前界面风格。
• 窗体大小
  • 窗体的设计要有层次感，父窗口、子窗口应该有所区别。窗口不该该有太多空白处，功能区域充实。例如：
    • 窗口太大，功能按钮分散，间隔太大。
    • 窗口过小，功能按钮过于集中，间隔过小，或控件显示不全。
    • 弹出窗口未能定于屏幕居中位置。

不一样软件组织的缺陷管理过程

• 个体行为
  • 处于CMM第一级（或称为初始级）的软件组织，对软件缺陷的管理无章可循。工程师们只是在发现缺陷后，修改相应的软件。一般，没有人会去记录本身发现的缺陷。也没有人知道在新的软件版本里，究竟纠正了哪些缺陷，还有哪些缺陷未被纠正。并且，只有在下一轮测试中才有可能知道那些所谓已被纠正了的缺陷是否真的被纠正了，更重要的是纠正过程是否引入了新的缺陷。
  • 因此这样的软件组织的项目交货期（Release Date）表现出强烈的不可预测性。而且， 为了得到一个高质量的软件产品（若是可以的话），一般要在测试上花费大量的人力。
• 项目行为
  • 在CMM第二级（或称为可重复级）的软件组织中，软件项目会从自身的须要出发，制定本项目的缺陷管理过程。一个完备软件缺陷管理过程一般会包括以下几个方面：
    • 提交缺陷。
    • 分析和定位缺陷。
    • 提请修改相应的软件。
    • 修改相应的软件。
    • 验证修改。
  • 项目组会完整地记录开发过程当中的缺陷，监控缺陷的修改过程，并验证修改缺陷的结果。
• 组织行为
  • CMM第三级（或称为已定义级）的软件组织会聚集组织内部之前项目的经验教训，制定组织级的缺陷管理过程。而且，要求项目根据组织级的缺陷管理过程定制本项目的缺陷管理过程。
  • 从而，整个软件组织中的项目都遵循相似的过程来管理缺陷。好的缺陷管理实践成为全部项目的实践，而教训也为全部项目所了解。更重要的是，随着组织的不断发展完善，组织的过程会获得持续性的改进，全部项目的过程也都会相应的改进。
• 持续优化
  • 与CMM第四级相比，CMM第五级（或称为持续优化级）更强调对组织的过程进行持续性改进，从而使过程能力获得不断的提高。
  • 就缺陷管理而言，软件组织应当在量化理解其过程能力的基础上，持续地改进组织级的开发过程、缺陷发现过程，引入新方法、新工具，增强经验交流，从而实现缺陷预防（Defect Prevention）。
  • 缺陷预防的着眼点在于缺陷的共性缘由（Common Cause）。经过找寻、分析和处理缺陷的共性缘由，实现缺陷预防。