【软件测试】软件测试概念 | 测试用例 | BUG | 开发模型 | 测试模型 | 生命周期

文章目录


一、什么是软件测试

1.什么是软件测试

  • 软件测试就是找BUG,发现缺陷
  • 软件测试只是一个样本测试,具有不可穷尽性。

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

在早期,更多的是将软件测试看做对软件产品的"检验" ,检查软件的每个功能是否正常运行正常

  • 验证软件功能执行的正确性,可以是否能正常工作。
  • 测试的活动是以测试人员"预期的结果(需求定义)"为依据,看是否符合需求

测试:就是保障软件的质量

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

调试:开发自己调试,确保程序做了程序员想做的事,发现问题,解决问题。在开发阶段进行。

测试:测试和开发一起执行。确保程序解决了它要解决的问题,来发现问题。测试伴随软件的整个生命周期

测试人员需要的素养

技能:

1.测试用例设计的能力

2.编程能力(编写测试工具、自动化测试用例)

3.技术快速学习的能力、业务快速学习能力

非技能

1.沟通合作能力

2.文字表达能力(写测试用例、编写测试文档、BUG)

3.抗压能力

4.责任感


二、软件测试概念

1.需求

1.需求的定义
  • 用户需求:甲方提出来的需求,或者用户要完成的任务

  • 软件需求:功能需求,详细描述需要实现的软件功能

软件需求是产品经理写的

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

用户需求就是一句话,软件需求是一个文档(详细描述用户需求应该如何实现)

2.测试人员眼中的需求
  • 需求是测试人员开展软件测试工作的依据

  • 业务需求--->软件功能需求点--->测试需求点--->测试用例

  • 从软件功能需求出发,无遗漏的识别出测试需求。直接关系到用例的测试覆盖率
  • 对于每个测试需求点,需要具体设计测试用例
  • 测试工程师在需求分析和设计阶段开始介入

2.测试用例

Test Case

1.测试用例概念
  • 测试用例是一组集合,包含测试环境、测试数据、预期结果、操作步骤

例子:测试环境:windows+Chrome +本地

测试数据:用户名字符串、密码字符串

​ 操作步骤:输入用户名、输入密码、点击登录按钮

​ 测试预期:登录成功

  • 测试用例可以提高测试人员的工作效率,降低工作的重复性
  • 测试用例是建立自动化的基础

3.BUG 软件错误

  • 当且仅当规格说明书(软件需求)是存在的并且正确。程序与规格说明之间的不匹配(预期结果!=执行结果)才是错误
  • 当程序没有实现最终用户合理预期的功能要求时,就是软件错误。

4、开发模型和测试模型

1.软件的生命周期
  • 需求分析:分析需求是否合理、需求是否完整
  • 计划 : 谁开发、谁测试、开发多久、测试多久...
  • 设计 : 设计应该如何实现功能
  • 编码 :进行具体的代码编写
  • 测试 : 对代码功能进行测试,出具测试报告后才能上线
  • 运营维护 :如果线上有问题,测试人员需要协助开发定位、解决问题
2.开发模型
1.瀑布模型
  • 需求分析产出:需求文档
  • 设计环节产出:技术文档(涉及到哪些接口,库表,mq, 定时任务...)、UI视觉搞

特点:线性的

优点:强调开发的阶段性,每个阶段做什么,产出什么非常清晰

缺点:风险往往会推迟到后期测试阶段才会显露,失去及早纠正的机会

适应的项目:小型的项目

2.螺旋模型

优点:每个阶段都会进行风险分析,避免发生一些线上问题

缺点:风险分析可能会分析错,需要大量人力财力时间的投入

适应项目:比较大的项目、风险比较多的项目

3.增量、迭代

增量:逐块建造的概念,做完一个模块,再做下一个模块

迭代:反复求精,先整体,再细节 (就像素描,先画一个轮廓,再画手、画脸)

4.敏捷
敏捷宣言
  • 拥抱变化、请流程、重交付、轻文档、重交互

​ 个体与交互重于过程和工具(个体之间面对面沟通)

​ 可用的软件重于完备的文档 (开发文档、需求文档)

​ 客户协作重于合同谈判

​ 响应变化重于遵循计划

​ 在每对比对中,后者并非全无价值,但我们更看重前者。

scrume开发模式
三大角色

product owner(产品经理)

scrum master(项目经理)

team(研发团队):后端开发、前端开发、UI设计师、测试

流程

1.产品经理收集用户需求

2.项目经理将需求进行优先级的划分、计划项目什么时候开始和结束、由谁来做

