软件质量保证与测试

第一章 概述

1.2.3软件质量概念（14页）

1、IEEE关于软件质量的定义

软件质量是:

·系统、部件或者过程满足规定需求的程度.

.系统、部件或者过程满足顾客或者用户需要或期望的程度

该定义相对客观，强调了产品(或服务)和客户/社会需求的一致性

2.ANSI 关于软件质量的定义

按照美国国家标准学会(American National Standards Institute,ANSI)于1983年的标 准陈述，软件质量定义为“与软件产品满足规定的和隐含的需求的能力有关的特征和特性的 全体”。具体包括：

·软件产品中能满足用户给定需求的全部特性的集合。

·软件具有所期望的各种属性组合的程度。

·用户主观得出的软件是否满足其综合期望的程度。

·决定所用软件在使用中将满足其综合期望程度的软件合成特性。

1.2.4评价体系与标准（16页）

IEEE 给出软件质量保证(SQA) 的定义：一种有计划的、系统化的行动模式，是为项目 或者产品符合已有技术需求提供充分信任所必需的；用来评价开发或者制造产品的过程的 一组活动，与质量控制有区别。

然而，和实际的软件质量保证有偏离，软件质量保证不应局限于开发过程，软件质量保 证行动不应局限于功能需求的技术方面，而应该包含与进度和预算有关的活动。

针对这个考虑，软件质量保证有一个扩展定义：软件质量保证是一个有系统的、有计划 的行动集合，是为提供软件产品的软件开发过程与维护过程符合已经建立的技术需求，以及 跟上计划安排与在预算限制之内进行的管理上的充分信任的必需。

1.3.2软件测试的定义

软件测试是保证软件质量的关键步骤，是对软件规格说明、设计和编码的最后复审，其 工件量约占总工作量的40%以上。对于人命关天的情况，测试相当于其他部分总成本的 3～5倍。

1983年，IEEE 在提出的软件测试文档标准:软件测试是使用人工或自 动手段来运行或测定某个系统的过程，检验是否满足规定的需求，或者弄清预期结果与实际 结果之间的差别。

IEEE 在1990年颁布的软件工程标准术语集中沿用了这一概念，该概念非常明确地提 出了软件测试以检验是否满足需求为目标。

美国计算机科学家梅耶(Glenford Myers)在其经典论著《软件测试的艺术》中对软件测 试提出以下观点：

(1)测试是程序的执行过程，目的在于发现错误。

(2)一个好的测试用例可以发现至今尚未发现的错误。

(3)一个成功的测试能发现至今未发现的错误。

归根结底，测试包含检测、评价和测验，这和找错是显然不同的。

1.3.3软件测试的方法（25页）

黑盒测试形象地称为“戴着眼罩测试软件”。

黑盒测试也称功能测试或数据驱动测试，是已知软件所需功能，通过测试来检测每个功 能是否都能正常使用。

黑盒测试方法主要有等价类划分、边值分析、因果图、错误推测，等等，用于软件确认测 试。该方法着眼于程序外部结构，不考虑内部逻辑结构，针对软件界面和软件功能进行测 试。黑盒测试方法是穷举输入测试，只有把所有可能的输入都作为测试情况使用，才能以这 种方法查出程序中所有的错误。实际上，测试情况有无穷多个，人们不仅要测试所有合法的 输入，而且还要对那些不合法但是可能的输入进行测试。

白盒测试形象地称为“戴上 X 光眼镜测试软件”。

白盒测试也称结构测试或逻辑驱动测试，知道软件内部的工作过程，可通过测试来检测 软件产品内部的动作是否按照规格说明书的规定正常进行，并且按照程序内部的结构测试 程序来检验程序中的每条通路是否都能按预定要求正确工作，而不考虑功能是否正确。

白盒测试方法有逻辑覆盖、域测试、路径测试、程序插桩、程序变异，等等。

灰盒测试介于白盒与黑盒之间，关注输出对于输入的正确性，同时也关注内部表现。但 是，这种关注不像白盒那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部 的运行状态。有时候输出是正确的，但内部其实已经错误了。如果每次都通过白盒测试来 操作，效率会很低，因此需要采取灰盒的方法。

第二章 软件质量工程体系

2.1.1软件质量控制的基本定义

从本身的技术意义上说,软件质量控制是一组由开发组织使用的程序和方法,可在规定的资金投入和时间限制的条件下提供满足客户质量要求的软件产品并持续不断地改善开发过程和开发组织本身，以提高将来生产高质量软件产品的能力。

