【软件测试】 软件测试生命周期与Bug

简介: 【软件测试】 软件测试生命周期与Bug

🍃前言

本篇文章主要内容如下:

  • 软件测试的生命周期
  • 如何描述一个bug
  • 如何定义bug的级别
  • bug的生命周期

🌴软件测试的生命周期

🚩软件的生命周期

需求分析,计划,设计,编码,测试,运行维护。

需求阶段

  • 测试人员了解需求、对需求进行分解,得出测试需求

计划阶段

  • 根据需求编写测试计划/测试方案

设计阶段

  • 测试人员适当的了解设计,对于设计测试用例是很有帮助的,测试人员搭建测试用例框架,根据需求和设计编写一部分测试用例

编码阶段

  • 测试人员一般是不需要编码的,但已经编码的模块,专业的白盒测试人员可以计划执行单元测试,完善、细化测试用例以及调整测试计划和方案。

测试阶段

  • 测试阶段是软件测试人员最为重要的工作阶段,根据测试用例和计划执行测试,在执行的过程中记录、管理缺陷,测试完成后编写测试报告。

运行维护

  • 测试人员需要参与项目的实施工作。测试人员对项目产品的业务和操作非常了解,加上测试人员的沟通表达能力一般都比较强,所以测试人员可以参与用户使用软件的培训,在试运行项目时收集问题并及时反馈给相关负责人。

🚩软件测试的生命周期

需求分析→测试计划→ 测试设计、测试开发→ 测试执行→ 测试评估

🌲BUG

bug指的就是程序或软件运行结果不符合我们的预期

🚩如何描述一个bug

一个合格的bug描述应该包括以下几个部分:

1、发现问题的版本

  • 开发人员需要知道出现问题的版本,才能够获取对应版本的代码来重现故障。并且版本的标识也有利于统计和分析每个版本的质量。

2、问题出现的环境

  • 环境分为硬件环境和软件环境,如果是web项目,需要描述浏览器版本,客户机操作系统等,如果是app项目,需要描述机型、分辨率、操作系统版本等。详细的环境描述有利于故障的定位。

3、错误重现的步骤

  • 描述问题重现的最短步骤。

4、预期行为的描述

  • 要让开发人员指导怎么样才是正确的,尤其要以用户的角度来描述程序的行为是怎样的。如果是依据需求提出的故障,能写明需求的来源是最好的。要相信:测试人员是最懂需求的。

5、错误行为的描述

  • 描述错误的现象。crash等可以上传log,UI问题可以有截图。

6、其他

  • 某些公司会有一些其他的要求,例如故障的分类:功能故障,界面故障,兼容性故障等。有些有优先级的分类,严重影响测试需要开发人员优先修改的,可以设置优先级为高。

7、不要把多个bug放到一起

  • 在无法确认是同一段代码造成的故障时,不要将bug放在一起提交

🚩如何定义bug的级别

bug的定义每个公司都不一致,在定义级别之前需要查看公司规范。

以下为样例:

1、Blocker(崩溃):

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

2、Critical(严重)

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

3、Major(一般):

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

4、Minor(次要):

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

🚩bug的生命周期

每个公司、每一个工具对bug生命周期的定义都是不一致的,下面仅是一个常见的例子

测试人员应该跟踪一个Bug的整个生命周期,从Open到Closed的所有状态。

BUG状态转换图如下:

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

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

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

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

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

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

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

无效的bug:open->closed 或 open-rejected-closed

⭕总结

关于《【软件测试】 软件测试生命周期与Bug》就讲解到这儿,感谢大家的支持,欢迎各位留言交流以及批评指正,如果文章对您有帮助或者觉得作者写的还不错可以点一下关注,点赞,收藏支持一下!

相关文章
|
8天前
|
机器学习/深度学习 人工智能 算法
深入探索软件测试中的黑盒测试技术
本文旨在通过一个创新视角,探讨软件测试领域中的黑盒测试技术。我们将从一个全新的维度——测试用例的生成策略出发,分析如何提高黑盒测试的效率和效果。文章不仅会介绍传统的测试用例设计方法,如等价类划分、边界值分析等,还会结合最新的技术发展,讨论人工智能在黑盒测试中的应用前景。通过案例分析和实践应用,我们期望为读者提供一套系统的黑盒测试解决方案,以应对日益复杂的软件测试需求。
|
12天前
|
敏捷开发 测试技术
软件测试中的探索性测试方法
【6月更文挑战第12天】探索性测试,一种灵活的测试实践,旨在通过自由形式的探索发现软件的潜在缺陷。它不依赖于事先编写的测试用例,而是鼓励测试人员利用直觉、经验和创造力来指导测试过程。本文将深入探讨探索性测试的核心概念、实施策略以及它如何增强传统测试方法的有效性。
|
6天前
|
敏捷开发 测试技术
软件测试中的探索性测试方法
【6月更文挑战第18天】本文将深入探讨探索性测试(Exploratory Testing)在软件测试领域的重要性与实施策略。不同于传统的脚本化测试,探索性测试强调测试人员的主观能动性和创造性,以真实用户的角度出发,发现那些可能在规范性测试中被忽视的问题。文章首先介绍探索性测试的定义和优势,然后通过案例分析,展示如何有效执行探索性测试,最后讨论其在敏捷开发环境中的适应性以及如何与传统测试方法相结合以提升测试覆盖率和效率。
|
21天前
|
NoSQL 关系型数据库 MySQL
软件测试之【基于开源商城系统fecmall功能测试项目实例】
软件测试之【基于开源商城系统fecmall功能测试项目实例】
48 0
软件测试之【基于开源商城系统fecmall功能测试项目实例】
|
1月前
|
测试技术 数据安全/隐私保护
通过抓包能否做好接口测试
通过抓包能否做好接口测试
23 0
|
6天前
|
JSON Java Maven
使用`MockMvc`来测试带有单个和多个请求参数的`GET`和`POST`接口
使用`MockMvc`来测试带有单个和多个请求参数的`GET`和`POST`接口
19 3
|
1月前
|
NoSQL 安全 测试技术
接口测试用例设计的关键步骤与技巧解析
该文介绍了接口测试的设计和实施,包括测试流程、质量目标和用例设计方法。接口测试在需求分析后进行,关注功能、性能、安全等六项质量目标。流程包括网络监听(如TcpDump, WireShark)和代理工具(Charles, BurpSuite, mitmproxy, Fiddler, AnyProxy)。设计用例时,需考虑基本功能流程、输入域测试(如边界值、特殊字符、参数类型、组合参数、幂等性)、线程安全(并发和分布式测试)以及故障注入。接口测试用例要素包括模块、标题、优先级、前置条件、请求方法等。文章强调了保证接口的幂等性和系统健壮性的测试重要性。
54 5
|
7天前
|
监控 前端开发 测试技术
postman接口测试工具详解
postman接口测试工具详解
35 7
|
7天前
|
监控 JavaScript 前端开发
postman接口测试工具详解
postman接口测试工具详解
20 6
|
1天前
|
监控 druid Java
Springboot用JUnit测试接口时报错Failed to determine a suitable driver class configure a DataSource: ‘url‘
Springboot用JUnit测试接口时报错Failed to determine a suitable driver class configure a DataSource: ‘url‘
6 0

热门文章

最新文章