【测试开发/测试】零基础轻松入门：了解软件测试中的BUG

🔥艾莉丝努力练剑：个人主页

❄专栏传送门：《C语言》、《数据结构与算法》、C/C++干货分享&学习过程记录、Linux操作系统编程详解、笔试/面试常见算法：从基础到进阶

⭐️为天地立心，为生民立命，为往圣继绝学，为万世开太平

🎬艾莉丝的测试开发博客简介：

​

一、软件测试的生命周期

软件测试贯穿于软件的整个生命周期，针对这句话我们一起来看一下软件测试是如何贯穿软件的整个生命周期。

软件测试的生命周期是指测试流程，这个流程是按照一定顺序执行的一系列特定的步骤，去保证产品质量符合需求。在软件测试生命周期流程中，每个活动都按照计划的系统的执行。每个阶段有不同的目标和交付产物。

​

各阶段具体内容：

二、BUG详解

2.1 概念：什么是BUG？

定义：一个计算机bug指在计算机程序中存在的一个错误 (error) 、缺陷 (flaw) 、疏忽 (mistake) 或者故障 (fault)，这些bug使程序无法正确的运行。Bug产生于程序的源代码或者程序设计阶段的疏忽或者错误。

准确的来说：

1、当且仅当规格说明是存在的并且正确，程序与规格说明之间的不匹配才是错误。 2、当需求规格说明书没有提到的功能，判断标准以最终用户为准：当程序没有实现其最终用户合理预期的功能要求时，就是软件错误。

2.2 BUG描述的要素

2.2.1 为什么描述BUG还要有要素要求

为什么描述bug还有要素要求?

在心理学上说，人们在编写文档的时候，经常会出现自己想表达的和写出来的内容往往南辕北辙。

bug描述：浏览器打开链接失败。

这种描述的坏处：在这个描述下，测试人员并没有明确说明是哪个浏览器打开链接失败，失败的具体表现是什么，这导致开发人员无法捕捉到更多有效的信息，会造成沟通效率低下，工作质量低下等问题。

2.2.2 案例展示

案例：101智慧课堂

​

在不同浏览器打开的效果截然不同，如果在谷歌浏览器打开后二维码被遮住了一半——

​

2.2.3 正确的BUG描述（例子）

（具体表现如下图所示——这句话不是BUG描述，下面块引用里面的才是）

​

问题出现的版本：谷歌浏览器版本123.0.6312.123（正式版本）（64位） 问题出现的环境：Windows家庭版 问题出现的步骤： 1、打开谷歌浏览器，输入网址101智慧课堂 2、等待首页页面渲染完成 预期结果：二维码与登陆模块不会出现遮挡，二维码可以正常扫描 实际结果：二维码被登陆模块遮挡，二维码扫描失败

2.3 BUG的级别

通过定义bug的级别，能够明确看出问题的严重程度。工作中开发人员通常需要按照bug的级别来分配优先级来处理bug，除此之外，通过bug级别也能够体现出开发人员的开发质量。

bug级别一般分为：崩溃、严重、一般、次要。

​

2.4 BUG也有生命周期

测试人员在执行测试的过程中如有发现bug，需要在对应的bug管理平台来创建bug（bug生命起 源），创建好的bug需要被开发人员修复，以及测试人员的持续跟踪和测试。

​

New：新发现的Bug，未经评审决定是否指派给开发人员进行修改。 Open：确认是Bug，并且认为需要进行修改，指派给相应的开发人员。 Fixed：开发人员进行修改后标识成修改状态，有待测试人员的回归测试验证。 Rejected：如果认为不是Bug，则拒绝修改。 Delay：如果认为暂时不需要修改或暂时不能修改，则延后修改。 Closed：修改状态的Bug经测试人员的回归测斌验证通过，则关闭Bug。 Reopen：如果经验证Bug仍然存在，则需要重新打开Bug，开发人员重新修改。 无效的bug：open->closed open-rejected-closed

三、解决冲突：如何处理和开发的关系（高频题）