概念：软件质量控制是对开发进程中软件产品(包括阶段性产品)的质量信息进行连续的收集、反馈。

2.2.1软件质量控制模型

在我国,经过多年的全面质量管理工作的实践,PDCA 被证明是行之有效的质量管理理念,而目前基于PDCA的全面统计质量控制(Total Statistical Quality Control,TSQC)模型是我国实际采用的模型之一,其指导开发者计划和控制软件质量的框架用来描述各组成要素间的关系,如图2-5所示。

TSQC过程是一个调节和控制那些影响软件质量的参数的过程。影响软件质量的参数如下

产品:所有可交付物;

过程:所有活动的集合;.

资源:活动的物质基础(人力、技术、设备、时间、资金等)。

TSQC过程是PDCA几个活动的循环。

·计划 Plan:确定参数要求;

实施 Do:根据要求开展活动;

检查Check:通过评审、度量、测试确认满足要求改进

Action:纠正参数要求再开发。

2.3软件质量保证体系

2.SQA目标

SQA组织并不负责生产高质量的软件产品和制订质量计划,这些都是软件开发人员的工作。SQA 组织的责任是审计软件经理和软件工程组的质量活动,并鉴别活动中出现的偏差。

软件质量保证的目标是以独立审查的方式监控软件生产任务的执行,给开发人员和管理层提供反映产品质量的信息和数据,辅助软件工程组得到高质量的软件产品,主要工作句括以下3个方面。

(1)通过监控软件的开发过程来保证产品的质量;

(2)保证生产出的软件和软件开发过程符合相应的标准与规程;

(3)保证软件产品、软件过程中存在的不符合问题得到处理，必要时将问题反映给高级管理者。

从软件质量保证的目标中可以看出,SQA人员的工作与软件开发工作紧密结合,需要与项目人员沟通。因此,SQA 人员与项目人员的合作态度是完成软件质量保证目标的关键，如果合作态度是敌意的或者是挑剔的,软件质量保证的目标将难以顺利实现。

3.SQA任务

软件质量保证的主要作用是给管理者提供实现软件过程的保证因此SQA 组织要保证以下内容:

• 选定的开发方法被采用;
• 选定的标准和规程得到采用和遵循;
• 进行独立的审查;
• 偏离标准和规程的问题得到及时地反映和处理;
• 项目定义的每个软件任务得到实际执行。

相应地，软件质量保证的主要任务有以下方面

1)SQA审计与评审

其中,SQA 审计包括对软件工作产品、软件工具和设备的审计,评价这几项内容是否符合组织规定的标准。SQA 评审的主要任务是保证软件工程组的活动与预定义的软件过程一致，确保软件过程在软件产品的生产中得到遵循。

2)SQA报告

SQA人员记录工作的结果,并写人到报告之中,发布给相关的人员。SQA 报告的发布应遵循3条基本原则:SQA 和高级管理者之间应有直接沟通的渠道,SQA 报告必须发布给软件工程组但不必发布给项目管理人员,在可能的情况下向关心软件质量的人发布 SQA报告。

3)处理不符合问题

通过在软件开发周期中尽可能早地预期或检测到不符合情况(错误)来防止错误的发生,并减少错误纠正的成本。错误发现得越早,造成的损失越小,修改的代价也越小。这是SQA的一个重要任务。SQA 人员要对工作过程中发现的不符合问题进行处理及时向有关人员及高级管理者反映。在处理问题的过程中要遵循两个原则:其一,对符合标准过程的活动，SQA 人员应该积极地报告活动的进展情况,以及这些活动在符合标准方面的效果;其二,对不符合标准过程的活动,SQA 要报告其不符合性，以及它对产品的影响,同时提出改进建议。

第三章 软件质量度量和配置分配

3.1.1度量的定义

Metric:已定义的测量方法和测量尺度,在很多场合与Indicator 交叉出现，内涵大于Indicator,Metric指软件环境中任何一个软件对象的属性的量化表现。

3.2.4缺陷排查效率

缺陷排除效率(Defect Removal Efficiency,DRE)在项目级和过程级都能提供有益的质量度量。在本质上,DRE 是对质量保证及控制活动的过滤能力的一个测量,这些活动贯穿于整个过程框架活动。

在把一个项目作为一个整体考虑时,DRE 按以下方式定义:

DRE -E/(E+D)

其中,E=软件交付给最终用户之前所发现的错误数,D=软件交付之后所发现的缺陷数。

