前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >1 缺陷规范

1 缺陷规范

作者头像
互联网金融打杂
修改2023-02-06 01:04:20
6960
修改2023-02-06 01:04:20
举报
文章被收录于专栏:测试开发架构之路

想必大家都有这样被老板灵魂发问的经历吧。

  1. 当你负责的项目按时交付发布后,你老板问项目的测试质量怎么样啊?
  2. 当你测试的项目上线后有用户曝出使用缺陷,你老板问你这个缺陷怎么没有测试出来呢?

如果测试工程师将测试工作理解为测试用例设计、测试执行,那么你大概率回答不好老板的发问,给不到老板想要的答案。

测试工程师作为项目质量把关者, 是产品质量保障至关重要的一环,测试设计和执行只是其职责的一部分,殊不知,测试质量度量也是测试工作尤为重要的一环。测试质量度量的范围不仅限于测试角色,也包括开发角色,甚至是产品角色。因为产品质量不是测试同学测出来的,而是产研测三方共同努力“测试”的结果。

度量是一种工具,就像一把尺子,衡量项目测试质量的好坏,哪些地方做的好,哪些地方还需要改进。

下面就分享下测试工程师如何度量软件测试质量,我将其分为三个过程:

  1. 缺陷规范
  2. 缺陷管理
  3. 质量度量

1 缺陷规范

软件缺陷可以是编码中的缺陷,也可以是软件需求设计中的缺陷,最终都会导致软件程序运行不符合用户预期需求 的结果。有过测试经验的小伙伴,大都接触过比较流行的缺陷管理工具Jira,用于记录测试过程发现的缺陷。想要做好质量度量,就一定要有被度量的元数据(缺陷数据),而缺陷自身被给予的特征维度越多,则越能将度量工作做的更细致,也能度量出更多的结果。而缺陷规范,可以简单理解为给缺陷 贴不同维度标签(要素)。

1.1 缺陷要素

如上所述,理论上缺陷要素越多则度量的结果越精确,但通常会包含以下基本内容,如描述、发现缺陷的日期、发现缺陷的测试人员的名字、修复缺陷的开发人员的名字等。

  • 缺陷ID:唯一的缺陷ID,可以根据该ID追踪缺陷
  • 缺陷状态:一般情况下缺陷状态有:“打开/重新打开”、“待解决”、“不解决(拒绝)”、“已解决”、“已修复”、“延期修复”、“关闭”等。英文描述:Open/Reopen、un-solved、Won’t Fix、Resolved、Fixed、Deferred、Close。
  • 缺陷标题:描述缺陷的标题
  • 缺陷标签:用于缺陷归类
  • 缺陷的详细描述:对缺陷的详细描述,缺陷如何复现的步骤等等,之所以把这项单独列出来,是因为对缺陷描述的详细程度直接影响开发人员对缺陷的修改,描述应该尽可能详细。
  • 缺陷的严重程度:描述缺陷的严重程度,一般分为“致命(Critical)”、“严重(Major)”、“一般(Minior)”、“轻微(Trival)”和“建议修改(Suggestion)”等五种。
  • 缺陷的紧急程度:描述缺陷的紧急程度,用P0-4级来定义,4是优先级最低的等级,0级是优先级最高的等级。缺陷的紧急程度与严重程度虽然是不一样的,但两者密切相关,往往的越是严重,就越是紧急;但是也存在一些情况,虽然严重等级不高,但是需要紧急修复。
  • 缺陷提交人:缺陷提交人的名字
  • 缺陷所属项目/模块:缺陷所属的项目和模块,最好能较精确的定位至模块
  • 缺陷解决人:最终解决缺陷的人
  • 缺陷处理结果描述:对处理结果的描述,如果对代码进行了修改,要求在此处体现出修改
  • 必要的附件:对于某些文字很难表达清楚的缺陷,使用图片等附件是必要的。

2 缺陷管理

缺陷管理是一个缺陷从被发现到缺陷修复的系统过程,也叫缺陷生命周期管理。缺陷管理周期包含以下阶段:

1)发现缺陷

2)记录缺陷

3)修复缺陷

4)验证缺陷

5)Reopen/关闭缺陷

6)统计缺陷

2.1 发现缺陷

在发现阶段,项目团队必须在项目交付之前,尽可能多地发现缺陷。一个缺陷被发现且被开发认可,缺陷就变成可接受的状态,等待开发修复。

2.2 记录缺陷

发现缺陷则利用缺陷管理工作记录缺陷,缺陷描述务必详细,这样能降低开发“理解”/复现缺陷的成本。然后要对缺陷进行分类,例如缺陷严重程度分类有助于软件开发人员对其任务进行优先排序,开发人员优先修复那些非常严重的缺陷。

下面来做个小测验:

No

Description

Priority

Explanation

1

网站无法记住用户的登录会话

