软件工程——软件测试的策略详解，2024年最新GitHub已标星16k-CSDN博客

本文链接：https://blog.csdn.net/2401_84254474/article/details/138005259

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新软件测试全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上软件测试知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip1024b （备注软件测试）

正文

α测试和β测试
验收测试
确认测试的结果

通常软件测试过程按4个步骤进行，即 **单元测

试、组装测试、确认测试和系统测试**。

如下图所示。

在这里插入图片描述

单元测试

===================================================================

单元测试（unit testing）又称模块测试，是针对软件设计的最小单位—程序模块，进行正确性检验的测试工作。
单元测试目的在于发现各模块内部可能存在的各种差错。单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。

单元测试的内容

单元测试主要采用白盒测试方法设计测试用例，辅之以黑盒测试的测试用例，使之对任何合理的输入和不合理的输入，都能鉴别和响应。
在单元测试中进行的测试工作如下图所示，需要在5个方面对被测模块进行检查。

在这里插入图片描述

模块接口测试。在单元测试的开始，应对通过被测模块的数据流进行测试。

对模块接口可能需要如下的测试项目：

1.调用本模块时的输入参数与模块的形式参数的匹配情况；

2.本模块调用子模块时，它输入给子模块的参数与子模块中的形式参数的匹配情况；

3.是否修改了只作输入用的形式参数；

4.全局量的定义在各模块中是否一致；

5.限制是否通过形式参数来传送。

局部数据结构测试。

模块的局部数据结构是最常见的错误来源，应设计测试用例以检查以下各种错误：

1.不正确或不一致的数据类型说明；

2.使用尚未赋值或尚未初始化的变量；

3.错误的初始值或错误的默认值；

4.变量名拼写错；

5.不一致的数据类型。

6.可能的话，除局部数据之外的全局数据对模块的影响也需要查清。

路径测试。选择适当的测试用例，对模块中重要的执行路径进行测试。应当设计测试用例查找由于错误的计算、不正确的比较或不正常的控制流而导致的错误。对基本执行路径和循环进行测试可以发现大量的路径错误。
错误处理测试。比较完善的模块设计要求能预见出错的条件，并设置适当的出错处理，以便在一旦程序出错时，能对出错程序重作安排，保证其逻辑上的正确性。

若出现下列情况之一，则表明模块的错误处理功能包含有错误或缺陷：

1.出错的描述难以理解；

2.出错的描述不足以对错误定义，不足以确定出错的原因；

3.显示的错误与实际的错误不符；

4.对错误条件的处理不正确；

5.在对错误进行处理之前，错误条件已经引起系统的干预等。

边界测试。在边界上出现错误是常见的, 要特别注意数据流、控制流中刚好等于、大于或小于确定的比较值时出错的可能性，对这些地方要仔细地选择测试用例，认真加以测试。

单元测试的步骤

通常单元测试是在编码阶段进行的。在源程序代码编制完成，经过评审和验证，肯定没有语法错误之后，就开始进行单元测试的测试用例设计。
模块并不是一个独立的程序，在考虑测试模块时，同时要考虑它和外界的联系，用一些辅助模块去模拟与被测模块相联系的其他模块。
这些辅助模块分为如下两种:

驱动模块（driver）——相当于被测模块的主程序，它接收测试数据，并把这些数据传送给被测模块，最后再输出实测结果。
桩模块（stub）——也叫做存根模块，用以代替被测

模块调用的子模块。桩模块可以做少量的数据操作，不需要把子模块所有功能都带进来，但不允许什么事情也不做。被测模块、与它相关的驱动模块及桩模块共同构成一个“测试环境”，如下图所示。

在这里插入图片描述

组装测试

===================================================================

组装测试（integrated testing）也叫做集成测试或联合测试。通常，在单元测试的基础上，需要将所有模块按照设计要求组装成为系统，

把模块组装为系统的方式有两种：一次性组装方式（big bang）和增值式组装方式。

一次性组装方式

一次性组装方式。它是一种非增值式组装方式，也叫做整体拼装。使用这种方式，首先对每个模块分别进行模块测试，然后再把所有模块组装在一起进行测试，最终得到要求的软件系统。
例如，有一个模块系统结构，如下图（a）所示，其单元测试和组装顺序（b）所示。

在这里插入图片描述

图中，模块d1，d2，d3，d4，d5是对各个模块作单

元测试时建立的驱动模块，s1，s2，s3，s4，s5是为单元测试而建立的桩模块。这种一次性组装方式试图在辅助模块的协助下，在分别完成模块单元测试的基础上，将被测模块连接起来进行测试。但是，由于程序中不可避免地存在涉及模块间接口、全局数据结构等方面的问题，所以一次试运行成功的可能性不很大。

增值式组装方式

增值式组装方式。这种组装方式又称渐增式组装，首先是对一个个模块进行模块测试，然后将这些模块逐步组装成较大的系统，在组装的过程中边连接边测试，以发现连接过程中产生的问题。最后通过增值逐步组装成为要求的软件系统。

增值组装有以下3种做法

==========================================================================

自顶向下的增值方式

自顶向下的增值方式。这种组装方式是将模块按系统程序结构，沿控制层次自顶向下进行组装，其步骤如下：

以主模块为被测模块兼驱动模块，所有直属于主模块的下属模块全部用桩模块代替，对主模块进行测试。
采用深度优先（如下图）或宽度优先的策略，逐步用实际模块替换已用过的桩模块，再用新的桩模块代替它们的直接下属模块，与已测试的模块或子系统组装成新的子系统。

在这里插入图片描述

进行回归测试（即重新执行以前做过的全部测试或部分测试），排除组装过程中引入新的错误的可能。
判断是否所有的模块都已组装到系统中，若是则结束测试，否则转到步骤2去执行。
自顶向下的组装和测试存在一个逻辑次序问题。在为了充分测试较高层的处理而需要较低层处理的信息时，就会出现这类问题。在自顶向下组装阶段，还需要用桩模块代替较低层的模块，
根据不同情况，桩模块的编写，可能如下所示的几种选择。

在这里插入图片描述