单元测试和集成测试详解，零基础入门到精通，收藏这篇就够了-优快云博客

软件测试分类

按测试用例的设计方法，软件测试分为白盒测试和黑盒测试。
按测试策略和过程，软件测试分为单元测试、集成测试、确认测试和系统测试。
按软件系统工程，测试是软件质量保证的最后的一关。

高质量的程序取决于以下几个方面：

高质量的设计
规范的编码
有效的测试

开发部的测试效果不好：为什么？

没有时间测试
不知道怎样测试
不好组织
缺乏方法和工具

这种情况下，往往把单元测试的任务堆积到系统测试阶段。

如果把单元测试的任务堆积到系统测试阶段，将会怎样？

大量的故障堆积在项目中后期：项目后10%的工作，占用了项目90%的时间。
故障难以定位
故障飘忽不定
开发、测试人员疲于奔命

软件缺陷的修复费用

单元测试（why）

最高的成本收益比
减少联调和后续测试的时间
BUG更容易定位
更有信心去修改老代码

单元测试（who）

单元测试可以是开发者本人执行，也可以是独立的专业测试人员执行。
两者各有优势。
建议开发人员必须完整地做单元测试，同时测试人员针对重点模块实施独立的单元测试。

1、单元测试的目标和任务

测试的4个阶段：单元测试----->集成测试----->系统测试----->验收测试

按阶段进行测试是一种基本的测试策略

定义: 单元测试是对软件基本组成单元进行的测试。

时机: 单元测试和编码是同步进行，但在TDD中，强调测试在先，编码在后。一般在代码完成后由开发人员完成,QA人员辅助。

概念: 模块, 组件, 单元

1.1 为何要进行单元测试?

尽早发现错误 (错误发现越早,成本越低. 发现问题比较容易修正问题更容易 )
检查代码是否符合设计和规范

为什么要进行单元测试?

1.单元测试是不是太浪费时间了？

不经过单元测试，直接进入集成测试，系统正常工作的可能性非常低，大量的时间被花费在跟踪那些简单的Bug上，会导致集成为一个系统时增加额外的工期。
编写完整计划的单元测试和编写实际的代码所花费的精力大致相同。但是，一旦完成了这些单元测试工作，很多Bug将被纠正，在确信他们手头拥有稳定可靠的部件的情况下，开发人员能够进行更高效的系统集成工作，这才是真正意义上的进步。
调试人员的不受控和散漫的工作方式只会花费更多的时间而取得很少的好处。

2.单元测试仅仅是为了证明这些代码作了什么吗？

这是那些没有首先为每个单元编写一个详细设计文档而直接跳到编码阶段的开发人员提出的一条普遍的抱怨。这样的测试完全基于已经写好的代码，这无法证明任何事情。
单元测试基于详细设计文档，这样的测试可以找到更多的代码错误，甚至是详细设计的错误。
因此，高质量的单元测试需要高质量的详细设计文档。

3.我是一个很棒的程序员，是不是可以不进行单元测试呢？

每个人都可能犯错误。
真正的完整的系统往往是非常复杂的，不能寄希望于没有进行广泛的测试和Bug修改过程就可以正常工作。

4.有集成测试就够了，集成测试将会抓住所有的Bug。

系统规模愈来愈大，复杂度愈来愈高，没有单元测试，开发人员很可能会花费大量的时间仅仅是为了使该系统能够运行。
任何实际的测试方案都无法执行。
在系统集成阶段，对单元功能全面测试的负载程度远远的超过独立进行的单元测试过程。
最后的结果是测试将无法达到它所应该有的全面性，一些缺陷将被遗漏，并且很多Bug将被忽略过去。

5.单元测试的成本效率不高？

无论什么时候做出修改都要进行完整的回归测试。
在生命周期中尽早的对产品进行测试将使效率和质量得到最好的保证
Bug修改越晚，费用就越高，单元测试是一个在早期抓住Bug的机会。
相比后阶段的测试，单元测试的创建更简单，维护更容易，并且可以更方便的进行重复。
从全程的测试费用来考虑，相比复杂且旷日持久的集成测试，或是不稳定的系统，单元测试所需的费用是最低的。