High

这是个严重的问题,因为用户可以登录,但无法执行任何进一步的交易。

2

网站的登录功能不能正常工作

Critical

登录是网站的核心功能之一,如果这个功能不能正常工作就是严重的缺陷。

3

网站的界面在移动设备上不能正确显示

Medium

影响到使用智能手机浏览网站的用户

4

网站页面上文字颜色不正确

Low

不影响功能使用,影响到体验

2.3 修复缺陷

修复缺陷过程开始于将缺陷提交给开发人员,然后开发人员根据优先级安排缺陷的修复,最后开发人员向测试同学同步修复结果。借助测试缺陷管理工具,例如Jira,可以管理缺陷的整个生命周期的活动,大大提升测试管理效率。

  • 指派开发人员。指派给开发人员或其他技术人员进行修复,并将缺陷状态改为响应。
  • 安排修复。他们将根据缺陷的优先级,创建一个修复这些缺陷的时间表。
  • 修复缺陷。在开发团队修复缺陷的同时,测试同学根据上述时间表跟踪缺陷的修复过程。
  • 同步修复结果。修复缺陷后,开发将缺陷状态设置成fixed。

2.4 验证缺陷

在开发团队修复并报告了缺陷后,测试团队会验证缺陷是否真的被修复了。

2.5 Reopen/关闭缺陷

一旦一个缺陷被解决和验证,该缺陷的状态就会被改变为关闭。如果没有,你要重新打开(reopen)缺陷,再次提交给开发修复。

2.6 统计缺陷

软件测试中的统计缺陷是将缺陷按照要素进行数据归类,用于缺陷度量。

3 质量度量

强调一点,缺陷度量不仅仅发生于测试结束后,而是伴随整个测试过程的。那么,测试质量度量指标有哪些呢?

汇总如下,可以看出软件测试度量范围不仅限于测试角色,还包括开发角色。

指标名称

定义

度量范围

测试执行率

(实际执行的测试用例数/测试用例总数)*100%

测试进度

测试通过率

(执行通过的测试用例数/测试用例总数)*100%

开发质量

需求(测试用例)覆盖率

(已设计测试用例的需求数/需求总数)*100%

测试设计质量

需求通过率

(已测试通过的需求数/需求总数)*100%

进度

测试用例命中率

(缺陷总数/测试用例数)*100%

测试用例质量

二次故障率

(Reopen的缺陷/缺陷总数)*100%

开发质量

NG率

(验证不通过的缺陷/缺陷总数)*100%

开发质量

缺陷有效率

(有效的缺陷/缺陷总数)*100%

测试

缺陷修复率

(已解决的缺陷/缺陷总数)*100%

开发

缺陷生存周期

缺陷从提交到关闭的平均时间

开发、测试

缺陷修复的平均时长

缺陷从提交到修复的平均时间

开发

缺陷关闭的平均时长

缺陷从修复到关闭的平均时间

测试

缺陷探测率

(测试发现的缺陷数/(测试发现的缺陷+客户发现的缺陷))*100%

测试质量

缺陷拒绝率

(缺陷拒绝修复数/缺陷总数)*100%

测试质量

缺陷逃逸率

(线上缺陷/(提交缺陷数量+线上缺陷))*100%

测试质量

以缺陷拒绝率为例,假如测试提出84个缺陷,开发测试双方认定其中20个不属于缺陷, 你可以计算出缺陷拒绝率是20/84=0.238(23.8 %)。通常来说,缺陷拒绝率值越小,测试的质量就越高。

我们通过上述指标可以窥探测试/开发在项目中存在的问题(效率问题、质量问题等),用于提出解决方案,并最终提升项目效率和质量。这时候你也许会问了,测试同学要掌握的技能好多啊,不仅要会测,还要知道如何管好”测“,更要会分析,整个项目都要参与进来协调产研同学啊,妥妥就一项目经理(PM),啥都要管哦。

HAHA,那可不是嘛,优秀的测试工程师就是优秀的PM啊。

本文参与 腾讯云自媒体同步曝光计划,分享自作者个人站点/博客。
原始发表:2022-07-24,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 1 缺陷规范
    • 1.1 缺陷要素
    • 2 缺陷管理
      • 2.1 发现缺陷
        • 2.2 记录缺陷
          • 2.3 修复缺陷
            • 2.4 验证缺陷
              • 2.5 Reopen/关闭缺陷
                • 2.6 统计缺陷
                • 3 质量度量
                相关产品与服务
                测试管理
                CODING 测试管理(CODING Test Management,CODING-TM)为您提供井然有序的测试协同管理工具服务,从测试用例库管理、制定测试计划,到协作完成测试任务,为测试团队提供敏捷测试工作方式,提高测试与研发团队的协同效率。提供可视化的工作视图以及数据报告,随时把控测试进度和规划。
                领券
                问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档