【软件测试】一个冬天,如何从手工测试转职成为测试开发?


在回答这个问题之前我们先回答其他一些问题。

测试人员的职能是什么?


我认为是质量保障。一个测试人员,无论你是手工点来点去,还是用自动化进行一些模拟操作,他们的核心职能都是相同的,那就是保证项目或产品的质量。如果你能保证你负责的模块缺陷数少,并且基本没有什么问题会遗留到生产环境或用户环境的话,那么你是一个优秀的测试人员。至于你用什么方式去达到这个结果的,手工还是自动化,这些都不太重要。关键的问题是,你需要在规定的时间内保障项目/产品质量


规定的时间内往往是加班的罪魁祸首,一般来说如果项目工期比较紧急的话,项目的管理者大多会砍掉测试的时间以便项目能够及时交付。所以很多时候测试人员没有足够的时间去进行完全的反复的测试,只能凭借直觉和经验来重点验证新功能或核心功能,而一些不太重要的功能可能在回归时被忽略。在有限的时间内,有经验的测试人员会优先选择测试变化的功能,也就是代码发生了增改的功能;另外还有一些测试人员选择对团队中能力较弱的开发人员开发的功能进行重点测试(好吧,我以前就是这样,牛人写的代码往往缺陷不多,那些能力平平的人做的功能往往缺陷买一送一,惊喜不断,甚至出现改一个bug送几个bug的情况),从长远上看,这种策略对项目质量是有帮助的


如果你能在保证产品质量的前提下捞到一些闲暇的时间,那么你可以去研究自动化测试,接口自动化测试,app专项测试和性能专项测试。对于一般的测试人员来说,这些技能是加分项,能让你在找工作的时候给人很好的第一印象,以及获得不错的议价能力。

总而言之质量管理能力觉得你薪资的下限,其他测试技术相关能力觉得你薪资的上限


测试开发人员的职能是什么?

其实也是质量保障。无非就是保障的手段更加的技术化。

上文我们也说过,测试的时间周期在很多时候是整个项目时间周期缩短时首当其冲的牺牲品,测试的时间往往是不够的,物以稀为贵,也就是说测试的时间是相当宝贵的,如果能加快测试的速度,降低用例回归的成本,将以前的选择性测试(测一些重点功能)变成全面的回归测试+重点功能的人工干预,那么项目的质量可能会比纯人工测试要好

所以一些自动化的加快回归速度,降低每次回归成本(比如100个自动化用例,如果回归100次,那么每次回归的成本相对来说还是很低的),那么是可以一定程度上解决时间不够的问题的。

测试开发同学质量保障的手段可能不如手工测试同学那么直接,测试开发同学一般是通过提高测试效率来帮助产品改进质量。以前在同一个时间周期,手工测试可以回归100个用例,现在测试开发的同学可以让这个时间周期内回归到的用例数达到1000个,效率提升了10倍,由于效率提升而节约的时间就可以投入到其他的质量保障手段中去,比如code review之类的,质量保障的方式更加的立体化,更加的有层次感。

总之测试开发同学的关键字是效率。

手工测试如何转测试开发?

回到正题

其实很简单,当然过程会比较痛苦,那就是提升效率。

尽可能的把费时费事的测试工作用机器或用一些更加有效率的方式去实现。

比如性能测试,如果没有自动化的加压工具,性能测试很可能是一群人在三更半夜统一思想听统一号令一起点网页的工作。性能工具极大的提升了性能测试压力发生的效率,降低了成本和难度。这就是测试开发很好的切入点。

手工测试同学可以这样的慢慢培养自己的测试开发意识,潜移默化的完成转变

找到可以进行效率提升的点。比如每次测试之前都要手工的去系统里创建一些测试数据,这些工作是不是可以用自动化的方式去做呢

学会一门编程语言。学会跟计算机交流,让计算机去做那些需要重复反复去做的事情;

学会使用一些测试工具。比如selenium——学会操控网页,比如postman——学会测试一些restful的接口等等;

根据业务的需求,自己开发一些测试工具或平台。比如公司需要统一的压力发生平台,能不能试着用jmeter的集群模式去搭建一个呢?

