未来软件测试的5个主要趋势以及软件测试进阶路线_软件测试未来规划

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

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

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

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

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

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

正文

在过去的一年里，有很多关于数字转型的讨论和文章。企业正在经历巨大的数字化变革，这也带来了许多不安全感和挑战。使用诸如Agile和DevOps之类的方法，测试过程变得更加灵活，并且能够响应业务需求。

然而，随着新特性必须以渐进的模式交付，这将增强在启动和运行的应用程序中持续部署和集成的需要。业务转换每天都会遇到新的挑战，这些挑战可能与性能、安全性或功能相关。因此，随着时间的推移，对持续开发和集成的需求只会不断增加。

3、测试数据在业务中的有效应用

正如业务专家和技术极客所预估的那样，数据将增强测试人员的业务决策能力，并使有效的决策能力成为可能。而更重要的是测试数据，它可以确保推导出的推论是准确的，并以一种容易理解的形式去传递。测试人员需要验证TB级别的数据是否得到了有效的处理，并被分解为精确的集群，以获得所需的推论。

这种测试数据可以应用到性能测试、功能测试，甚至是安全测试。在大数据测试中，保证数据的质量是非常关键的，大数据测试可以从精度、准确性、一致性、重复性等特征入手进行验证。

4、测试智能应用程序

根据ResearchAndMarkets的一份报告，“全球智能应用市场在2017年是83.9亿美元，预计到2026年将达到934亿美元，在预测期间的复合年增长率为30.7%。”对先进分析工具的日益渴望，部署新产品技术的进步，以及大数据和分析市场的提升，正在推动智能应用的发展。发展中经济体的接受程度加深为市场扩张提供了重大机遇。

这份报告总结了智能应用的需求，我们可以从未来的趋势中评估，测试需求只会增加。对这些应用程序的准确性、性能、安全性、功能以及任何基于需求的东西进行有效测试的需求也正在增长。

5、性能工程，而不仅仅是性能测试

确保你的应用程序或软件在不断变化或具有挑战性的条件下按预期工作始终是需要考虑的一个重要因素。性能测试一直是软件测试的一个关键方面，随着趋势的发展，性能测试将最终转向性能工程。重点将主要集中在所有能够确保性能、安全性、可用性、网络兼容性等的因素上，而这些因素都必须致力于交付高质量的应用程序，以满足客户日益增长的需求。

即使在未来几年，软件测试的需求和作用也只会越来越突出，技术和数字环境方面的挑战必将进一步增加。因此，对软件测试和质量保证的需求在这些变化的环境中保持相关性同样重要。

软件测试学习路线

学习规划图：正在学习测试的小伙伴可以通过点击下面的小卡片
https://jq.qq.com/?_wv=1027&k=3T9tmL0thttps://jq.qq.com/?_wv=1027&k=3T9tmL0t

一、测试与软件模型

软件开发生命周期模型指的是软件开发全过程、活动和任务的结构性框架。软件项目的开发包括：需求、设计、编码、测试、稳定、部署、维护等阶段。

常见的软件开发模型有瀑布模型、迭代开发、螺旋开发和敏捷开发。

1 瀑布模型

瀑布模型式是最典型的预见性的方法，严格遵循预先计划的需求分析、设计、编码、集成、测试、维护的步骤顺序进行。步骤成果作为衡量进度的方法，例如需求规格，设计文档，测试计划和代码审阅等等。瀑布式的主要有以下问题：

1. 各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量；
2. 由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险；
3. 早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。

因此，瀑布式方法在需求不明并且在项目进行过程中可能变化的情况下基本是不可行的。

2 迭代开发模型

迭代式开发是一种与传统的瀑布式开发相反的软件开发过程，具有更高的成功率和生产率。在迭代开发中，整个开发工作被组织为一系列的短小的、固定长度（如3周）的小项目，逐步逐步的完成，故为迭代。每一次迭代都包括需求分析、设计、实现与测试。采用这种方法，开发工作可以在需求被完整地确定之前启动，并在一次迭代中完成系统的一部分功能或业务逻辑的开发工作。再通过客户的反馈来细化需求，并开始新一轮的迭代。迭代开发具有以下优点：

