qileilove

blog已经转移至github,大家请访问 http://qaseven.github.io/

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

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

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

posted @ 2012-08-06 09:43 顺其自然EVO 阅读(198) | 评论 (0)编辑 收藏

自动化测试阶段和软件设计思考

  序言:发现好久没写博文了,前段时间,发现很浮躁,别想办法的静下心来,踏踏实实的思考,踏踏实实的做事,一直也在写总结,但却很零散,现在理理思绪,这一段时间,自动化测试很多东西都已经上道了,测试人员也能够去独立完成很多自动化测试任务了,我能够将更多的精力放在软件工程的思考上,那就暂且以软件设计为题,说这一段时间的心得吧。也许认知有限,请指点。

  一、自动化测试的阶段认知

  很多人都将使用自动化测试工具当做了自动化测试,这样理解也没用错,个人现在看来,自动化测试的几种阶段吧

  1、使用者阶段,能够去使用工具,到能够利用工具完成自动化测试任务。这个过程中,也许你需要的是将工具的使用帮助看懂,能够结合你的部门自动化测试需求去使用好工具,对测试理论有所理解。

  2、半开发者阶段,能够基于工具进行拓展,例如:基于QTP和RFT等写一系列的框架,这种阶段,就要求你能够懂一些自动化测试思想了,且对工具的API和脚本语言有一些理解了。

  3、开发者阶段,能够脱离一些不灵活的工具,大千世界,各种测试开源工具的包能够为我所用,例如:你可以用selenuim操作web的api,abbot操作java界面的api或者写一个脚本驱动库调用CLI来作为一个对象操作底层,自己封装一层数据驱动和关键字驱动层,然后调用然后调用robot的结果api,最终也可以加上husdon来做一个测试任务的触发,根据自己的测试需求,应用各种开源包定制自己的自动化测试架构,当然,你需要能够很深刻的看待测试和自动化测试,能够对各种测试开源工具的原理有所理解(这种理解也是建立对软件开发知识的理解程度,例如操作系统、虚拟机系统、web服务等)

  4、设计者阶段,我以前,现在更是认为:自动化测试的大部分效益不是一定来源于一个多大的平台,多少个用例,而是来源于平时的各种测试活动中,无所谓自动化测试,也所谓手工测试,能够找出测试中的不足,能够抽象出测试中的某种理论或者模型。

  5、设计开发者阶段,我觉得,所谓的设计开发者,就是知行合一,能够快速的将繁杂的测试需求用自动化脚本替代,能够将一些测试的理论用软件工程的方式验证,能够基于某个测试任务能够快速的开发出易用性的自动化测试工具,不仅提出疑问,而且能够去抽象,去快速实践和证明。

  6、商业型阶段,所谓商业型,即是能够真正让整个领域产生巨大价值的推动,这个阶段,我也迷惑,但我相信肯定会有的。

  注:也许以上的阶段有的看似脱离了自动化,但是我觉得,自动化是为其测试理论服务的,无论自动化测试还是别的测试技术,都是为了推动测试商业化,能够让测试良好的运作起来。

  二、软件设计的思考

  再说一说对软件设计的思考吧

  很多时候,我们把软件设计想的太复杂了,从而让我们畏惧止步不前,最近在思考,领域是相通的,那么软件设计如何与我们最简单的认知相通呢。

  1、软件设计是否好比我们写文章,我们一开始学会文字,不管是学汉语也好,还是学英语也好,我们刚开始都是学语法,就好比软件设计,我们刚开始也是选择编程语言(java、C++、C),不同的语言有不同的应用环境,然后学习编程语言的语法

  2、写文章,我们学会了语法,认识了字,但是我们还写不出文章,我们要学习写句子,学编程也是,我们首先要学习写简单的线性代码,很多人认为一开始要学习高深的软件思想,其实不好,为什么C语言基础,因为C语言是教你怎么一步一步写句子,然后组成记流水账似的文档,虽然不好看,但实用和基础。

  3、之后,我们踏入了学习写文章了,这个过程,就像我们写一个系统,没有人能一开始就能写长篇小说,每个人都是从最简单的文章开始,我们写代码也是,必须一步一步来,有的人写文档需要打草稿,其实就相当于编程过程中,说的好听可以叫建模,其实就是定义一些接口,组成系统的架构。

  4、写文章有很多大纲模板,就相当于写代码有很多框架,你要写成什么样的文章,需要你对某一个情景什么样的感触,编程也是,你能写成什么样的系统,就需要你对业务和协议的理解程度了。

  5、所以,软件设计和写文章道理很是相通,领悟力和苦功夫都是必需的,需要我们钻研进去但又不能拘泥于其中。写文章要多写才能出真文采,则软件设计也是一样,要多实践,不要老是望而远之,找借口确实比实践来得容易的多,我们往往太看重结果而不敢上前,但是实际上闭着眼睛只要迈出一步,会发现原来这也是一件很容易的事情,刚开始的话,可以临摹,可以仿照,之后脱离自己写,到最后自己去思考架构,思考文笔,思考“写作”的系统流程。

  总结:其实个人觉得:很多人都说,厉害的测试人员不一定要写代码,其实我也同意这种说法,但是,我认为更厉害的测试人员他一定懂软件设计和工程,并且有了一定的理解力,测试人员可以是一个文章的读者,也可以是研究者,挑剔读者能读出文章的好坏,但是却无法指点,而研究者不仅知好坏,还能进行保障,会成为写文章之人的良师益友。对与不对,共勉~

版权声明:本文出自 散步的SUN 的51Testing软件测试博客:http://www.51testing.com/?382641

原创作品,转载时请务必以超链接形式标明本文原始出处、作者信息和本声明,否则将追究法律责任。

posted @ 2012-08-06 09:41 顺其自然EVO 阅读(351) | 评论 (0)编辑 收藏