在测试工作中，最常遇到的是和开发人员的PK，作为测试经理还会和项目经理、产品经理的PK进度、 质量。作为一名测试人员，一般会遇到以下几种情况——

​

工作当中遇到争执不要怕，我们要理性的分析和反馈问题。

3.1 先自省：是不是自己没有把BUG描述清楚

如果能正确地、高质量地录入一个Bug，那么基本上已经成功地与开发人员沟通了一大半的关于Bug的信息。但是总有“书难达意”的时候，这时就需要测试人员主动与开发人员进行沟通了。如果测试人员发现在写完一个缺陷后，好像还有很多关于Bug的信息没有表达出来，或者很难用书面语言表达出来时，就应该在提交Bug后，马上找相关的程序员解释刚才录入的Bug，确保程序员明白Bug描述的意思，而不要等待开发人员找自己了解更多的信息。

3.2 站在用户角度考虑并抛出问题

站在用户角度考虑问题，应该让开发人员了解到Bug对用户可能造成的困扰，这样才能促使开发人员更加积极地、高质量地修改Bug。当你身为测试人员和开发人员处在争执时，可以问开发人员一句：“如果你是用户，你可以接受么？”

3.3 BUG定级要有理有据

BUG定级时，不仅要参考BUG级别，还要考虑BUG是否会影响到流程，往往用户的BUG级别和我们的是有区别的，需站在用户的角度定考虑定位级别。

3.4 提高自身技术和业务水平，做到不仅能提出问题，最好也能给出解决方案

提高自身的业务和技术水平，不但要做到能提出问题，还能够提出解决问题的思路。这样才能更让人信服。在工作中，你会发现同一个bug，资深测试工程师提出和初级测试工程师提出，两者的结果完全不同，两者最大的差别是资深测试工程师往往会提出解决方案。而长此以往，权威性逐渐的建立起来，那么开发人员看到bug的第一反应，就是这是一个bug，而不是这是一个bug吗?

注意：可以给出解决方案，但是不能喧宾夺主，命令式让开发人员按照自己的想法来修改，这样日后可就不好一起共事了，等到熟悉业务、成为一个老练的测试人员之后，可以再提出BUG之后给出你认为的解决方案，也让知道你不是在挑他的刺。

3.5 BUG评审

如果确实是bug，尽管友好沟通了，还是不能解决问题，那么就得召开bug评审。

bug评审主要解决两个问题：

1）决定如何处理bug； 2）分析缺陷产生的原因，找出预防的对策。

bug评审至少需要项目组各个方面的代表参加——

1）测试代表

测试代表主要从Bug的具体表现、严重程度等方面提供信息，并提出自己对Bug的处理意见。需要注意的是，测试人员不应该一味地要求对Bug进行修改，因为修改可能带来回归的风险，同时带来的是回归测试的工作量，如果时间比较紧迫，修改后剩余的时间若不足以做一次有效的回归测试，可能不修改是个明智的选择。

2）开发代表

开发代表主要从修改缺陷的难度和风险出发，考虑缺陷修改需要付出的代价，以及可能影响的范围、可能引发的风险等，如果决定要修改，还要讨论出修改的初步方案。

3）产品代表（产品经理）

产品代表主要从产品的整体计划、用户的要求等方面对缺陷的修改必要性、缺陷修改的时间和版本提出自己的意见。

结尾

往期回顾：

【测试开发/测试】从“0”建立【模型】的概念：需求、开发模型、测试模型一文全知道

【测试开发/测试】初识测试：测试入门常见概念全知道

结尾：本期我们学习了测试开发/测试内容中的BUG篇，包括软件测试的生命周期、什么是bug、bug的要素、bug级别、bug的生命周期、怎么处理和开发的关系等等内容，希望对学习测试开发/测试相关内容的uu有所帮助，不要忘记给博主“一键四连”哦！

🗡博主在这里放了一只小狗，大家看完了摸摸小狗放松一下吧！🗡 ૮₍ ˶ ˊ ᴥ ˋ˶₎ა

​