深圳软件测试培训
达内深圳龙华中心

139-2227-5185

热门课程

达内专家:Bug的详细分解

  • 时间:2016-06-07
  • 发布:达内
  • 来源:达内

本文主要针对Bug进行详细的讲解,包括Bug如何诞生的?Bug的创造者是谁?优化消灭Bug的进程等等,希望能对你有所帮助!
1.Bug的前世

在第一篇里,我们谈到了强大的Bug大军。那他们是如何诞生的呢?又是谁创造了Bug呢?一般人都会认为肯定是程序猿。我想说的是你只答对了一部分。而且真的只是冰山一角。

有句话说,解铃还须系铃人。谁有本事解铃,那他们也一定是系铃的人。上一篇中,我们谈到所有参与消灭Bug军团的兵种都是Bug的创造者,你一定会很吃惊,产品经理、测试、系统工程师他们也是Bug的创造者。因为是人总会犯错的,从来都没有完美的人。

(1)问题的复杂度决定了出现Bug的可能性高低

一个系统复杂度的标准:

◆   业务需求比较多,行业的专业性强;

◆   需求经常在不断地变化;

◆   不停地询问-回答-询问的过程的头脑风暴;

◆   方法的复杂度、工具的复杂性、人的复杂性、过程的复杂性。

(2)现实很残酷,更便宜、更好、更快、市场时间等词语加注到项目开发过程中时,会忘记其中的一些环节,bug由此产生。

◆   时间:在时间充裕的条件下,编写同样功能的程序会产生相对较少的Bug。然而,现实往往是残酷的,在相对较短的时间里产出高质量的产品的过程中,必然会出现一些不可避免的缺陷,这时就是一个控制的问题。

◆   钱:可以说是公司的收益。当花费长时间去编写低Bug率的代码时,必需要增加成本的基数。任何公司和个人都不会做赔本的生意,所以在时间和金钱上,Bug率总是不断地斗争着,如何才能调整好两者间的关系是至关重要的。

◆   持续变化的过程:由于很多不定性因素,如客户需求的变更、系统环境的变化(XP/VISTA/WIN7)、团队人员的变化等,这些都是考虑的问题,对于系统的缺陷影响有时就在不能完全理解式样和需求以及变化的环境中产生的。

◆   缺少相关经验:当我们对一件事情不太熟悉的时候,出现迷糊的情况是比较多的,所以会产生与环境和技术相对应的反应,由此产生的一些Bug也是在所难免的,只有不断地积累经验,当碰到一件事情的时候可以对照起来应用,效果就更佳!

(3)人性的弱点

是人都会犯错误的。我们常常会犯一些很低级的错误,这个时候,我们需要正视自己的错误,然后勇于改正错误。


2.Bug的创造者

(1)再提Bug的分类

上一篇,我们提到了Bug军团的兵种类型组成:代码错误类型、界面优化类型、设计缺陷类型、配置相关类型、安装部署类型、性能问题类型、标准规范类型、测试脚本类型。这些不同类型的Bug对应于他们不同的创造者们。

(2)Bug的创造者们

◆   产品设计师:创造出天然有设计缺陷的Bug,这种Bug破坏力很强,比如:设计的框架都有问题,最后只有重新再来,是极具毁灭性的。

◆   需求分析师:对需求分析不清晰,导致后来程序猿大喊大叫:“这里要怎么做,不知道”。

◆   系统工程师:搭建了错误的环境,出现了一批僵尸Bug,导致很多无用功的出现。

◆   交互工程师:设计出荒唐的交互操作,直接跑到交互的死循环里,而无法自拔。

◆   前端开发工程师:这个很直观,界面上一览无余,不符合行业用户的习惯或视觉体验。

◆   后台开发工程师:就是我们通常所说的逻辑代码的错误或者脚本错误。

◆   DBA:通常是写错了数据库的脚本,比如:写错了某个视图。

◆   测试工程师:你一定会很吃惊,测试不是找Bug的吗?是的,他们也会提一些错误的Bug导致系统出现更多的问题。此外还有开发的测试脚本的问题。

◆   配置工程师:这个也很牛,只要她配置错了某个版本,你看Bug是不是会死灰复燃。


