软件质量保证与测试，零基础入门到精通，收藏这篇就够了

第一章 概述

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.网站测试

这两年，IT行业面临经济周期波动与AI产业结构调整的双重压力，确实有很多运维与网络工程师因企业缩编或技术迭代而暂时失业。

很多人都在提运维网工失业后就只能去跑滴滴送外卖了，但我想分享的是，对于运维人员来说，即便失业以后仍然有很多副业可以尝试。

运维副业方向

运维，千万不要再错过这些副业机会！

第一个是知识付费类副业：输出经验打造个人IP

在线教育平台讲师

操作路径：在慕课网、极客时间等平台开设《CCNA实战》《Linux运维从入门到精通》等课程，或与培训机构合作录制专题课。
收益模式：课程销售分成、企业内训。

技术博客与公众号运营

操作路径：撰写网络协议解析、故障排查案例、设备评测等深度文章，通过公众号广告、付费专栏及企业合作变现。
收益关键：每周更新2-3篇原创，结合SEO优化与社群运营。

第二个是技术类副业：深耕专业领域变现

企业网络设备配置与优化服务

操作路径：为中小型企业提供路由器、交换机、防火墙等设备的配置调试、性能优化及故障排查服务。可通过本地IT服务公司合作或自建线上接单平台获客。
收益模式：按项目收费或签订年度维护合同。

远程IT基础设施代维

操作路径：通过承接服务器监控、日志分析、备份恢复等远程代维任务。适合熟悉Zabbix、ELK等技术栈的工程师。
收益模式：按工时计费或包月服务。

网络安全顾问与渗透测试

操作路径：利用OWASP Top 10漏洞分析、Nmap/BurpSuite等工具，为企业提供漏洞扫描、渗透测试及安全加固方案。需考取CISP等认证提升资质。
收益模式：单次渗透测试报告收费；长期安全顾问年费。

比如不久前跟我一起聊天的一个粉丝，他自己之前是大四实习的时候做的运维，发现运维7*24小时待命受不了，就准备转网安，学了差不多2个月，然后开始挖漏洞，光是补天的漏洞奖励也有个四五千，他说自己每个月的房租和饭钱就够了。

为什么我会推荐你网安是运维人员的绝佳副业&转型方向?

1.你的经验是巨大优势: 你比任何人都懂系统、网络和架构。漏洞挖掘、内网渗透、应急响应，这些核心安全能力本质上是“攻击视角下的运维”。你的运维背景不是从零开始，而是降维打击。

2.越老越吃香，规避年龄危机: 安全行业极度依赖经验。你的排查思路、风险意识和对复杂系统的理解能力，会随着项目积累而愈发珍贵，真正做到“姜还是老的辣”。

3.职业选择极其灵活: 你可以加入企业成为安全专家，可以兼职“挖洞“获取丰厚奖金，甚至可以成为自由顾问。这种多样性为你提供了前所未有的抗风险能力。

4.市场需求爆发，前景广阔: 在国家级政策的推动下，从一线城市到二三线地区，安全人才缺口正在急剧扩大。现在布局，正是抢占未来先机的黄金时刻。

运维转行学习路线

（一）第一阶段：网络安全筑基

1. 阶段目标

你已经有运维经验了，所以操作系统、网络协议这些你不是零基础。但要学安全，得重新过一遍——只不过这次我们是带着“安全视角”去学。

2. 学习内容

**操作系统强化：**你需要重点学习 Windows、Linux 操作系统安全配置，对比运维工作中常规配置与安全配置的差异，深化系统安全认知（比如说日志审计配置，为应急响应日志分析打基础）。

**网络协议深化：**结合过往网络协议应用经验，聚焦 TCP/IP 协议簇中的安全漏洞及防护机制，如 ARP 欺骗、TCP 三次握手漏洞等（为 SRC 漏扫中协议层漏洞识别铺垫）。

**Web 与数据库基础：**补充 Web 架构、HTTP 协议及 MySQL、SQL Server 等数据库安全相关知识，了解 Web 应用与数据库在网安中的作用。

**编程语言入门：**学习 Python 基础语法，掌握简单脚本编写，为后续 SRC 漏扫自动化脚本开发及应急响应工具使用打基础。

**工具实战：**集中训练抓包工具（Wireshark）、渗透测试工具（Nmap）、漏洞扫描工具（Nessus 基础版）的使用，结合模拟场景练习工具应用（掌握基础扫描逻辑，为 SRC 漏扫工具进阶做准备）。

（二）第二阶段：漏洞挖掘与 SRC 漏扫实战

1. 阶段目标

这阶段是真正开始“动手”了。信息收集、漏洞分析、工具联动，一样不能少。

熟练运用漏洞挖掘及 SRC 漏扫工具，具备独立挖掘常见漏洞及 SRC 平台漏扫实战能力，尝试通过 SRC 挖洞搞钱，不管是低危漏洞还是高危漏洞，先挖到一个。

2. 学习内容

信息收集实战：结合运维中对网络拓扑、设备信息的了解，强化基本信息收集、网络空间搜索引擎（Shodan、ZoomEye）、域名及端口信息收集技巧，针对企业级网络场景开展信息收集练习（为 SRC 漏扫目标筛选提供支撑）。

漏洞原理与分析：深入学习 SQL 注入、CSRF、文件上传等常见漏洞的原理、危害及利用方法，结合运维工作中遇到的类似问题进行关联分析（明确 SRC 漏扫重点漏洞类型）。

工具进阶与 SRC 漏扫应用：

