单元测试发现是问题不是缺陷

简介: 单元测试发现是问题不是缺陷

近几天被单元测试发现的问题是不是缺陷给困扰了,我一直在想单元测试发现的问题为什么不记录到缺陷管理系统?记录的缺陷管理系统有什么用,会有什么影响?为什么要记录缺陷,到底什么是软件缺陷?

缺陷

《宋史·李沆传》:“身食厚禄,时有横赐,计囊装亦可以治第。但念内典以此世界为缺陷,安得安满如意,自求称足?”


缺陷,汉语词汇,拼音是quē xiàn,本意指欠缺;缺失;不完美。  在晶体学、质检等不同领域又有着不同的含义。出自《宋史·李沆传》。


这么看来,缺陷就是一个不好的点,在软件交付过程中的任何部分,只要是不完美,都可以称之为缺陷,业务不完美、需求缺失、开发设计欠缺,测试不完美、运维欠缺等等,如果依据这个定义,那么缺陷就是一个贯穿全部软件交付生命周期的概念了。 但是,在IT行业,软件缺陷却不是这样定义,在下面是三个队软件缺陷的定义:

  • 维基百科中的定义如下:软件缺陷是计算机程序或系统中的错误、缺陷或故障,导致其产生不正确或意外的结果,或以意外的方式运行。(这里软件缺陷还是成为BUG)
  • 百度百科中的定义如下:软件缺陷(Defect),常常又被叫做Bug。 所谓软件缺陷,即为计算机软件或程序中存在的某种破坏正常运行能力的问题、错误,或者隐藏的功能缺陷。缺陷的存在会导致软件产品在某种程度上不能满足用户的需要。
  • IEEE729-1983对缺陷有一个标准的定义:从产品内部看,缺陷是软件产品开发或维护过程中存在的错误、毛病等各种问题;从产品外部看,缺陷是系统所需要实现的某种功能的失效或违背。


从上面三部分的定义可以看出,软件缺陷都是响运行后影响某些正常或者预设行为的情况,在从开发阶段开始就有可能引入了缺陷。

为什么要缺陷管理


image.png


从上面的定义我们可以看出,大部分的软件缺陷的约束都是在运行态之下的定义了。那么再反过来讨论一下,单元测试发现的问题要不要记录到缺陷系统里,要讨论这个问题我们就看一下我们为什么要统记录缺陷、管理缺陷呢?


  • 百度百科:缺陷管理是在软件生命周期中识别、管理、沟通任何缺陷的过程(从缺陷的识别到缺陷的解决关闭),确保缺陷被跟踪管理而不丢失。一般的,需要跟踪管理工具来帮助进行缺陷全流程管理。


说白了,就是在发现缺陷后,要记录缺陷的是怎么产生的、是怎么修复的以及确认是不是这的没有了。那么这里就会涉及到好几个人,有开发工程师、测试工程师、产品经理甚至有时候还有运维工程师,每个人做了上面这个缺陷生命周期的不同部分的工作,因此我们需要管理缺陷,确定每一个缺陷都经由缺陷生命周期的全流程,最后验证通过而关闭。


上面是一个中典型的缺陷处理流程,有缺陷发现人员提交缺陷,并分配给有能力修复这个缺陷的人,然后有对应人员确定是不是一个缺陷,如果不是就拒绝,这样缺陷就关闭了。如果是一个缺陷就来确定是不是可以修复,可以修复就修复完后将缺陷设置已修复状态,有缺陷发现人员再次验证没有问题后关闭该缺陷,至此一个缺陷的生命周期就结束了。这个流程往往要经过前面说的多个角色的多个人。这么多人如果坐在一起,靠口口相传也是可以的,但是后来发现这些角色之间往往是多对多的关系,因此必须有一种工具记录着缺陷的流转状态,这就是缺陷管理系统的出现,当然有些人非要用电子表格我也不能说不对。


有了缺陷管理系统我们就可以衡量很多和缺陷相关的指标,例如缺陷修复时长,千行BUG率(虽然被很多人唾弃)等等。


单元测试部分的问题要不要记录缺陷管理系统

上面我们说了为什么要管理缺陷和为什么有缺陷管理系统。那么下面我们再看看开发的工作过程,开发在写代码的时候会不断的调试,那么开发的工作产出包含两类代码,一类是实现业务的代码,一类是单元测试,那么单元测试的开发也是在不断的调试中完善的。按照正常做法开发工程师本地调试成功、单元测试测试通过,就可以push 代码到代码仓库的feature分支了,因此如果本地单元测试是fail,开发会继续调试单元测试代码然后去修改这种情况并不能算是软件缺陷,只能算是开发调试。

image.png


