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

Posted 2021-07-18 赵jc

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了软件测试学习之旅----概念篇相关的知识，希望对你有一定的参考价值。

概念篇

需求是什么？
软件测试的生命周期
开发模型和测试模型
BUG

需求是什么？

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

用户需求：用户想要软件实现的功能（相对来说比较简单，没有具体的实现细节，有时候可能就是用户的一句话，但我们需要将其具体化）
软件需求：用户需求的具体化，有用户需求转化而来（开发人员根据软件需求进行软件开发）
举个例子吧

软件测试的生命周期

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

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

开发模型和测试模型

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

瀑布模型

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

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

螺旋模型

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

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

迭代、增量模型

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

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

`敏捷模型`

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

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

scrum的流程

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

在这里插入图片描述
测试模型主要有两个，v模型和w模型

软件测试V模型

V模型最早是由Paul Rook在２０世纪８０年代后期提出的，目的是改进软件开发的效率和效果。是瀑布模型的变种
在这里插入图片描述

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

软件测试W模型

W模型增加了软件各开发阶段中应同步进行的验证和确认活动。W模型由两个V字型模型组成，分别代表测试与开发过程，图中明确表示出了测试与开发的并行关系。
在这里插入图片描述

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

BUG

什么是bug？

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

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

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

bug的等级

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

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

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

bug的生命周期

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