软件质量管理实践.docx
《软件质量管理实践.docx》由会员分享，可在线阅读，更多相关《软件质量管理实践.docx（25页珍藏版）》请在冰点文库上搜索。
软件质量管理实践
软件质量管理实践
——软件缺陷预防、清除、管理实用方法
第7章软件度量
软件度量是针对软件开发项目、过程及产品进行数据定义、收集以及分析的持续性定量化的过程。
有效度量的作用在于能够帮助软件组织认清自身的能力，理解、评价、控制、预测和改进软件工作产品或软件过程。
本小节为大家介绍的是软件度量及其方针。
随着技术的进步和软件应用领域的拓展，用户需要更大规模、更可靠的软件，此时，软件度量工作显得更为重要了。
如果一个组织能够对其生产的产品做出预测和承诺，那么就可以说这个组织是成功的。
有效度量的作用在于能够帮助软件组织认清自己的能力，根据对度量数据结果的分析，进一步为他们的生产和服务制订出可行的计划；及时找到变化趋势，预测问题，发现或者采取有效手段预防缺陷；不断改进软件开发过程。
需求的变更直接导致规模的变更、进度的延期以及成本的增长，公司要求项目经理定期度量需求变更（包括新增的、修改的和删除的需求数）的数量及需求总数的变化，控制需求变更并采取相应的措施。
图7-1中两条线分别表示需求总数的变更以及每周需求变更的数量。
曲线中的数据表明，第二周的需求评审后，第三周需求总数又有了明显的增长，而且第三、第四和第五周需求变更的数量都很大。
为了查找具体原因，须继续分析更加详细的数据，如图7-2所示。
图7-2中显示，经过了第二周的"第1次评审"，需求变更还是很大，其中大量的需求处于修改状态。
而且第七周"第2次评审"后，需求在相当长的时间内依旧没有稳定下来。
目前，项目已经进入到设计阶段，大量的需求变更是项目失败的一个隐患。
为了控制不断需求的变更，项目可能采取包括重新分配资源，重新估计规模、工作量和进度等具体措施。
另外，还可以详细地分析需求变更的具体原因（如误解、不清楚、不完善和不正确等）、需求变更的类型（如功能、性能和接口需求等）以及细化跟踪的粒度到每个模块。
通过这些详细的分析，可确定造成需求频繁变更的根本来源，以便有针对性地采取措施。
7.6 缺陷度量
缺陷度量是软件度量的一部分，其本身并不能发现缺陷、剔除缺陷，但是有助于这些问题的解决。
另外，当正确、持续地进行了缺陷度量时，产品以及过程的质量属性的数据为实施和管理过程改进活动提供了有效的基础。
数据的质量等因素，我们在本章7.4节中已经考虑了，这里仍将遵循。
7.6.1 什么是缺陷度量
软件产品质量度量，主要集中在软件的缺陷度量上。
缺陷度量就是对项目过程中产生的缺陷数据进行采集和量化，将分散的缺陷数据统一管理，使其有序而清晰，然后通过采用一系列数学函数，对数据进行处理，分析缺陷密度和趋势等信息，从而提高产品质量和改进开发过程。
一般来说，在软件质量保证过程中，需要度量的缺陷数据包括6大类缺陷发现手段发现的所有缺陷。
如测试相关的缺陷，需要度量包括测试投入的工作量和成本数据、测试任务完成情况、测试规模数据、测试结果数据（包括缺陷数据、覆盖率数据）等。
（1）组织级缺陷度量，目的是了解组织的整体缺陷情况，了解客户对组织的质量满意度，建立组织基线，确定改进活动。
（2）项目级缺陷度量，目的是了解项目实时质量情况（很多项目只在最后度量，包括那些迭代式开发的项目，实际上为时已晚），预测缺陷造成的发布后维护工作量，了解客户对项目的质量满意度。
（3）个体缺陷度量，目的是了解个体缺陷产生的详细原因，并实施行动进行改进。
前两种度量大家接触较多，但第三种度量常常被忽略。
这常常导致：
项目反复得到关于自己的质量评价，但很难了解如何去提高；
测试组常常能做一些改进（如增加测试覆盖、延长测试周期）来提高缺陷排除效率，但开发组没有降低缺陷产生数量的有效措施；
软件开发遵循了编码规范，但似乎对提高质量没有太多帮助。
度量得到的缺陷相关数据，分析方法可参见本章稍后的"缺陷分析"相关内容。
7.6.2 缺陷度量元
缺陷度量元的选择，也需要从度量目标出发，确定适当的度量元。
例如，可以按照如下表所示的思路确定组织整体或者项目组个体使用哪些缺陷度量元。
信息需要
可度量概念
度量目的
度量元
派生度量元
通过模块的各类型缺陷数来评价软件质量
模块缺陷分布
反映缺陷按类型、严重程度、所属模块分布情况。
通过度量可以客观上看出哪个模块的缺陷比较高，这样可加大对这个模块的开发投入
每个模块的各类缺陷数目
各模块的缺陷个数百分比
通过总体的各类型缺陷数来评价软件质量
总体缺陷分布
反映总体缺陷的分布情况，可看出软件的缺陷主要是哪些方面的缺陷，可帮助项目组找出问题，提高质量
每类缺陷的数目
每类缺陷占总缺陷的比例
通过缺陷密度评价模块稳定性
缺陷密度
通过按模块的缺陷密度倒序排列，通过二八定理确定缺陷密集模块，确定修复重点
每个模块的各类缺陷数目
每个模块的各类缺陷密度及比例
判断缺陷数量的趋势
总体趋势
反映新缺陷数、被解决的缺陷数和遗留的缺陷数的趋势，了解缺陷解决是否及时和全面
各种状态缺陷的数量
各种状态缺陷的数量的比例
判断缺陷驻留时间
缺陷排除情况
判断缺陷产生的原因
缺陷数量排行、缺陷发现时间、缺陷清除时间
整体缺陷清除率、阶段性缺陷清除率、缺陷的驻留时间
确定哪种缺陷发现方式有效
缺陷数量和种类
选择合适的降低缺陷的方法
缺陷种类
缺陷密度、同行评审发现错误率、测试发现的缺陷数、PPQA发现的缺陷数
除了上边重点描述的度量元外，还可以考虑其他与缺陷度量有关的因素。
例如：
缺陷分布度量、基于时间的缺陷到达模式、PTR累积模型、测试用例的深度、质量和有效性、测试执行的效率和质量、基于需求的测试覆盖评估、基于代码的测试覆盖评估。
再说一下前面的"前人栽树、后人乘凉"的5个度量元。
通过需求变化率、同一需求变化次数、配置项变化率、同一配置项变化次数、同一缺陷变化率这5个度量元的度量数据，查找一下是不是由变化最多的需求引起的，是不是由变化最大的配置项引起的，可以使维护的效率提高40%左右。
有效选择缺陷度量元，对缺陷预防、缺陷清除和缺陷管理有着至关重要的意义和作用。
7.6.3 缺陷密度的定义
对于一个软件工作产品，软件缺陷可以分为通过评审或测试等方法发现的已知缺陷（knowndefect）和尚未发现的潜在缺陷（1atencydefect）两种。
Myers有一个关于软件测试的著名反直觉原则：
在测试中发现缺陷多的地方，还有更多的潜在缺陷将会被发现。
这个原则背后的原因是，发现缺陷越多的地方，漏掉的缺陷可能性也会越大，或者说测试效率没有被显著改善之前，在纠正缺陷时将引入较多的错误。
其数学表达就是缺陷密度的度量--每KLOC或每个功能点（或类似的度量--对象点、数据点、特征点等）的缺陷数，缺陷密度越低意味着产品质量越高。
缺陷密度的定义如下：
缺陷密度=已知缺陷数量/产品规模
缺陷密度与缺陷率、整体缺陷清除率、缺陷趋势、预期缺陷发现率等都有一定的关系，相关内容可以参考
7.6.4 缺陷密度的用途
缺陷密度是软件缺陷的基本度量，可用于设定产品质量目标，支持软件可靠性模型（如Rayleigh模型）预测潜伏的软件缺陷，进而对软件质量进行跟踪和管理，支持基于缺陷计数的软件可靠性增长模型（如Musa-Okumoto模型），对软件质量目标进行跟踪并评判能否结束软件测试。
如果缺陷密度跟上一个版本相同或更低，就应该分析当前版本的测试效率是不是降低了？
如果不是，意味着质量的前景是乐观的；如果是，那么就需要额外的测试，还需要对开发和测试的过程进行改善。
如果缺陷密度比上一个版本高，那么就应该考虑在此之前是否为显著提高测试效率进行了有效的策划，并在本次测试中得到实施？
如果是，虽然需要开发人员更多的努力去修正缺陷，但质量还是得到更好的保证；如果没有，意味着质量恶化，质量很难得到保证。
这时，要保证质量，就必须延长开发周期或投入更多的资源。
当软件产品或者项目首次发布，并规定使用LOC计数时，可以比较容易地说出它的计划或者实际的质量等级，如"本产品共有83KLOC，在今后的3年时间里，潜在的缺陷率是2.0个缺陷/KLOC"。
但当进行了修改、增强后进行产品的后续发布时，问题就会越来越复杂。
缺陷跟踪：
缺陷必须被跟踪到版本源头，其中包含此缺陷的代码段，以及在哪个版本中加入、修改或增强的。
当计算整个产品的缺陷率时，要用到所有缺陷；当计算新的和更改代码的缺陷率时，则只需要包含新的和更改代码的版本源头中的缺陷即可。
缺陷率度量在每个单位的基础上度量代码质量。
从用户的角度来看，缺陷率远没有缺陷总数那么重要，对他们来说，产品应该确保缺陷总数与发布版本大小无关，而随着发布版本下降。
如果一个新发布版本的大小比它的前一版本大很多，则需要新的和更改代码的缺陷率应该明显地好于以往版本。
我们可以考虑如下假设的例子：
产品A最初发布时代码总量为50KLOC，估计残留缺陷总数是100个，平均有2个缺陷/KLOC。
发布第二版时，新增代码行为20KLOC，包括修改原来的4KLOC行代码（需要剔除，避免重复计算），可以计算出该版本代码总数为5020466KLOC，该版本对上一版本的缺陷率有10%的改进，估计当前版本残留缺陷新增总数可以控制在36个以内，则平均残留缺陷数为1.8个/KLOC。
此时，由于此次发布版本较小，在缺陷率有10%的改进的同时，用户在缺陷数方面经历了（10036）/10064%的明显下降。
如果进行第三版的发布时，新增代码行为40KLOC，这比第二次发布大得多，其中包括修改原来的10KLOC行代码，则该版本代码总数为66401096KLOC，为了使用户的缺陷体验不至于失望，增加的缺陷总数不应该多于上个版本的36个，所以缺陷率目标需要控制在36/400.9或者更低，即该版本的缺陷率必须比第二版的好50%。
7.6.5 缺陷管理库
从缺陷发现、缺陷修复，直到缺陷解决、经验证、关闭缺陷为止，在缺陷管理的整个生命周期中记录了大量相关资料，它们是进行缺陷分析、提高产品质量所需要的宝贵信息。
度量这些缺陷的发现成本、修改效益，对缺陷管理及其改进是非常有帮助的。
一般地，要求将通过同行评审、测试、管理评审、PPQA发现、项目组内部发现以及客户反馈等几种手段发现的缺陷，都需要统一存放在缺陷跟踪系统（如TD、BUGZILLA等）中，进行统一管理、统计。
其中涉及缺陷的基本信息在第1章已经描述过，包括缺陷标识、缺陷描述/主题、发现时间、所处阶段、发现手段、缺陷原因、发生条件、发生缺陷的子系统、所处的模块、发生缺陷的机器、软硬件平台、严重程度、优先级、缺陷状态、缺陷起源、发现人、计划修正时间、修正方法、跟踪验证人等信息项。
其中，软件发布前的缺陷原因关键字，可能包括以下几种：
（1）需求文档：
需求分析文档不明确、不详尽等原因引起。
（2）信息交流：
信息交流不畅，开发成员间沟通不及时引起。
（3）编程：
原始编程出错，没有客观原因。
（4）修改：
由于修改缺陷而引入的新缺陷，并且引发的变更与原变更的错误是相关的。
（5）外部问题：
涉及软件模块外部问题而引起。
（6）培训：
项目组新成员培训不充分，或使用新工具不熟练引发。
（7）其他：
指以上各种原因之外所产生的缺陷。
软件发布后缺陷原因的关键字，可以有以下几种实例：
（1）需求分析：
需求分析不足等原因引起。
（2）系统设计：
软件系统设计种种原因引起。
（3）程序编码：
软件开发阶段中编程错误引起。
（4）维护：
软件发布后程序维护时引起。
（5）实施：
实施人员做软件初始化设置或系统参数设置不当等所引发。
（6）用户：
泛指用户不了解业务和软件、不熟悉操作等原因产生的异常问题。
（7）数据异常：
运行中不明原因引起的用户数据混乱和异常。
（8）升级：
软件版本升级过程中发生的问题，包括用户在升级时未按规程操作产生的问题。
（9）外部问题：
所涉及软件外部问题引起的变更，包括操作系统、数据库软件、第三方软件所引起的问题。
（10）其他：
指以上各种原因之外的变更，包括变更原因不明。
但需要强调，记录缺陷信息的关键是注意信息正确性。
不能有人为因素失真，尤其像变更产生根本原因、变更测试情况。
只有正确的信息，才能保障正确的分析结果。
7.7节"缺陷分析"。
使用缺陷密度时，有一点需要注意：
百分比度量表示相对频率，需要给出足够的上下关系信息。
通常的描述在使用百分比和比率时不够小心，例如：
"需求缺陷占总数的15%，设计缺陷占总数的25%，编码缺陷占总数的50%，其他的缺陷占总数的10%"。
还不能提供更加详细有力的信息，如果按照如下所述，将可以得到更多的信息，即"一个包含了8000行代码的工程，在其开发期间，检测并排除了约200个缺陷，因此缺陷排除率为每千行代码25个缺陷。
在这200个缺陷中，需求缺陷占总数的15%，设计缺陷占总数的25%，编码缺陷占总数的50%，其他的缺陷占总数的10%"。
7.7.1 缺陷种类分析
下面以一个项目的系统测试故障为例进行分析，如图7-9所示。
图7-9 系统测试缺陷类型分布图
从系统测试故障来看，有较多故障是由接口原因造成的，细分有以下几种原因。
（1）跨项目间的接口：
接口设计文档的更改没有建立互相通知的机制，导致接口问题到系统测试时才暴露出来；
（2）部门内部跨子系统的接口：
由于本项目设计文档按功能规划编写，而不是按照产品组件编写，一般由主要承接功能工作的组编写该文档，接口内容可能不为其他开发组理解并熟悉，导致因接口问题而出错；
（3）系统设计基线化后，更改系统接口：
没有走严格的变更流程，进行波及分析，导致该接口变更只在某个子系统中被修改，而使错误遗留下来。
根据图7-9，可以制定有针对性的改进建议：
（1）对接口文档的评审，一定要识别受影响的相关干系人，使他们了解并参与接口设计的把关；
（2）对基线化的接口设计文档的变更一定要提交变更单给CCB决策，并做好充分的波及影响分析，以便同步修改所有关联的下游代码；
（3）概要设计文档按子系统规划，详细设计文档按模块规划，通过相关组参加评审的办法来协调接口设计。
以上例子的缺陷分类只是为了描述方便，本身描述并不尽合理。
实际定义缺陷分类可能有很多个维度，可以将前面所说的6种缺陷发现方法发现的缺陷，按照缺陷严重程度、缺陷来源、缺陷类型、注入阶段、发现阶段、修复阶段、缺陷性质、所属模块等方面进行分类和统计，计算以下各种缺陷的分布情况。
（1）缺陷按发现方法的分布；
（2）缺陷按生命周期注入阶段的分布；
（3）缺陷按生命周期修复阶段的分布；
（4）缺陷按严重程度等级的分布；
（5）缺陷按系统模块的分布，并按模块缺陷密度排序。
7.7.2 缺陷根源分析
对于同行评审、测试出来的缺陷进行缺陷分类，按照其类型分布，找出那些关键的缺陷类型，进一步分析其产生的根源，从而制定针对性的改进措施。
通过对功能上的分布情况进行分析，可以了解哪些模块处理比较难，哪些模块程序质量比较差，有利于程序质量的改进和提高。
缺陷起源分布报告，显示了缺陷产生的根本原因上的分布情况，这种分析会帮助改进程序代码质量。
利用鱼骨图、柏拉图等分析缺陷产生的根本原因，根据这些根本原因采取措施，可以改进开发和测试过程，有重点地避免缺陷发生，提高软件产品的质量。
7.7.3 缺陷注入-发现矩阵
缺陷有"注入阶段"和"发现阶段"两个重要指标，注入阶段和发现阶段可以是软件生命周期的各个阶段。
根据这两个阶段可以绘制出一个"缺陷注入-发现矩阵"，从中分析出软件开发各个环节的质量，找到最需要改进的环节（见表7-7）。
表7-7 缺陷注入-发现矩阵
缺陷注入阶段
缺陷发现阶段
需求
设计
编码
注入总计
需求阶段
4
4
设计阶段
13
62
75
编码、单元测试阶段
2
11
16
29
系统测试阶段
2
3
97
102
验收测试阶段
0
0
21
21
发现总计
21
76
134
231
本阶段缺陷移除率
19%
82%
12%
在分析例子之前，先简单介绍一下其中的一些基本概念。
缺陷注入分析矩阵的每行表示该阶段或活动发现的各阶段产生的缺陷数；矩阵的每列表示该阶段或活动注入的缺陷泄漏到后续各环节的缺陷数。
还可以通过修复阶段、缺陷性质、所属模块这样的整理（这部分内容见上一节"缺陷根源分析"），进一步扩展成缺陷注入发现修复矩阵，但是此矩阵表现起来就不会像"缺陷注入发现矩阵"那么直观了。
缺陷移除率定义为：
缺陷移除率=（本阶段发现的缺陷数/本阶段注入的缺陷数）100%
如需求阶段一共注入了21个缺陷，需求评审时只发现了4个，设计过程中发现了13个，编码和单元测试阶段发现了2个，还有2个直到系统测试阶段才被发现。
这样，需求阶段的缺陷移除率4/21100%19%。
它反映的是该活动阶段的缺陷清除能力。
相应的还有一个概念就是"缺陷泄漏率"，即有多少本阶段注入的缺陷没有在本阶段发现而是被泄漏到后阶段环节才被发现。
其计算公式为：
缺陷泄漏率=（下游发现的本阶段的缺陷数/本阶段注入的缺陷总数）100%
显然，它等于（1缺陷移除率）。
它反映的是本阶段质量控制措施落实的成效。
从表7-7可以看到，编码过程的缺陷大部分依赖系统测试发现。
很显然，项目开发过程中的单元测试和集成测试活动开展不够深入。
我们可以进一步分析这些系统测试出来的测试缺陷，是不是可以被更前端的评审/测试/设计讨论活动所替代。
另外，我们看到，需求阶段注入的缺陷绝大部分是在设计阶段发现的。
这大概是目前国内公司大部分项目的现实，需求不稳定、不明确，很多东西需要在设计过程中才能明确下来。
从分析结果也可以看出，在设计评审时，也需要重新审视需求规格说明书，必要时可利用需求追踪矩阵辅助发现上游需求的缺陷。
当然，实际规划"缺陷注入发现矩阵"时，可以依据自己的管理要求，对缺陷的发现活动和注入阶段进行细分或粗分，并且在Bug系统中提交时，需要准确地填写这些属性字段。
7.7.4 收敛趋势分析
进行趋势分析的前提是研发过程稳定，其质量表现大体一致，这样数据反映的趋势才具备可信度。
本节先给出一个比较常用的分析图（见图7-10），管理者可以从中发现一些简单的缺陷发展趋势（这种缺陷可以是本文论述的广义缺陷发现手段确定的，也可以是单纯的测试手段发现的），从而了解软件质量趋势。
更严格和准确的趋势分析图，可以参考8.3节"质量控制工具"和8.4节"统计技术应用"。
图7-10 缺陷发展趋势图
横轴（时间轴）：
若干个均匀的时间点，以天、周或者月为单位，视项目的规模而定。
纵轴：
同一类性质的缺陷数量的个数。
根据具体的缺陷发现情况，可以绘制出如下4条曲线。
（1）发现数，累计的所有被发现的缺陷数量。
（2）关闭数，累计的所有被关闭的缺陷数量。
（3）日发现，当日（当期）发现的缺陷数量。
（4）日关闭，当日（当期）关闭的缺陷数量。
其中，发现数和关闭数是两条关键的趋势曲线。
对于使用如此分析的缺陷趋势图，可以初步分析出如下几种情况。
（1）可以关闭的情况（见图7-11）
当发现数和关闭数两条曲线刚好汇集在一起时，表明所有发现的缺陷都已经被关闭了，但此时仍然存在风险。
因为对于最新的这个版本，只完成了回归，还需要一些时间再进行最后一轮（甚至几轮）验证。
图7-11 可以关闭的趋势图
（2）暂时不能结束的状态（见图7-12）
图7-12 暂时不能结束的趋势图
图7-12中发现和关闭的缺陷都比较少，两条曲线没有汇集，区间也还比较大，但是都很平。
可能是研发和几种缺陷发现的效率都有了问题。
进展受到影响，关闭数的那条曲线很平，可能是发生了比较严重的技术难题，同时这个难题影响了测试进度（发现数曲线也很平，表明测试发现问题的进度也明显受到了影响）。
（3）无休止的情况（见图7-13）
图7-13 无休止的趋势图
发现数和关闭数两条线都呈上升趋势，而且都比较高，说明研发和缺陷发现的效率都比较高。
但是，严重的是，两条线的开口越来越大，短期内看不到汇集的趋势。
关闭数持续走高，代表了3种情况：
要么是产品代码质量不高，存在大量问题；要么是大量已关闭的问题又重新被打开；再有可能就是测试经理把关不严，导致重复提单。
此时，需要PPQA以及管理人员介入，协助指导发现问题所在。
（4）比较理想的状态（见图7-14）
该图中，发现数和关闭数两条曲线已经汇集，并持续了一段时间，此时的产品质量应该视为比较稳定，可以批准对外发布。
图7-14 比较理想的趋势图
这是缺陷发现关闭趋势图的几种典型状况解析，有利于在质量管理过程中及时观察现象，通过对过程的监控来降低产品质量风险。
7.7.5 回归分析
所谓回归分析法，是在掌握大量观察数据的基础上，利用数理统计方法建立因变量与自变量之间的回归关系函数表达式（称回归方程式）。
在回归分析中，当研究的因果关系只涉及因变量和一个自变量时，叫做一元回归分析；当研究的因果关系涉及因变量和两个或两个以上自变量时，叫做多元回归分析。
此外，在回归分析中，又依据描述自变量与因变量之间因果关系的函数表达式是线性的还是非线性的，分为线性回归分析和非线性回归分析。
通常线性回归分析法是最基本的分析方法，遇到非线性回归问题，可以借助数学手段转化为线性回归问题处理。
回归缺陷是由于修正当前缺陷时而引起相关的、新的缺陷，所以即使在测试阶段，也会产生新的缺陷。
我们的一个项目数据表明，严格地执行需求/设计评审和代码审查，可以使开发质量有200%的提高，其因果分析表明，常有一些缺陷本来可以在开发周期的早期发现，对缺陷源数据的分析指出，代码开发阶段的缺陷注入是最高的。
强烈重视评审和代码审查，使得审查覆盖率更高，效果更好。
可以分析开发和测试在人力资源的配比上是否恰当，可以分析出某个严重的缺陷所造成的项目质量的波动。
对于异常的波动，如本来应该越测试越收敛的，但到了某个时间点处，发现的缺陷数反而呈上升趋势，那么，这些点往往发生了一些特殊的事件。
例如：
（1）在该时间段，送测的回归版本增加了新的功能，导致缺陷注入；
（2）该回归版本开发部没有进行集成测试就直接送测。
类似等等问题。
前面反复强调，越到后端发现的缺陷，用于问题复现、问题定位和缺陷修复花费的时间和成本就越多，软件工程经济学中"1:
10:
100规则"也揭示了这种情况。
那么有什么方式可以在项目早期识别哪些活动没有充分投入，或者没有运用合适的技术方法导致缺陷被泄漏到下游，从而防范于未然呢？
我们可以在组织的典型项目中运用一定的抽样原则，抽样出某个阶段的若干个缺陷，从技术、流程、方法等方面去分析更适合、更经济的清除方法，然后把这些方法固化到日常的项目实施过程中，就可以逐步降低上游对后端的缺陷泄漏。
下面以一个项目的系统测试阶段发现的故障为例，进行过程有效性回归分析，如表7-8 回归分析举例
实际发现活动
最佳发现活动
计数
百分比
系统测试
代码评审
2
14%
集成测试
7
50%
设计评审
4
29%
系统测试
1
7%
从表7-8可以看出，真正需要遗留到系统测试阶段才能发现的故障只有7%，大部分故障在集成测试和设计评审过程中就应该被发现。
导致在集成测试过程中未能充分发现这些缺陷的原因主要有：
（1）测试环境不具备，导致部分测试项必须到系统测试阶段才具备测试条件；
（2）测试设计中某些测试项的缺失，需要加强测试设计的评审工作；
（3）在回归测
升级会员 