当前位置：首页 > news >正文

软件测试笔记（测试的概念、测试和开发模型介绍、BUG介绍）

news 来源：原创 2025/7/31 5:20:59

软件测试笔记

认识测试

软件测试是啥？
说白了，就是检查软件的功能和效果是不是用户真正想要的东西。比如用户说“我要一个能自动算账的软件”，测试就是看这个软件到底能不能准确算账、有没有漏掉功能。

软件测试定义：软件测试就是验证软件产品特性是否满足用户的需求。

概念篇

什么是需求

在多数软件公司，会有两部分需求。一部分是用户需求，一部分是软件需求。

用户需求：通常是用户随口说的一句话，比如“我想要个能聊天的软件”。这种需求很模糊，不能直接拿来开发，比如用户没说要支持语音还是文字聊天。

软件需求：产品经理对用户需求进行需求分析（技术可行性、市场可行性、成本投入和收益占比等）后得到软件需求，它是开发和测试人员工作的基本依据。产品经理会把用户需求“翻译”成具体能实现的东西。比如：

聊天软件要支持文字、语音、发图片；
消息要能撤回，还要有已读提示。
这些具体的功能点才是开发写代码、测试做检查的依据。

开发模型

软件的生命周期

需求的开始是软件生命的起点，中间会经历需求的计划、设计，程序开发，程序测试阶段，直到软件不再进行维护便到了生命的终点。

简而言之就是：

需求分析 -> 计划 -> 设计 -> 编码 -> 测试 -> 运行维护

常见开发模型

瀑布模型

瀑布模型的每个阶段只执行一次，因此是线性顺序进行的软件开发模式。

瀑布模型的优点：
1. 强调开发的阶段性
2. 线性结构，每个阶段只执行一次
3. 是其他模型的基础框架

瀑布模型的缺点：

测试后置
- 前面各阶段遗留的风险推迟到最后的测试阶段才被发现，可能导致大面积返工。
- 必须给测试留够足够长的时间，不然会导致测试不充分。
周期太长，产品很迟才能被看到和使用，可能会导致需求/功能过时。

瀑布模型的适用场景：需求固定的小项目。

螺旋模型

螺旋模型的优点：

强调严格的全过程风险管控。
强调各开发阶段的质量。
增加风险分析和原型。

螺旋模型的缺点：

增加了风险分析和原型，需要增加人员、资金、时间的投入，提高项目的成本。
项目中存在的风险性与风险管理人员的技能水平有直接关系。

增量模型

增量模型是把待开发的软件系统模块化，将每个模块作为一个增量组件，从而分批次地分析、设计、编码和测试这些增量组件。运用增量模型的软件开发过程是递增式的过程。

优点：

将待开发的软件系统模块化，可以分批次地提交软件产品，使用户可以及时了解软件项目的进展。
以组件为单位进行开发降低了软件开发的风险。一个开发周期内的错误不会影响到整个软件系统
开发顺序灵活。开发人员可以对组件的实现顺序进行优先级排序。

缺点：

待开发的软件系统可以被模块化，如果待开发的软件系统很难被模块化，那么将会给增量开发带来很多麻烦。

适用场景：大型项目。

迭代模型

迭代模型：将系统的开发工作划分成一个个迭代，不要求一次行完成整个系统的开发（相对于瀑布开发而言）。

迭代模型的特点：

第一个阶段就覆盖了项目整体范围，以后每个阶段都是在前一阶段的基础上改进、完善，没有业务范围的扩展。

适用场景：大型项目。

敏捷模型

敏捷模型旨在帮助项目快速适应变更请求、促进项目的快速完成。

在敏捷模型中。需求被分解成许多可以增量开发的小部分，每个增量部分都是在迭代中开发的。每次迭代都旨在小而易于管理。并且只能在几周内完成。

敏捷模型的四个特点：轻文档、轻流程、重目标、重产出。

测试模型

V 模型

优点：明确的标注了测试过程中存在的不同类型的测试，并且清楚的描述了这些测试阶段和开发过程期间各阶段的对应关系，有效提升了测试的质量和效率。

缺点：V 模型是瀑布模型的变种，瀑布模型存在的问题V 模型也存在。V模型最大的问题就是“测试开始得太晚”——它把大部分测试都堆在开发完成后才做。比如需求阶段只写文档，不提前检查问题，等到最后测试才发现需求理解错了，这时候改起来成本就很高。如果能在写需求、设计文档的时候，就边写边检查（比如找人评审文档），很多问题其实不用等到最后就能提前解决。（举例：就像盖楼，等房子盖完了才发现图纸有问题，拆了重建肯定费钱费力。如果盖之前就把图纸检查清楚，返工就会少很多。）

W 模型（双 V 模型）

W 模型由两个 V 字形模型组成，分别代表测试与开发过程。图中明确表示出了测试与开发的并行关系。

特点：测试的对象不仅是程序，需求、设计等也需要测试，测试与开发是同步进行的。

优点：W 模型相对于 V 模型来说，测试更早的进入到开发阶段，与开发阶段是并行关系，更早的发现问题，能够及时解决问题，各个阶段分工明确，方便管理。

缺点：W 模型是顺序性的，不可逆，需求的变更和调整，依旧不方便。

BUG 篇

软件测试的生命周期

软件测试贯穿于软件的整个生命周期。

各阶段的具体内容：

BUG 的描述和级别

描述 BUG 的基本要素：问题出现的版本、问题出现的环境、问题出现的步骤、预期结果、实际结果。

BUG 级别一般分为：崩溃、严重、一般、次要。

BUG 的生命周期

BUG 的生命周期：

一个Bug从被发现到解决，会经历这些状态：

New（新发现）
- 状态说明：刚发现的Bug，还没确认要不要修。
- 举个栗子：测试小哥发现点击按钮会卡死，先记下来，等大家开会决定要不要处理。
Open（确认要修）
- 状态说明：确认是Bug，交给程序员去修了。
- 举个栗子：开会确认这按钮确实有问题，程序员A接单开修！
Fixed（已修复）
- 状态说明：程序员说修好了，等测试人员再检查一遍。
- 举个栗子：程序员A提交代码后，测试小哥得重新点按钮看还卡不卡。
Rejected（拒绝修）
- 状态说明：“这不是Bug，不用修！”
- 举个栗子：程序员A说按钮卡死是因为网络慢，不算Bug，直接驳回。
Delay（延后修）
- 状态说明：“先放着，以后再说。”
- 举个栗子：这Bug只在IE浏览器出现，但公司早不用IE了，先不修。
Closed（已关闭）
- 状态说明：测试通过，Bug正式关掉！
- 举个栗子：测试小哥验证按钮不卡了，Bug彻底解决，关掉！
Reopen（重新打开）
- 状态说明：“Bug没修好，打回去重修！”
- 举个栗子：测试小哥发现按钮还是偶尔卡死，重新丢给程序员A返工。

参考资料

软件开发传统模型——瀑布模型、原型模型、增量模型、螺旋模型、喷泉模型-CSDN博客

开发模型的理解：瀑布模型/增量式/迭代/敏捷开发——笔记 - 知乎

软件测试模型——V模型 & W模型_软件测试v模型-CSDN博客

本文到这里就结束啦~

在这里插入图片描述