精华内容
参与话题
问答
  • 常见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 14:27:50
    作为一名测试人员,重要的工作内容之一,就是找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是一种怎样的体验?

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

    点击上方“程序员小灰”,选择“置顶公众号”

    有趣有内涵的文章第一时间送达!


    本文转载自公众号  小象


     | 小象      | 小象君

    “哥们,又在写bug呢?”

    据说

    这是对程序员杀伤力最大的一句话

    没有之一!

    之所以如此,那是因为

    这是句大实话啊!

    程序员的人生

    就是bug和debug交织在一起的悲歌

    尽管每天都要和Bug打交道

    可你是否知道

    Bug这个叫法是怎么来的吗?

    上图中那个黑乎乎的东西

    就是史上第一个程序Bug——

    一只烧糊的蛾子

    1947年

    哈佛大学的计算机Harvard Mark II

    突然停止了工作

    程序员们费尽周折

    终于找到了问题的关键

    就是这只死掉的蛾子

    这就是Bug这种叫法的来由

    那时

    哈佛二代没有二极管和晶体管

    是继电器计算机

    靠无数个噼啪作响的电子元件运作

    时常有电弧闪光出现

    这只蛾子被闪光所吸引

    毅然决然地扑了上去……

    从此

    从此永垂不朽

    其实

    Bug虽然人人能写

    但也有高低之分

    总体来说

    水平越高的程序员

    Bug写得越是牛逼…

    不信?

    我们来看看这些大神级的Bug

    吊炸天的Google APP

    前阵子

    谷歌推出了一个好玩的App

    Google Arts & Culture

    用户可以上传自己的自拍照

    系统会将照片与艺术画作进行对比

    匹配出一张

    和用户长得很像的

    画作中的人物肖像

    社交网络顿时沸腾了!

    人们纷纷晒出自己的自拍匹配成果

    有些效果确实不错

    有些就比较尴尬了

    画面太美不敢直视

    不得不说

    这哥们确实长得很屌…

    出现这样的Bug

    只能归咎于脸部识别技术尚不完全成熟了

    希望Google能早点改掉这些bug

    让他们重新做人…

    Bumblebee惊天bug

    如果不是Bumblebee开源项目

    你会相信

    一个空格也能导致系统瘫痪吗?

    安装后,

    usr/会被删掉

    至于后果有多严重?

    看下图…

    怎么样?怕了吧?

    500英里的Bug

    来源:知乎用户郭智明

    信用卡关联Bug

    对这位仁兄的遭遇

    小象君深表同情…

    见怪不怪的微软Bug

    敢问Outlook

    你究竟干了什么伤天害理的事?

    连亲妈都不认你了!

    ……

    那些匪夷所思的Bug

    有些Bug的出现让人百思不得其解

    fix后除了无奈

    更让人哭笑不得

    我叫刘伟楠,凭啥屏蔽我?

    这位刘伟楠童鞋

    想以实名注册新浪微博

    但他发现只要涉及“刘伟楠”三个字

    甭管加怎样的前缀后缀

    都会注册失败

    即便以其他名称注册成功后

    更改昵称为“刘伟楠”也同样无法实现

    该童鞋万般无奈之下发了帖子

    一时间响应者无数

    最终在网友齐齐声讨下

    新浪微博取消了该项屏蔽

    不过至于为什么会出现这样的bug

    新浪微博并没有给出解释……

    飙高音造成笔记本死机

    最终解决方案:

    把固定硬盘的螺丝紧了紧

    固有频率改变

    硬盘就不共振了

    X射线带来的Bug

    Quora上有位程序员

    讲述了这样一个经历

    他为医院急救设计了一个相关程序

    在实验室运行良好

    但是每次在医院调试都出 bug

    作者只好到医院去现场调试

    经过漫长的测试终于发现

    是由于医院使用的X射线

    导致电脑内存总是丢失几个 bit 的信息

    致使程序出问题!

    最终的解决方案是

    把电脑的内存用铅板隔起来!

    硬盘分区搞死人

    故事发生在工厂

    工厂里有14条线

    其中一条线的zebra打印机

    在打印标签时

    比其它线要多耗时3秒左右

    即便打印的东西完全一样

    因为产线一直在生产

    所以没法在线debug

    只能在线外模拟

    但模拟结果一直都显示正常

    问题始终无法解决

    后来干脆换了电脑,fix了!

    最后看了下硬盘的分区格式

    服务器是NTFS

    这台电脑的D盘是NTFS

    而E盘居然是FAT32!!!

    谁特么这么干的!

    粗来!保证不打死你!

    中文和英文符号的差异

    请童鞋们看看

    如上两段代码有什么不同?

    一模一样是吧?

    但实际上第二行可以运行

    第一行却无法运行

    至于原因

    分享的童鞋最后说了

    中文的-和英文的-外表没有不同

    但编码就是不一样……

    微信大小写坑爹

    一位程序员自述

    3月份负责公司微信公众号开发

    当时的后台是技术领导写的,c#

    公众号支付的预定单和加密全在后台

    后来后台改版本

    由c#改为Java

    结果调了一晚上

    显示签名错误

    技术领导看了好久也不知道怎么回事

    c#的代码和Java的代码对了一遍

    发现没问题

    又把微信公众号配置也看了一遍

    也没问题

    各种百度、各种猜想

    各种验证,都不对……

    几乎把网上的说的问题都查了一遍

    还是不对……

    最后去微信官网看了开发者文档

    发现上面预定单的appId的i是大写

    但支付的时候是小写!

    于是,fix了……

    不是Bug的Bug

    有些程序员习惯了bug与debug的节奏

    遇到问题

    往往第一时间进行debug处理

    结果好不欢乐

    下面我们来听听

    他们和Bug的那些事

    Bug是Wifi

    刚进公司做iPad应用

    公司给了两台测试机:

    一台iPad4

    一台iPad Air

    应用里面有个资源下载功能

    同一个资源用同一段代码

    不过在iPad Air上下得飞快

    在iPad4上面就慢如龟爬

    一直搞不懂是什么问题

    两边程序都是一模一样

    但到底为什么会有这么大的差别呢?

    曾天真的设想

    是不是两台不同型号的设备内部

    某个网络相关的硬件不一样

    导致下载速度不一样呢?

    然后不断Google、百度查资料

    看帖看论坛看博客

    希望找到看有没有前辈遇到这种怪问题

    然而找了3天还是找不到……

    到了最后……

    特么发现

    那台iPad4连的

    是楼下咖啡店的WiFi……

    图像为啥黑屏

    直播伴侣

    是给主播用的视频美颜的工具

    眼下各大直播平台都普遍采用

    有一次程序作了大的架构调整

    结果发现图像黑屏了

    就下断点一步一步查

    先检查采集SDK给我的数据是否有问题

    再看看GPU图像数据缓冲区

    最后终于找到了问题

    fix了

    但第二天这个问题又出现了

    摄像头又一次黑屏了

    于是又开始设断点

    检查采集的图像数据

    检查GPU里的缓存数据

    检查经过美颜

    经过图像识别处理后的数据

    但是反复检查

    就是没有发现任何问题!

    心急如焚之际

    突然发现

    摄像头的正面扣在地上

    直挺挺的竖在那儿

    于是把摄像头拿起

    问题解决……

    游戏Bug

    作为程序员

    每次玩游戏遇到Bug

    总会设身处地地想

    这哥们到底怎么搞的?

    猎魔人

    魔兽世界

    质量效应

    人物和画面出现问题

    是游戏Bug基本的表现形式

    不过这还算好的

    起码情节没耽误

    下面这种情况就让人无奈了:

    我是团里里最厉害的大神

    今天要打团战

    突然我连人带马嵌到了鼓里

    怎样也甩不掉 

    想通过栅栏与鼓分离

    结果栅栏也甩不掉了

    没时间了,出城吧!

    栅栏比城门宽,出不去

    无法从城门走

    那用轻功吧!

    结果……

    连人带马嵌入了城墙里

    无奈只得联系客服

    说人能下来,但——

    打团战怎能没坐骑?

    然后客服给了我——

    生活中遇到的Bug

    浸淫行业数年

    练就了一双火眼金睛

    对于各类Bug最是敏感

    比如:

    弱弱地问下

    这趟是星际高铁吗…

    受宠若惊!

    您这是跨省来接我的吗……

    ……

    每次遇到这种情况

    小象君总会幻想

    如果我中意的妹子遇到Bug

    憋慌!

    除了写Bug

    我们更擅长Debug!


    —————END—————




    喜欢本文的朋友们,欢迎长按下图关注订阅号程序员小灰,收看更多精彩内容




    展开全文
  • 常用BUG管理工具系统

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

    千次阅读 2017-12-05 19:25:23
    WHY为什么要做bug分析 原因一:借助bug,提升测试人员对产品质量的整体把控  从项目初期的产品需求PK,到开发阶段的自测、迭代提测、集成上线提测,直至发布后用户反馈,可以说bug几乎贯穿了产品发展的各个阶段。...
  • Bug汇总

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

    千次阅读 2018-01-05 23:03:28
    &nbsp; &nbsp; &nbsp;... 接下来笔者会围绕bug产生的原因,各种类型的bug修复方案,以及如何必免大部分bug的产生,来一探bug的真面目,希望能对您有所帮助。 &nbsp; &nbsp; ...
  • VScode终端变成chcp 65001后,一运行,就会出现一串红色乱码,让我去GitHub。如下: ![图片说明]... 然后我点回车后就变成这个样子 ... 在活动页936下倒不会出现红色错误,只是会中文乱码 ...
  • 一个BUG(缺陷)的生命周期

    万次阅读 2018-06-01 15:05:15
    缺陷状态 对于一个问题,其处理过程是一个周期,周期的不同阶段,其所处的状态也是不一样的。不同状态所对应的处理人也是不一样的。打开 : 表示问题被提交等待有人处理。重新指派 : 问题被重新指派给某人处理...
  • 在知乎上看到一个很有意思的问题“软件测试完后,还有BUG,是测试人员的问题吗?” 相信很多测试的小伙伴也都遇到过这样的情况,往往产品上线,只要出现bug,成为“背锅侠”。 测试人员在工作中经常打交道的肯定是开发...
  • 一、问题的出现 如下图所示,当你要打印出***“Hello world 你好”***时,==“你好”==这个词就输出成中文乱码 二、问题出现的原因: 因为你选的文本格式是UTF-8(95001),而编辑器默认的格式是GBK(936) ...
  • 这种新手都不会范的错,居然被一个工作好几年的小伙子写出来,差点被当场开除了。
  • iOS Bug 太多,苹果终于坐不住了!

    万次阅读 多人点赞 2019-11-23 09:10:00
    开源的 Android 和闭源的 iOS,作为用户的你,更偏向哪一个呢? 整理 | 屠敏 出品 | CSDN(ID:CSDNnews) 毋庸置疑,当前移动设备操作系统市场中,Android 和 iOS 作为两大阵营,在相互竞争的同时不断演进。...
  • 解决办法有的很多种,下面的都是我亲测的,有时候发现第二次使用另一种方式也可以解决,所以内容仅供参考 1- jpa解决org.hibernate.lazyinitializationexception无法初始化代理 - 没有会话 #配置文件添加懒加载 ...
  • Bug

    2006-12-29 11:58:00
    Bug的生命流程从新增的opened状态开始,到closed状态结束,主要流程包括bug新增、bug解决、bug验证和bug关闭。 一、 Bug跟踪流程Bug的生命流程从新增的opened状态开始,到closed状态结束,简单而言,Bug核心跟踪...
  • 常用BUG解决方法

    千次阅读 2018-06-10 10:44:11
    下面就来说一说,在遇到代码BUG,我们常用的一些方法! 二分定位法   通常来说,无论BUG因此多深,通过二分定位法基本可以确定问题所在!那么什么是二分定位法?就是在程序关键点(可能的出错点)进行分割,看...
  • Bugfree使用手册

    千次阅读 2013-05-28 00:17:54
    Bugfree使用手册 本文档已按照最新版本的BugFree 3进行了更新,部分内容可能不适用于老版本的BugFree。建议访问BugFree下载页面,下载并升级至最新版本的BugFree。 BugFree FAQ Q1: 访问出现形如 “The ...
  • 前端调试bug的方法

    万次阅读 多人点赞 2019-07-06 19:04:21
    一: 断点调试(逻辑异常时使用) 在可能出错的位置设置断点 启动调试 单部执行(F10),观察变量的变化,将变量变化结果与预期结果进行比较,如果结果一致,则继续执行,如果不一致,可能出错。...
  • 一个bug管理软件:BugFree

    千次阅读 2006-08-08 18:40:00
    一个bug管理软件:BugFreeBugFree的发展目标:代替BugZilla和Mantis,成为最流行的Bug管理系统! 关于BugFree作者:刘振飞 Email: liuzf at pku dot org dot cn版本:$Id: ABOUT.htm,v 1.5 2005/06/27 07:23:59 ...

空空如也

1 2 3 4 5 ... 20
收藏数 1,074,668
精华内容 429,867
关键字:

bug