最理想的 DRE 值是1,即软件中没有发现缺陷。在现实中,D会大于0但随着E值的增加,DRE的值仍能接近 1。事实上,随着 E的增加,D的最终值可能会降低(错误在变成缺陷之前已经被过滤了)。DRE 作为一个度量,提供关于质量控制和保证活动的过滤能力的衡量指标，则 DRE 鼓励软件项目组采用先进技术，以便在交付之前发现尽可能多的错误DRE 也能够用来在项目中评估一个小组发现错误的能力,在这些错误传递到下一个框架活动或软件工程任务之前(例如需求分析任务产生了分析模型)可以复审该模型以发现改正错误。在分析模型的复审中,未被发现的错误会传递给设计任务(这里它们有可能被发现，也有可能没被发现)。在这种情况下,定义 DRE 为:

DRE=E/(E+E)

其中,E=在软件工程活动中所发现的错误数,E=在软件工程活动i1中所发现的错误数,这些错误来源于软件工程活动中未能发现的错误。

软件项目组(或单个软件工程师)的质量目标是使 DRE接近1,即错误应该在传递到下一个活动之前被过滤掉。

3.3.2常见问题

1.度量得太多、太频繁

2.度量得太少、太迟

3.度量了不正确的事物或属性

4.度量的定义不精确

5，收集了数据却没有利用

6错误地解释度量数据

7.自动化工具欠缺

第四章 软件可靠性度量和测试

4.1.2软件可靠性的定义

经过长期的争论和研究在1983年美国IEEE计算机学会对“软件可靠性”一词正式作出了如下定义:在规定的条件下,在规定的时间内,软件不引起系统失效的概率,该概率是系统输入和系统使用的函数,也是软件中存在的错误的函数,系统输人将确定是否会遇到已存在的错误(如果错误存在); 在规定的时间周期内,在所述条件下,序执行所要求的功能的能力。

4.4提高软件可靠性的方法和技术

4.4.1建立以可靠性为核心的质量标准

在软件项目规划和需求分析阶段要建立以可靠性为核心的质量标准。这个质量标准包括实现的功能、可靠性、可维护性、可移植性、安全性、吞吐率,等等。虽然没有一个衡量软质量的完整体系,但还是可以通过一定的指标来指定标准基线。

4.4.2选择开发方法

软件开发方法对软件的可靠性也有重要影响。

目前的软件开发方法主要有 Parnas 方法、Yourdon 方法面向数据结构的Jackson方法和 Warnier 方法PSL/PSA 方法、原型化方法面向对象方法 可视化方法ICASE方法瑞理开发方法等,其他还有 BSP 方法CSF 方法等。这里特别要提一下的是 Parnas方法。

4.4.3软件重用

最大限度地重用现有的成熟软件不仅能缩短开发周期、提高开发效率,也能提高软件的可维护性和可靠性。因为现有的成熟软件已经过严格的运行检测,大量的错误已在开发、运行、维护过程中排除，比较可靠。在项目规划开始阶段就要把软件重用列人工作中不可缺少的一部分，作为提高可靠性的一种必要手段。

4.4.4 使用开发管理工具

开发大的软件系统离不开开发管理工具,项目管理员仅仅靠人管理是不够的,需要有开发管理工具来辅助解决开发过程中的各种各样的问题,以提高开发效率和产品质量。

4.4.5 加强测试

在软件开发前期各阶段完成之后,为进一步提高可靠性，只有通过加强测试来实现了。为最大限度地除去软件中的差错、改进软件的可靠性,要对软件进行完备测试。对大的软件系统进行完备测试是不可能的,所以要确定最小测试数和最大测试数,前者是技术性的决策,后者是管理性的决策,在实际过程中要确定一个测试数量的下界。总的来说,要在可能的情况下进行尽可能完备的测试。

4.4.6容错设计

提高可靠性的技术可以分为两类，一类是避免故障,在开发过程中尽可能不让差错和缺陷潜入软件,常用的技术如下。

。算法模型化:把可以保证正确实现需求规格的算法模型化。

模拟模型化:为了保证在确定的资源条件下的预测性能的发挥,使软件运行时间内存使用量及控制执行模型化。

可靠性模型:使用可靠性模型从差错发生频度出发预测可靠性正确性证明:使用形式符号及数学归纳法等证明算法的正确性。

软件危险分析与故障树分析:从设计或编码的结构出发,追踪软件开发过程中潜入系统缺陷的原因。

