软件测试的生命周期、Bug

一、软件测试的生命周期

1、软件的生命周期：

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

设计：项目的上线时间、开始开发时间、测试时间、人员...

计划：设计技术文档、进行UI设计...

编码：写代码（实现用户需求）。

测试：测试软件是否有 Bug。

运行维护：出现线上问题进行修复。

2、软件测试的生命周期

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

测试计划：测试人员、测试开始与结束时间、上线时间...

测试开发：开发测试工具、开发自动化测试用例...

测试执行：提交 Bug并验收。

测试评估：产出测试报告。

二、Bug（软件缺陷）

1、描述

一个 bug 的描述应包含一下方面：

1.1、出现问题的版本。

1.2、问题出现的环境：分为硬件环境和软件环境。若是一个 web 项目，则需描述浏览器版本、客户机操作系统等（如电脑端：windows10，64位操作系统，Microsoft Edge版本 108.0.1462.42 (正式版本) ）；若是APP项目，则需描述机型、分辨率、操作系统版本等。详细的环境描述有利于定位故障。

1.3、错误重现的步骤：描述问题重现的最短步骤。

1.4、预期行为的描述

1.5、错误行为的描述：描述错误的现象，如 log 日志、UI问题的错误截图等。

1.6、其他：故障的分类（判断是需求、缺陷（包含功能性、浏览器兼容性、界面故障还是性能）还是建议级别），优先级的分类等。

PS：在不确定是否是由于同一段代码造成的故障时，不能把 bug 放在一起提交。

例如：

编号：#1

标题：购物车全选按钮和结算功能

版本：v1.0.0

环境：华为CDY-AN00（机型），鸿蒙版本2.0.0.294（版本号），2400x1080（分辨率）

状态：未解决

优先级：中

重要程度：严重

所属模块：购物车、管理

前置条件：联网、已登录、购物车中有商品

重现步骤：点击【购物车】-【全选】-【结算】，再点击【返回（确认订单）】 

预期行为：不清空总额，全选按钮仍勾选

错误行为：清空总额，全选按钮取消

创建人：A

指派给：B

计划日期：xxxx.xx.xx

截止日期：yyyy.yy.yy

2、级别

2.1、Blocker（崩溃）：

阻碍开发或测试工作的问题；造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错 误，主要功能丧失，基本模块缺失等问题。如：代码错误、死循环、数据库发生死锁、重要的一级菜单功能不能使用等。（该问题在测试中较少出现，一旦出现应立即中止当前版本测试）。

2.2、Critical（严重）：

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

2.3、Major（一般）：

功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。如：操作时间长、查询时间长、格式错误、边界条件错误，删除没有确认框、数据库表中字段过多等。（ 该问题实际测试中存在最多）。

2.4、Minor（次要）：

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

3、bug 缺陷的生命周期流程

4、bug状态的转换

New：新发现的 bug ，测试人员bug提交所标志的状态。

Open：确认是 bug ，且认为需要进行修改，再指派给相应开发人员。

Rejected：确认不是 bug ，则拒绝修改。由 bug 分配人或开发人员进行设置。

Dely：暂时认为不需要或者不能修改，则延后修改。

Fixed：开发人员修改问题后所标志的状态，修改后还未进行测试。

Reopen： 经验证后，bug 仍存在，则需要重新打开 bug，开发人员再重新修改。

Closed：验证的 bug 经过测试人员回归验证测试通过，则关闭 bug。

 PS：无效的 bug：Open ==> Closed、Open ==> Rejected  ==> Closed

PS：还可参考：测试中BUG定义、测试BUG的等级划分、Bug流程以及Bug解决优先级_测试bug成功率的定义_测试小扎的博客-CSDN博客

浅谈BUG的定义 - 知乎 (zhihu.com)