软件测试学习之旅----概念篇

概念篇

  • 需求是什么?
  • 软件测试的生命周期
  • 开发模型和测试模型
    • 瀑布模型
    • 螺旋模型
    • 迭代、增量模型
    • 敏捷模型
    • 软件测试V模型
    • 软件测试W模型
  • BUG
    • 什么是bug?
    • bug的等级
    • bug的生命周期
    • 如何描述一个bug?

需求是什么?

需求简而言之就是想要干什么事。在互联网方面主要分为用户需求和软件需求

  • 用户需求:用户想要软件实现的功能(相对来说比较简单,没有具体的实现细节,有时候可能就是用户的一句话,但我们需要将其具体化)
  • 软件需求:用户需求的具体化,有用户需求转化而来(开发人员根据软件需求进行软件开发)
    举个例子吧
    软件测试学习之旅----概念篇_第1张图片

软件测试的生命周期

需求分析---->测试计划---->测试设计/开发---->执行测试---->测试报告—>运行维护

  • 需求分析:分析需求,细化需求,验证需求的正确性和合理性
  • 测试计划:规划测试人员数量,规划测试时间、范围和目的
  • 测试设计/开发:分析需求,从细化的需求中提炼功能点,设计测试用例
  • 测试执行:执行测试用例,记录bug
  • 测试报告:测试的范围,有多少测试用例执行了,余留了多少测试用例,发现了多少bug,修改了多少bug(验证通过确定修改了),遗留的bug和解决方案
  • 运行维护

开发模型和测试模型

开发模型有五种常用的,瀑布模型,螺旋模型,敏捷模型,迭代、增量模型

瀑布模型

瀑布模型在软件工程中占有重要地位,是所有其他模型的基础框架。瀑布模型的每一个阶段都只执行一次,因此是 线性顺序进行的软件开发模式。
在这里插入图片描述

  • 优点:各个阶段比较独立,看重需求分析和软件测试
  • 缺点:无法适应需求的变化,测试到编码后才介入,导致前期的缺陷无法及时发现和修正
  • 应用场景:适用于需求稳定的项目

螺旋模型

一般在软件开发初期阶段需求不是很明确时,采用渐进式的开发模式。螺旋模型是渐进式开发模型的代表之一。
这对于那些规模庞大、复杂度高、风险大的项目尤其适合。这种迭代开发的模式给软件测试带来了新的要求,它不 允许有一段独立的测试时间和阶段,测试必须跟随开发的迭代而迭代。因此,回归测试的重要性就不言而喻了。
软件测试学习之旅----概念篇_第2张图片

  • 优点:强调软件的质量,每一次迭代进行严格的风险分析,讨论项目是否有必要进行下去
  • 缺点:引入风险管理,会投入大量的人力物力
  • 应用场景:前期需求不是很明确,并且有风险,项目比较庞大的系统开发

迭代、增量模型

迭代和增量模型一般配合使用,例如,一个系统有四个功能,ABCD四个模块,要在两周之内完成

  • 迭代模型:第一周开发人员完成ABCD四个模块的基础功能,第二周,在基础功能之上进行细化和完善(迭代模型的的抗风险能力更强)
  • 增量模型:第一周完成AB模块,第二周完成CD模块

敏捷模型

敏捷模型是现在主流的模型,它轻文档,轻流程,看重目标和质量,可以适应需求的变化,目标是交付一个高质量可用的软件
scrum是现在主流的敏捷开发的一种形式,它主要包含三部分的成员,crum由product owner(产品经理)、scrum master(项目经理)和team(研发团队)组成。

  • PO:产品经理product owner负责整理user story(用户故事),定义其商业价值,对其进行排序,制定发布计划,对产品负责。
  • SM:项目经理scrum master 负责召开各种会议,协调项目,为研发团队服务,负责保证整个敏捷流程的顺利实施
  • ST:scrun Team研发团队则由不同技能的成员组成,通过紧密协同,完成每一次迭代的目标,交付高质量的产品。

scrum的流程

  1. 发布计划会议
  2. 迭代计划会议
  3. 开发过程中的每日站会
  4. 产品演示评审会
  5. 回顾会议

软件测试学习之旅----概念篇_第3张图片
测试模型主要有两个,v模型和w模型

软件测试V模型