如果合并feature分支到开发主干的时候单元测试失败了,那么持续集成流水线就失效了,开发会讲对应的问题修改掉然后在继续持续集成,这个时候还是处于开发调试阶段,被测系统还没有运行,因此也不是软件缺陷。但是这个时候我们绝大部分会衡量流水线恢复的时间来作为研发效能的一个度量指标。只有走完持续集成后进入持续交付、持续部署的过程中发现的问题才叫缺陷,部署后有损失(这里的损失很多公司是以资损衡量的,但是这却不是唯一的划分方法,具体还应该以系统影响的根本考核点为准)一般称为故障。


换个角度,如果我们将单元测试问题也算缺陷,那么开发从发现到修复时间会很短,这样也为我们度量团队研发效能的缺陷修复时长指标带来很多的噪音。


因此无论从合理使用还是从合理度量的角度,绝大部分情况不把单元测试的问题叫做缺陷,因为也就没有必要记录的缺陷管理系统了。但是这并不是一概而论的,如果有自己的度量的需求或者其他的需求,也是可以通过自动化手段将单元测试发现的问题自动的提交到缺陷管理系统的。


目录
相关文章
|
7月前
|
监控 测试技术
当测试发现300个缺陷时
当测试发现300个缺陷时
54 0
|
2月前
|
机器学习/深度学习 测试技术
ACL杰出论文奖:GPT-4V暴露致命缺陷?JHU等发布首个多模态ToM 测试集,全面提升大模型心智能力
【10月更文挑战第6天】约翰斯·霍普金斯大学等机构提出了一项荣获ACL杰出论文奖的研究,旨在解决大模型在心智理论(ToM)上的不足。他们发布了首个MMToM-QA多模态ToM测试集,并提出BIP-ALM方法,从多模态数据中提取统一表示,结合语言模型进行贝叶斯逆规划,显著提升了模型的ToM能力。这一成果为机器与人类自然交互提供了新思路,尽管仍面临一些局限性和技术挑战。论文详情见:https://arxiv.org/abs/2401.08743。
52 6
|
7月前
|
机器学习/深度学习 数据采集 人工智能
【专栏】AI在软件测试中的应用,如自动执行测试用例、识别缺陷和优化测试设计
【4月更文挑战第27天】本文探讨了AI在软件测试中的应用,如自动执行测试用例、识别缺陷和优化测试设计。AI辅助工具利用机器学习、自然语言处理和图像识别提高效率,但面临数据质量、模型解释性、维护更新及安全性挑战。未来,AI将更注重用户体验,提升透明度,并在保护隐私的同时,通过联邦学习等技术共享知识。AI在软件测试领域的前景广阔,但需解决现有挑战。
1027 6
|
3月前
|
机器学习/深度学习 人工智能 安全
软件测试中的探索性测试:一种高效发现软件缺陷的方法
本文将深入探讨软件测试中的一种关键方法——探索性测试。探索性测试是一种动态的、探索性的软件测试方法,它依赖于测试人员的直觉和经验,通过实际操作软件来发现潜在的问题和缺陷。与传统的基于预定义用例的测试方法相比,探索性测试更加灵活,能够更全面地覆盖软件的各个方面,从而更有效地发现难以预见的错误和漏洞。
43 2
|
4月前
|
监控 测试技术
软件测试中的风险管理:如何避免潜在缺陷
【8月更文挑战第5天】在软件开发的生命周期中,测试阶段扮演着至关重要的角色。本文将深入探讨软件测试中的风险管理,包括风险识别、评估和缓解策略。我们将通过具体案例分析,揭示如何在早期阶段预防和减少潜在的软件缺陷,以及如何通过有效的测试计划和执行来保障产品质量。文章旨在为读者提供一套系统的风险管理框架,帮助他们在软件开发过程中识别和应对各种测试风险。
210 3
|
7月前
|
前端开发 测试技术 数据安全/隐私保护
软件测试 —— 案例系统缺陷报告
软件测试 —— 案例系统缺陷报告
|
7月前
|
缓存 C语言 C++
【项目日记(九)】项目整体测试,优化以及缺陷分析
【项目日记(九)】项目整体测试,优化以及缺陷分析
|
7月前
|
测试技术
有了测试标准流程后缺陷就不会遗漏到线上吗?
有了测试标准流程后缺陷就不会遗漏到线上吗?
|
7月前
|
测试技术
『测试基础』| 如何理解测试用例管理和缺陷管理?
『测试基础』| 如何理解测试用例管理和缺陷管理?
222 1
|
监控 测试技术
测试思想-流程规范 软件测试缺陷管理流程
测试思想-流程规范 软件测试缺陷管理流程
186 0

热门文章

最新文章