文章目录
2025软件测试复习大纲整理
参考 https://blog.csdn.net/qq_47951468/article/details/125293776
第一章、引论
为什么要进行软件测试
- 产品质量的保证
- 控制成本的关键
- 软件可靠性确认
- 让企业具备国际竞争的实力
什么是软件测试
Bill Hetzel博士（正向思维的代表）：- 软件测试就是为程序能够按预期设想那样运行而建立足够的信心
- 软件测试是一系列活动以评价一个程序或系统的特性或能力并确定是否达到预期的结果
- 测试是为了验证软件是否符合用户需求，即验证软件产品是否能正常工作
Glenford J.Myers(反向思维的代表):- 测试是为了证明程序有错，而不是证明程序无错误
- 一个好的测试用例是在于它能发现至今未发现的错误
- 一个成功的测试是发现了至今未发现的错误的测试
软件测试四种导向
- 以功能验证为导向，测试是证明软件是正确的（正向思维）
- 以破坏性检测为导向，测试是为了找到软件中的错误（逆向思维）
- 以质量评估为导向，测试是提供产品的评估和质量度量
- 以缺陷预防为导向，测试是为了展示软件符合设计要求，发现缺陷、预防缺陷
验证（Verification） 和 有效性确认（Validation）
软件测试是由 验证（Verification） 和 有效性确认（Validation） 活动构成的整体
- 验证是检验软件是否已正确地实现了产品规格书所定义的系统功能和特性
- 有效性确认是确认所开发的软件是否满足用户真正需求的活动
软件测试和软件开发的关系
- 测试不是开发下一道工序
- 测试与开发是并行、协作的关系
软件测试与SQA的关系
软件质量保证（SQA）活动是通过对软件产品有计划的进行评审和审计来验证软件是否合乎标准的系统工程，通过协调、审查和跟踪以获取有用信息，形成分析结果以指导软件过程
联系
- SQA指导、监督软件测试的计划和执行，督促测试工作的结果客观、准确和有效，并协助测试流程的改进
- 软件测试是SQA重要手段之一，为SQA提供所需的数据，作为质量评价的客观依据
区别
- SQA是一项管理工作，侧重于对流程的评审和监控
- 测试是一项技术性的工作，侧重对产品进行评估和验证
五大学派
- 分析学派：分析学派认为测试工作是技术性很强的工作， 侧重使用类似UML工具进行分析和建模。
- 标准学派：标准学派把测试看作侧重劣质成本控制并具有可重复标准的、旨在衡量项目进度的一项工作，测试是对产品需求的确认，每个需求都需要得到验证。
- 质量学派：软件质量需要规范，测试就是过程的质量控制、揭示项目质量风险的活动，确定开发人员是否遵守规范，测试人员扮演产品质量的守门员角色。
- 上下文驱动学派：认为软件是人创造的，测试所发现的每一个缺陷都和相关利益者密切相关；认为测试是一种有技巧的心理活动；强调人的能动性和启发式测试思维。探索性测试就是其典型代表。
- 敏捷学派：认为软件就是持续不断的对话，而测试就是验证开发工作是否完成， 强调自动化测试。TDD 是其典型代表。
第二章、软件测试的基本概念
软件缺陷定义
任何程序、系统中的问题，如与产品设计书的不一致性、不能满足用户的需求
修复软件缺陷的代价
缺陷带来的成本被称为“劣质成本”非线性增长，不及时处理所带来的成本很高
在设计阶段就是它的3～6倍，在编程阶段是它的10倍，在内部测试阶段是它的20～40倍，在外部测试阶段是它的30～70倍，而到了产品发布出去时，这个数字就是40～100倍，修正错误的代价不是随时间线性增长，而几乎是呈指数增长的。
测试结束标准
- 用例全部测试
- 覆盖率达到标准
- 缺陷率达到标准
- 其他指标达到标准
以下为本章掌握
软件测试的分类
静态测试
静态测试包括对软件产品的需求和设计规格说明书的评审、 对程序代码的审査以及静态分析等，并不需要对代码进行编译和仿真运行。
动态测试
动态测试是通过真正运行程序发现错误，通过观察代码运行过程，来获取系统行为、变量实时结果、内存、堆栈、线程以及测试覆盖度等各方面的信息，来判断系统是否存在问题，或者通过有效的测试用例，对应的输入输出关系来分析被测程序的运行情况，来发现缺陷。
回归测试
为保证软件中新的变化(新增加的代码、代码修改等)不会对原有功能的正常使用有影响而进行的测试。也就是说,满足用户需求的原有功能不应该因为代码变化而出现任何新的问题。
压力测试
也称负载测试，用来检查系统在不同负载（如数据量、并发用户、连接数等）条件下的系统运行情况，特别是高负载、极限负载下的系统运行情况，以发现系统不稳定、系统性能瓶颈、内存泄漏、CPU使用率过高等问题。
ET vs. ST
ST
- 先设计、后执行
- 强调逻辑分析
- 关注需求和测试文档
- 有明确的测试标准
- 强调评审、可控
- 严谨、规范
ET
- 学习、设计和执行并行
- 上下文驱动
- 强调个人能力
- Test Oracle
- 关注与产品的交互
- 拥抱变化、乐趣
软件测试的工作范畴
- 软件测试工作的组织与管理：制定测试策略、测试计划，确认所采用的测试方法与规范，控制测试进度，管理测试资源。
- 测试工作的实施：编制符合标准的测试文档，搭建测试环境，开发测试脚本、与开发组织协作实现各阶段的测试活动。
第三章、软件测试方法
白盒测试的概念
按照程序内部的结构测试程序，通过测试来检测产品内部动作是否按照设计规格说明书的规定正常进行，检验程序中的每条通路是否都能按预定要求正确工作。
黒盒测试的概念
黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用。在测试中，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。
什么是测试用例
为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求，被称为有效地发现软件缺陷的最小测试执行单元。
为什么要设计测试用例
测试用例测试用例是软件测试的核心，构成了设计和制定测试过程的基础。
- 测试用例是测试人员在测试过程中的重要参考依据。
- 测试用例可以帮助实施有效的测试，所有被执行的测试都是有意义的，不要执行毫无意义的测试操作。
- 良好的测试用例不断地被重复使用，使得测试过程事半功倍。
- 测试用例是一个知识积累的过程。
以下为本章掌握
逻辑覆盖
结构性测试力求提高测试覆盖率。逻辑覆盖是对一系列测试过程的总称，它是在使用白盒测试法时，选用测试用例执行程序逻辑路径的方法。
逻辑覆盖按覆盖程度由低到高大致分为以下几类：
- 语句覆盖：设计若干测试用例，使程序中每一可执行语句至少执行一次；
- 判定覆盖：设计用例，使程序中的每个逻辑判断的取真取假分支至少经历一次；
- 条件覆盖：设计用例，使判断中的每个条件的可能取值至少满足一次；
- 判定/条件覆盖：设计用例，使得判断中的每个条件的所有可能结果至少出现一次，而且判断本身所有可能结果也至少出现一次；
- 条件组合覆盖：设计用例，使得每个判断表达式中条件的各种可能组合都至少出现一次；显然，满足⑤的测试用例也一定是满足②、③、④的测试用例。
- 路径覆盖：设计足够的测试用例，使程序的每条可能路径都至少执行一次。如果把路径覆盖和条件组合覆盖结合起来，可以设计出检错能力更强的测试数据用例。
基本路径测试
在程序或业务控制流程的基础上，分析控制构造的环路复杂性，导出基本可执行路径集合，从而设计出测试用例。
- 依据代码绘制流程图
- 确定流程图的圈复杂度
- 确定线性独立路径的基本集合
- 设计测试用例覆盖每条基本路径
所谓独立路径，是指包括一组以前没有处理的语句或条件的一条路径。基本集：由独立路径构成的集合。
path1：1 - 11path2：1 - 2 - 3 - 4 - 5 - 10 - 1 - 11path3：1 - 2 - 3 - 6 - 8 - 9 - 10 - 1 - 11path4：1 - 2 - 3 - 6 - 7 - 9 - 10 - 1 - 11
路径path1，path2，path3，path4 组成了一个基本路径集。基本路径集不是唯一的。
设计所有的测试用例，来覆盖程序中基本的执行路径。
为什么需要求环路复杂度
进行程序的基本路径测试时，程序的环路复杂性给出了程序基本路径集合中的独立路径条数，这是确保程序中每个可执行语句至少执行一次所必需的测试用例数目的上界。
等价类划分方法
- 有效等价类是有意义的、合理的输入数据，可检查程序是否实现了规格说明中所规定的功能和性能。
- 无效等价类与有效等价类的意义相反。
用等价类划分法设计测试用例步骤：
- 形成等价类表，每一等价类规定一个唯一的编号；
- 设计一个新的测试用例，使其尽可能多地覆盖尚未覆盖的有效等价类， 重复这一步骤，直到所有有效等价类均被测试用例所覆盖；
- 设计一个新测试用例，使其只覆盖一个无效等价类，重复这一步骤直到所有无效等价类均被覆盖。
边界值分析法
- 确定边界情况（输入或输出等价类的边界）
- 选取正好等于、刚刚大于或刚刚小于边界值作为测试数据
判定表方法
输入是由多个因素构成，不需要进行因果分析
因果图方法
有限状态机
有限状态机（FSM）是对象行为建模的工具，以描述对象在其生命周期内所经历的状态序列，以及如何响应来自外界的各种事件
状态图
第四章、软件测试流程与规范
TMM
过程能力描述了遵循一个软件测试过程可能达到的预期结果的范围。TMM的建立，得益于以下3点：
- 充分吸收
CMM的精华 - 基于历史演化的测试过程
- 业界的最佳实践
TMMi呈现的是一个过程改进的阶段型架构。它包括阶段或级别，组织可以通过它们使测试过程从临时的和未管理的状态进化为已管理、已定义、已测量和优化的状态。
在
TMMi中有5个级别，规定了成熟度级别和测试过程改进的路径。每个级别都有一组过程域，组织需要实施这些过程域来达到对应的成熟度级别。
TMMi1级—初始TMMi2级—已管理TMMi3级—已定义TMMi4级—已测量TMMi5级—优化
TPI
TPI是基于连续性表示法的测试过程改进的参考模型，是在软件控制、测试知识以及过往经验的基础上开发出来的。
CTP
- 关键测试过程（Critical Test Process，
CTP）评估模型主要是一个内容参考模型，一个上下文相关的方法，并能对模型进行裁剪。 - 使用
CTP的过程改进，始于对现有测试过程的评估， 通过评估以识别过程的强弱，并结合组织的需要提供改进的意见。
STEP
STEP（Systematic Test and Evaluation Process，系统化测试和评估过程）是一个内容参考模型，认定测试是一个生命周期活动，在明确需求后开始直到系统退役。
W模型
第五章、单元测试与集成测试
全部掌握
单元测试概念
定义：单元测试是对软件基本组成单元进行的测试
时机：一般在代码完成后由开发人员完成，QA人员辅助
测试人员：单元测试一般由编程人员和测试人员共同完成，而以开发人员为主
单元测试的测试方法：
- 检查每一条独立执行路径的测试。保证每条语句被至少执行一次。
- 检查局部数据结构完整性
- 检查模块接口是否正确
- 检查临界数据处理的正确性
- 预见、预设的各种出错处理是否正确有效
依据：详细设计和概要设计
单元测试测试的不仅仅是代码，还有：接口测试、局部数据结构测试、独立路径测试、边界条件测试、错误处理测试、功能测试、性能测试、内存使用测试等。
模块和组件都是系统的组成部分，只是从不同的角度拆分系统而已。
- 从逻辑的角度来拆分系统后，得到的单元就是
模块
- 划分模块的主要目的是职责分离
- 从物理的角度来拆分系统后，得到的单元就是
组件
- 划分组件的主要目的是单元复用
单元测试目标
主要目标：检验各单元模块是否被正确地编码
需要验证以下内容：
- 信息能否正确地流入和流出单元。
- 在单元工作过程中，其内部数据能否保持其完整性，包括内部数据的形式、内容及相互关系不发生错误，也包括全局变量在单元中的处理和影响。
- 在为限制数据加工而设置的边界处，能否正确工作。
- 单元的运行能否做到满足特定的逻辑覆盖。
- 单元中发生了错误，其中的出错处理措施是否有效。
集成测试
集成测试是将软件集成起来，对模块之间的接口进行测试。
集成测试又叫子系统测试、组装测试、部件测试等。
模块内的集成，主要是测试模块内各个接口间的交互集成关系
子系统内的集成，测试子系统内各个模块间的交互关系
系统内的集成，测试系统内各个子系统和模块间的集成关系
测试人员：有经验的测试人员和开发者共同
测试依据：软件概要设计说明书，软件详细设计说明书
主要目标：实践表明，一些模块虽然能够单独地工作，但并不能保证连接起来也能正常的工作。程序在某些局部反映不出来的问题，在全局上很可能暴露出来，影响功能的实现。目标在于检验与软件设计相关的程序结构问题。如数据穿过接口时可能丢失；一个模块与另一个模块可能有由于疏忽的问题而造成有害影响； 把子功能组合起来可能不产生预期的主功能；个别看起来是可以接受的误差可能积累到不能接受的程度；全程数据结构可能有错误等。
集成模式
- 非渐增式测试模式：先分别测试每个模块，再把所有模块按设计要求放在一起结合成所要的程序，如大棒模式。
- 渐增式测试模式：把下一个要测试的模块同已经测试好的模块结合进来进行测试，测试完后再把下一个应该测试的模块结合起来测试。渐增式测试又可以根据每次添加模块的路线分为自顶向下测试、自底向上测试和混合测试等方式。
- 自顶向下：从主控模块开始，沿着软件的控制层次向下移动，从而逐渐把各个模块结合起来。（深度优先的或宽度优先的策略）
- 自底向上：从“原子”模块开始集成以进行测试。
- 混合策略：结合上述的两种方法逐步实施集成测试。
驱动程序：用于模拟被测模块的上级模块，能够调用被测模块，驱动模块接受测试数据，调用被测模块并把相关数据传送给被测模块。
桩程序：用于模拟被测模块工作过程中所调用的下层模块，一般很少进行数据处理，一般只检测被测模块传输数据的正确性。
第六章、系统功能测试
系统测试概念：
- 检验系统所有元素之间协作是否合适，整个系统的性能和功能是否达到要求。
- 其测试内容包括：功能测试，非功能测试与回归测试等。
- 功能测试：根据产品规格说明书，来检验被测试的系统是否满足各方面功能的使用要求
- 非功能性测试包含：性能测试、压力测试、容量测试、安全性测试、可靠性测试、容错性测试
- 回归测试：在程序有修改的情况下保证原有功能正常
测试人员：软件测试工程师
测试依据：软件需求规格说明书、软件概要设计说明书、软件详细设计说明书
确认测试：
- 确认测试又称有效性测试，是在模拟的环境下，运用黑盒测试的方法，验证被测软件是否满足需求规格说明书列出的需求。
- 任务是验证软件的功能和性能及其他特性是否与用户的要求一致。对软件的功能和性能要求在软件需求规格说明书中已经明确规定，它包含的信息就是软件确认测试的基础。
第七章、专项测试
什么是性能测试，以及测试目标是什么？
性能测试就是为了发现系统性能问题或获取系统性能相关指标而进行的测试。
一般在真实环境、特定负载条件下，通过工具模拟实际软件系统的运行及其操作，同时监控性能各项指标，最后对测试结果进行分析来确定系统的性能状况。
目标：
- 获取系统性能某些指标数据
- 为了验证系统是否达到用户提出的性能指标
- 发现系统中存在的性能瓶颈，优化系统的性能
α，β测试
α测试是指软件开发公司组织内部人员模拟各类用户行对即将面市软件产品（称为α版本）进行测试，试图发现错误并修正。
经过α测试调整的软件产品称为β版本。紧随其后的β测试是指软件开发公司组织各方面的典型用户在日常工作中实际使用β版本，并要求用户报告异常情况、提出批评意见。然后软件开发公司再对β版本进行改错和完善。
第8章、软件本地化测试
软件国际化（I18N）
I18N 是借助功能设计和代码实现中软件系统有能力处理多种语言和不同文化，使创建不同语言版本时，不需要重新编写代码的软件工程方法。
软件本地化（L10N）
L10N 是将一个软件产品按特定国家/地区或语言市场的需要进行加工，使之满足特定市场上的用户对语言和文化的特殊要求的软件生产活动。
软件全球化 G11N= I18N + L10N
关系和区别
I18N是L10N的基础和前提，为L10N做准备L10N是I18N向特定本地语言环境的转换I18N是软件产品源语言开发的一部分，属于EngineeringL10N可以独立于Engineering，可由第三方完成
第9章、软件测试自动化
测试自动化的内涵
- 自动化测试是相对手工测试而存在的一个概念，由手工逐个地运行测试用例的操作过程被测试工具自动执行的过程所代替
- 测试工具的使用是自动化测试的主要特征
- 测试自动化指一切可以由计算机系统自动完成的测试任务都已经由计算机系统或软件工具、程序来承担并自动执行
测试自动化实现原理
- 代码分析：类似于高级编译系统，在工具中定义类/对象/函数/变量等定义规则、语法规则等，在分析时对代码进行语法扫描，找出不符合编码规范的地方。
- 对象识别：Windows对象、Mac对象、Web DOM对象
- 脚本技术：
- 线性脚本
- 结构化脚本
- 数据驱动脚本
- 关键字驱动脚本
- 自动比较技术：静态比较和动态比较，简单比较和复杂比较， 敏感性测试比较和健壮性测试比较，比较过滤器
- 测试自动化系统的构成：测试工具的分类、测试工具的选择、测试自动化普遍存在的问题、自动化测试的引入和应用
自动化测试的引入和应用：
- 找准测试自动化的切入点
- 把测试开发纳入整个软件开发体系
- 测试自动化依赖测试流程和测试用例
- 软件测试自动化的投入较大
- 进行资源的合理调度
功能测试工具：QTP
性能测试工具：Loadrunner
TA框架的构成
