发布新日志

  • 失散的51,我回来了

    2012-09-18 20:04:05

    好长一段时间没有来论谈了,为什么呀?
    细细想,工作忙是主观的理由还是自己不愿意来充电呢/
    终于回来了,我忠爱的51.
    这个职业我从事多年了,一直在默默的工作着,不断的完善着自己 。
  • 一位软件测试工程师六年的工作经验总结

    2011-08-29 20:19:51

    看到一篇文章很喜欢,跟大伙分享下;原文地址http://bbs.51testing.com/viewthread.php?tid=95214&extra=page%3D1%26amp%3Bfilter%3Dtype%26amp%3Btypeid%3D11

    1分享第一条经验学历代表过去、能力代表现在、学习力代表未来其实这是一个来自国外教育领域的一个研究结果。相信工作过几年、十几年的朋友对这个道理有些体会吧。但我相信这一点也很重要:重要的道理明白太晚将抱憾终生!所以放在每一条,让刚刚毕业的朋友们早点看到哈!

    2
    一定要确定自己的发展方向,并为此目的制定可行的计划。不要说什么,我刚毕业,还不知道将来可能做什么?跟着感觉走,先做做看。因为,这样的观点会通过你的潜意识去暗示你的行为无所事事、碌碌无为。一直做技术,将来成为专家级人物?向管理方向走,成为职业经理人?先熟悉行业和领域,将来自立门户?还是先在行业里面混混,过几年转行做点别的?这很重要,它将决定你近几年、十年内做什么事情才是在做正确的事情!

    3
    软件开发团队中,技术不是万能的,但没有技术是万万不能的!在技术型团队中,技术与人品同等重要,当然长相也比较重要哈,尤其在MM比较多的团队中。在软件项目团队中,技术水平是受人重视和尊重的重要砝码。无论你是做管理、系统分析、设计、编码,还是产品管理、测试、文档、实施、维护,多少你都要有技术基础。算我孤陋寡闻,我还真没有亲眼看到过一个外行带领一个软件开发团队成功地完成过软件开发项目,哪怕就一个,也没有看到。倒是曾经看到过一个高学历的牛人”(非技术型)带一堆人做完过一个项目,项目交付的第二天,项目组成员扔下一句再也受不了啦!四分五裂、各奔东西。那个项目的成功度大家可想而知了。

    4
    详细制定自己软件开发专业知识学习计划,并注意及时修正和调整(软件开发技术变化实在太快)。请牢记:如果一个软件开发人员在12年内都没有更新过自己的知识,那么,其实他已经不再属于这个行业了。不要告诉自己没有时间。来自时间管理领域的著名的三八原则告诫我们:另外的那8小时如何使用将决定你的人生成败!本人自毕业以来,平均每天实际学习时间超过2小时。

    5
    书籍是人类进步的阶梯,对软件开发人员尤其如此。书籍是学习知识的最有效途径,不要过多地指望在工作中能遇到世外高人,并不厌其烦地教你。对于花钱买书,我个人经验是:千万别买国内那帮人出的书!我买的那些家伙出的书,!00%全部后悔了,无一本例外。更气愤的是,这些书在二手市场的地摊上都很难卖掉。拥有书籍并不表示拥有知识;拥有知识并不表示拥有技能;拥有技能并不表示拥有文化;拥有文化并不表示拥有智慧。只有将书本变成的自己智慧,才算是真正拥有了它。

    6
    不要仅局限于对某项技术的表面使用上,哪怕你只是偶尔用一、二次。对任何事物不究就里是任何行业的工程师所不应该具备的素质。开发Windows应用程序,看看Windows程序的设计、加载、执行原理,分析一下PE文件格式,试试用SDK开发从头开发一个Windows应用程序;用VC++、DelphiJava.Net开发应用程序,花时间去研究一下MFCVCLJ2EE.Net它们框架设计或者源码;除了会用J2EEJBossSpringHibernate等等优秀的开源产品或者框架,抽空看看大师们是如何抽象、分析、设计和实现那些类似问题的通用解决方案的。试着这样做做,你以后的工作将会少遇到一些让你不明就里、一头雾水的问题,因为,很多东西你知其然且知其所以然
     
    7
    在一种语言上编程,但别为其束缚了思想。代码大全中说:深入一门语言编程,不要浮于表面。深入一门语言开发还远远不足,任何编程语言的存在都有其自身的理由,所以也没有哪门语言是包治百病灵丹妙药。编程语言对开发人员解决具体问题的思路和方式的影响与束缚的例子俯拾皆是。我的经验是:用面对对象工具开发某些关键模块时,为什么不可以借鉴CC51、汇编的模块化封装方式?用传统的桌面开发工具(目前主要有VC++Delphi)进行系统体统结构设计时,为什么不可以参考来自Java社区的IoCAOP设计思想,甚至借鉴像SpringHibernateJBoss等等优秀的开源框架?在进行类似于实时通信、数据采集等功能的设计、实现时,为什么不可以引用来自实时系统、嵌入式系统的优秀的体系框架与模式?为什么一切都必须以个人、团队在当然开发语言上的传统或者经验来解决问题???他山之石、可以攻玉

    8
    养成总结与反思的习惯,并有意识地提炼日常工作成果,形成自己的个人源码库、解决某类问题的通用系统体系结构、甚至进化为框架。众所周知,对软件开发人员而言,有、无经验的一个显著区别是:无经验者完成任何任务时都从头开始,而有经验者往往通过重组自己的可复用模块、类库来解决问题(其实这个结论不应该被局限在软件开发领域、可以延伸到很多方面)。这并不是说,所有可复用的东西都必须自己实现,别人成熟的通过测试的成果也可以收集、整理、集成到自己的知识库中。但是,最好还是自己实现,这样没有知识产权、版权等问题,关键是自己实现后能真正掌握这个知识点,拥有这个技能。

    9
    理论与实践并重,内外双修。工程师的内涵是:以工程师的眼光观察、分析事物和世界。一个合格的软件工程师,是真正理解了软件产品的本质及软件产品研发的思想精髓的人(个人观点、欢迎探讨)。掌握软件开发语言、应用语言工具解决工作中的具体问题、完成目标任务是软件工程师的主要工作,但从软件工程师这个角度来看,这只是外在的东西,并非重要的、本质的工作。学习、掌握软件产品开发理论知识、软件开发方法论,并在实践中理解、应用软件产品的分析、设计、实现思想来解决具体的软件产品研发问题,才是真正的软件工程师的工作。站在成熟理论与可靠方法论的高度思考、分析、解决问题,并在具体实践中验证和修正这些思想与方式,最终形成自己的理论体系和实用方法论。

    10
    心态有多开放,视野就有多开阔。不要抱着自己的技术和成果,等到它们都已经过时变成垃圾了,才拿出来丢人现眼。请及时发布自己的研究成果:开发的产品、有创意的设计或代码,公布出来让大家交流或者使用,你的成果才有进化和升华的机会。想想自己2000年间开发的那些Windows系统工具,56年之后的今天,还是那个样子,今天流行的好多Windows系统工具都比自己的晚,但进化得很好,且有那么多用户在使用。并且,不要保守自己的技术和思想,尽可能地与人交流与分享,或者传授给开发团队的成员。与人交换苹果之后,每个人还是只有一个苹果;但交换思想之后,每个人都拥有两种思想,道理大家都懂,但有多少人真正能做到呢?

    11
    尽量参加开源项目的开发、或者与朋友共同研制一些自己的产品,千万不要因为没有钱赚而不做。网络早已不再只是虚拟世界,网上有很多的开源项目、合作开发项目、外包项目,这都是涉猎工作以外的知识的绝好机会,并且能够结识更广的人缘。不要因为工作是做ERP,就不去学习和了解嵌入式、实时、通信、网络等方面的技术,反过来也是一样。如果当他别人拿着合同找你合作,你却这也不会,那也不熟时,你将后悔莫及。

    12
    、书到用时方恨少,不要将自己的知识面仅仅局限于技术方面。诺贝尔经济学奖得主西蒙教授的研究结果表明:对于一个有一定基础的人来说,他只要真正肯下功夫,在6个月内就可以掌握任何一门学问。教育心理学界为感谢西蒙教授的研究成果,故命名为西蒙学习法。可见,掌握一门陌生的学问远远没有想想的那么高难、深奥。多方吸取、广泛涉猎。极力夯实自己的影响圈、尽量扩大自己的关注圈。财务、经济、税务、管理等等知识,有空花时间看看,韬光养晦、未雨绸缪。

    13
    、本文的总结与反思:

    A
    :不要去做技术上的高手,除非你的目标如此。虽然本文是关于提高软件开发知识的建议,做技术的高手是我一向都不赞同的。你可以提高自己的专业知识,但能胜任工作即止。
    B
    :提高软件知识和技术只是问题的表面,本质是要提高自己认识问题、分析问题、解决问题的思想高度。软件专业知识的很多方法和原理,可以很容易地延伸、应用到生活其它方面。
    C
    :在能胜任工作的基础上,立即去涉猎其它领域的专业知识,丰富自己的知识体系、提高自己的综合素质,尤其是那些目标不在技术方面的朋友。

  • 测试最需要的是淡定

    2011-08-29 20:12:10

     The best tester is not the one who finds the most bugs or who embarrasses the most developers. The best tester is the one who gets the most bugs fixed.

      最好的测试者并不是那些找到最多BUG的人,或者是那些困扰了最多开发者的人,而是那个得到最多BUG FIXED的人。偶尔看到了一句话,觉得写的很好。

      最近学会了一句话,叫淡定,感觉有时候还是蛮受用的。这个淡定更是有其中的玄妙之处。

      BUG对于测试来说很微妙。你觉得有,它就有bug,只要你足够细心,你可以认真得去校验每个点,甚至关联的,去计较每个不用测的点,每个你与开发观点不一致的BUG。你觉得没,就没有,睁一只眼闭一只眼,把测试用例给过一遍。或者说直接提bug,不管是否是有效BUG,提给开发去校验就是了。

      测试需要一份耐心,一次次的执行相同的用例,也需要一份良好的心态。有人说BUG就像一面镜子,你对她笑她就笑,你对她哭最后就你一个人哭。切记要用好的心态对她。

      测试是以发现BUG为目标,但不是用于标榜自己的成就感,需要秉持以项目质量的态度。在任务紧张的状态下,需要淡定,不能敷衍行事;在环境宕机的时候,需要淡定,不能把问题归咎到环境就大事化了;在BUG手指脚趾加起来都数不清楚的情况下,需要淡定,不能捶胸顿足,怨声怨道;一个BUG都没有的项目,需要淡定,不能就这么和项目大眼瞪小眼的,非得找个BUG出来;在工作比较轻松的时候,需要淡定,要安排好时间,不能虚度。

      测试不能浮躁的“跑路”,初步测试的道路更是如此。需要一份淡定的心态,去发现BUG,去解决BUG。

      测试之于态度,测试是锤炼态度的好工作;态度之于测试,态度是推使测试有效进行的好工具。

  • [转]和51testing一起走过的日子

    2011-05-09 15:19:22

  • [转载]测试的价值不仅仅是找Bug

    2009-11-12 20:01:12

    测试的价值不仅仅是找Bug

    字体:        | 上一篇 下一篇 | 打印  | 我要投稿  | 每周一问,答贴有奖

      在我测试工作的前5年,一直以为测试的目标和价值就是在黑盒测试活动中找bug,以找到bug越多越自豪。但当我随着商业意识的不断积累,跳出测试的视角,站在公司的角度看测试时,会发现测试的目标是商业成功,而不仅是找bug。商业成功的关键是什么?简单点说就是可以长期地稳定获得大量的客户并获得足够的利润。而要想长期稳定的得到客户的喜爱,就必须提供让用户满意的质量,这是测试找bug的初衷。可是商业成功要解决的“大量的客户”,“足够的利润”,如何由测试来保障呢?

      “大量的用户”的获得有时关键就是看谁的产品先推向市场,先占领市场。因此一个词“TTM——Time to Market”就是非常重要的,测试应该支撑项目在满足质量目标的条件下能及时地推向市场,而不是拖延产品的发布进度。

      “足够的利润”就要确保成本越低越好。减少研发人力:减少开发人力和测试人力;减少研发时间:减少开发修改bug的时间和减少测试活动时间;就能帮助产品减少成本,提高产品的利润。

      项目成功的铁三角:质量,成本,进度。每一个关键因素都需要测试人员来做出贡献和支撑。如果仅仅只找bug,可能只支撑了质量,甚至有时也并未真正保障了客户想要的质量。那么测试如何支撑项目成功的成本和进度呢?这时需要的就不仅仅是自动化测试,虽然自动化测试能起到一定的效果。但更需要具有商业意识的测试领导者,站在公司的角度思考选择做正确的测试决策。

      下面就以一个案例来证明测试如何更大地发挥其应有的商业价值:

      如果一个项目有10个功能:3个功能支撑性能,3个功能支撑可靠性,2个功能支撑可用性,2个功能支撑基本功能。(客户最关心:可靠性,不太在意性能和可用性)

      测试如何支撑项目获得更短的研发周期和更低的研发成本:

      反面案例:

      一个测试思考简单化的测试经理,可能要求10个测试人员进行10个功能的全面测试。1个测试人员的生产力为:1个功能需要10天测试完成,1天发现1个bug。10个测试人员用了10天时间完成了测试,并在每个功能发现了10个bug,一共100个bug。

      1个开发人员的生产力为:1天修复1个bug。100个bug需要10个开发人员修改10天。

      总结:重点功能50个bug,开发人力:100人天。测试人力:100人天,项目用时:20天。

      正面案例:

      一个真正了解客户需求,理解公司商业利益的测试经理做了如下决策:用10个测试人员,2个人一组重点测试可靠性的3个功能和2个基本功能,用时5天,每个功能发现10个bug,重点功能共发现50个bug。其余5个非重点功能的测试工作量可以减少一半,用时2.5天,每个功能发现5个bug,非重点功能共发现25个bug。 开发人员10人,修改75个bug,用时7.5天。

      总结:重点功能50个bug,开发人力:75人天,测试人力:75人天,项目用时:15天。

      从以上数据可以看到,只需要测试经理或测试架构师多用一点时间来思考,以公司最终目标:“在保障满足客户需求质量的前提下成本更低,进度更快”为自己的工作目标。避免大而全的唯bug论,就可以发现在重点功能质量标准不下降的前提下,可以实现开发和测试都节省了25%的研发成本和25%的研发进度。

      测试如何支撑项目获得更高质量的同时有更短的研发周期和更低的研发成本:

      测试经理做了如下决策:用10个测试人员,2个人一组重点测试可靠性的3个功能和2个基本功能,每个功能发现15个bug,重点功能共发现75个bug,用时7.5天。其余5个功能的测试工作量可以减少为1/4,用时1.25天,每个功能发现2.5个bug,非重点功能共发现12.5个bug。 开发人员10人,修改87.5个bug,用时8.75天。

      总结:重点功能75个bug,开发人力:87.5人天,测试人力:87.5人天,项目用时:17.5天。

      从以上数据可以发现在同样的测试人力和开发人力情况下,最应该保障的重点功能发现了更多的bug,为原方案的150%,必须重点关注的地方的相对质量得到了提升,而研发成本下降为87.5%, 研发进度减少了2.5%。

      本文通过一个简单的案例故事,说明了测试的价值不仅是找bug,只要我们测试工作追求科学的思考,而不盲目的干活,那么我们测试执行活动也能在提高关键质量目标的同时,帮助公司降低研发成本,减少研发时间,全面真正支撑公司商业成功所必须的:更快的进度,更低的成本,更高的质量。

      希望我们广大测试人员能从平时的测试工具研究使用和测试脚本开发过程中多抬头思考,选择正确的事来做,做到事半功倍。要相信测试人员能创造更大的商业价值,而不仅仅是bug。

  • 个人测试路该怎样走好?

    2009-06-25 20:07:06

    个人测试路该怎样走好?


    我从事测试工作近10年了,测试经历好下,可是工资不高5K左右,一直想给自己找个合适的充电的机会及充电的方法。
    我中专毕业,专业不对口,先进入一家电视企业做测试工作,刚开始是做制造的过程控制,后面又做出货检查,且做过一段时间的组长,只因不会处理人系关系,后面就离开了制造中心,调入了研发中心工作了。后面调入同一公司的研发中心从事DQA的测试工作,即性能检查,就是从客户的角度去检查电视机的质量,在这里工作了七年多,可是工资一直上不去。
    后面通过努力拿到了助工的资格证书,拿到了大专文凭,也是由于家庭的原因,被迫离开了公司,后面经朋友介绍到了一家软件公司从事软件测试方面的工作,职位是测试工程师,在这里我学到了很多东西,但是发现是年轻人的天地,在这里薪水也较高了,可公司裁员时,领导想到了我,没有办法我成了牺牲品。
    现在又来到了一家公司的研发部门从事软件测试,给的是助工的,也就是4K的薪水,真是越走越低了呀。
    现在很想为自己充电,很想知道自己该如何发展,根本也找不到自己的职业规化路,想知道该如何走好自己的职业路。
    希望各位大侠指点一下,像我这种状态,有工作经验,没有理论的人,该如何来发展。
Open Toolbar