软件测试笔记1(测试的概念、测试和开发模型介绍、BUG介绍)

软件测试笔记

认识测试

软件测试是啥?

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

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

概念篇

什么是需求

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

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

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

  • 聊天软件要支持文字、语音、发图片;

  • 消息要能撤回,还要有已读提示。

  • 这些具体的功能点才是开发写代码、测试做检查的依据。

开发模型

软件的生命周期

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

简而言之就是:

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

常见开发模型
瀑布模型

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

瀑布模型的优点:

  1. 强调开发的阶段性

  2. 线性结构,每个阶段只执行一次

  3. 是其他模型的基础框架

瀑布模型的缺点:

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

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

螺旋模型

螺旋模型的优点:

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

螺旋模型的缺点:

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

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

优点:

  1. 将待开发的软件系统模块化,可以分批次地提交软件产品,使用户可以及时了解软件项目的进展。

  2. 以组件为单位进行开发降低了软件开发的风险。一个开发周期内的错误不会影响到整个软件系统

  3. 开发顺序灵活。开发人员可以对组件的实现顺序进行优先级排序。

缺点:

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

适用场景:大型项目。

迭代模型

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

迭代模型的特点:

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

适用场景:大型项目。

敏捷模型

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

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

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

优点:

  1. 快速交付价值:通过小步快跑降低风险,尽早验证商业模式
  2. 适应变化:灵活响应市场和客户需求变动
  3. 客户满意度高:频繁交付可运行版本,增强客户信任
  4. 资源利用率高:减少前期过度规划,避免资源浪费

缺点:

  1. 规划挑战:需求动态变化导致成本和时间难以准确预估
  2. 文档不足:轻文档特性可能增加后期维护和新成员融入难度
  3. 依赖客户参与:若客户需求不明确,项目易偏离目标

测试模型

V 模型

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

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

W 模型(双 V 模型)

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

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

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

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

BUG 篇

软件测试的生命周期

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

各阶段的具体内容:

BUG 的描述和级别

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

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

BUG 的生命周期

BUG 的生命周期:

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

  1. New(新发现)

    • 状态说明:刚发现的Bug,还没确认要不要修。
    • 举个栗子:测试小哥发现点击按钮会卡死,先记下来,等大家开会决定要不要处理。
  2. Open(确认要修)

    • 状态说明:确认是Bug,交给程序员去修了。
    • 举个栗子:开会确认这按钮确实有问题,程序员A接单开修!
  3. Fixed(已修复)

    • 状态说明:程序员说修好了,等测试人员再检查一遍。
    • 举个栗子:程序员A提交代码后,测试小哥得重新点按钮看还卡不卡。
  4. Rejected(拒绝修)

    • 状态说明:"这不是Bug,不用修!"
    • 举个栗子:程序员A说按钮卡死是因为网络慢,不算Bug,直接驳回。
  5. Delay(延后修)

    • 状态说明:"先放着,以后再说。"
    • 举个栗子:这Bug只在IE浏览器出现,但公司早不用IE了,先不修。
  6. Closed(已关闭)

    • 状态说明:测试通过,Bug正式关掉!
    • 举个栗子:测试小哥验证按钮不卡了,Bug彻底解决,关掉!
  7. Reopen(重新打开)

    • 状态说明:"Bug没修好,打回去重修!"
    • 举个栗子:测试小哥发现按钮还是偶尔卡死,重新丢给程序员A返工。

参考资料

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

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

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


本文到这里就结束啦~

相关推荐
饕餮争锋1 小时前
设计模式笔记_创建型_建造者模式
笔记·设计模式·建造者模式
萝卜青今天也要开心2 小时前
2025年上半年软件设计师考后分享
笔记·学习
吃货界的硬件攻城狮2 小时前
【STM32 学习笔记】SPI通信协议
笔记·stm32·学习
蓝染yy3 小时前
Apache
笔记
lxiaoj1113 小时前
Python文件操作笔记
笔记·python
半导体守望者4 小时前
ADVANTEST R4131 SPECTRUM ANALYZER 光谱分析仪
经验分享·笔记·功能测试·自动化·制造
啊我不会诶5 小时前
倍增法和ST算法 个人学习笔记&代码
笔记·学习·算法
程序员三藏5 小时前
如何使用Pytest进行测试?
自动化测试·软件测试·python·测试工具·职场和发展·测试用例·pytest
逼子格6 小时前
振荡电路Multisim电路仿真实验汇总——硬件工程师笔记
笔记·嵌入式硬件·硬件工程·硬件工程师·硬件工程师真题·multisim电路仿真·震荡电流
一条破秋裤6 小时前
一份多光谱数据分析
笔记·数据挖掘·数据分析