单元测试的重要性

一个尽责的单元测试方法将会在产品开发的某个阶段发现很多的Bug，并且修改它们的成本也很低。
系统开发的后期阶段，Bug的检测和修改将会变得更加困难，并要消耗大量的时间和开发费用。
无论什么时候做出修改都要进行完整的回归测试，在生命周期中尽早的对产品代码进行测试将是效率和质量得到最好的保证。
在提供了经过单元测试的情况下，系统集成过程将会大大的简化。开发人员可以将精力集中在单元之间的交互作用和全局的功能实现上，而不会陷入充满很多Bug的单元之中不能自拔。
使测试工作的效率发挥到最大化的关键在于选择正确的测试策略，这包含了完全的单元测试的概念，以及对测试过程的良好的管理，还有适当的使用好工具来支持测试过程。

单元测试的背景

开发流程时间表与修改Bug代价的关系图

编程过程中，每写1000行代码会犯几十个错误
编程与编译运行结束后，每1000行代码中大约残留有2-6个Bug
寻找与修改程序错误的代价占总体开发投资的30% -60%
Bug在整个研发流程中被发现的越早，修改的代价就越低

单元测试是什么？

单元测试，对单个的软件单元或者一组相关的软件单元所进行的测试，是代码级的测试。

Unit：函数，源代码文件，类

把测试比作是清洗一台机器：

系统测试就是清除机器外面的尘土。
集成测试就是保证机器各个部件的接头处干净。
单元测试就是清洗各个零件的内部。

单元测试原则

应该尽早地进行软件单元测试。
应该保证单元测试的可重复性。
尽可能地采用测试自动化的手段来支持单元测试活动。

1.2 单元测试的目标和要求

目标: 单元模块被正确编码

信息能否正确地流入和流出单元；
在单元工作过程中，其内部数据能否保持其完整性，包括内部数据的形式、内容及相互关系不发生错误，也包括全局变量在单元中的处理和影响。
在为限制数据加工而设置的边界处，能否正确工作。
单元的运行能否做到满足特定的逻辑覆盖。
单元中发生了错误，其中的出错处理措施是否有效。
指针是否被错误引用、资源是否及时被释放。
有没有安全隐患？是否使用了不恰当的字符串处理函数等。

单元测试的一系列活动:

建立单元测试环境，包括在集成开发环境中安装和设置单元测试工具（插件）；
测试脚本（测试代码）的开发和调试；
测试执行及其结果分析。

单元测试的主要内容:

目标：确保模块被正确地编码。
依据：详细设计描述。
过程：经过设计、脚本开发、执行、调试和分析结果等环节。
执行者：由程序开发人员和测试人员共同完成。
采用那些测试方法：包括代码控制流和数据流分析方法，并结合参数输入域的测试方法。
测试脚本的管理：可以按照产品代码管理的方法进行类似的配置（并入代码库），包括代码评审、版本分支、变更控制等。
如何进行评估：通过代码覆盖率分析工具来分析测试的代码覆盖率、分支或条件的覆盖率。

单元测试的一般准则:

软件单元功能与设计需求一致。
软件单元接口与设计需求一致。
能够正确处理输入和运行中的错误。
在单元测试中发现的错误已经得到修改并且通过了测试。
达成了相关的覆盖率的要求。完成软件单元测试报告。

任务１：模块独立执行通路测试

检查每一条独立执行路径的测试。保证每条语句被至少执行一次。

Checklist:

误解或用错了算符优先级。
混合类型运算。
变量初始化错误、赋值错误。
错误计算或精度不够。
表达式符号错等。

任务2：模块局部数据结构测试

检查局部数据结构完整性

Checklist:

不适合或不相容的类型说明。
变量无初值。
变量初始化或缺省值有错。
不正确的变量名或从来未被使用过。
出现上溢或下溢和地址异常。

