今天,晚上9点下班回住的地方,和同事一起走到10号线地铁(牡丹园站)里面,看见地铁地面上有个机子,这时候地铁还没有来,于是乎我俩就走到了地铁的指示机前,是触屏的,但是不支持多点触控,点了一点,感觉还可以!有一些方便大家的提示,比如:地铁出口附近的公交车有哪些?但是没有详细的哪一个公交车具体经过的站牌是哪些?有地铁的最早发车时间和最晚发车时间表,就在看这个的时候,发现了一个bug,13号线开往西直门的全程末班车的时间有一个居然是13:10分,感觉不太对劲,地铁怎么可能在13:10分停运呢、于是乎我就上网查地铁运营时间表!
地铁乘客信息查询系统
红色标出的是错误的时间表
公司网址:http://www.sgs.com.cn/news_show.asp?id=1414&channel=5&classid=5
网上查询正确的结果如下:
希望贵公司发现此bug,赶紧处理!
看到回龙观这一行,发现时间是23:10。
哎! ---->bug啊!这么严重的bug,数据库中插入的值肯定输入错误了,这个测试怎么测试的呢!开发人员的测试呢?QA的审批?等等!
一系列的问题都暴露出来了!软件的开发周期是多久,开发人员的测试,测试人员的系统测试,这些测试案例怎么写的??种种因素导致了以上的错误,其实生活中我们难免出错!但怎么才能避免产品出现这么显而易见的错误呢?
现在的软件行业都是抱着“短,平,快”的效率发展,很少人原因多花钱在测试身上,都是找一些刚毕业的做测试,开发也是一个人顶3个人用!软件行业的“高”起点收入下背后往往是一些苦逼的程序员在不停的加班,做事没有章法,别管用什么方法,老大只看结果。往往小公司都是这么干的。---->还所谓的敏捷开发。再来看看一些大的公司,华为,提交一个bug,要找3-4个人review,而且被review的人必须每行代码都必须讲清楚。否则就不允许提交---->入库。修改100行代码要写风险方案评估等等。这些看似浪费时间,降低我们的开发效率。但其实这种方法才是真正意义上的减少重复错误的出现。一些小的开发公司,往往忽略这些,每天的bug都忙着解不过来,哪有什么时间写风险评估?比如一些公司会开展分模块开发,往往都是每一个人单挑一个模块的大梁,在review的时候,往往别人都看不懂(甚至不熟悉他的模块的情况下),就匆匆签字提交,只是会负责任地问一声“验了吗?”往往在这种高压的工作环境下,人出错的概率会大一些。然后我们会重复解决一些已经解决的bug,一些bug是因为我们以为解决了,但是会引起另一个(甚至好几个bug)。我就遇到这种事!中国程序员的命运有部分就是是这么悲惨的!
提点意见:注意总结,提交代码尽量把这个问题搞清楚,下次在出什么问题,能很快定位到什么地方!和同事多交流,这样知识是流动的,会像一条条河流流向一个方向形成大海一样。准备一个本子,写下自己每天解决的bug,然后每隔一个月对比一下,看哪些是重复的问题?养成一个良好的习惯----多写注释!尤其在关键的地方。