软件测试相关概念和bug的相关总结

什么是测试

测试是测试人员用来检验软件的实际运行结果是不是满足用户的需求

什么是需求

用户需求 : 用户想要干什么, 想要实现什么功能
软件需求 : 是一个文档, 用来描述功能是如何实现的.

测试用例(CASE)

测试用例是一组集合 , 用来测试环境 , 测试数据 , 预期结果 , 操作步骤等.
作用

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

什么是BUG

当且仅当规格说明书软件需求)存在且正确,程序与规格说明书之间不匹配才是错误.
当规格说明书不存在的功能,当程序最终没有实现用户合理的功能预期要求, 也是错误.

软件的生命周期

软件生命周期是指从软件产品的设想开始到软件不再使用而结束的时间。如果把软件看成是有生命的事物,那么软件的生命周期可以分成6个阶段,即需求分析、计划、、设计、编码、测试、运行维护。

开发模型

瀑布模型

在这里插入图片描述

  • 特点 : 线性的
  • 优点 : 每个阶段做什么 , 产出什么非常清晰
  • 缺点 : 测试人员介入太晚, 风险往往迟至后期的测试才显现出来,因而失去及早纠正的机会.
    适用项目 : 小型的项目

螺旋模型

在这里插入图片描述

  • 优点 : 每个阶段都会进行风险分析,避免一些线上问题的发生.
  • 缺点 : 风险分析可能出错, 需要大量人力财力的投入.
  • 适用项目 : 适用于比较大的, 风险较多的项目.

增量模型和迭代模型

理解增量模型和迭代模型的区别.

  • 增量模型是完成一个模块,在进行下一个模块,逐步完成系统的所有功能.
  • 迭代模型是完成一个模块的一部分, 进行下一个模块.通过多次循环迭代来完成这个系统

敏捷

下面是敏捷的内容
在这里插入图片描述

敏捷开发有很多种方式,其中scrum是比较流行的一种。
scrum

  • scrum里面的角色 scrum由product owner(产品经理)、scrum master(项目经理)和team(研发团队)组成
  • 其中product owner负责整理user story(用户故事),定义其商业价值,对其进行排序,制定发布计划,对产品负责。
  • scrum master负责召开各种会议,协调项目,为研发团队服务。
  • 研发团队则由不同技能的成员组成,通过紧密协同,完成每一次迭代的目标,交付产品。

测试模型

v模型

在这里插入图片描述

特点 : 左边是开发 , 右边是测试, 类似于瀑布模型
优点 : 测试被划分成许多类
缺点 : 测试人员介入太晚.

W模型(双V模型)

在这里插入图片描述

  • 特点 : 开发一个V模型, 测试一个V模型
  • 优点 : 测试对象不仅是程序,需求,设计等也需要测试.
    测试介入早有利于过早发现问题
  • 缺点 : 测试人员和开发人员一定程度上是串行的
    测试和开发也保持一种线性的先后关系 ,不能拥抱变化,不适用于敏捷.

软件测试的生命周期

在这里插入图片描述

如何描述一个bug

  1. 发现问题的版本.
    只有正确的版本,开发人员才能找到对应的代码来重现故障.
  2. 问题出现的环境. 环境分为硬件环境和软件环境.
    如果是web项目,需要描述浏览器版本,客户机操作系统等
    如果是app项目,需要描述机型, 分辨率,操作系统版本等.详细的环境有利于故障的定位.
  3. 错误重现的步骤
  4. 预期行为的描述 要让开发人员站在用户的角度描述程序的行为是怎么样的.
  5. 描述故障的种类: 功能故障,界面故障,兼容性故障等. 优先级不同,开发人员修改的顺序也不同
  6. 不能把多个bug放在一起提交

bug的级别

  1. Blocker(崩溃)
    阻碍开发或测试工作的问题; 造成系统崩溃,司机,死循环,数据库数据丢失,主要功能丢失,主要模块丢失等.
  2. Critical(严重)
    系统主要功能部分丧失,功能设计和需求不符,模块无法启动或调用,程序重启,自动退出,关联程序间嗲用冲突等.
  3. Major(一般)
    功能没有完全实现但不影响使用,功能菜单存在缺陷但不影响系统稳定.如操作时间长,查询时间长等
  4. Minor(次要)
    界面,性能存在缺陷, 不影响操作功能的执行,可以优化性能的方案等.

bug的生命周期.

在这里插入图片描述

产生争执怎么办

  1. 先检查自身,确认是否是bug, 是否bug描述不清楚.
  2. 站在用户的角度考虑问题,让开发了解到bug可能对用户产生的困扰.
  3. bug的定级要有理有据
  4. 提高自身的技术和业务水平, 不光要做到能提出问题, 最好也能提出解决方案.
  5. 开发不接受时,不要争吵,多沟通,反复沟通无效提出bug评审.
    bug评审主要包括两个层面
  • 决定如何处理bug
  • 分析缺陷产生的原因

.

  • 28
    点赞
  • 26
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值