软件测试BUG

感谢各位大佬对我的支持,如果我的文章对你有用,欢迎点击以下链接
🐒🐒🐒 个人主页
🥸🥸🥸 C语言
🐿️🐿️🐿️ C语言例题
🐣🐣🐣 python
🐓🐓🐓 数据结构C语言
🐔🐔🐔 C++
🐿️🐿️🐿️ 文章链接目录
🏀🏀🏀 笔试练习题
🐯🐯🐯 Git
😎😎😎 软件测试

软件测试的生命周期

软件测试贯穿于软件的整个生命周期,他的整个生命周期过程如下

上一篇文章中说的是软件的生命周期,软件的生命周期过程是需求分析->计划->设计->编码->测试->运行维护
可以看到还是有一点区别的

软件测试的各个阶段具体内容如下
需求分析:
用户角度：软件需求是否合理
技术角度：技术上是否可行，是否还有优化空间
测试角度：是否存在业务逻辑错误、冗余、冲突等问题

测试计划:
制定测试计划：什么时候开发测试，什么时候结束测试,耗时多久

测试设计与开发:
参考需求文档、技术文档等编写测试用例,写测试文档，明确标注使用到的测试方法，测试⼯具，测试形式等等

测试执行:
充分利用测试用例和测试工具对项⽬尽可能做到全方面等的测试覆盖

测试评估:
测试是否通过，本次测试是否有遗留的BUG，最终测试⼈员需要产出⼀个测试报告

上线:
项目测试结束后，将项目发布到线上环境，测试人员需求跟踪上线并测试线上环境下软件的运⾏是否正确(因为线上和线下环境不一样,可能线下测试没问题,线上就出问题了,比如代码冲突,因为一个项目是有很多人一起完成的,每个人写的代码都有可能会发生冲突)

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

BUG

BUG概念

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

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

上面的话看起来很难理解简答的来说就是验证软件产品是否符合用户的需求,验证这个产品需要根据软件需求文档来验证

描述BUG的要素

在工作中对于BUG的描述是非常重要的,如果我们对于BUG的描述过于口语话这样会导致沟通成本增加
比如:对于一个界面的测试,界面中的一个按钮非常小,站在用户的角度上这个可以算作BUG的,但是站在开发这边来说功能都实现出来了,并且也可以正常使用,此时我们应该站在用户的角度去提交BUG,如果我们在提交BUG的时候只是简单的说界面按钮小,具体哪个按钮小为什么要改不说清楚的话会导致开发无法捕捉有效信息

描述bug的基本要素：问题出现的版本、问题出现的环境、问题出现的步骤、预期结果、实际结果

bug级别

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

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

这里谈一下我实习的一些事情,和这里的内容相关
我之前也帮助我的导师去测试功能,当功能有一些缺陷的时候就要提缺陷,也就是提bug,因为我是一个实习生,我的导师对我提的缺陷不是很放心,所以让我每次提的时候都要让他审核一遍,如果确实是bug那么就提交这个缺陷当时提交缺陷的时候对bug分类有几个程度,然后对功能测试也有几个选项,具体哪几个选项由于时间比较长了有点忘了,但是简答的说就是这个功能是否需要测试,和这个功能是否是bug...然后每次选择这当中的几个选项时都要填写理由,比如确认是bug了,那么就填写为什么是bug,这个bug体现在哪里
因为我是在海康威视这边实习,测试的是摄像头的功能,当时测试功能的时候测试用例有具体的测试过程和测试文档,我只需要跟着测试的操作过程一步一步测就完事了,但有一个问题就是这个摄像头是比较便宜的那种,功能比较少,有些功能有 有些功能没有,我的导师并没有告诉我要具体测哪些,而且有些功能确实是要有的,但是最后发现那块居然没有
这样就导致了我无法分辨哪些到底需要提交bug,哪些不需要提交bug,这里其实也是我导师的一些问题
后面说的就是我的一些问题了
我在测的时候因为每个bug提交都要给我导师审核通过才行,因为导师给了我提交bug的权限,所以我能直接提交,不需要他审核,我在提交bug的时候一开始还是勾选了让导师审核通过就提交,后面就搞忘了,其实也可以说是我一直以为我提交的bug都让导师审核了的,结果后面发现我并没有,导致我提交的bug直接让研发那边看到了后面就是一群人拉我进一个群问为什么提交这个bug,这个功能有什么问题,还有一些不认识的人私信问我这些bug的问题,当时人都懵了🤣🤣最后也就是发现我是个实习生,提交bug的时候没有安装流程走,所以就把我的大多数bug都退回了