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

目录

一、什么需求

二、什么是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，开发人员重新修改。