任务３：模块接口测试

检查模块接口是否正确

checklist:

输入的实际参数与形式参数是否一致。 (个数、属性、量纲)
调用其他模块的实际参数与被调模块的形参是否一致。 (个数、属性、量纲)
调用预定义函数时所用参数的个数、属性和次序是否正确
全程变量的定义在各模块是否一致。
外部输入、输出 ( 文件、缓冲区、错误处理 )

任务４：模块边界条件测试

检查临界数据处理的正确性

Checklist:

普通合法数据的处理。
普通非法数据的处理。
边界值内合法边界数据的处理。
边界值外非法边界数据的处理。
其它

任务5：模块的各条错误处理通路测试

预见、预设的各种出错处理是否正确有效。

Checklist:

输出的出错信息难以理解。
记录的错误与实际遇到的错误不相符。
在程序自定义的出错处理代码运行之前，系统已介入。
异常处理不当。
错误陈述中未提供足够的定位出错的信息。

2、静态测试

静态测试技术：不运行被测试程序，对代码通过检查、阅读进行分析。

三步曲：走查（Walk Through）审查（Inspection）评审（Review）

2.1 编码的标准和规范

标准：建立起来必须遵守的规则
规范：建议最佳做法，推荐更好方式

实施代码规范的原因：可靠性可读性和可维护性可移植性

2.2 代码评审

一次检查少于200～400行代码
努力达到一个合适的检查速度：300～500LOC/hour
有足够的时间、以适当的速度、仔细地检查，但不宜超过60～90分钟
在审查前，代码作者应该对代码进行注释
使用检查表（checklist）肯定能改进双方（作者和复审者）的结果
验证缺陷是否真正被修复

1.代码走查（Walk Through）

定义：采用讲解、讨论和模拟运行的方式进行的查找错误的活动。

注意：

引导小组成员在走查前通读设计和编码。
限时，避免跑题。
发现问题适当记录，避免现场修改。
检查要点是代码是否符合标准和规范，是否有逻辑错误。

2.正式会议审查（Inspection）

定义：采用讲解、提问方式进行，一般有正式的计划、流程和结果。主要方法采用缺陷检查表。

注意：

以会议形式，制定会议目标、流程和规则，结束后要编写报告。
按缺陷检查表逐项检查。
发现问题适当记录，避免现场修改。
发现重大缺陷，改正后会议需要重开。
检查要点是缺陷检查表，所以该表要根据项目不同不断积累完善。

走查与审查的比较

	走查	审查
准备	通读设计和编码	应准备好需求描述文档、程序设计文档、程序的源代码清单、代码编码标准和代码缺陷检查表
形式	非正式会议	正式会议
参加人员	开发人员为主	项目组成员包括测试人员
主要技术方法	无	缺陷检查表
注意事项	限时、不要现场修改代码	限时、不要现场修改代码
生成文档	会议记录	静态分析错误报告
目标	代码标准规范，无逻辑错误	代码标准规范，无逻辑错误

3.评审（Review）

定义：通常在审查会后进行，审查小组根据记录和报告进行评估。

注意：

充分审查了所规定的代码，并且全部编码准则被遵守。
审查中发现的错误已全部修改。

3 、动态测试

动态测试需要真正将程序运行起来，需要设计系列的测试用例保证测试的完整性和有效性。

白盒测试黑盒（灰盒）测试

驱动程序和桩程序

运行单元程序有时需要基于被测单元的接口，开发相应的驱动模块和桩模块。

驱动模块（drive）:对底层或子层模块进行测试所编写的调用这些模块的程序。
桩模块（stub）：对顶层或上层模块进行测试时所编写的替代下层模块的程序。

单元测试设计

单元测试模型的设计。
测试项目的设计。

（1）单元测试模型设计

构造最小运行调度系统，即驱动模块，用于模拟被测模块的上一级模块。
模拟实现单元接口，即单元函数需调用的其他函数接口，即桩模块。
模拟生成测试数据或状态，为单元运行准备动态环境。
对测试过程的支持，对测试结果的保留，对测试覆盖率的记录等。

