海纳百川,有容乃大!期待和测试同行交流学习,共同进步。

发布新日志

  • 转载:如何在应聘职位前准备可能面试到的内容?

    2010-10-03 14:20:40

    前言:两年前换工作时写的日志。今天路过这儿,跟大家分享一下。希望对大家有帮助。

    正文

    一、做好充分的准备

    如果打算换工作,应该提前一或者半年做准备工作,一般情况我是不赞成换工作的。但是如果确实不适合现在的工作,不换不得已,那就只能走了,适时地放弃意味着又一次选择,探明此路不通的努力远非白费。既然因为不得已离开现在的工作,那就给自己的工作做个总结,吸取教训,首先问问自己一下的问题,自己回答清楚了再离开,不然很可能就要频繁的换工作了。

    1、为什么离开这家公司

    就像我,因为身体吃不消不得已离开以前的公司,所以我再找工作的时候就首先本着可持续发展的道路,工作时间一定要合理。

    2、知己知彼

    我在这家公司学到了什么,有什么经验可作为找新工作的资本,只有考虑清楚了这些,才能在面试的时候展示自己的亮点,有了亮点才能让招聘者认可你。知己知彼首先要知己,知己才能知道目标,也就是知彼此,才能百战不殆。除了知已,还要清楚自己以后的发展方向,在哪个领域,做个长期的打算。有句话说,有志人立长志,无志人常立志。相信大家都想做个有志的人,那就从实际做起吧。

    3、我还需要学习什么

    如果你的实力不足以让你找到一份满意的工作,那么从现在开始为自己充电吧。

    4、我是冲动吗

    自己是因为冲动离开现在的公司吗,冲动是魔鬼。

    二、面试技巧

    1、认真对待每次面试

    在面试的时候,把每次机会都当成最后一次机会,珍惜这个机会。当有很多机会的时候,才可以去挑选。如果机会溜走了,就没得挑选了。我就是拿了好几份offer的。

    2、面试时怎么说话

    首先说话要清晰,可能好多人觉得这个很easy,觉得我口齿很清晰呀。口齿清晰的人不一定能说话清晰,不一定能表达清楚自己的意思。怎么做到说话清晰呢?首先,还是要知己知彼,就像是两个很好的朋友,用几个简单的词就能清楚的表达自己的意思,但是碰到陌生人,用很长的一大段也说不清,这个例子想说的是文化的差异,如果是与外国人面试,就更要多研究研究文化的差异了。还有就是语言的差异,就像芬兰人会把/t/当成/d/,/p/当成/b/,如果不清楚这些,很难交流的。说话清楚了,对方就能感知你的意思了。然后要思路清晰,这是表达你的交流能力的,很多人会在简历中写道,很强的交流能力,如果在面试的时候表达都没条例,何谈很强的交流能力。还有就是说话大声、清晰,否则会显得你很羞涩,或者没经过场,是面试又不是相亲,是展露自己才华的时候。要想说话大声、清晰首先要消除心理障碍,不要怕。就算面试官很牛又怎么样呢,不然他就不会来面试你了,归根结底都是人,没什么好怕的,坦诚对待一切。

    3、坦诚

    面试是一个让面试官了解你的过程,你有的才能,不用谦虚地掩盖;你没有的才能,也不用编造。人才是德才兼备的人。小事靠才,大事靠德。所以建议展示真是的自己。

    4、巧答技术问题

    对于面试官提出的技术性问题,如果你只讲理论,面试官会以为你不懂实际;如果你只说实际的东西或者例子,面试官会以为你理论基础不扎实;所以最好的策略是,先讲理论,然后举例子。不建议先举例子,再讲理论。老师再学校讲课通常是先举例子,然后将理论,因为老师面对的是学生。而现在我们面对的是面试官,面试官是明知故问的。

    5、巧答发散思维问题

    对于这样的问题,首先分类,然后一一作答。比如,你喜欢什么样的交流方式,MSN,e-mail,面对面地交谈,还是电话?你说喜欢任何一个都显示你有某方面的不足,你如果选择MSN,表现了你不擅于与人面对面的交流,逻辑思维不强(不然可能用e-mail);如果你选择了电话,你是否考虑到公司的财政;......。

    6、分析问题

    除了技术型的问题,面试官还会问很多其他的问题,当听到这些问题时,首先要清楚面试官的目的是什么,大多数的答案是多选或者单选型的,相信每个人都知道善恶美丑,选什么样的选项不是个问题。只有知道了面试官的目的,才能给面试官想要的结果。不然就像面试官展示了你理解力不强的弱项。

    7、怎么说怎么圆

    不管自己说什么,都要给出合适的理由,以理服人。是是非非,有理就行。所以一定要解释理由,但是不是强词夺理,要合理的理由,有理有据。

    结束语

    最后祝愿大家找到理想的工作!
    本文转自:http://bbs.51testing.com/viewthread.php?tid=182451&page=2#pid1427669
  • 新工作 pk 旧工作

    2010-09-19 20:44:23

  • 新工作计划

    2010-09-18 22:00:40

  • 工作心态

    2010-09-08 22:21:55

      最近心态一直都不好,估计是对新工作期待太多了,希望越多失望越多。在论坛上也发了抱怨贴,感谢各位各位同仁的热情批评,也许新工作确实让自己需要更多的主动性,之前的工作太忙,总有忙不完的任务。

     刚把心态慢慢的调整过来的时候又听说有几个同事要走了,新工作工资及环境都超过我好多,最重要的是工作经验没我多,能力嘛估计也相差不大,自己的情绪又开始波动了,心态又不好了。仔细想想自己的经历,在这几年期间自己跳了3+以上,最短的是半年,最长的也就只有1.5年,这么频繁的跳槽的话对自己今后找工作都不利,员工的稳定性还是很重要的,虽然每个跳槽都不是自己乐意的。

     想想前5年是积累经验阶段,自己在过去的几年里接触面比较窄,做的比较单一,郁闷的是还没写过case,主要是没这个机会,所以在新工作中要沉下来,好好学学,一个公司肯定有值得学习的地方,要善于发现同事之间的闪光点,即使没自己有经验,但还是有地方可以学习的,这个没有什么不服气的,再说自己还是新来的。

     记住:机会是给那些有准备的人

  • 转:Android 操作系统特点

    2010-07-26 21:05:16

    1 真正意义上的开放

         不仅仅是开发工具,更是底层源代码的完全开放,在android的主页上你可以自由下载现成的开发工具和源代码。而无论你是资金雄厚的开发公司还是精力过剩的高中生爱好者,在android的世界里,只有平等和自由。

         2 将互联网一切都免费的精神发挥到极致

         只需要50美金注册保证金,你就可以面向全球发布你的伟大软件创意,不好再有烦琐的审核和限制;超过80%的1万多个免费应用程序可以任意下载安装,没有乱七八糟的证书要安装。

         3 从头到尾的自由

         中国移动的OMS就是Android自由精神的最大体现,没办法,Google就是这么大方的不拘小节。Google甚至允许全世界各地的个人和公司等任意的修改android小机器人的标志,这在商业社会的今天简直是不可想象的,全世界的android粉丝创造发挥了几百款各式各样憨态可掬的android机器人形象。

         4 每一个线程都独立运行

         用过googlechrome的人都知道,如果Chrome遇到崩溃,可不是像IE那样傻傻等半天最后几十个窗口全部死掉,Chrome是只有崩溃的那个窗口死掉,其它的都照常运行,android系统的手机也是这样,内存溢出,程序崩溃之后造成一个应用程序的重启,不会影响其他程序和手机系统的运行,所以android的手机基本上可以永远不关机,Windows手机上那套“死机-拔电池-重新开机”的黄金定律没有了。

    转自:http://www.inandroid.cn/bbs/viewthread.php?tid=52

  • 深深体会计划的重要性

    2010-07-26 09:56:41

  • 工作纠结

    2010-07-11 17:01:05

  • 感情杂想

    2010-06-28 10:31:02

  • 外包到hw的1.5年间的体会

    2010-06-05 22:15:48

     外包到hw已有1年半之久了,在这期间让我感受到了大公司的风范,但就是累了点。对于测试,公司还是比较重视的,其中觉得有些地方还是很值得学习的。

     1、先说说bug的处理。这个走的还是基本的流程,相信大部分公司都有的,但却有个很独特的地方,CCB。即这个主要是针对一些有争议的bug,开发认为是非问题,或者是修改这个问题风险比较大,拒绝修改,此时可不是开发说了算,这时候就是CCB起作用了。CCB成员主要是各个部门的头组成了,其中还包括测试经理哦。当然到CCB裁决时此时也是项目的尾声了,CCB裁决的单会直接关闭。如果对于被裁掉的单有异议的话可以直接反馈给测试经理,或许还有回旋的余地哦。

     2、对于无规律问题的处理。这个还是强调找找规律,对于那些找不到规律但抓的Log对开发定位有帮助的话就可以直接提单,对于那些没有log或者Log无效的话,就将这个bug提到疑难问题中,这个有1个专门的excel来记录。然后在后期会定期分配人专门去复现。

     3、质量意识。他们有1个事故级别(1级、2级...),所谓的事故就是漏测,这个包括的范围很广,小到手机彩盒,大到手机功能。记得有1次我不小心将手机掉到地上,发现扬声器被损坏了,像这种情况下测试要提单的,这个在我以前的公司还是从来没遇到过的。会将以往项目事故写成文档,事故现象,事故的原因分析等,对于新人都要先培训这个知识的。

    4、知识共享。测试组人比较多,手机模块多。对于骨干的话都是负责几个模块,然后再输出心得体会,供新人学些参考。还有培训也是,大家相互培训学习。

     当然也存在一些问题,比如项目比较混乱,这个主要是项目太多了,时间又紧迫,有些bug在这个手机上合入了,在另1个项目上又不合....,但是在中国的测试行业相信他还是领头羊的。

  • 近期测试工作总结

    2010-06-05 21:23:26

  • feeling杂想

    2010-05-19 22:14:34

      近期因个人问题弄的工作没精打采,导致工作上出现了好几个严重漏测问题。看来不能这样了,要好好的工作,好好的爱自己。放手让自己去寻找幸福吧,也许只是把ta想的太好了吧,人还是需要多多的了解的。因为不了解而在一起,最后的结果也不会好到哪去,身边这样的例子也不少.踏实点吧,努力过自己这关。不是人不好够,不是不够优秀,而是自己眼里有刺,所以才会看什么都不顺眼。
      给自己点时间吧,或许3个月或许....,如果努力过了还是过不了自己这关的话,那只能说对不起,我已经努力了....
     
  • 转:如何有效的选择回归测试用例?

    2010-05-16 22:37:48

    本文转自:http://www.51testing.com/?1592/action_viewspace_itemid_83107.html

     

    今天看到51testing上有这个问题,觉得很值得探讨一下,就在此谈谈我的看法。
     
    关于这个问题,我粗粗的搜索以下网上的关于这个问题的说法,大都是空空理论之谈,实际操作起来并不一定适合。
     
    说到回归测试用例,先说什么是回归测试。顾名思义,回归测试就是修改完bug之后对程序的新的一轮测试,据微软的统计,按照他们的经验,一般开发人员解决3~4个bug会衍生出一个新的bug,这就是必须作回归测试的原因。简单的说,就是检测一下解决了bug之后有没有带进新的问题,以免把聋子给治成哑巴,就得不偿失了~~
     
    一般的软件测试的流程是后期快速迭代的,bug在后期是快速收敛的,debug和测试的周期也是越来越短,频率是越来越高,譬如说第一轮测试需要花上10天跑用例,那么到后期就没那么长的时间,可能就是1~2天的测试时间,在后期有时候一天就有一个新的版本,这时候就要求测试人员能快速的进行一轮回归测试。
     
    一般来说,覆盖越高,风险越低,但是效率就越差,反之亦然。所以如果时间允许的话,能把所有的用例都再跑一边是最好不过的,但是一般不会有那么多的时间,这就需要在效率和覆盖之间有一个适当的平衡,选择其中一部分测试用例用来作回归测试。
     
    选择回归测试的时候,首先要确定的是,回归测试用例的比例,这个要根据时间情况了,100%是最好了,我个人一般这个比例在60%左右。然后要确定回归测试用例的优先级。根据我的经验,一般有如下必须回归的用例:
     
    第一,新修改的功能,这个显然是重点
    第二,新修改的功能的关联功能,就是有耦合的部分,这个一般最好咨询一下开发人员
     
    第三,程序最有卖点或者说亮点的部分,这个地方一旦有问题,会使程序质量大打折扣
     
    第四,程序中最致命的部分,譬如说安全隐患,数据泄露,加密注册,
     
    第五,程序中比较脆弱的部分,这个要咨询开发人员,一般就是他们心中最没底的地方
     
    第六,程序的主干功能
     
    第七,如果以上做完,还有时间的话,最好把用例中级别比较高的用例再执行一遍。

     
    OK ,以上是回归测试用例的选择优先级。
     
    其实,即使这样做,还是有风险的。最根本的解决方法是自动化测试工具加上手工测试。具体就是常用的程序主干功能,主要功能,用自动化测试,保证每一个版本都能够执行一遍,其他修改频繁的小功能手工测试了。
    说了这么多,好像比较乱,总结一下。
     
    个人觉得解决这个回归测试的终极解决方案是:
     
    a.作每日构建
     
    b.基线功能自动化
     
    c.编写用例时一定要分级(按照风险度,常用度,重要度)
     
    d.手工执行回归测试用例(就是我上面说的7项)
     
    好了,这是我对这个问题的解决方案,欢迎大家补充,讨论,拍砖~~~~~~~~

     

  • 因为无知竟和严重问题擦肩而过

    2010-04-19 21:45:37

  • 转:避免做“紧急任务”的奴隶

    2010-04-11 19:55:54

    避免做“紧急任务”的奴隶
     
    无论做什么事情都要有时间管理,这是我们一直关注的话题,一般时间管理可以分为四个部分,这样才能很高的提高自己的工作效率。
    1. 重要而且紧急
    2. 重要但是不紧急
    3. 不重要但是很紧急
    4. 不重要而且不紧急
    根据这个把要做的事情一一标注,哪个先做,哪个后做,并留出一定的缓冲.而且不会把自己搞得太累。
    但是最近在工作中发现其实并不是这样的 即使你想按这样做领导也不会答应你这样,在他眼里样样是紧急的事情。目前碰到一个项目 最高领导 要求要一周加4天班9月15日内完成任务,任务到达下来到我们直接领导变成9月4日完成。而且所有的任务都变成死任务非常紧急的任务,嗨没办法……一级压一级压死人咯!

         在工作时间管理中8-2原理是十分重要的,要让20%的投入产生80%的效益。只要把握一天中20%的经典时间(有些人是早上上班时间有些人
    是下午,如果是晚上只能自己认命加班),专门用于你对于关键问题的思考和准备。
      有那么多的“紧急事”和“重要事”,想把每件都做到最好是不实际的。建议你把“必须做的”和“尽量做的”分开。必须做的要做到最
    好,但是尽量做得尽力而为就可。建议用良好的态度和胸怀接受那些不能改变的事情,多关注那些你能够改变的事情。以终为始,做一个长期的蓝图规划,一步一步地向你的目标迈进。这样,就能一步步地看到进展,就会更有动力、自信地继做下去。

    本文转自:http://www.51testing.com/?uid-240349-action-viewspace-itemid-111139

  • <宫心计>观后感

    2010-04-11 17:41:20

  • 转:谈谈测试执行分层(UT,ST,IT)

    2010-03-28 22:26:47

      V模型体现了测试设计分层和测试执行分层的概念,本文以作者自身的理解谈谈测试执行分层,不过从实际项目运作情况来看,真正做到测试执行分层的并不多,这里原因有很多种,暂且不论。

      1. UT

      单元测试的对象是LLD中所划分定义的程序单元或模块,它也是单元测试用例设计中可测试的最大单元。该测试对象可能由一个或多个函数或者类组成,测试设计就是对测试对象进行测试用例设计。

      UT的目的,是通过函数运行来检查模块代码对于LLD文档的顺从性,验证每个函数的输入输出响应,与它在详细设计文档中预先定义的是否一致。函数是产品开发实现的最基本单位,下一个实现单位是模块,从测试的角度看,希望UT完成后,每个函数都牢固可靠,下一步的IT测试将聚焦在函数之间配合能否实现分配需求,而不用担心函数本身的输入输出响应问题。

      单元测试比较适合开发人员做。

      2. IT

      集成测试是指把若干个经过单元测试的单元组装到一起而进行的测试,集成测试应依据HLD,主要发现接口、依赖中的错误或不完善的地方。集成测试的对象为若干个单元测试对象的组合,至少为两个。

      IT的目的,是根据模块设计对模块的分解,从已验证的函数开始,逐层向上集成,得到一个可运行的模块。

      IT可以由开发人员做,也可以由测试人员做。

      不难看出,UT是面向每一个单元的测试,IT是测试单元之间的接口,可以把UT/IT归为“单元级”测试。

      3. ST

      CMM定义的系统测试:系统测试是针对软件项目组所承担开发的软件系统进行的整体测试,将软件系统作为整体运行或实施明确定义的软件行为子集的测试。主要采用的测试方法是黑盒测试,即不管程序内部的实现逻辑,以检验输入输出信息是否符合规格说明书中有关需求规定的测试方法。可见ST的测试对象是规格说明书,更确切的说,是模块需求规格说明书,所以一般也称为MST。模块SRS文档给出了模块的输入输出的相应要求。MST后,每个模块是牢固可用的。

      4. BBIT

      BBIT为模块间接口测试,验证模块之间的接口能不能配合,有时和联调混在一起,其实目的并不相同。BBIT的目的,是根据系统设计对系统的分解,从已通过验证的模块开始,逐层向上集成,得到一个可运行的系统。而联调一般涉及软件、硬件或者不同产品间的配合测试。MST和BBIT可以归到“模块级” 的测试,一个验证模块,一个验证模块间的接口。

      以上UT/IT/MST/BBIT一般由开发人员完成,系统基本可以运行起来了,测试人员可以开展SDV、SIT、SVT了。

      5. SDV

      SDV虽然属于测试人员开展的系统测试,但是有点偏灰盒测试,因为SDV验证各子系统的配合是否满足设计需求(DR),对内部的实现还是关注的,验证多个模块集成以后是否满足设计需求。

      6. SIT

      SIT也是验证设计需求是否得以满足,与SDV不同的是,SIT完全把系统当作一个黑盒来测试,不关心内部具体的实现。实际应用中,SDV和SIT 虽然都属于系统一级的测试,往往由不同项目组(子系统)的测试人员分别测试,他们只关注各自的子系统,所以还是把SDV和SIT归为“子系统级”的测试比较好。

      7. SVT

      SVT是验收测试,其测试对象是产品包需求OR。产品包需求给出了产品的范围,从产品可能的应用环境的角度刻画系统,SVT的目的就是确认(或验收)产品包需求给出的各种应用场景产品均能满足。

      产品包需求不考虑内部实现的差异,SVT也是从整个系统的角度考虑包需求的各种应用场景,属于“系统级”的测试。

      各个级别的测试描述完毕,回头再看看这个分层测试的模型图,不难发现以下几个特征:

      1)基于系统架构的分解结构(系统-子系统-模块-单元),开发按照自顶向下的顺序逐层设计,测试按照自底向上的顺序逐层验证,这个分解结构在每一层或每一个阶段,将开发和测试过程统一起来。

      2)在每一层,测试的对象是开发相应阶段设计的输出(包括需求和这个阶段的设计文档),测试的目的与开发相应阶段设计的思路是相辅相成的,所以决定每个阶段的测试如何开展、评价一个测试过程时,如果离开开发过程,只谈测试自身的话,是不系统、不全面的。

      3)除了“系统级”的SVT测试以外,其他各层的测试均包含两个方面:一是对这个层每个构件的测试,有n个构件就要测试n次,二是这n个构件之间接口的测试。例如:nSDV(每个测试项目组的SDV是一个SDV)和SIT、nMST(每个开发项目组的MST是一个MST)和BBIT、nUT和IT。

     

    转自:http://www.51testing.com/html/99/n-211399.html

  • 手机入网流程

    2010-03-08 22:05:03

     

    对于手机进网预测试可以分为四大部分:
    (1)    TA---型号核准测试
    (2)    EMC---电磁兼容测试
    (3)    Field try---场测(专业试用)
    (4)    NAL---电信设备进网测试

     

    转自:http://bbs.mobiletest.cn/redirect.php?tid=7403&goto=lastpost#lastpost

  • 转:一个厉害mm对男人的极品评价 女生你要记得

    2010-02-25 22:33:47

  • How to be a good tester employee?

    2010-01-25 23:23:32

    自从从事软件测试工作以来,前前后后,大大小小也参与过了四个项目,同时也和四个做事风格迥然不同的项目经理合作过,如何成为一个做事让Leader满意的tester呢?需要注意的地方,我总结了以下几点,供以后的职场测试新手参考(前四点是职场小规则,后面就针对工作的技术方面等的技巧了):

    1. 别太爱出风头,既然有意见相悖的,在实际经验不足的情况下,根据指示走

       这是我参与第一个项目总结出来的,说一下情况,我的第一个项目经理是英语专业出生,工作后转软件测试,计算机专业知识懂得不多。所以呢,我刚开始经常和他有技术上面的争论,一个新手和项目经理一开始有争执,即使你的都是对的,这都引起了我以后诸多的麻烦。
       呵呵,没有太多的意思,我是说, 在学习期间,一定要沉住气,即使自己有过多的理论知识,也要多听听别人的看法,他们实践经验比你丰富,虚心请教就是了,这个时候就是要少讲话,多思考,多做事。
       另外最重要的一点,既然这个PM再怎么不好,不要在同事之间谈论,同事之间不要谈论同事工作,为人的好坏,最多针对工作谈工作,以免引起你以后很多不必要的麻烦,这是我深有体会的。

    2. 和Leader讲话说话三思

       和同事关系再好,那也仅仅是针对工作,当然,我并不是说同事不能相处成为生活上面的好朋友。再和Leader谈话的时候要就事对事,按事实说话,而且就说你看到的,不要加以自己的揣测,尤其是和Leader谈论你的同事的时候。不是每个PM做事都是很内部团结的那样子。讲话三思,不要到最后一传十十传百,你就成为了千古罪人了,自找麻烦。

    3. 做事要稳重,不能急

        新手做事,都有点蠢蠢欲动,迫不及待的样子,当真正遇到挫折的时候,就像激流撞石,可以想象。做事前多思考,不要急,刚开始慢慢来,列一个规划,先做什么,后做什么,预计会遇到什么样子的困难,急事慢做。我讲的慢是个人的心态,思考成熟后才动手

    4. 没事找事做

        没事要找事做,先手最缺的是经验和技术,在闲时的时候,可以没事找事做,好处我就不多说了,但是最关键对你的好处,可以不断的练手,熟悉,接触更广的测试领域,会有很多意想不到的收获的,虽然中间可能会遇到很多的麻烦。在这个时候,千万别害怕困难,能遇到困难,这也是你的福气了,每一个障碍都是一个进步的起点。

    5. About Email

        每天工作结束后,离开办公室前,一定要给你的Leader发邮件,并且CC to项目小组的其他成员,邮件内容可以包括以下几个方面的内容:
        a. 你今天具体做了哪些事情 这是你自己的一个每天的工作小结,同时也让Leader知道你的工作进度情况,好安排下面你的工作安排,配合开发更好的做好bug的修复工作,如果是到了测试阶段,可以附上bug list,显示bug的状态,这样子,和DEV的工作也好沟通和协调,同时让Leader知道,你还在工作的,你和DEV的一个工作协调到什么程度了。
        b. 你遇到了哪些方面的问题 哪些问题是要大家在晨会的时候探讨的,当然要附上自己的理解和自己已经思考过后的解决方案,表明自己已经研究过,但是还是有争论和问题,你需要大家怎样的帮助
        c. 第二天的工作安排,你准备做什么?以及各项事项的优先级。

        下面是我的PM给我的邮件上面的指点,可以供大家一起参考下:
        a. Have all cases finished? What did you do today? need process(percents) and what are deliverables
        b. What's the issue? Anything out of your control blocked you? If not, please figure it out by yourself
        c. What's your next step?ETA? Priority?

        自己写的邮件一定要自己先检查一下,尤其是英文邮件,如果你站在对方的角度你确定你自己能看得懂吗?如果你对自己的邮件满意,你就可以发送了。我开始就说了,一定要记得CC To项目小组的其他人

    6. 学习和工作过程中,思考后问问题

        我在about Email中也提及过这方面的内容,问问题一定要讲究技巧性,每个人都是各司其职的一个状态,不可能对你的工作了如指掌,当你有技术方面的问题要问的时候,要说下具体哪方面的block you?你自己思考的一个情况,不要什么都问,有些问题你自己思考思考就会有答案的。如果有需求方面的问题,你可以把你自己的理解,写成1,2,3的选择,这样子也省得PM去费事再去深入思考理解,也好尽快的解决好问题。
        实际工作中,问问题也是一门艺术,关键的一点,自己先想后问,自己有了自己的答案后,有了自己的理解后问问题,是不会有错的,还有就是不要把问题压到快下班的时候,如果技术上面的问题,一定要尽早思考尽早开口,给别人多一点的时候解决,这样子也不耽误工作的进程和时间。

    7. 保存好测试的证据

        这是非常重要的,你到底哪些case跑过了,哪些case没有跑过,我怎么去证明,一定要保存好测试的证据。这是一方面;第二方面,当你测试到以后的测试用例的时候可以可以参考前一步的测试数据,好做对比,保存好测试的数据的好处不由我说,测试过的同行肯定已经深有体会的了。

    8. 一个好的测试人员可以协调好开发和PM的关系,推动整个项目的进程

        这算是最后的一个总结吧,一句话,一个好的测试人员可以协调好开发和PM的工作,推动整个项目的进程。这个是要长期工作的积累的,一个好的测试人员,从需求开始,确定需求是否有需要更改的,是否有再要变动,及时提出来,解决问题,很大程度地节约了以后如果再次修改需求,修改数据库,再次重新编码的一大堆事情。测试人员紧跟进bug,和DEV协调好工作,会很有效的提前产品发布时间,减少后期因为bug管理不善而导致的种种问题。

         经验和技术都太重要了,明白了,为什么职务和薪资的差别在哪儿了吧?大家都要加油加油再加油,我也在努力中……

    http://www.51testing.com/?uid-245435-action-viewspace-itemid-200496

    本文转自:

  • 由和头顶嘴想到的

    2010-01-24 19:40:56

1442/8<12345678>
Open Toolbar