您现在的位置是:首页 >技术杂谈 >软件测试之基础概念学习篇(需求 + 测试用例 + 开发模型 + 测试模型 + BUG)网站首页技术杂谈

软件测试之基础概念学习篇(需求 + 测试用例 + 开发模型 + 测试模型 + BUG)

hssq 2023-06-07 11:30:35
简介软件测试之基础概念学习篇(需求 + 测试用例 + 开发模型 + 测试模型 + BUG)

1. 什么是软件测试

软件测试就是验证软件功能是否满足用户需求

在具体业务中表现为,最终交付的产品是否和用户的需求一致,如果不一致,则需要找出不一致的点

2. 软件测试和软件开发的区别

  • 难易程度方面

    开发对于知识的广度小,专业度高,测试的广度大,专业度低

  • 技能要求方面

    测试比开发要求更广泛,测试人员需要具备一定的业务能力、沟通能力、对测试工具的收敛使用,是需要有一定的编程能力

3. 软件测试和软件调试的区别

  • 目的

    软件测试的目的是验证软件是否满足用户的需求

    软件调试的目的是验证软件是否实现了开发人员想让它实现的功能

  • 角色

    软件测试是由开发人员和测试人员共同完成的

    软件调试是由开发人员完成的

  • 阶段

    软件测试贯穿了整个软件开发的生命周期

    软件调试只是在开发阶段

软件开发的生命周期

需求分析 -> 计划 -> 设计 -> 开发 -> 测试 -> 运维

4. 什么是需求

需求就是实现用户的期望或者满足文档(合同、标准、规范)所需要的条件或者权限

需求包括软件需求和用户需求

用户需求就是用户想要软件实现的功能,用户需求比较粗略直接实现比较困难

软件需求是从用户需求转化而来的,是对用户需求的细化和具体实现

软件需求是测试人员进行测试工作的基本依据

1)以需求为依据设计测试用例

首先验证需求,保证需求正确可实现,然后细化需求,从需求中提炼出一个个测试项

以 “ 用户登录 ” 为例,具体过程如下:

请添加图片描述

5. 测试用例是什么

测试用例是为了实施测试向被测试系统提供的一组集合,包含:测试环境、测试步骤、测试数据、预期结果等因素

测试用例告诉我们该测什么,怎么测

设计一条网易邮箱登录的测试用例:

请添加图片描述

测试环境: Chrome PC端 Windows操作系统

测试数据: 用户名:123456 密码:h123456789

测试步骤:

  1. 在 Chrome 浏览器打开网易邮箱 URL
  2. 输入用户名和密码
  3. 点击登录

预期结果: (操作完测试步骤后的结果)登陆成功

6. 什么是 BUG(软件错误)

  • 当且仅当规格说明书(软件需求)存在且合理,程序和软件需求之间不匹配的情况就是 BUG
  • 当软件需求不存在,用户需求存在且合理,软件功能和用户需求不符合,就说明是软件错误

软件测试在需求分析阶段时需要验证需求的合理性和正确性

7. 五个开发模型

软件开发的生命周期

需求分析 -> 计划 -> 设计 -> 开发 -> 测试 -> 运维

1)瀑布模型

瀑布模型是严格按照软件开发的生命周期进行的分阶段的开发模型

请添加图片描述

优点: 强调开发的阶段性,强调早期的需求分析和后期的测试

缺点: 测试在编码后才开始介入,导致前期的问题后期才发现,可能会失去错误补救的机会

2)螺旋模型

一般在软件开发初期阶段需求不是很明确时,采用渐进式的开发模型,螺旋模型就是典型的 渐进式开发模型,螺旋模型适用于 规模庞大复杂度高风险大 的项目

请添加图片描述

优点: 强调严格的风险管理,强调各开发阶段的质量

缺点: 引入严格的风险管理,需要更多人员、时间和金钱的投入

3)迭代模型、增量模型

将一个系统分为四个模块,A、B、C、D,在两周内将四个模块开发完成

迭代模型:

第一周先开发 A、B、C、D四个模块的基础功能

第二周再在第一周的基础之上完成其他的功能

增量模型:

第一周开发 A、B 两个模块的功能

第二周开发 C、D 两个模块的功能

增量模型和迭代模型抗风险能力都很强,迭代模型相比较增量模型还要更强些

4)敏捷开发模型