分布接口需求规格说明:在设计的各阶段使用形式的接口需求规格说明,以便验证需求的分布接口实现可能性与完备性。这些技术一般都需要比较深厚的数学理论知识和模型化技术

第五章 软件质量标准

5.3能力成熟度模型

5.3.1 CMM质量思想

软件过程成熟度模型(Capability Maturity Model,CMM）。CMM 主要用于软件开发过程和软件开发能力的评价、改进，侧重于软件开发过程的管理及工程能力的提高、评估。

CMM包括5个等级,共计18 个过程域52个目标00多个关键实践,如图5-2 所示。

CMM 为软件过程改进提供了一个框架，5 个成熟度等级定义了一个有序的尺度，用来衡量组织软件过程成熟度和评价其软件过程能力。在每一级中定义了达到该级过程管理水平所应解决的主要问题和关键域。CMM分为5个等级:1级为初始级，2级为可重复级,3级为已定义级,4 级为已管理级,5 级为优化级。从当今整个软件公司现状来看,最多的成熟度为1级，多数成熟度为 2级,少数成熟度为3 级,极少数成熟度为4 级,成熟度为5 级的更是凤毛麟角。

第六章 软件评审

1.软件评审的定义

评审是一些用于开发过程早期检查和纠正缺陷的有效方法,可以用来检查未形成执行代码的文档的缺陷。

2.软件评审的意义

总体来说,在开发过程中评审可以让我们获得以下收益:

(1)提高项目的生产率,这是由于早期发现了错误,因而减少了返工时间，还可能减少测试时间。

(2)改善软件的质量。

(3)在评审过程中使开发团队的其他成员更熟悉产品和开发过程

(4)通过评审标志软件开发的一个阶段的完成。

(5)生产出更容易维护的软件。

3.评审的内容

1.管理评审是最高管理者为评价管理体系的适宜性、充分性、有效性所进行的活动。管理评审的主要内容是组织的最高管理者就管理体系的现状、适宜性、充分性、有效性以及方针和目标的贯彻落实与实现情况进行正式的评价。其目的是通过这种评价活动来总结管理体系的业绩。

2.技术评审(Technical Review)是一种同行审查技术,主要特点是由一组评审者按照规范的步骤对软件需求、设计、代码或其他技术文档进行仔细的检查,以找出和消除其中的缺陷。

3.文档评审在软件开发的每个阶段对该阶段形成的文档进行评审,尽早发现问题,并及时采取措施予以解决，确保文档的内容准确,为软件产品的质量提供保障

4.过程评审是对软件开发过程的评审，主要任务是通过对流程的监控保证 SQA 组织定义的软件过程在项目中得到了遵循,同时保证质量保证方针能得到更快、更好的执行。过程评审的评审对象是质量保证流程,而不是针对产品质量或者其他形式的工作产出。

4.评审的方法，异同点

1.评审的方法

（1）特别检查(Ad hoc Review)

特别检查是最不正式的一种评审方法,通常应用于平常的小组合作

（2）轮查(Pass Around)

轮查又称为分配审查方法,作者向评审者做简要介绍,但不参加评审过程;评审者独立进行评审,并记录发现的结果,准备报告。

（3）走查(Walk through)

走查也属于一种非正式的评审方法,在软件企业中被广泛采用。

产品的作者将产品向一组同事介绍,并收集他们的意见。在走查中,作者占有主导地位，由作者描述产品的功能和结构以及完成任务的情况等。走查的目的是希望参与评审的其他同事可以发现产品中的错误，了解产品,并对模块的功能和实现达成一致意见。然而,由于作者的主导性,也使得缺陷发现的效果并不理想。因为评审者事先对产品的了解不够,导致在走查过程中可能曲解作者提供的信息,并假设作者是正确的。评审员对于作者实现方法的合理性等很容易保持沉默，因为并不确信作者的方法存在问题

（4）团队评审(Group Review)

团队评审是有计划的和结构化的,非常接近于最正式的评审技术评审的参与者在评审会议前几天就拿到了评审材料,并对该材料独立研究。同时,评审还定义了评审会议中的各种角色和相应的责任。然而,评审的过程还不够完善,特别是评审后期的问题跟踪和分析往往被简化、忽略。

（5）检视(Inspection)

检视和团队评审很相似,比团队评审更严格,是最系统化、最严密的评审方法。普通的检视过程包含了制订计划、准备和组织会议、跟踪和分析检视结果,等等。

2.评审的方法异同点

第七章 软件全面质量管理

7.1.3全面质量管理与ISO9000（异同点）

ISO9000是指质量管理体系标准,它不是指一个标准,而是一族标准的统称。

下面将ISO9000和全面质量管理进行比较，给出相同和不同之处。

(1)相同之处:首先，两者的管理理论和统计理论基础一致，都认为产品质量形成于产品全过程,都要求质量体系贯穿于质量形成的全过程。在实现方法上,两者都使用了PDCA质量环运行模式。其次，两者都要求对质量实施系统化的管理,都强调一把手对质量的管理。最后,两者的最终目的一致,都是为了提高产品质量,满足顾客的需要,都强调任何一个过程都是可以不断改进和不断完善的。

(2)不同之处:首先，两者的期间目标不一致。全面质量管理的目标是改变现状,其作业只限于一次,目标实现后管理活动也就结束了。下一次计划管理活动虽然是在上一次计划管理活动的结果的基础上进行的,但绝不重复与上次相同的作业。相反,ISO9000的目标是维持标准现状,目标值为定值,管理活动是重复相同的方法、作业,使实际工作结果与标准值的偏差量尽量减少。其次,两者的工作中心不同,全面质量管理以人为中心,ISO 9000以标准为中心。再次,两者的执行标准及检查方式不同。实施全面质量管理企业所制定的标准是企业结合其自身特点制定的自我约束的管理体制,其检查方主要是企业内部人员,检查方法是考核和评价。而ISO 9000 系列标准是国际公认的质量管理体系标准,是世界各国共同遵守的准则。贯彻SO 9000 系列标准强调的是由公正的第三方对质量体系进行认证并接受认证机构的监督和检查。

全面质量管理是一个企业达到长期成功的管理途径,但成功地推行全面质量管理需要

定的条件。对大多数软件企业来说,直接引入全面质量管理有一定的难度,而 ISO9000 是质量管理的基本要求，只要求企业稳定组织结构,确定质量体系的要素、模式就可以贯彻实施。因此,贯彻ISO9000系列标准和推行全面质量管理之间不存在截然不同的界限,把两者结合

起来才是现代企业质量管理深化发展的方向。软件企业开展全面质量管理必须从基础工作抓起认真结合企业的实际情况和需要贯彻实施ISO 9000族标准。应该说,认证是企业实施标准的自然结果，而“先行请人捉刀,认证后再逐步实施”是本末倒置的表现。最后，企业在贯彻 ISO 9000标准、取得质量认证证书后一定不要忽视甚至丢弃全面质量管理。

7.2.3 6σ管理的特征

1.以顾客为关注焦点

2.通过提高顾客满意度和降低资源成本来促使组织的业绩提升

3.注重数据和事实,使管理成为基于数字的科学

4.以项目为驱动

5.实现对产品和流程的突破性质量改进

6.有预见地积极管理

7.无边界合作

8.追求完美并容忍失误

9.强调骨干队伍的建设

10.遵循DMAIC的改进方法

第九章 软件测试

9.1.2软件测试的原则

(1)在整个开发过程中要尽早地和不断地进行软件测试。

(2)在开始测试时不应默认程序中不存在错误。

(3)在设计测试用例时要给出测试的预期结果。

(4)测试工作应避免由系统开发人员或开发机构本身来承担

(5)对合理的和不合理的输入数据都要进行测试。

(6)重点测试错误群集的程序区段。

(7)除检查程序功能是否完备外还要检查程序功能是否有多余。

(8)用穷举测试是不可能的。

(9)长期完整地保留所有的测试用例和测试文件,直则该软件产品被废弃为止。

9.2.单元测试、集成测试、系统测试的异同

第十章 黑盒测试

10.1等价类划分

10.2边界值分析法

10.3因果图法

第十一章 白盒测试

11.2.1语句覆盖

11.2.2判定覆盖

11.2.3条件覆盖

11.2.4判定-条件覆盖

11.2.5路径覆盖

第十二章 基于缺陷模式的软件测试

12.1.1软件缺陷的产生原因

(1)程序编写错误:这是一个很常见的问题

(2)编写程序未按照规定

(3)软件越来越复杂

(4)开发人员的态度

(5)沟通上的问题

(6)需求变更太频繁

(7)进度上的压力

（8）管理上的失误

12.1.2减少缺陷的关键因素

在软件开发中减少软件缺陷有以下10个关键点，总结了软件开发中缺陷引人的规律和如何减少软件的方法策略,对于软件开发组织有宝贵的参考价值。

(1)软件在版本发布后发现和解决一个软件存在的问题所需的费用通常要比在需求和设计阶段发现、解决问题高出约100倍;

(2)当前软件项目40%~50%的费用花费在可以避免的重复工作上;

(3)大约80%的可避免的重复工作产生于20%的缺陷;

(4)大约80%的缺陷产生于20%的模块,约一半的模块缺陷是很少的;

(5)大约 90%的软件故障来自于10%的缺陷;

(6)有效的审核可以找出约60%的缺陷;

(7)有的目的性审核能够比无方向的审核多捕获约35%的缺陷;

(8)人员的专业性训练可减少高达约 75%的缺陷出现率;

(9)在同等情况下,开发高可信赖的软件产品与开发低可信赖的软件产品相比成本要高出近 50%,然而如果考虑到软件项目的运行和维护成本,投资是完全值得的;

(10)40%~50%的用户程序都包含有非常细小的缺陷。

12.1.3软件缺陷的特征

(1)缺陷的发生都是有原因的:缺陷产生的原因是客观存在的,所以无论多么难以重现和修复的缺陷，只要其发生,都是有触发原因的。

(2)缺陷的重现性(Reproducible):一个缺陷不能重现就无法进行修复。

(3)缺陷的累积性、放大性。

(4)缺陷的修复(Fixing Bug)可能又引进新的缺陷:在修复完个缺陷的时候(即解决一个问题的时候)要仔细检查这个修复会不会带来新的问题，这主要是因为代码之间的依赖关系。

12.5.1报告软件缺陷的基本原则

软件缺陷的有效描述规则主要如下。

(1)单一准确:每个报告只针对一个软件缺陷。在一个报告中,报告多个软件缺陷的弊端是经常会导致缺陷部分被注意和修复,不能得到彻底修正。

(2)可以再现:提供缺陷的精确操作步骤,使开发人员容易看懂,可以自已再现这个缺

陷,通常情况下开发人员只有再现了缺陷才能正确地修复缺陷。(3)完整统一:提供完整、前后统一的软件缺陷的步骤和信息,例如图片信息、Log 文件等。

(4)短小简练:通过使用关键词可以使软件缺陷的标题的描述短小简练,又能准确解释产生缺陷的现象，如“主页的导航栏在低分辨率下显示不整齐”中的“主页”“导航栏”“分辨

率”等是关键词。(5)特定条件:许多软件功能在通常情况下没有问题，而是在某种特定条件下会存在缺陷,所以软件缺陷描述不要忽视这些看似细节的但又必要的特定条件(如特定的操作系统、浏览器或某种设置等),它们能够提供帮助开发人员找到原因的线索;如“搜索功能在没有找到结果返回时跳转页面不对”

(6)补充完善:从发现 Bug 那一刻起,测试人员的责任就是保证它能被正确报告,并且得到应有的重视,继续监视其修复的全过程。

(7)不做评价:软件缺陷描述不要带个人观点对开发人员进行评价。软件缺陷报告是针对产品、针对问题本身,将事实或现象客观地描述出来就可以,不需要任何评价或议论。

12.6.6缺陷分析指标

缺陷发现率是将发现的缺陷数量作为时间的函数来评测，即创建缺陷趋势图。在该趋势图中,时间显示在X轴上，而在此期间发现的软件缺陷数目显示在Y轴上,图中的曲线显示发现的软件缺陷如何随着时间的推移而变化,如图 12-12 所示。

2缺陷潜伏期

测试有效性的另外一个有用的度量是缺陷潜伏期,即一种特殊类型的缺陷分布度量。

在实际测试工作中,发现缺陷的时间越晚缺陷所带来的损害就越大,修复这个缺陷所耗费的成本就越多。所以,在一项有效的测试工作中,发现缺陷的时间往往都会比一项低效的测试工作要早。表12-10显示了一个项目的缺陷潜伏期的度量。在一个实际项目中可能需要对这个度量进行适当的调整,以反映特定的软件开发生命周期的各个阶段、各个测试等级的数量、名称。例如在总体设计的评审过程中发现的需求缺陷,其阶段潜伏期可以指定为 1;如果一个缺陷在对产品进行试运行之前都没被发现,就可以将它的阶段潜伏期指定为8。

第十三章 集成测试

13.1集成测试优缺点

第十四章 系统测试

14.3系统测试的主要方法

1.性能测试

2.强度测试

3.安全性测试

4.兼容性测试

5.恢复测试

6.用户图形界面测试

7.安装测试

8.可靠性测试

9.配置测试

10.可用性测试

11.文档资料测试

12.网站测试