功能测试】bug一般都是因为什么原因导致的

2021-03-17 10:43发布

4条回答
aijingda
2楼 · 2021-03-17 10:49

第一,程序员是人,人一定会犯错,因为总有精神不集中的情况,所以人犯错程序就会出BUG,静态检查永远无法发现所有的低级错误,覆盖测试也仍然不够。

第二,对代码进行review和test可以有效消除bug,但这两种手段的有效性随逻辑复杂度升高而下降。

因此,软件工程的主要目标一直都是控制复杂度。程序员水平的一个重要表征就是可以控制住每一段代码的复杂度,保证代码可读性和非耦合性,从而保证即便在精神不够集中的情况下也不会产生太多的bug。也有一些程序员在精神高度集中的情况下可以将很复杂的逻辑一遍写对,这是一种很有益的技巧,但在可能的情况下,我还是更推崇将问题拆分降低复杂度的方法。

花轮同学
3楼 · 2021-03-17 11:03

1:逻辑不清晰,功能频繁修改

2:功能在设计之初出现缺陷

3:技术人员出错

是开心果呀 - 热爱生活
4楼 · 2021-03-17 12:47

1. 需求表述、理解、编写引起的错误。

2. 系统设计架构引起的错误。

3. 开发过程缺乏有效的沟通及监督,甚至没有沟通或监督。

4. 程序员编程中产生的错误。

5. 软件开发工具本身隐藏的问题。

6. 软件复杂度越来越高。

7. 与用户需求不符,即使软件实现本身无缺陷。

8. 外界应用环境或电磁辐射导致的缺陷。


征戰撩四汸
5楼 · 2021-10-13 14:35
1. 特殊的测试数据

有经验的测试人员在进行测试的时候并不会按部就班的按照case来测,假如case的粒度很粗的 话更会如此,有时候突发奇想的填了一个数据进去,结果程序报错了,等回过神来再试图去重 现的时候发现case里准备的数据都不能触发那个bug了,这时候就应该努力去回想当时用的是 什么数据(当然很多时候确实很难记起来)。

2. 环境不稳定

在实际的实际的工作中,开发环境、测试环境、生产环境、UAT环境都是分开来的,所以不同 的环境下同一个数据的实际结果也有可能不同,导致测试环境下发现的bug在开发在开发环境 验证的时候无法重现,这时候有可能是开发已经deploy了最新的代码,但是测试环境没有得 到及时更新;还有另一种情况,就是环境的不稳定,这种问题在项目初期尤为明显,刚搭完的 环境总是有很多难以重现的莫名其妙的bug,这种情况可能是由于环境的配置、软件的配置或 者接口不稳定造成的。

3. 操作顺序不当

如果页面上的操作没有严格的先后顺序,测试员在测试的时候有可能第一遍是12354,发现了 bug,当准备回头去验证的时候发现重现不了了,因为用例里写的顺序是12345而测的12354只 是心血来潮,bug的触发需要特定的条件和特定的操作顺序,刚好12354能够满足触发条件而 12345却能运行正常。

4. 没有找到触发关键步骤

特定的bug只会在经过特定的操作之后才会出现,而当测试员不经意的做出某操作而试图重现 的时候又忽略那个关键操作的时候,那也很难重现。

5. 内存泄漏或锁

有一些系统只有经过长时间运行才会暴露出bug,这个问题也很难重现。需要经过长时间的测 试才能确认以及特殊情况下数据锁的问题,导致的一些bug都很难重现。

6. 测试人员的错误操作

测试人员在测的时候忘记了执行某一操作,导致出现的结果跟预期不匹配,等再回头按照case 跑的时候发现无法重现而导致误报。


