如何度量软件测试质量?

发表于:2023-5-29 09:57

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:QualityAssurance21    来源:博客园

  想必大家都有这样被老板灵魂发问的经历吧。
  1. 当你负责的项目按时交付发布后,你老板问项目的测试质量怎么样啊?
  2. 当你测试的项目上线后有用户曝出使用缺陷,你老板问你这个缺陷怎么没有测试出来呢?
  如果测试工程师将测试工作理解为测试用例设计、测试执行,那么你大概率回答不好老板的发问,给不到老板想要的答案。
  测试工程师作为项目质量把关者, 是产品质量保障至关重要的一环,测试设计和执行只是其职责的一部分,殊不知,测试质量度量也是测试工作尤为重要的一环。测试质量度量的范围不仅限于测试角色,也包括开发角色,甚至是产品角色。因为产品质量不是测试同学测出来的,而是产研测三方共同努力“测试”的结果。
  度量是一种工具,就像一把尺子,衡量项目测试质量的好坏,哪些地方做的好,哪些地方还需要改进。
  下面就分享下测试工程师如何度量软件测试质量,我将其分为三个过程:
  ·缺陷规范
  · 缺陷管理
  · 质量度量
  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 记录缺陷
  发现缺陷则利用缺陷管理工作记录缺陷,缺陷描述务必详细,这样能降低开发“理解”/复现缺陷的成本。然后要对缺陷进行分类,例如缺陷严重程度分类有助于软件开发人员对其任务进行优先排序,开发人员优先修复那些非常严重的缺陷。
  下面来做个小测验:
  2.3 修复缺陷
  修复缺陷过程开始于将缺陷提交给开发人员,然后开发人员根据优先级安排缺陷的修复,最后开发人员向测试同学同步修复结果。借助测试缺陷管理工具,例如Jira,可以管理缺陷的整个生命周期的活动,大大提升测试管理效率。
  ·指派开发人员。指派给开发人员或其他技术人员进行修复,并将缺陷状态改为响应。
  · 安排修复。他们将根据缺陷的优先级,创建一个修复这些缺陷的时间表。
  · 修复缺陷。在开发团队修复缺陷的同时,测试同学根据上述时间表跟踪缺陷的修复过程。
  · 同步修复结果。修复缺陷后,开发将缺陷状态设置成fixed。
  2.4 验证缺陷
  在开发团队修复并报告了缺陷后,测试团队会验证缺陷是否真的被修复了。
  2.5 Reopen/关闭缺陷
  一旦一个缺陷被解决和验证,该缺陷的状态就会被改变为关闭。如果没有,你要重新打开(reopen)缺陷,再次提交给开发修复。
  2.6 统计缺陷
  软件测试中的统计缺陷是将缺陷按照要素进行数据归类,用于缺陷度量。
  3 质量度量
  强调一点,缺陷度量不仅仅发生于测试结束后,而是伴随整个测试过程的。那么,测试质量度量指标有哪些呢?
  汇总如下,可以看出软件测试度量范围不仅限于测试角色,还包括开发角色。
  以缺陷拒绝率为例,假如测试提出84个缺陷,开发测试双方认定其中20个不属于缺陷, 你可以计算出缺陷拒绝率是20/84=0.238(23.8 %)。通常来说,缺陷拒绝率值越小,测试的质量就越高。
  本文内容不用于商业目的,如涉及知识产权问题,请权利人联系51Testing小编(021-64471599-8017),我们将立即处理
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号