单元测试环境的示意图如下：

（2）测试项目设计

测试项目是测试用例的一个总则，主要是根据测试需求设计测试点，不包含具体实践的用例。

在测试项目的设计中，主要从功能覆盖和代码覆盖两个角度进行考虑。

       功能覆盖属黑盒的范畴，用来指出测试用例是否已经覆盖了程序应该提供的功能。逻辑覆盖率是考核单元测试质量的一个关键指标。

        代码覆盖也称逻辑覆盖，包括语句覆盖、分支覆盖、路径覆盖，是一种常用的白盒测试方法。

覆盖率指标：核心代码覆盖率达到100%，共享资源库的代码覆盖率达到100%，非核心代码覆盖率达到90%。

4、调试与评估

调试与测试的对象及采用的方法有很大程度上的相似，调试还用到断点控制等排错方法，但其目的却完全不同。测试是为了找出软件中存在的缺陷，而调试是为了解决存在的缺陷。

软件单元功能与设计需求一致。
软件单元接口与设计需求一致。
能够正确处理输入和运行中的错误。
在单元测试中发现的错误已经得到修改并且通过了测试。
达到了相关的覆盖率的要求。
完成软件单元测试报告

5、单元测试的管理

过程:

在详细设计阶段完成单元测试计划。
建立单元测试环境，完成测试设计和开发。
执行单元测试用例，并且详细记录测试结果。
判定测试用例是否通过。
提交《单元测试报告》。

单元测试的文档

《软件需求规格说明书》、《软件详细设计说明书》 -----> 《单元测试计划》
《单元测试计划》、《软件详细设计说明书》-----> 《单元测试用例》
《单元测试用例》文档及《软件需求规格说明书》、《软件详细设计说明书》-----> 《缺陷跟踪报告》/《缺陷检查表》
《单元测试用例》、《缺陷跟踪报告》、《缺陷检查表》-----> 《单元测试检查表》
评估-----> 单元测试报告》

7、系统集成的模式与方法

集成测试定义

定义

集成测试又称“组装测试”、“联合测试”。集成测试遵循特定的策略和步骤将已经通过单元测试的各个软件单元（或模块）逐步组合在一起进行测试，以期望通过测试发现各软件单元接口之间存在的问题。

集成测试对象

理论上凡是两个单元（如函数单元）的组合测试都可以叫做集成测试。实际操作中，通常集成测试的对象为模块级的集成和子系统间的集成，其中子系统集成测试称为组件测试。

集成测试目的与意义

考虑以下问题：

在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失；
各个子功能组合起来，能否达到预期要求的总体功能；
一个模块的功能是否会对另一个模块的功能产生不利的影响；
全局数据结构是否有问题单个模块的误差积累起来，是否会放大，从而达到不可接受的程度。
共享资源访问的测试 ( 要想发现并排除在模块连接中可能发生的上述问题，就需要进行集成测试。)

集成测试有以下不可替代的特点：

单元测试具有不彻底性，对于模块间接口信息内容的正确性、相互调用关系是否符合设计无能为力。只能靠集成测试来进行保障。
同系统测试相比，由于集成测试用例是从程序结构出发的，目的性、针对性更强，测试项发现问题的效率更高，定位问题的效率也较高；
定位问题较快，发现问题后比较容易定位，所以能够有效地加快进度，减少隐患。

集成测试（when)

在开始体系结构设计的时候开始制定测试方案；
在进入详细设计之前完成集成测试方案；
在进入系统测试之前结束集成测试。

集成测试（who)

集成测试可以在开发部进行，也可以由独立的测试部执行。
开发部尽量进行集成测试，测试部有选择地进行集成测试。

集成测试原则

集成测试是产品研发中的重要工作，需要为其分配足够的资源和时间。
集成测试需要经过严密的计划，并严格按计划执行。
应采取增量式的分步集成方式，逐步进行软件部件的集成和测试。
应重视测试自动化技术的引入与应用，不断提高集成测试效率。
应该注意测试用例的积累和管理，方便进行回归并进行测试用例补充。