V模型最早是由Paul Rook在20世纪80年代后期提出的,目的是改进软件开发的效率和效果。是瀑布模型的变种
软件测试学习之旅----概念篇_第4张图片

  • 优点:左边开发的每一个阶段和右边测试的每一个阶段一一对应,同时也是有右边每一个测试的依据
  • 缺点:测试介入晚,前期的错误和风险到后期才发现,会失去及时纠正的机会

软件测试W模型

W模型增加了软件各开发阶段中应同步进行的验证和确认活动。W模型由两个V字型模型组成,分别代表测试 与开发过程,图中明确表示出了测试与开发的并行关系。
软件测试学习之旅----概念篇_第5张图片

  • 特点:测试的对象不仅是程序,需求、设计等同样要测试,测试与开发是同步进行的
  • 优点:测试阶段和开发阶段在两个独立的V模型里面,测试介入得比较早,在项目初期就介入了,前期的风险可以及时被发现
  • 缺点:W模型每一个阶段任然是一个串行的过程,不能适应需求变化的项目,所以无法应用到敏捷开发

BUG

什么是bug?

凡是实现效果和需求不相符的都可以认为是BUG.一般分为两种情况

  • 当软件需求存在并且合理,如果软件功能和软件规格不想符合,就是一个bug
  • 当软件需求不存在的时候,用户需求存在且合理,软件功能和用户需求不相符,就是一个bug

对bug我们要心存敬畏, 但是不要害怕. 程序猿身上背负的bug, 就是一个老兵身上的疤痕, 最值得骄傲的军功章(没有事不可能得啦,不是在写bug,就是在修改bug的路上(笑哭))

bug的等级

bug一般分为四个等级,崩溃、严重、一般、次要

  • 崩溃:系统运行阻断,严重影响了开发人员和测试人员的工作,需要立马修复
  • 严重:系统还可以运行,但是已经不稳定了,如果在运行下去,可能会产生严重的后果
  • 一般:系统可以稳定的运行,但一些次要的功能还没有实现,可能会影响用户的体验
  • 次要(建议性):用户需求中没有严格要求的,但影响用户的视觉体验(界面的文字提示内容,图片的排版等)要不要改需要和产品经理商量

线上出现崩溃级别的bug怎么办?
回退到上一个版本

bug的生命周期

每个公司、每一个工具对bug生命周期的定义都是不一致的,下面仅是一个常见的例子测试人员应该跟踪一个Bug的整个生命周期,从Open到Closed的所有状态。
BUG状态转换图
软件测试学习之旅----概念篇_第6张图片
●New:新发现的Bug,未经评审决定是否指派给开发人员进行修改。
●Open:确认是Bug,并且认为需要进行修改,指派给相应的开发人员。
●Fixed:开发人员进行修改后标识成修改状态,有待测试人员的回归测试验证。
●Rejected:如果认为不是Bug,则拒绝修改。
●Delay:如果认为暂时不需要修改或暂时不能修改,则延后修改。
●Closed:修改状态的Bug经测试人员的回归测斌验证通过,则关闭Bug。
●Reopen:如果经验证Bug仍然存在,则需要重新打开Bug,开发人员重新修改。
无效的bug:open->closed open-rejected-closed

如果测试人员提了一个bug,开发人员已经修改了,但是测试人员测试的时候,发现bug依旧存在,有哪些原因?

  • 测试人员忘记拉取最新的代码到测试环境进行发布(先从自身找问题)
  • 开发人员没有吧代码更新到测试环境
  • 开发人员没有修改好

如何描述一个bug?

  • 版本号(代码版本号)
  • 测试环境(平台),不同的浏览器对同一个系统的同一个页面解析是不同的
  • 测试步骤和测试数据
  • 实际结果
  • 预期结果
  • 附件(错误截图,错误日志等)

举例:
软件测试学习之旅----概念篇_第7张图片
软件测试学习之旅----概念篇_第8张图片

如果碰到bug和开发人员产生冲突怎么办?

  • 先检查自己的bug是否描述清楚
  • 检查bug的定级是否按照公司的标准来的
  • 站在用户的角度去说服开发人员
  • 不断提高自己的业务水平和技术水平
  • 和开发人员,产品经理商量bug的解决方案

但这些都是套话啦,现实中情商高一点,多和开发人员走动走动搞好关系,出了bug一起解决岂不美哉!

你可能感兴趣的:(软件测试,软件测试)