敏捷开发是一种可以应对快速变化的用户需求的一种软件开发模式

特点:

轻文档、轻流程、重目标、重产出

拥抱变化,客户可以在整个流程中对需求进行更改

周期短,团队人员少但精干

敏捷宣言:

个体与交互重于过程和工具

可用的软件重于完备的文档

客户协作重于合同谈判

响应变化重于遵循计划

Scrum 中的角色

  • PO(product owner)产品经理,负责整理用户需求,形成 userstory
  • SM(scrum master)项目经理,管理整个团队,负责敏捷流程的顺利实施,以及各种会议的顺利召开
  • ST(scrum team)研发团队,负责整个项目的研发,由各种技能的工程师组成

Scrum 流程

请添加图片描述

  • 发布计划会议: 产品经理收集需求相乘 userstory,讲解 userstory,决定本次迭代需要开发的 userstory 形成 sprint backlog
  • 迭代计划会议: 分析 userstory,把 userstory 分解成一个个的任务,分配给开发人员,制定开发计划
  • 每日会议: 讲解昨天干了什么,遇到的问题、今天的计划
  • 产品演示会议: 给客户演示研发的成果,产品经理整理和手机演示后客户的意见形成新的 userstory,放到下一次迭代中
  • 回顾计划会议: 回顾整个迭代过程,把不足的地方找出,在下一次迭代过程中改进,优化迭代流程

8. 测试模型

1)V 模型

特点: 明确标注了测试过程中存在的不同类型的测试,并且清楚的描述了这些测试阶段和开发过程各阶段的对应关系

缺点: 测试在编码之后才被引入,会失去对错误及时纠正的机会

请添加图片描述

2)W 模型

特点:

  • 测试贯穿整个软件开发的生命周期,对需求、代码等都会进行测试测试
  • 测试更早的介入,可以尽早发现错误并解决
  • 测试与开发独立并行

缺点:

  • 测试和开发保持一种线性的前后关系,上一阶段完全结束才可开始下一阶段工作
  • 无法支持敏捷开发模型

请添加图片描述

9. 软件测试的生命周期(软件测试的流程)

生命周期: 需求分析 -> 测试计划 -> 测试设计、测试开发 -> 测试执行 -> 测试报告

  1. 需求分析

    测试人员对需求进行分析,验证需求的合理性和正确性,细化需求,根据需求提炼测试点

  2. 测试计划

    确定测试的范围、目的、人员名单、测试工具以及测试环境

  3. 测试设计、测试开发

    测试人员根据提炼的测试点编写测试用例

  4. 测试执行

    在开发人员提交代码之后,测试人员根据测试用例和计划执行测试,记录测试过程中发现的 BUG 并提交

  5. 测试报告

    对本次测试进行分析和总结,记录在本次测试中使用了哪些测试用例,发现了哪些 BUG,修改了多少,剩余的 BUG 有哪些比较好的解决方案

10. 如何描述一个 BUG

一个合格的 BUG 描述包括以下几部分:

  1. 发现 BUG 的版本

    开发人员提交代码时代码的版本号

  2. 测试环境

    在不同的测试环境下问题出现的情况可能不一样

  3. 测试步骤

    告诉开发人员测试数据和执行测试时的具体步骤,以便于开发人员复现 BUG

  4. 实际结果

  5. 预期结果

  6. BUG 产生时的日志、错误截图等

11. BUG 的级别

1)崩溃

系统崩溃、死机、死循环,黑屏、闪退等导致系统不能运行的问题

如果系统已经发布,用户在使用过程中出现崩溃级别 BUG 怎么办?

  • 可以采用停服维修的方式来对 BUG 进行维护,但是这样会影响用户的体验和产品的利润
  • 最高效且损失最低的方法是,回到上一个稳定可用的历史版本

2)严重

系统可以用,但是不稳定,继续使用会产生严重的错误,如数据库插入用户数据时出错,用户数据的安全性问题等

3)一般

系统可以正常使用,但是一些次要的功能没有实现,如系统的提示语不完善,删除时没有确认弹窗等

4)建议(次要)

一些建议性的问题或者可以对系统进一步优化的方案,比如界面排版不符合用户习惯等

12. BUG 的状态转移图

请添加图片描述

风语者!平时喜欢研究各种技术,目前在从事后端开发工作,热爱生活、热爱工作。