挨踢部落故事汇(29):开发转型测试是一种怎样的体验

原创
移动开发
Gavin有着20年的工作经验,拥有多个项目和系统的开发经验。最初从事Java系统开发,对比较流行的开源框架都有使用过。后来转测试方向,在测试领域带领团队实施兼容Web测试平台搭建,性能测试实施,自动化测试实施,移动端测试及测试技术探索。目前主要做管理和技术指导工作。

【51CTO.com原创稿件】Gavin有着20年的工作经验,拥有多个项目和系统的开发经验。最初从事Java系统开发,对比较流行的开源框架都有使用过。后来转测试方向,在测试领域带领团队实施兼容Web测试平台搭建,性能测试实施,自动化测试实施,移动端测试及测试技术探索。目前主要做管理和技术指导工作。

[[206040]]

Gavin·测试主管

从开发到测试,华丽转型

当时Gavin认为自己开发的一个很健壮的项目却被测试出许多Bug,因此他对测试产生好奇,同时也想扩充自己的能力面。这样在后续的一个偶然的机会中,他就转到测试工作上了。最开始他不明白测试的方法和过程,通过学习,培训和实践逐步了解。测试初期Gavin做的是测试技术支持,专门做测试软件的售后技术,以及性能,自动化测试。

因为从开发转过来比较容易上手,对于一些工作中遇到的开发人员不配合或不理解的情况,他比较能够理解,对于这样的干扰一般通过测试概念多沟通增强开发人员的质量意识来形成互相支持。如今Gavin在测试行业也已工作多年,后来慢慢带团队做全职测试了,包括功能的也会做。

之所以转型做测试,Gavin纯粹是当时的兴趣。但是未来开发和测试是统一的,技术发展的好,将来开发兼测试,测试也是开发,界限会模糊的。开发的压力往往在于工期紧,有些需要技术研究等,目的在于建设实现上。测试的压力也有工期的问题,但测试的责任压力是非常重的,如果有问题发生往往***责任人是测试,因此要求测试特别细致,同时需要考虑的功能也要全面,工作量并不比开发少。

相比以往,测试工作同样需要技术,而且对技术要求越来越高,就像自动化测试与开发无大的区别了。测试人员除了要理解测试理念,还要关注技术部分。这样能更好的发现和理解深层次的问题,比如:多线程。这样才能知道是否是并发的问题。包括一些框架的概念,有助于定位问题,还要了解数据库技术,可独立填充数据和做压力测试数据。

对于转型做测试的新手来说,Gavin建议一般可从技术支持岗位入手。比较容易,测试技术相对少,对于有过开发经验的人来说上手快,不必太多去了解复杂的业务。只是测试基本方法不了解,这个需要一点学习,相对来讲测试难度不大,可比较顺利开展工作。

测试中常见的问题列举两个:

***个问题就是如何对需求做案例,这个是测试人员的基本要求。通过系统的学习测试基本理论方法,如:边界值,等价类等。然后将这些方法进行工作实践。能快速进入测试工作。

第二个问题是测试工具的使用。需要理解这些工具的概念,原理。没有啥特殊的方法,只有通过文档和实践来学习。多看网上资料,看原始文档,测试环境验证,基本上都能掌握。涉及特殊环境下问题通过查文档和论坛等搜索资料来解决。

对解决的问题进行整理记录,积累提高。

浅析测试用例管理停滞的原因

对测试及开发过程和技术都了解一些,这次Gavin谈谈测试中测试用例的管理和体会。主要是分享一下测试案例的管理问题,这个一直比开发落后。自入行到现在他经历了几个公司,无论是做开发时期还是到现在做测试管理,在自身的体会中以及从多数同事和朋友了解到测试用例的管理基本上还是以Xmind和Excel为主,只有少部分公司采用了商业化方案或自研的工具。

相比开发的技术更新迭代频繁,测试在这个方向没有多少进步。造成测试用例管理停滞的原因是什么呢?Gavin分析主要有以下几个原因:

1、  商业工具费用高,一般公司不能负担成本

这些工具对于中小公司作为软件采购是不现实的,必要的软件工具都不一定是正版采购(没有歧视的含义),更谈不上这些昂贵费用的支出。多数情况下采用免费版本的拿来主义,尽量使公司的管理模式和软件有更好的匹配,也造成市场上各种软件流行,没有人能占据主流位置;

2、  自研能力有限,或成本投入不合算

自研需要开发团队来处理,对于测试自主开发工具往往在技术能力上也有欠缺;即使是自动化测试人员也是更多的关注于业务领域,对于纯产品类的研发技术深度和广度都需要积累;

3、  测试人力成本低,增加人力即可弥补问题

这是比较现实的一个因素,功能测试人员大多是刚毕业进入此领域,很少有在相同业务领域长时间做功能测试人员,很多是在3年左右熟悉业务后进入其他工作领域,有转做产品,开发,包括售前支持;也有很多在测试领域转向性能测试和自动化测试。这个过程中学习测试用例的设计,执行测试,也并未更多考虑到相关管理问题。

另外,相对开发来说能比较快速补充人力资源,个人任务量的减少也降低的对案例管理的需求。就管理层来说这个因素也对项目测试任务量的准确评估不必要求过高从而放松了对测试用例的管理要求;

4、  测试过程在公司的生产环节重视程度不够

相较于大公司的产品过程,大多数公司对测试环节没有深刻认识到它的作用,往往会出现“简单测一测”的行政指令,让本就资源不足的测试更加雪上加霜难以充分执行,造成***去掉的就是测试用例设计,没有了这个环节管理也就无从谈起了。即使是外包项目由于时间压缩经常出现测试用例的软件交付后设计。

虽有成本及其他因素,但还是希望用例的设计和管理能够得到充分重视和推广。有无好的解决方案呢?Gavin认为有以下两点:

1、  测试理念的推广,让大家充分了解测试,认识测试的重要性,保障测试的严格执行;

2、  管理工具的演进,通过工具技术的提升让用例管理更方便,更易用;

***做一点展望,希望测试工作能深化和发展,让测试充分为软件产品质量保驾护航。

如果你也愿意分享你的故事,请加51CTO开发者QQ交流群 627843829联系群主小官,期待你精彩的故事!

51CTO开发者交流群④群 627843829

 

 

 

【51CTO原创稿件,合作站点转载请注明原文作者和出处为51CTO.com】

责任编辑:何星 来源: 51CTO
相关推荐

2016-12-30 16:43:53

开发者故事

2017-01-19 13:40:56

开发者故事

2017-01-18 16:37:43

开发者故事

2017-11-28 14:15:38

开发者故事

2017-03-21 11:19:57

开发者故事

2017-03-01 15:57:48

开发者故事

2017-01-11 17:25:23

开发者故事

2017-07-06 14:59:27

2017-01-10 14:59:03

开发者故事

2017-09-15 11:39:47

2017-03-24 16:43:09

开发者故事

2017-10-23 13:15:51

2017-04-21 15:50:52

开发者故事

2017-03-10 11:32:49

开发者故事

2017-01-16 17:24:08

开发者故事

2017-01-18 11:07:20

开发者故事

2017-06-09 16:27:40

开发者故事

2017-04-25 15:39:30

开发者故事

2017-06-21 14:04:33

转型Android应用SDK

2017-01-05 15:30:59

开发者故事
点赞
收藏

51CTO技术栈公众号