杀虫记录(3)-柿子赶软的捏

本文讨论了测试人员偏爱的Bug类型,尤其是那些在界面上明显出现问题的情况。文章通过一个具体的案例,展示了当软件升级后自动发布功能出现明显错误时,如何通过错误信息快速定位问题所在,并提出了改进错误处理和记录的建议。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

    测试人员最喜欢怎样的Bug呢?我觉得是界面明显出错的Bug。
    从开发的角度看,写更多的信息能给自己特别是测试带来便利。我测试过企业级应用,测试过私活的小应用。最头疼的就是没有任何线索的Bug。
    下面来看下这个案例:一个发布系统,在版本1的时候,自动发布和手动发布都是正常的,升级到版本2的时候,手工发布还是正常过的,但是自动发布在页面出现如下的Bug:
   

ERROR [2007-02-09 10:46:44,156] com.18m.lmw.lmwutils.dao.common.AutoPublishCommonDAO - 
[ERR]: 02/09/2007 at 02:46:44.156 GMT @ lmwpc02 (127.0.0.1);  # com.18m.lmw.lmwutils.dao.common.AutoPublishCommonDAO
[USR]: Administrator (C:\Documents and Settings\Administrator) @ C:\18m\apache\AppServer
[THD]: Thread-20 ( 77f5a9fc )
[THG]: main = { com.18m.logging.MultiFileHandler:, Thread-3, Alarm Manager, LT=0:P=276578:O=0:port=2228, LT=1:P=276578:O=0:port=2811, Alarm : 0, ServerSocket[addr=0.0.0.0/0.0.0.0,port=0,localport=8882], PoolScavenger0, Alarm : 1, Thread-9, Alarm : 2, Thread-10, ServerSocket[addr=0.0.0.0/0.0.0.0,port=0,localport=9081], ServerSocket[addr=0.0.0.0/0.0.0.0,port=0,localport=9444], ServerSocket[addr=0.0.0.0/0.0.0.0,port=0,localport=9091], ServerSocket[addr=0.0.0.0/0.0.0.0,port=0,localport=9044], Thread-12, LocalNotificationServiceDispatcher : 0, Thread-13, RT=0:P=276578:O=0:WSTCPTransportConnection[addr=127.0.0.1,port=2809,local=2242], RT=1:P=276578:O=0:WSTCPTransportConnection[addr=127.0.0.1,port=1503,local=2243], Thread-14, NotificationService dispatcher : 3, Thread-15, SoapConnectorThreadPool : 0, SoapConnectorThreadPool : 1, Thread-16, Thread-17, Thread-18, Thread-19, Thread-20, Servlet.Engine.Transports : 0, Servlet.Engine.Transports : 1, NotificationService dispatcher : 5, Servlet.Engine.Transports : 2, Thread-21, Thread-22, Thread-23,  }
[LOC]: com.18m.mm.beans.util.lmwBTraceLog:error
[MSG]: java.sql.SQLException: ORA-00933: SQL command not properly ended

错误直接在页面显示出来了:
 这种就是最喜欢的Bug:
1 从用户角度来说,即使出错也不该在页面显示错误信息,应该转到通用出错页面。
2 从最后的错误能清晰的得出是开发的存储过程的分号出了问题。
3 最好是把错误写到Log,比如Log4J等包需要应用在这里,帮助分析。

不说Log4J的4种Log Level,18m公司规定的几个规定我真是觉得实用,以至于到了别的公司我仍然怀念那种清晰的命名制度:
1 各个组件在出错的时候有各自独立的缩写:
2 每个错误都是个组合体
  THD 表示线程,THG,USR,LOC以及MSG等等
3 每个错误有独立的错误代码,每个产品都有独立的Error Message 红皮书随着产品发布。
4 每个错误都生成自己的Dump,方便送给Dev去分析出错的状态以及发生的原因。

这比我在这之后遇到那种错误信息全无的,全靠SQL Job调用的错误要方便到天上去了。不得不佩服18m的管理制度。这不是一个天才程序员或者测试员能办到的。这就是18m的组织过程资产,也是18m能傲气于服务行业的最大原因。

希望有志于打造国产利器的某些公司也能有类似的规范。



来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/9562545/viewspace-748702/,如需转载,请注明出处,否则将追究法律责任。

转载于:http://blog.itpub.net/9562545/viewspace-748702/

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值