3.Bug是这样产生的

(1)对软件的修改

在修改软件的过程中可能会产生自客户需求的变更以及维护阶段对式样理解的不透彻,这些环节都会有意无意地产生出Bug,造成软件整体水平的下降。

主要表现在以下几点:

◆   理解力不足。在对问题理解力不够的条件下很难正确地修改软件。

◆   视野狭隘。不同的开发人员修改的视野不一样,是站在全局的角度进行修改,还是只是站在本模块的角度进行修改。

◆   特征蠕变

(2)拙劣的描述

一个不正确的描述会导致不正确的实现,从而导致Bug。

(3)缺少一致的观点

产品人员和开发人员的分歧、开发人员之间对同一个问题不同的解决方案的分歧。

(4)程序员错误
缺乏对工具的理解、使用不恰当的工具、懒惰。为了追求方便,选择了不适合的工具,结果导致了大量的问题。


4.Bug是这样躲过测试的

(1)遵循形式过程代价太大

由于检查、审查和测试占据很多的时间、精力和费用,所以付出的成本代价比较大。

(2)时间不充分

如前所述,测试要花时间、QA要花时间,当日程表改过后,留给测试和QA的时间相当少,所以也就是这个时候,Bug出现的机率开始提高。记得,软件在时间不充裕的时候就会出现Bug。

(3)测试人员缺少重现能力

有时候当测试人员发现错误后,很难再次重现该Bug。当然Bug的可重现性有很多原因,如没有正当地或正确地记录和跟踪Bug出现的环境和状况,没有适当的配置和环境来重现等都是Bug逃避的手段。

(4)程序猿的自负

作为一个程序员都对自己的程序非常自信,认为没有错误、认为特完美,殊不知错误就发生在你认为非常完美的地方。可以这样说,人无法面对自己的缺点就像开发出软件时无法面对自己的Bug一样,所以这也是Bug为什么能够继续猖獗的原因之一。

(5)差劲的描述/不知道该测什么

当我们失去目标时,我们的前途开始渺茫,我们不知道自己的生活重心是什么,就像我们面对软件时不知道如何下手测试其正确性一样。发现Bug如何更好地描述,如何更好地重现Bug以为开发人员找到突破口是关键。所以详细地记录Bug发生的环境和条件至关重要。

(6)缺乏测试环境

好的测试环境有三个特征:有良好工具的测试人员,在一台与客户系统有相同的系统配置的计算机的软件上,用户的使用被理解并且被良好的建模。只有这三点都满足时,才能更好地测试出Bug,并且记录。

除此之外,还有市场、政策等其他原因。通过对Bug生命周期这章的学习,了解到Bug产生的原因以及Bug为什么没有在测试中被发现的种种原因。只有了解如何产生我们才能更好地面对它、解决它。


5.怎样优化消灭Bug的进程

软件测试改进过程:

◆   测试的目的就是发现尚未被发现的错误。

◆   一个优秀的测试人员应该持有的基本态度是集中精力揭露错误。

◆   态度:我就是要破坏掉这个东西,我知道有错而且要找出错误,这就是我的工作。

◆   测试的过程是发现错误的环节,是个对事不对人的环节。所以,处理好开发者和测试者之间的关系也很重要,毕竟是战友啊!

◆   测试人员工作内容:检查内部结构和设计、检查功能型的用户界面、检查设计目的、检查用户需求、运行代码……

◆   测试是一个在软件生存周期中始终存在的一个过程,测试过程中越早发现错误对于公司与软件来说都是有益的!

◆   风险评估是软件开发过程中所必须的。

◆   测试框架:计划—— 我们想做什么、我们打算怎么做、要花多长时间、需要的资源、成本….

◆   测试必须独立进行,这样才能真正有效地对软件质量进行度量。

上一篇:达内专家:软件测试功能图的分析方法详解
下一篇:【达内职场秀】人和人之间的差距怎么就那么大

【达内软件测试教程】软件测试新手的修炼之路

【达内软件测试教程】你是否也对软件测试存在误区?

【达内软件测试教程】影响软件测试质量的元凶是什么?

【达内软件测试教程】嵌入式软件测试基础知识

选择城市和中心
贵州省

广西省

海南省