3.每日站会,汇报昨天的工作。如果没有完成,遇到了什么问题、今天计划要做什么。

4.演示。

3.测试模型
1.V模型

特点:左边是开发、右边是测试、类似于瀑布模型

优点:测试被划分成很多类型

缺点:测试介入太晚,问题发现的时间太晚

2.W模型(双V模型)

特点:开发一个V 、测试一个V

优点:测试人员尽早的介入

缺点:测试人员和开发人员在一定程度上仍是串行的。并且不能拥抱变化、不能适应于敏捷

三、软件测试基础

1.软件测试的生周期

  • 需求分析->测试计划->测试设计、测试开发->测试执行->测试评估

需求分析:需求是否完整、需求是否正确

测试计划:确定由谁测试、什么时候开始测试、结束测试

测试设计:写测试用例(手工测试用例、自动化测试用例)、编写测试工具

测试执行:执行测试用例

测试评估:测试人员产生测试报告

2.描述一个BUG

1.发现问题的版本

2.出现问题的环境

3.错误重现的步骤

4.预期行为的描述

5.错误行为的描述

6.其他。比如BUG复现的前置条件、BUG给谁、BUG的优先级

1.BUG的优先级
  • 根据bug的影响程度进行划分

1.Blocker(崩溃):阻碍开发、测试工作的问题,系统崩溃、死机、数据库数据丢失、主要功能丧失...

2.Critical(严重):只要功能部分丧失、数据库保存调用错误、用户数据丢失

3.Major(一般):功能没有完全实现,但是不影响使用、如操作时间长、数据库表中字段过多。

4.Minor(次要):优化、建议类、不影响功能的使用。如错别字

强调:如果发现崩溃级别的bug,就需要停止测试,测试打回

2.BUG的生命周期
  • New:新发现的Bug,未经评审决定是否指派给开发人员进行修改。

  • Open:确认是Bug,并且认为需要进行修改,指派给相应的开发人员。

  • Fixed:开发人员进行修改后标识成修改状态,有待测试人员的回归测试验证。

  • Rejected:如果认为不是Bug,则拒绝修改。

  • Delay:如果认为暂时不需要修改或暂时不能修改,则延后修改。

  • Closed:修改状态的Bug经测试人员的回归测斌验证通过,则关闭Bug。

  • Reopen:如果经验证Bug仍然存在,则需要重新打开Bug,开发人员重新修改。

无效的bug:open->closed open-rejected-closed

3.如何发现bug

1.测试的二八定律:80%的故障集中于20%的模块

2.开发的二八定律:80%的故障集中于20%的开发人员

3.进行逆向思维和发散性思维

4.不局限于用例和需求文档

5.尽早介入项目

4.如何进行测试

1.充分理解需求

​ 文档(产品文档+技术文档)

​ 项目功能问题问产品。模块底层如何实现问开发

​ 参加会议

2.确定测试计划

3.执行测试

​ bug在开发修复之后,一定要进行验收

4.项目上线 +维护

点击移步博客主页,欢迎光临~

相关推荐
钱钱钱端8 小时前
【压力测试】如何确定系统最大并发用户数?
自动化测试·软件测试·python·职场和发展·压力测试·postman
测试199810 小时前
外包干了2年,快要废了。。。
自动化测试·软件测试·python·面试·职场和发展·单元测试·压力测试
qq_4337169515 小时前
测试分层:减少对全链路回归依赖的探索!
自动化测试·软件测试·功能测试·测试工具·回归·pytest·postman
qq_4337169516 小时前
Postman断言与依赖接口测试详解!
自动化测试·软件测试·功能测试·测试工具·mysql·接口测试·postman
生命几十年3万天17 小时前
通宵修bug
bug
LilKevinRay17 小时前
【SpringMVC】记录一次Bug——mvc:resources设置静态资源不过滤导致WEB-INF下的资源无法访问
java·笔记·mvc·bug
会发光的猪。18 小时前
前端vue3若依框架pnpm run dev启动报错
前端·javascript·vue.js·前端框架·bug
霍格沃兹测试开发学社测试人社区1 天前
软件测试学习笔记丨Vue常用指令-条件渲染(v-if)
软件测试·测试开发
测试老哥1 天前
需求不明确时如何设计测试用例?
自动化测试·软件测试·python·功能测试·测试工具·职场和发展·测试用例
程序员雷叔1 天前
外包功能测试就干了4周,技术退步太明显了。。。。。
功能测试·测试工具·面试·职场和发展·单元测试·测试用例·postman