1. 降低风险。如果开发人员重复某个迭代，那么损失只是这一个开发有误的迭代的花费。
2. 适应需求变更。由于用户的需求并不能在一开始就作出完全的界定，它们通常是在后续阶段中不断细化的。
3. 持续的测试与集成，降低后期的工作量与风险。

3 螺旋开发模型

螺旋开发，将瀑布模型和快速原型模型结合起来，强调了其他模型所忽视的风险分析，特别适合于大型复杂的系统。“螺旋模型”刚开始规模很小，当项目被定义得更好、更稳定时，逐渐展开。 “螺旋模型”的核心就在于不需要在刚开始的时候就把所有事情都定义的清清楚楚。您轻松上阵，定义最重要的功能，实现它，然后听取客户的意见，之后再进入到下一个阶段。如此不断轮回重复，直到得到您满意的最终产品。 螺旋开发分为以下四个阶段：

1. 制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件；
2. 风险分析：分析评估所选方案，考虑如何识别和消除风险；
3. 实施工程：实施软件开发和验证；
4. 客户评估：评价开发工作，提出修正建议，制定下一步计划。

一个阶段首先是确定该阶段的目标，完成这些目标的选择方案及其约束条件，然后从风险角度分析方案的开发策略，努力排除各种潜在的风险，有时需要通过建 造原型来完成。如果某些风险不能排除，该方案立即终止，否则启动下一个开发步骤。最后，评价该阶段的结果，并设计下一个阶段。

4 敏捷开发模型

敏捷开发，是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。相对于“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发中人的作用。

1. 个体和互动重于流程和工具。
2. 可工作的软件重于求全而完备的文档。
3. 客户协作重于合同谈判。
4. 应对变化重于遵循计划。

其中位于右边的内容虽然也有其价值，但是左边的内容最为重要。人员彼此信任，人少但是精干，可以面对面的沟通。

敏捷开发小组主要的工作方式可以归纳为：作为一个整体工作；按短迭代周期工作；每次迭代交付一些成果；关注业务优先；检查与调整。

最重要的因素恐怕是项目的规模。规模增长，面对面的沟通就愈加困难，因此敏捷方法更适用于较小的队伍，40、30、20、10人或者更少。

5 四种模型比较

传统的瀑布式开发，也就是从需求到设计，从设计到编码，从编码到测试，从测试到提交大概这样的流程，要求每一个开发阶段都要做到最好。特别是前期阶段，设计的越完美，提交后的成本损失就越少。

迭代式开发，不要求每一个阶段的任务做的都是最完美的，而是明明知道还有很多不足的地方，却偏偏不去完善它，而是把主要功能先搭建起来为目的，以最短的时间，最少的损失先完成一个“不完美的成果物”直至提交。然后再通过客户或用户的反馈信息，在这个“不完美的成果物”上逐步进行完善。

螺旋开发，很大程度上是一种风险驱动的方法体系，因为在每个阶段之前及经常发生的循环之前，都必须首先进行风险评估。

敏捷开发，相比迭代式开发两者都强调在较短的开发周期提交软件，但是，敏捷开发的周期可能更短，并且更加强调队伍中的高度协作。敏捷方法有时候被误认为是无计划性和纪律性的方法，实际上更确切的说法是敏捷方法强调适应性而非预见性。

适应性的方法集中在快速适应现实的变化。当项目的需求起了变化，团队应该迅速适应。这个团队可能很难确切描述未来将会如何变化。

6 软件开发过程中的测试

在前面介绍的软件开发过程中，测试都是一个重要的组成部分。尤其对于中大型项目，从项目开始指出就要制定测试计划、对需求进行测试、设计测试和测试用例、执行测试，最后对测试的结果进行总结和分析。软件缺陷发现得越早，修复软件缺陷所需的代价越小。

