软件测试基础认知

日升时奋斗，日落时自省 

目录

1、测试需求

2、测试用例

3、软件测试BUG

4、开发模型

4.1、软件的生命周期

4.2、瀑布模型（waterFall Model）

4.3、螺旋模型

4.4、 增量模型

4.4.1、增量开发

4.4.2、迭代开发

4.5、敏捷开发（scrum）

4.5.1、scrum里面的角色

4.5.2、流程

4.5.3、测试模型

5、软件测试的生命周期

5.1、BUG描述

5.2、BUG级别

5.3、BUG的生命周期

---

1、测试需求

软件测试的依据来源于需求是什么？才能进行准确测试

需求大体上常见以下两种：

用户需求：可以简单理解为甲方提出的需求。

软件需求：实际上也是功能需求，该需求会详细描述开发人员必须实现的软件功能

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

这个不难理解下面举一个例子，友友们就明白了（以登录系统为例）

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

 2、测试用例

上面测试需求中可能只有测试用例会让觉得很新颖，这里给友友们了解一下就不新颖了。

测试用例是用于验证软件系统是否符合预期功能的一组输入、操作和预期输出的详细描述。它是一种文档，用于记录测试人员在测试过程中发现的问题和解决方案；（这就跟你写文档一样，先干了啥后干啥：这里只是针对登录操作写的一个案例）

步骤动作:	期望的结果:
进入注册页面，选择注册（手动操作）	系统展现注册页面（效果）
输入符合要求的单位名称、单位邮箱、密码、确认密 码、组织机构代码、验证码，并确认同意《用户注册 协议》，提交注册信息（成功提供信息）	系统进行注册操作，发送激活邮件。注册 成功后，跳转到注册成功页面，并提示用 户进行激活操作。
进入注册用的邮箱，进行激活操作	激活成功
用注册的邮箱和密码，进行登录操作	登录成功，系统展示欢迎页面
测试方式	手工
重要性	重要
测试环境	CHROME,IE10+（浏览器版本，或者系统环境）
测试前提	系统运行正常，邮件服务器已开启
功能模块	注册登录模块

注：测试是否覆盖率是无从考量的，是衡量软件的指标，但是不是唯一的，对于新版本重复测试很难实施，不要存在大量冗余测试影响测试效率

3、软件测试BUG

注：规格说明是一份文档，用于描述软件系统的功能、性能、安全等方面的要求和限制。它通常由产品经理或业务分析师编写，包括这些内容：功能需求、性能需求、安全需求、界面需求等

平常见的BUG很普通（最常见的就是报红），但是不仅仅这样的BUG，程序与规格不匹配才是错误（BUG）

当需求规格说明没有提到功能，判定标准以最终用户为准：当程序没有实现其最终预期的功能要求时，就是软件错误

4、开发模型

开发模型是指在软件开发过程中，为了提高开发效率和质量，采用的一种组织和管理方式（这里就涉及到了软件的生命周期，一切的操作都是在软件的生命周期之内的）

4.1、软件的生命周期

软件生命周期是指从软件产品的设想开始到软件不再使用而结束的时间；

可以分为这6个阶段：需求分析、计划、设计、编码、测试、运行维护（end）

4.2、瀑布模型（waterFall Model）

执行方式：从开始-->需求分析-->计划-->设计-->编码-->测试-->结束

瀑布模式：一种线性的开发模型，每个阶段完成后才能进入下一个阶段

优点：

<1>为项目提供了按阶段划分的检查点。

<2>当前一阶段完成后，您只需要去关注后续阶段。

缺点：

<1>缺乏灵活性：瀑布模型是一种线性顺序的开发方法，一旦进入下一个阶段，就无法回退或修改之前的工作。这使得在项目开发过程中出现问题时，很难进行调整和修改。

<2>高成本：瀑布模型需要在每个阶段完成后进行评审和验收，这会增加项目的成本和时间。此外，由于每个阶段都需要完成所有后续阶段的工作，因此可能会导致资源浪费和重复工作。

<3>缺乏反馈：瀑布模型中的每个阶段都是独立的，没有及时的反馈机制来评估项目进展情况和质量。这可能导致项目延误或出现错误。

<4>不适用于快速变化的项目：瀑布模型适用于需求稳定、变化缓慢的项目。但对于需求频繁变化、技术更新迅速的项目，瀑布模型可能无法适应。

适用场景：比较小的项目

注：风险往往迟至后期的测试阶段才显露，因而失去及早纠正的机会（风险比较大）

4.3、螺旋模型

软件开发初期阶段需求不是很明显时，采用渐进式的开发模型，螺旋模型就是渐进式开发模型的代表之一

螺旋模型其实像是一个周期性模型（下图四个阶段就是一个周期的迭代），循环迭代，减小风险概率

螺旋模型：简单版

 

 注：上面的图解也不是个螺旋形状的，是一个比较简单的图解，下面是比较详细的螺旋图解，明白简单的螺旋图解之后就能知道复制的情况了，只是更详细了一点

