发布新日志

  • 失散的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。

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

  • Android自动化测试初探

    2011-06-23 20:12:34

    Android自动化测试初探

      入职两月有余,从之前的android app开发到现在的测试框架开发,工作中遇到很多问题,趁这次机会分享一下。

      Android自动化测试目前可借鉴的经验不多,现在采取的方式就是通过java代码对Activity和View进行操作,目前已知的入口是Instrumentation类。

      Instrumentation与Activity均位于android.app包下,这个包内还有诸如ActivityManagerNative这种不对App层开放的类,通过查看Android源码发现Activity类中诸如startActivity(Intent intent)这样重要的方法都是通过Instrumentation实现,Instrumentation中也提供了一系列对Activity生命周期控制的方法。以Instrumentation为基础,Android SDK在Junit基础上进行了扩展,提供了AndroidTestCase类及系列子类,其中最重要的一个类是ActivityInstrumentationTestCase2。

      基于Instrumentation的测试框架的工作原理SDK中的这张图说明的很清楚了:

      研究Android源码发现框架层中有很多对测试有帮助的类、方法都被加上了@hide注解或是声明为private的,无法从app层访问。自然而然我们想到了java的反射机制, java反射允许我们访问这样的类和方法。

      在上面的基础上,国外有人开发出了Robotium工具,可以在有app源码或apk的情况下进行自动化黑盒测试

      但是Robotium目前的缺点也很明显,无法对WebView进行操作,这对大量使用WebView的淘宝Android客户端来说无疑是很大的限制。

      而且Robotium提供的API是面向过程的,测试代码的可扩展性差。

      我们需要一个面向对象的,可对WebView进行操作的自动化测试框架,这就催生了TMTS(Taobao Mobile Test Studio)框架。

      TMTS立项时还试图着重解决另一个问题,就是Instrumentation框架下testapp和app运行在一个进程中 ,app crash会导致testapp一并crash。当时和士敦一起研究了Instrumentation、Activity的启动流程,甚至想去研究一下dalvik是如何解析Manifest文件的,最后也没有想到好的方法,收获就是了解了android更底层一些的细节,这个问题现在先搁置了起来。

    从测试代码方面来看, Robotium中采用的是actionMethod(View, arg)的方式,TMTS中采用getView(id).actionMethod(arg)的方式,更加符合java的编程习惯。TMTS测试代码的编写也就是分三步,找到View,调用View的相应的action方法,断言。

      TMTS框架主要思想就是通过反射机制调用Android框架层API拿到当前Activity的所有View,在此基础上返回需要获得的View对象,对获得的View通过Instrumentation封装一些此View常用的操作,最后返回,这就是TmtsView及其子类。

      这种方式缺点也很明显,对每个从android.View继承来的子类,如果其中有特殊的操作,就需要封装出一个对应的TmtsView子类。

      还有一个缺点就是目前是通过View在布局文件中声明的id去寻找,这样测试人员在编写代码时需要对app的源码非常熟悉,了解当前操作的view的id是多少,在传递id参数时还有可能写错。之后我们对这个方式进行了一些改进,使用SDK自带的hierarchyviewer工具获得view的id;对每个布局文件进行解析生成java类,这个类中会提供方法返回布局文件中的所有带id的view,经过讨论,最后按view子类型来对一个布局中的view进行归类。

      现在测试代码从getView(id).actionMethod(arg)演变成了Layout(layout.class).ViewType().view().actionMethod(arg)的方式,代码虽然变长了,但是出错的可能性大大降低了。

      Bug的定位离不开日志,因而日志系统也是一个测试框架重要的组成部分,Android的Log类中提供了一系列的静态方法可以在IDE中打印日志。在TMTS中,提供TmtsLog类,除日志打印外可将日志内容实时保存至SD卡指定目录,在框架代码中的关键部位都加上了这样的日志用来保存异常时的调用栈信息,用户的测试代码中也可以加上对TmtsLog的调用跟踪测试代码执行进度,TmtsLog将为每个测试类保存一份这样的日志文件,同时包含用户的过程日志和框架异常日志,文件名以精确到毫秒的日期加以区分。

      项目做到这里远远没有结束,套用屈原的一句话就是路漫漫其修远兮。

      后面计划解决的问题有:

      1.跨进程测试,让testapp和app运行在两个不同的进程中,这是一个大坑。

      2.稳定性问题,目前框架中有很多地方硬编码Thread.sleep()去等待一个View加载完成,避免对空的View进行操作,或者是对一个view进行set操作后,也需要等待一段时间让操作生效。希望能找到一种回调机制优雅的解决。

      3.设法捕获Toast消息

      后面可能会研究的方向,是通过非java的方式来实现android自动化测试。Android目前已经通过ASE(Android Scripting Environment)支持了多种脚本语言,如phyton,lua,perl等,限于目前的人力还没有时间来研究这一块,相信ASE会给Android自动化开辟一片新天地。

      最后谈一点点感悟,老子曾经曰过:“持而盈之,不如其已;揣而锐之,不可长保。金玉满堂,莫之能守;富贵而骄,自遗其咎。”和“重为轻根,静为躁君。”第一句话说有缺陷才是真正的完美,没有一个方案是真正完美的。第二句话说有时候看起来完美的方案,过段时间之后又不适用了,而且不适用的地方很可能就是当初觉得完美的地方,对于软件项目解决方案也是如此。

      分享到此结束,敬请期待士敦下次关于WebView方面的分享。

  • 测试老兵的唠叨

    2011-06-20 17:50:40

    测试老兵的唠叨

      作为一个测试老兵,写点唠叨的话,给测试新人一些参考,也作为自己的一个纪念。

      1)测试人员或团队不能保证软件的质量

      很长的时间以来,测试人员总是被看做是“质量保证”人员,但作为一个超过10年的一线测试老兵来说,从心而论,测试人员或团队却不能保证高质量的软件产品。为了说明这个观点,我举几个例子。大家可能都知道,软件产品的最初版本(Version 1),通常来说都是由很多质量问题(Bug),这是一个非常普遍的现象,小公司的软件产品是这样,大公司的软件产品也是这样的。难道是Version 1软件产品没有测试人员么?还是测试人员的水品不行?显然都不是。另外一个现象就是,很多成熟的软件产品也会出现很多质量问题,例如很多大型软件基本上每个月都与补丁以及安全漏洞。那么到底是什么原因呢?其背后的根本原因是测试人员无法保证软件产品的质量。有了测试团队,并非一定能够解决质量问题,并非一定能够保证软件质量。有了好的测试团队,也未能够百分百保证软件的质量。再举一个类比的例子,现在所有的房屋建设都有监管机构,但是豆腐工程仍然是层出不穷,显然监管机构不能绝对保证质量。

      2)测试人员的价值在哪里?

      既然测试人员不能保证质量,那么测试人员的价值在哪里呢?我也曾经多次问过自己,最后我总结出测试人员的价值在于为产品开发提供有价值的质量反馈。这里面的”有价值“,应该体现为深入的,系统的和犀利的见解(Insights),另外这些见解应该和软件质量息息相关,这些都是质量保证的一个重要环节。而质量保证本身是由整个项目组共同努力的目标或结果,而绝非测试人员能够独自保证的。对于日常的测试活动,例如功能测试性能测试和安全性测试等等,这些活动的目标都是为质量提供有价值的反馈:反馈包括不同的层次和类型,例如产品缺陷(Bug),设计优化建议,用户体验反馈等等;从大类来说可以分为产品属性,用户体验和流程优化三个方面。

      测试人员提供的价值和医生为病人提供的价值很相似:医生为患者提供了关于健康的有价值的反馈,但是不能保证病人一定能被治愈。医生会做很多检查工作,就像软件质量的度量指数;医生开的方子就像测试人员提供的质量反馈一样。

      另外,测试人员往往产品的专家,同时也是非常了解客户,所以测试人员的见解往往非常有价值,而且是独特的。

      3)测试人员的职责

      讨论清楚了测试人员的价值后,再谈谈测试人员的职责就比较容易了。总的来说,质量保证的任务是一定的,无非来说有些有开发人员来做,有些是测试人员来做,有些是项目经理来做,没有统一明确的分工,每个团队都有自己的特点。这种分工通常没有一个确定的模式。影响这种分工的包括人员的特长和开发测试比例等因素。举例来说,据谷歌测试总监介绍,谷歌公司的开发测试比例为10:1,微软的测试总监也“微软测试之道”中提到微软的开发测试人员通常为1:1 到2:1之间。据我所知,很多的软件公司也基本上也2:1-3:1之间。因此,测试人员的职责在各个公司各不相同。比如说,在10:1的公司,我相信测试人员是不可能有时间为项目写具体功能测试用例或性能测试用例等,那么这种测试人员可能会在更高层次上提供质量反馈,比如说质量保证流程,需求审查等等。因此,无论哪种公司,测试人员的价值都应该是一致,就是有价值的质量反馈。这

      种价值应该得到团队的认可和确实帮助了产品质量的保证。

      4)测试人员的发展

      测试人员发展和开发人员发展类似,分为管理路线和工程师路线,管理路线包括测试主管,测试经理,测试总监等;工程师路线包括工程师,高级测试工程师,测试架构师等等。但是从公司的需求来说,绝大部分公司对于测试总监和测试架构师的需求都不是很多,其主要原因是大部分软件产品的复杂性,高级测试经理带领团队就足以实现提供质量反馈的价值。对于测试架构师的需求也是一样,只有当系统足够复杂,才有业务的需求,举例来说在微软Windows和搜索都有自己的测试架构师。

  • [转]和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-07-17 09:29:16

    灰盒测试

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

      一直想找一灰盒测试方面的书及在网上找一些灰盒测试的方法及例子来给我部门的人讲讲,但一直没有找到好的资料,想想,还是把自己理解的一些灰盒测试相关的知识整理一下。

      灰盒测试的概念,在网上找了一下,觉得百度百科上写得不错,摘抄如下:

      “灰盒测试,确实是介于白盒测试黑盒测试之间的,可以这样理解,灰盒测试关注输出对于输入的正确性,同时也关注内部表现,但这种关注不象白盒那样详细、完整,只是通过一些表征性的现象、事件、标志来判断内部的运行状态,有时候输出是正确的,但内部其实已经错误了,这种情况非常多,如果每次都通过白盒测试来操作,效率会很低,因此需要采取这样的一种灰盒的方法。

      灰盒测试结合了白盒测试和黑盒测试的要素。它考虑了用户端、特定的系统知识和操作环境。它在系统组件的协同性环境中评价应用软件的设计。

      灰盒测试由方法和工具组成,这些方法和工具取材于应用程序的内部知识和与之交互的环境,能够用于黑盒测试以增强测试效率、错误发现和错误分析的效率。

      灰盒测试涉及输入和输出,但使用关于代码和程序操作等通常在测试人员视野之外的信息设计测试。”

      灰盒测试我的理解,灰盒测试是运用工具及开发知识,寻找软件黑盒的测试点。 灰盒测试属于黑盒测试的一部分,也是对一个黑箱子进行测试,只是灰盒测试点增加黑盒测试路径,也是黑盒测试人员的更高的境界。

     灰盒测试是要运用一些开发知识的,大家都认为要去学习开发知识。网上很多论坛也有人说做测试之前,最好要有一、二年的开发经验就比较好。做为黑盒测试人员,如果会当然好,但是大部分黑盒测试人员是没有开发经验,这里我谈谈黑盒测试人员学习什么,怎么去学习。

      1、多看、多分析、多总结缺陷

      测试人员应该多去看别人的发现的缺陷,特别是一个模块后,你测试完成后,别人再测试,心里一定要多问他为什么可以发现这些缺陷,你没有发现。多分析缺陷发生的原因,是由于开发人员业务不是很了解,还是在设计的问题,还是开发人员态度的问题。可以分类汇总发现的缺陷,也可以总结开发人员常犯的缺陷。

      2、和开发做朋友,充分交流。

      当发现一个缺陷时,我们应该了解缺陷发现的原因及一些原理。这些缺陷发现的原因只有开发人员很清楚,需要他跟你讲解。只有多和开发人员交流,你对缺陷发现的原因慢慢了解,你的水平才会得到提升。

      3、了解数据库结构及学习数据库知识

      在界面上你看不到的一些字段,往往是造成一些非常难发现的缺陷,因为这些字段是用来做控制作用。也可以利用数据库知识进行SQL注入。

      4、学习工具

      可以利用一些工具,方便我们去了解开发相关的知识,比如:Charles能够让我们查看所有网络和机器之间的HTTP流量情况。包括请求、响应、HTTP头信息(包含cookies和缓存)等。

      我觉得从上面四个方法着手,应该可以提高自己的水平。有人会问我要不要学习一门开发语言,如果有时间、有能力学当然好,但是不学习也没有关系。我觉得很多缺陷都是逻辑上、或者设计上没有考虑清楚造成的。 灰盒测试是要运用一些开发知识的,大家都认为要去学习开发知识。网上很多论坛也有人说做测试之前,最好要有一、二年的开发经验就比较好。做为黑盒测试人员,如果会当然好,但是大部分黑盒测试人员是没有开发经验,这里我谈谈黑盒测试人员学习什么,怎么去学习。

      1、多看、多分析、多总结缺陷

      测试人员应该多去看别人的发现的缺陷,特别是一个模块后,你测试完成后,别人再测试,心里一定要多问他为什么可以发现这些缺陷,你没有发现。多分析缺陷发生的原因,是由于开发人员业务不是很了解,还是在设计的问题,还是开发人员态度的问题。可以分类汇总发现的缺陷,也可以总结开发人员常犯的缺陷。

      2、和开发做朋友,充分交流。

      当发现一个缺陷时,我们应该了解缺陷发现的原因及一些原理。这些缺陷发现的原因只有开发人员很清楚,需要他跟你讲解。只有多和开发人员交流,你对缺陷发现的原因慢慢了解,你的水平才会得到提升。

      3、了解数据库结构及学习数据库知识

      在界面上你看不到的一些字段,往往是造成一些非常难发现的缺陷,因为这些字段是用来做控制作用。也可以利用数据库知识进行SQL注入。

      4、学习工具

      可以利用一些工具,方便我们去了解开发相关的知识,比如:Charles能够让我们查看所有网络和机器之间的HTTP流量情况。包括请求、响应、HTTP头信息(包含cookies和缓存)等。

      我觉得从上面四个方法着手,应该可以提高自己的水平。有人会问我要不要学习一门开发语言,如果有时间、有能力学当然好,但是不学习也没有关系。我觉得很多缺陷都是逻辑上、或者设计上没有考虑清楚造成的。

  • [转载]资深软件测试工程师必备知识

    2009-07-09 20:44:45

    做了这么久测试,最近又换了工作,结合以前的工作经验和面试心得,总结了资深测试工程师必备的技能,希望自己能够2年内在这些方面都有提高:
    1.测试理论知识
    有了理论知识做指导,才能对整个测试领域有一个各方面的认识,从而找准方向自己向哪方面努力;否则,连测试需要的技能和方向都不知道,怎么进步呢?
    2.开发经验能够提高很大的竞争力(优先级最高-重要不紧急)

    3.数据库知识和技术能力(优先级最高-重要不紧急)
    最普及使用的是oracle数据库,应多掌握;

    4.pl/sql开发技能,和sql的运用(优先级高-重要不紧急)
    5.网络知识(优先级高-重要不紧急)
    能够给软件环境搭建测试或生产环境;

    6.配置管理知识
    有了上面2,3,4,5的基础,学习这部分应该可以很快入门;
    7.操作系统unix,linux技能
    unix命令,能够写脚本

    8.较强的英语口语也会提升很大的竞争力
    每天中午看英语新闻,听听力.融入生活学习过程.

     

    自己的实际情况:

    最近三个月的精力主要放在java教程,oracle技术上;

    每天抽1小时学习java教程;

    每天抽1小时学习oracle知识;

    发现总是不经意的在网上随便闲逛一下,一晚上甚至一天的时间就过去了.
    自控力很弱的情形下,默认的就把网线拔掉了,需要查资料的时候再上网.

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

    2009-06-25 20:07:06

    个人测试路该怎样走好?


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

    2009-06-18 19:21:14

    1. 测试和开发网站:http://www.boobooke.com/
    2. 测试网站:http://www.51testing.com
    3. 测试中国论坛:http://www.testingcn.com/
     
     
    5. 豆豆网:http://www.ddvip.com/
  • 好的测试职业发展文章

    2008-10-18 11:52:58


    测试职业规划


    内容如下:
    作为一名测试新人加入团队,大多数情况下,项目组成员都是一种热情欢迎的态度,并且主动提供力所能及的支持和帮助,如何快速熟悉项目业务和测试环境,尽快投入到实际工作中去,我谈谈个人的经验和一些看法,供同行参考:


    1
    、寻找新公司的团队元老:

      
    一般来说,一个新人进入新公司,都要指定一个师傅带一段时间,这也就是我们说的测试前辈。很多时候,测试前辈都是经验非常丰富的测试高人,如何您和他相处融洽,关系不错,凭他个人丰富的业务经验,给您指点迷津,也许会比你自己摸索10倍的时间效果还好。很多的测试新手,刚进入新公司时,自高自大,眼高收低,测试前辈都不愿意交,结果到了试用期转正答辩的时候,一问三不知,被迫离开公司,被炒鱿鱼。这样的例子我看到的不下于10例,很可惜丢失了很多工作机会。

    2
    、虚心的学习态度:

    刚到一家新公司,保持谦虚的学习态度非常必要。记得我刚毕业那年,公司招聘了一个测试主管,他有45年的工作经验,阅历算是不简单,也是我们心目中的牛人吧。但是那个人,除了听总监的话以外,对于我们部门的其它人来说,他简直是自高自大,目中无人,根本不把部门里的其他人放到眼里,觉得部门的人都不如他。他作为一个空降兵,老员工和新员工,对他都很冷漠,碰到什么问题,需要小组成员帮忙的时候,大家都不愿意帮助他,互相推诿,并且经理也找他谈了几次话,效果不明显,结果他呆了不到2个月,估计是自己觉得很不开心,被迫离开了公司。其实,保持低姿态,谦虚的学习态度,必不可少。

    3
    、阅读项目相关的文档:

      
    一般来说,新人一到公司,就会安排到项目中去。作为测试新手,快速阅读相关的需求文档详细设计文档用户手册特别关键。我们能够通过需求规格说明书等文档,快速熟悉系统相关的知识,获取编写测试文档的相关信息。如果项目已经编好了用户手册,您完全可以根据文档的步骤,一步一步傻瓜式的熟悉每项功能。只有掌握的这些文档的精髓,测试才会变得异常轻松呀。

    4
    、快速熟悉项目相关业务知识:

    刚到新公司的测试人员,如果你是跳槽到以前做过的相近行业,有丰富的经验了,那么您熟悉业务没什么大的问题。如果您换的新公司是您以前都没有接触到的行业,那你一定得努力一点,买些相关的业务知识看看非常必要。我深有体会,以前从一家通讯公司跳槽到做银行系统的公司,业务完全两样,很多业务知识都是从零开始。不过有一定的工作经验,学习起来也挺快,关键取决于个人是酷爱学习和坚强的学习毅力。

    5
    、尽快介入了解被测试系统:

       
    刚跨入一家新公司,如果被测试系统已经开发的差不多了,部分功能已经OK了。你可以部署到测试环境下,尝试从直观测试的角度去尽快了解系统,尽快结合文档熟悉起来。很多的时候,通过页面操作实际的系统比看文档效果好的多,并且印象更深刻,熟悉系统更快。新加入公司的朋友不防试一试。

    6
    、了解公司类似的相关产品:

       
    大多数的公司,都不可能在每个行业都非常强,基本上都是在某一个较小的领域很强势,公司主要就是研发强势相关业务的产品。所以说,相关的产品一般来说是很多的,如果要你测试的系统没有开发完毕,如果时间和条件允许,不妨先了解一下公司类似的产品,以便尽快熟悉起来。大多数情况下,公司很多的产品都是相通的,大部分的产品是在不同的客户要求下,修改了部分功能和界面而已。个人认为:了解类似的产品,也是测试新手快速熟悉产品的一条捷径。

    7
    、尽量多参加项目的各种会议:

       
    每个项目,特别是在项目的启动阶段,大会小会不断,很多时候项目组成员抱怨居多,都认为很浪费时间,耽误开发进度。如果作为测试新手的您这个时候加入,那太好了,多参加这样的讨论会。大部分时间都是在讨论项目的重点和关键,如果大家意见不一致,必然要对不一致的东西展开细节讨论,您肯定是收益匪浅。特别是对业务方面的讨论,您参加几次讨论,比您看10篇需求还强,并且理解也很透彻。如果您对需求有所了解,但是部分功能模块还有问题,就可以在讨论会上随时提出来,大家一起讨论,共同解决。如果有这样的机会,切勿放弃哟。

    8
    、阅读类似项目已有的测试用例:

       
    如果项目已经启动并进入了测试阶段,如果你在这个时候介入,通常情况下负责人都会给你提供整个项目或部分需要你测试的部分模块的测试用例。这些测试用例也是您快速上手测试的重要参考资料。如果还没有编写测试用例,你就介入了,那你就得重头开始,您可以阅读项目类似的测试用例,并结合以前项目的测试经验,根据公司相关的测试用例模板开始编写测试用例。如果在编写测试用例中碰到您不了解和很难处理的问题,您可以记入测试需求疑问表格,等部门开会时,提出来大家讨论。最好不要碰到一个问题就去问,经常打乱人家的思路,弄得别人嫌烦,那就不值了。

    9
    、查看缺陷数据库中旧有的缺陷:

       
    一般的测试缺陷跟踪系统,都是按模块来分类软件缺陷的。如果老大给你分配了测试任务,你就可以有目的的去熟悉即将测试的模块缺陷。登录系统后,对缺陷进行筛选,尝试按测试前辈的Bug描述步骤进行操作,看看是否能够重新缺陷?这种方法能够借鉴测试同行的经验,尽快发现问题,避免测试的盲目性。一来可以拓宽您的视野,避免递交类似问题的Bug或是重复的Bug,二来还可以为您快速熟悉被测试系统添砖加瓦。

    10
    、必须明白自己领导是谁:

       
    一般的员工进入公司,公司和部门领导很多,搞不清楚谁管我,碰到问题问谁?谁可以帮忙解决问题?如果真是这样那就麻烦了。部门领导臃肿的情况实在是太多了,有的公司,既有2测试经理,又有几个测试主管,还有多个项目经理和研发总监,不知道工作向谁回报,对哪个领导负责。弄得每个领导都回报,很累呀!!我的做法是:测试项目中负责领导只有一个那就是测试主管,测试主管负责安排和分配每个测试人员的工作和任务,我直接Review测试主管。如果项目中碰到有什么解决不了的问题,组内成员可以直接找我,同时我也定期加入项目参加部分测试,了解测试项目的一些进展情况,必要时还要找一些人谈心。这样,工作汇报比较简单明了,很轻松。

    11
    、熟悉与测试相关的管理软件的使用:

      
    我说的这个测试相关的软件包括缺测试需求管理软件(如TestDirectorQC)、陷跟踪管理软件(如:TestTrack ProTestDirector等等)、版本配置管理工具软件(CVSVSS,还是SVN等等),具体熟悉到什么程度,那就要看您的职位了。如果您是一般的工程师,那你就只了解一般的使用就够了,如果您是测试经理,您不仅要了解一般的使用,还要更深层次的了解软件的权限和项目的配置,因为您要作为该软件的Admin,碰到问题大部分都由您搞定呀,高工资不是那么好拿的呀,哈哈!!!如果作为新入职的您,连这些都不会,那你就得加把油了,不然到了测试启动阶段,你才开始熟悉管理软件,那么你觉的能够快速展开测试吗?

    12
    、注意沟通技巧,把握请教良机:

      
    为了尽快熟悉项目,展开测试工作,沟通技巧必不可少。您作为新入职的测试人员,尽量了解每个开发人员开发的模块和每个开发人员的性格特点,寻找一些共同语言,拉近与开发人员的距离,让他们对您产生好感。只有这样,当您碰到问题的时候,他们才会鼎立的帮助您。如果您与开发人员关系不好,看了就觉的很讨厌,那他们肯定不会帮助您的,更不原意和您配合,当您提错Bug的时候,他们就会抓住这些Bug不放,有时候还要说您什么都不懂,这样你就很郁闷,肯定呆不长久的,只有走人的份了,呵呵。特别是开发人员很窝火的时候,您更要多一些理解和宽容,切勿火上浇油,您可以给他一些表扬,给他一些鼓励。他一听准开心死了,总觉得还是您们最了解我,把您当成自己人。这个时候,你再问开发人员问题,他也许态度就不一样了,他准会仔细的给你讲解,并且以后的什么事情,他也会百厌齐烦地帮助您的,因为他觉您最了解他们,无意识的把您当成了好朋友和哥们。还有的时候,开发人员有空过来测试部门逛逛,准备和您交流时,一定要把握机会,和开发人员开开玩笑和一些必要赞赏,也能够调节和开发人员的关系。总之,这一点做起来真的很难,如果做的好,那效果确实就不一样了。

Open Toolbar