日历

« 2008-12-05  
 123456
78910111213
14151617181920
21222324252627
28293031   

我的好友

统计信息

  • 访问量: 474
  • 日志数: 8
  • 建立时间: 2007-09-05
  • 更新时间: 2008-11-23

RSS订阅

我一直在哭一直在哭,哭我没鞋穿,可是有一天我发现有人没有脚。

我的最新日志

  • 软件测试新手应看的一些东西(转)

    2008-11-23

    1、Q:给测试新手的建议和指导
    A:
    http://bbs.testage.net/thread-3921-1-28.html

       http://bbs.testage.net/thread-3202-1-26.html

    http://bbs.testage.net/thread-6223-1-24.html
    http://bbs.testage.net/thread-6217-1-24.html

    2、Q:testcase 具体都包含哪些内容?
    A::
    http://bbs.testage.net/thread-3571-1-32.html

    3、Q:网管软件需要做哪些方面的测试?
    A:
    http://bbs.testage.net/thread-4208-1-31.html

    4、Q:测试工程师流程、入门、经验介绍
    A:
    http://bbs.testage.net/thread-3199-1-31.html
       http://bbs.testage.net/thread-5971-1-25.html
    http://bbs.testage.net/thread-3259-1-22.html

    5、Q:测试覆盖率详解
    A:
    http://bbs.testage.net/thread-4195-1-31.html

    6、Q:软件测试基本概念和分类
    A:
    http://bbs.testage.net/thread-3512-1-31.html

    7、Q:软件测试书籍列表:
    A:
    http://bbs.testage.net/thread-4303-1-30.html
       http://bbs.testage.net/thread-5249-1-26.html

    8、Q:单元测试概念
    A:
    http://bbs.testage.net/thread-4593-1-30.html

    9、Q:软件测试常识
    A:
    http://bbs.testage.net/thread-3173-1-30.html
          http://bbs.testage.net/thread-3172-1-26.html
    http://bbs.testage.net/thread-6110-1-25.html
    http://bbs.testage.net/thread-5988-1-25.html
    http://bbs.testage.net/thread-6121-1-21.html

    10、Q:PC测试概念
    A:
    http://bbs.testage.net/thread-4221-1-30.html

    11、Q:C/S、B/S结构的测试简介
    A:
    http://bbs.testage.net/thread-4221-1-30.html

    12、Q:安装与卸载测试
    A:
    http://bbs.testage.net/thread-3241-1-30.html

    13、Q:软件测试工程师(初中级)职业前景
    A:
    http://bbs.testage.net/thread-3759-1-27.html

    14、Q:关于黑盒测试
    A:
    http://bbs.testage.net/thread-5523-1-26.html
    http://bbs.testage.net/thread-5522-1-26.html
    http://bbs.testage.net/thread-5524-1-26.html
    http://bbs.testage.net/thread-3721-1-22.html

    15、Q:有关压力测试
    A:
    http://bbs.testage.net/thread-6038-1-25.html

    16、Q:如何设计编制软件测试用例
    A:
    http://bbs.testage.net/thread-6031-1-25.html

    17、Q:测试设计中需要考虑的测试类型
    A:
    http://bbs.testage.net/thread-6153-1-24.html

    18、Q:测试工具大全[转帖]仅供参考
    A:
    http://bbs.testage.net/thread-6234-1-24.html
    http://bbs.testage.net/thread-7488-1-21.html

    19、Q:有关自动化测试
    A:
    http://bbs.testage.net/thread-6198-1-24.html

    20、Q:测试术语
    A:
    http://bbs.testage.net/thread-6827-1-23.html
    http://bbs.testage.net/thread-6037-1-23.html
    http://bbs.testage.net/thread-6341-1-22.html

    21、Q:Bug汇总
    A:
    http://bbs.testage.net/thread-6828-1-21.html
  • 为什么想做测试,测试是做什么的,你要做哪种测试,那你怎么看待测试呢?(转)

    2008-11-23

    我跟一个六年工作经验的前辈聊天时她问的“我不知道你为什么想做测试,测试是做什么的,你要做哪种测试,那你怎么看待测试呢,测试是一种要求策略,能力和自豪感的职业,我对我所做的就很有自豪感。”

      我也对此苦思了好久,终究没有我要的答案,如是我上网搜索了一些值得学习和有助今后找工作面试都有用的答案。下面是我的整理13条定律:

    1、测试是做什么的?
      如果是专业的测试人员的话,那软件测试的工作就相当复杂了,首先制定测试计划是势在必行的,包括测试的起始结束时间,在什么时间要有什么进度,之后就是进行各个测试环节,单元测试——集成测试——系统测试——验收测试。这里边前两步是用到白盒测试,后两步需要的是黑盒测试。
      如果是找测试方面的工作的话,那一开始我相信问得不会很深,但是基础肯定是要知道的,就是什么是黑白盒测试,建议测试文档包含的必须部分等等吧,都是很基础的。


    2、软件测试类型都有哪些?测试类型的区别与联系?
      测试类型有:功能测试,性能测试,界面测试。
      功能测试在测试工作中占的比例最大,功能测试也叫黑盒测试。是把测试对象看作一个黑盒子。利用黑盒测试法进行动态测试时,需要测试软件产品的功能,不需测试软件产品的内部结构和处理过程。采用黑盒技术设计测试用例的方法有:等价类划分、边界值分析、错误推测、因果图和综合策略。
      性能测试是通过自动化测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试,两者可以结合进行。通过负载测试,确定在各种工作负载下系统的性能,目标是测试当负载逐渐增加时,系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接收的性能点,来获得系统能提供的最大服务级别的测试。
      界面测试,界面是软件与用户交互的最直接的层,界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作,起到向导的作用。同时界面如同人的面孔,具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉,相反由于界面设计的失败,让用户有挫败感,再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。
      区别在于,功能测试关注产品的所有功能上,要考虑到每个细节功能,每个可能存在的功能问题。性能测试主要关注于产品整体的多用户并发下的稳定性和健壮性。界面测试更关注于用户体验上,用户使用该产品的时候是否易用,是否易懂,是否规范(快捷键之类的),是否美观(能否吸引用户的注意力),是否安全(尽量在前台避免用户无意输入无效的数据,当然考虑到体验性,不能太粗鲁的弹出警告)?做某个性能测试的时候,首先它可能是个功能点,首先要保证它的功能是没问题的,然后再考虑该功能点的性能测试。

    3、请试着比较一下黑盒测试、白盒测试、单元测试、集成测试、系统测试、验收测试的区别与联系?  黑盒测试:已知产品的功能设计规格,可以进行测试证明每个实现了的功能是否符合要求。
      白盒测试:已知产品的内部工作过程,可以通过测试证明每种内部操作是否符合设计规格要求,所有内部成分是否以经过检查。
      软件的黑盒测试意味着测试要在软件的接口处进行。这种方法是把测试对象看做一个黑盒子,测试人员完全不考虑程序内部的逻辑结构和内部特性,只依据程序的需求规格说明书,检查程序的功能是否符合它的功能说明。因此黑盒测试又叫功能测试或数据驱动测试。黑盒测试主要是为了发现以下几类错误:
      1、是否有不正确或遗漏的功能?
      2、在接口上,输入是否能正确的接受?能否输出正确的结果?
      3、是否有数据结构错误或外部信息(例如数据文件)访问错误?
      4、性能上是否能够满足要求?
      5、是否有初始化或终止性错误?
      软件的白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看做一个打开的盒子,它允许测试人员利用程序内部的逻辑结构及有关信息,设计或选择测试用例,对程序所有逻辑路径进行测试。通过在不同点检查程序状态,确定实际状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。白盒测试主要是想对程序模块进行如下检查:
      1、对程序模块的所有独立的执行路径至少测试一遍。
      2、对所有的逻辑判定,取“真”与取“假”的两种情况都能至少测一遍。
      3、在循环的边界和运行的界限内执行循环体。
      4、测试内部数据结构的有效性,等等。
      单元测试(模块测试)是开发者编写的一小段代码,用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言,一个单元测试是用于判断某个特定条件(或者场景)下某个特定函数的行为。
      单元测试是由程序员自己来完成,最终受益的也是程序员自己。可以这么说,程序员有责任编写功能代码,同时也就有责任为自己的代码编写单元测试。执行单元测试,就是为了证明这段代码的行为和我们期望的一致。
      集成测试(也叫组装测试,联合测试)是单元测试的逻辑扩展。它的最简单的形式是:两个已经测试过的单元组合成一个组件,并且测试它们之间的接口。从这一层意义上讲,组件是指多个单元的集成聚合。在现实方案中,许多单元组合成组件,而这些组件又聚合成程序的更大部分。方法是测试片段的组合,并最终扩展进程,将您的模块与其他组的模块一起测试。最后,将构成进程的所有模块一起测试。
      系统测试是将经过测试的子系统装配成一个完整系统来测试。它是检验系统是否确实能提供系统方案说明书中指定功能的有效方法。(常见的联调测试)
      系统测试的目的是对最终软件系统进行全面的测试,确保最终软件系统满足产品需求并且遵循系统设计。
      验收测试是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪,并且可以让最终用户将其用于执行软件的既定功能和任务。
      验收测试是向未来的用户表明系统能够像预定要求那样工作。经集成测试后,已经按照设计把所有的模块组装成一个完整的软件系统,接口错误也已经基本排除了,接着就应该进一步验证软件的有效性,这就是验收测试的任务,即软件的功能和性能如同用户所合理期待的那样。


    4、做好测试用例设计工作的关键是什么?
      白盒测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果;
      黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。不可能做到完全测试,以最少的用例在合理的时间内发现最多的问题。

    5、测试计划工作的目的是什么?测试计划工作的内容都包括什么?其中哪些是最重要的?
      软件测试计划是指导测试过程的纲领性文件,包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。借助软件测试计划,参与测试的项目成员,尤其是测试管理人员,可以明确测试任务和测试方法,保持测试实施过程的顺畅沟通,跟踪和控制测试进度,应对测试过程中的各种变更。
      测试计划和测试详细规格、测试用例之间是战略和战术的关系,测试计划主要从宏观上规划测试活动的范围、方法和资源配置,而测试详细规格、测试用例是完成测试任务的具体战术。所以其中最重要的是测试测试策略和测试方法(最好是能先评审)。

    6、做好测试计划工作的关键是什么?
      1. 明确测试的目标,增强测试计划的实用性
      编写软件测试计划得重要目的就是使测试过程能够发现更多的软件缺陷,因此软件测试计划的价值取决于它对帮助管理测试项目,并且找出软件潜在的缺陷。因此,软件测试计划中的测试范围必须高度覆盖功能需求,测试方法必须切实可行,测试工具并且具有较高的实用性,便于使用,生成的测试结果直观、准确
      2.坚持“5W”规则,明确内容与过程
      “5W”规则指的是“What(做什么)”、“Why(为什么做)”、“When(何时做)”、“Where(在哪里)”、“How(如何做)”。利用“5W”规则创建软件测试计划,可以帮助测试团队理解测试的目的(Why),明确测试的范围和内容(What),确定测试的开始和结束日期(When),指出测试的方法和工具(How),给出测试文档和软件的存放位置(Where)。
      3.采用评审和更新机制,保证测试计划满足实际需求
    测试计划写作完成后,如果没有经过评审,直接发送给测试团队,测试计划内容的可能不准确或遗漏测试内容,或者软件需求变更引起测试范围的增减,而测试计划的内容没有及时更新,误导测试执行人员。
      4. 分别创建测试计划与测试详细规格、测试用例
      应把详细的测试技术指标包含到独立创建的测试详细规格文档,把用于指导测试小组执行测试过程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中。测试计划和测试详细规格、测试用例之间是战略和战术的关系,测试计划主要从宏观上规划测试活动的范围、方法和资源配置,而测试详细规格、测试用例是完成测试任务的具体战术。

    7、测试用例设计方法都有哪些?请分别以具体的例子来说明这些方法在测试用例设计工作中的应用。
      1.等价类划分
      划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类.
      2.边界值分析法
      边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.
      使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据.
      3.错误推测法
      基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法.
      错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结. 还有, 输入数据和输出数据为0的情况. 输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况. 可选择这些情况下的例子作为测试用例.
      4.因果图方法
      前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图(逻辑模型). 因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况.

    8、你对测试最大的兴趣在哪里?为什么?
      最大的兴趣就是测试有难度,有挑战性!做测试越久越能感觉到做好测试有多难。曾经在无忧测试网上看到一篇文章,是关于如何做好一名测试工程师。一共罗列了11,12点,有部分是和人的性格有关,有部分需要后天的努力。但除了性格有关的1,2点我没有把握,其他点我都很有信心做好它。
      刚开始进入测试行业时,对测试的认识是从无忧测试网上了解到的一些资料,当时是冲着做测试需要很多技能才能做的好,虽然入门容易,但做好很难,比开发更难,虽然当时我很想做开发(学校专业课我基本上不缺席,因为我喜欢我的专业),但看到测试比开发更难更有挑战性,想做好测试的意志就更坚定了。
      不到一年半的测试工作中,当时的感动和热情没有减退一点(即使环境问题以及自身经验,技术的不足,做测试的你一定也能理解)。
      我觉得做测试整个过程中有2点让我觉得很有难度(对我来说,有难度的东西我就非常感兴趣),第一是测试用例的设计,因为测试的精华就在测试用例的设计上了,要在版本出来之前,把用例写好,用什么测试方法写?(也就是测试计划或测试策略),如果你刚测试一个新任务时,你得花一定的时间去消化业务需求和技术基础,业务需求很好理解(多和产品经理和开发人员沟通就能达到目的),而技术基础可就没那么简单了,这需要你自觉的学习能力,比如说网站吧,最基本的技术知识你要知道网站内部是怎么运作的的,后台是怎么响应用户请求的?测试环境如何搭建?这些都需要最早的学好。至少在开始测试之前能做好基本的准备,可能会遇到什么难题?需求细节是不是没有确定好?这些问题都能在设计用例的时候发现。
      第二是发现BUG的时候了,这应该是测试人员最基本的任务了,一般按测试用例开始测试就能发现大部分的bug,还有一部分bug需要测试的过程中更了解所测版本的情况获得更多信息,补充测试用例,测试出bug。还有如何发现bug?这就需要在测试用例有效的情况下,通过细心和耐心去发现bug了,每个用例都有可能发现bug,每个地方都有可能出错,所以测试过程中思维要清晰(测试过程数据流及结果都得看仔细了,bug都在里面发现的)。如何描述bug也很有讲究,bug在什么情况下会产生,如果条件变化一点点,就不会有这个bug,以哪些最少的操作步骤就能重现这个bug,这个bug产生的规律是什么?如果你够厉害的话,可以帮开发人员初步定位问题。

    9、你的测试职业发展是什么?
      测试经验越多,测试能力越高。所以我的职业发展是需要时间累积的,一步步向着高级测试工程师奔去。而且我也有初步的职业规划,前3年累积测试经验,按如何做好测试工程师的11,12点要求自己,不断的更新自己改正自己,做好测试任务。

    10、你自认为测试的优势在哪里?
      优势在于我对测试坚定不移的信心和热情,虽然经验还不够,但测试需要的基本技能我有信心在工作中得以发挥。

    11、当开发人员说不是BUG时,你如何应付?
      开发人员说不是bug,有2种情况,一是需求没有确定,所以我可以这么做,这个时候可以找来产品经理进行确认,需不需要改动,3方商量确定好后再看要不要改。二是这种情况不可能发生,所以不需要修改,这个时候,我可以先尽可能的说出是BUG的依据是什么?如果被用户发现或出了问题,会有什么不良结果?程序员可能会给你很多理由,你可以对他的解释进行反驳。如果还是不行,那我可以给这个问题提出来,跟开发经理和测试经理进行确认,如果要修改就改,如果不要修改就不改。其实有些真的不是bug,我也只是建议的方式写进TD中,如果开发人员不修改也没有大问题。如果确定是bug的话,一定要坚持自己的立场,让问题得到最后的确认。

    12、你以前工作时的测试流程是什么?
      公司对测试流程没有规定如何做,但每个测试人员都有自己的一套测试流程。我说下我1年来不断改正(自己总结,吸取同行的方法)后的流程吧。需求评审(有开发人员,产品经理,测试人员,项目经理)->需求确定(出一份确定的需求文档)->开发设计文档(开发人员在开始写代码前就能输出设计文档)->想好测试策略,写出测试用例->发给开发人员和测试经理看看(非正式的评审用例)->接到测试版本->执行测试用例(中间可能会补充用例)->提交bug(有些bug需要开发人员的确定(严重级别的,或突然发现的在测试用例范围之外的,难以重现的),有些可以直接录制进TD)->开发人员修改(可以在测试过程中快速的修改)->回归测试(可能又会发现新问题,再按流程开始跑)。

    13、你为什么想离开目前的职务?
      因为公司运作情况并不理想,公司需要调整部门体系,公司考虑到缩减部门人员,所以大批量的裁员(有6,7个),这是我的第一份工作,对公司也有较深的感情,因为在这里我找到了职业理想(就是测试),所以公司需要精简人员,我自愿退出。虽然很舍不得,但我将会有新的发挥能力的舞台。

  • 解密测试面试官的心理

    2008-11-23

    多多少少也面试个几个人了,有一点心得,拿出来分享一下:

    记得当年我第一次应聘的时候,根本就没意识到面试的重要性,很随意的就去见了我之前的老总,虽然顺利的通过,但后来到了公司之后,才知道我当时是多么的惊险。直到后来,我才明白当初老总那玩味的眼神意味着什么!还好,平时知识积累了那么点,谈吐也不是扭扭捏捏,回头来看,我的运气还不错。

    后来,我第一次作为面试官的时候,同样遇到跟我当年作风一样的一个小男孩,我才明白我当年是多么的幸运,而我面前这个男孩是多么的不幸。5

    我不大清楚hr是怎么面试的,我大概了解测试技术面试,那就大概谈谈,我作为面试官,我喜欢什么样的测试,下面我说的主要结合面试官的角度来说说,而不是从应聘者的角度来分析,让大家对面试官的心理有一定把握。

    第一印象:

       第一印象非常重要,一般来说你的着装能代表你对工作和你对这个职位的态度,也能决定面试官的‘考察深度’,相信如果你不是超级牛人,你应该不愿意面试官给你很有深度的问题。当然牛人例外,因为牛人一般是后面用他的技术和他的才华来征服面试官。建议面试的时候穿着比较正统,相对轻松的服装,最重要的是整洁。为什么这么说呢?因为技术面试一般来说都是改公司测试部门的人,一般来说都是搞技术的,在大多企业,技术部门的着装是很随便的,所以着装没必要太隆重,过于隆重可能会适得其反。

    千万不要不懂装懂:

        上面说了,技术面试一般都是公司的工作人员,多多少少有点斤两,如果问你几个问题,你不会就不会,但是不用回答的太直接,你可以委婉的说你不太熟悉,虽然回答问题失败了,但是面试官会知道你是个诚实的测试人员。我之前面过一个测试,他自称在某游戏公司负责自动化测试,主要成果是开发机器人。恰好,我对这个也比较感兴趣,就顺便问了一下机器人和游戏服务器如何实现通信的,机器人和游戏客户端区别是什么?不过这个人很聪明,他的回答是:通过网络实现通信,机器人不需要人来操作,客户端需要人来操作。他的答案其实没错,只是如果自己做过这些东西,了解这些东西的话,相信他不会这么回答我,我也就只好请他等候通知了,呵呵!一般我们问问题的时候,自己心里是有底的,如果你试图忽悠面试官的话,我可以明确的说99%的情况下,你会失去资格。

    其实我们也没标准答案:

        一般2种情况下,面试官会问你很深入的问题,这类问题其实面试官他们也没好的解决方案,呵呵!第一种情况就是你的态度或你的表现让面试官不满意了,另一种情况,就是你太让面试官满意了,这2种情况,其实在面试的时候,你自己应该是能区分出来的,如果你很谦虚,前面问题有回答的很有条理,思路也很清晰,那就是第二种,如果你什么都不清楚的话,那你多半是第一种了。如果是第二种,我恭喜你,这个时候其实面试官已经让你通过了。这个时候面试官一般问的问题都比较深入,或者是比较经典的问题,或者他自己都没解决这个问题,你只要放心大胆的说出你的想法以及分析思路和原因就行了,如果解决了面试官的问题,那offer差不多就是你的了,如果解决不了,也不用担心,你至少说出了你的想法,让面试官知道你思考问题的方式。

    沟通很重要:

        测试的一个重要素质就是沟通能力,面试官不会直接考察这个能力,而是通过面试过程来给你这个能力评分。所以从头到尾,你都要表达清楚,大方,而且能抓住重点。很多应聘的同学,心理会有一点紧张,经常会出现答非所问,或者不知所云的情况。如果是这样,建议多问问面试官,你是问的这个问题吗?你是想问这个问题出现的原因还是解决的办法?这样,你可以更精确的定位面试官的意图,直接答到点子上去,面试官绝不会因为你问了问题而给你不好的评价。

    思考方式也是一种能力:

        在面试的时候,我经常会遇到一些应聘者不知道如何回答一个问题.一般来说他们会选择说我不知道,或者欺骗的方式,这些我都不喜欢。只有很少的人,他会来分析这个问题,他在分析过程中,熟悉问题,切入问题,解决问题。在遇到这种问题的时候,不要怕,大胆想,不怕出错,但出错也要出得情有可原。实在解决不了,你表达出你思考方式就好了。这样我也会给你一个高分。你要什么都不说我只好不给分了,当然你要乱说的话,我就只能在前面给你扣分了。

    做你擅长的事:

        面试的时候,一般会问到你最擅长的是什么?这个时候你可以放心大胆的说,而且一定要深入。首先你需要有信心,你擅长的,面试官不一定擅长,要尽可能展现你的能力,让面试官对你有一个清新的认识。只要你的观点,思路正确,面试官还是会认同的,虽然面试官他不知道为什么,但是他知道是什么。这个主要是为了让面试官欣赏你,觉得你能给他们带来帮助。

    装b被雷劈:

       我遇到好几个应聘者,一来就说什么国内测试行业很落后,国外很先进,什么国外的做得多么好,微软的做得多么好,但我一问为什么?让他们分析一下原因,却没人说的上来!其实我也说不上来,所以我不说。经常遇到自称能力很强,一副我是救世主,来了可以拯救你们公司的模样。大家都是技术人员,都有几分傲气的,现在还是你的面试官,你就这么装b,那将来要是同事了,你让我怎么过啊?我还敢招你吗?如果你确实能力出众,那无可厚非,但是如果半灌水,那就......,其实我也遇到很多大牛,我发现一点,越大的牛,越低调,越谦虚。

    细节决定成败:

       面试官其实大多很注重细节,比如坐姿啊,手势,眼神之类的,这些其实网上说得也多,就不多说了。一次,我面试一个学生,面试完了后,说完再见他轻轻的带上门,这一点让我很欣赏他。因为之前的学生要么就是不关门,要么就是砰的一下关上门,我直接让他b变成了a,我同事问我为什么,我跟他说,这么关注细节的人,能做不好测试吗?

  • 给一个想做测试的大学毕业生的回信(转godn_1981)

    2008-11-02

    前天收到一个邮件,是一个刚毕业的学生发给我的,内容如下:

    你好,我是一名刚毕业的大学生。学校算是个三四流的吧。现在打算在软件测试方面找工作,可是什么都不会。请教你一下培训怎么样?

    谢谢!

    在征得写信者的同意之后,把我的回信贴出来,也许可以给大家一点建议。

    回信如下:

    XXX:

    你好,我就您的问题,谈谈我的看法。

    我想我先不谈测试培训的问题,先谈谈你职业选择的问题。看你的邮件,似乎是因为目前手头没什么技能,无奈先屈尊于测试行业,至少从我的理解来说,您似乎不是有兴趣或者自认为有专长,而是因为暂时因为没其它更好的选择而来做测试。

    如果真是这样的话,请你要再三思了。也许您觉得测试似乎门槛低一些,无需太多的技能,做起来比较容易。这么说也没错,但是其实也不是这么简单的,测试决不是一般想的那样点点鼠标,验证验证。真正一个好的测试工程师需要很多方面的素质,最基本的有:洞察力,耐心,沟通能力,承受较大工作压力,逆向思维习惯,比较好的逻辑性,比较广的知识,比较好的文档水平,还最好有一定的程序基础。

    当然很多人也许并不具备这些素质,也在做测试,但是每一行业都是一样,测试更是这样,门槛不高,做好做精却是很难,我的感觉是,如果您今天选择测试只是因为门槛低,你做上一段时间之后会发现有瓶颈,再实现一个质的跃迁很难,如果到那时候再迷茫的话,倒不如早点想清楚,为什么要选择这个行业?自己有哪些优势适合这个行业?应该说每一个测试者都想早点脱离点击一族的黑盒测试,但是再进一步就需要一些知识和技能,以及好的idea,但反过来说,如果你拥有这些,你在别的行业一样可以做的很出色,譬如现在流行的as,ajax等,如果你有能力,我保证肯定比你做测试拿钱多
    综上所述,我的意思是说,看起来测试这碗饭门槛比较低,吃起来容易一些,其实在每一个行业要想做好都是需要知识,能力和想法的。在测试行业也是一样,如果你没有好的知识技能和学习能力,那么也只会一直做一个普通的Tester,一直点击着,直到被年轻人淘汰……
     
    以上是我对您选择职业的看法,如果你真的决定了选择测试行业,那么也很好,那就踏踏实实做下去,肯定是有前途的,中国目前的测试行业确实发展很快,目前真正的测试高端人才还是凤毛麟角。
    如果你想选择做测试,又苦于不会什么技术。那么只有两条路,一条是速成就是培训,可以快速上手,不过需要一定的费用,另一条就是找个类似实习的工作,自己买书学习充电,并在工作中留心,另外如果有人给你传帮带就最好了。
    另外再啰嗦一点,培训只是给你提供知识,技能和方法,真正培养能力还是在自己实践中,不要寄希望太高。另外,如果一定要选择培训,最好不要去北大青鸟,我面试过几个北大青鸟的,感觉除了夸夸其谈一些大道理之外,真的不怎么样。据说51testing的培训还办的不错~另外据朋友说,中国软件测试人才网也还可以。本人绝不是做广告哦,嘿嘿
  • 测试工作中的“思考与行动” 转(lan_7366)

    2008-11-02

    最近一直很迷茫。关于自己的职业规划很迷茫。虽然一直都懂得勤于观察,善于思考的重要性。可是一直没能完全克服自己的懒惰心里。虽然一直在学习着。但是没有紧迫感。今天在一个测试群里。和一个测试讲师的聊天启发了我。不能再这样下去了。如果要改变目前的境况,必须做一个行动派。

        做为刚入门不久的新手,工作中,我们要勤于观察资深的同事是怎样处理问题的:遇到有争议的BUG怎样跟开发部门的同事沟通,遇到需求不明确的BUG怎样和提需求的人员沟通。遇到需要头儿出面协调的问题,怎么巧妙的向头儿表达这件事必须他出面才能解决。而不是你能力不行解决不了。观察平日里别人是怎么向头儿汇报工作的。让头儿知道你都在干什么。你主动的干了什么。让头儿知道你的能力。

        观察的同时我们要善于思考。分析自己的优缺点。考虑怎样才能,学习别人的长处,发扬自己的优点。怎样做才能针对薄弱的地方,尽力克服。当然要做起来,这是很难的事情,人类最大的敌人莫过于自己了。战胜自己是困难的。为了自己的梦想,再苦再累我们也得坚持。

        一个人只有在不断的学习。不断的思考。不断的总结中才会提高,成长的更快。随着我们工作时间的增加。做过的项目也多起来。我们要不断的总结得失。做的好的地方发扬光大。做的不好的。以后一定注意完善。

        就让我们都多思考我们职业规划,思考怎样才能完成我们的理想,思考下一步我们该如果去做。最重要的一点要说明一下哦。呵呵。思考固然重要。行动才是解决问题的关键。思考与行动哪一个环节都不能少哦!所以。让我们都做一个行动派吧!

  • [转贴]谨以此文献给正在郁闷的人们!!!

    2008-11-02

    一头老驴,掉到了一个废弃的陷阱里,很深,根本爬不上来,主人看他是老驴,懒得去救他了,让他在那里自生自灭。那头驴一开始也放弃了求生地希望。每天还不断地有人 往陷阱里面倒垃圾,按理说老驴应该很生气,应该天天去抱怨,自己倒霉掉到了陷阱里 ,他的主人不要他,就算死也不让他死得舒服点,每天还有那么多垃圾扔在他旁边。可是有一天,他决定改变他的人生态度(驴生态度更确切点),他每天都把垃圾踩到自己 的脚下,从垃圾中找到残羹来维持自己的生命,而不是被垃圾所淹没,终于有一天,他重新回到了地面上。
       不要抱怨你的专业不好,不要抱怨你的学校不好,不要抱怨你住在破宿舍里,不要抱怨你的男人穷你的女人丑,不要抱怨你没有一个好爸爸,不要抱怨你的
    工作差,工资少,不要抱怨你空怀一身绝技没人赏识你,现实有太多的不如意,就算生活给你的是垃圾,你同样能把垃圾踩在脚底下,登上世界之巅。 这个世界只在乎你是否在到达了一定的高度,而不在乎你是踩在巨人的肩膀上上去的,还是踩在垃圾上上去的。我认为踩在垃圾上上去的人更值得尊重。年轻没有失败,看驴生豪迈,不过从头再来......
Open Toolbar