软件测试理论知识（入门篇）
一、测试基础
知识点1、软件生命周期
| 阶段 | 主要人员 | 主要任务 | 输出文档 |
|---|---|---|---|
| 计划 | 项目经理 | 指定整个项目的计划（目标、人员、预算） | 项目计划 |
| 需求分析 | 产品经理、需求分析人员 | 进一步确定用户的需求 描述软件的具体功能 解决系统 做什么 的问题 |
需求规格说明书（SRS） 产品需求文档（PRD） |
| 设计 | 系统架构师、高级开发人员 | 系统架构师：系统–>子系统–>模块–>函数 高级开发人员：对函数的实现进行详细设计 解决问题 如何做 的问题 |
概要设计 详细设计 |
| 编码 | 开发人员 | 根据详细设计完成软件的编码和调试 | 代码和程序 |
| 测试 | 测试人员 | 对代码和程序进行测试 检查实际结果和预期结果是否一致 检查需求和设计是否有遗漏 |
测试报告 |
| 运维 | 运维人员 | 安装、部署和升级软件，问题排查、技术支持 | 运维报告 |
知识点2、常见软件研发流程
-
瀑布模型
顺序模型：从计划到维护
-
螺旋模型
顺序流程：分阶段实现功能，每个功能的开发都是采用瀑布模型
知识点3、软件测试是什么？
定义：软件测试是对软件的认知活动。测试不只是找 BUG，测试不一定非要执行和操作软件。
目的：项目早期，预防缺陷的产生；项目中期，及早发现软件的缺陷，让软件稳定下来；项目后期，证明软件可用。
知识点4、什么是缺陷？
- 缺陷、故障、失效的区别
| 中文 | 英文 | 说明 |
|---|---|---|
| 缺陷 | bug/defect | 缺陷是软件内隐藏的问题 |
| 故障 | fault | 缺陷诱发出来产生故障 |
| 失效 | failure | 故障不能很好处理就可能导致失效 |
- 缺陷分类
额外实现：做多了，需求里没有的功能实现了。
实现缺失：做少了，需求里有的功能没有实现。
实现错误：做错了，需求里有的功能实现和需求不符。
二、测试过程
知识点1、测试四个阶段
- 单元测试阶段：检查实现的函数代码是否和详细设计一致
| 测试依据 | 详细设计说明书（LLD） |
|---|---|
| 测试对象 | 函数 |
| 测试重点 | 函数功能是否正确，函数内部逻辑实现是否正确 |
| 评估标准 | 主要是逻辑覆盖率 |
- 集成测试阶段：检查实现的模块代码是否和概要设计一致
| 测试依据 | 概要设计说明书 |
|---|---|
| 测试对象 | 模块 |
| 测试重点 | 模块功能是否正确，函数相互调用和接口是否正确 |
| 评估标准 | 主要是接口覆盖率 |
- 系统测试阶段：检查实现的软件代码是否和需求规格说明书一致
| 测试依据 | 需求规格说明书 |
|---|---|
| 测试对象 | 整个软件 |
| 测试重点 | 功能，性能，界面，安全性，兼容性等 |
| 评估标准 | 主要是需求覆盖率 |
- 验收测试阶段：检查实现的软件代码是否和用户需求一致
| 测试依据 | 用户需求 |
|---|---|
| 测试对象 | 整个软件 |
| 测试重点 | 是否达到用户比较粗的需求 |
| 评估标准 | 主要是用户需求覆盖率 |
4.1正式验收测试：第三方评测
4.2用户验收测试：
①阿尔法测试：在开发环境下进行，开发工程师主导
处于受控状态（参与测试的人是有选择的，测试的结果需要反馈）
②贝塔测试
在实际使用环境下进行，处于不受控状态
知识点2、 回归测试（把已经测试过的再测试一遍）
- 回归测试目的
验证缺陷是否修复；检查是否引入新的缺陷 - 回归测试策略
▲选择性回归
①覆盖修改法 仅根据修改的内容来选择测试用例重新测试
②周边影响法 除了覆盖修改外，受到修改间接影响的部分也要选择测试用例重新测试
③指标达成方法 确定一个要达成的指标，如修改代码100%的覆盖，相关关的接口60%的覆盖等
▲完全回归
重新执行所有在前期测试阶段建立的测试用例
需要借助于自动化测试
知识点3、测试的四个活动
每个测试阶段都可以细分为 4 个测试活动
- 测试计划活动
从管理角度规划和控制整个测试工作
输出：测试计划文档
人员：测试经理编写
内容：人员分工，测试范围，时间进度
- 测试设计活动
从技术角度规划和控制整个测试工作
输出：测试方案文档
人员：高级测试工程师编写
内容：如何测试（选择什么测试方法，选择什么测试工具）
- 测试实现活动
输出：测试用例
人员：测试工程师编写
测试用例 用一组数据按照一定步骤来检查软件的处理是否正确
- 测试执行活动
根据测试用例文档对被测对象进行操作
测试员完成
具体内容：
1）搭建测试环境
2）执行测试用例
3）提交缺陷报告（开发人员要通过调试来定位和修复缺陷；测试工程师需要通过回归测试验证缺陷是否修复）
4）测试记录
5）编写测试报告和测试总结
知识点4、双V模型
- 测试在编码完成之后进行，细分为：
单元测试（计划-设计-实现-执行）
集成测试（计划-设计-实现-执行）
系统测试（计划-设计-实现-执行）
验收测试（计划-设计-实现-执行） - 双V模型
- 代码审查：代码编译，编码规则检查，注释率统计
- 验证与确认
验证 Verification 检测每一阶段形成的工作产品是否与前一阶段定义的规格相一致
确认 Validation 检测每一阶段的工作产品是否与最初定义的需求规格相一致
特点：
- 测试和开发同步开展工作
- 测试执行的顺序和开发的活动顺序相反
- 每个阶段的测试计划、设计、实现和执行分离
- 系统测试计划、设计、实现最早开始，执行最晚结束
三、测试方法
知识点1、 黑白灰测试
- 黑盒测试
根据外在特性开展测试。只知道被测对象外在特性，不知道内部实现细节。
系统测试的主要依据是需求规格
需求规格告诉我们软件的功能（外在特性）
系统测试主要采用黑盒测试 - 白盒测试
根据内部结构开展测试。只知道被测对象内部实现细节，不知道外在特性。
单元测试的主要依据是详细设计
详细设计主要是函数的内部逻辑（内部结构），也有函数的功能（外在特性）
单元测试根据函数内部结构和功能开展测试，主要采用白盒测试。 - 灰盒测试
同时根据外在特性和内部结构开展测试。既知道外在特性，也知道内部实现细节。
集成测试的主要依据是概要设计
概要设计有每个模块的功能（外在特性），和每个模块内部有哪些函数（内部结构）
集成测试根据模块功能以及内部组成来开展测试，采用灰盒测试
知识点2、静态动态测试
- 静态测试
不执行被测对象进行测试
分类：
人工静态测试 同行评审
自动化静态测试 代码编译
测试对象：需求规格，概要设计，详细设计，代码，用户手册，帮助 - 动态测试
执行被测对象进行测试
分类 功能测试，性能测试，安全性测试，可靠性测试，语句覆盖测试
测试对象 代码，程序
知识点3、人工自动化测试
- 人工测试
人工测试是自动化测试的基础 - 自动化测试
重复性高、技术难度低的工作可交给电脑完成
- 自动化测试优点
确保软件之前正常的功能没有问题
提高回归测试效率
具有很好的一致性 - 自动化测试局限性
当界面发生变化或者位置发生变化时，脚本失效
脚本维护工作量大大增加
无法提高测试效果
很难发现新的问题 - 自动化测试何时引入
界面不发生变化时可引入
需要重复执行10次以上 - 狭义自动化测试
用自动化测试脚本替代人做执行 - 广义自动化测试
四个活动是否可以利用计算机替代人的工作
测试计划（自动分工）
测试设计实现（测试用例自动生成）
测试执行（测试环境自动搭建部署，测试用例自动执行）
四、软件质量
知识点1、什么是软件质量？
- 质量的定义
质量是实体的各种特性满足需求的程度。
三要素
1）实体 （产品和服务）
产品分软件产品（WPS），硬件产品（杯子）和软硬件结合的产品（手机）
2）特性 多角度评价：功能，性能，易用性，安全性，可靠性 …
3）需求 - 软件质量的定义
软件质量是软件的实体特性对需求的满足程度
2.1 软件质量的三个层次
对需求规格的满足 内部和外部质量
对用户需求（显式）的满足 验收质量
对用户实际需求（显式和隐式）的满足 使用质量
2.2 软件质量铁三角
1）组织
细分整个开发团队：产品部，项目部，开发部，测试部，运维部
2）技术
开发技术 设计（概要，详细，界面）和编码
测试技术 分析测试点，设计测试用例，自动化测试
3）流程
使团队可以更好的协同工作
大流程 研发流程，测试流程
小流程 缺陷管理流程，需求管理流程，配置管理流程
知识点2、 软件质量模型
从多个不同角度看待软件，分 6 大特性和 27 子特性
软件外部质量：功能性，效率，易用性，可靠性，可移植性 主要由测试工程师关注
软件内部质量：可维护性 主要由开发工程师关注
特性一、 功能性
1）适合性
软件产品为指定的任务和用户目标提供一组合适的功能的能力
功能是不是用户需要的
如：电商软件提供商品搜索和购物车功能是适合的，搜狗拼音升级安装搜狗浏览器是不适合的。
2） 准确性
软件产品提供具有所需精确度的正确或相符的结果或效果的能力
功能是否准确，计算精度是否达到要求，是否和需求规格严格一致
如：商品搜索结果和搜索关键字是否匹配，美团骑手位置的准确性
3）互操作性
软件产品与一个或更多的规定系统进行交互的能力
不同软件之间互操作
如：链接分享到其他软件，微信读取通讯录，软件打印和打印机软件的互操作，手机软件和基站
的互操作
第三方登录（使用QQ和微信登录），第三方支付（支付宝，微信支付）
4）保密安全性
软件产品保护信息和数据的能力， 以使未授权的人员或系统不能阅读或修改这些信息和数据， 而
不拒绝授权人员或系统对它们的访问
如：密码输入需要掩码显示，密码传输需要加密，密码存储需要加密。论坛普通用户不能删除其
他用户的发帖。WPS文档可以加密。
5）功能性依从性
软件产品遵循与功能性相关的标准、约定或法规以及类似规定的能力
要考虑国际标准、国家标准、行业标准、企业内部规范等
特性二、效率
1）时间特性
在规定条件下，软件产品执行其功能时，提供适当的响应和处理时间以及吞吐率的能力。即完成
用户的某个功能需要的响应时间。
如：手机App启动的时间，页面链接点击响应时间，服务器的吞吐率。
2）资源利用性
在规定条件下，软件产品执行其功能时，使用合适的资源数量和类别的能力
包含本机的资源，也包含服务器的资源。
如：手机App占用的CPU和运行内存，服务器多用户访问占用的CPU和内存，网络带宽。
3） 效率的依从性
软件产品遵循与效率相关的标准或约定的能力
特性三、 易用性
1）易理解性
软件产品使用户能理解软件是否合适以及如何能将软件用于特定的任务和使用环境的能力
界面显示让用户易理解
如：图标形象容易理解功能，用户容易找到需要使用的功能在哪里操作
2）易学性
软件产品使用户能学习其应用的能力
根据帮助或者提示可以很快学会
如：鼠标悬停在图片的提示，软件的在线帮助
3）易操作性
软件产品使用户能操作和控制它的能力
如：操作的步骤少，按钮的位置，菜单的层级少
4）吸引性
软件产品吸引用户的能力
如：按钮的样式，输入框宽度一致，间距相同，不同层级的文字样式，对齐方式
5）易用性的依从性
软件产品遵循与易用性相关的标准、约定、风格指南或法规的能力
特性四、 可靠性
1）成熟性
软件产品为避免由软件中错误而导致失效的能力
软件对于内部的问题能够很好的处理
如：软件正常操作长时间不出现问题，MTBF
2）容错性
在软件出现故障或者违反指定接口的情况下，软件产品维持规定的性能级别的能力
软件对外部错误能够很好的处理
如：某些必填项不写注册，输入整数的输入小数
3）易恢复性
在失效发生的情况下，软件产品重建规定的性能级别并恢复受直接影响的数据的能力
成熟性和容错性都是为了保证不出异常和故障，易恢复性是为了保证出现故障以后能恢复
4）可靠性的依从性
软件产品遵循与可靠性相关的标准、约定或法规的能力
特性五、 可移植性
1）适应性
软件产品无需采用有别于为考虑该软件的目的而准备的活动或手段就可能适应不同的指定环境的能力
软件适应不同的环境(操作系统，浏览器，分辨率)
如：QQ Windows版本支持Windows 10/7/11/8.1，某网站支持Chrome/Firefox/Edge/IE浏览器，某移动App支持1920x1080，2340x1080，1280x720分辨率的手机
2）易安装性
软件产品在指定环境中被安装的能力
不同用户环境下都容易安装
如：安装选项简单步骤少，包含软件需要的依赖环境（VC运行库）
3） 共存性
软件产品在公共环境中同与其分享公共资源的其它独立软件共存的能力
和其它软件共存
如：和电脑管家，杀毒软件共存，快捷键冲突支持自定义快捷键
4）易替换性
软件产品在同样环境下，替代另一个相同用途的指定软件产品的能力
如：WPS替换Office，Chrome替换IE，WPS高版本替换低版本
5）可移植性的依从性
软件产品遵循与可移植性相关的标准或约定的能力
特性六、 可维护性
1）易分析性
软件产品诊断软件中的缺陷或失效原因或识别待修改部分的能力
如：软件代码中增加运行日志
2）易改变性
软件产品使指定的修改可以被实现的能力
代码是否容易修改，模块化，分层明确
3）稳定性
软件产品避免由于软件修改而造成意外结果的能力
模块的接口定义是否稳定
4）易测试性
软件产品使已修改软件能被确认的能力
方便测试执行，可观察，可控制
5）可维护性的依从性
软件产品遵循与维护性相关的标准或约定的能力
知识点3、 质量管理体系
- CMM
软件能力成熟度模型。软件组织在定义、实施、度量、控制和改善其软件过程的实践中各个发展阶段的描述。
专门针对软件行业，CMM 关注企业内部的能力。
- CMMI
CMM 的升级版本，软件能力成熟度模型集成。
- 阶段式表示
| 等级 | CMM Level | CMM 等级 | CMMI Level | CMMI 等级 |
|---|---|---|---|---|
| 1 | Initial | 初始级 | Initial | 初始级 |
| 2 | Repeatable | 可重复级 | Managed | 已管理级 |
| 3 | Defined | 已定义级 | Defined | 已定义级 |
| 4 | Managed | 已管理级 | Quantiatively Managed | 量化管理级 |
| 5 | Optimizing | 优化级 | Optimizing | 优化级 |
- 连续式表示
过程管理，项目管理，工程，支持
五、软件需求
知识点1、需求工程
- 需求的定义
解决用户问题或达到用户目标所需的条件或能力
为遵循合同、标准、规格或其他要求的正式文档，系统必须满足或拥有的条件或能力
强调做什么（What）而不是如何做（How） - 需求工程
需求开发：需求获取，需求分析，需求定义，需求验证
需求管理： 需求分配，需求评审，需求基线，需求跟踪，变更控制 - 需求管理工具
Quality Center（QC）
IBM Rational DOORS
禅道
知识点2、需求规格说明书
- 定义
需求规格说明书（Software Requirement Specification）
是对在特定环境下要完成一定功能的软件产品、程序或一组程序的说明
应该从以下方面去描述需求：
功能 软件要做什么
性能 速度、响应时间等
外部接口 如何与人、系统硬件、外部的硬件和软件交互
属性 可移植性、可靠性、可维护性、易用性等
实现的设计约束 标准、实现语言、资源限制、操作环境 - 目的
- 在客户和开发者之间达成一致
- 为编制计划和成本计价提供基础
- 为设计提供了基础
- 为确认和验证提供一个基础
- 提高开发效率
- 特点
- 软件需求的正确性
- 软件需求无歧义性
- 软件需求可验证性
- 软件需求一致性
- 软件需求完整性
- 软件需求可追踪性
- 内容
- 产品环境介绍：软件在什么环境下使用？和测试环境的搭建相关
- 用户特征：软件给谁用？ 要从用户使用的角度考虑测试点
- 假设和依赖关系：开发语言、开发环境 不同开发语言测试的关注点有差异
- 用户接口：人机接口/界面 原型图
- 功能需求：描述了软件必须执行的基本动作
用需求编号加上简短词汇做为功能需求名 如 OA.REGISTER.USERNAME.01
内容包含：简要介绍，输入，处理，输出 - 性能需求：描述对软件的静态的和动态的量化需求
静态：支持的终端数目、支持的同时使用的用户数、表和文件的大小……
动态：请求响应时间、吞吐量、资源利用率…… - 技术限制：使用特定技术的限制，包括接口，数据库，通讯协议，编程规范等
- 本地化：描述支持多种语言的需求
- 软件接口：与外部软件的接口，考虑软件质量模型中互操作性
- 标准符合性：软件质量模型中依从性
- 需求分级：螺旋模型可以根据需求分级来确定哪些功能先做，测试用例的重要级别和需求分相关
优先级：
基本的（Essential/Mandatory）绝对基本特性，如果不包含，产品就会被取消。
条件的（Conditional）不是基本的特性，但这些特性会影响产品的生存能力。
可选的（Optional）期望的特性，省略一个或多个特性不会影响产品的生存能力。
知识点3、 同行评审
- 基本概念
同行评审（Peer Review）是一种通过作者的同行来确认缺陷和需要变更区域的检查方法。
需要前期准备、计划和时间进度表
越早进行越好 - 评审方法
2.1 正规检视
需要有严格的评审流程，目的是发现缺陷
评审对象 仅针对基础性的技术类工作成果物，如需求规格说明书，概要设计，详细设计
2.2 技术评审
主要由技术类工作人员参与，主要提出可替换的技术方案
评审对象 管理类工作成果物和测试的工作成果物，如项目计划，测试计划，测试方案，测试用例和测试报告
4.2.3 走查
主要目的是发现缺陷、遗漏和矛盾的地方，改进产品。不需要评审会议。
评审对象 代码，用户手册，帮助
知识点4、需求评审
- 评审流程
- 需求分析人员提交需求规格给开发经理（评审组织者）
- 项目经理确定参与评审的评审专家
- 项目经理把需求规格、评审表单、评审检查单给评审专家
- 评审专家如果觉得需求规格不好理解可建议召开介绍会议
- 项目发经理根据评审专家反馈组织介绍会议（可选）
- 作者解答疑问，保证评审专家能开展评审
- 评审专家评审并反馈评审表单给开发经理
- 项目经理汇总评审表单并反馈需求分析人员查看
- 开发项目经理组织评审会议（需求分析人员逐一确认每条评审意见）
- 针对需要讨论的问题召开第三小时会议（可选）
- 需求分析人员根据确认后的评审意见修改需求规格
- 评审专家确认修改是否正确
- 确认后的需求规格可正式对外发布
六、系统测试
知识点1、 什么是系统测试
检查已经集成的软件是否和需求规格说明书一致
系统种类：桌面软件，Web 网站，客户端软件，移动 App，小程序，智能设备，通信系统 …
知识点2、系统测试类型
- 功能测试
质量模型中 功能性
分类：单功能测试，功能交互测试，业务场景测试 - 性能测试
质量模型中 效率
性能测试指标：响应时间，吞吐量/吞吐率，并发用户数，内存占用，CPU占用，磁盘占用，功耗，流量。
性能测试是一个大的测试类型，是所有性能相关测试的统称。可以细分为几个子测试类型：
- 负载测试
测试系统在各种负载情况下，是否满足需求规格说明书各项性能指标相关要求， 并测试出系最
大负载，主要测试系统的能力。 - 压力测试
测试系统在极限负载情况下是否会崩溃，各项性能指标在长时间运行的情况下是否稳定，主要测试系统的耐力。 - 容量测试
测试系统可处理同时在线的最大用户数，通常和数据库容量相关。
只关注数量多少，不关注速度多快。 - 基准测试
用于一些大型的网站的性能测试
找一台普通服务器，针对不同版本的软件进行小容量的测试，进行对比 - 并发测试
测试多个用户同时访问同一个应用、同一个模块或者数据记录时是否存在问题
- 界面测试
质量模型中 易用性的易理解性和吸引性
- 测试界面元素的显示
界面元素大小，形状，色彩
界面元素文字的字体，字号，对齐
光标位置
输入回显 - 测试界面元素的行为
输入限制，输入检查，输入提醒
默认值
出错信息位置 - 测试界面的布局
各界面元素所在位置
各界面元素对齐方式
各界面元素之间的间距
各界面元素之间的色彩搭配
- 易用性测试
质量模型中 易用性的易操作性
软件操作方便，操作步骤少
桌面软件菜单级数不超过 3 级
网站分类导航不超过 3 级 - 兼容性测试
质量模型中 可移植性的适应性
也叫配置测试
不同软硬件环境下功能测试，界面测试和性能测试。不是完全独立的测试类型。
- 软件环境
客户端
操作系统（Windows 10/7/11，macOS，Android 11/10/9，iOS 16/15)
浏览器（Chrome, Firefox, Edge, IE11）
分辨率（1920x1080，1366x768，1280x720，2K，4K）
服务器
Web 服务器软件（Apache, nginx）
数据库服务器软件（Oracle，MySQL） - 硬件环境
如游戏测试考虑不同档次和不同品牌的显卡
- 安全性测试
质量模型中 功能性的保密安全性
数据的安全性
权限的安全性
安全漏洞 - 安装测试
质量模型中 可移植性的易安装性
- 安装前测试
检查安装包文件格式、类型和大小等
检查安装包中文件是否齐全
检查安装包中是否有病毒或木马
检查硬件环境配置是否符合要求 - 安装中测试
安装流程测试
升级降级测试
异常情况测试 磁盘空间不足，磁盘没有写权限，内存不足 - 安装后测试
测试安装好的软件是否可运行
软件的卸载测试
程序文件的目录及子目录是否正确产生
是否存在无用的目录、子目录、程序文件和临时文件
安装日志检查
测试安装是否完整
- 可靠性测试
质量模型中 可靠性
稳定性测试
连续运行较长时间不出现问题
容错性测试
也称为异常测试，鲁棒性测试
恢复性测试
从灾难或出错中能否很好地恢复
异常：软件系统故障，断电，硬件及有关设备故障，通信故障和错误 - 文档测试
对用户使用手册，系统部署文档，帮助等文档进行测试。
检验文档的完整性，正确性，一致性，易理解性和易浏览性 - 网络测试
不同网络环境下软件是否正常运行
WiFi 网络
2G，3G，4G，5G 移动网络
弱网
无网
知识点3、系统测试环境
- 环境组成
- 硬件
PC，服务器，网络设备，测试仪表，打印机 - 软件
操作系统
Web服务器软件
应用服务器软件
数据库
被测软件
软件支持平台
浏览器
测试数据
测试脚本
- 环境分类
- 主测试环境
Windows 10 + Chrome + 1920x1080
测试所有测试用例 - 辅测试环境
Windows 7 + Firefox + 1366x768，Windows 11 + Edge + 3840x2160
测试所有高优先级的测试用例以及和界面相关的测试用例 - 真实环境 4G，5G，WiFi，弱网（电梯，地铁）使用实际网络
- 仿真环境 3G，2G使用软件模拟，弱网（电梯，地铁）使用软件模拟
- 测试数据的准备
产品数据（注意脱敏处理），工具生成，捕获数据，手工构造，随机数据
知识点4、 系统测试执行
- 测试环境搭建
- 系统测试预测试
基本功能检查，检查软件质量是否满足后续测试要求，也叫冒烟测试
每日构建 每天自动完整编译最新代码 - 转系统测试评审（可选）
开会确定是否能开始正式的系统测试执行
评审点
1） 系统测试预测试是否通过
2）测试用例是否完成并经过评审
3）测试人员是否到位
4）测试仪表或工具是否到位且进行了相关培训
- 执行测试用例
填写测试记录：
1）测试用例执行人员
2）测试用例执行时间
3）测试用例执行结果
测试通过（PASS/OK） 执行结果和预期结果相符
测试失败（FAIL/NOK） 执行结果和预期结果不符
测试被阻塞（BLOCK） 由于一些缺陷导致该测试用例无法继续执行，该缺陷不是这个测试用例
的测试点
测试未进行（Not Test/NT） 该测试用例功能已实现但还没有执行
测试不适用（Not Applicable/NA） 该测试用例对于被测软件不适用，比如功能未实现
4）问题单号
5） 执行测试用例数统计
6） 测试记录提交人员
编写测试日报：
汇报每天执行情况
测试日报内容：执行情况，发现缺陷情况，存在的问题以及需要的帮助
缺陷管理：
提交缺陷报告，跟踪缺陷状态，回归测试验证缺陷
- 编写测试报告和测试总结
测试执行结束时
七、测试用例
知识点1、 什么是测试用例
定义：通过一组数据和操作实现测试目的
如何生成测试用例：用户原始需求 > 产品需求 > 测试计划 > 测试方案 > 测试需求 > 编写测试例
知识点2、测试用例内容
-
用例编号
区分测试用例的一个标识
项目名_测试阶段_测试项_子项序号
测试阶段：单元测试 UT ；集成测试 IT ；系统测试 ST
项目名和测试阶段可选 -
测试项目
单元测试 函数名
集成测试 模块名或接口名
系统测试 功能点，性能指标，界面元素
通常多个测试用例公用一个测试项目 -
测试标题
简短说明从哪个角度对测试目的进行测试
原则上标题不重复
不能出现不确定的描述，如是否，能不能。不能出现测试步骤和预期结果。 -
重要级别
影响测试用例执行顺序
和对应的测试点的重要性有关
常见的重要级别：高，中，低 -
预置条件
操作步骤一致，预置条件不一致，结果不一致
环境设置 测试环境(Windows 10 + Chrome)
预置数据 如已注册某用户
先运行其他测试用例
简化测试用例的步骤 不需要所有测试用例从登录或首页开始，可以是已经使用某个用户登录系统进入某模块 -
测试输入
可选项，输入的数据比较复杂或者是文件时使用，如附件，测试用例有关的数据或文件上传
输入数据简单的情况直接填写在对应的测试步骤就可以
输入的数据要求是具体的数据，不是规则的描述 -
测试步骤
执行当前测试所需要经过的操作步骤，需要明确的给出每个步骤的描述 -
预期结果
界面检查，数据库检查，测试用例通过失败标准
预期结果中不允许出现操作步骤 -
其他可选内容
用例设计人员
用例设计时间
需要评审
用例状态
知识点3、测试用例管理工具
TestLink，禅道，JIRA，QC
八、缺陷管理
知识点1、缺陷报告内容
- 缺陷标识
一般由缺陷管理系统自动生成，不会重复 - 缺陷标题
在什么地方做了什么操作出现什么错误 - 缺陷详述
- 测试环境
- 测试步骤
- 预期结果
- 实际结果
- 结果分析
- 缺陷属性
- 严重性
对软件本身产生的影响
| 严重性 | 说明 |
|---|---|
| 1致命 | 崩溃，闪退，数据丢失 |
| 2 严重 | 影响主要流程的缺陷 |
| 3 一般 | 一般的功能，非主流程的功能 |
| 4 建议 | 界面问题、显示问题 |
- 优先级
是缺陷被修复的紧急程度
| 优先级 | 说明 |
|---|---|
| P1 立即 | 致命的问题 立即解决 |
| P2 高 | 严重的问题 高优先级 |
| P3 中 | 一般的问题 中优先级 |
| P4 低 | 建议的问题 低优先级 |
- 分类
功能问题，性能问题，兼容问题，安全问题 … - 出现频率
必然，经常，有时，很少 - 状态
与缺陷流程有关
- 版本
被测软件版本号 - 附件
截图，录像，日志(log)，测试数据 - 报告人
- 报告日期
- 指派人
知识点2、 缺陷管理工具
Mantis，Bugzilla，Bugfree，Bugclose，QC，JIRA，禅道，公司自研
工具分类：
全流程项目管理工具：QC，JIRA，禅道
单独的缺陷管理工具：Mantis，Bugzilla，Bugfree，Bugclose
需求和测试用例管理工具：TestLink
知识点3、缺陷管理流程
- 缺陷管理目的：缺陷跟踪和解决，缺陷分析和产品度量
- 缺陷生命周期：发现-提交-确认-分配-修复-验证-关闭
- 缺陷管理基本流程：
- 测试人员发现缺陷并提交 Bug，状态 New
- 开发人员接受 Bug，状态 Open
- 开发人员拒绝 Bug，状态 Reject
- 开发人员解决 Bug，状态 Fixed
- 测试人员验证 Bug
- 如果解决，状态 Closed
- 如果未解决，状态 Reopen
留言：如果对你有帮助，给博主点个免费的赞吧 ~ 创作不易，感谢支持！
