。

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

BUG

定义一个计算机bug指在计算机程序中存在的一个错误、缺陷、疏忽或者故障这些bug使程序无法正确的运行。

Bug产生于程序的源代码或者程序设计阶段的疏忽或者错误。

准确说

当且仅当规格说明(需求文档)是存在的并且正确程序与规格说明之间的不匹配才是错误。

当需求规格说明书没有提到的功能判断标准以最终用户为准当程序没有实现其最终用户合理预期的功能要求时就是软件错误

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

在工作中对于BUG的描述是非常重要的,如果我们对于BUG的描述过于口语话这样会导致沟通成本增加

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

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

bug级别

通过定义bug的级别能够明确看出问题的严重程度。

工作中开发人员通常需要按照bug的级别来分配

优先级来处理bug除此之外通过bug级别也能够体现出开发人员的开发质量

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

测试人员在执行测试的过程中如有发现bug需要在对应的bug管理平台来创建bugbug生命起

源创建好的bug需要被开发人员修复以及测试人员的持续跟踪和测试。

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

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

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

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

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

无效的bugopen-closed-open-rejected-closed

我之前也帮助我的导师去测试功能,当功能有一些缺陷的时候就要提缺陷,也就是提bug,因为我是一个实习生,我的导师对我提的缺陷不是很放心,所以让我每次提的时候都要让他审核一遍,如果确实是bug那么就提交这个缺陷当时提交缺陷的时候对bug分类有几个程度,然后对功能测试也有几个选项,具体哪几个选项由于时间比较长了有点忘了,但是简答的说就是这个功能是否需要测试,和这个功能是否是bug...然后每次选择这当中的几个选项时都要填写理由,比如确认是bug了,那么就填写为什么是bug,这个bug体现在哪里

因为我是在海康威视这边实习,测试的是摄像头的功能,当时测试功能的时候测试用例有具体的测试过程和测试文档,我只需要跟着测试的操作过程一步一步测就完事了,但有一个问题就是这个摄像头是比较便宜的那种,功能比较少,有些功能有

有些功能没有,我的导师并没有告诉我要具体测哪些,而且有些功能确实是要有的,但是最后发现那块居然没有

这样就导致了我无法分辨哪些到底需要提交bug,哪些不需要提交bug,这里其实也是我导师的一些问题

我在测的时候因为每个bug提交都要给我导师审核通过才行,因为导师给了我提交bug的权限,所以我能直接提交,不需要他审核,我在提交bug的时候一开始还是勾选了让导师审核通过就提交,后面就搞忘了,其实也可以说是我一直以为我提交的bug都让导师审核了的,结果后面发现我并没有,导致我提交的bug直接让研发那边看到了后面就是一群人拉我进一个群问为什么提交这个bug,这个功能有什么问题,还有一些不认识的人私信问我这些bug的问题,当时人都懵了最后也就是发现我是个实习生,提交bug的时候没有安装流程走,所以就把我的大多数bug都退回了