QA是如何体现价值的(软件测试人生系列之四)

  作为一个软件测试人员,如何才能体验出自己的价值呢?

  首先,我们要明白什么叫做软件测试人员的价值。

  从经济学来讲,价值,是凝结在商品中的无差别的人类劳动。从测试人员来说,我们可以狭义的理解,价值就是我们凝结在在软件产品中的测试活动。所以,软件测试人员的价值,可以直接由产品的质量体现。

  而反映出一个软件测试人员的价值,就是你给产品的质量带来了多少正向的收益。

  从统计学角度,一个软件测试人员的价值可以由如下统计数据反映:开发测试用例的数量,执行测试用例的数量,发现缺陷的数量等等。

  从逻辑学角度,可以由以下作为参考:负责功能区域的优先级,测试用例的结构性,缺陷的深度和广度等等。

  从行为学角度,可以参考:任务优先级的安排,测试用例执行的顺序,缺陷跟踪的过程等等。

  从社会学角度,可以参考:对用户真实需求的贴合度,用户体验的反馈,与其他角色的交流效率等等。

  总之,一个软件测试人员的价值体现是由多个因素构成的。所以,如果想做一个高价值的测试人员,不光光是从技术角度等等方面单纯的考虑。一个好的技术人员,只是作为一个高价值的测试人员的必要条件,不是充分条件。所以对于很多单纯的想通过掌握很多测试工具来体现自己价值的从业人员来说,这是一个美丽的陷阱。

  所谓德智体美劳全面发展,如何让人把你认可为一个高价值的测试人员呢?

  个人认为主要是从如下三个方面体现:

  第一,个人能力。个人的能力包括了你的技术力,经验力,创新力,交流力等等,作为必要的条件存在。

  如何衡量你的个人能力呢?说实话,很难有个简单有效的方法。但是,有些公认的方法都可以实现。比如说,测试用例的质量,组织,结构和逻辑都很好。发现的缺陷都是直达源头。总之,个人能力好,就是大家对你的工作很放心,拥有很高的信任感。

  第二,团队能力。不怕老虎一样的敌人,就怕猪一样的队友。可是,作为团队的成员,如果你只是不停抱怨你身边的队友如何拖后腿,那么你缺乏最起码的团队精神。作为一个优秀的团队成员,你的作用不仅仅是完成自己的工作,而且要和全体成员一起达到团队成就。让每个团队中的人,能够发挥出自己的长处,避免自己的短处,鼓励激励。这不是一个团队领导自己能完成的任务,靠的是团队中的每一个人。你要做的是,让你的团队能力把你的团队推向更好。

  第三,管理能力。有句老俗话,中国人个个都是龙,凑一起就是虫。不过,这很少是因为你缺乏团队能力。而是缺乏管理能力。管理,有个人的自我管理,有任务的效率管理,有团队的执行管理等等。每个人都处于自我管理和参与团队管理和监督管理中,这样的团队,才是个有核心的团队,你才是个高价值的成员。

  其实,还有另外一种说法:

  第一,你对自己的认成度。第二,你对对团的认成度。第三,你对产品的认成度。

  综合来讲,我们作为从业人员,拿工资,干活,就是参与了价值的创造,剩余价值的剥夺和交换过程。对老板来说,你能创造比别人多的剩余价值,就是高价值的。 可是,对于每个人来说,追求自己高价值的认同,不仅仅是为了物质利益,也同时是满足自己的精神追求。

  如果你连最起码的精神追求都没有,那就谈不上什么精神愉悦感,更谈不上什么人生理想,纯粹是机械的为了生存而生存着。那你何必还去追寻如何作为一个有价值的测试人员呢。你已经抛弃了自己,不需要别人再来否定你了。

版权声明:本文出自 gigobin 的51Testing软件测试博客:http://www.51testing.com/?26810

原创作品,转载时请务必以超链接形式标明本文原始出处、作者信息和本声明,否则将追究法律责任。

posted @ 2012-08-06 09:41 顺其自然EVO 阅读(544) | 评论 (0)编辑 收藏

大话js代码静态检查

  1、背景

  首先必须承认,静态代码检查不能解决所有问题!比如说,QA不能指望着靠静态代码检查来发现rd的代码逻辑的bug。而对于javascript,可能就是代码某处少了个分号,或者是某些编码的bad –practice。这些问题可能很小很小,但是对用户体验足以造成巨大影响。因此,如果这种检查真的能发现问题,那么还是很有必要的。

  之后的一个问题是成本:为了发现一个潜在的问题,我们要付出多少精力?静态检查给我们的印象是:飞速的扫描一遍代码然后返回一大堆信息——就像一个可能蕴藏金子的沙堆,我们必须有耐心才能在这个沙堆中找到有价值的信息。显然这一过程的成本由以下两部分组成:代码扫描+判别有效性。第一个过程往往十分迅速,秒级而已。而第二个过程往往需要人工的介入,这是成本消耗的关键点。试想,如果静态检查返回过多无用信息,导致人工检查耗时过长,则这种检查的收益就得不偿失了。

  综上所述,静态代码检查面临的挑战是:准确性和低成本。

  2、初识静态检查规则与工具

  静态检查工具jslint&jshint

  为了应对QA前端js知识储备不足的短板,我们除了加强自身的学习之外,一个有效的方法就是“站在巨人的肩膀上”。

  1)jslint

  前端领域的大牛Douglas Crockford编写了JsLint,将他认为的那些重要的js编程实践作为静态检查项,他提出的某些编程实践也确实被人们所接受,因为这确实是容易引起问题的关键点(例如,在应该使用===的地方不要使用==等)。不过JsLint也存在一些问题,如它的某些检查过于严苛;遇到for-in语句后会停止检测;且非开源。。这些问题都使得人们对JSLint“敬而远之”。

  2)jshint

  为解决jslint现存的问题,有了JSHint这个项目,此开源项目作为JSLint的一个分支,允许用户自定义检查项,使用起来更加轻量级。有了JSHint,程序员就可以根据自己的编程习惯来定制个性化的检查策略。文献[1] 讲述了JSHint与JSLint的区别。

  JsHint本质上是一个js库(jshint.js)。笔者也曾膜拜此文件的代码,发现它实际上是一个js的词法分析器,里面定义了各种规则,然后对输入的代码字符串做切词和匹配,每发现一个“错误”(或是坏的编程实践)就放到结果数组中保存起来。因此,如果你会写js代码的话,完全可以在js文件中引用jshint.js。例如,你可以使用JSHINT函数来进行代码检查,如下所示:

  var result = JSHINT(source, options);

  其中JSHINT是一个全局函数,第一个参数source : 必选项。表示需要检查的代码,js或者json,可以传一个字符串或者一个数组。如果传字符串,需要用’\r’或者’\n’来分隔一行一行的代码;如果传数组,则每一个数组元素表示一行的代码。第二个参数option : 可选项。表示代码检查的配置项,具体的配置项含义参见文献[2],使用key/value字典表示,key就是要检查的配置项名称,value是bool类型。返回值:如果代码没有问题,JSHINT会返回一个true;否则返回false。当返回值是false的时候可以使用JSHINT.errors获取出错的原因,JSHINT.data包含了本次检查更详细的信息。另外,使用JSHINT.report可以生成错误信息的html报告。

  认识检查规则