集成测试内容

集成功能测试
接口测试
全局数据结构测试
资源测试
任务优先级冲突测试
性能和稳定性测试

集成测试、单元测试与系统测试的差别

测试类型	对象	目的	测试依据	测试方法
单元测试	模块内部的程序错误	消除局部模块的逻辑和功能上的错误和缺陷	模块逻辑设计，模块外部说明	大量采用白盒测试方法
集成测试	模块间的集成和调用关系	找出与软件设计相关的程序结构，模块调用关系，模块间接口方面的问题	程序结构设计	结合使用白盒与黑和测试方法，采用较多黑盒方法构造测试用例
系统测试	整个系统，包括系统中的硬件等	对整个系统进行一系列的整体、有效性测试	系统结构设计，目标说明书，需求说明书等	黑盒测试

由以上可以看出，整个软件系统的测试过程是：先对各个软件模块进行单元测试，然后把经过单元测试的各个模块组装起来进行集成测试，最后把经过集成测试的子系统合成软件版本，对照需求规格，在实际环境下，进行系统功能验证。

7.1 集成测试前的准备

人员安排、测试计划、测试内容、集成模式、测试方法

7.2 集成测试的模式

渐增式测试模式与非渐增式测试模式：

非渐增式测试模式：先分别测试每个模块，再把所有模块按设计要求放在一起结合成所要的程序，如大棒模式。
渐增式测试模式：把下一个要测试的模块同已经测试好的模块结合起来进行测试，测试完以后再把下一个应该测试的模块结合进来测试。

各自的优缺点：

非渐增式测试模式优缺点：工作量较小；发现模块间接口错误较晚；发现错误较难诊断，可以并行测试。
渐增式测试模式优缺点：要编写的软件较多，工作量较大；发现模块间接口错误较早；测试执行更彻底；需要较多的机器时间。

7.3 大棒集成方法(Big-bang Integration)

采用大棒集成方法，先是对每一个子模块进行测试（单元测试阶段），然后将所有模块一次性的全部集成起来进行集成测试。

因为所有的模块一次集成的，所以很难确定出错的真正位置、所在的模块、错误的原因。这种方法并不推荐在任何系统中使用，适合在规模较小的应用系统中使用。

非增量式集成测试实例

评述：模块d1、d2、d3、d4、d5是对各个模块做单元测试时建立的驱动模块，s1、s2、s3、s4、s5是为单元测试而建立的桩模块。这种一次性集成方式将所测模块连接起来进行测试，但是一次试运行成功地可能性并不大。其结果发现有错误，但茫然找不到原因，差错和改错都会遇到困难。

适应于一个维护型或被测试系统较小的项目。

非增量式策略——优缺点:

优点： ①方法简单 ②允许多测试人员同时并行工作，人力物力资源利用率较高
缺点： ①必须为每个模块准备相应的驱动模块和桩模块，测试成本较高 ②一旦集成后包含多种错误，难以纠正。

7.4 自顶向下和自底向上集成方法

驱动程序/驱动模块（driver），用以模拟被测模块的上级模块。驱动模块在集成测试中接受测试数据，把相关的数据传送给被测模块，启动被测模块，并打印出相应的结果。

桩程序/桩模块（stub），也有人称为存根程序，用以模拟被测模块工作过程中所调用的模块。桩模块由被测模块调用，它们一般只进行很少的数据处理，例如打印入口和返回，以便于检验被测模块与其下级模块的接口。

1.自顶向下法(Top-down Integration)

自顶向下法，从主控模块(主程序)开始，沿着软件的控制层次向下移动，逐渐把各个模块结合起来。

组装过程可以采用深度优先策略和宽度优先策略