因此我们可以看出手工测试转测试开发的过程是一个思想转变和技术提升的过程。

我是不是应该苦练测试开发技能,然后换一份专职的测试开发工作?

我的建议是不要总是想着换工作,争取可以把自己的手工测试职位变成是测试开发职位,把学会的技术技能运用到目前的工作中去。

其实你目前的工作并不缺少测试开发的场景,你只是缺少发现这些场景的意识。

分享一个我朋友的故事。


2013年的秋天,他在某外包公司做手工测试,外包公司的流程管理很严格,手工回归的工作很多,而且也很辛苦。那时候是ibm的测试人员写测试用例,他们回归,他们写另一个模块的测试用例,让ibm的测试人员回归。1个项目有2个公司的外包测试团队参与,是那时候的常态。

很凑巧,那时候他们公司有一些qtp的授权,反正也没人会,他就在工作之余(一般是白天,晚上要验bug,白天开发改bug)勤学苦练,好不容易把qtp学会了一些,然后用录制和加检查点的方式搞定了一个小系统的回归测试。就这样开发白天改bug,他们晚上用机器去回归,现在想想那时候回归很挫,还要有人盯着,防止qtp自己跑崩溃,但这还是比自己点来点去看着要爽。

后来他们有很多的项目都使用qtp进行回归,他也成了专职的qtp自动化测试人员,那时候还没有测试开发这一说,不过现在看来他应该是一条腿迈进了测试开发的大门。

所以尽量把自己学到的技术应用到现在的工作中,而不是想着去换一份专职的测试开发工作。

这个故事后来的发展是:他涨薪了,涨了一倍,跟开发的薪水一样

当然这是个正面的例子,转型失败的例子也很有多,无非就是能力加运气,缺一不可。

当然不是每一个人都有我朋友这样的机遇的,但是走上测试开发是测试人员一个比较好的后续准备,那么如何才能安稳的走上测试开发的道路呢,乐搏学院提供软件测试全部知识,开阔你的测试道路吧

原文地址:http://blog.51cto.com/13848818/2323582

时间: 2024-11-10 09:53:21

【软件测试】一个冬天,如何从手工测试转职成为测试开发?的相关文章

徐盛:软件测试新趋势从超人时代到智慧测试时代

本篇文章来自于HPE和msup共同举办的技术开放日HPE测试中心总监徐盛的分享,由壹佰案例整理编辑. 从HPE全球软件测试中心历史看未来的测试 HPE IT信息服务部实际上是整个IT部门下的一个测试中心,主要是对内服务管理内部的IT,不对外做交付.我们有大概1500个系统,我们负责的是这些系统每天的开发.升级.维护工作. 最早是从1996年开始在印度做HPE测试中心的实践,2002年开始中国上海的测试中心的实践.最开始做的主要是一些功能化的测试,因为HPE IT内部的系统五花八门,Web.SOA

软件测试-测试开发需要学习的知识结构

努力成为一个优秀的测试开发从业者,加油!!!       一些视频链接:我这有一些软件测试的视频,你可以点开看看. 转行互联网测试需要哪些技能? - 假装在测试的回答 - 知乎 作为一名软件测试人员,有哪些网站是你应该多多关注的,哪些书籍是你必须要看的? - 假装在测试的回答 - 知乎 白盒与黑盒测试什么区分 1.黑盒测试 黑盒测试也称功能测试或数据驱动测试,它是在已知产品所应具有的功能,通过测试来检测每个功能是否都能正常使用,在测试时,把程序看作一个不能打开的黑盆子,在完全不考虑程序内部结构和

软件测试培训 高级测试/测试开发基本技能列表

软件测试培训从事软件测试许多年,想必很多人都有感到迷茫不知所措的时候,人生的十字路口有很多,该如何抉择呢?有人成功转型,QA.项目管理.配置管理.当然还有技术型,性能测试.自动化测试.测试开发,而想要延续走技术型路线,不可避免的就是钻研开发技术,说的通俗些就是coding的能力.软件测试所涉及的知识面很广,所以有些开发不要一味的黑测试诋毁测试的能力,当然不否认,现在大部分黑盒测试仍然局限在点点点,但技术需要提升,想要晋升为高级测试或者测试开发,所需要的能力变慢慢有所体现出来,测试所带来的价值也应

