我的软件测试之旅:(6)跳转——追逐新鲜事物的探险者

我似乎一直都很喜欢去尝试新鲜的东西,直到现在好像也是如此,只是动力没有以前大,尽头也没有以前那么足。当时被公司派过来做外包,一开始我还不情愿,被老板悉心教育后,半推半就地接受了安排,现在想来,倒是幸运。但之后,欣然接受邀请加入测试自动化小组,主动要求担纲测试框架维护者,也都是我自己的决定。再后来,得到执行回归测试,以及之后更新回归测试自动化脚本的工作时,我也都没有推脱。而那个大模块测试的任务,回想起来也是很艰巨,用开发来做比喻,就是需求还异常的不清晰呢,你就背负着在某个时候必须交货的重任。

  再后来,测试部门的老大担纲成立新的Linux部门,负责研发基于Linux操作系统的模块实现,招募新人的时候,我也主动请缨加入。不瞒大家说,当时最大的驱动力是因为在大学里选修的Linux系统课,考了两次才通过,工作中有这样的机会继续学习,怎么能放过它呢。只不过,对于测试工作来说,Linux操作系统和之前的专有嵌入式操作系统相比,只是一些操作命令和执行环境的变化,要测试的功能以及测试工作的核心都还是没有太多的变化,绝对没有说是对Linux系统的原理或是设计有了更深的理解,最多算得上 “唯手熟尔”。当然,也借此机会接触了Shell脚本,以及Linux下的众多命令,以及版本控制工具SVN(全称Subversion)等等很多的工具,在当时看来,可真的要算是比较新颖、前沿的软件开发工具。就拿版本控制工具来做比喻吧,之前公司里使用的是微软的VSS(Visual Source Safe),后来我们在测试自动化小组使用的是CVS(Concurrent Version System),而直到现在还有很多地方在使用CC(ClearCase)呢,我们在当时就可以用上SVN,真的是走在了时代的前沿。更不要提后来我们使用的xUnit和CruiseControl等很多的工具,不过这也都是Scrum试点项目时候的事情了。

====================================分割线================================

最新内容请见作者的GitHub页:http://qaseven.github.io/

时间: 2024-10-30 23:00:10

我的软件测试之旅:(6)跳转——追逐新鲜事物的探险者的相关文章

我的软件测试之旅:(10)贡献——开发项流程

开发项流程(Development Item Process) 当时的这个Scrum试点项目身负重任,其中之一就是要探索出在新型的敏捷模式下该使用何种的开 发流程,负责人就是当时的Linux部门经理,而我则捞到了负责测试部分流程的机会.整个试点项目的人员扩张速度不错,4个人的团队维持了好几个迭代,陆续有人加入,新的测试人员在大概是第四个迭代的时候才补充进来,而后逐渐扩张到两三个团队.这样的扩张速度对测试流程的确定来说非常好,一开始我可以只考虑自己的想法,不断地尝试摸索,可以很快地得到反馈然后改进

我的软件测试之旅:(2)转变——作为专职测试人员

后来我被直接派驻客户(诺基亚网络杭州3G研发中心,现诺基亚西门子网络杭州研发中心)现场,再后来被直接买下,成为了诺基亚的员工.也正是从派驻诺基亚那时起,我开始了自己作为专职测试人员的旅程.但编程这个活动一直都伴随着我,直到现在,这也是我从来都不认为开发.测试有着很清晰的界限的原因,欲知详情请继续往下看. 当时我们两家公司合作已经有一段时间,已经有数十位工程师在诺基亚干活,我们这一批人是专门为研发中心某个产品线的测试部门补充人力的.团队管理非常简单,我们自己公司的事务由自己的外包经理或者叫协作者经

我的软件测试之旅:(12)机遇——测试自动化培训师和教练

测试自动化小组尝试过另一款芬兰同事开发的新型框架,名字叫做robotframework,如今已经开源.这个框架本身使用Python语言开发完成,用来开发可接受性测试,是关键字驱动的测试自动化框架,支持多种测试用例的格式,我最喜欢的是使用表格的HTML文件格式.框架非常好用,各方评价都非常高,但是由于核心的开发者都在芬兰,杭州本地需要有人能够进行培训.辅导,才有可能做到快速地推广使用.于是测试自动化小组的同事参加了该框架的高级培训,以及如何进行入门级培训的培训,然后向杭州研发中心的其他同事提供培训

