圣诞感恩回馈

测试人员发展道路之我见

加国无忧 51.CA 2012年1月22日 17:17 来源:新职学院转载 [ 加大字体缩小字体 ]
我写这个标题可能被大方之家耻笑了--你才做测试多久,就考虑什么之路了?或许将来看,我现在的想法很幼稚,但是现阶段我还是不断的思考,不断的让自己在将来接近成熟的目标。
  刚到一个新环境,之前两个月的测试工作也算告一段落。因为到这边换了业务,尽管还是在一个大系统里,但是和原来的测试内容之间的交集已经很少。需要重新去学习对应的业务只是,重新开始。
  没法,虽然已经有工作经验,但是对于目前公司的业务这块,自己还是一张白纸,好画最新最好的画。此篇也是仅仅总结前两个月的一些感想,因为涉及到信息安全,我不会写业务有关的知识,只是想想这两个月的测试生活,让自己沉淀,走更宽更长的路------转载请注明出自测试窝。
  这两个月从事的是中间件的测试,需要从底层获取接口,同时向上提供API的测试,具体框架也只能说这么多,全程全部自动化,测试人员负责编写测试脚本,撰写代码(不懂编码不行),自己搭建服务器集群,测试产品的功能--分布式部署、负载均衡、性能问题(既有指标,也要探索)等测试人员需要关注的,因为是全程跟产品,因此也不存在只做功能或者性能,都要懂怎么搞。
测试用例是测试人员的最基本功,入这个行业的基本功底就是编写测试用例,不管是前端页面还是后台接口测试,常用的工程方法都需要的。设计出来的测试用例能够体现一个测试人员的基本能力。但是不是每个熟悉测试方法的人都能够设计好用例,换句话说,仅仅理解了工程方法是远远不够的。
  不知道这句结论是否下的有点武断,但是目前我遇到的困境正是这样,因为之前做的是和数据有关方便的测试,对通信方面的业务知识基本上只是了解到大学毕业的水平。知道有那么回事,况且我们从事着一个日新月异的行业,那点知识早就可以进历史博物馆了。业务,是你能否取得长足进步的不容忽视的部分,甚至过分的说,这个比测试方法更让你的价值提高。
  这轮测试的时候,我设计的用例在工程方法上面来说基本上是覆盖面最广最全的,也很少被挑毛病,可是这个东西是我的绩效么?你或许会说做的这么好是啊,甚至是好的绩效。不错,这个好只能证明你的测试功底确实不错,你的基础没有问题,可是这个用例真的不是这个产品特别需要的用例。我设计了这些是因为我之前几周了解了这些东西的业务背景,现在刚报道新的产品,我设计用例就举步维艰。
  接上面的讨论。一个产品,设计出来是给客户使用的,用户对你支持1000个还是2000个字符、特殊字符、null传递什么的不是特别感冒,他们关注的是你这个东西能够适应我这个使用场景么?这个才是重点,你设计了那么多用例,给你自己,整个产品以及最终用户有多少帮助呢?现在简单的说下我的用例的结果,业务部分,我的用例是远远不足的,也就是说,这个用例还停留在初级阶段,根本没有结合使用场景。可是要现在的我去思考用户的真实使用场景,我承认,我现在还很
  接下来我就想这个测试行业了。我和主管的差距、和老员工的差距,技术方面做个几年大家都差不多了,毕竟这个行业的技术也就这么多。那他们比我强的最核心的部分也就是业务。而且这个东西,在这个行业中越久,了解的东西就越多。如果那种不停的跳槽的人,这个积累是不断的被夭折的。也就是他们常说的经常跳槽的人最后就跳不动的原因。

  我们选择了职业做测试,但是我们更应该提前选好行业,通信也好,互联网也罢,这个东西和职业一样重要,因为在中国,技术还真的做的很辛苦,而且不懂业务的技术,真的不是什么好现象。我们还是早点清晰点认识为好。祝大家都有个好前程。

了解更多详细信息,欢迎致电 416-644-1998,或浏览网站www.NewJob123.com

来源:51Testing软件测试网采编

相关专题 »

    更多相关文章 »

    • 无忧资讯刊载此文不代表同意其说法或描述,仅为提供更多信息,也不构成任何投资或其他建议
    • 欢迎投稿,如发现稿件侵权,或作者不愿在本网发表文章,请版权拥有者通知本网处理
    • 凡用户自行发布的信息的合法性及真实性由发布者负责,与 51.CA 及其运营公司无关