测试开发之路--一个小小工程师的回首

关于背景 学生时代 高中:精力都放在魔兽3冰封王座上了,种族UD,全校第一.各个班级和周边网吧都挑战遍了.结果当然是不学无术的我高考失利,上了三流大学. 大一:因为酷爱电脑游戏报了计算机系.大一期间同样不思进取,打了一年的魔兽世界,60年代,全服第三工会中第一DPS. 大二:这一年幡然悔悟,痛定思痛,洗心革面,痛改前非,重新做人.花了一年时间把英语4级过了(底子太差...花了这么久). 大三:这一年学java,学校跟一个培训机构合作在学校办班.我跟一帮同学报名并组了个项目组,接接活,日子挺愉快.

xcode创建一个工程的多个taget,便于测试和发布多个版本

背景:很多时候,我们需要在一个工程中创立多个target,也就是说我们希望同一份代码可以创建两个应用,放到模拟器或者真机上,或者是,我们平时有N多人合作开发,当测试的时候,在A这里装了一遍测A写的那块,当需要测试B写的代码时,我们需要到B那里去装一遍,如果只有一个target的话,那么A的将会被覆盖 还有些时候,我们需要确定到底是A的问题还是B的代码出了问题,这时候都需要建立一个工程能够编译多个版本出来,下文就介绍怎么在一个工程中编译多个版本 好了,闲话不多少,下面正式开始: 我们建立一个默认的

如果你恨一个程序员,忽悠他去做iOS开发

如果你恨一个程序员,忽悠他去做iOS开发.不管他背景是cobel还是 java,送他一本iOS开发的书.这种书最好是国人写的,容易以偏概全一点,相比洋鬼子的书,更容易学到皮毛.这叫舍不得孩子套不着狼,谁叫你恨他呢. 然后你就会发现他没事会琢磨一下在虚拟机里运行一下mac OSX.Mac高大上啊,一用就上瘾.慢慢的,你发现他不再满足虚拟机了.程序员嘛,一般都对性能敏感的.他开始琢磨黑苹果了.这是发病的第一个阶段.这个阶段他会乐此不疲,殊不知也耗散着精力. 第一个阶段玩了一段时间后,他开始受不了了.

"iOS push全方位解析(三)【译文】"——一个极简的demo,并测试一下push

这是一篇来自raywenderlich的教程,内容翔实!结构简单透彻.讲解循序渐进.文章质量上乘!是一篇难的的博文!使用半瓶的英语水平翻译了一下: 1. push的概述 2. 生成push证书,生成Provisioning Profile 3. 一个极简的demo,并测试一下push.(本博文) 这里查看原文 一个极简的demo 到目前为止,上面还不是做的还不够让人兴奋,但是那些准备工作还是很有必要的.本教程像你详细展示了如何生成证书,因为每天都会用到证书,而且没有证书push就不好.刚才你刚搞

80. 投奔怒海——一个Domino老程序员眼里的Java开发

这是一个以键盘鼠标为谋生工具已十多年的人初次进行专门的Java开发的体验和感受,对于Java程序员,这些也许早就习以为常,那就把这当成从一个来自不同世界的新人眼里看看他们自己的工作:对于我的Domino同行,这些体验或许将来有更多共鸣的可能. 在加入到这个Java产品开发团队之前,我的Java开发经验如下:十几年前跟着一本Java入门书做练习写的几个Applet,Domino项目开发中写的几个读写数据库和外部邮件的代理,XPages开发中的少量Java Beans和一个流程库.除此之外就只剩下对

一个基于.NET平台的自动化/压力测试系统设计简述(可独立运行,提供源码)

AutoTest系统设计概述 AutoTest是一个基于.NET平台实现的自动化/压力测试的系统,可独立运行于windows平台下,支持分布式部署,不需要其他配置或编译器的支持.(本质是一个基于协议的测试工具),前面还有一篇对其功能的简单介绍[http://www.cnblogs.com/lulianqi/p/4773146.html] AutoTest用于发布的部分有2个部分,主程序[AutoTest.exe]及分布式部署程序[RemoteService.exe](用于将将测试业务分布式部署到