测试理论基础，X-mind 思维导图
点此下载：https://download.csdn.net/download/qq_41126139/15765634
- 2-1.3.1 软件测试对象
- 2-1.3.2 软件测试定义
- 2-1.3.3 软件测试目的
- 2-1.3.4 软件测试原则（11个）
- 2-1.3.5 软件测试模型
- 2-1.3.6 软件发布标准
- 2-1.3.7 软件测试交付件
2-1.1 软件基础
2-1.1.1 软件定义
- 软件定义：由文档、数据及程序组成。
- 程序：源程序、目的程序。
2-1.1.2 软件生命周期
计划 - 需求分析 - 设计 - 编码 - 测试 - 运维上线
-
计划
角色：项目经理
职责：确定时间安排、人员分工、资源成本、风险评估等。 -
需求分析
角色：需求人员
输出：需求规格说明书（SRS） -
设计
角色：设计人员
输出：概要设计说明书（HLD）、详细设计说明书（LLD）、数据库设计说明书 -
编码
角色：编码人员
输出：程序代码 -
测试
角色：测试人员
输出：测试计划、测试方案、测试用例、缺陷报告 -
运维上线
角色：运维人员
2-1.1.3 软件研发模型
-
瀑布模型
特征：自上而下，线性，测试在编码后。
优点：需求稳定，重复工作少，软件质量高。
缺点：周期长，成本高。
场景：适用于大型、国企、高质量的项目（如生命财产安全） -
螺旋模型
特征：强调风险，适用于复杂、风险高的项目
流程：制定计划 - 风险分析 - 实施过程 - 客户评估
迭代周期：平均为 3 - 6 个月 -
敏捷开发 Scrum 模型
特征：适用于用户需求变化频繁的项目
迭代周期：平均为 3 - 4 周
优点：周期短，成本低
缺点：需求变更频繁，重复工作多，软件质量下降
2-1.1.4 软件项目组成人员
- IT公司技术部门：
- 产品部：用户需求文档，界面原型图，预期结果
- 研发部：程序（源程序、目的程序），实际结果
- 测试部：比对实际结果与预期结果之间的差别
- 运维部：运维上线，后期维护
- 软件项目组成人员：
（1）项目经理
（2）需求人员：需求规格说明书（SRS）
（3）设计人员：概要设计说明书（HLD）、详细设计说明书（LLD）、数据库设计说明书
（4）编码人员：程序代码
（5）测试人员：测试计划、测试方案、测试用例、缺陷报告
（6）运维人员
（7）配置管理人员：使用专业的配置管理工具管理配置项。
配置项：软件研发的所有输出物，主要包括文档和代码等。
（8）质量保障人员（QA） ，目的：预防缺陷
职责：
（1）制定软件规范和流程；
（2）监督项目成员是否遵循规范和流程；
（3）评审项目成果。
2-1.2 软件质量
2-1.2.1 软件质量定义
软件质量定义：实体基于实体特性满足需求的程度。
2-1.2.2 软件质量层次
软件质量层次：
- 满足需求规格
- 满足用户的显示需求
- 满足用户的实际需求（显示需求 + 隐式需求）
2-1.2.3 软件质量铁三角
质量三要素：组织、技术、流程。
2-1.2.4 软件质量模型
| （1）功能性 | |
|---|---|
| 适合性 | 软件是否提供基本功能 |
| 准确性 | 软件提供的功能是否准确 |
| 互操作性 | 系统之间的接口 |
| 保密安全性 | 是否安全地提供功能 |
| 功能性的依从性 | 提供的功能是否遵循国标、行内标准、用户习惯等 |
| （2）可靠性 | |
| 成熟性 | 软件可以很好地处理消化内部错误 |
| 容错性 | 软件可以很好地处理外部错误 |
| 易恢复性 | 软件失效后，可以恢复到正常状态的能力 |
| 可靠性的依从性 | 提供的功能是否遵循国标、行内标准、用户习惯等 |
| （3）易用性 | |
| 易理解性 | 界面显示是否清晰易懂 |
| 易学性 | 提供帮助信息 |
| 易操作性 | 操作步骤简单，导航菜单不要超过三级 |
| 吸引性 | 界面美观 |
| 易用性的依从性 | 提供的功能是否遵循国标、行内标准、用户习惯等 |
| （4）效率 | |
| 时间特性 | 软件中某个操作需要的时间 |
| 258原则： （1）< 2s：用户感觉良好 （2）2 ~ 5s：用户可以接受 （3）5 ~ 8s：用户可以忍受 （4）> 8s：用户不能忍受 | |
| 资源特性 | 软件占用的资源，如CPU、内存、电量、流量等 |
| 效率的依从性 | 提供的功能是否遵循国标、行内标准、用户习惯等 |
| （5）可移植性 | |
| 适应性 | 产品适应不同环境的能力（兼容性） |
| 易安装性 | 在不同环境下安装是否方便 |
| 易替换性 | 软件的升级与降级是否方便 |
| 共存性 | 软件是否能与其他软件共同使用 |
| 可移植性的依从性 | 提供的功能是否遵循国标、行内标准、用户习惯等 |
| （6）维护性 | 内部质量 |
| 易分析性 | 是否容易定位缺陷（日志记录） |
| 易改变性 | 增加功能是否方便 |
| 易测试性 | 可以直接看到页面打开时间 |
| 稳定性 | 修改尽量少，尽量修改界面 |
| 维护性的依从性 | 提供的功能是否遵循国标、行内标准、用户习惯等 |
2-1.2.5 软件质量管理体系
- ISO9000系列标准，ISO：国际标准化组织。
- CMM：软件能力成熟度模型，用于评估软件公司级别。
- CMM 级别：
（1）初始级
（2）已重复级：经验积累
（3）已定义级：过程规范
（4）已管理级：过程受控
（5）优化级：关注过程改进
2-1.3 软件测试基础
2-1.3.1 软件测试对象
软件测试对象：软件，软件包含文档、数据及程序，程序包含源程序和目的程序。
2-1.3.2 软件测试定义
软件测试定义：
使用人工或自动化的手段来运行或测试某个系统的过程，其目的在于检验系统是否满足规定的需求，或是弄清楚实际结果与预期结果之间的差别。
- 测试人员职责：制定计划与方案、分析并参与需求讨论、编写测试用例、测试执行
2-1.3.3 软件测试目的
软件测试目的：
- 测试是为了发现程序中的错误而执行程序的过程
- 好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案
- 成功的测试是发现了至今为止尚未发现的错误的测试
- 测试并不仅仅是为了找出错误，通过分析错误产生原因和错误的发生趋势，提高软件质量
2-1.3.4 软件测试原则（11个）
- 所有的测试都应该追溯到需求阶段；
- 测试工作应该由第三方进行；
- 尽早开始测试工作；
- 穷尽测试是不可取的；
- 测试是有风险的；
- 前进两步，后退一步：回归测试；
- 并非所有的缺陷都值得修复；
- 缺陷具有集群效应；
- 杀虫剂怪事：缺陷免疫测试用例；
- 帕累托法则（28原则）：80%的缺陷存在于20%的核心业务模块中；
- good-enough 原则：既不要做过分的测试，也不要做不充分的测试。
2-1.3.5 软件测试模型
软件测试模型：V 模型、W模型
- V 模型
-
特征：
（1）左边开发流程，右边测试流程
（2）左边每个开发环节的输出，作为右边每个测试环节的输入
（3）测试在编码后 -
流程：
用户需求 - 需求分析 - 概要设计 - 详细设计 - 编码 - 单元测试 - 集成测试 - 系统测试 - 验收测试
-
V字模型的设计阶段对应的测试阶段包括：单元测试和集成测试
- W 模型
-
特征：
（1）左 V 开发流程，右 V 测试流程
（2）在开发工作的需求、设计和编码阶段，测试工作分两部分：
一部分：对需求文档、设计文档进行测试
另一部分：根据文档进行相应的测试设计工作
（3）强调测试工作与开发工作并行启动 -
流程：
（1）开发工作：用户需求 - 需求分析 - 概要设计 - 详细设计 - 编码 - 集成 - 实施 - 交付
（2）测试工作：验收测试设计 - 需求规格说明书测试 & 系统测试设计 - 概要设计说明书测试 & 集成测试设计 - 详细设计说明书测试 & 单元测试设计 - 单元测试 - 集成测试 - 系统测试 - 验收测试
2-1.3.6 软件发布标准
- 完成测试计划中的各个环节
- 测试各阶段的输出均达到项目需求，如测试计划、测试方案、测试用例、缺陷报告、测试总结报告等
- 测试对需求的覆盖率达到100%
- 验收测试通过
2-1.3.7 软件测试交付件
软件测试交付件：测试计划、测试方案、测试用例、缺陷报告、测试总结报告
2-1.4 测试方法
测试方法按照测试技术、动静态、人工自动化划分。
2-1.4.1 按测试技术划分
- 白盒测试：分析程序代码，查找缺陷。
- 黑盒测试：不关注内部代码，通过界面的输入验证输出与预期结果是否一致。
- 灰盒测试：白盒测试 + 黑盒测试。
2-1.4.2 按是否动态运行软件划分
- 动态测试：运行软件，查找缺陷。
- 静态测试：不运行软件，主要涵盖文档测试、需求评审、代码走查、用例评审等。
2-1.4.3 按是否使用自动化工具划分
- 人工测试
- 自动化测试
2-1.5 测试过程
2-1.5.1 单元测试（UT，Unit Testing）
- 测试范围：最小单位，如函数、类
- 测试依据：详细设计说明书（LLD）
- 测试方法：白盒测试
- 评估标准：逻辑覆盖率
2-1.5.2 集成测试（IT，Integration Testing）
- 测试范围：模块与模块之间的接口，以及集成后的功能
- 测试依据：概要设计说明书（HLD）
- 测试方法：灰盒测试
- 评估标准：接口覆盖率
2-1.5.3 系统测试（ST，System Testing）
- 测试范围：整个系统的功能及非功能
- 测试依据：需求规格说明书（SRS）
- 测试方法：黑盒测试
- 评估标准：测试用例对需求的覆盖率
- 系统测试执行活动
（1）搭建测试环境
（2）冒烟测试（预测试）
（3）转系统测试评审（可选）
（4）执行测试用例，填写测试执行记录
（5）提交并跟踪缺陷报告
（6）回归测试，直到最后一轮未发现缺陷，软件发布上线
（7）测试总结报告
2-1.5.4 验收测试（UAT，User Acceptance Testing）
- 正式验收测试
- 特征：适用于外包项目，根据合同、需求规格、验收计划等，项目组成员与用户在客户现场开展测试。
- 结果：客户可以接受，客户不能接受。
- 非正式验收测试
- 特征：适用于游戏项目。
- α 测试：内测，项目组成员和用户在开发场地进行测试，有技术人员指导。
- β 测试：公测，用户在实际环境进行测试，无技术人员指导。
2-1.5.5 回归测试（Regression Test）
- 回归测试适用于各个测试阶段，包括单元测试、集成测试和系统测试。
- 职责：
- 验证缺陷是否修复正确；
- 重复测试，验证对系统的变更没有影响到以前正常的功能。
- 策略：
（1）完全重复测试：对所有测试用例进行测试，工作量巨大，可考虑自动化。
（2）选择性重复测试：
a. 覆盖修改法：缺陷修复所在模块的其他点需要重复测试
b. 周边影响法：缺陷修复所在模块相关联的其他模块需要重复测试
c. 指标达成法：确定一个指标，按照指标确定重复测试的用例数量
2-1.5.6 冒烟测试（Smoke Test）
- 在系统进行执行测试用例前，对软件的核心业务模块进行测试；
- 若在冒烟测试中发现许多致命的缺陷，则冒烟测试不通过，系统测试被挂起。
2-1.5.7 测试策略
测试策略（17种）：
（1）功能测试
（2）性能测试
（3）压力测试：测试系统在极限状态下的响应情况，找到系统的极限并发数
（4）负载测试：测试系统在预期并发数下的响应情况，达到预期值即可
（5）容量测试：测试软件消耗占用的资源
（6）兼容测试：测试系统在不同环境下的响应情况
（7）界面测试：测试软件的界面布局
（8）易用性测试：测试软件是否容易理解，操作是否简单
（9）可靠性测试：测试软件的容错能力及易恢复能力
（10）稳定性测试：测试系统在长时间不断操作下的响应情况
（11）安装测试：测试 C/S 架构软件是否正常安装
（12）卸载测试：测试 C/S 架构软件是否正常卸载
（13）升级测试：测试 C/S 架构软件是否正常升级
（14）接口测试：测试系统不同模块之间，客户端与服务器之间，系统与其他系统之间的接口
（15）文档测试：测试系统相关的所有文档
（16）网络测试：针对移动端 app 展开网络测试，如不同网络、弱网等
（17）安全测试：测试软件是否能安全地提供功能
集成测试：接口测试
Web系统测试：功能测试、性能测试（压力测试、负载测试、容量测试、兼容测试、界面测试、易用性测试、可靠性测试、稳定性测试等）
App 测试：安装、卸载、升级、网络测试、功能测试、性能测试
其他测试：安全测试、文档测试
- 兼容测试
（1）APP兼容测试时需要兼容不同类型的操作系统，需要兼容不同分辨率的手机
（2）Web系统兼容测试需要兼容不同操作系统，需要考虑浏览器兼容性：谷歌、火狐、IE等
2-1.6 软件测试活动
2-1.6.1 测试计划
交付件：测试计划
- 测试计划文档：管理型文档，由测试经理或测试主管完成，主要包括测试范围、人员安排、时间分配、测试资源、风险评估等。
2-1.6.2 测试设计
交付件：测试方案
- 测试方案文档：技术型文档，由高级测试工程师完成，主要包括测试环境、测试方法、测试策略等。
2-1.6.3 测试实现
交付件：测试用例、测试规程
- 测试用例：技术型文档、测试人员编写测试用例。
- 测试规程：执行测试时，测试活动的序列文档。
2-1.6.4 测试执行
交付件：测试报告（执行测试结果的文档）、测试日报（每天执行测试的记录）
- 测试人员执行测试用例，填写测试执行记录
- 提交并跟踪缺陷报告
- 验证缺陷修复是否正确
- 测试总结报告
2-1.7 测试用例
2-1.7.1 写好测试用例的关键要素
- 规范编写测试用例的每个要素
- 尽可能全面覆盖测试点
2-1.7.2 如何保证测试用例的覆盖率
- 测试需求100%覆盖
- 一个需求尽可能全面覆盖测试点
- 展开用例评审会议，进行查漏补缺
2-1.7.3 测试用例八大要素
- 用例编号：如 项目代号 - 模块名 - 序列号
- 测试模块：如 一级模块，二级模块
- 用例标题：每个用例的标题不重复，简洁写出每条用例的具体测试点
- 优先级：分为高中低，p1~p4，根据模块的重要程度划分
- 预置条件：第一个操作步骤可以执行下去，需要满足的前置状态
- 操作步骤：每个步骤前加序列号，并分行显示，步骤中写明测试点
- 测试输入：操作步骤中涉及的，符合测试点的一组参考数据
- 预期结果：写出结论和期望的软件界面现象
2-1.8 软件缺陷报告（禅道）
5C原则：准确（Correct）、清晰（Clear）、简洁（Concise）、完整（Complete）、一致（Consistent）
2-1.8.1 软件缺陷
2-1.1.4 软件缺陷
-
缺陷类型
（1）错误：软件实际效果与需求描述不一致
（2）遗漏：软件未实现明确规定的需求
（3）额外的实现：软件实现未明确规定的需求 -
严重性
（1）致命：系统崩溃、闪退、无响应等，需立即解决
（2）严重：基本核心功能出现问题，需在产品发布前解决
（3）一般：一般功能出现问题，时间允许会解决
（4）轻微：界面建议性问题，不影响使用，可能会解决 -
优先级
（1）最高：紧急处理，停止一切测试，立即修复
（2）次高：优先处理，在产品发布前，必须修复
（3）中等：正常排队，时间允许应该会修复
（4）最低：推迟修复，可能会修复 -
来源
（1）需求（主要）
（2）设计
（3）编码
（4）其他
2-1.8.2 缺陷管理工具
缺陷管理：禅道、bugzilla、bugfree、jira、QC（ALM）等
- 禅道使用说明
- 安装集成工具 xampp，或者单独安装Apache、Mysql、PHP组件等
Apache：监听 http 请求的 web 服务
Mysql：数据库
PHP组件：语言解析器，解析语言并生成响应包 - 下载禅道源码，复制到 xampp 的 htdocs 目录下
- 打开服务器浏览器：http://localhost/zentaopms/www
- 打开客户端浏览器：http://服务器的 IP 地址/zentaopms/www
2-1.8.3 缺陷生命周期
- 测试人员提交缺陷，缺陷状态激活，未确认，分配给测试经理
- 测试经理确认缺陷，缺陷状态激活，已确认，分配给开发人员
- 开发人员解决缺陷，缺陷状态已解决，选择解决方案：已解决，分配给测试人员
- 测试人员验证缺陷，若缺陷修复正确，关闭缺陷，缺陷状态已关闭，否则重新激活缺陷，分配给测试人员
2-1.8.4 正常的缺陷流程
正常的缺陷流程分四种：
- 测试人员 - 测试经理 - 开发人员 - 测试人员
- 测试人员 - 开发人员 - 测试人员
- 测试人员 - 测试经理 - 开发经理 - 开发人员 - 测试人员
- 测试人员 - 开发经理 - 开发人员 - 测试人员
2-1.8.5 缺陷的要素
- 缺陷编号
- 所属产品
- 所属模块
- 所属项目
- 影响版本
- 当前指派
- 测试环境：操作系统，浏览器
- 缺陷标题：XX 时，关键测试点，实际结果
- 严重程度（4个）：严重性
- 优先级（4个）
- 预置条件
- 操作步骤
- 预期结果
- 实际结果
- 提交人及提交时间
- 解决人及解决时间
- 解决方案（7个）：设计如此，重复bug，外部原因，无法重现，延期处理，不予解决，已解决
- 缺陷状态（3个）：激活，已解决，已关闭
- 附件：截图
无法重现
- 开发人员无法重现缺陷，解决方案：
确认开发环境的版本、输入数据与测试环境是否一致 - 测试人员无法重现缺陷，解决方案：
（1）立即截图并记录详细的复现步骤，反复使用不同的环境和数据复现缺陷；
（2）复现 2-3 小时，若依然未复现，先记录下来，完成其他工作再尽力复现；
（3）若依然无法复现，告知开发人员和测试经理协助复现缺陷。
不予解决
- 开发人员对缺陷不认可，解决方案：
（1）使用不同的环境和数据反复复现缺陷，分析缺陷产生的原因，以及不修复会造成的后果；
（2）与开发人员再次耐心沟通；
（3）若开发人员仍然不认可，则找测试经理协助解决。
缺陷误区
- 以下做法不正确：
（1）对于不可重现的错误，可以不用报告
（2）为了提高人们对缺陷的注意力，需要夸大一些缺陷的严重性
（3）细小的缺陷不需要报告
（4）开发人员可以上报缺陷
（5）开发人员可以关闭缺陷
（6）测试人员不能引用他人的缺陷报告
（7）测试人员可以关闭未解决的缺陷
2-1.8.6 高质量缺陷需考虑的要素
- 缺陷的标题能概括缺陷的核心内容
- 缺陷的描述及步骤完整
- 明确指出缺陷的严重等级和优先级
763
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
