一个人不应该依附在其他人身上,一个人应该首先自力更生。你应该自己能够独立,能够安顿你自己,那你就不会害怕了。你爱你自己的话,别人不能不爱你吧。

发布新日志

  • 一位软件工程师的6年总结

    2008-03-27 17:01:34

     一位软件工程师的6年总结   文章指数:0  CSDN Blog推出文章指数概念,文章指数是对Blog文章综合评分后推算出的,综合评分项分别是该文章的点击量,回复次数,被网摘收录数量,文章长度和文章类型;满分100,每月更新一次。
    一位软件工程师的6年总结

    作者:成晓旭

    (声明:欢迎转载,请保证文章的完整性)

    “又是一年毕业时”,看到一批批学子离开人生的象牙塔,走上各自的工作岗位;想想自己也曾经意气风发、踌躇满志,不觉感叹万千……本文是自己工作6年的经历沉淀或者经验提炼,希望对所有的软件工程师们有所帮助,早日实现自己的人生目标。本文主要是关于软件开发人员如何提高自己的软件专业技术方面的具体建议,前面几点旨在确定大的方向,算是废话吧。

    谨以此文献给那个自己为你奉献3年青春与激情的开发团队。还有团队成员:PPL、YT、YK 、TYF、LGL、CHL、CDY、CB、DPD。

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

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

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

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

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

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

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

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

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

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

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

    13、本文的总结与反思:

    A:不要去做技术上的高手,除非你的目标如此。虽然本文是关于提高软件开发知识的建议,做技术的高手是我一向都不赞同的。你可以提高自己的专业知识,但能胜任工作即止。

    B:提高软件知识和技术只是问题的表面,本质是要提高自己认识问题、分析问题、解决问题的思想高度。软件专业知识的很多方法和原理,可以很容易地延伸、应用到生活的其它方面。

    C:在能胜任工作的基础上,立即去涉猎其它领域的专业知识,丰富自己的知识体系、提高自己的综合素质,尤其是那些目标不在技术方面的朋友。

    Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1853575

  • 小工具,用于繁琐的重复工作

    2007-07-20 17:19:35

    按键精灵 6.31

    按键精灵软件介绍
    按键精灵可以帮你操作电脑。不需要任何编程知识就可以作出功能强大的脚本。只要您在电脑前用双手可以完成的动作,按键精灵都可以替您完成。

    1.定义一个热键,实现一系列的键盘按键动作、鼠标点击动作、鼠标移动动作、输入字符串动作、延迟动作。更多的插入动作以后也会扩充。
    2.实现动作的循环,每个动作都可以进行循环,你可以定义热键中止动作的循环,也可以自己定义循环的次数或者循环的时间。
    3.所有的热键都可以对指定的窗口有效,这样就不会出现切换了窗口还自动执行动作的情况。
    4.每个热键的动作都生成一个scrīpt文件,高手可以自己编辑这个文件,实现功能强大的宏键。
     

    全能鼠标键盘记录器

    功能十分强大的脚本记录工具,可以记录您的鼠标\键盘操作的所有动作,包括鼠标的单击,双击,拖动,键盘击键,各种组合键等. 记录后可以在您以后需要的时候随时进行回放,在一些需要重复操作的场合特别有用,可以有效的节省您的时间,提高您的工作效率,如:企事业单位处理表格时进行的一些重复计算的操作,游戏里的一些练功过程,简化一些软件里的复杂操作,甚至可以做为一种辅助教学工具在计算机教育中使用,给学员演示一些软件的操作过程.


    详细功能:

    非常易于使用

    秉承丝茅草软件的以用户为中心的设计理念,鼠标键盘记录器从各方面考虑了用户的使用习惯和方便性, 动画图标式的功能操作方式让新手也能在最短时间内轻松上手。

    录制范围广

    支持各种鼠标及键盘操作的记录,包括滚轮鼠标的滚轮动作。

    录制范围可设置,非常灵活

    以选择录制脚本的范围是否仅录制键盘或是鼠标,及是否记录击键延时、是否记录普通鼠标移动过程等等。

    支持热键播放,方便实用

    每个脚本都可以设置一个对应的热键,一键操作,非常简单方便,特别允许多个脚本使用同一个热键,软件会弹出窗口给用户选择。

    方便的脚本编辑功能

    对于录制的脚本可以进行任意编辑,可以在脚本中加入一些控制命令(这些控制命令无法在录制时产生),这个功能仅在增强版和企业版中有效,标准版不含这个功能。

    支持数据库做为输入源

    可以将某一数据库中的数据做为输入的数据源,这对于录入数据的场合特别有用,这个功能仅在企业版中有效,标准版和增强版不含这个功能。

    特别支持快速脚本

    快速脚本是为需要更简单的一些场合设置的,一键即可开始录制,完成录制后随时一键开始播放,使用极为简单,快速脚本同样可以在需要的时候保存为普通脚本。

    支持脚本的密码保护

    支持脚本密码保护,不知道密码的情况下将无法对脚本进行修改和回放。

    脚本播放计划和相关启动程序

    最多可以设置8个脚本相关程序,这些程序将在播放这个脚本前运行,脚本的播放也可以通过播放计划定时进行播放。

    界面色调任意调

    软件内置多种配色方案,用户也可以定义自己的配色方案,使用更加舒适。
     
     
    我用了按键精灵,还不错。。。
     
     
    这个还没有看。。。
     
     
  • 经典故事与商务谈判(转载)

    2007-06-13 15:18:40

    原文

    测试的过程中会有大量的与研发的沟通与谈判,最近看到的,收获颇大,发文共享

    商务谈判的三步曲为我们掌握商务谈判进程提供了可以遵循的基本框架。毫无疑问,申明价值可以使我们了解谈判双方的各自需求;创造价值可以使我们达到双赢的目的;克服障碍使我们顺利达成协议。然而,我们的谈判人员往往还不能真正理解其内涵,因此,我们给大家讲一个在谈判界广为流传的经典小故事。

        有一个妈妈把一个橙子给了邻居的两个孩子。这两个孩子便讨论起来如何分这个橙子。两个人吵来吵去,最终达成了一致意见,由一个孩子负责切橙子,而另一个孩子选橙子。结果,这两个孩子按照商定的办法各自取得了一半橙子,高高兴兴地拿回家去了。

        第一个孩子把半个橙子拿到家,把皮剥掉扔进了垃圾桶,把果肉放到果汁机上打果汁喝。另一个孩子回到家把果肉挖掉扔进了垃圾桶,把橙子皮留下来磨碎了,混在面粉里烤蛋糕吃。

        从上面的情形,我们可以看出,虽然两个孩子各自拿到了看似公平的一半,然而,他们各自得到的东西却为物尽其用。这说明,他们在事先并未做好沟通,也就是两个孩子并没有申明各自利益所在。没有事先申明价值导致了双方盲目追求形式上和立场上的公平,结果,双方各自的利益并未在谈判中达到最大化。

        如果我们试想,两个孩子充分交流各自所需,或许会有多个方案和情况出现。可能的一种情况,就是遵循上述情形,两个孩子想办法将皮和果肉分开,一个拿到果肉去喝汁,另一个拿皮去做烤蛋糕。然而,也可能经过沟通后是另外的情况,恰恰有一个孩子即想要皮做蛋糕,又想喝橙子汁。这时,如何能创造价值就非常重要了。

        结果,想要整个橙子的孩子提议可以将其他的问题拿出来一块谈。他说:“如果把这个橙子全给我,你上次欠我的棒棒糖就不用还了”。其实,他的牙齿被蛀得一塌糊涂,父母上星期就不让他吃糖了。

        另一个孩子想了一想,很快就答应了。他刚刚从父母那儿要了五块钱,准备买糖还债。这次他可以用这五块钱去打游戏,才不在乎这酸溜溜的橙子汁呢。

        两个孩子的谈判思考过程实际上就是不断沟通,创造价值的过程。双方都在寻求对自己最大利益的方案的同时,也满足对方的最大利益的需要。

        商务谈判的过程实际上也是一样。好的谈判者并不是一味固守立场,追求寸步不让,而是要与对方充分交流,从双方的最大利益出发,创造各种解决方案,用相对较小的让步来换得最大的利益,而对方也是遵循相同的原则来取得交换条件。在满足双方最大利益的基础上,如果还存在达成协议的障碍,那么就不妨站在对方的立场上,替对方着想,帮助扫清达成协议的一切障碍。这样,最终的协议是不难达成的。

  • 功能测试经验

    2007-06-12 17:26:16

     
    作者:qiubole 来自http://www.cnblogs.com/qiubole

    此文旨在以检查单的形式,对于一些没有设计测试用例,而进行快速功能测试提供指导。

    一、刚进窗口时的测试
    1、  每次打开窗体,都要先关闭,再打开一次。对一个窗体测试完了之后,也要关闭后再进入一次。

    2、  进入窗体后,要先检查一下窗体的各种情况,很多程序员,喜欢在创建或显示的时候写代码。

    3、  先检查一下界面上的布局是否合理。一般公司都有检查单,就按检查单的内容来进行检查一次。如果是界面布局不合好的,在提交问题的时候请尽量客气点,程序员就那点怪脾气,整个一审美盲,做得不好,还不太愿意别人提。

    4、  进入之后,先别急着按照说明书去操作,先把能点的,能录的,能拖的都试试,如果涉及到一些可以双击操作的,也没事多双击试试。一般建议,将窗体上所有的按钮都点点,多点几次,花不了多少时间。

    二、针对各种控件的测试。
           在程序中,有各种各样的控件,特别是在我们的CS程序中,用到很多系统标准的控件,对于标准控件的测试,在此列出,如果自定义的控件,后面再详细列一份,比如我们自己的录入控件。

    1、  按钮:一般使用按钮,主要是为了执行一系列的事件,在按钮上,大部分只用到了它的单击(CLICK)方法,我们要注意到这么几点。

    a)         如果按钮用来管理状态的,比如,点击按钮,打开,再点击,则关闭这类的,请多点击几次。

    b)        如果按钮是用来执行一系列的较长的事件的,则请连续点击,很多程序员不会注意到这一点,快速点击几次,可能就会出问题。

    c)        删除按钮,如果按钮是用来删除数据的,请确认点击时,是否有提示,而且提示是否明确,很多时候,程序员为了懒一下,提示往往不明确,比如‘您确认要删除它吗?’之类的,其实是不标准的,标准的应该是‘你确认要删除[0001]号单据吗?’这样一类的。其它的提示请参考检查单。

    d)        保存按钮,一般保存按钮,建议是用普通的按钮或可以获得焦点的按钮,如果你发现用的是不能获得焦点的按钮,比如平滑按钮,这就要注意了,很多时候,刚录入一条数据,如果焦点未离开输入框,点击保存时,该录入框的内容是不会被存上的。

    e)         退出按钮,通常退出按钮是要用求无焦点的按钮,否则,你录入一条不合法的数据,想退出时,很有可能会被拒绝,要求你输入正确的数据,这就很郁闷了。

    f)         其它,正常情况下,每点一个按钮,界面上都需要进行响应,如果你点击一个按钮,界面没有任何反应,这就要提醒开发者了。当然,有些公司规定默认是不响应的,其实这是不太合理的。

    2、  单选框:一般情况下,在一组相关的单选框中,一定要有一个默认值,很多程序员会在这里面加上一系列的状态,比如选择第一个单选框,则改变状态,普通情况下出错的可能性不大。

    3、  复选框:复选框的作用是可以重复选择,如果复选框选择之后,将其它的复选框清除了,这时候就要注意向开发人员确认了,因为正常情况下,复选框是不允许这样操作,要这样操作,需要用到单选和复选的结合。

    4、  标签:对于标签的测试,是比较简单的,主要把握这两个方面。

    a)         一是标签的位置,是否与之相关的项目对齐。在一个页面上,如果标签和输入框比较多的情况下,经常会出现位置相差1个象素的情况。

    b)        二是标签的焦点,有些标签上,会有加速键列表,比如(员工(A)),你要确认一下,按了Alt+A之后,它对应的焦点是否落在它之后的可获得焦点的控件上。

    5、  日期和时间控件:日期选择控件本身是不会出什么问题,但是,与之作用相关的地方,比如根据日期条件进行查询,默认日期时间等会出问题,从以下几个方面考虑。

    a)         短日期格式,有一些人在写程序的时候,经常会将日期转换为字符串进行比较,如果经验少的人,会把1990-1-1日变成‘1990-1-1’,这在进行比较的时候可能会出问题,尽量要求开发人员在系统启动的时候,改变系统的短日期格式,使之在日期选择的时候,为‘1990-01-01’这种。

    b)        很多语言,用的日期控件,和时间控件是同一个控件,比如(DELPHI),如果开发人员没留意,在进行日期比较的时候,可能就存上了时间了。这样就会导致数据出问题,测试的时候,要把握边界值的方式,比如查询2号到10号的数据,你要想办法,试一下1,2,3,9,10,11这几个值了。

    c)        如果日期控件显示的是1899-1-1号,这就要注意了,这表明这个日期没有赋初始值,如果这是一个数据敏感控件,则很可能没有给相应的数据集赋上值。

    d)        当然,我们可以强烈建议,程序员给日期控件赋上默认值,当前日期,当前月份的第一天之类的。

    e)         成组的日期,比如开始日期和结束日期,这里我们要注意,开发人员是否控制了结束日期必须大于开始日期。

    6、  编辑框:很多时间,这是出问题的主要来源,对于编辑框,我们可以从以下方面考虑,其中一些可以对开发人员进行建议。

    a)         录入的类型:根据录入的类型不同,测试方法也有所不同,这里给出常见的几种。

                             i.              纯字符录入

    1.         长度,比如名称,要注意,该名称的长度,如果是敏感控件,这一点可以不用考虑,因为控件本身就管理了,如果是非敏感控件,则要注意这一点,否则很有可能就会出现字符被截断的问题。

    2.         非法字符,这主要是指一些特定语言的一些转义符,比如\001,之类的,在delphi中,要注意’号,在VB中,要注意”号。同时,如果系统有特殊要求的话,则有时,空格也是不允许的。

                           ii.              整型的录入,有一些要求必须输入整型的地方,要注意以下几个方面。

    1.         非数据和-号,是否能录入字母,其它符号之类的。

    2.         最大值和最小值的控制

    3.         0和非0值,在很多业务逻辑中,必须要输入大于0的数,看是否控制到位了。

    4.         是否能用Ctrl+V键进行粘贴,很多人写代码的时候,会根据敲的键来将非法字符过滤(这可以不用管,很多时候,可以不考虑这点)。

    5.         退格键,方向键,删除键是否能用。

    6.         是否能输入小数。

                          iii.              浮点型,和整型前面五点相似,另要补充几点。

    1.         是否能输入多个小数。

    2.         小数的位数

                         iv.              日期和时间:看是否能录入正确的日期和时间,离开后应该要判断,其它同上面的日期和时间控件。

    b)        取值范围:这就是我们运用黑盒测试中,等价类划分和边界值的最好时机了。详细的就不在这里列了。

    c)        系统判断的时机:一般一讲,我们会要求开发人员,在该控件离开时,判断输入的值是否合法。但有很多程序员,只是在按回车键的时候提示,这样就有问题了。

    d)        与回车键的关系问题:这也是经常出问题的地方,很多程序员要求在输入值后,按回车,然后会取出另一些相关的值,如果我们敲回车之后,系统取出值,我们再回过头来改这个输入框的值,最后保存时,就会有逻辑问题了。

    7、  下拉框。下拉框作为一种录入或选择手段,在很多情况下,它的取值范围,判断时机和回车键的关系与上面的编辑框类似,在此不复述。另要注意几点。

    a)         是否允许手工录入的问题,很多下拉框是不允许手工录入的。如果允许手工录入了,看系统是否控制了该录入值的取值范围。

    b)        如果之前你测试的时候,是允许手工录入的,程序员改了一次之后,它是不允许手工录入的,你就要注意了,特别是面对DELPHI程序,要特别注意,赋值和取值是否正确。

    8、  列表框。要注意以下几方面。

    a)         是否允许编辑,大部分列表框应该是禁止编辑数据的。对一个节点,点一次鼠标,稍停一会,再点一次鼠标,就会能看到是否可以编辑。

    b)        是否可以复选。

    c)        拖动,很多列表框有拖动方面的功能,这时要注意,它拖动的目标,有时候把它拖动到本身,就会出错。

    9、  树。在有层次结构的情况下,经常会用到树,我们要注意以下几个方面。

    a)         是否允许编辑,大部分树应该是禁止编辑数据的。对一个节点,点一次鼠标,稍停一会,再点一次鼠标,就会能看到是否可以编辑。

    b)        拖动,很多列表框有拖动方面的功能,这时要注意,它拖动的目标,有时候把它拖动到本身,就会出错。同时,将上一个节点拖放到它的子节点应该也是不允许的。

    c)        不选择树的节点:如果程序中用到了树的节点,这时候你不选择节点,有时候也会是报错的来源。

    d)        选择非子节点,如果程序中要求你选择子节点,而你未选择。

    e)         树的刷新,有时候,一个树是与当前录入的数据有关的,这时候要查看一下,新增了数据,树是否正常刷新了,删除了数据,更新了数据也同理。

    10、              多行文本框,注意以下情况。

    a)         回车是否被转移焦点了

    b)        如果这是一个SQL语句查询录入框,还要注意,是否能录入DELETE, UPDATE, DROP之类的DCL语句。也就是安全问题。

    c)        最大字符数问题。

    11、              数据表格,很多程序中,用到了大量的表格,在表格中我们要注意这么几点。

    a)         如果只是显示查询结果的表格,要注意,该表格是否是只读,是否可以用Ctrl+delete之类的删除数据。

    b)        如果是可编辑的,那么请查看,如果能够点击表头排序,还是否能正常录入数据。

    c)        是否能录入重复的数据。

    12、              打开和保存对话框:主要是查看是否有扩展名过滤,默认路径。

    13、              图表:无限放大和无限缩小。
  • 16个月的工作感想 (转载)

    2007-06-06 15:40:20

    原文

    从去年6月底开始正式做软件测试以来,我个人经过了很多阶段。从一开始的网站功能测试,到后来开始接触ERP,做了LR性能测试,然后开始做WR的自动化,到这时候大概半年时间去掉了。之后做了2个月的C#开发,在自动化测试方面用QTP开始逐渐替代了WR。然后我调到了市区“前线”工作。开始着手做NUNIT单元测试和基于.NET开发环境下的LR压力测试代码编写及面向Oracle存储过程的性能测试。06年7月,我开始担任测试管理的角色,开始从事培训新人,安排测试任务,与开发协调测试任务方面的工作,直到今天。我写这篇总结的原因,是由于自己对测试工作的职业发展开始感到迷茫,对技术发展没有方向。

    我个人认为,我上班16个月以来所走过的路,是比较合理的。这样的路建立的经过测试专业培训的基础上(个人感觉,新人接受专业培训是很有必要的),否则可能先需要在基础方面努力3个月左右。基于对测试的正确理解以及对各种测试工具的了解,在正式工作中可以快速的应用上去。

    下面说下我认为“菜鸟”应有的发展路程。

    测试新人应该从系统手工测试开始,首先应该对整个软件的开发流程(软件工程)有正确的认识,了解测试工作在整个开发流程中的切入点和所起的作用。就项目而言,测试是其中的一部分,想要做好系统测试,首先应该学会怎么看SRS(需求规格说明书),对需求的正确理解将直接影响你的用例设计。其次,是用例设计的方法,这包括很多种,我就不多说了。主要的一点是,看SRS所设计的用例可能不全面,在实际测试过程中,应该从系统的操作中继续发现应该测试的点。另外,对于测试用例和BUG的编写,应该规范,清晰。出色的完成你的初测。其次,当开发修改完BUG之后开始复查时,首先你需要明白一个名词,它就是:版本。然后你开始复查BUG,如果时间允许,我强烈建议你重新执行所有用例,以防万一。

    当你的系统测试做的“炉火纯青”的时候,你应该开始了解配置管理,质量保证,CMM以及一些开发上的相关知识。这可以巩固你对整个项目流程各个环节的了解,让你对他们有全面正确的认识。我认为这一点,很重要!

    之后,公司的测试水平开始升华,你的经理发现,总是复查BUG是一件多么耗费时间和人力的事情啊!他开始要求做自动化测试。这时候你就应该加入其中。对于自动化测试怎么做法我就不仔细说了,东西太多,我自己目前可能处于中级应用阶段,大家可以去51testing上看相关帖子了解一下。需要说明的是,自动化虽然好,但是不可能替代手工测试。另外,它不适用于一些小项目,对于小项目来说,上自动化所带来的项目成本,将远大于手工测试。

    在自动化测试过程中,你可能需要自己去写一些脚本。这就需要对编程有一定了解。在这里我想说,会编程不是测试人员必须会的技能,但是,不懂编程将不会成为一个高级测试人员,它会成为你发展的一个绊脚石。我在做程序员的2个月中,学到了很多,它会影响你对系统的认识,拓展你的测试思路,增强你对数据库的了解。在这个阶段中,我建议你有空时学习相关网络拓扑,系统架构,数据库的知识,为将来打下基础。

    做到这样我可以说,这个人已经是测试方面的中高级人才了。当然,如果你想做技术全能选手,那就开始接触性能测试和白盒吧。我认为这两个是高阶的玩意。

    在性能测试领域,我是只会用LR,关于怎么学我不想说,自己找资料。需要说明的是,性能测试有两个难点。第一,是对面向被测系统的认识,如何确认到底需要监控测试哪些性能点的问题。第二,是对于测试出来的结果,能否正确分析找出瓶颈的问题。这两面都需要大量的工作经验,以及对系统,网络等各方面的深刻认识。这是一个具有挑战性的工作。

    在白盒测试方面,首先你要懂编程,要写过程序,其次,你要会使用相关工具实现测试过程。基于代码级的测试和系统测试在理念上是差不多的,你也需要对被测的方法或者基类设计测试用例,然后用测试代码去实现它。这是一个自己构造输入参数,执行代码并获取结果的过程,有兴趣学习的自己找资料看去吧!在每日构建方面我没有做过,所以也不好多说什么,别误导了大家,我只能说,每日构建是每天对配置库中的代码进行自动的单元测试,确保每天配置库中得下得代码是编译可通过的一个过程。

    当你在技术上有了一定造诣,你得到了领导的赏识,可能你会步入测试管理的行列。强力的技术背景将成为你做领导的支柱,但不是全部。我想说的是,做测试管理和做技术完全不是一回事,管理基本关注两点,一是成本,二是进度。在确定这两点是可控的情况下,可以说你的管理工作是合格的。你的技术背景为你提供了如下的好处:第一,手下人对你的信服;第二,有利于和开发方沟通;第三,协助解决技术难题;第四,强力的自信。这一切都为实现控制成本和进度提供保障。这方面我就不多说了,我自己做这个时间也不长,大家自己摸索一下吧。

    做任何事情都是没有止境的,不论是系统测试,自动化测试,性能测试,单元测试还是测试管理(当然还有做配置管理和质量控制的),都有需要继续学习的东西。目前国内没有超级牛的人带领大家在技术和发展方向上奔走,大家可能都是在爬行。当你在某个领域做到一定程度的时候,你会发现走到了瓶颈点,无法继续提高。这个是无法避免的问题,我给大家一个偏激但可行的方法,那就是跳槽。新的环境会带给你新的思路和活力。测试需要学习的东西太多太多,以上说的都是纯软件方面,我自己现在仍然不熟悉JAVA方面以及类似UNIX之类的操作系统,如果你做的是通信或其他方面的测试工作,你还需要掌握这方面的知识,实在是有的学,我相信经过3年的磨练,应该可以成为一个较为成熟的测试工程师。另外,前面提到了做CMO和SQA的方向,这个和做纯测试工作是不同的发展方向,CMO的工作我太熟悉,不过SQA实在又是一个博大而又精深的领域,据我所知,国内这方面的牛人很少,精英QA可以和PM相媲美,他对项目成功的贡献是巨大的,好像大多这类人是做了PM或系统分析员多年的人转做的。在这方面就不深入探讨了。

    补充一点,公司的流程不可能像你学到的那样完美和规范,不要奢求,尽量去改善它才是你要做的。另外我想说下待遇问题,我建议新手不要太计较这个,也许你在51testing培训花了10K(不清楚现在具体价格,只是假设),你觉得自己从那培训出来已经是个牛人了,你要马上把你的投资赚回来。其实这么做实在是想法有问题,首先,你即使培训了,其实你仍旧是菜鸟,其次,中国人太多,人力资源不值钱,除非你是高级人才。新人在第一年不应该计较工资,而应该关注对方单位将会带给你的工作环境和发展潜力。讲工资的时候,应该在2-3年以后,需要强调的是,英文实在重要,我确实的体会,只是我太懒,一直不肯好好学,大家千万别学我啊!

    以上是我个人的一些观点,大家随便看看吧,说错了我可不负责啊 ^_^
    另外,我目前对于个人职业发展也比较迷茫,哪个牛人看了对我有所建议,请不吝赐教。。。。
                                                    胡  睿
                                            2006年11月18日星期六

Open Toolbar