TDD（测试驱动开发）的思路就是通过测试推动整个开发的进行，开发代码之前，先编写测试代码。在明确要开发某个功能后，首先思考如何对这个功能进行测试，并完成测试代码的编写，然后编写相关的代码满足这些测试用例。并且，软件测试的活动贯穿整个软件开发生命周期的始终。

7 软件测试的目的与原则

测试的定义：使用人工或自动手段来运行或测定某个系统的过程，其目的在于检查它是否满足规定的需求或是弄清预期结果与实际结果之间的差别。

软件测试的目的：发现程序中的错误，保证软件产品的最终质量。

1. 测试是程序的执行过程，目的在于发现错误
2. 一个成功的测试用例在于发现至今未发现的错误
3. 一个成功的测试是发现了至今未发现的错误的测试
4. 确保产品完成了它所承诺或公布的功能，并且用户可以访问到的功能都有明确的书面说明。
5. 确保产品满足性能和效率的要求
6. 确保产品是健壮的和适应用户环境的

软件测试的原则：

1. 测试用例中一个必须部分是对预期输出或接口进行定义
2. 程序员应避免测试自己编写的程序
3. 编写软件的组织不应当测试自己编写的软件
4. 应当彻底检查每个测试的执行结果
5. 测试用例的编写不仅应当根据有效和预料到的输入情况，而且也应当根据无效和未预料到的输入情况
6. 检查程序是否“未做其应该做的”仅是测试的一半，测试的另一半是检查程序是否“做了其不应该做的”
7. 应避免测试用例用后即弃，除非软件本身就是个一次性的软件
8. 计划测试工作时不应默许假定不会发现错误
9. 程序某部分存在更多错误的可能性，与该部分已经发现错误的数量成正比

8 软件的可测性

软件的可测性太差会导致测试的难度相当大，甚至无法测试。这种情况往往是由于极差的软件架构设计和极为不规范的软件开发工作导致的。

1. 紧耦合。不把大半个系统实例化就无法测试。
2. 弱内聚。这个类实现了太多功能，导致测试非常复杂。
3. 冗余。同一个方法在多处使用，每一处都得测。

好的软件架构应该是松耦合、高内聚的。提高软件的测试性的同时也提高了软件的可维护性和可管理性。

二、测试用例设计

测试用例是为特定的目的而设计的一组测试输入、执行条件和预期的结果。测试用例是执行的最小实体。简单地说，测试用例就是设计一个场景，使软件程序在这种场景下，必须能够正常运行并且达到程序所设计的执行结果。

1 黑盒测试与白盒测试

黑盒测试：已知产品的功能设计规格，可以进行测试证明每个实现了的功能是否符合要求。白盒测试：已知产品的内部工作过程，可以进行测试证明每种内部操作是否符合设计规格要求，所有内部成分是否经过检查。

合理的测试策略是将这两种测试要素组合起来。我们可以通过使用特定的面向黑盒测试的测试用例设计方法，而后使用白盒测试方法对程序的逻辑结构进行检查以补充这些测试用例，借此来设计出一个相当严格的测试。

白盒测试方法有语句覆盖、判定覆盖、条件覆盖、判定/条件覆盖、条件组合覆盖、路径覆盖。黑盒测试方法有等价类划分、边界值分析、因果图分析、错误测试、状态图、场景法等。

2 白盒测试用例设计

白盒测试关注的是测试用例执行的程度或覆盖程序逻辑结构（源代码）的程度。完全的白盒测试是将程序中每条路径都执行到，然而对一个带有循环的程序来说，完全的路径测试并不切合实际。白盒测试的特点：依据软件设计说明书进行测试、对程序内部细节的严密检验、针对特定条件设计测试用例、对软件的逻辑路径进行覆盖测试。

