新手区 移动端测试入门系列:测试基础理论 (二) 之 缺陷 (BUG)[第四期]

Jwong · 2020年06月01日 · 442 次阅读

做测试的小伙伴,缺陷相关的知识是必备的。如下内容通过搜集和筛选(感谢原作者),你必须要掌握,方可迈入测试行列。

软件缺陷定义(BUG)
软件没有实现产品的说明书所描述的功能。
软件实现了产品说明书描述不应有的功能。
软件执行了产品说明书没讲的操作。
软件没有实现产品说明书没描述但应该实现的功能(用户体验相关)。
从软件测试员的角度来看,软件难以理解、不易使用、运行缓慢,或者最终用户认为不对。

常用的缺陷追踪系统
JIRA
Readmine
Bugzilla
禅道 (bugfree 升级版)
mantis

缺陷处理流程(简易版)

提交缺陷一般的必填项
标题:
应保持简短、准确、提供缺陷的本质信息。
尽量以缺陷发生的原因与结果的方式相结合的方式书写;
尽量避免使用模糊不清的词语,例如:“功能中断”、“功能不正确”、“行为不起作用” 等,应该使用具体文字说明缺陷的症状;
为了便于他人理解,尽量避免使用俚语或过分具体的测试细节;

复现步骤:
应该包含如何使用别人很容易理解缺陷的复现步骤。
为了达到这个要求,书写的测试步骤应当是完整的、简洁的、准确的、可复现的;
尽量避免包含过多冗余步骤,且句子结构混淆、可读性差、难以理解;包含的操作步骤过少,缺少必要的复现步骤;

期望结果:
描述应与实际结果的描述方式相同,通常列出产品达到什么样的功能或效果。
附件:对缺陷的补充说明,例如缺陷的截图、测试使用的数据等。

缺陷严重程度

缺陷优先级

缺陷状态

很多测试的小伙伴刚开始会把严重程度和优先级搞混。一般来说,如下的搭配不会有什么大问题:致命缺陷对应紧急,严重缺陷对应优先级高,一般缺陷对应一般优先级,轻微和建议对应低优先级。但是我们也需要知道,这些并不是固定搭配,主要还是看这个缺陷对当前上线版本的影响范围。举个栗子:某个子功能点击后会导致崩溃,这算是致命问题,但是通过线上监控显示,该功能对于用户来说使用率极低,或者使用的交互路径很深,换句话说缺陷触发的情况很低,所以某种程度上来说它并不算是一个紧急优先级,不需要立刻发版解决,可以等到下个迭代版本再修复。我们可以把缺陷定为高优先级。

下面以常用的 jira 系统为例,看一条缺陷包括那些字段信息:

下一期预告(每周一更):
移动端基础知识(Android)

暂无回复。
需要 登录 后方可回复, 如果你还没有账号请点击这里 注册