软件测试与维护思维脑图思维导图
U354455870
2023-12-28
软件测试
软件维护
单元测试
软件测试概念，黑盒测试等相关内容讲解
树图思维导图提供《软件测试与维护思维脑图》在线思维导图免费制作，点击“编辑”按钮，可对《软件测试与维护思维脑图》进行在线思维导图编辑，本思维导图属于思维导图模板主题，文件编号是：14b1dca7d1d5a41137da913399e42f54
思维导图大纲
相关思维导图模版
软件测试与维护思维导图模板大纲
软件测试的基本概念
从用户的角度出发，普遍希望通过软件测试暴露软件中隐藏的错误和缺陷,以考虑是否可接受该产品
从软件开发者的角度出发，则希望测试成为表明软件产品中不存在错误的过程,验证该软件已正确地实现了用户的要求,确立人们对软件质量的信心。
目的是
统地找出软件中潜在的各种错误和缺陷。
测试不能表明软件中不存在错误，它只能说明软件中存在错误。
软件测试原则
完全测试是不可能的
测试中有风险存在
软件测试只能表明缺陷的存在，而不能证明产品已经没有缺陷
软件产品中所存在的错误数与已发现的错误数成正比
要避免软件测试的杀虫剂现象
在设计测试用例时，应包括输入数据和预期的输出结果两个部分
要集中测试容易出错或错误较多的模块
应该长期保留所有的测试用例
使开发人员和测试人员分立
测试工作应该尽早开始
软件测试分类
软件开发过程是一个自顶向下，逐步细化的过程。
测试过程是依相反顺序安排的自底向上，逐步集成的过程。
软件测试是一个极为复杂的过程。一个规范化的软件测试过程，通常包括以下基本过程。
制定测试计划
编制测试大纲
要设计和生成测试用例
实施测试
生成软件问题的报告
软件测试模型
软件测试模型是指软件测试全部过程、活动或任务的结构框架。
软件测试最典型的测试模型是Ⅴ模型，另外还有W模型、H模型、前置模型和测试驱动模型等等。
V模型
V模型中，描述了基本的开发过程和测试行为。它的价值在于非常明确地标明了测试过程中存在的不同级别，并且清楚的描述了这些测试阶段和开发过程期间各个阶段的对应关系。
W模型
测试与开发同步
W模型优点：
在V模型的基础上，增加了开发阶段的同步测试，形成W模型；测试与开发同步进行，有利于尽早地发现问题。
W模型有利于即时了解项目的测试风险，及早制定应对方案，加快项目进度。
局限性
仍把开发活动看成是从需求开始到编码结束的串行活动，只有上一阶段完成后，才可以开始下一阶段的活动，不能支持迭代，自发性以及变更调整
H模型将测试活动完全独立出来，形成一个完全独立的流程;
测试用例
测试用例是测试工作的指导，是软件测试的必须准守的准则，更是软件测试质量稳定的根本保障。
指的是在测试执行之前设计的一套详细的测试方案，包括测试环境、测试步骤、测试数据和预期结果。
测试用例设计的好坏直接决定了测试的效果和结果，所以在软件测试活动中最关键的步骤就是设计有效的测试用例。
测试用例可以针对黑盒测试设计用例，也可以针对白盒测试设计用例。
为达到最佳的测试效果或高效的揭露隐藏的错误而精心设计的少量测试数据并执行。
测试分静态测试与动态测试，一般意义上的测试，多是指动态测试。
黑盒测试法
白盒测试法
黑盒测试
这种方法是把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。 黑盒测试又叫做功能测试或数据驱动测试。
黑盒测试能发现以下几类错误:
功能不对或功能遗漏。
界面错误。
数据结构或数据库访问错误性能问题。
性能测试
初始化和终止错误。
黑盒测试的优点:
有针对性地找问题，并且定位问题更准确;
黑盒测试可以证明产品是否达到用户要求的功能，是否符合用户的工作要求;
能重复执行相同的操作，测试中最枯燥的部分可由自动化完成
黑盒测试的缺点:
需要充分了解产品用到的技术，测试人员需要具有较多的经验;
在测试过程中很多是手工操作;
测试人员需要负责大量的文档;
常用的黑盒测试的方法：
等价类划分法
等价类划分的原则:
按区间划分
按数值划分
按数值集合划分
按限制条件或规则划分
分两种
有效等价类：对程序的规格说明是有意义的、合理的输入数据所构成的集合
无效等价类：对程序的规格说明是无意义的、不合理的输入数据构成的集合
边界值分析法
边界值分析法就是对输入或输出的边界值进行测试的一种黑盒测试方法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试用例来自等价类的边界。
软件测试所包含的边界条件：数字、字符、位置、质量、大小、速度、方位、尺寸、空间
对应的边界值：最大/最小、首位/末位、上/下、最快/最慢、最高/最低、最短/最长、空/满
遵守的原则 ：
如果输入条件规定了取值范围，应以该范围的边界内及刚刚超范围的边界外的值作为测试用例
若规定了值的个数，应分别以最大、最小个数和稍小于最小和稍大于最大个数作为测试用例
如果程序规格说明书中提到的输入或输出范围是有序的集合，应注意选取有序集的第一个和最后一个元素作为测试用例
常见的边界值
文本框接受字符个数，比如用户名长度，密码长度等
报表的第一行和最后一行
数组元素的第一个和最后一个
循环的第1次、第2次和倒数第2次、最后一次
边界值与等价划分的区别
边界值分析不是从某等价类中随便挑一个作为代表，而是这个等价类的每个边界都要作为测试条件。
边界值分析不仅考虑输入条件，还有考虑输出空间产生的测试情况。
错误推测法
也可以靠经验和直觉推测程序中可能存在的各种错误，从而有针对性地编写检查这些错误的例子。这就是错误推测法。
错误推测法的基本想法是：列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据它们选择测试用例。
因果图法
因果图法是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况。
因果图的适用范围
如果在测试时必须考虑输入条件的各种组合,可使用一种适合于描述对于多种条件的组合，相应产生多个动作的形式来设计测试用例，这就需要利用因果图。
因果图方法最终生成的就是判定表。
因果图中出现的基本符号
表示约束条件的符号
因果图法的测试用例设计步骤
根据程序规格说明书描述的语义内容，分析并确定“原因”和“结果”。
找出原因与原因之间、原因与结果之间的对应关系，将其表示成连接各个原因与各个结果之间的“因果图”。
由于语法及环境限制，有些原因与原因之间、原因与结果之间的组合情况是不可能出现的，在因果图上用记号表明约束或限制条件。
将因果图转换成决策表。
根据决策表中每一列设计测试用例。
因果图法的问题
作为输入条件的原因和输出结果直接的因果关系，有时候很难从软件规格说明中得到。
因果图得到的测试用例数量将达到惊人的速度，这给软件测试工作带来了沉重负担。
决策表法
决策表是分析和表达多逻辑条件下执行不同操作的情况的工具。在所有的黑盒测试方法中，基于决策表（也称为判定表）的测试是最为严格、最具有逻辑性的测试方法。
优点
决策表能够将复杂的问题按照各种可能的情况全部列举出来，简明并避免遗漏。因此利用决策表能够设计出完整的测试用例集合。这也是决策表的优点。
决策表通常由以下四部分组成：
条件桩——列出问题的所有条件
条件项——针对条件桩给出的条件列出所有的可能值
动作桩——列出问题规定的可能采取的操作
动作项——指出在条件项的各组取值情况下应采取的动作
构建决策表的步骤
确定规则的个数。一般来说，有n个条件的决策表有2n个规则（每个条件都取真、假值）。
列出所有的条件桩和动作桩。
填入条件项。
填入动作项，得到初始决策表。
简化决策表，合并相似规则。
子主题 5
黑盒测试选择
在任何情况下都必须选择边界值分析方法
必要时用等价类划分法补充一些测试用例
用错误推测法再追加一些测试用例
如果程序的功能说明中含有输入条件的组合情况，则可选用因果图法和决策表法
白盒测试
软件的白盒测试是对软件及其执行过程做细致的检查，它允许测试人员针对程序内部的逻辑结构及有关信息，设计或选择测试用例，对软件的执行过程进行覆盖测试，检查程序中的每条通路是否符合预定要求，能正确工作，并可通过在程序不同位置设立检查点，来检查程序的状态，以确定实际运行状态与预期状态是否一致。
软件人员使用白盒测试方法，主要想对程序模块进行如下的检查：
对程序模块的所有独立的执行路径至少测试一次；
对所有的逻辑判定，取“真”与取“假”的两种情况都至少测试一次；
在循环的边界和运行界限内执行循环体；测试内部数据结构的有效性等。
代码检查法
静态结构分析法
程序插桩技术
逻辑覆盖法
以程序内部逻辑结构为基础，通过对程序逻辑结构遍历实现程序测试的覆盖。
从覆盖源程序语句的详尽程度，可以分为
语句覆盖
每条语句至少执行一次
判定覆盖
每一判定的每个分支至少执行一次
条件覆盖
每一判定中的每个条件，分别“真”、
“假”至少各执行一次
判定/条件覆盖
同时满足判定覆盖和条件覆盖的要求
条件组合覆盖
求出判定中所有条件的各种可能组合
值，每一可能的条件组合至少执行一次
路径覆盖
是否每个函数的每一条可能的路径都被走过
基本路径法
测试用例要保证在测试中程序的每条可执行语句至少执行一次。
控制流图中，圆圈称为控制流图的一个结点，表示一个或多个无分支的语句或源程序语句；箭头称为边或连接，代表控制流
独立路径：
和其他独立路径相比，至少包含一条新边的路径，也就是包含一些前面的路径未包含的语句。
环路复杂度：
一种为程序逻辑复杂性提供定量测度的软件度量。
计算环路复杂度的方法：
流图中区域的数量对应于环路的复杂度
给定流图G的环路复杂度V(G)，定义为V(G)=E-N+2，其中E是流图中边的数量，N是流图中结点的数量
给定流图G的环路复杂度V(G)，定义为V(G)=P+1，其中P是流图G中判定结点的数量
基本路径测试法步骤：
以详细设计或源代码为基础，导出程序的控制流图
计算得出控制流图G的环路复杂度V(G)
确定线性无关的路径的基本集
生成测试用例，确保基本路径集中每条路径的执行
白盒测试方法选择
在测试中，可采取先静态再动态的组合方式，先进行代码检查和静态结构分析，再进行覆盖测试
覆盖测试是白盒测试的重点，一般可使用基本路径测试法达到语句覆盖标准，对于软件的重点模块，应使用多种覆盖标准衡量测试的覆盖率
在单元测试阶段，以代码检查、覆盖测试为主，在集成测试阶段，需要增加静态结构分析等，在系统测试阶段，应根据黑盒测试的结果，采用相应的白盒测试方法
软件测试的一般步骤
单元测试：着重测试每个单独的模块，以确保它作为一个单元来说功能是正确的
集成测试：把模块装配（即集成）在一起形成完整的软件包，在装配的同时进行测试
确认测试：测试在需求分析阶段确定下来的确认标准
系统测试：验证所有系统元素是否都能正常配合
单元测试
单元测试概述
单元测试又称模块测试，是针对软件设计的最小单位-----程序模块，进行正确性检验的测试工作。
单元测试内容
内部处理逻辑
数据结构
单元测试方法
在进行单元测试时，被测试的单元本身不是独立的程序，需要为其开发驱动模块（也称驱动程序）和桩模块（也称存根程序）。
驱动模块是用来模拟待测试模块的上级模块。
桩模块是用来模拟待测模块工作过程中所调用的模块。
集成测试
集成测试概述
集成测试是对软件系统进行测试，主要用来揭露设计阶段产生的错误。它就是把模块按照设计要求组装起来的同时进行测试，主要目标是发现与接口有关的问题。
也叫组装测试或联合测试。在单元测试的基础上，将所有模块按照设计要求组装成为子系统或系统，进行集成测试。
目标是利用已通过单元测试的构件建立设计中描述的程序结构。
集成测试分析
集成测试分析直接指导集成测试用例的设计，在整个集成测试过程中占据最关键的地位。
集成测试策略
模块组装成软件系统的两种方法：
非增量式集成：先分别测试每个模块，再将所有模块按照设计要求放在一起结合成所要的程序。
增量式集成：将下一个要测试的模块同已经测试好的那些模块结合起来进行测试，测试完后再将下一个应测试的模块结合起来进行测试 。
自顶向下增量式集成测试
深度优先策略
广度优先策略
自顶向下的集成方式的主要优点
可以及早地发现和修复模块结构图中主要控制点存在的问题
能较早地验证功能的可行性
最多只需要一个驱动模块
自顶向下的集成方式的主要缺点是需要开发和维护大量的桩模块。
自底向上增量式集成测试
自底向上集成方式的主要优点
大大减少了桩模块的开发
先对底层模块进行测试，减少了回归测试成本
在集成的早期实现对底层模块的并行测试
自底向上集成方式的主要缺点
需要大量的驱动模块
主要控制点存在的问题要到集成后期才能修复，需要花费较大成本
三明治集成测试
将自顶向下测试与自底向上测试两种模式有机结合起来，采用并行的自顶向下、自底向上集成方式形成。
确认测试
又称有效性测试。任务是验证软件的功能和性能及其它特性是否与用户的要求一致。
是根据软件需求规格说明书当中定义的全部功能，性能以及确认测试的计划来测试整个软件系统是否达到了要求，并提交最终的用户手册和操作手册。
通过检验和提供客观证据，验证软件是否满足特定预期用途的需求
依据软件需求规格说明书
确认测试主要是验证软件是否在“做正确的事”
系统测试
系统测试概述
系统测试，是将通过确认测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其它系统元素结合在起，在实际运行环境下，对计算机系统进行一系列的组装测试和确认测试。
系统测试的目的在于通过与系统的需求定义做比较，发现软件与系统的定义不符合或者与之矛盾的地方。
测试范围可分为功能测试、性能测试、压力测试、容量测试、安全性测试、图形用户界面测试、可用性测试、安装测试、配置测试、异常测试、备份测试、健壮性测试、文档测试、在线帮助测试、网络测试、稳定性测试。
验收测试
在测试过程中，除了考虑软件的功能和性能外，还应对软件的可移植性、兼容性、可维护性、错误的恢复功能等进行确认。
确认测试应交付的文档有:
确认测试分析报告
最终的用户手册和操作手册
项目开发总结报告
验收测试概述
以用户为主的测试
在软件系统测试结束以及软件配置审查之后开始，应由用户、测试人员、软件开发人员和质量保证人员一起参与，目的是确保软件准备就绪
验收测试内容
验收测试主要包括
配置复审
合法性检查
软件文档检查
软件代码测试
软件功能和性能测试
测试结果交付内容
α测试和β测试
α测试由用户在开发者的场所进行，并且在开发者对用户的“指导”下进行测试。
β测试由软件的最终用户在一个或多个客户场所进行。 这些用户返回有关错误给开发者。
回归测试
回归测试不是一个测试阶段，而是一种可以用于单元测试、集成测试、系统测试和验收测试各个测试过程的测试技术。
回归测试指软件系统被修改或扩充后重新进行的测试，以确认修改没有引入新的错误或导致其他代码产生错误。自动回归测试将大幅降低系统测试、维护升级等阶段的成本。
软件调试
调试
软件调试是在进行了成功的测试之后才开始的工作。它与软件测试不同，调试的任务是进一步诊断和改正程序中潜在的错误。
调试活动由两部分组成
确定程序中可疑错误的确切性质和位置。
对程序(设计、编码)进行修改，排除这个错误
调试是在测试发现错误之后排除错误的过程。
调试过程
调试过程的结果
找到了问题的原因并把问题改正和排除掉了
没找出问题的原因
调试途径
蛮干法
回溯法
原因排除法（对分查找法、归纳法、演绎法）
测试分析报告编写指南
软件维护
在软件产品交付给用户之后，为了改正软件测试阶段未发现的缺陷，改进软件产品的性能，补充软件产品的新功能等，所进行的修改软件的过程。
软件维护的过程
建立维护机构
用户提出维护申请并提交维护申请报告
维护人员确认维护类型并实施相应的维护工作
整理维护记录并对维护工作进行评审
对维护工作进行评价
软件维护分类
纠错性维护：为了识别并纠正软件产品中所潜藏的错误，改正软件性能上的缺陷所进行的维护
适应性维护：为了使软件产品适应软硬件环境的变更而进行的维护
完善性维护：软件维护的主要部分，针对用户对软件产品所提出的新需求所进行的维护
预防性维护：为以后进一步维护软件打下了良好的基础
影响软件可维护性的因素
可理解性
可测试
可修改性
软件维护的副作用
修改代码的副作用：每次对代码的修改都有可能产生新的错误
修改数据的副作用：数据结构被改动时有新的错误产生的现象
修改文档的副作用：在软件产品的内容更改之后没有对文档进行相应的更新而为以后的工作带来不便的情况
查看更多
相似思维导图模版
首页
我的文件
我的团队
个人中心