语句覆盖是最起码的结构覆盖要求，语句覆盖要求设计足够多的测试用例，使得程序中每条语句至少被执行一次。可以很直观地从源代码得到测试用例，无须细分每条判定表达式。由于这种测试方法仅仅针对程序逻辑中显式存在的语句，但对于隐藏的条件和可能到达的隐式逻辑分支，是无法测试的。（遗漏隐藏的逻辑分支）

判定覆盖要求必须编写足够的测试用例，使得每一个判断都至少有一个为“真”和为“假”的输出结果。判定覆盖比语句覆盖要多几乎一倍的测试路径，当然也就具有比语句覆盖更强的测试能力。同样判定覆盖也具有和语句覆盖一样的简单性，无须细分每个判定就可以得到测试用例。往往大部分的判定语句是由多个逻辑条件组合而成（如，判定语句中包含AND、OR、CASE），若仅仅判断其整个最终结果，而忽略每个条件的取值情况，必然会遗漏部分测试路径。（遗漏组合判定中的某些条件取值）

条件覆盖要求设计足够多的测试用例，使得判定中的每个条件获得各种可能的结果，即每个条件至少有一次为真值，有一次为假值。要达到条件覆盖，需要足够多的测试用例，但条件覆盖并不能保证判定覆盖。条件覆盖只能保证每个条件至少有一次为真，而不考虑所有的判定结果。

判定/条件覆盖要求设计足够多的测试用例，使得判定中每个条件的所有可能结果至少出现一次，每个判定本身所有可能结果也至少出现一次。判定/条件覆盖满足判定覆盖准则和条件覆盖准则，弥补了二者的不足。判定/条件覆盖准则的缺点是未考虑条件的组合情况。

多重条件覆盖要求设计足够多的测试用例，使得每个判定中条件结果的所有可能组合至少出现一次。多重条件覆盖准则满足判定覆盖、条件覆盖和判定/条件覆盖准则。更改的判定/条件覆盖要求设计足够多的测试用例，使得判定中每个条件的所有可能结果至少出现一次，每个判定本身的所有可能结果也至少出现一次。并且每个条件都显示能单独影响判定结果。缺点是线性地增加了测试用例的数量。

路径覆盖要求设计足够的测试用例，覆盖程序中所有可能的路径。由于路径覆盖需要对所有可能的路径进行测试（包括循环、条件组合、分支选择等），那么需要设计大量、复杂的测试用例，使得工作量呈指数级增长。而在有些情况下，一些执行路径是不可能被执行的，这样不仅降低了测试效率，而且大量的测试结果的累积，也为排错带来麻烦。

3 黑盒测试用例设计

（1）等价类划分

等价类划分是把所有可能的输入数据,即程序的输入域划分成若干部分（子集）,然后从每一个子集中选取少数具有代表性的数据作为测试用例。等价类分为有效等价类和无效等价类，其中，有效等价类是指对于程序的规格说明来说是合理的，有意义的输入数据构成的集合；而无效等价类是指对于程序的规格说明来说是不合理的，没有意义的输入数据构成的集合。设计测试用例时,要同时考虑这两种等价类。因为软件不仅要能接收合理的数据,也要能经受意外的考验，这样的测试才能确保软件具有更高的可靠性。划分等价类有以下原则：

1. 在输入条件规定了取值范围或值的个数的情况下,则可以确立一个有效等价类和两个无效等价类。如：输入值是学生成绩，范围是0～100；则小于0和大于100的为无效等价类，0~100之间的为有效等价类。
2. 在输入条件规定了输入值的集合或者规定了"必须如何"的条件的情况下，可确立一个有效等价类和一个无效等价类。
3. 在输入条件是一个布尔量的情况下,可确定一个有效等价类和一个无效等价类。
4. 在规定了输入数据的一组值（假定n个）,并且程序要对每一个输入值分别处理的情况下,可确立n个有效等价类和一个无效等价类。例：输入条件说明学历可为:专科、本科、硕士、博士四种之一，则分别取这四种这四个值作为四个有效等价类，另外把四种学历之外的任何学历作为无效等价类。
5. 在规定了输入数据必须遵守的规则的情况下,可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）；
6. 在确知已划分的等价类中各元素在程序处理中的方式不同的情况下,则应再将该等价类进一步的划分为更小的等价类。