深度优先：从最顶层单元开始，持续向下到下一层，选择一个分支，自顶而下一个一个的集成这条分支上的所有单元，直到最底层，然后转向另一个分支，重复这样的集成操作直到所有的单元都集成进来。
广度优先：从最顶层单元开始，持续向下到下一层，一个个完成下一层上所有单元集成后，再转向下面一层，重复这样的集成操作直到所有的单元都集成进来。

自顶向下增量测试

自顶向下集成测试的整个过程由3个步骤完成：

主控模块作为测试驱动器。
根据集成的方式（深度或广度），下层的桩模块一次一次地被替换为真正的模块。
在每个模块被集成时，都必须进行单元测试。重复第2步，直到整个系统被测试完成。

深度优先组装方式:

广度优先组装方式:

自顶向下法——优缺点

优点：

不需要测试驱动程序；

能够在测试阶段的早期实现并验证系统的主要功能；

能在早期发现上层模块中的接口错误。

缺点：

需要桩程序，要使桩模块能够模拟实际子模块的功能十分困难；

底层验证被推迟；同时涉及复杂算法，真正输入/输出的模块一般在底层，

他们是最容易出问题的模块，到测试和集成的后期才遇到这些模块，一旦发现问题导致过多的回归测试。

自顶向下增量式集成适用范围：

产品控制结构比较清晰和稳定；
高层接口变化较小；
底层接口未定义或经常可能被修改；
产口控制组件具有较大的技术风险，需要尽早被验证；
希望尽早能看到产品的系统功能行为。

练习：

（1）对如下结构采用自顶向下深度优先策略进行测试

（2）一个按广度优先测试进行集成测试

首先，对顶层的模块A进行单元测试，这时需配以被调用子模块s1、s2、s3，以模拟被它调用的模块B、C和D。
其后，把模块B、C和D与顶层模块A连接起来，再对模块B和D配以被调用模拟子模块s4和s5以模拟对模块E和F的调用。
最后，去掉被调用模拟子模块s4和s5，把模块E和F集成后再对软件完整的结构进行测试。

2.自底向上法(Bottom-up Integration)

自底向上法，测试从原子模块(软件结构最底层的模块)开始集成以进行测试。自底向上进行集成和测试时，需要为所测模块或子系统编制相应的驱动模块。

自底向上增量式集成测试步骤：

起始于模块依赖关系树的底层叶子模块，也可以把两个或多个叶子模块合并到一起进行测试
使用驱动模块对步骤１选定的模块（或模块组）进行测试
用实际模块代替驱动模块，与它已测试的直属子模块组装成一个更大的模块进行测试
重复上面的行为，直到系统最顶层模块被加入到已测系统中

自底向上增量式测试

一个自底向上增量式集成测试的典型例子

首先，(a)、(b)、©表示树状结构图中处于最下层的叶结点模块E、C和F，由于它们不再调用其他模块，对它们进行单元测试时，只需配以驱动模块d1、d2和d3，用来模拟B、A和D对它们的调用。
完成这3个单元测试后，再按(d)和(e)的形式，分别将模块B和E及模块D和F连接起来，再配以驱动模块d4和d5实施部分集成测试。
最后按图(f)的形式完成整体的集成测试。

自底向上法——优缺点

与自顶向下法刚好相反。

优点：

不需要桩程序；
同时由于涉及到复杂算法和真正输入/输出的模块最先得到集成和测试，可以把最容易出问题的部分在早期解决；
自底向上增值的方式可以实施多个模块的并行测试，提高测试效率。

缺点：

“程序一直未能作为一个实体存在，直到最后一个模块加上去后才形成一个实体”。也就是说，在自底向上集成和测试的过程中，对主要的控制直到最后才接触到。
驱动的开发工作量大；

自底向上增量式集成适用范围：

适用范围：

适应于底层接口比较稳定；
高层接口变化比较频繁；
底层组件较早被完成。

3.混合策略(Modified Top-down Integration)

混合法：对软件结构中较上层，使用的是“自顶向下”法；对软件结构中较下层，使用的是“自底向上”法，两者相结合。

7.5 三明治集成方法(Sandwich Integration)

