bug_bugkucrypto - CSDN
精华内容
参与话题
  • 常见BUG整理

    2018-12-30 09:34:42
    1.访问数据库相关 Err: can not convert from java.sql.Statement to java.beans.Statement  import错误的包 java.sql.Statement这个是和数据连接有关 java.beans.Statement是javabean包123456 ...

    1.访问数据库相关

    Err:
    can not convert from java.sql.Statement to java.beans.Statement 

    import错误的包
    java.sql.Statement这个是和数据连接有关
    java.beans.Statement是javabean包123456

    Err:
    com.microsoft.sqlserver.jdbc.SQLServerException: 只进结果集不支持请求的操作。

    //数据指针只能向后移动,且可更改数据
    stmt = connection.createStatement(ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_UPDATABLE);

    将 ResultSet.TYPE_FORWARD_ONLY修改为 ResultSet.TYPE_SCROLL_SENSITIVE1234567

    FQ:
    Class.forName("com.microsoft.sqlserver.jdbc.SQLServerDriver");
    不加载JDBC驱动一样能连接数据库

    JDBC4.0 是不用显式的去加载驱动,如果驱动包符合 SPI 模式就会自动加载
    2.

    访问数据库相关

    Err:
    String dbURL = "jdbc:sqlserver://localhost:1433/STUDENT;";
    com.microsoft.sqlserver.jdbc.SQLServerException: 端口号 1433/STUDENT 无效。

    Java连接 MySQL和SQL Server不同
    String sqlServerURL = "jdbc:sqlserver://localhost:1433;dataBaseName=STUDENT;";

    String MySqlURL = "jdbc:mysql://localhost:3306/STUDENT";

    3.

    泛类型

    class Test2 <T> {
        static void printList(List<? extends T> c) {
            for(T item : c) {
                System.out.println(item);
            }
        }
    }
    Err:Cannot make a static reference to the non-static type T

    <T>表示是个泛型方法,传入参数有泛型
    static <T> void printList(List<? extends T> c) {
           ...
    }
    4.

     CMD运行java

    错误:找不到或无法加载主类
    命令格式:
    java -cp ../../ com.Section_23.Server

    ../../ 返回包所在位置(相对路径) 或者使用绝对路径
    com.Section_23.Server 包名+类名

    //javac A.java B.java
    5.1.ext日历控件的问题
    this.render为空  this.render(this.el.dom.parentNode)
    dom节点未加载尚不可用,需要将js放置其后
    5.2.jsp中将this对象传入js中
    <input style="width:60px" name="qtyPerPK" value="" οnblur="autoGenValueOfnumOfPKS($(this))"/>
    function autoGenValueOfnumOfPKS(r) {
        alert(r.val());
    }
    5.3.关于innerHTML和value值
    document.getElementsByName("obj")[0].innerHTML取得是文本内容默认为String类型
    如果要跟数字进行比较需要parseInt()转换为int类型
    5.4.设置输入框中只能输入数字不能输入字符或中文
    οnkeyup="this.value=this.value.replace(/[^\d\.]/g,'')"  onafterpaste="this.value=this.value.replace(/[^\d\.]/g,'')"
    5.5.单双引号内嵌时使用转义字符

    6.Null Reference Exception: Object reference not set to an instance of an object
    空指针(引用)异常,

    7.Unassigned Reference Exception: The variable cube of lesson03 has not been assigned.
    You probably need to assign the cube variable of the lesson03 script in the inspector.
    未赋值指针异常


    8.UnityException: Tag: 小猪佩奇 is not defined.


    9.ArgumentException: The Object you want to instantiate is null.
    参数异常,参数为空

    10.You are trying to create a MonoBehaviour using the 'new' keyword.  
    This is not allowed.  MonoBehaviours can only be added using AddComponent().  
    MonoBehaviour脚本不能New


    11.Cant add Script Exception...
    脚本的组件名和类名不一致


    12.MissingComponentException: There is no 'Rigidbody' attached to the
    丢失组件异常,Rigidbody没有被添加

    展开全文
  • 软件测试之BUG的生命周期

    千次阅读 2019-06-18 15:42:17
    作为一名测试人员,重要的工作内容之一,就是找BUG,提交BUG,验证BUG,推进BUG的解决,直至软件达到发布的标准,提高软件的质量,及研发的工作效率和质量。 要找BUG,那么,就要先了解一下BUG的定义是什么? BUG...

           作为一名测试人员,重要的工作内容之一,就是找BUG,提交BUG,验证BUG,推进BUG的解决,直至软件达到发布的标准,提高软件的质量,及研发的工作效率和质量。

           要找BUG,那么,就要先了解一下BUG的定义是什么?

    BUG的定义:

           软件的BUG,狭义概念是指软件程序的漏洞或缺陷,广义概念除此之外还包括测试工程师或用户所发现和提出的软件可改进的细节、或与需求文档存在差异的功能实现等。

           我们的职责就是,发现这些BUG,并提交给开发,让开发去修改。

    BUG的由来

    1、缺乏有效沟通

    2、软件的复杂度

    3、编程错误

    4、不断变更的需求

    5、时间的压力

          了解了BUG的定义以及由来后,那就要去了解BUG的类型,只有了解了BUG的类型,才能有的放矢,才能有目的,有范围的去寻找BUG,避免盲目寻找BUG,浪费宝贵的测试时间。 

    BUG的类型

           要确定一个BUG的类型,需要对项目(或产品)有比较深的理解。这个划分对于问题类型的统计就比较重要了。

           划分方式一:

           功能问题、设计缺陷、界面优化、性能问题、配置相关、安装部署、安全相关、标准规范、测试脚本、文档错误、兼容问题、用户体验、其它。

           划分方式二:

          功能类、性能类、界面类、易用性类、兼容性类、其它。

           找到BUG后,那么,就要对BUG区分等级,以便开发人员,根据BUG的优先级来处理BUG,优先解决紧急的,致命的BUG,次要解决严重的BUG,接着解决一般的BUG,再接着解决轻微的BUG,最后,解决界面上的细小问题,这样,能提高软件研发的进度,提高软件的质量。

    BUG的等级

           Bug等级,这个划分有分三级或四级,也有分五级的。如果是等级越高,那么可能被修复的等级会高一些,有些公司还会根据你提的BUG数量和BUG等级来考察你的绩效。很多情况下,我们提交BUG大致的等级差不多即可,没有严格区分。

    如何判断BUG的等级(严重程度1、2、3、4),一般可以参照下面的判断条件

        1、致命错误(1级提BUG需慎重)

    (1)常规操作引起的系统崩溃,死机,死循环

    (2)造成数据泄漏的安全性问题,比如恶意攻击造成的账户私密信息泄露

    (3)涉及金钱

    (4)用户数据受到破坏,或者危及人身安全

         2、严重错误

     (1)重要功能不能实现;

     (2)错误的涉及面广,影响到其他重要功能的正常实现;

      (3)严重操作导致的程序崩溃、死机、死循环;

      (4)外观难以接受的缺陷;

      (5)密码明文显示;

      (6)数据不能保存,系统的次要功能完全丧失,系统所提供的功能或服务受到明显的影响

        3、一般错误

    不影响产品的运行、不会成为故障起因,但对产品外观和下道工序影响较大的缺陷

      (1)次要功能不能正常实现;

      (2)操作界面错误(包括数据窗口内列名定义、含义不一致);

      (3)查询错误,数据错误显示;

      (4)简单的输入限制未放在前端进行控制;

      (5)删除操作未给出提示;

         4、细微错误

    程序在一些显示上不美观,不符合用户习惯,或者是一些文字的错误

       (1)界面不规范;

       (2)辅助说明描述不清楚;

       (3)提示窗口文字未采用行业术语;

       (4)界面存在文字错误;

    三级BUG_未修改成功,又重新打开等级上升一次_二级BUG_二级还是没解决_直接一级BUG

    改进建议:可以提高产品质量的建议,包括新需求和对需求的改进。

           找到BUG,提交BUG后,那么,就要进入BUG的生命周期了。

    bug的生命周期

    BUG的生命周期,就是一个BUG被发现到这个BUG被关闭的过程。

    生命周期中缺陷状态:新建-->指派-->已解决-->待验-->关闭

    发现BUG-->提交BUG-->指派BUG-->研发确认BUG-->研发去修复BUG-->回归验证BUG-->是否通过验证-->关闭BUG

    如果待验的BUG在验证时没有解决好,我们需要重新打开--指派—已解决—待验,循环这个过程。

    中间其他状态:拒绝、延期等

    BUG的处理流程图(生命周期图)

     

     

     

    设计如此(不是缺陷):1、核对需求规格说明书  2、找业务或者产品进行确认  3、确认是设计如此(不是缺陷),则直接关闭BUG。4、确认设计不是如此,跟开发沟通,重新激活指派BUG

    重复BUG: 测试人员找到对应重复BUG的ID。如果确认是重复BUG,直接关闭(通常是关闭,后面提交的那个重复的BUG)

    无法重现:1、确认开发的环境,跟操作步骤是否跟测试人员一致;2、在与提交BUG相同的环境下,重复验证一定的次数,比如,15-20次等,再未重现BUG,将状态该为无法重现

    注意事项:

    开发人员应在BUG系统中,备注好以下信息:

    已修改BUG应在该BUG的注释处,备注修改方案及信息,以备以后出现类似的问题时,可以快速的找到原因

    设计如此(不是缺陷)、不予解决、延期解决的BUG、无法重现的BUG,应备注处理的原因,节省沟通的时间,以及,如果后续有相同问题时,可以快速查找到原因

    重复BUG注明重复BUGID

    状态处理

    1.已经指派的BUG---已经指派给开发的,应随时关注并进行跟踪自己所提BUG的状态变化!如果一直未修复,提醒开发人员修改;如果已经修复等待测试环境更新后进行验证

    2.已解决的BUG----等待测试环境更新后进行验证,验证通过则关闭;验证不通过则重新指派给开发

    3.重复BUG----先去查看下是否跟开发指定的BUG或者,自己在BUG系统内看到的BUG重复?如果确定重复则关闭;如果不重复,说明原因,重新打开指派给开发。

    4.不是缺陷----确认开发环境是否和测试环境一致,如果如开发所说不是缺陷则进行关闭;如果确认是缺陷跟开发沟通,沟通未达一致找产品/反馈老大确认,确认是BUG注明情况并再次指派给开发。

    5.无法重现----确认开发环境是否跟测试环境一致?包括操作步骤,浏览器、环境、特定账号等,如果多个版本验证之后,如开发所说重现不了,依据BUG的严重程度跟产品,开发一起确认关闭;如果找到重现原因,注明清楚并再次指派给开发。

    6.不予解决---找产品经理进行确认。确认不予解决进行关闭;确认需要解决请备注原因并打开指派给开发

    7.设计如此---找产品经理进行确认。确认设计如此进行关闭;确认是问题,备注原因重现指派给开发。

    8.延期修改---请看下BUG严重程度,是否影响当前版本发布?与产品经理进行确认。不予延期请根据情况重新打开并将情况进行备注说明;确定延期则做好记录,后续版本进行关注。

     

    展开全文
  • 测试人员怎样定位bug原因

    万次阅读 多人点赞 2018-07-23 09:42:45
    作为测试人员,和我们最常打交道的,莫属bug。当你发现bug后,会采取什么样的行动?是直接报出来,亦或找找问题原因? 不管是我们自己找到的,亦或是开发修复后告诉我们的,知道问题之所在总是好的。在本篇文章中,...

    作为测试人员,和我们最常打交道的,莫属bug。当你发现bug后,会采取什么样的行动?是直接报出来,亦或找找问题原因?

    不管是我们自己找到的,亦或是开发修复后告诉我们的,知道问题之所在总是好的。在本篇文章中,笔者试图带领大家一起梳理下,为什么测试人员定位问题很重要,以及我们可以使用什么样的定位方法。

    一、定位问题的重要性

    很多测试人员可能会说,我的职责就是找到bug,至于找原因并修复,那是开发的事情,关我什么事?

    好,我的回答是,如果您只想做一个测试人员最基本最本分的事情,那么可以这么想。但是,如果您想要在测试甚至开发的道路上长足发展,就要知其所以然。那么,为什么定位问题如此重要?

    1.可以明确一个问题是不是真的“bug”。很多时候,我们找到了问题的原因,也许发现这根本不是bug。原因明确,误报就会降低。比如我们团队的大梅同学,全年500个bug中没有一个无效的。

    2.找到bug原因后,可以明确地指个某个开发,防止他们打太极推来推去,提高缺陷的修复速度。

    3.让开发人员能够佩服你,提升开发对测试的信任度。

    4.自己在这个过程中能学到很多东西,有助于理解产品内部逻辑,对架构的理解,以及数据流是怎样的走向。随着对业务架构逻辑的理解,反过来又会促进对问题的定位。

    5.可以降低缺陷率。这个可以说是最重要的。在bug系统中,我们会要求开发人员记录bug产生的原因。只有我们自己对bug有一个较全面的认识,才会判别出开发写的是不是真正的原因,也才能有助于我们后续对bug进行分析归类,根据bug分析,有针对性地未雨绸缪,进而提升产品质量,降低缺陷。

    所以,定位问题很重要。接下来我们就来探讨下有哪些定位问题的方法和技巧。

    二、问题定位技巧

    首先,作为开发也好,测试也好,定位问题有一个总的思路,而这个思路是和数据的走向一致的。大致是这样:

    用户层面问题 -> Web页面/软件界面 -> 中间件 -> 后端服务 -> 代码 -> 数据库

    以下都以Web页面举例说明。

    用户层面问题指的是用户自己的环境问题或者操作问题,比如环境不通,或者操作不正确。这种问题一般不是bug,当然,如果要考虑构建更加健壮的软件,那么可以根据实际情况来决定要不要处理这类问题。

    到第二步,用户在Web页面进行正常操作时,也可能会发现问题。这类问题一般通过观察以及利用一些常识可以发现,比如样式问题一般是css的问题,交互问题一般是js的问题,文本问题一般是html的问题(当然有可能是其他问题,例如js生成html)。

    到第三步,Web页面操作后,比如发出一个请求,可能会进入中间件这个层面。我这里说的中间件是广义上的,比如LVS、CDN、各种缓存服务器等等。我们遇到过一个问题,发现刚刚上传的图片进行读取展示时就读不到,那么可以想到可能是负载均衡时将上传照片和读取照片两个请求分配到了不同的服务器导致的,也就是我们常说的会话保持。当然,中间件问题有时候是和开发相关的,有时候是公司其他团队负责的,比如360公司就是OPS在负责。当然,中间件也不仅仅会出现在这一步,实际的项目中可能还会用到更多的基础设施,比如消息中间件、数据存取中间件等,如果发现了相应的问题也就需要有对应的思路去排查。

    接着再往下到第四步,服务会转发到我们真正的后端服务层,web服务器、应用服务器比如nginx、tomcat会收到请求。如果发现内存溢出,那么就可能会定位到是tomcat配置的问题;如果请求返回404,也可能是nginx配置不当。当然,这个时候可能会遇到一些环境问题,比如测试环境没有的问题,到线上就有了,很可能是环境原因,比如jdk版本不同、tomcat版本不同、jar包版本不同等等。

    最后一层是数据库。代码没有问题,不代表软件没有问题。数据库层面也可能会有各种各样的问题,比如字段的约束问题等等。假如一个文本框的前端校验和接口校验的文本长度最大是50,但数据表字段设定的是varchar(30),那么在存数据的时候肯定会报错。再比如之前发现一个数据库的问题,测试环境没有,到线上却有了,那么也可以看下是不是数据库版本不同导致的。

    上面我们说的是问题定位的一个大致思路。每一个环节都有可能出现bug,既可能是response的问题,也可能是前端回调处理的问题。有的问题可能会直接暴漏在用户面前,有些则可能需要我们去分析日志。

    当然,很多时候我们不需要这样一层一层去定位,经验丰富的开发或者测试根据现象可能马上能定位到究竟哪里出了问题。

    下面我们就来说说测试人员定位问题的N板斧。

    1

    让子弹飞一会儿

    碰到问题先别忙定位,首先请保存犯罪现场,并且确认能复现。然后排除QA的低级问题 。为什么要保存现场?如果以后复现不了,就证明不了问题的存在。有哪些QA的低级问题?常见的就是hosts不对,网络不通,以及操作姿势不正确等等。这个其实就是上文提到的用户层面问题,这里的用户就是QA人员。经常有QA人员发现问题后就赶紧叫开发过来看,开发这时候幽幽地说句“host对吗”,一看不对岂不是很尴尬。

    还有一类问题就是脏数据,我们有时候会遇到服务端报500错误,查看日志后,报空指针,那么很有可能就是数据库中关联表的数据被人为删掉导致的。还有的问题是由于工具的影响导致的,例如fiddler。所以发现问题您别慌,让子弹飞一会,确认不是自己的问题再说。

    2

    直观查看页面表现

    这个就是上文提到的对Web页面的观察。不再赘述。

    3

    看状态码

    4xx状态码一般表示是客户端问题(当然也有可能是服务器端配置问题),比如发生了401,那么要看下是否带了正确的身份验证信息;发生了403则要看下是否有权限访问;404则要看下对应的URL是否真实存在。

    而5xx一般表示服务端问题。比如发生了500错误,则表明是服务器内部错误,这个时候要配合服务器log进行定位;发生了502则可能是服务器挂了导致的;发生503可能是由于网络过载导致的;发生504则可能是程序执行时间过长导致超时。

    4

    看服务器日志

    如果发生5xx问题,或者检查后端接口执行的sql是否正确,我们最常见的排查方法就是去看服务器日志比如tomcat日志,开发人员一般会打出关键信息和报错信息,从而找到问题所在。测试人员要养成看日志的习惯。并且,如果将来进行开发,也要养成打日志的习惯,否则发现问题真不知道到哪哭去。

    5

    接口的请求和返回以及js执行是否有报错

    在第3点中我们说了状态码的问题,明确了4xx和5xx的问题所在。那么,如果接口返回了200,就一定正常吗?

    假设有这么一种情况,要测试一个翻页控件,翻到第二页的时候,发现内容和第一页完全一样,接口请求返回的是200。这个时候你会怎么排查?

    这个时候就要看前端发送的参数正不正常,后端返回的内容正不正常,即接口的请求和返回。

    我们来看翻页控件的问题。我们看接口的请求(F12控制台查看网络请求或者抓包工具),一般根据开发的习惯,会有pn、ps参数,看看传值是否正确。如果请求参数不正确,那么就是前端的问题。如果正确,那么就看response,看看返回的内容对不对,以此就知道到底是前端问题还是服务端问题。如果发现js执行报错了,那就是前端有问题,比如跨域问题。

    请求URL不正确,是前端bug,传参不正确,是前端bug,响应内容不正确,则是后端bug。如果是响应内容不正确的后端问题,那就要继续深挖,是接口吐数据的时候出错了,还是数据库中的数据就错了,还是缓存中的数据错了(如果用到了缓存的话)。经常见到后端开发人员有的负责接口,有的负责写入数据库,有的负责维护缓存,所以如果发现是后端的问题,可以更进一步确认下是哪块的问题。

    6

    看需求文档

    有时候,前端和服务端的交互都正确,但是从测试的角度看不合理。这个时候,我们应该翻翻需求文档(如果没有的话,就直接抛出这个问题)。如果和需求文档不符,那么就要看下谁改合理,是前端改,还是服务端改,或者两者都得改。这里有一个原则,就是前端尽可能少地去承担逻辑,只负责渲染展现。当然,不要以为需求文档就全部正确,它也可能会有错误,我们也应该去发现需求文档的bug,然后再去协调PM,敦促FE或者RD进行修改。在这点上,不得不说,有的开发做的比较好,他会有自己的思想,在开发的时候就能发现需求文档的错误,而有的开发则是无条件无脑执行。

    7

    后端生成页面问题

    后端生成页面,最常见的就是类似于jsp、php、python的某些前后端不分离的框架,这种比较特殊,常见于单人开发的项目,这种项目的问题排查和其他项目总的思路也一样,只不过前后端bug的修改可能都是同一个人而已。

    8

    开发提供可测性支持

    有时候,涉及到多方面合作,不太好测试的情况下,需要开发提供可测性支持。比如,要查看接口给另一个接口发的请求是否正确,可以让开发打印出完整的请求log。还有一些逻辑开关、修改页面数据条数等,都属于可测性支持的范畴。

    9

    配置的问题

    很多时候,bug不是代码问题,而是tomcat配置、nginx配置、jdbc配置等的问题。在这个层面上,测试人员最好能够了解下它们的各项配置,在发现问题后可能就会想到这方面的问题。

    10

    经验法则

    太阳底下没有新鲜事,有经验的人早就遇到过相同的问题。高手往往能够一眼看穿表面现象内部的问题,然后直奔主题,迅速报告或者解决,留下别人在风中凌乱……

    11

    其他

    常见的可能还有构建的问题,比如代码本身都没错,但是合并代码到主干后出问题了,常见的就是代码存在冲突时手动解决的时候。所以我之前有一段时间喜欢问开发在合并代码时有没有冲突,如果有冲突,那是什么地方有冲突,就得重点对待了。

    另外,定位到问题后,还要考虑下具体情况,根据开发人员的心态来决定要不要告诉他具体原因。有的开发不够open,会觉得你抢了他的饭碗。而对于open的开发,你们会因此配合的更加默契。

    当然,我们在发现问题或者定位到问题原因后,一定要进行一步,就是再次确认问题。所谓确认问题,就是弄清楚问题是否每次都发生,还是概率事件,或者是工具相关的问题(比如换个浏览器是否依然出现?如果换个浏览器不出现的话,很可能就是前端的兼容性问题)。比如翻页控件,我们待测的系统有很多页面都有翻页控件,那么就要看下是否每个页面都会出现这个问题,进而报bug时进行统一说明,也更加方便开发人员批量处理,防止漏改。

    以上是对问题的初步定位。对问题的进一步分析可能是更加体现测试人员素质的,比如你发现了一个问题,通过白盒测试看他的代码,发现某一个分支的判断条件写错了,并且把这些告诉了开发,那么他一定会给你一个大大的赞,然后说上一句,小伙子靠谱,和你合作很愉快!

    三、案例

    下面介绍几个常见的问题并逐一分析下。

    1、点击页面的某个“修改”按钮,页面弹窗提示“unforbidden”,但需求文档中显示应该提示“没有权限”,如何定位?

    这个问题要看弹窗中的错误信息是谁发出的。如果点击修改按钮,前端发出了一个接口请求,而该接口的response中有“unforbidden”,那么说明前端的提示是后端返回的,那么就需要后端去修改。否则就是前端写的提示。所以,有时候不能想当然地认为前端弹窗提示文案一定是前端的问题。具体问题具体分析。

    2.修改某个表单中文本框内的文字并提交,跳转到结果列表页后发现该文本内容显示不全,该如何排查?

    这个问题的可能性有很多,我们可能需要这样排查:首先查看下表单提交时,前端发送的请求中该文本内容是否正确,如果正确就再去数据库中查看记录,然后去看后端响应内容是否正确,然后去看前端渲染是否正确,以此来判断是前后端交互的哪个环节出了问题。

    四、总结

    可以发现,上面两个案例都没有定论,都是得具体问题具体分析。我们只要掌握了分析方法和思路,就能够找出来到底是哪里出了问题。前端页面所看到的所有元素以及所有数据,要么是前端返回,要么是后端返回,有问题了,就看是谁生成的返回,前端返回的就去找前端,后端返回的就去找后端,谁的孩子惹麻烦了就去找谁,前后端就靠http来通信,所以要多F12,多观察前后端接口交互。

    这只是经验总结,并非标准。bug千差万别,有时候需要一个一个分析。多修炼内功:对业务系统的掌握,测试方法以及开发技术。建设自己的bug知识库,多思考、多积累、多总结。

    最后,请谨记:对于无法确定的问题或者目前功力难以定位的问题,要交给开发,不要死磕,浪费时间。如果冒烟测试都不通过,就不要浪费时间定位了,直接打回。优先解决项目进度问题,其次才是测试深度。

    展开全文
  • 软件史上最严重的十个Bug

    千次阅读 2010-08-18 10:04:00
    原文地址:http://www.cxybase.com/daypic/bug-117.html 2005年10月在通报其汽车预警灯毫无理由的点亮和汽油发动机出现不可预 见的延迟之后,丰田制造商宣布召回他的160,000辆Prius hybrid混合动力汽车。...

     

    原文地址:http://www.cxybase.com/daypic/bug-117.html

     

    2005年10月在通报其汽车预警灯毫无理由的点亮和汽油发动机出现不可预 见的延迟之后,丰田制造商宣布召回他的160,000辆Prius hybrid混合动力汽车。但和去年大规模的召回汽车不同,Prius hybrid的根本问题不是硬件问题——而是智能型汽车的软件出了故障。Prius hybrid汽车中的嵌入式软件中存在着bug。

    伴随 着这次召回,Prius hybrid也加入到Buggy Computer的行列中—这是一个在1947年成立的组织,这一年工程师在Harvard Mark 1系统中的F, Relay #70中发现了一个bug。当工程师发现故障时,该计算机正在运行它的乘法器和加法器。该错误被捕获,删除并且以下面的语句的方式录制到计算机的日志 中:“first actual case of a bug being found.”

    60过去了,计算机bug仍然存在着,同时并没 有任何灭绝的迹象。随着软件和硬件的界限越来越难以区分,代码错误越来越对我们的日常生活造成不良影响。Bug并不仅仅是寄生在我们的操作系统和应用程序 中—今天他们存在于我们的电话、起搏器、我们的电力设备和医疗设备中,还有我们的车上。

    但是哪一个是最严重的呢?

    我们很容易列出造成较大破坏的bug,然而我们却很难去评估他们的严重程度。哪一个破坏性更大?—是一个被计算机蠕虫所利用,连续几天关闭你的上网服务的安全漏洞,还是一个引发国家电话系统整个白天瘫痪的排字工?答案也许取决于你是需要打电话还是查收你的电子邮件。

    很 多人认为最严重的bug是能够致命的bug。固然,这类的bug不是很多,但是像Therac-25的案例被普遍认为是一种会在重要的安全应用程序的软件 广泛传播的警告。尽管研究这些系统的专家警告该软件可能会对一些人造成伤害,阻止该技术引入到那些非常需要智能处理技术的领域,那些人需要承受可能会有的 风险。然而,最终他们却认为该软件的缺乏可能会比那些不可避免的bug给更多的人造成伤害。

    Mariner I发射

    按照时间顺序,著名网络媒体Wired News列出了到目前为止10个最严重的软件bug。

    1962年7月28日, Mariner I空间探测器事件。

    Mariner 1航空软件的bug导致火箭在发射时偏离了其的预期轨道。任务控制器在大西洋上空将整个火箭摧毁。在对这起事故进行调查中发现,使用铅笔撰写下的一个公式被不正确的录入到计算机代码中,直接导致计算机错误的计算了火箭的运行轨道。

    1982年—苏联的石油管道事件。

    根 据CIA(美国中央情报局)的陈述,为其工作的间谍们在苏联购买的用来控制跨西伯利亚石油管道的加拿大计算机系统中种下了一个bug。当时是苏联通过秘密 购买或者偷窃美国的敏感技术来获取到了该系统。据说CIA发现了这个存在bug的程序,决定对可以通过苏联人检查的设备做一个让苏联人事与愿违的破坏,使 得该设备一旦运行起来将会失败。该事件的结果据说在历史上造成了最大的非原子破坏。

    1985-1987年间 -- Therac-25医疗加速器事件。

    一 个放射疗法的设备故障造成了在几个医疗设备中发出了致命的射线。Therac-25是一个在以前设计的基础上改进的治疗设备,该设备可能会发出两种射线: 或者是一个低功耗的电子束或者是X射线。Therac-25'的X射线是通过猛烈的高能电子束撞击到一块位于电子枪和患者之间的金属目标而产生的。第二项 改进是对于更旧的Therac-20'电动保险联动装置采取软件控制的方式代替,做这项改进是因为软件被认为更加可靠。

    然而工程师所不知道 的是20和25型号都是建立在有一个没有经过正规培训的程序员所开发的操作系统上的。由于这个不易察觉的叫做"race condition,"的bug,一个快速的打字员很可能会很偶然的配置Therac-25从而导致电子束将会在高能模式下启动。但是强烈的X射线偏移了 目标。最后直接导致了五名患者死亡;其余患者受到了严重伤害。

    1988年--伯克莱UNIX操作系统finger守护进程缓冲器溢出事件。

    第 一个网络蠕虫,莫里斯蠕虫利用缓冲器溢出在一天之内感染了2000到6000台计算机,起因是一个标准输入输出库函数gets(),原来设计为从网上获取 一段文本,但遗憾的是,gets()函数没有规定输入文本的长度。过长的文本导致蠕虫入侵任何接入的计算机。程序员们试图用工作码来取代gets()函数 的功能,但是他们拒绝从C语言的标准输入输出库中删除它,直到今天还保留着。

    1988-1996年间--Kerberos随机数字发生器事件。

    Kerberos安全系统的作者忽略了产生真正的程序随机码时使用恰当的种子,导致长达八年依赖Kerberos验证的计算机可被轻易入侵。如果漏洞不被利用,就一直不会被发现。

    1990年1月15日,AT&T网络瘫痪。

    利 用一个新发布软件的bug可以控制AT&T #4ESS远程交换机,在邻近计算机之间发送信息引起大型计算机瘫痪,机器恢复时发送信息又导致邻近计算机当机。 一天纽约的一台交换机当机并且重启,引起它邻近交换机瘫痪,由此及彼,一个连着一个,很快,114台交换机每六秒当机重启一次,六万人九小时内不能打长途 电话。当时的解决方式:工程师重装了软件以前的版本。

    1993年--Intel奔腾浮点指数除法事件。

    一 个硅片上的错误导致Intel高性能奔腾芯片在一段范围内计算浮点指数除法时发生错误。例如4195835.0/3145727.0产生的是 1.33374而不是1.33382,产生了0.006偏差。尽管该bug仅仅影响了几个用户,然而他却成了整个公众的噩梦。估计流通中的三百万到五百万 的芯片存在着这样的缺陷,起初Intel仅仅为那些能够证明他们确实有高精度计算需求的用户提供了取代奔腾的芯片。最后,Intel公司只好妥协为任何投 诉的人提供替代芯片。该bug给Intel最终造成了4亿7千5百万损失。

    1995/1996年–致命的ping命令。

    由 于缺乏对IP段组装代码的完整性检查和错误的执行使得有可能通过从互联网的任意位置发送恶意的”ping”数据报而攻击多个操作系统。大部分受明显影响的 是运行Windwos的计算机,当他们接受到数据报后,他们就会死锁同时显示所谓的“蓝屏死机”。但是攻击同时也影响很多Macintosh和Unix系 统。

    1996年**号—501航天飞机爆炸事件。

    对于Ariane 4火箭的工作代码在Ariane 5中被重新使用,但是Ariane 5更高速的运算引擎在火箭航天计算机中的算法程序中触发了一个bug。该错误存在于将64位浮点数转换为16位带符号整数的程序中。更快的运算引擎导致了 Ariane 5中的64位数据要比Ariane 4中更长,直接诱发了溢出条件,最终导致了航天计算机的崩溃。

    首先501航天飞机的备份计算机崩溃,然后0.05秒之后,主计算机也崩溃了。这些计算机崩溃直接导致了火箭的主要处理器使火箭的运算引擎过载,同时导致火箭在发射40秒后解体破碎。

    2000年11月 –巴拿马市国家肿瘤中心事件。

    在这一系列事故中,由一家美国公司—Multidata Systems International所开发的治疗软件错误的计算了对于正处于放射治疗中的病人所应该使用的合适剂量。

    Multidata的软件允许放射治疗师利用计算机屏幕的一个叫做"blocks"的金属装置来保护健康组织以免受射线的伤害。但是该软件仅仅允许治疗师使用4个屏蔽块,但是巴拿马的医生希望用5块来保护。

    医 生发现他们可以通过将所有的屏蔽块画成一个在中间有孔的大块来欺骗该软件。然而医生们没有意识到的是Multidata软件在这种配置中根据该空画法的不 同给出了不同的答案:如果该孔是在一个方向绘制的,则给出正确的计算出的剂量,如果是在另外不同的方向绘制的,软件就会推荐出要比必须需要暴露的射线的两 倍剂量。至少有8个病人在这次事故中丧生,同时接受了过多剂量放射的20个病人产生了严重的健康问题。被要求手动两次检查计算机的计算的医生被以谋杀罪起 诉。

    展开全文
  • 每天写bug是一种怎样的体验?

    万次阅读 2018-02-11 09:04:32
    本文转载自公众号 小象源 | 小象 文 | 小象君“哥们...程序员的人生就是bug和debug交织在一起的悲歌尽管每天都要和Bug打交道可你是否知道Bug这个叫法是怎么来的吗?上图中那个黑乎乎的东西就是史上第一个程序Bug
  • 尽量避免bug的一些手法

    千次阅读 多人点赞 2019-11-21 14:51:56
    尽量避免bug的手法
  • Bug汇总

    2019-10-24 22:32:17
    总结 1.ConstraintLayout无法让一个子控件在父容器的最右侧。如果是RelativeLayout就可以做到了。 2. listView中的内容一页显示不下,同时也无法继续向下拉动。ConstraintLayout无法向下滑动?还是应该设置一个属性...
  • BUG汇总 1

    千次阅读 2017-12-05 22:49:03
    1.Unsupported Modules Detected: Compilation is not supported for following modules问题描述: 在程序界面的右上角提示无法编辑程序 解决办法: File -> Invalidate Caches / Restart -> Invalidate Caches & ...
  • VScode终端变成chcp 65001后,一运行,就会出现一串红色乱码,让我去GitHub。如下: ![图片说明]... 然后我点回车后就变成这个样子 ... 在活动页936下倒不会出现红色错误,只是会中文乱码 ...
  • 常用BUG管理工具系统

    万次阅读 2018-08-21 16:40:50
    常用BUG管理系统 1.EasyBUG 优点: 1)基于WEB的在线的,不用配置; 2)界面简单,操作容易上手,基本上只要是会上网的人一看就会用 3)拥有截图功能,以图片的形式直接存在,而不是以附件形式; 4)BUG解决流程...
  • 一个BUG(缺陷)的生命周期

    万次阅读 2018-06-01 15:05:15
    缺陷状态 对于一个问题,其处理过程是一个周期,周期的不同阶段,其所处的状态也是不一样的。不同状态所对应的处理人也是不一样的。打开 : 表示问题被提交等待有人处理。重新指派 : 问题被重新指派给某人处理...
  • 记录几种常见的内存溢出与...使用的第三方软件中的BUG;  5.启动参数内存值设定的过小; 1.堆 设置jvm值的方法是通过-Xms(堆的最小值),-Xmx(堆的最大值) 2.栈 设置栈大小的方法是设置-Xss参数 3.PermGen space
  • 趣图:太真实,程序员调 Bug 的写照

    万次阅读 多人点赞 2018-01-08 12:56:30
    (点击上方公众号快速关注,不错过趣图)程序员调 Bug 的样子,非常真实~↓↓↓(动图原作者是 @我的邻居全是猫 )网友评论:@中国有圣人:哈哈哈……太形象了!最后干脆撂挑子不干了!破罐破摔了!@她叫小明:所以...
  • 3、如果开发说测试环境问题, 让他说明清楚测试环境问题是什么,按照他说的验证一遍, 如果确实如他所说, 关闭bug,但是不是他说的那样,继续激活bug给开发解决,确保产品质量。 4、如果开发说用户不存在这种使用...
  • web测试中,如何判断是前端的bug还是后端的bug呢?

    万次阅读 多人点赞 2019-01-23 16:25:57
    web测试中,如何判断是前端的bug还是后端的bug呢? 通常可以利用抓包工具来进行分析。可以从三个方面进行分析:请求接口,传参,响应。 1.请求接口url是否正确 如果请求的接口url错误,为前端的bug 2.传参是否...
  • 漫画:程序员调Bug的真实写照

    万次阅读 多人点赞 2018-01-09 18:27:17
    本漫画来自网络程序员调 Bug 的样子,非常真实~↓↓↓(动图原作者是 @我的邻居全是猫 )网友评论:@中国有圣人:哈哈哈……太形象了!最后干脆撂挑子不干了!破罐破摔了!@她叫小明:所以发明回溯这个超能力的这个...
  • Log抓取和分析-BugReport

    万次阅读 2018-03-01 11:28:41
    参考文章: http://blog.csdn.net/createchance/article/details/51954142 Google为了方便Android开发人员...开发人员可以使用adb bugreport命令获取系统运行的所有log信息。命令如下:adb bugreport &gt; bug...
  • 严重:很明显的错误性的bug 较重:相对明显的错误性的bug 一般:常见的bug 建议类:(暂时保留,可能去掉) 二 优先级 说明:紧急相当于执行前的准备工作,重要相当于后续的工作 重要且紧急:...
  • 一条缺陷(Bug)记录包含哪些记录

    万次阅读 2019-03-12 10:34:26
    Bug标题 Bug描述 Bug出现步骤 附件(可以附上出现的缺陷截图更有说服力) Bug严重程度和优先级《一般严重等级分为;致命,严重,一般,建议四个等级和优先级分为高中低三级》 指派给谁(一般指派给开发者...
  • 拼多多现重大Bug

    万次阅读 2019-01-21 18:26:11
    1月20日,一个平静的周末,拼多多却在这一天给消费者送了一个大礼,准确的说是大羊毛。据悉从20号凌晨开始,拼多多出现了一个超级大Bug,用户可以领取100元无门槛券,注意...
1 2 3 4 5 ... 20
收藏数 989,305
精华内容 395,722
关键字:

bug