• 系统学习 SQLMap、BurpSuite、AWVS 等工具的高级功能，开展工具联用实战训练；

• 专项学习 SRC 漏扫流程：包括 SRC 平台规则解读（如漏洞提交规范、奖励机制）、漏扫目标范围界定、漏扫策略制定（全量扫描 vs 定向扫描）、漏扫结果验证与复现；

• 实战训练：使用 AWVS+BurpSuite 组合开展 SRC 平台目标漏扫，练习 “扫描 - 验证 - 漏洞报告撰写 - 平台提交” 全流程。
  SRC 实战演练：选择合适的 SRC 平台（如补天、CNVD）进行漏洞挖掘与漏扫实战，积累实战经验，尝试获取挖洞收益。

恭喜你，如果学到这里，你基本可以下班搞搞副业创收了，并且具备渗透测试工程师必备的「渗透技巧」、「溯源能力」，让你在黑客盛行的年代别背锅，工作实现升职加薪的同时也能开创副业创收！

如果你想要入坑黑客&网络安全，笔者给大家准备了一份：全网最全的网络安全资料包需要保存下方图片，微信扫码即可前往获取!

因篇幅有限，仅展示部分资料，需要点击下方链接即可前往获取

优快云大礼包：《黑客&网络安全入门&进阶学习资源包》免费分享

（三）第三阶段：渗透测试技能学习

1. 阶段目标

全面掌握渗透测试理论与实战技能，能够独立完成渗透测试项目，编写规范的渗透测试报告，具备渗透测试工程师岗位能力，为护网红蓝对抗及应急响应提供技术支撑。

2. 学习内容

渗透测试核心理论：系统学习渗透测试流程、方法论及法律法规知识，明确渗透测试边界与规范（与红蓝对抗攻击边界要求一致）。

实战技能训练：开展漏洞扫描、漏洞利用、电商系统渗透测试、内网渗透、权限提升（Windows、Linux）、代码审计等实战训练，结合运维中熟悉的系统环境设计测试场景（强化红蓝对抗攻击端技术能力）。

工具开发实践：基于 Python 编程基础，学习渗透测试工具开发技巧，开发简单的自动化测试脚本（可拓展用于 SRC 漏扫自动化及应急响应辅助工具）。

报告编写指导：学习渗透测试报告的结构与编写规范，完成多个不同场景的渗透测试报告撰写练习（与 SRC 漏洞报告、应急响应报告撰写逻辑互通）。

（四）第四阶段：企业级安全攻防（含红蓝对抗）、应急响应

1. 阶段目标

掌握企业级安全攻防、护网红蓝对抗及应急响应核心技能，考取网安行业相关证书。

2. 学习内容

护网红蓝对抗专项：

• 红蓝对抗基础：学习护网行动背景、红蓝对抗规则（攻击范围、禁止行为）、红蓝双方角色职责（红队：模拟攻击；蓝队：防御检测与应急处置）；

• 红队实战技能：强化内网渗透、横向移动、权限维持、免杀攻击等高级技巧，模拟护网中常见攻击场景；

• 蓝队实战技能：学习安全设备（防火墙、IDS/IPS、WAF）联动防御配置、安全监控平台（SOC）使用、攻击行为研判与溯源方法；

• 模拟护网演练：参与团队式红蓝对抗演练，完整体验 “攻击 - 检测 - 防御 - 处置” 全流程。
  应急响应专项：

• 应急响应流程：学习应急响应 6 步流程（准备 - 检测 - 遏制 - 根除 - 恢复 - 总结），掌握各环节核心任务；

• 实战技能：开展操作系统入侵响应（如病毒木马清除、异常进程终止）、数据泄露应急处置、漏洞应急修补等实战训练；

• 工具应用：学习应急响应工具（如 Autoruns、Process Monitor、病毒分析工具）的使用，提升处置效率；

• 案例复盘：分析真实网络安全事件应急响应案例（如勒索病毒事件），总结处置经验。
  其他企业级攻防技能：学习社工与钓鱼、CTF 夺旗赛解析等内容，结合运维中企业安全防护需求深化理解。

证书备考：针对网安行业相关证书考试内容（含红蓝对抗、应急响应考点）进行专项复习，参加模拟考试，查漏补缺。

运维转行网络攻防知识库分享

网络安全这行，不是会几个工具就能搞定的。你得有体系，懂原理，能实战。尤其是从运维转过来的，别浪费你原来的经验——你比纯新人强多了。

但也要沉得住气，别学了两天Web安全就觉得自己是黑客了。内网、域渗透、代码审计、应急响应，要学的还多着呢。

如果你真的想转，按这个路子一步步走，没问题。如果你只是好奇，我劝你再想想——这行要持续学习，挺累的，但也是真有意思。

关于如何学习网络安全，笔者也给大家整理好了全套网络安全知识库，需要的可以扫码获取！

因篇幅有限，仅展示部分资料，需要点击下方链接即可前往获取

优快云大礼包：《黑客&网络安全入门&进阶学习资源包》免费分享

1、网络安全意识

2、Linux操作系统

3、WEB架构基础与HTTP协议

4、Web渗透测试

5、渗透测试案例分享

6、渗透测试实战技巧

7、攻防对战实战

8、CTF之MISC实战讲解

关于如何学习网络安全，笔者也给大家整理好了全套网络安全知识库，需要的可以扫码获取！

因篇幅有限，仅展示部分资料，需要点击下方链接即可前往获取

优快云大礼包：《黑客&网络安全入门&进阶学习资源包》免费分享