在确立了等价类后,可建立等价类表,列出所有划分出的等价类输入条件：有效等价类、无效等价类，然后从划分出的等价类中按以下三个原则设计测试用例：

1. 为每一个等价类规定一个唯一的编号；
2. 设计一个新的测试用例,使其尽可能多地覆盖尚未被覆盖地有效等价类,重复这一步，直到所有的有效等价类都被覆盖为止；
3. 设计一个新的测试用例,使其仅覆盖一个尚未被覆盖的无效等价类,重复这一步，直到所有的无效等价类都被覆盖为止。

（2）边界值分析

边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。边界值分析不是从某等价类中随便挑一个作为代表，而是使这个等价类的每个边界都要作为测试条件。边界值分析不仅考虑输入条件，还要考虑输出空间产生的测试情况。

长期的测试工作经验告诉我们，大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。使用边界值分析方法设计测试用例，首先应确定边界情况。通常输入和输出等价类的边界，就是应着重测试的边界情况。应当选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据。

（3）因果图

因果图是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况。

等价类划分法和边界值分析方法都是着重考虑输入条件，但没有考虑输入条件的各种组合、输入条件之间的相互制约关系。这样虽然各种输入条件可能出错的情况已经测试到了，但多个输入条件组合起来可能出错的情况却被忽视了。如果在测试时必须考虑输入条件的各种组合，则可能的组合数目将是天文数字，因此必须考虑采用一种适合于描述多种条件的组合、相应产生多个动作的形式来进行测试用例的设计，这就需要利用因果图（逻辑模型）。

（4） 错误测试

错误测试是基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法。

如测试一个对线性表（比如数组）进行排序的程序，可推测列出以下几项需要特别测试的情况：

1. 输入的线性表为空表；
2. 表中只含有一个元素；
3. 输入表中所有元素已排好序；
4. 输入表已按逆序排好；
5. 输入表中部分或全部元素相同。

4 测试用例设计综合策略

Myers提出了使用各种测试方法的综合策略：

1. 在任何情况下都必须使用边界值分析方法，经验表明用这种方法设计出测试用例发现程序错误的能力最强。
2. 必要时用等价类划分方法补充一些测试用例。
3. 用错误推测法再追加一些测试用例。
4. 对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度，如果没有达到要求的覆盖标准，应当再补充足够的测试用例。
5. 如果程序的功能说明中含有输入条件的组合情况，则一开始就可选用因果图法。

测试用例的设计步骤：1)构造根据设计规格得出的基本功能测试用例；2)边界值测试用例；3)状态转换测试用例；4)错误猜测测试用例；5)异常测试用例；6)性能测试用例；7)压力测试用例。

三、软件测试类型

单元测试

单元测试并不是对整个程序进行测试，而是对构成程序的较小模块进行测试。单元测试减小了调试的难度（一旦某个错误被发现出来，我们就知道它在哪个具体的模块中）；单元测试提供了同时测试多个模块的可能，将并行工程引入软件测试中。

在为模块单元测试设计测试用例时，需要使用两种类型的信息：模块的规格说明和模块的源代码。规格说明一般都规定了模块的输入和输出参数以及模块的功能。单元测试总体上是面向白盒测试的，因此，单元测试的测试用例的设计过程如下：使用一种或多种白盒测试方法分析模块的逻辑结构，然后使用黑盒测试方法对照模块的规格说明以补充测试用例。

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注软件测试）

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
测试总体上是面向白盒测试的，因此，单元测试的测试用例的设计过程如下：使用一种或多种白盒测试方法分析模块的逻辑结构，然后使用黑盒测试方法对照模块的规格说明以补充测试用例。

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注软件测试）
[外链图片转存中…(img-VypLYHJn-1713567007336)]

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！