我的软件测试之旅:(3)同期——加入测试自动化小组

刚被派遣到诺基亚不久,确切地说是刚刚结束新员工入职培训的时候,小组长问我对测试自动化是否 感兴趣,我觉得好像蛮酷的,而且还可以被派到北京去参加两天的培训,英国人授课,何乐而不为呢.这个英国人就是Mark Fewster,<Software Test Automation>的作者,这本书被认为是该领域的开山之作,详细地描述了测试自动化相关的所有细节.战略和战术.于是就这样我加入了只有两个人的兼职测试自动化小组,之所以成立这个小组是因为在国外的其他研发中心使用测试自动化的效果非常好,所以要把它引入

我的软件测试之旅:(9)行动——简化测试文档和流程

现有的各种测试相关文档都很齐备,但是已经有较丰富经验的我感觉到其中的信息有很多都是不必要的冗余,老早就想把它们给简化简化.因为我这个人总觉得,如果是没有必要的或者不需要的信息,为何一定要放在文档里呢,直接不写不就行了么?放在那里总会吸引人去看一眼,然后心想"哦,N/A.",这也是时间和精力的浪费啊!保持文档干净整洁,只记录有意义的信息,不是很好么.而且,在原来的测试管理工具中,测试用例和测试计划,都有很多不同的版本,针对的是不同的产品发布版本.版本多也好的,但问题就是有的时候时间上最新

我的软件测试之旅:(5)难点——功能改进的测试

测某一个功能很容易,但是如果被测的对象是功能的改进(Improvement)呢?例如要提高性能(Performance),提高配额(Quota)准确度,过滤以减少不必要的日志数量. 当我拿到这样的功能需求规格说明书时,我一头雾水.其实我都算是二手,这个被测大模块(多个模块组成的一种服务型模块)的测试任务(算是个子项目)是从他人手中转交给我的,他人也是刚刚接受作为这个领域的测试负责人,上手不到几个月,连这个测试任务都还没有熟悉就转交给我.于是我只能努力地去获取各种可以提供参考的信息,首先我到测试管

《Google软件测试之道》—第2章2.1节SET的工作

第2章 软件测试开发工程师 Google软件测试之道 C:\Documents and Settings\Administrator\桌面\页面提取自- 9780321803023_book.jpg 在理想情况下,一个完美的开发过程是怎样进行的呢?测试先行,在一行代码都没有真正编写之前,一个开发人员就会去思考如何测试他即将编写的代码.他会设计一些边界场景的测试用例,数据取值范围从极大到极小.导致循环语句超出限制范围的情况,另外还会考虑很多其他的极端情况.这些测试代码会作为产品代码的一部分,以自检

《Google软件测试之道》目录—导读

内容提要 Google软件测试之道 每天,Google都要测试和发布数百万个源文件.亿万行的代码.数以亿计的构建动作会触发几百万次的自动化测试,并在好几十万个浏览器实例上执行.面对这些看似不可能完成的任务,谷歌是如何测试的呢? 本书从内部视角告诉你这个世界上知名的互联网公司是如何应对21世纪软件测试的独特挑战的.本书抓住了Google做测试的本质,抓住了Google测试这个时代最复杂软件的精华.本书描述了测试解决方案,揭示了测试架构是如何设计.实现和运行的,介绍了软件测试工程师的角色:讲解了技术

一个初级码农的测试之旅(一)——初识单元测试

前言 首先说一下我自己--一个码农,准确的讲我是一名在中国最大互联网公司搬砖的初级码农.我不是计算机科班出身,一年前进入公司的时候,从未接触过web开发,没有完整的学习过数据库知识,写不出一条完整的sql语句,甚至不知道js和css到底是怎么控制页面行为和样式的--这样的人为什么可以通过面试?反正不是因为我长得帅. 背景知识 文章最初,先介绍一下我们团队的产品--阿里云持续交付平台(crp.aliyun.com),是一个旨在服务阿里云上众多开发者的持续交付平台(你可能还没听说过,但不妨一试哦),