测试概论思维导图
U891948118
2025-03-02
测试概论
软件质量
缺陷管理
软件生命周期，测试流程，缺陷管理相关内容讲解
树图思维导图提供《测试概论》在线思维导图免费制作，点击“编辑”按钮，可对《测试概论》进行在线思维导图编辑，本思维导图属于思维导图模板主题，文件编号是：523ee64e0605c91b26c75ca4b7ab3984
思维导图大纲
相关思维导图模版
测试概论思维导图模板大纲
软件生命周期与测试流程
软件生命周期
项目计划
角色：项目经理
职责
组织项目人员
制定时间进度安排
分配测试任务
识别项目风险
项目范围
成本、目标、技术
产出：软件项目计划
需求分析
角色：产品经理/业务分析师
职责
与客户沟通交流；市场调研
多方面分析客户的需求
功能
性能
兼容
界面
产出：软件需求规格说明书（SRS）
Software Requirement Specification
设计
概要设计
角色：架构师
职责
根据需求、项目计划制定整个软件系统的框架
完成框架设计文档（数据库表结构；模块设计）
产出：概要设计文档（HLD）
High Level Design
详细设计
角色：高级开发工程师
职责
根据需求、项目计划、概要设计对基本单位做详细设计
完成详细设计文档（具体表的内容、函数编写规范）
产出：详细设计文档（LLD）
Low Level Design
实施（编码）
角色：开发工程师
职责
计划、详细设计文档创建数据库；编写函数代码
整合代码
产出：Codes
测试
角色：测试工程师
职责
根据项目计划、需求、设计文档完成测试工作
测试计划、方案、用例、脚本、执行测试、缺陷
产出：各种测试计划、方案、用例、脚本、缺陷报告、总结报告
运行与维护
角色：运维人员
职责
部署环境
安装软件
解决用户问题
反馈用户问题
评价
角色：客户
职责
使用
反馈问题
评价
产出：吐槽；五星好评
测试的概念
狭义测试概念：找bug；运行被测试程序或者软件系统；测试是在开发工作完成之后进行
广义测试概念：证明符合预期，检测问题；可以运行也可以不运行；测试工作是贯穿于整个软件生命周期
IEEE：使用人工和自动化手段运行后者测试某个系统的过程；其目的在于检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差别
测试目的
证明：软件能够使用--功能
检测：发现不足与缺陷；表现更好；功能不足、性能不足、界面不美观
预防：不足缺陷分析避免再次发生
测试流程
单元测试
概念：对软件系统最基本单位（函数、类、表）进行测试--组件测试
依据：详细设计说明书
测试方法：白盒测试方法为主（细节--内部结构）
考察基准：逻辑覆盖率
集成测试
概念：针对完成单元测试的函数、类、表进行组装的测试（组装测试，联合测试）
依据：概要设计文档
测试方法：白盒+黑盒--灰盒
考察基准：接口测试覆盖率
系统测试
概念：将完成集成的测试软件系统作为一个元素和其他软硬件进行整体的测试
依据：软件需求规格说明书
测试方法：黑盒测试方法为主
考察基准：需求覆盖率
验收测试
概念：用户参与测试（UAT：User Acceptance Testing）
依据：验收合同；用户手册
测试方法：黑盒测试方法
验收测试类型
Alpha测试（内测）：潜在用户在开发环境下有开发人员在现场对测试进行记录，整个测试过程可控。
Beta测试（公测）：潜在用户在真实环境没有开发人员在现场做记录，整个测试过程不可控。
回归测试
概念：修复了缺陷或者对代码进行修改添加删除的操作，因为修改有些用例会受到影响，对受到影响的测试用例再次测试--回归测试（Regression Testing）
策略
选择回归测试
覆盖修改法
周边影响法
指标达成法
完全重复回归测试
测试活动
测试模型
瀑布模型
特点
一次性计划好所有的项目工作
只有一个测试活动
不能适应变化
适合项目
规模小
复杂度低
需求稳定
V模型
特点
将测试阶段化
每一个测试阶段都对应一个开发工作
测试没有尽早开始
适合项目
大多数项目
频繁变化的项目
双V模型
特点
将测试阶段化
每一个测试阶段都对应开发工作
测试工作尽早开始和开发工作并行
测试设计工作的顺序和测试执行工作的顺序相反
适合项目
规模大
比较复杂
测试活动
测试计划
角色
测试经理/组长
职责
制定测试计划
制定测试进度、确定测试范围、测试组织形式；安排测试任务、制定测试目标、识别测试风险、确定总体的测试技术、标准。
工作产出
测试计划
单元测试计划
集成测试计划
系统测试计划
测试设计
角色
测试分析设计师
职责
制定测试方案
指导如何编写测试用例脚本、细化测试工作范围内容、如何搭建测试环境、运用测试工具、提交缺陷跟踪缺陷、指定回归测试 版本和确定回归测试策略、测试数据。
工作产出
测试方案
单元测试方案
集成测试方案
系统测试方案
测试实现
角色
测试工程师
职责
编写测试用例、测试脚本、测试规程（说明测试用例执行顺序的一份文档）
工作产出
单元测试用例、脚本、规程
集成测试用例、脚本、规程
系统测试用例、脚本、规程
测试执行
角色
测试工程师
职责
搭建测试环境、准备测试数据、执行测试用例、记录测试用例执行结果、提交缺陷、跟踪缺陷、回归测试
编写阶段测试报告（测试经理/测试组长）
工作产出
单元测试缺陷报告、总结报告、测试用例执行结果记录
集成测试缺陷报告、总结报告、测试用例执行结果记录
系统测试缺陷报告、总结报告、测试用例执行结果记录
测试用例写作和缺陷管理
测试用例写作
测试用例的概念
Test Case：测试的一种具体情况
测试用例是测试工程师进行测试执行工作的指导性文件。通俗的说 ，告诉测试工程师，怎么测试一种情况（准备，步骤，预期结果）
测试用例的作用
防止测试的遗漏
防止测试的重复
可以做到复用
可以发现测试依据（LLD；HLD；SRS）中的缺陷；
可以估算测试的工作量
如何编写测试用例
测试用例编号
作用：唯一性；可识别性
要求：从大到小
系统测试用例（SRS）：产品名称（项目名称）--测试阶段--系统测试项--系统测试子项--序列号
微信文字聊天功能：Wechat--ST--Function--Chat--Text--01
集成测试用例（HLD）：产品名称（项目名称）--测试阶段--集成测试项--集成果测试子项--序列号
微信支付接口：Wechat--IT--Pay--Didi--01
单元测试用例（LLD）：产品名称（项目名称）--测试阶段--单元测试项--单元测试子项--序列号
微信点赞函数：Wechat--UT--Praise--Cancel--01
测试项
作用：分类
命名规则：可以用某个名称涵盖这一类测试用例的共同属性
系统测试：需求项名称
微信文字聊天功能
集成测试：接口名称
微信支付接口
单元测试：类名、函数名、表名
微信点赞函数
测试用例名称
作用：测试用例的独特的特点，测试用例的目的
命名规则：直接说明测试用例具体的测试点要达到的测试目的
系统测试
微信文字聊天发送9张JPG图片
集成测试
微信支付调用美团退款接口
重要级别（优先级）
作用：进度资源紧张时轻重缓急的区分
划分原则（3~4级）
高
定义：基本功能、重要特性或者核心业务、使用频率比较高
微信：注册、登录、聊天、通讯录、朋友圈；支付
中：备选的非主流非核心业务、使用频率中等
微信：卡包；收藏；微信小程序
低：使用频率不高、对系统业务功能影响不大的模块的测试用例
微信：摇一摇；看一看
预置条件（可选）
作用：完成某些用例需要提供的一些特别的条件
根据用例的实际需要确定是否有预置条件存在的必要
通信测试：114
没有sim卡
手机5G的网络情况
5G信号
输入
作用：测试用例执行的具体数据信息
要求：具体明确。不要用模糊概括的语言
五个简体汉字：你今天真帅
10个英文字符：helloworld
三张100K的JPG图片
操作步骤
作用：指导测试人员具体的动作与操作
要求：动词、具体；不能有分支的描述（如果；或者）
建议：输入；点击；打开；双击左键；单击右键；敲回车
预期结果
作用：判断测试用的结果是否正确
要求：具体明确。不要用模糊概括语言
输入到什么介质上：显示屏上；输出到打印机；打印凭条
显示信息；信息的顺序；信息加密（身份证号、手机号码、账户余额、密码显示多少位，加密哪几位）
案例
缺陷管理
缺陷报告
什么是缺陷
实际与预期不一致，软件中存在一些不足、错误和需要做的改进
错误、人为主观原因造成
什么是缺陷报告
将A线的缺陷以标准的文字记录方式呈现出来
缺陷报告的作用
不会造成缺陷的遗漏
让所有参与缺陷跟踪的人员对缺陷的信息了解一直并且理解一致
根据缺陷报告中的信息做各种缺陷分析工作，从而起到预防的作用
缺陷跟踪（管理）流程
如何编写缺陷报告
摘要信息（简单描述）
说明：对所发现的缺陷用精简的语言直接陈述实际问题
举例：已存在QQ号码正确密码登录失败
缺陷提交人（发现人）
说明：缺陷理解不一致；缺陷修复之后需要再次验证
缺陷提交时间
说明：缺陷的修复时间（优先级）
严重程度
说明：从用户角度考虑，对使用系统的影响有多大
致命的：程序崩溃（闪崩）；数据丢失
高级：主要功能无法使用；重要特性不符合要求
中级：次要功能，不太重要特性不符合要求
低级：文字错误，不友好
举例
致命的：微信发送图片微信闪退；某个收费系统的用户账单信息丢失
高级：微信朋友圈无法发图片
中级：微信支付不能每次超过1000块
低级：账号--帐号；登录--登录
优先级
说明：从开发人员角度考虑，缺陷提交之后响应的修改时间
非常紧急：当天修改（当前版本改）
高级：三天之内（下一个版本修改）
中级：五天之内（三个版本修改）
低级：两周之内（五个版本修改）
重现
是/否
重现率/重现次数
至少重现三次
缺陷的详细描述（重现步骤）
类似于测试用例的操作步骤
简化与缺陷重现无关的步骤
具体的操作步骤、数据
预期结果
实际结果
初步分析
测试阶段
单元测试
集成测试
系统测试
验收测试
测试类型
功能测试
性能测试
安全测试
GUI测试
兼容
。。。。。
测试模块（需求）
测试用例项（测试用例标题）
测试版本
测试环境
缺陷状态
跟踪缺陷记录缺陷的处理过程
新建
打开
修复
关闭
重新打开
延迟
重复
无效缺陷
拒绝/放弃
指派人
附件
截图
log日志
录屏
缺陷的跟踪管理流程
软件质量
软件质量的概念
什么是质量
一个实体的所有特性，基于这些特性可以满足明显的或隐含的需求。质量就是基于这些特性满足需求的程度。
什么是软件质量
软件质量就是软件这类实体基于软件特性满足需求的程度
功能
效率
可靠性
易用性
可移植性性
可维护性
评价需求的层次
符合需求规格（开发者明确定义的目标）
符合用户显式需求（符合用户明确说明的目标）
符合用户实际需求（符合实际用户使用的需求；包括未明确说明的行业规范）
软件质量的要素（质量铁三角）
流程：将最终目标（成本、进度、范围，质量）分解到各个活动，使得整个生产过程可见。
软件开发过程
测试过程
缺陷管理过程
评审过程
技术：方法论；工具；仪器；技术人才（高学历，专项技术）；经验；专利
开发技术
网络技术
测试技术
黑白盒
自动化
分析设计技术
组织
引进流程；使用流程；监督流程；改进流程
引进技术；发展技术；招聘技术人才
软件质量模型
涉及到软件生命周期的质量种类
过程质量
内部质量
单元测试、集成测试
外部质量
系统测试
使用质量
验收测试
软件质量模型
ISO9126
功能性
概念：当软件在指定条件使用时，软件产品提供满足明确和隐含需求的功能能力
子特性
适合性
概念：软件产品为指定的任务和用户目标提供一组合适的功能能力。
举例
OA管理软件人事总监
遗漏
要求：可以查看考勤信息；可以查看薪酬体系；可以批准请假和加班
实际：可以查看考勤信息；可以查看薪酬体系；可以批准请假
额外实现
要求：可以查看考勤信息；可以查看薪酬体系；可以批准请假和加班；查看公司财务报表
有没有（遗漏；画蛇添足（额外实现）
准确性
概念：软件产品提供具有所需精确度的正确或相符结果或效果的能力。
举例
OA管理软件人事总监
要求：可以查看三月内考勤信息；可以查看薪酬总监级别以下体系；可以批准请假（10天）和加班（8天）
要求：可以查看当月内考勤信息；可以查看薪酬部门经理级别以下体系；可以批准请假（5天）和加班（3天）
对不对
互操作性
概念：软件产品与一个或更多的规定系统进行交互的能力。
举例
OA软件
软件系统内部交互：申请出差；出差报销；填写费用报销调用出差申请单
软件系统外部交互：OA的报销申请可以通过钉钉进行通知
软件和硬件交互：OA报销单打印到打印机上
安全保密性
概念：软件产品保护信息和数据的能力。
I：防止未得到授权的人或系统访问相关信息的能力。
II：保证得到授权的人或系统能正常访问相关信息或数据
举例
OA软件：系统管理员能够查看到所有用户的信息可以去进行密码的重置
OA软件：普通员工看到薪酬体系
其他安全：注册；密码；密码次数限定；密码加密；SQL注入。。。。。。。
功能性的依从性
可靠性
概念：在指定条件下使用时，软件产品维持规定的性能级别的能力。
子特性
成熟性
概念：软件产品为避免由软件中错误而导致失效的能力。
举例：软件长时间使用闪退
内部接口防范
容错性
外部接口防范
概念：在软件出现故障或者违法指定接口的情况下，软件产品维持规定性能级别的能力。
举例：OA上传一个超大文件，报错了，正常使用。
易恢复性
概念：在失效的情况下，软件产品重建规定性能级别的能力。
举例：闪退--重启；超大文件--出错--删除超大文件，恢复正常。
可靠性的依从性
易用性
概念：在指定的条件下使用时，软件产品被理解、学习、使用和吸引用户的能力。
子特性
易理解性
概念：软件产品使用户能理解软件是否合适以及如何将软件用于特定任务和使用环境的能力。
举例：快捷键；图标按钮；提示信息
易学性
概念：软件产品使用户能学习其应用的能力。
举例：在线帮助；用户手册；使用向导。
易操作性
概念：软件产品使用户操作和控制它的能力。
举例：特斯拉的刹车不易操作；苹果手机的铃声设置需要Itunes同步
吸引性
概念：软件产品吸引用户的能力。
举例：游戏的界面色彩人物造型；标题党（门户新旺，视频）
易用性的依从性
508法案（弱视群体）
效率
概念：在规定条件下，相对于所用资源的数量，软件产品可提供适当性能的能力。
子特性
时间特性
概念：在规定的条件下，软件产品执行其功能时，提供适当的响应时间和处理时间以及吞吐率的问题。
举例：网站
纯文本
静态图片
动态图片
视频
资源利用性
概念：在规定的条件下，软件产品执行其功能时，使用合适资源的数量和类别的能力。
举例：网站
纯文本
静态图片
动态图片
视频
效率依从性
可维护性
概念：软件产品可被修改的能力。
子特性
易分析性
概念：软件产品诊断软件中的缺陷或失效的原因或识别待修改部分的能力。
举例
代码注释行；Log日志
易改变性
概念：软件产品使指定的修改可以被实现的能力。
举例
高内聚；低耦合
稳定性
概念：软件产品避免由于软件修改而造成意外结果的能力。
举例
高内聚；低耦合
易测试性
概念：软件产品使已修改软件能被确认的能力。
举例
白盒测试：程序插装（被测试代码写入测试代码）
可维护性的依从性
可移植性
概念：软件产品从一种环境迁移到另外一种环境的能力。
子特性
适应性
概念：软件产品无需采用有别于考虑该软件的目的而准备的活动或手段就可能使用不同指定环境环境的能力。
举例
微信：PC端微信；Web版微信；IOS；Andriod；Linux；Mac
某个Web系统：不同浏览器
易安装性
概念：软件产品在指定环境中被安装的能力。
举例
安装步骤，安装之前的准备（格式化；重新格式化硬盘格式）
卸载
复杂的命令行；查看端口号；修改端口；环境变量
共存性
概念：软件蟾皮在公共环境与其分享公共资源的其它独立软件共存的能力。
举例
360和腾讯
不同浏览器
不同杀毒软件
易替换性
软件产品在同样的环境下，替代另一个相同用途的指定软件产品的能力。
举例
Office中表格、文档用WPS打开
Outlook中的邮件通过Foxmail
Office2007的表格文档用Office2010版打开
软件补丁
可移植性的依从性
各大特性的依从性
法律法规行业标准规范。企业规则
国家税法
国家电商法
航空标准
银行、保险、正确规则
查看更多
相似思维导图模版
首页
我的文件
我的团队
个人中心