软件测试基础

1. 软件测试的生命周期

在这里插入图片描述

需求分析：站在用户的角度查看需求逻辑是否正确，是否符合用户的需求和行为习惯。站在开发的角度思考需求是否可以实现，或者说实现起来难度高不高
测试计划：指定测试计划（包括不限于测试的工时，人力的安排等）
测试设计、测试开发：设计测试用例，经验丰富的白盒测试人员可以开始单元测试
测试执行：参考测试用例来执行测试
测试评估：测试人员需要记录测试、做好缺陷管理，然后进行测试评估

我们知道软件测试是贯穿于整个软件的声明周期的

软件测试的生命周期vs软件的生命周期?

回想一下软件的生命周期

需求分析
- 测试也要对需求进行分析，分析需求逻辑是否合理，需求是否符合用户的行为习惯，站在开发人员的角度思考技术实现难度，针对技术难度来合理调整需求
计划
- 根据需要编写测试计划/测试方案
设计
- 测试人员适当的了解设计，合理的进行测试用例设计和调整
编码
- 专业的白盒测试人员可以计划执行单元测试，完善、细化测试用例以及调整测试计划和方案
测试
- 参考测试用例来执行测试
运行维护
- 测试往往是最了解需求的人。测试人员通常来进行产品的演示和功能的介绍(演示会议)，期间记录下来大家反馈的建议，反馈给产品经理，成为以新的用户需求。

2. 如何描述一个Bug?

一个合格的 $b ug$ 应该需要包含以下几点

发现问题版本

开发需要知道是哪个版本出现了问题，才能获取到对应版本的代码来重现出问题。并且说明版本也有利于统计和分析每个版本的质量。
出现问题的环境

环境分为硬件环境和软件环境，如果是一个web项目，则需要提供浏览器版本，出现问题的操作系统版本等，如果是一个手机app项目，就需要描述出现问题的机型、分辨率、操作系统版本等等，详细的描述出现问题的环境更有利于问题的定位。
重现出现错误的步骤

以最短的不走描述能重现问题的步骤。
预期行为的描述

要让开发人员知道怎么样才是正确的，尤其哟啊已用户的角度来描述程序的行为到底是怎样的。如果是依据需求提出的故障，能写明需求的来源是最好的。（要坚信测试是最懂需求的！）
错误行为的描述

描述出现错误的现象，奔溃等问题可以上传日志，如果是UI有问题可以截图
其它

有些公式可能对故障进行分类或者是优先级进行分类，严重影响测试的故障需要开发修改的，可以设置高的优先级
不要把多个bug放到一起

如果是无法确定是同一段代码照成的故障，不要把bug放在一起！

示例：

标题：通过谷歌浏览器登录进入首页后，导航栏的信息有两行文字重叠
发现bug版本：Chrome版本: 113.0.5672.93（正式版本） （64 位）
发现bug环境：win10 Chrome
发现bug步骤：通过win10打开Chrome浏览器打开登录页面直接登录跳转首页
期望结果：跳转后首页右下角的两行文字正常间距展示
实际结果：跳转后首页的右下角的两行文字出现重叠
其它：(bug类型：前端问题，bug等级：次要)

3. Bug的级别

bug的定义不同的公司都不一致，在定义级别之前需要查看公式的规范

举几个列子：

Blocker（奔溃）

阻碍开发或者测试工作的问题，照成系统奔溃、死机、死循环甚至数据丢失，连接数据库出错，主要功能丧失，基本模块缺失等。比如：代码错误或者是发生死循环、死锁等，重要的一级菜单不能使用。不过这种问题在测试中是很少出现的，一般在开发阶段就会发现，但是如果一旦出现就应该立即终止当前版本测试。
Critical（严重）

系统主要功能部分丧失、数据库保存数据调用错处、用户数据丢失，一级功能菜单不能使用但是不影响其他功能测试。功能设计与需求严重不符，模块无法调用或者启动，程序自动重启或退出，关联程序调用冲突、安全问题、稳定性等。比如：软件中数据保存后数据库中显示出错，用户所要求的功能缺失，程序的接口错误，数值计算统计错误等。（该类问题如果出现，在不影响其它功能测试的情况下可以继续测试该版本）。
Major（一般）

功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。比如：操作反应慢、查询数据时间长、格式有点问题、删除没有确认框，数据库表中字段多等（该问题在测试中存在是最多的）
Minor（次要）

界面或者是性能有缺陷，建议类问题，不影响功能的执行，可以优化性能的方案等。比如：错别字。界面根式不规范、页面显示重叠、不该显示的要影藏、描述不清楚。提示语丢失，文字排列不整齐，光标位置不正确、用户体验感受不好，就是一些优化建立类的问题。(这类问题在测试初期较多，优先级程度较低，在测试后期出现较少，应及时处理)