相关问题推荐

  • 回答 6

    、 黑盒测试:是一种常用的软件测试方法,它将被测软件看作一个打不开的黑盒,主要根据功能需求设计测试用例,进行测试。几种常用的黑盒测试方法和黑盒测试工具有,等价类划分法、边界值分析法、因果图法、决策表法。在实际运用中要选择合适的方法。二、 因果...

  • 回答 4

    果图法是一种适合于描述对于多种输入条件组合的测试方法,根据输入条件的组合、约束关系和输出条件的因果关系,分析输入条件的各种组合情况,从而设计测试用例的方法,它适合于检查程序输入条件涉及的各种组合情况。因果图法一般和判定表结合使用,通过映射同...

  • 回答 5

    判定表(Decision Table)是分析和表达多逻辑条件下执行不同操作的情况下的工具.在程序设计发展的初期,判定表就已被当作编写程序的辅助工具了.由于它可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确....

  • 回答 5

    判定表通常有以下四个部分组成:1)条件桩(Condition Stub):列出了问题的所有条件。通常认为列出的条件的次序无关紧要。2)动作桩(Action Stub):列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。3)条件项(Condition Entry):列出针对它左列...

  • 回答 3

    长期的测试工作经验告诉我们,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例,可以查出更多的错误。使用边界值分析方法设计测试用例,首先应确定边界情况。通常输入和输出等价类的边界,就是...

  • 回答 2

    1) 边界值分析不是从某等价类中随便挑一个作为代表,而是使这个等价类的每个边界都要作为测试条件。2) 边界值分析不仅考虑输入条件,还要考虑输出空间产生的测试情况。

  • 回答 4

    边界值分析方法是对等价类划分方法的补充. 长期的测试工作经验告诉我们,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.使用边界值分析方法设计测试用例...

  • 回答 7
    已采纳

    在编程中,布尔量指一个真或假状态。通常它们分别用0,1或1,-1来表示,这和编程语言有关。具体来说当布尔量为真的时候表示一个表达式或判断成立,否则这个式子或判断不成立。你把它理解为成立或不成立就行了。...

  • 回答 1

    1)输入条件规定取值范围,则卡定义一个有效等价类和两个无效等价类。例如学生成绩范围是0~100,则一个有效类:0

  • 回答 6

    1,先确定等价类别2,找出有效等价类和无效等价类3,边界值找好,尽可能多的找的会有重复的数据4,有效等价类尽可能条件符合的归一起不要重复5,无效等价类单独写开6,写好测试用例7,执行测试用例...

  • 回答 4

    应用场景:只要有数据输入的地方就可以采用等价类划分法。按照需求,把无穷多的数据进行分类,从中挑选出代表性数据进行测试。具体操作:(1)明确测试对象(测试什么)(2)划分等价类(按照需求分有效、无效)(3)细化等价类(有效、无效进行细化)(4)建...

  • 回答 10

       采用黑盒技术设计测试用例的方法有:等价类划分、边界值分析、错误推测、因果图和综合策略。

  • 回答 7

    Priority()和Severity(严重程度)是的两个重要属性。很多新人经常混淆这两个概念。通常,人员在提交Bug时,只定义Bug的Severity, 即该Bug的严重程度,而将Priority交给Project Leader 或Team Leader来定义,由他们来决定该Bug被修复的优先等级。某种意义上来说...

  • 回答 5

    1致命:致命是指系统主要功能丧失,用户数据受到破坏,造成系统崩溃、悬挂、死机或者危及人身安全等的问题。例如程序所引起的死机,非法退出、死循环、数据库发生死锁、数据流环节上严重的数值计算错误、产品设计存在严重的安全问题、漏洞被利用后可能导致系统...

  • 回答 3
    已采纳

    1、New:(新的)当某个bug被发现的时候(第一次),测试人员需要与项目负责人沟通以确认发现的的确是一个bug,如果被确认是一个bug,就将其记录下来,并将bug的状态设为New。2、Assigned(已指派的)当一个bug被指认为New之后,将其将给开发人员,开发人员将...

  • 回答 2

    软件缺陷是计算机软件或程序中存在的某种破坏正常运行能力的问题、错误,或者隐藏的功能缺陷。缺陷的存在会导致软件产品在某种程度上不能满足用户的需要。IEEE729-1983对缺陷有一个标准的定义:从产品内部看,缺陷是软件产品开发或维护过程中存在的错误、毛病等...

没有解决我的问题,去提问