【软件测试】基础概念总结

目录

一、什么需求

二、什么是BUG

三、什么是测试用例

四、开发模型

1,瀑布模型 

2,螺旋模型

3,迭代,增量模型

4,敏捷模型

六、测试模型

1,V模型

2,W模型

七、BUG级别

1,崩溃

2,严重

3,一般

4,次要

八、BUG的生命周期


一、什么需求

IEEE定义:软件需求是

(1)用户解决问题或达到目标所需条件或权能(Capability)。

(2)系统或系统部件要满足合同、 标准、规范或其它正式规定文档所需具有的条件或权能。

(3)一种反映上面(1)或(2)所述条件或权能的文档说明。它 包括功能性需求及非功能性需求,非功能性需求对设计和实现提出了限制,比如性能要求,质量标准,或者设计限制。

以社交APP发朋友圈为例(boss)

需求——分析/设计——开发——测试——上线

用户需求:用户想要软件实现的功能

软件的需求用户需求的具体细化,是用户需求的具体实现,开发人员根据软件需求进行软件开发

软件的开发中的需求:需求就是满足用户的期望或者合同规定的标准,规范,文档所需的条件和权限

二、什么是BUG

第一个bug :

1945年9月的某天,在一间老式建筑里,从窗外飞进来一只飞蛾,此时Hopper正埋头工作在一台名为Mark Il的计 算机前,并没有注意到这只即将造就历史事件的飞蛾。这台计算机使用了大量的继电器(电子机械装置,那时还没 有使用晶体管)。突然,Mark II死机了。Hopper试了很多次还是不能启动,他开始用各种方法查找问题,最后定 位到了某个电路板的继电器上。Hopper观察这个继电器,惊奇地发现一只飞蛾已经被继电器打死。Hopper小心地 用镊子将飞蛾夹出来,用透明胶布贴到“事件记录本”中,写上“第一个发现虫子的实例”。Hopper的事件记录本,连 同那只飞蛾,现在都陈列在美国历史博物馆中。 软件错误的一般定义: 程序与规格说明之前不匹配

分为两种情况:

1)当软件需求的规格(软件需求)存在且合理,如果软件和软件需求规格不相符,就说是软件错误(BUG)

2)当软件需求规格不存在的时候,用户需求存在且合理,软件功能和用户需求不相符,就说是软件错误(BUG)

三、什么是测试用例

向被测试系统发起的一组集合,这组集合包括测试数据,测试步骤,测试平台,预期结果

以注册网易邮箱为例

 1)测试数据

邮箱地址:xiaoming123

密码:123456789

手机号:13344445555

2)步骤

打开网易邮箱注册页面

输入邮箱地址,密码,手机号

勾选同意条款,点击立即注册

3)测试平台

Chrome浏览器

4)预期结果

注册成功

四、开发模型

1,瀑布模型 

优点:各个阶段比较独立,看重需求分析和软件测试

缺点:无法适应需求的变化,测试到编码后才介入,导致前期的缺陷无法实现及时发现,无法及时修正

2,螺旋模型

适应项目:前期需求不是很明确,并且有风险,项目比较庞大的系统开发

优点:强调软件质量,每一次迭代进行严格的风险分析,提供讨论项目是否有必要进行下去的机会

缺点:引入风险管理,会投入大量的人力物力

3,迭代,增量模型

一个系统的四个功能:A模块,B模块,C模块,D模块,两周时间内完成

迭代模型:第一周开发人员完成ABCD四个模块基础功能,第二周,在基础功能上进行细化和完善

增量模型:第一周,完成AB模块,第二周,完成CD模块

4,敏捷模型

轻文档,轻流程,重目标,重质量,拥抱变化,可以适应需求的变化

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

1)发布计划会议

2)迭代计划会议

3)开发工程中,每日站会

4)产品演示评审会

5)回顾会议

六、测试模型

1,V模型

优点:左边的每一阶段和右边的每一阶段一一对应,左边的每一阶段是右边的每一测试阶段的依据

缺点:测试介入晚,会失去前期错误及时纠正的机会,每一阶段是一个单一串行的工程,不能适应需求的变化,无法应用到敏捷开发

2,W模型

优点:测试介入比较早,前期的风险可以及时发现,及时纠正

缺点:每一阶段是一个单一串行的过程,不能适应需求的及时变化,无法应用到敏捷开发

七、BUG级别

1,崩溃

系统无法运训,严重到阻碍了开发人员或者测试人员的工作,如果线上出现这种情况,立马退回版本到一个的系统稳定的状态

2,严重

系统还可以运行,但是已经不稳定了,如果继续运行下去,会产生严重的后果

3,一般

系可以稳定的运行,但会影响用户的操作

4,次要

建议性的BUG,页面问题,排版,字体大小,弹出框但是没有明确定的按钮,图片显示

八、BUG的生命周期

New:发现bug,未经评审决定是否指派给开发人员进行修改。

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

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

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

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

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

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

猜你喜欢

转载自blog.csdn.net/qq_50156012/article/details/124481154