螺旋模型：详细版

螺旋线的每个周期对应于一个开发阶段

注：图中的四个象限代表了以下活动

<1>制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件

<2>风险分析：分析评估所选方案，考虑如何识别和消除风险

<3>实施工程：实施软件开发和验证

<4>客户评估：评价开发工作，提出修正建议，制定下一步计划

适用场景：规模庞大、复杂度高、风险大的项目，不允许有一段独立的测试时间和阶段，测试必须跟随开发的迭代而迭代

4.4、 增量模型

4.4.1、增量开发

主要功能：增量开发是一种软件开发过程方法，其核心思想是模块化待开发的软件系统，将每个模块看作一个增量组件，并按优先级分批次分析、设计、开发、测试和交付增量组件 。在增量开发中，先开发主要功能模块，再开发次要功能模块，逐步完善，最终开发出符合需求的软件产品

 4.4.2、迭代开发

第一个阶段就覆盖了项目整体范围，以后每个阶段都是在前一阶段的基础上改进、完善，没有业务范围的扩展；

它将整个软件开发过程分成多个迭代周期，每个周期都包括需求分析、设计、编码、测试和部署等阶段。在每个迭代周期结束时，开发团队会交付一个可用的软件产品或服务，并进行反馈和改进

优缺点：

优点：是可以更快地响应客户需求和市场变化，提高开发效率和质量，减少风险和成本

缺点：可能会导致过度关注短期目标而忽略长期规划和架构设计，以及可能出现代码重复和维护困难等问题

注：每个模块开发一点，周期性开发

4.5、敏捷开发（scrum）

注：敏捷开发适用于需要快速响应变化、灵活适应、与客户紧密合作、高效交付的项目

4.5.1、scrum里面的角色

scrum由 product owner（产品经理）、scrum master（项目经理）和team（研发团队）组成

分别处理的任务：

<1>product owner（产品经理）：负责调整user story（用户事故）、定义其他商业价值、对其进行排序、定制发布计划、对产品负责；

<2>scrum master（项目经理）：负责召开会议、协调项目、为研发团队服务

<3>研发团队：不同成员组成、通过紧密协同、完成项目迭代、交付

4.5.2、流程

 4.5.3、测试模型

v模型：

特点：类似于瀑布模型 （左边是开发，右边是测试）

优点：测试被分为多各类型

缺点：测试人员介入太晚，修复成本比较高，就是一个阶段一个阶段处理

双v模型（w模型）：

注：先清楚单v模型，再看双v模型会更清晰

 特点：开发是一个v，测试是一个v

优点：测试人员尽早的介入需求  

缺点：测试人员和开发人员还是一个串行的（例如系统测试出现问题，就需要回溯到测试文档处）

5、软件测试的生命周期

软件测试的生命周期：需求分析-->测试计划-->测试设计、测试开发-->测试执行-->测试评估

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

测试计划：确定软件由谁测试，开始测试，结束测试的时间

测试设计：写测试用例（手工测试用例，自动化测试用例）、编写测试工具

测试执行：执行测试用例

测试评估：测试人员产生测试报告（包含测试人员、测试时间、开发人员、开发时间、测试用例、BUG、文档）

5.1、BUG描述

<1>发现问题的版本（哪个版本不兼容）

<2>问题出现的环境（硬件环境和软件环境）

<3>错误重现的步骤

<4>预期行为的描述（以用户角度描述程序是怎么样的，最好的就是能写明来源）

<5>错误描述（描述现象，上传log，UI视觉问题可以截图）

<6>不要把多个BUG放在一起提交，不好确认

5.2、BUG级别

BUG按照优先级进行处理；

<1>Blocker（崩溃）：造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错
误，主要功能丧失，基本模块缺失等问题（例如婚外恋：不能原谅级别，需要及时止损）

<2>Critical（严重）：系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试。功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用冲突，安全问题、稳定性等（例如婚外暧昧关系：问题不小，但是还能纠正）

<3>Major（一般）：功能方面不能完全但是不影响使用，有缺陷但是不影响系统稳定性

<4>Minor（次要）：界面、性能缺陷、建议类问题，不影响功能的执行，今天优化性能的方案，界面不规范，页面实现重叠，描述不清楚（例如：男朋友张的有点磕碜，但是还是爱你，所以无伤大雅，可以后天性整改）

5.3、BUG的生命周期

这里通过一个流程图来理解BUG的生命周期；

 注：针对以上进行解释

<1>New：新发现的BUG，未经评审决定是否指派给开发进行修改

<2>Open：确定是BUG，并且认为需要进行修改，指派给相应的开发人员

<3>Fixed：开发修改后表示修改状态，待测人员回归测试验证

<4>Reject：认为不是BUG，可以拒绝修改

<5>Delay：暂时不做修改，或者暂时不能修改

<6>Closed:修改状态的BUG测试回归通过

<7>Reopen：修改后仍然有BUG，打回