导图社区 测试理论总结
软件测试理论总结思维导图。详细的总结了，软件产品研发流程和质量，软件测试计划，测试用例，测试执行，软件测试基础等五个方面的知识点。
提示: 本内容由社区用户上传并分享。平台不对内容的真实性、合法性、知识产权归属及是否侵害第三方权利进行事前审核或保证。本内容可能包含受版权保护的图片、字体或其他第三方素材，使用前请自行确认授权范围。
Oracle Database，又名Oracle RDBMS，或简称Oracle。Oracle数据库系统是世界上流行的关系数据库管理系统，系统可移植性好、使用方便、功能强，适用于各类大、中、小微机环境。
一张思维导图带你了解APP专项测试性能指标需要做些什么，首先Monkey（测试APP稳定性），GT（测试APP的性能）。
社区模板帮助中心，点此进入>>
互联网9大思维
产品立项报告
组织架构-单商户商城webAPP 思维导图。
域控上线
产品经理如何做好项目管理
python思维导图
经验分享：产品经理必懂的产品思维
产品诞生过程
产品周期图
css
测试理论总结
软件产品研发流程和质量
软件产品定义
软件是一种逻辑产品，脑力劳动的结晶，需要依赖计算机才能发挥它的作用，以“程序”和“文档”的形式保存。
软件产品组成
包装
相关文档（使用说明书、安装说明书、维护手册）
源程序
软件由哪些角色完成
项目经理PM
需求分析工程师 BA（产品专员）
架构师PD
开发工程师PG
测试工程师TE
配置管理员CMO
项目管理工程师（QA）
软件工程
把系统化的、严格约束的、可量化的方法应用在软件开发、测试、运行以及维护上，提高软件开发的效率和质量
软件开发模型
瀑布模型（按阶段划分，按顺序不可逆，各阶段需要评审以及输出相关文档，通过后才能进入下一个阶段，测试后期才介入）
V模型（与瀑布模型比较，把测试进行了细分，分为单元测试、集成测试、系统测试、验收测试）
W模型（与V模型比较，测试提前介入，在需求评审通过后即可以开展测试工作）
快速原型法（分析需求文档，先把核心的功能先做出来，提前给用户体验，根据用户的反馈，及时修正，然后逐步把剩下功能添加版本中，直到所有需求完成为止。
敏捷迭代开发模型（根快速原型法差不多，只是加强了对人员的沟通管理、严格把控项目进度）
目的
满足用户需求
提高质量，降低成本
保证项目可管理，进度可控制
测试人员在整个项目中，运用自身知识和技能，创造出尽量完善的软件
软件的生命周期
需求
设计
编码
测试
维护
升级
废弃
软件测试的生命周期
测试计划
测试要点分析
测试方案
测试用例
测试执行
测试报告
Bug的生命周期
新建（测试人员）
打开并指派给开发人员（测试经理或开发经理或测试人员）
修复（开发人员）
验证（测试人员）
Bug已解决，关闭
Bug未解决，重新激活指派给开发人员继续修复
质量模型
质量：反映实体满足明确或隐含需要能力的特征总和
内部质量
外部质量
使用质量（站在用户的角度）
有效性
生产率
安全性
满意度
CMMI（能力成熟度模型集成）
1级 初始级 2级 已管理级 3级 已定义级（软件企业从3级开始评定） 4级 量化级 5级 持续优化级
PDCA循环（戴明环）
Plan 计划
Do 执行
Check 检查
Action 纠正
软件测试计划
定义
描述所有要完成的测试工作，包括被测试项目的目的，背景，范围，资源，进度，环境，测试任务分配以及测试有关的风险和措施等方面。
作用
测试过程提供指导
改善测试任务与测试过程的关系
提高测试组织，规划和管理能力
如何做好计划
认真做好测试相关资料的整理
可行性分析报告
软件需求规格说明书
明确测试目标，增强测试计划的实用性
采用评审和更新机制，保证测试计划满足实际需求
坚持“5W1H”规则明确内容与过程
内容
目的，背景，范围
测试进度
测试资源（人员、软、硬件、工具等）
测试环境（软件、硬件）
测试策略（功能测试、接口测试、自动化测试、性能测试、安全测试等）
测试风险
测试开始条件
软件的主要模块代码已实现
测试用例，测试代码准备完成
测试环境搭建完毕
冒烟测试通过
测试结束条件
正常结束
需求覆盖率（100%实现）
Bug解决率（95%已解决，没有致命和严重Bug存在）
达到预定质量目标
用例执行率（100%执行）
异常结束
关键功能未实现
出现大量有严重BUG
人员不足
测试环境不满足要求
资源短缺
测试环境
分类
开发环境(公司内部用，提供给开发人员自测用) 测试环境（公司内部用，提供给测试人员使用） 现场环境（用户现场真实使用环境）
环境包括
软件（操作系统、数据库等）
硬件（客户端、服务器、其它终端设备）
进度风险
人员风险
成本风险
质量风险
变更风险
测试用例构成元素
用例编号、用例标题、优先级、预置条件、操作步骤、预期结果、备注
编写用例注意事项
语言描述简洁、清晰，无歧义
用例要素齐全，操作步骤详细，容易让其它测试工程师读懂
用例的执行状态
通过
不通过
阻塞
观察
未执行
用例的评审流程
1.项目管理工程师提前2~3天将测试用例已邮件方式发给相关的项目组人员审查 2.2~3天后会召开用例评审会（一般控制在2个小时内），对用例的书写规范、需求覆盖等多方面进行评审 3.相关人员反馈用例存在的问题，确定负责人与完成时间，由项目管理工程师进行会议纪要 4.会议结束后，项目管理工程师已邮件方式发送会议纪要给相关人员，要求负责人在规定的时间内修改完成 5.用例修改完后再已邮件方式进行地评审
测试环境组成
硬件环境
软件环境
网络环境
测试时间够怎么办？
加班
加人
向领导申请延期
缺陷状态
以禅道为例： 激活 已解决 已关闭
缺陷等级划分
1级;致命 2级：严重 3级：一般 4级：轻微或建议
怎么样才算是缺陷？
功能未实现
功能实现不完整
多余功能
运行出错
数据结果错误或精度不够
难理解、不方便使用、运行缓慢、界面不好看
所有的BUG都要修改吗？什么情况下可以不修改？
发布前不一定要把所有的Bug都要解决，只要bug解决率95%以上，允许遗留一些一般或轻微的bug,但不能存在有致命和严重的。
缺陷生命周期
Bug提交-Bug处理-Bug验证-Bug关闭
一个缺陷包括哪些内容
Bug标题 测试环境描述 Bug严重程度 Bug优先级 内部版本号 Bug重现步骤、实际结果、期望结果 附件（截图、日志、录屏、抓包等）
概述、测试环境描述、测试过程记录与分析、测试过程评估、测试结果
测试总结
对整个测试周期过程的一个总结，把做得好的继续发扬，做得不足制定改进措施，避免再次出现。
软件测试基础
软件测试定义
用手工或者自动化的手段来运行被测系统的过程，其目的为了验证软件是否实现了需求规定的功能，或者是弄明白实际结果与预期结果之间的差别。
测试目的
最少人力、物力和时间
质量的度量与评估
过程改进
证明软件中存在错误
符合用户的需求
测试的原则
GoodEnough原则
木桶原则
8/2原则
尽早介入原则
以用户需求原则。。。。
测试对象
程序
数据
文档
确认与验证的区分
确认：确认软件是否满足用户的需求
验证：验证软件是否满足产品规格说明书
测试分类
按阶段
单元测试
集成/接口测试
系统测试
验证测试
是否运行
静态
动态
查看代码
白盒
黑盒
功能
逻辑功能
界面
易用
安装
兼容
性能
负载测试
压力测试
稳定性测试
基准测试
配置测试
其它
冒烟测试
回归测试
随机测试
安全测试
探索性测试
测试人员的素质
基本素质
责任心、耐心、专心、自信心、细心 沟通能力好、洞察力、发现问题的敏锐度 语言及文字的表达能力 逻辑与发散思维能力 团队协作能力 日常突发事件处理能力
专业素质
熟悉产品业务知识，较强的需求理解能力 熟悉软件测试理论基础知识和测试流程 掌握各种测试技术和方法 熟练常用测试工具的使用 具有一定的编程能力 掌握质量管理知识
5W
功能性
可靠性
易用性
效率
维护性
可移植性
