软件测试-思维导图
2022-04-14 14:47:35 283 举报AI智能生成
软件测试的思维导图是一种图形化的工具，用于表示和组织软件测试过程中的各种概念、任务和方法。它以树状结构展示，从中心主题（如“软件测试”）出发，分为多个子主题，如“功能测试”、“性能测试”、“安全测试”等。每个子主题下又有更详细的分支，如“黑盒测试”、“白盒测试”、“压力测试”等。通过这样的结构，可以清晰地展示软件测试的层次关系和逻辑顺序，帮助测试人员更好地理解和掌握测试知识。同时，思维导图还可以作为团队协作的工具，让团队成员共享信息、讨论问题和制定计划。总之，软件测试的思维导图是一种高效、直观的学习和管理工具。
作者其他创作
大纲/内容
第六章 软件测试的度量
6.1
6.2 软件测试的度量及其应用
bug综合评价模型
数量
定量
质量
定性
测试过程
测试人员
第七章 系统测试技术
7.1 软件自动化测试
概念：是通过测试工具或其他手段，按照测试工程师的预定计划对软件产品进行自动化的测试。
优缺点
优点
对程序回归测试更方便
建立可靠、重复的测试，减少人为失误，更好地利用资源。
增强测试质量和覆盖率
执行手工测试不可能完成的任务
缺点
不能取代手工测试
发现的问题和缺陷比手工测试要少
不能用于测试周期很短的项目、不能保证100%的测试覆盖率、不能测试不稳定的软件和软件易用性等
第八章 软件测试工具及其应用
第九章 第三方测试
9.1 基本概念与测试过程
概念：是由开发者和用户以外的第三方进行的软件测试，其目的是为了保证测试工作的客观性。
第一章 软件测试基础
1.1软件测试基本概念
软测定义
在特定的条件下运行系统或构件，观察或记录结果，对系统的某个方面做出评价
分析某个软件项以发现和现存的，以及和要求的条件之差别，并评价此软件项的特性
软测目的
以最少的人力物力时间找出软件中潜在的各种错误和缺陷，回避这些错误和缺陷给软件造成的商业风险
发现当前开发工作所采用的软件过程的缺陷，修正软件开发规则
对软件质量进行度量和评估，以验证软件的质量满足用户的需求
对软件质量进行度量和评估，以验证软件的质量满足用户的需求
软件质量保证
概念：贯穿软件项目整个生命周期的有计划的系统活动，经常针对整个软件项目质量计划执行情况进行评估，检查和改进，确保项目质量与计划保持一致
软件可靠性：软件在规定的运行环境中和规定的时间内无失效运行的概率。
1.2软件测试分类
按测试阶段分
单元测试：又称模块测试，针对软件设计中的最小单位程序模块进行正确性检查的测试工作
单元测试的内容
模块接口
局部数据结构
重要的执行路径
错误处理
边界条件
单元测试采用的方法
为被测试模块编写驱动模块和桩模块来实现被测试单元的可运行。驱动模块模拟被测模块的上级调用模块来驱动被测模块，接收被测模块的测试结构并输出。桩模块模拟被测模块所调用的模块，作用是返回被测模块所需要的信息
集成测试：又称组装测试，通常在单元测试的基础上，对所有程序模块进行有序的，递增的测试。重点测试不同模块的接口部分
确认测试：又称有效性测试，目标是验证软件的功能和性能以及其他特性是否与用户的要求一致
系统测试：将整个软件系统看为一个整体进行测试，包括对功能、性能、以及对软件所运行的软硬件环境进行测试。
验收测试：按照项目任务书或合同、供需双方约定的验收依据文档进行的对整个系统的测试与评审，决定接收或拒收系统
按使用的测试技术划分
静态测试
动态测试
黑盒测试：又称数据驱动测试，不考虑程序内部的结构和特性，注重于测试软件的功能需求。只关心软件的输入数据和输出数据
白盒测试：也称结构测试或逻辑驱动测试，是针对被测单元内部如何进行工作的测试。根据程序的控制结构设计测试用例，主要用于软件或程序验证。
按测试项目划分
性能测试：测试软件是否达到需求规格说明中规定的各类性能指标，并满足相关的约束和限制条件
一般性能测试
可靠性测试
负载测试：是通过逐步增加系统负载，测试系统性能的变化，确定系统所能承受的最大负载量
压力测试：对系统不断施加压力的测试，通过确定一个系统的瓶颈或者不能接收的性能点，获得系统能提供的最大服务级别的测试
功能测试
逻辑功能测试
界面测试
易用性测试
安装测试
兼容性测试：测试软件在一个特定的硬件/软件/操作系统/网络等环境下的性能如何。
其他
回归测试：软件被修改后重新进行的测试，如重复执行上一个版本的测试用例，是为了保证对软件所做的修改没有引入新的错误而重复进行的测试
1.3软件缺陷管理
概念
软件未达到产品说明书中标明的功能
软件出现了产品说明书中指明的不会出现的功能
软件功能超出了产品说明书中指明的范围
软件未达到产品说明书中指明应达到的目标
软件难以理解和使用、运行速度慢，或最终用户认为不好
类型
界面
功能
性能
安全性
数据
其他
缺陷产生原因
软件本身
①需求不清晰，导致设计目标偏离客户需求
②系统结构非常复杂，导致意想不到的问题或系统维护、扩充上的困难
③对程序逻辑路径或数据范围边界考虑不够周全
团队工作
①系统需求分析时团队对客户的需求理解不清楚
②不同阶段的开发人员相互理解不一致。
③对于设计或编程上的一些假定或依赖性，相关人员没有充分沟通。
技术问题
①算法错误：在给定条件下没能给出正确或准确的结果
②语法错误：对于解释性语言程序，只能在测试运行时发现。
③计算和精度问题：计算的结果没有满足所需要的精度。
缺陷生命周期
书上的状态：新建、打开、指派、测试、延期、拒绝、确认、重新打开、关闭
1.4
1.5软件测试原则和测试停止原则
软件测试原则
证伪而非证真
尽早和不断地进行软件测试
重视无效数据和非预期使用习惯的测试
程序员应避免检查自己的程序
充分注意测试中的群集现象（二八原则）
用例要定期评审
测试停止原则
基于测试阶段的原则
基于测试用例的原则
基于缺陷收敛趋势及缺陷修复率原则
基于验收测试的原则
基于覆盖率的原则
软件项目暂停或终止，则测试活动也应相应暂停或终止
第二章 软件测试策略
2.1 软件开发过程及模型
开发过程
8个部分
开发模型
瀑布模型
快速原型模型
增量模型
螺旋模型
2.2 软件测试过程
2.3 软件测试与软件开发的关系
常见软件测试模型
V模型：最具有代表意义
W模型
H模型：强调软件测试是一个独立的流程，贯穿产品的整个生命周期，与其他流程并发地进行。“尽早准备，尽早执行”
X模型
前置测试模型
软件测试与软件开发各阶段的关系
2.4 黑盒测试和白盒测试
黑盒测试
概念：也叫数据驱动测试。不考虑程序内部的结构和特性，注重于测试软件的功能需求
白盒测试
概念：也叫结构测试或逻辑驱动测试。是针对被测单元内部如何进行工作的测试，它根据程序的控制结构设计测试用例
第三章 黑盒测试与测试用例设计
3.1 设计用例综述
测试用例：指的是在测试执行之前设计的一套详细的测试方案，包括测试环境、测试步骤、测试数据和预期结果。
设计测试用例基本原则
代表性
针对性
可判定性
可重现性
测试用例设计步骤
测试需求分析
业务流程分析
测试用例设计
测试用例评审
测试用例更新完善
黑盒测试优缺点
优点
定位问题准确
可以证明是否达到用户要求的功能
能重复执行相同的操作
缺点
测试人员需要具有较多经验
测试过程中很多是手工操作
测试人员需要负责大量文档
3.2 等价类设计方法
等价类划分
概念：解决如何选择适当的数据子集代表整个数据集的问题，通过降低测试的数目去实现“合理的”覆盖，覆盖了更多的可能数据，以发现更多的软件缺陷
有效等价类
无效等价类
3.3 边界值设计方法
概念：对输入输出的边界值进行测试的一种黑盒测试方法
设计方法
确定边界情况
选取正好等于、刚刚大于或刚刚小于边界值作为测试 数据
3.4 因果图设计法
概念：是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件的各种组合情况
基本符号
恒等→
非→
~
~
或V
与^
约束符号
E(互斥、异或)：表示两个原因不会同时成立，两个中最多有一个可能成立
I(包含、或)：表示三个原因中至少有一个必须成立
O(唯一)：表示两个原因中必须有一个，且仅有一个成立
R(要求)：表示两个原因，a出现时，b也必须出现，a出现时，b不可能不出现
M(强制)：两个结果，a为1时，b必须是0，当a为0时，b值不定
设计测试用例
因果图方法是根据输入和输出之间的因果关系来设计测试用例的。
3.5 正交实验设计方法
概念：根据正交性从全面试验中挑选出部分有代表性的点进行试验，这些有代表性的点具备了“均匀分散，齐整可比”的特点
正交表的构成
行数
正交表中行的个数，行数=因素数*(水平数-1)+1。
因素数
正交表中列的个数，要测试的功能点
水平数
任何单个因素能够取得的值的最大个数。比如只能有选或不选两种可能，水平数为2
正交表表示
L行数(水平数因素数)
正交表元素
n行，其中第j列由数码1，2，… Sj 组成，这些数码均各出现n/Sj 次
第四章 白盒测试
PPT中
穷举路径测试后仍存在错误的原因
无法检查出程序本身是否违反了设计规范，即程序是否是一个错误的程序
不可能查出程序因为遗漏路径而出错
发现不了一些与数据相关的错误
计算环形复杂度
V(G) = E-N+2，其中，E是控制流图中边的数量，N是控制流图中的节点数量。
4.1 程序控制流图
4.2 逻辑覆盖测试
逻辑覆盖
语句覆盖：又称行覆盖，段覆盖，基本块覆盖，度量被测代码中每个可执行语句是否被执行到了
判定覆盖：又称分支覆盖，设计足够多的测试用例，使得程序中的每一个判断至少获得一次"真"和一次"假"
条件覆盖：使得每个判断中每个条件的可能取值至少满足一次
条件/判定组合覆盖：通过设计足够多的测试用例，使得每个判断中每个条件的可能取值至少满足一次，也使得程序中的每一个判断至少获得一次"真"和一次"假"
组合覆盖：执行足够多的测试用例，使得程序中每个判定的所有可能的条件取值都至少出现一次，满足这个一定满足前三个
路径覆盖：利用设计足够多的测试用例，覆盖程序中所有可能的路径
4.3
4.4
4.5 变异测试
概念：用变异技术来评价测试集的充分性或增强测试集。变异是一种变更程序的行为。
第五章 软件测试的过程管理
5.1 软件测试的各个阶段
测试需求的分析和确定
测试计划
测试设计
测试执行
测试记录和缺陷跟踪
回归测试
测试总结报告
5.2
5.3
5.4
5.5 测试的执行
冒烟测试：对软件的基本功能进行测试，保证软件系统能够正常运行，并且可以进行后续的正式测试工作。
0 条评论
下一页
