测试人员最喜欢怎样的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/