努力的去做好一件事,那也许就叫做成功^_^

发布新日志

  • 测试转开发

    2007-09-20 15:53:30

       

       工作快半年了,毕业快三个月了,做测试也快半年了,在这半年的测试生活里,感觉不好也不坏,日子就那样过,没有感觉,收获也不大,现在的能力是:可以写功能测试用例,可以做黑盒测试,知道了测试流程.

       个人体会是学不到什么东西,感觉做测试没什么意思,是重复了再重复,工作就是一个水平面,公司的测试流程是混乱的,有的时候竟然是更新一个bug后,也要换包!天啊,每天点鼠标.像个呆子!就象黑盒测试的定义一样,你不需要知道软件的内部结构,我们只关心它能不能完成这个功能.每天打开网站,"什么测试职业的前途,没有技术含量,环境造成低人一等,测试人员的困惑!"我觉得特别的不便服.这种环境让我感觉压抑,我希望我刚工作就是这个样子,我有能力去改变.于是我决定转开发!

       当然,上面我讲的有可能太过于偏激,但是那确实是我的工作感受.我想测试工程师要求其实还是挺高的,要站得比开发人员更高.在测试的过程中我也学到不少的测试知识,方法,技巧,我想如果我转测试的话,一定会做的更好,写出更优秀的代码.也许以后我会再杀回来呢,呵呵,来个回马枪!

     

      

      

  • 两个月的测试生活和收获

    2007-09-07 17:51:04

       上班快两个月了,感觉没学到什么东西.感觉公司的测试流程相当的混乱,软件产品出来只是做了功能方面的测试,看一看功能能不能执行,流程能不能走得通就行了.什么性能方面的测试也不做靠感觉.呵呵

    感觉有点无聊,来了个新包就要重复原来的动做,拜托能不能用一下ROBOT之类的软件进行一下回归测试.可是公司没有人会啊!感觉现在会工具的高手现在还没有见到过,只是在网上看到几个N人在讲,不过他们讲的我大多都不懂,很想学习,觉得有前途.

    编程能力不是太强,好好学,方向是java ,比较的感兴趣.最近没事就拿我们测试的这个项目的源代码来看看,还真能看得的懂,只不过如果让编起来可能就太困难了,还有就是对j2ee的整体构架不是太清楚.

    学了点关于oracle方面的东西.以前以为多么深奥的东西,其实数据库都是一样的东西,不过oracle的测试服务器还真的很难搭建.搞了好长时间没弄好,找开发帮弄的,也不知道为什么.想研究一下.

    还有最近回去没事,玩起了单机版的 游戏:大航海时代,呵呵,觉得挺好玩.一定程度的影响了自己学习java的时间.

    好了,一个星期又快要过去了,感觉时间真的很快呀,

    现在回头看了一下全文一点逻辑都没有,讲出来也挺开心,在写的过程中总结了这段时间的收获,不错对以后的工作和学习都有好处.希望以后要坚持!

    祝看到我的贴子的测试朋友,天天 开心,享受测试的快乐!

     

     

     

  • 态度决定你的“薪”情

    2007-08-15 10:53:35

     我的同事C,也是我的好朋友,跳槽去了一个正在迅速发展的IT公司,年薪翻了一倍。而他,从准备找工作到工作敲定,仅仅一周。二十万的年薪,在IT行业,对于不到五年工作经验的人来说,是一个很不错的收入了,我的同事自然也很开心很满足。我的其他同事,还有我的朋友,听说后,都非常羡慕,觉得他的运气很好。我也觉得他的运气不错,但除了运气外,我更多地觉得,他具备了这样的实力,所以当机会来了,自然就是他的了。我也会觉得,他的实力,源于他的态度,源于他一点一滴的积累与提升。
      

      在与C合作的两年多的时间,我们的合作非常愉快,虽然存在异议,但是所有的争议都是为了把工作做得更好。我们的第一次合作,是一个短信过滤模块,产品出来后,是一个初步的原型,根据我对SMS的理解、业务的需求和维护方便,给他提了很多不错的建议,对于我所提的建议,他没像其他开发那样讨价还价,几天之后又交给我一个比较完美的产品。

      对产品的测试,我非常挑剔,不满足于简单的需求,在产品满足了功能需求后,继续进行了深入的测试、改进和性能调优;产品试行后,继续跟进产品在实际环境的运行情况,对产品进行二次完善,所有的这个过程,C都非常配合,力求完美,毫无怨言。最终,他开发的这个产品,是我们SMS系统中,功能最完善、故障最少的产品。如果当初,没有他积极的配合,也许,这个产品也像其他的产品一样,只是一个普通的模块,我再努力也是徒劳。
      

      在05年春节,我们的P2P系统出现了很大的故障,故障的原因无法定位也无法重现,当时整个团队都承受了很大的压力,我自己也在想方设法定位问题解决问题。那段时间,C给了我非常大的帮助,我们在一起讨论问题可能产生的原因,在交换各自的见解,每有一个新的想法就测试问题是否重现,同时配合代码白盒检查,将问题一个个地解决。我们都很清楚,这些隐藏的问题,仅仅靠一个开发或测试是很难定位的,需要的是一个配合良好的团队的努力。在后来的性能调优中,我提了很多建议,别的开发都没时间去做优化,是C主动接过了别人负责的模块,积极地配合我对P2P进行了长达两个月的性能调优与隐患挖掘,P2P最终成了一个从05年底到现在都无任何来自于软件的故障。现在再翻开我们合作完成的P2P性能调优报告,整整50页,每个改进都密密麻麻地写满了我们各自的原因追踪、改进建议和结果分析,现在再看,我自己还会感动。我想,这样的工作态度,是成就了他年薪翻倍的主要原因。
      

      在他刚进入公司的时候,回复bug也跟其他同事那样只是简单地写上“fixed”或“ok”,我对他说:“回复bug的时候,最好能够写上产生bug的原因、解决的方法、升级的步骤以及这个改动引起哪些变动,方便测试进行模块升级和问题跟踪,也方便以后维护管理。”从此以后,他所有的bug回复都非常详细、专业。但,我其他的同事,同样的话我重复了N次,部门经理也发邮件要求大家去遵循,但是没几个同事能够像C那样自觉、认真的地回复,也没几个同事可以坚持两年多来一直都是那样认真地回复每个bug。我想,这就是人与人之间的差距,从这么一件简单的事情上,可以看到不同的人的工作态度。我们在羡慕别人得到了好机会的青睐,以为这只是运气,但事实上,运气的背后,是他的付出。

      现在,当我们再回头查看两年前C所负责的bug,对于每一个问题,都可以从他的回复中看出当初问题产生的原因以及解决方法,对于公司来说,这无疑是一笔财富。我的这个同事,并不是一个非常聪明的人,也不是一个很能说会道的人,却是一个勤奋、认真的人,也是一个知道自己要的是什么的人。在项目不紧张的时候,他会主动去研究公司的核心产品,尽管那不是他所负责的,但他的主动为他积累了基础,也为他积累了机会;他甚至还会去学习与IT毫不相干的法律,为了维护自己的合法权益。他知道上班时间,也知道下班时间,上班的时候全部投入认真工作,但下班之后就很难得在公司找到他的影子。因为他觉得,下班了,就是自己的时间了,应该回家跟家里人一起分享。我非常欣赏他的这样的一种工作状态,也非常欣赏他的生活态度。公司的人才保留机制做得不好,他来公司两年工资的提高并不是很大,但他还是坚持以学习的态度认真做好他的工作,当他所负责的项目接近了尾声,他觉得自己的努力付出并没有得到相应的回报,所以决定离开。他知道自己的英文口语并不太好,没有像我那样一心坚持进管理完善的外企;因为决定了要离开,他也不像别人那样,边工作边找工作;他看中了一间正在迅速发展的公司,请了10天的年假,开始了他的应聘之路,而他也真的幸运,一周不到,就收到了他想去的公司的offer,当然,最令人兴奋的是他想去的公司满足了他二十万年薪的要求。


      同事C去新的公司上班将近一个月了,我的其他同事和朋友说起他新的工作,仍然羡慕不已,但我会觉得,这不仅仅是因为他的运气,而是因为在过去的几年中,他努力的付出、认真的学习、塌实的工作,当然,更重要的是他清楚自己需要什么,也努力去争取自己想要的。我的身边,很多人都会在抱怨自己工资不高,也有很多人抱怨自己没有机会,但是,他们很少在自己的身上去找原因,只是将一切归于运气。我很想对他们说,你是否觉得C的运气很好?那你是否也像C那样在好运降临之前主动、认真、塌实地做好每一件事情?


      其实,机会,并不是天上掉下来的馅饼,而是抓住机会的本事。当你历练出了抓住机会的本事,好运自然降临。

  • 测试人员应该如何报bug【转】

    2007-08-15 10:48:19

       首先,确保你所发现的问题是确实是一个bug,不要出现因为测试人员操作错误或配置错误所引起的“bug”,这样会降低你在开发人员心中的可信度。在测试的时候,如果发现测试的实际结果与预期测试结果不符时,不要着急马上报bug,先想想为什么会出现错误。作为专业的测试人员,应该能够对出现的问题进行跟踪,确认了在配置、操作没有错误的前提下,通过追踪分析确认所测试的业务流程确实是存在bug,并能大概对bug的产生原因进行定位。测试人员,需要做到专业,尽量少给开发找麻烦,不要制造实际上并不存在的bug。
        确认了所发现的问题是一个bug之后,按照测试步骤再执行一次,确保bug是可重现的而不是随机的。如果bug不能重现,应该尽量找到bug重现的规律,在一些比较难重现的问题可以找开发配合一起查找原因,如果还是无法重现则需要在bug report中对出现的问题描述清楚并说明出现的随机性。
        接下来就是填写bug report了,在填写bug report的时候,最重要的是bug的标题和bug描述。在bug报告中,首先用一句话对bug进行简要精确的描述作为bug的标题,让开发或项目经理一看就知道存在什么问题,比如“XX模块在压力测试2小时后出现内存泄露”。而在bug的描述中,需要使用简明准确的语言描写出现bug的测试步骤、实际的测试结果、预期的测试结果和结论;也就是说描述导致出现bug的操作步骤是怎样,由测试步骤所做的操作引起的测试结果是什么,而预期的结果应该是怎样,并由实际结果与预期结果相对比说明问题所在。比如:“在管理网页新增用户,当新增的用户登录名名称很长(例如登录名长度为输入框允许的最大长度),按‘新增’按纽新增后系统提示已经有该用户存在,而事实上该用户并不存在,建议对超长的用户名进行处理。”
        在测试人员发现了一个已隔离的,可重现的问题后,应该对问题进行归纳。同一个问题是否出现在其他的模块或其他的流程?同一个故障是否会引起更加严重的问题?如果存在,也需要提出来让开发一并处理。
        在开发对bug进行修改之后,测试需要报着怀疑的态度认真地对问题进行验证,需要严格按照测试步骤来进行测试,检查开发是否已经正确修改了所出现的问题,以及开发对bug进行了修复之后是否会引进新的问题。不要相信开发说“已经修改好了,肯定没问题了”就不对问题进行细致的检查了,如果开发修改得不彻底,问题仍然会存在的,或者可能会由于开发在修改bug的时候忽略了另一些细节导致了新bug的出现。尽量不要在关闭bug之后,才发现这个问题还没有修改彻底;也不要出现bug关闭之后,出现了新的bug。
        测试对bug进行验证确认已经修改ok之后,关闭bug。在关闭的时候,应该对Bug最终修改结果进行简要描述,如果bug的修改引起配置或数据库或业务流程的变更,也需要在bug关闭描述中进行说明。

数据统计

  • 访问量: 8006
  • 日志数: 15
  • 建立时间: 2007-08-15
  • 更新时间: 2007-09-26

RSS订阅

Open Toolbar