混合式集成
把系统划分成三层，中间一层为目标层，目标层之上采用自顶向下集成，之下采用自底向上集成

三明治集成策略

集成步骤

首先对目标层之上一层使用自顶向下集成，因此测试A，使用桩代替B，C，D
其次对目标层之下一层使用自底向上集成，因此测试E，F，使用驱动代替B，D
其三，把目标层下面一层与目标层集成，因此测试（B，E），（D，F），使用驱动代替A
最后，把三层集成到一起，因此测试（A，B，C，D，E，F）

优缺点分析

优点：集合了自顶向下和自底向上两种策略的优点

缺点：中间层测试不充分，在真正集成之前每一个独立的模块没有完全测试过。

适用范围：适应于大部分软件开发项目

改善的三明治集成方法

改进的三明治集成方法，不仅自两头向中间集成，而且保证每个模块得到单独的测试，使测试进行得比较彻底。

集成策略框图

几种集成方法性能的比较

	自底向上	自顶向下	混合策略	大棒	三明治	改进三明治
集成	早	早	早	晚	早	早
基本程序能工作时间	晚	早	早	晚	早	早
需要驱动程序	是	否	是	是	是	是
需要桩程序	否	是	是	是	是	是
工作并行性	中	低	中	高	中	高
特殊路径测试	容易	难	容易	容易	中等	容易
计划与控制	容易	难	难	容易	难	难

集成策略选择

7.6 持续集成

通常系统集成都会采用持续集成的策略，软件开发中各个模块不是同时完成，根据进度将完成的模块尽可能早的进行集成，有助于尽早发现Bug，避免集成中大量Bug涌现。
而且容易定位Bug、修正Bug，最终提高软件开发的质量与效率。

7.7 集成测试流程

集成测试主要由系统部的系统设计人员、软件评测部完成，开发人员也参与集成测试。集成测试相对来说是挺复杂的，而且对于不同的技术、平台和应用差异也比较大，更多是和开发环境融合在一起。集成测试所确定的测试的内容，主要来源于设计模型。

集成测试流程

（1）集成测试计划

输入 :需求规格说明书、概要设计文档、产品开发计划路标

输出：集成测试计划

活动步骤

确定被测试对象和测试范围
评估集成测试被测试对象的数量及难度，即工作量
确定角色分工和划分工作任务
标识出测试各阶段的时间、任务、约束等条件
考虑一定的风险分析及应急计划
考虑和准备集成测试需要的测试工具、测试仪器、环境等资源
考虑外部技术支援的力度和深度，以及相关培训安排
定义测试完成标准

（2）集成测试分析和设计

集成测试分析和设计的主要目的是制定测试大纲（测试方案）。集成测试大纲规定了今后的集成测试内容、测试方法以及可测性接口，以后所有集成测试均在该大纲的框架下进行，所以，制定一份完善的集成测试大纲非常重要。

输入：需求规格说明书概要设计集成测试计划

输出：集成测试设计方案

活动步骤

被测对象结构分析
集成测试模块分析
集成测试接口分析
集成测试策略分析
集成测试工具分析
集成测试环境分析
集成测试工作量估计和安排

（3）实施阶段

输入：需求规格说明书概要设计集成测试计划集成测试设计

输出：集成测试用例集成测试规程集成测试代码、集成测试脚本、集成测试工具（如果有）

活动步骤

集成测试用例设计
集成测试规程设计
集成测试代码设计（如果需要）
集成测试脚本（如果需要）
集成测试工具（如果需要）

（4）执行阶段

输入

需求规格说明书
概要设计
集成测试计划
集成测试设计
集成测试用例
集成测试规程
集成测试代码（如果有）
集成测试脚本（如果有）
集成测试工具（如果有）
详细设计
代码
单元测试报告

输出

集成测试报告

活动步骤

执行集成测试用例
回归集成测试用例
撰写集成测试报告

相应过程的测试文档

这两年，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 夺旗赛解析等内容，结合运维中企业安全防护需求深化理解。