propdescription
bitwise如果是true,则禁止使用位运算符
curly如果是true,则要求在if/while的模块时使用TAB结构
debug如果是true,则允许使用debugger的语句
eqeqeq如果是true,则要求在所有的比较时使用===和!==
evil如果是true,则允许使用eval方法
forin如果是true,则不允许for in在没有hasOwnProperty时使用
maxerr默认是50。 表示多少错误时,jsLint停止分析代码
newcap如果是true,则构造函数必须大写
nopram如果是true,则不允许使用arguments.caller和arguments.callee
nomen如果是true,则不允许在名称首部和尾部加下划线
onevar如果是true,则在一个函数中只能出现一次var
passfail如果是true,则在遇到第一个错误的时候就终止
plusplus如果是true,则不允许使用++或者- -的操作
regexp如果是true,则正则中不允许使用.或者[^…]
undef如果是ture,则所有的局部变量必须先声明之后才能使用
sub如果是true,则允许使用各种写法获取属性(一般使用.来获取一个对象的属性值)
strict如果是true,则需要使用strict的用法,
详见http://ejohn.org/blog/ecmascript-5-strict-mode-json-and-more/
white如果是true,则需要严格使用空格用法。

  不足

  牛人的东西很好,但实际使用起来发现有如下的问题:

  (1)静态代码检查规则配置需要修改Jshint的Js源代码,修改代价较高,且容易出错;

  (2)检查结果误报较多,且可读性差,找到真正是问题的结果需要排查几K的报错信息,效率较低。

  3、jshunter:一款基于jshint的静态代码检查工具

  为解决Jshint以上2个突出问题以及扩展更多的特性满足ECOM WEB类产品JS静态代码检查的准确性、有效性,基于Jshint和Rhino开发了Jshunter这一款工具用于js代码语法类错误检查。

  Jshunter提供的解决方案如下:

  (1)检查规则灵活配置。Jshunter支持将所有检查项放到一个配置文件中,用户可以通过true或false来自定义个性化的检查项,而不必修改Jshint源代码;

  (2)清晰醒目的结果报表。Jshunter从繁杂的检查结果字符串中提出关键信息,以Html文件的形式展现,对扫描结果严重程度给出LEVEL标识。非常适用于持续集成的开发模式,作为Hudson上的一个报表呈现;示意图如下:

  (3)支持Html内嵌js代码的检查,提高检查准确性。业界的Jshint不支持Html内嵌Js代码检查,存在漏检、漏测的风险。Jshunter解决了这个问题,不但能检查Js文件,还能检查Html中内嵌的文件;

  (4)扫描结果过滤,减少冗余信息,提高结果分析效率。通过黑名单过滤和错误级别设定,Jshunter支持用户设定结果提醒级别,目前支持warning,error和ignore,其中被设定ignore的错误不会在报表中呈现,减少冗余信息的查看与分析。

  具体说来,之前困扰的根源就在于我们解析jshint.js的环境是浏览器,受限于浏览器的环境,我们不能进行外部文件读写。如果需要将jshint命令行化我们需要找到这样一个环境:既能解析js代码,又能进行文件读写。因此我们找到了rhino——一个能解析js代码的java环境[4]。利用java环境,我们读取外部文件提取待检查的js代码,之后利用rhino运行大牛写的jshint.js。

  此工具依赖python环境,无需安装。使用也极其简单,只需要进入jshunter的主目录下运行:./hint.py /rest/file/path /path/to/check/*.js就可以了。这里hint.py是主程序的代码,/rest/file/path是该工具生成的报表文件名,/path/to/check/*.js是待检查的文件(支持单个文件和多个文件的代码检查)。程序运行后会根据主目录中的check.cfg配置文件进行检查,该文件各个检查项的具体含义见注释的描述。另外,如果不希望看到某些提示信息,可以将这些信息放到ignore.list黑名单文件中。也就是说,通过check.cfg和ignore.list,用户可以定制符合自己产品线特点的检查策略。

  4、小结

  本文介绍了和js代码静态检查技术相关的内容。代码检查的成本很低,且确实能发现一些潜在的问题。Jshint是业界一款开源的静态代码检查工具,但在易用性方面存在2个突出的问题,针对目前存在的问题,我们基于JSHint开发的一个命令行方式的代码检查工具jshunter,支持自定义的检查策略配置和黑名单过滤机制,并且能生成格式美观的报表。


posted @ 2012-08-02 14:10 顺其自然EVO 阅读(1110) | 评论 (0)编辑 收藏

软件测试的前途与职业发展

  (3)成功有先后,在于学习效率和实践能力

  软件行业是最具创新和发展的行业,新技术,新工具,新思想,新需求,新模式,日新月异,推陈出新。软件测试人员是一群智商出众的人群,如果再这些人员中快速脱颖而出,需要坚持持续学习,高效率的学习,并且积极实践。“要想人前显贵,必须人后受罪”,如果你还没有成功,自问一下你是否比大多数同学或同事勤奋认真。

  庸人抱怨工作太紧张,没有时间学习,庸人抱怨年龄大了,学不进去了。庸人总是找各种借口和抱怨,智者抓住一切机会学习。不妨主动问自己,每年购买和阅读多少本软件测试领域的新书,每周浏览多少国际和国内软件测试领域的网站,是否关注和阅读了国内和国际测试领域最新研究成果和文章。如果你还没有做到这些,请从现在做起,坚持3年,你的未来掌握在你的手中。

  优秀的测试人员总是在积极工作项目实践的基础上,学习软件测试的理论知识,学习软件测试目标,原则,策略,流程,方法,技术和工具。没有理论指导的测试实践是盲目的实践,测试理论是测试实践的抽象和归纳,是测试实践的智慧总结。优秀的测试人才既是实践高手,也是理论高手。

  (4)最好最简单的小事,才能担当好大事

  很多人刚开始从事测试工作是从执行手工测试做起的,根据测试用例,运行软件,分析输出结果,报告软件缺陷。庸人认为这件工作没有任何技术挑战,枯燥乏味,抱怨软件测试没有前途。这其实还是不正确的工作心态作怪,是眼高手低的表现。

  海尔公司CEO张瑞敏有句名言:“能把每一件简单的事情做好就是不简单,能把每一件平凡的事做好就是不平凡”。手工测试是最基础的软件测试工作,是培养软件缺陷敏感性的实践性工作,是最有效的发现软件缺陷的工作。不妨以学习的心态拷问自己:“我还可以更快的完成测试码?我还能更多的发现缺陷吗?”,从多方面提高测试工作的效率和效果。

  我来说说我刚开始做软件测试的情形吧。我1999年博士毕业后,先从事4年的软件编程工作,2002年初开始转入软件测试工作。我每天根据测试用例执行手工测试,由于缺乏测试工作经验,开始的时候经常遗漏软件缺陷,为此经常被测试经理指出,甚至遭受严厉地批评。于是,我购买了书籍学习被测试软件,分析缺陷的类型和特征。3个月后,我每天执行的测试用例数量和发现的有效缺陷数量,在我所在的测试团队名列第一,并且提出了改进测试执行效率的流程,后被测试部门作为后续测试项目的基础流程,半年后我开始独立带领一个项目的测试团队。

  (5)个人是否优秀,在于和谁一起奋斗

  古语讲“良禽择木而栖,贤臣择主而事”,一个人能够取得伟大的成就,需要良好的工作环境,需要宽广的事业舞台。新广告语说“打球找国梁,贷款找银行”,如果要提高乒乓球技艺,最好找奥运冠军刘国梁打球,如果要申请贷款买房,找大型银行最专业。

  软件测试工作同样如此,公司的文化对于测试人员的成长影响较大。准备从事软件测试的信任,寻找第一份工作时一定要对这家公司有比较清楚的了解,对比这家公司的规模,行业,理念,学习机会和发展空间是否与自己的职业发展吻合。不要随便找一家公司工作,否则,对于自己对于公司都是损失。

  如果工作若干年后,掌握了充分的测试技能,在寻求新发展目标时,如果当前工作单位没有合适的职位,无法提供更大舞台,可以主动走出去,到可以施展个人职业技能的新单位谋求发展。“出路出路,走出去才有路”,与优秀公司的测试智者为伍,增强的不仅是技能,还有解决问题的视野和信心,以及更宽广的职业发展空间。  软件测试的职业发展是个很宽泛的命题,不同测试工作经历的人有不同的观点,初入测试行业的新手与具有丰富测试工作经验的老手具有不同的认识。为了提高文章内容的针对性,本文将以对软件测试感兴趣,准备从事软件测试的人员,已经从事软件测试1到3年的人员为读者对象。文章将分析软件测试人员的职业发展方向途径,提出实现职业发展的方式方法。

  在信息技术产业快速发展过程中,软件应用领域不断扩展,市场对软件产品的质量提出了更高的要求。软件工程领域的实践证明,有效实施软件测试可以显著改进软件质量。软件测试是专业性、技术性、实践性要求非常高的工作,有效实施软件测试,需要依靠高素质的测试人才。

  一个时期以来,我国一些软件企业存在“重开发,轻测试”的错误观念,很多国内高校没有设立软件测试专业,因此,国内软件测试人才(特别是具有10年以上软件测试实践经验的人才)的紧缺已是一个无法回避的事实。由于软件测试是新兴的IT职业,很多测试从业者对职业发展感到迷茫,需要加强软件测试人才的职业化建设,明确职业发展的方向和途径,增强职业的自豪感和工作动力。

  1、软件测试是有前途的职业吗?

  笔者在为企业培训和大学教课过程中,经常有学员问到“软件测试工作是否有前途?”的问题。我总是反问一句:“你是如何理解工作前途的?”学员的回答五花八门,如图1所示。有人说工作挣钱多,工资高,有人说能够不断学到新知识,有人说工作受到社会尊重,有人说有到全球500强企业工作的机会,有人说今后不会被淘汰。

图1 什么是有前途的职业

  笔者认为,判断一个职业是否有前途需要以发展的眼光分析,既要看到短期的工资待遇,更要看到未来的发展空间;既要看到短期市场需求,更要看到长远的社会需求;既要看到职业的社会地位,更要考虑到个人的职业兴趣。如果幻想不经过努力,刚从事某个职业就可以获取高薪,受到社会尊重,那么软件测试肯定没有前途,而且世上没有任何职业是有前途的。

  软件测试工作是否有前途?我的回答是“优秀的软件测试从业者,测试工作有前途,而且前途很大”。软件测试顺应全球化和信息化发展趋势,符合我国信息化与工业化发展目标,是新兴的朝阳职业。优秀的测试从业者依靠软件测试的专业技术,可以获得职业的不断提升,随着测试能力的提升,薪资待遇不断提升,成为受人尊敬的测试专家。

  2、软件测试职业的发展路线图

  “人往高处走,水往低处流”。每个测试从业人员都希望通过努力,提高工作职位,实现个人价值。软件测试从业者有哪些职位可以不断提高和发展呢?我将软件测试职业进行全方位分析,测试职业发展具有多级别,多层次,多方向,多职位的“四多”特征。软件测试职业发展的路线图如图2所示。

图2 软件测试的职业发展路线图

  “级别”

  描述了测试工作的影响范围,从小到大的各个级别分别是“任务级”,“项目级”,“部门级”,“组织级”和“行业级”。最小的测试工作影响范围只能影响到某个具体的测试任务,最高的测试工作可以影响到某个具体的测试任务,最高的测试工作可以影响到测试行业的发展趋势。

  “层次”

  描述了测试工作在组织结构中的所在地位,从低到高的各个层次分别是“执行层”,“设计层”,“计划层”,“决策层”和“指引层”。测试工作最底层是软件测试的具体执行工作,最高层是测试工作可以指引测试行业的发展。

  “方向”

  描述了测试工作的技能发展倾向,可以分为“技术”和“管理”两个方向。“技术”方向是在测试技术、领域技术和软件工程技术的广度和深度方面进行发展。“管理”方向是向提高组织能力,领导能力,沟通协调方面深入发展。

  “职位”

  描述了测试工作对应的具体岗位类别是名称,职位类别可以分为“组员”,“组长”,“经理”,“总监”和“高管”,每个类别分别对应许多具体的测试岗位。

  测试工作的职业发展方向决定测试职业的职位发展,测试职业发展的不同职业级别和层次影响测试职位的类别,不同的组织具有不同的测试职位名称及职责要求。软件测试强调实践性和应用性,无论今后向哪个方向发展,达到哪个级别和层次,最好从最基础的测试组员做起。

  3、软件测试的职业发展之道

  追求卓越,追求成功是职业人员的永恒主题。由于人生阅历不同,价值观不同,每个人对卓越和成功的理解不同。笔者认为“卓越”是具有超出大众的杰出表现,“成功”是经过积极努力,实现设定目标后的自信状态和满足感受。那么,测试职业人员如何才能实现测试职业发展的目标呢?

  (1)思路决定出路,视野决定事业

  没有工作目标的人永远为有明确目标的人工作。目标影响未来,如果你从事软件测试的目标是成为测试经理,则很少有机会成为公司高级管理者和测试行业专家。学习和工作中遇到了困难和问题,如果缺少主动分析和探索的工作思路,依靠别人帮助,很难突破工作发展的出路。

  追求软件测试职业发展的过程像攀登高山,在山脚下和半山腰徘徊,永远无法体会在山顶“一览众山小”的意境,无法领略极目远眺的宽广视野。取得微小成绩沾沾自喜的人,无法产生继续探索的动力。“山外有山,人外有人”,不要把眼光仅局限于一个公司,一个行业,也不要只仅局限于国内,还要放眼全球。软件测试领域的创新主要来自美国和欧洲,向国外测试专家学习,才能了解自己的专业差距,明确职业前进的方向。

  (2)庸人抱怨,智者行动

  软件测试行业存在两种人:庸人和智者。庸人从来都是打工者的心态,一辈子都要替别人打工。此举一例:两个都是新入职的同事,也都是第一份工作,领导交给他们差不多的事情做,一个想“TMD,就这么点工资,让干这么多活?”,另一个则想“没想到新人都给这么多机会锻炼,一定好好干”,一年后,第一个成为第二个人下属,几年后第二个成为公司部门经理。

  智者把工作当作带薪学习的机会,主动思考,踏实工作。当你月薪2000元的时候,象月薪8000的人士那样工作,一年后月薪肯定6000多。每个公司和同事都有自身存在的问题,庸者抱怨公司管理混乱,同事愚蠢,无法学到新技术,智者把存在的问题看作工作机会,主动解决问题,赢得同事的尊重和领导的提拔。

  智者未来注定不平凡,无论干什么工作。机会无大小,只有时间早晚,智者永远不嫌弃小机会。软件公司是最公平的名利场,机会是自己干出来的,否则只能说你无能。心态影响结果,心态影响未来。


posted @ 2012-08-02 09:43 顺其自然EVO 阅读(199) | 评论 (0)编辑 收藏

如何进行软件测试需求分析

如何进行软件测试需求分析

  1、项目经理会根据前期调研的情况进行需求整理,召开项目组会议讨论需求整理的内容,如果是大项目的话,请一些有经验的专家来参与讨论。讨论的范围:用户提出的需求哪些是可以通过技术完成,需求当中有哪些情况未调研,比如说非功能性的需求,性能,安全性等。

  2、需求文档会经过评审,评审主要是看需求的范围是否明确清楚,有没有超出范围的,或有遗漏的需求。

  3、测试人员会依据需求文档和demo模型来编写测试需求,并设定优先级。

  4、依据测试需求,设计测试用例。这期的测试用例是比较粗的,等到有了具体的界面说再补充测试用例。

  5、将优先级高的用例进行评审看看有没有未考虑到的情况,补充修改。

  测试人员在阅读需求文档或看demo时,要能回签如下问题:

  1、系统要实现哪些功能,这些功能的输入,输出,操作步骤是什么。

  2、系统中业务流程,业务规则描述是否清楚,是否按照流程图就可以正常的执行,有没有缺少的节点。

  3、系统涉及的用户有哪些,用户都具备什么样的权限。

  4、系统对于非功能性的需求有哪些?这些需求描述是否完整,有明确的指标。

  5、系统的运行环境描述是否完整,按照这个环境是否能搭建出测试环境。

  6、用户典型的操作行为有哪些?常用的功能是什么,操作时长等。

  以上这些问题的答案如果在文档或demo中无法找到答案,就需要跟项目经理进行沟通来了解这些信息。

  当项目紧时,无法写出需求文档,我们的做法就是:从网上找跟该项目相似的一些资料进行整理,需要是帮助我们理解业务,然后项目经理组织会议讨论该系统做成什么样,要实现哪些功能,测试人员要充分参与交流,将自己理解的情况表达出来,不能只是被动地去听。

posted @ 2012-08-02 09:38 顺其自然EVO 阅读(369) | 评论 (0)编辑 收藏

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

  测某一个功能很容易,但是如果被测的对象是功能的改进(Improvement)呢?例如要提高性能(Performance),提高配额(Quota)准确度,过滤以减少不必要的日志数量。

  当我拿到这样的功能需求规格说明书时,我一头雾水。其实我都算是二手,这个被测大模块(多个模块组成的一种服务型模块)的测试任务(算是个子项目)是从他人手中转交给我的,他人也是刚刚接受作为这个领域的测试负责人,上手不到几个月,连这个测试任务都还没有熟悉就转交给我。于是我只能努力地去获取各种可以提供参考的信息,首先我到测试管理工具中去查找以前版本的测试计划、测试用例以及测试报告,从中了解被测对象的情况。我还会去阅读相应的开发方面的文档,包括设计文档、实现文档,甚至代码。

  只是看文档远远不够,里面的内容总是可能会存在二义性或是含糊不清的地方,这时候就必须要鼓起勇气去骚扰别人。测试专家、测试架构师、开发团队(好几个人呢)、开发团队小组长、被测大模块的技术专家,我全都骚扰过。如此高频度的造访必须得讲求方式方法,不然人家很可能感到厌烦,而后你就会发现他们经常地很忙没有时间。在问人家问题之前,自己要先做好功课,尽量避免问太简单和基础的问题,更不能重复问同样的问题。而且不管是通过邮件还是当面请教,都要注意说话要有条理性,要能够在较短时间内以较小的篇幅讲清楚问题的背景以及问题本身。

  在不断地交流中,我对被测大模块的理解也越来越深,要怎么进行测试的想法也越来越具体。写测试计划其实就是一个动态的过程,我先写出一个大概的样子作为讨论的基础,而后拿着它不断地和大家交流,询问他们的意见,然后再修改。根据测试质量管理的规定,我们的测试计划需要得到批准才可以进入执行阶段。得到批准需要我提前两周邀请相关人员,预约他们的时间参加审核会议;会议一周前要把相关材料发出,并且还要注意催促参会人员都要阅读这些材料;开会的时候基本不用担心,我只需要回答大家提出的疑问,如果有确实需要修改的地方,记录下来会后修改即可,会议的部分有专门的主持人负责主持工作

  测试对象是功能的改进,如何度量其改进,如何选择度量的对象和指标,如何在测试中去收集这些数据,以及如果设计测试结果分析的部分,都很耗费时间和精力,更难得是得到各方都比较认可的共同理解。不仅仅是在写测试计划的过程中,我修改了无数次,在审核会议上也收到太多太多的修改意见,以至于主持人不得不总结说我们还需要召开第二次会议重新审核。一般来说在审核会议上,如果修改意见不多的话,只需要修改好之后邮件发出更新后的版本,大家通过邮件再给反馈即可,只有当修改意见实在太多的时候,才需要按照正式流程再召开一次会议。幸好,第二次审核后,测试计划获得大家的认可通过批复。

  由于我们要求在设计的测试用例中除了写明测试步骤,每一个测试步骤都要给出建议执行的操作或者命令,这意味着其实在设计测试用例的时候,我们就必须得实地执行这些命令,或者执行一些命令组合,并从中选择有效果的部分放入测试用例中。而在这个过程中实际上要重复执行相同的命令、命令组合甚至测试用例很多次,绝对具备了将它们进行自动化的需要。我本来就同时担任着测试自动化小组的工作,也将测试自动化的理念运用到自己手头的测试任务上是顺理成章的事情,也正是在这个时候,我开始坚信“任何操作,第二次执行的时候就是将其进行自动化的时候”。我很懒,所以我总想着有没有什么操作是可以拿出来写成一个函数,或者做一个简单脚本,在执行某些操作前执行这个脚本省去我手工操作。当时,测试质量管理部门对于测试自动化是有标准的,只需要将测试用例集合中可以、适合、便于实现自动化的部分实现脚本化即可。而我的测试任务完成后,所有的测试用例全都有相应的测试脚本,就连那种本来是要走到实验室里去亲自把板卡从插槽中拔出来的测试用例,我也将它实现成为了半自动的测试脚本。后来有了远程电源控制的硬件后,可以通过断电来模拟物理隔离,从而实现了脚本全自动执行。当然再后来,测试自动化小组壮大变为测试自动化团队后,他们实现了Tcl/Tk语言连接外部设备,还可以操控AX400这类之前必须靠手工操作的设备,可以进行全自动化的承载性能测试了。

  这一次的测试任务帮助我学会了如何在信息模糊的情况下去界定测试边界,以及选择测试方法。饱受信息不完整以及不清晰的折磨,我也特别注重去改善这方面的状况,功能需求规格说明书、设计文档、实现文档等资料的更新改进都有我的贡献。在测试报告中我也写得格外详细,不只是记录当前执行的结果,一些很好用的命令或者测试技巧、注意事项,我也都一一写入测试报告,以及更新到相应的测试用例当中去。藉此我希望能够免去后续测试人员苦寻资料之苦,只要看到之前一个版本的信息既可,用不着再去寻根溯源浪费气力。不过,资料做得再全面也不够,还需要人的手把手协助,后来我把这一块的测试负责工作移交他人时,也费了不少心思去辅导对方,只可惜对方似乎心不在焉没有太注意吸收我的讲述,更可惜之后不久还未曾经历太多实战该测试人员即转战他方,知识的传承纽带再度断裂,后续接受的人有得重新去追根溯源一把。此话绝对不假,在我已经担任敏捷教练职务,也即是离开大模块测试岗位近三年后,还有人根据测试相关文档中的作者信息找到我问问题,只可惜我当时就算记忆力再好也无法保证提供给他的答案绝对准确,更不要说在这三年里,大模块自身也不断地有新功能增加或是缺陷被修复,我的记忆已然不再是第一手信息。

相关链接:

我的软件测试之旅:(1)起点——作为软件开发人员

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

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

我的软件测试之旅:(4)并行——自动化回归测试

posted @ 2012-08-02 09:29 顺其自然EVO 阅读(221) | 评论 (0)编辑 收藏

Loadrunner随机生成15位数字串

Loadrunner随机生成15位数字串

PS:本人在51testing和sina blog上的文章全部为原创转载请注明出处!!

今天看到一个网友的问题,是想生成一个15位的数字串来进行参数化输入,要求如下:
1、前4位均是0436
2、其余的是11位的随机数
原帖地址:http://bbs.51testing.com/viewthread.php?tid=89018&page=1&extra=page%3D1

拿到问题,我思考了一下,前4位使用固定值很好办,唯一的问题就是生成随机数了;
生成随机数而且用lr实现,目前我知道2种方法:
1、使用c语言的rand()函数
2、使用lr的参数类型中的random number来生成

因为要生成固定的位数,所以我决定使用lr的random number方法;另外也是我想到rand()函数实现起来非常麻烦,~解决问题为主。

我的回复如下:
##############
1、在参数表(Parameter List)中新建一个参数(Parameter),命名为"num"
2、选择参数类型(Parameter type)为随机数(Random Number),
3、选择参数范围(Parameter range)为最小为1,最大为99999999
4、在随机数格式(Number format)里选择“%08lu”
然后引用类似为:
web_sumbit_data(
……
……
"card_id=0436000{num}";
LAST);
说明:随机数按照位数在c语言里不好实现,所以我选择了lr的参数化来生成。但是lr的参数化里最多只能生成8位数字(这个我还不知道能不能改),所以你要求有11位数字的时候,我就把你要求的固定的"0436"变成了"0436000",这样参数化以后就可以生成类似"043600012345678"的15位数字了。
##############

回复完毕,又仔细想想发现自己很傻,既然lr支持字符串和参数在一起被引用,那么为什么只用一个参数才解决呢?而且解决的也不彻底,还有3位数是固定值。。发现自己还真的很笨~~~~

更好的实现方法是创建2个或者多个随机数类型的参数(Random Number Parameter),这样,就能把随机数的参数化位数增加到11位甚至更多;~想参数多少位就多少位,嘿嘿

还是以15位的这个问题来说吧:
如图再增加一个随机数.

然后引用方法类似:
web_sumbit_data(
……
……
"card_id=0436{num1}{num}";
LAST);

搞定!!


再增加随机数

再增加随机数

相关阅读:

posted @ 2012-08-01 17:46 顺其自然EVO 阅读(3699) | 评论 (0)编辑 收藏

页面性能测试

  一、页面性能测试概述

  页面性能测试则是针对于页面性能优化而开展的一种性能测试,目的是对Web系统的页面进行测试以确认系统页面是否会影响系统的性能并为页面的优化提供依据与建议,最终提升系统的整体性能表现,提高用户体验满意度。可见,Web系统页面性能测试是相对Web系统后台测试的另外一种性能测试,是Web系统性能测试的一个重要部分。

  二、页面性能测试必要性

  相对于C/S架构的应用系统,Web应用系统所有数据都需要从服务器端下载,虽然浏览器有缓存机制,但客户每次访问仍然需要下载大量的数据。特别是用户对系统要求越来越高,除了要求功能完备,对界面的美观、易用性也提出了更高的要求,越炫的页面也就意味着页面中要包含更多的脚本、样式表、图片和Flash,页面的数据量也就越大,这对Web系统的性能提出了极大的挑战。

  曾经有个在线打印服务的应用提供商说他们的系统不需要关注系统性能问题,没有必要进行性能测试,因为他们可以购买足够多的服务器来支撑系统;不少业界同行也认为只要有足够多的服务器资源,性能就不会存在问题。其实不然,他们都只关注到了应用系统的后台性能表现,而忽略了页面对系统整体性能的影响。举个例子,当一个页面中包含几百个请求,页面中没有经过优化的javaScript文件、CSS 文件与图片件大小达到10MB,即使当前只有一个用户在访问该系统,页面的访问速度也会慢得惊人,纵使增加再多的服务器也不见得会有明显的性能提升。

  可见,对Web应用系统的页面进行性能测试和优化是非常有必要的。只有通过对页面的性能测试,发现页面存在的性能问题并根据性能测试结果进行页面优化以提升页面的加载性能,从而提升系统的整体性能。在应用系统高并发访问时,更能体现出Web页面优化后所带来的系统整体性能提升效果。

  2种方式来提升你的web 应用程序的速度:

  ● 减少请求和响应的往返次数

  ● 减少请求和响应的往返字节大小。

  减少请求和响应的往返次数:

  HTTP缓存是最好的减少客户端服务器端往返次数的办法。缓存提供了提供一种机制来保证客户端或者代理能够存储一些东西,而这些东西将会在稍后的HTTP 响应中用到的。(即第一次请求了,到了客户端,缓存起来,下次如果页面还要这个JS文件或者CSS文件啥的,就不要到服务器端去取下来了,但是还是要去服务器上去访问一次,因为请求要对比ETAG值,关于这个值,我将会在下次翻译中介绍其作用)这样,就不用让文件再次跨越整个网络了。

  缓存相关的请求头

  为了提高性能,微软的IE和其他的web客户端总是想尽办法来维持从远程服务器上下载下来的本地的缓存。

  当客户端需要一个资源(html,css.js…),他们有3种可能的动作:

  1、发送一个一般的HTTP请求到远程服务器端,请求这个资源。

  2、发送一个有条件的HTTP请求到服务器,条件就是如果它不同于本地的缓存版本。

  3、如果缓存的拷贝可用,就使用本地的缓存资源。

  当发送一个请求,客户也许会使用如下的几个HEADER

  减少请求肯响应往返的字节大小:

  1、使用更少的图画

  2、将所有的CSS浓缩到一个CSS文件中

  3、将所有的脚本浓缩到一个JS文件中

  4、简化你的页时间

  5、使用HTTP压缩

三、页面性能测试工具介绍

  第一种是通过HTTP代理的方式来截取客户与服务器之间的通讯。

  此类的工具非常的多,如:

  charles是一个HTTP代理/ HTTP监视器/使开发人员可以查看所有的计算机和互联网之间的HTTP和SSL/ HTTPS流量的反向代理。这包括请求,响应和HTTP标头(其中包含的cookies和缓存信息)。

  charles界面清爽,采用中国的瓷器为logo,给人的感觉简洁高雅。而且使用也非常简单。进入下载页面,选择你适合你的版本,安装也非常简单,一路“next”就OK了。

  点击工具栏上的“红色”按钮,就自动的记录你浏览器访问的所有网站。

  Fiddler是一个Web调试代理,记录所有的HTTP(S)之间的计算机和互联网的交通。提琴手允许您检查交通,设置断点,和“捣鼓”传入或传出数据。菲德勒包括一个强大的基于事件的脚本子系统,并可以使用任何。NET语言扩展。

  Fiddler是免费软件,可以调试,从几乎任何应用程序,支持代理,包括IE浏览器,谷歌Chrome,苹果Safari,Mozilla Firefox中,歌剧,还有数千交通。您也可以像Windows电话,iPod/ iPad和其他流行的设备调试的交通。

  Fiddler2相比Charles功能要更强大一些。当然了,如果单单把他们理解成页面性能测试工具有此片面,尤其Fiddlers2功能强大,当然了,我也没有深究,在此就不过多评论了。


posted @ 2012-08-01 11:10 顺其自然EVO 阅读(232) | 评论 (0)编辑 收藏

锁的来由和使用

  对于开发系统级别软件的朋友来说,无论你是主动的还是被动的,锁的应用都是少不了的。很多人用锁,可是却未必知道锁的前世今生,什么时候用锁,什么时候不用锁?该用什么样的锁?今天我们就来对这个问题说道说道。

  (1)为什么用锁?

  之所以会用锁,其根本目的在于对公共资源的保护。比如说,我们希望对某些数据的操作是连贯的、具体的。否则,如果这些脏数据如果被再次引用的话,肯定会引发不可预计的故障。虽然从代码上看,我们的操作可能只是一条语句,但是它所对应的汇编操作很有可能是由几条命令合在一起完成的,所以中间发生任何的切换、中断都会出现问题。那么,有哪些变动会导致这种情况发生呢?其实也不复杂,主要就三种,

  a)中断

  b)抢占

  c)smp

  (2)哪些场景需要互斥处理?

  上面说了三种情形,其实就是代码有可能被打扰的三种情况。首先,中断的发生是随机的,如果中断中使用了和内核段同样的数据,那么肯定会惹麻烦的。同样,抢占也是一个很重要的问题。所谓的抢占,其实就是说线程在中断返回、资源释放、抢占点有可能被系统切换出运行队列。有些时候,线程的数据可能需要与另外一个线程进行分享,如果我们此时不想和别人分享,那么关闭抢占就可以了,系统也不会进行线程调度处理了。最后一种是多cpu情形,本质上和多线程有关,不同的cpu运行不同的线程,所以对于数据的访问必须是互斥的,我们必须利用硬件提供的汇编语句来对代码进行互斥处理,自旋锁就是用的最多的一种方法。

  (3)有哪些锁的使用方法?

  为了提高数据的访问效率,人们设计了各种各样的锁。所有这些设计的目的只有一个,就是在保持数据正确性的条件下尽可能将锁造成的影响降到最小。这从linux内核发展的轨迹可以清晰地看出来,越是高级的锁,越是具有特定的应用场景,越需要小心处理。就我个人了解,当前使用较多的锁主要有下面几种:

  a)关中断

  b)禁止抢占

  c)自旋锁

  d)原子操作

  e)读写锁

  f)互斥量

  g)信号量

  h)事件

  (4)使用锁需要注意些什么?

  在所有代码里面,关于多线程的编写其实是很难的,主要是因为多线程考虑的情况多,另外一方面就是代码调试的难度很大,所以在模块设计的时候一定要慎重。在平时编写的时候,多用成熟代码,这样才会在软件质量上有所保障。不过,在锁的使用中,还是有一些规则是要注意的,比如,

  a)中断的代码是不能使用带有schedule函数的锁

  b)抢占只能防止本cpu上线程之间的互斥

  c)使用自旋锁的代码段不能太长,否则影响系统性能

  d)互斥量只能被本线程释放,在嵌入式实时系统中可能会遇到优先级反转的问题

  e)使用信号量最合适的地方就是pv操作

  f)原子锁计数比较合适

  g)事件功能和网络编程中的select很像,可以响应多个情形,但是无法保证这些事件有序

  h)锁成对使用、有序使用,做到这些可解决一大部分的死锁问题

  i)没事别写多线程,就是写也先把单线程的代码完善好了再进行考虑和移植

  j)在锁中使用指针需要十分小心

posted @ 2012-08-01 10:49 顺其自然EVO 阅读(200) | 评论 (0)编辑 收藏

仅列出标题
共394页: First 上一页 302 303 304 305 306 307 308 309 310 下一页 Last 
<2024年11月>
272829303112
3456789
10111213141516
17181920212223
24252627282930
1234567

导航

统计

常用链接

留言簿(55)

随笔分类

随笔档案

文章分类

文章档案

搜索

最新评论

阅读排行榜

评论排行榜