-
测试别被敏捷忽悠
2014-06-20 18:54:44
这篇帖子原先发表我在博客园的blog里,还有一些讨论,想想还是在这里也发一份吧。这个应该是几个月前的事情了。
个人对敏捷一直很关注,其实很正常的啦,作为一个资料的深度收集爱好者,在满眼都是敏捷的今天,想不关注都不可能啊。
腾讯无线研发部副总监张鼎(dylan)写了一篇《反思:别被敏捷忽悠》,里面的观点我个人很喜欢。这个应该是对dylan的访谈整理,也许会和dylan的意思有偏差,但假设不是记者太无良,dylan的思想应该是反敏捷的,至少对敏捷思想有很多的质疑。提炼一下dylan的观点:
- 敏捷方法会拉低质量标准。
- 传统瀑布和敏捷方法没有本质差别。
- 互联网软件和传统应用型软件开发没有本质差别
- 在一些情况下,文档优于沟通。
上面的观点是我总结的,具体内容大家可以看原文,有误读的地方请原文作者谅解。
其实对于敏捷,我的观点一直很矛盾,对开发人员这应该是好的,但是对于测试则未必。
敏捷从根本讲应该是开发方法,不是方法论,所以很多人可以把敏捷嵌入到CMMI、RUP等开发流程框架内。换句话说,敏捷说了开发人员应该怎么做,但是没有说比如测试人员做什么,也就是说,无论XP还是Scrum等,基本都没有考虑测试人员在其中应该做什么。当然了,有些开发人员会说,还要测试人员做什么,有TDD、BDD等,测试人员滚一边去玩吧。但是测试人员真的可以缺席吗?
测试人员其实一直努力的在希望嵌入到敏捷开发过程中,比如段念的《什么是敏捷软件测试》,朱少民的《究竟什么是敏捷测试》等,甚至有专门的书籍说敏捷过程中的测试,但都像是CMM的效颦TMM一样,没有太多的信服力。感觉就是在敏捷过程中,强加了一个测试角色,做和传统测试差不多的活儿,看上去很美,但是总觉得相当的不协调。
测试是什么,测试是质量的控制和度量。就和帖子最开始的dylan说的一样,敏捷实际在降低质量基线。敏捷的说法是从根源上,通过TDD、BDD、用户现场确认等方法,解决质量确认问题。认为通过用户认证了,就是好的。但是用户不是专业的测试人员,对质量等的认知,其实是有一定偏差的,敏捷方法貌似总在有意无意的忽视这种质量偏差。
在软件工程中,有一个基本的观点,不要让开发人员测试自己的程序,但是在敏捷过程中,测试角色是大部分由开发人员直接兼任,当然带包装的--测试驱动开发,但实质还是开发自己负责自己部分的质量问题。产品的生产者是开发,质量的提供者是开发,难道质量的确认者仍然是开发?或者再加上用户?这样做是否会出问题?
从根本说,敏捷方法的研发者都是开发出身,对测试我想未必有深入的了解,敏捷方法其实规定的都是开发人员的行为,但是问题就在于没有留出测试验证的位置, 测试人员即使挤进去,也有很多的力气无法使用上。比如敏捷测试过快,是否有必要重复的做开发人员做过的测试;敏捷变更太多,测试人员能否跟上变更的节奏等等。
我这里仅仅是提出问题,并没有解决问题。敏捷开发我还是仅从大家的资料中了解分析,测试也更多从理论和别人的文章中获取敏捷测试相关内容,也许我的整篇文章观点都是错误的,但是至少希望能给测试人员以思考,至少能提出一个让我认为合理的、可以容易确认执行的敏捷中的测试过程,也就不枉我打这么多的字了。
-
宋词分析改编版(ruby)
2014-02-02 23:50:10
很久之前写的了,在别的地方,blog多就总忘,还是在这里留一个备份吧。现在是ruby2.0版了,有时间还是应该重构一下。还有,我专门买了一个移动硬盘安装ubuntu,笔记本也用wubi安装了一个,所以现在主要在ubuntu下学习ruby,坑就少多了,大家也可以学习一下ruby。上一次我写的宋词分析,是在Windows环境下的,缺省编码是GBK(936),所以在处理UTF-8的时候,需要转换为GBK,再进行处理分析。不过现在已经是ruby1.9版了,那么就改一下,在uft-8下处理程序,主要就是把原宋词文件内容从gbk编码为utf-8,再进行相应的处理,dos下需要chcp 65001转换为utf-8编码,再执行才可以看到正确结果,否则就是乱码。我用的SciTE,在Options->Open Global Options File中,code.page=65001,output.code.page=65001去除前面的#,就可以正确处理utf-8文字了。嗯,Windows就是麻烦,Linux和mac一直想玩玩,但是单位无法上网,需要联网的东西太费事了。还有就是改写为utf-8版后,计数和gbk版的不同了,gbk版的,和原文的计数一致,utf-8版的,一是计数多了,二是很多后面的也提到了前面,不知道为什么,也许是gbk->utf-8转换的时候,一些文字出现问题了吧。#coding: utf-8require "iconv"NUM1 = 2 #分词长度NUM2 =500 #显示大于多少的记录def splitword(s,l) #分词,s是字符串,l是字符分词长度lt = s.lengthk = Array.new0.upto(lt-l) do |i|k<<s[i..i+l-1]endreturn kendt = Time.nowx = Array.new #记录分词结果的数组File.open("ci.txt", "r") do |file|file.each do |line|line = Iconv.conv("UTF-8//IGNORE","GBK", line)line.chomp!column = line.split(/,|。|!|?|、/) #使用标点分割column.delete_if {|i| i.length >10 } #去除大于10个字的语句column.each do |col|splitword(col,NUM1).each{|i| x<<i} if col.length>NUM1 # 分词endendendh = Hash.newh = x.inject(Hash.new(0)){|hash,x| hash[x] += 1; hash} #把数组内容进行计数为hashh.delete_if {|key, value| value <NUM2} #去除hash中小于指定数值的部分y = Array.newy = h.sort {|a,b| b[1]<=>a[1]} # 从大到小排序y.each_index {|i| puts "#{i+1} #{y[i][0]} = #{y[i][1]}" }puts "运行时间是:"<<(Time.now-t).to_s<<"秒" -
近期我所遇到的一些测试情况
2014-01-29 10:26:40
我在的公司,可以说是一个作坊,10年前,我来的时候,还没有专职测试人员,那个时候公司就过了cmm2,我现在都不清楚没有测试人员怎么过的。我来公司后,测试部就组建了,有的时候人多,有的时候人少,多的时候7、8个人,少的时候快2年时间,就我一个测试人员。当然了,从上面情况也能看出,公司也不重视测试,我个人懒的换地方,我所在的城市,专职测试可以去的地方也不多,也就这么对付着过来了。公司还是有一定规模的,大概70多开发人员,cmmi3、iso9000等等也都有,看上去比较正规,当然了,在我内部人的看法就是作坊。去年11月的时候,我最后一个手下离职了,又变成了光杆司令,当然了,我个人都习惯了,就和主管领导说,给我人啊,虽然没有活儿,但是真的要测试,总不能我一个人做吧。嗯,测试工作一直是不饱和的,去年我的实际工作量时间,不超过6、7个月吧,全年很多时候都空闲着,我个人平时喜欢看小说,这也是我不舍得走的原因之一吧,很清闲,可以做自己喜欢的事情。其实我去年一年,做的最多的事情不是测试,是给各个项目写测试文档,平时的时候,各个项目组,都不喜欢做测试,只有在项目验收的时候,我测试需要出具测试用例和测试报告,才会找我。或者做测试,但是测试到一半,1、2轮的时候,开发人员就以种种理由闪人了,比如其他项目组要用人,或者去现场开发等等,所以我去年只测试了一个完整的项目,大概1个月的时间,其他都是扔了一大堆的缺陷在哪里,没有理会了。当然了,这和公司的情况也有关系,第一,我们主要做行业软件,大部分的时候,开发人员都是在现场开发,边开发边上线,那边就直接用了,很多时候可能不希望测试人员插手,至少测试提出的一大堆问题需要改不是;第二就是很恶心的任务单制度。我们公司在建立项目的时候,就给出了项目的费用和人力计划,要报销等,必须在额度内,但是有一个问题,大家也都知道,开发人员几乎不可能在进度的设定内完成,所以进度一定是不够的,这种情况下,谁还会考虑测试人员?我一直和项目管理部的人说,测试要独立出来,不要走项目内经费,要不测试根本不可能有活儿干,那边一直在推搪。我去年干的活,还有一些费用没有报销,因为超过额度了,研发经理说等下次再做2期的时候,给我转过去,但是2期什么时候,天知道。上面的介绍一下背景,下面就是近期遇到的一些情况。公司有一个大项目,实际这两年,公司都指望这个项目,所以人力什么的很充足,还是老规矩,现场开发,去年要结项,去写测试用例,需求文档之类的是不用指望了,就是按照软件写吧,反正他们的说法,有就行,看都不看。当然了,写文档的过程中,测试人员一定会发现一些问题,实际软件已经在使用快1年了,个人觉得还是比较稳定的,问题算不上太多。写好后给他们了,至于改不改,和我无关了。2014年,这个软件在其他的地方销售成功,根据客户的要求,要做些改动,所以相当于原版本的一个升级。在2014年项目管理部出台了一个决议,说全部项目的计划、需求都需要评审,既然按规矩来,那就做吧,评审计划。既然有计划评审,当然在评审过程中,我作为测试要争取自己的利益和资源,其实当时开了一个下午,项目经理、我、项目管理部、QA,内容不多,大部分时间都在抢资源。虽然测试现在只有我1个人,但是还是说要3个人、1个半月(计划是2个人,1个月)。中间的细节就不说了,其实这个软件是一个很大的项目,160多个模块,业务流程也很复杂,他们开发了快2年,我对原有的版本比较熟悉,新的版本也就是写测试用例的1个月,勉强算了解。计划定下来了,人没有啊,找人。在我最后一个手下离开的时候,我就和主管领导说要招人,他的意思是,你测试现在也没有工作,即使招到人,也许过两天就跑了,所以等有工作的时候再说,你看开发组谁没有工作,到时候就支援你。嗯,这次有工作了,就从项目组暂时找了一个人,计划充当测试人员。还少人员啊,就和做软件的项目组说,测试没有人,到时候能否支援,项目经理也答应了。一切看起来挺好的吧。正好,有一个其他部门的人,强烈要求做研发,我们的研发副总看,不好推脱(小老板招的人),就扔给我了。嗯,现在有两个测试小白等着我浇灌了。既然这样,写ppt,做培训资料,后来看到有项目经理对我的工作比较感兴趣,那更好啊,开大培训,就介绍我们系统测试的工作。其实我写的ppt很少内容,只有13、4也,我的ppt原则是简略版的,只要说的内容,就不写,ppt只是一个引导。我第一次讲培训,效果不知道怎么样,反正很多人,20多吧,各个部门都来捧场了,我还以为讲2、30分钟就可以了呢,结果讲了1个半小时,我自己都怀疑自己怎么那么能说的。ppt主要内容就是:质量是用户的要求;测试是质量控制和度量,终极目的是验证需求和确认质量;,测试的工作是发现问题;一个软件开发出来后,有一个质量上限,测试的工作是接近上限,但是无法到达,提供质量的方法是开发和质量保证,测试做的工作主要是验证和修补,对质量的提高没有决定性作用;质量成本是有数量级的差别的,越到后期,处理成本越高;任何问题,等到系统测试发现和处理,全部都晚了。反正说了很多,效果如何不清楚,培训后,我问了很多人,都说挺好,我想可能还是客气话居多。当然了,这个是科普性质的培训,后来我还专门花了一天的时候,给两个新人,做具体测试内容应该如果做的培训,效果如何现在还没有开始测试,不清楚。原先说了,我和软件的项目组说要借调一个人,现在人齐了,本来我想测试人员越多越好,就去和研发经理L确认人员,你知道他怎么说吗?一周时间够不够,我当时就思密达了(他们在外面开发,没有听我的培训)。我说,你们的软件开发了两年,不说别的,你培训客户需要多久。L说,客户都知道业务啊,培训怎么用就行了。我说,老大,除了我,另外两个都是新人,业务都不熟悉,1周时间恐怕你的软件做什么他们都未必清楚。反正最后说了很多,他的人我也就不指望了。还有,本来我的计划是在年前,让他们去现场熟悉一下原版软件,这样年后测试其他地方的升级版,大概业务也能熟悉,但是万恶的任务单,他们就是不下,我也无法派工。未完待续。回家喽.................... -
测试过程3步走
2012-07-27 22:41:42
在我们公司,还是作坊式的开发,需求、设计基本没有,都是客户说几点要做的,其他都看开发人员的想象力。
这样在很少的需求文档,并且没有设计等内容的情况下,测试如何进行测试?
下面就以我近期测试的一个项目为例,说明在这种情况下,我如何处理这种情况。
我接手测试的是我们公司内部开发的一个项目管理系统,需求都是由项目管理部的经理提出,现有流程都是走的纸质单子,想把各个项目组的流程电子化。
我们测试并没有介入前期,所以直到交给我们,才看到具体的软件样子。
同期给我们的,只有数据库结构设计,其他莫有了。
开始第一轮测试。
第一轮测试,我主要是确认软件功能都是正确的。
项目管理软件,主要由3个部分组成,一是立项管理,就是销售或项目经理建立项目,指定项目经理,项目类型,预计人员,里程碑,项目回款等等。立项管理这里还有项目管理部等的审批,以及修改等内容。二是任务单,主要是确定做项目的人员,每个活动都对应到具体的人上面,根据人员计算项目花销。三是借款报销,主要就是在项目的框架内,进行直接借款或通过任务单借款和相应的报销。
功能算不上太复杂,大概6个大模块70个左右功能。
第一轮,主要是了解系统由哪些功能组成,而且确保每个功能的正确性。比如每次操作,我都会去查数据库,看是否数据进行了相应的变更,通过数据库的设计,可以更好的了解程序员是如何想的,程序是如何运作的。
每一个功能都需要进行了解和确认,比如立项的时候,有间接费用、直接费用、管理费、利润等等数据,每个数据都需要了解从哪里来的,以及如何计算,确保计算结果的正确性。
另外,收集需求的时候,他们既然把大部分的东西都写在自己的笔记本上,而不是整理出来,所以很多时候,都需要开发人员具体的解释。
总之,第一轮过后,我保证对数据库的每个表,每个数据都心里有数,知道每个操作会影响到哪里。
第一轮提出问题后,经过开发人员的修改,进入第二轮。
第二轮我不很关注功能,因为第一轮基本确认了所有的功能,保证其有效性,第二轮我主要从业务逻辑着手,发现其中可能存在的漏洞。
比如很多办理业务的过程中,需要先查询再办理,但是很多时候,查询结果只有入口,没有出口,这样随着项目的更新,查询就几乎失去了意义,因为很多都不是办理需要的。
还有像是任务单借款报销,这里并没有和任务单很好的结合,实际借款和任务单并没有太多关联。
这样的业务漏洞,在第2轮提出了很多。第二轮我所做的就是深入业务,了解各个业务是如何运作的,从整体上把握整个的项目。
在第2轮,终于从开发人员那里弄来了需求列表,上面都是项目管理部提出的对软件的要求,发现了很多不符合要求的地方,看文档日期,半年前的需求,一些确实是问题,一些后来在他们的笔记本上又变更了,其实后面第3轮,还要来了补充的需求,挤牙膏一样,很多东西他们自己都忘记有了。
第三轮我关注接口。
经过第二轮理顺业务,对整个系统应该熟悉了,就需要考虑一个地方变动,会对其他地方有什么影响。比如项目里面有客户,那么我把客户删除了,对项目有什么影响。
或者我提交了1个任务单,但是对此任务单多次借款和报销,是否会有问题。
另外就是磨一些比较细的地方,比如立项有4种类型,不同的类型对借款报销等的影响等等。第一轮也做过相应的测试,但是第3轮的时候,随着系统的熟悉,实际补充了很多的用例对可能有问题的地方做更细致的测试调整。
这样经过三轮测试,功能、业务、接口都没有问题了,剩下的就是慢慢的和开发磨了,很多时候一个问题经过多轮没有修改,或者原先一些问题没有发现,但实际都不影响大局。这个可能再经过3~5轮,项目就大概能收尾了。
测试用例我是第2轮才开始写的,因为刚接触软件的时候比较兴奋,还是第2轮沉淀和熟悉的时候,写用例更适宜,而且经过第2轮,软件很多地方有很大的调整,第一轮即使写了,也都需要变更。
还有就是一定要从业务的角度思考系统,功能是死的,但是为什么有这个功能,每个测试人员都需要了解。数据的流向也需要切实的把握,我是很喜欢用截图软件截图的,因为随时进行比对,看哪些内容有了变化。
大概就是这些了,只是自己的一点经验,可能大家有更好的测试方法,不妨也都说出来进行参考。
-
项目管理师我的复习方法
2012-01-05 19:55:37
最终成绩63,58,45,作文低了些,但是能过就好。
我们单位报了100多的中项和高项,高项大概20多人吧,现在知道的就过了6个了,今年下半年的题感觉比较简单,通过率应该会不错。
下面就说说自己的复习经历,给以后过高项的人作为参考。
9月中旬报名参加的项目管理师考试,报名后,就在当当买了四本书,分别为《信息系统项目管理师考试全程指导》、《信息系统项目管理师历年试题分析与解答》、《信息系统项目管理师案例分析指南》、《信息系统项目管理师考试-考点突破、案例分析、实战练习一本通》,前三本是清华大学出版社出的,考试项目组编制,最后的一本通是电子工业出版社出的,希赛网出品。《信息系统项目管理师教程(第2版)》也想买的,但是当时当当网没有货,就没有买,不过网上也能找到此教程的扫描版。
我还是建议大家多买几本书的,虽然书里面的内容都差不多,但是看一遍就相当于复习了一遍,如果买3、5本,就相当于复习了3、5次,至少了解了相关的内容。我先看的一本通,因为里面的内容比较少,每章只看到典型试题分析,实战练习题可以留到最后的时候考试前当模拟题,因为开始的时候,自己对项目管理的相关内容还是不怎么熟悉的,直接做题未必有什么好的效果。
十一回家的时候,就拿的案例分析指南,主要是因为比较薄,不占地方,当小说看就行了,这本书真的不错,建议大家都买一本,对案例题通过有很大作用。十一后,单位请的贾育老师来给我们做考前培训,总共5天的时间,系统的讲了中项和高项的相关内容,自己看书和听课感觉还是不同一样,感觉有老师讲解,对重点难点的掌握能更好,特别是计算题,自己看和听课差别很大。而且贾老师给了我们很多的资料,后期的时候,我都学习的这些资料。
这个阶段,我主要看历年试题,这本也是应该必买的书,主要就是了解大概会考哪些部分,通过哪些方式去考,做模拟题怎么都不如真题的。
看完真题,我最后才看的全程指导,这个时候,就是比较细致的了解各方面的内容,当然了,教程和全程指导感觉内容相差不多,买其中一本即可,不需要两本都买。
书都看完,剩下的就是看资料,贾老师给了很多资料,我个人在网上也基本把能找到的资料都下载看了一遍,看完后就是疯狂的做题,先做再对照答案,我把能找到的题都做了一遍,大概500道以上,最后两周的时候,做2010年2次和2011年上半年的考试真题,这个时候,做题就比较有把握了,2010上半年47分,下半年53分,2011上半年计算题没有,其他能做的63%的准确率。这样上午的选择题,个人觉得就差不多了。
接着就是准备论文,项目管理师网(cnitpm)押题为质量管理和人力资源管理,我个人觉得能考质量和沟通,最后就准备了质量、沟通、人力资源三篇论文,其中沟通一文用笔写的,主要找找写字的感觉。
最后一周,就是看书背东西,因为短期记忆的效果会比较好,这个时候,我才把电子版的教程看了一遍,感觉里面的内容其实不如全程指导。最后一天的时候,就是看论文,因为觉得自己的论文还是比较薄弱,没有什么信心。
剩下的就是考试了,这次的题很简单,觉得比上半年好很多,是否上半年都比较难,下半年就容易些。上午选择题,我考试当时确认基本对的就有42道,其他的都是蒙的,英文差的太多,基本都是蒙的。下午论述题,第一道就是送分的计算题,但是花了很久,大概40多分钟吧,主要是怕把图画错了。剩下的两道论述,第一道范围变更的还可以,第二道外包差了不少,主要是原先没有特别的关注外包内容,都主要看九大过程里面的内容了。
论文题压对了,虽然这次没有写大的范围,只写过程的其中一点,但是身为测试人员,写质量控制那还是比较简单的事情的。
大概就这些了,分数最后出来也算可以,做一下记录,以给后来人提供一些经验。 -
花朵数(ruby)
2011-12-28 17:53:55
花朵数,也可以称之为水仙花数,水仙花数 一个N位的十进制正整数,如果它的每个位上的数字的N次方的和等于这个数本身,则称其为花朵数。比如153是3位数,那么1^3+5^3+3^3=153,所以153是水仙花数。
其实我原先写过的,但是只是3位的,这次扩充到任意的位数,但实际上,7位数就要30秒了,8位数没有等到返回。
大概就是3≤N≤7,而且没有比较好的方法可以优化此过程。
#coding:utf-8
N = 4
(('1'<<'0'*(N-1)).to_i..('9'*N).to_i).each do |i| #从10...到99... 循环
n = 0.upto(N-1).inject(0) { |sum,j| sum + i.to_s[j].to_i**N} #N次方加和
p i if n==i
end
优化一下:
#coding: utf-8
N = 6
('1'<<'0'*(N-1)..'9'*N).each do |i|
n = 0.upto(N-1).inject(0) {|sum,j| sum + (i[j].to_i)**N }
puts "#{N}"<<"位花朵数是:"<<"#{i}" if n== i.to_i
end
-
蒙特卡洛方法求π值(ruby)
2011-12-26 17:54:44
就是在一个正方形里面随机投掷,看在圆内的数目是多少,可以求得PI值。
#coding:utf-8
N =999999 # 投掷次数
sum = 0
for i in 1..N
x = rand()
y = rand()
sum+=1 if x*x+y*y<1
end
p 4*sum/N.to_f
-
一道好玩的题(ruby)
2011-12-26 17:51:36
原文在http://www.cnblogs.com/BrainDeveloper/archive/2011/12/24/2300279.html
有N个数,编号1到n。按照以下规则进行删除数,求最后剩下的那个数。【1<= n <= 1000000000】
规则:
1 . 如果当前序列的个数大于1,则删除所有序列中第平方数的位置的数。
2. 将进行1操作剩下的数,重新排在一起,重复操作1,直接当前序列数为1个数时,这个数就是结果。
#coding:utf-8
NUM =99999 #最大值
a = (1..NUM).to_a
def value(arr) #去除平方位置的数
for i in 1..Math.sqrt(NUM)
arr[i*i-1] = nil
end
return arr.compact!
end
n = Time.now
until a.length == 1 #算是递归吧
value(a)
end
p Time.new-n
p a -
东风何处是人间(ruby版)
2011-12-15 17:48:43
在今年3月份的,就看到这个帖子《东风何处是人间》了,对宋词进行分词计数,当时就保存了这个帖子,想以后有时间写个ruby版的。后来就忘记了
近期这个帖子大火啊,也终于抽出时间写ruby版的了。
个人水平有限,程序写的很糟糕,至少比原文的看着复杂多了,不知道是否能有ruby高手给大家写个示例。
数据:《全宋词》文本
#coding: utf-8
require "iconv"
s1 = Iconv.conv 'gbk','utf-8',","
s2 = Iconv.conv 'gbk','utf-8',"。"
s3 = Iconv.conv 'gbk','utf-8',"!"
s4 = Iconv.conv 'gbk','utf-8',"?"
s5 = Iconv.conv 'gbk','utf-8',"、"
NUM1 = 2 #分词长度
NUM2 =500 #显示大于多少的记录
def splitword(s,l) #分词,x是字符串,l是字符分词长度
lt = s.length
k = Array.new
0.upto(lt-l) do |i|
k<<s[i..i+l-1]
end
return k
end
x = Array.new #记录分词结果的数组
File.open("ci.txt","r") do |file|
file.each do |line|
if line.length<500 and line.length>10
line.gsub!(s2,s1) #把标点都替换为",",再统一进行分割
line.gsub!(s3,s1)
line.gsub!(s4,s1)
line.gsub!(s5,s1)
line.chomp!
column = line.split(s1) #用逗号分割
column.delete_if {|i| i.length >10 } #去除大于10个字的语句
column.each do |col|
splitword(col,NUM1).each{|i| x<<i} if col.length>=NUM1 # 分词
end
end
end
end
h = Hash.new
h = x.inject(Hash.new(0)){|hash,x| hash[x] += 1; hash} #把数组内容进行计数为hash
h.delete_if {|key, value| value <NUM2} #去除hash中小于指定数值的部分
y = Array.new
y = h.sort {|a,b| b[1]<=>a[1]} # 从大到小排序
y.each_index {|i| puts "#{i+1} #{y[i][0]} = #{y[i][1]}" }
-
南京出差归来
2011-12-10 20:31:15
工作10年了,第一次出差。
我所在的公司外包了华为的项目,外包商除了我们,还有其他公司,华为说有预集成的步骤,让我们公司的人去南京华为和其他公司一起进行接口相关的工作。
在预集成的过程中,华为方也会进行一些测试活动,要我们这里出测试用例和自动化测试脚本,所以作为测试人员,就和开发人员一起去了南京。
在南京呆了一周,第一天住的宾馆,后来就在公司的南京办事处住的。
我们住的地方比较好,在新街口,商业区啊,做地铁就可以去华为。
华为的门禁比较严,要在公司外面的接待处用身份证换贴纸,在大楼前台,还需要用贴纸换工牌。出门的时候,我们的笔记本还需要填电子单才能出来。
华为的南京分公司还是比较大的,他们说主要负责华为的软件研发,大概1万多人。
不过华为身为大公司的一些东西,真的很让人无奈。比如我们在会议室,既然只有一个3孔插排,也只有1根网线,在那里一周,既然没有人有能力给我们拿几个插排和几根网线,也没有纸杯之类的东西给我们,第一天的时候,我们都没有带水,一天没有喝水,渴死我们了,至少在我们公司,什么事情说一声,要什么马上就能借来。
华为公司里面还是不错的,环境很好,里面的设施也都比较新,比较好,至少厕所很干净,也没有看到缺纸,蹲位也很多,还有专门的开水房,至少在我们公司,我是不指望这些了。
华为的食堂很糟糕,我们自己花钱吃了35元的自助,什么都没有,在我们这里35元可以吃自助烤肉了。
剩下的都是华为的员工带我们吃的,换了几个窗口吃过,都很难吃。特别是大米,干、硬,味如嚼蜡,真怀疑南方人怎么吃得下去。
华为员工还是不错的,接待我们的是SE,感觉类似售前和市场,具体就不清楚华为如何定位了。华为员工工作都是比较努力的,一直让我们的开发人员给他们讲我们的软件,不懂马上问,基本午饭和晚上下班都会耽误一些,我们出来的时候,都晚上6、7点多了,他们说基本都9点以后才会回家。嗯,我们都是正点下班,公司不怎么鼓励加班,加班也没什么好处,我们除非没有串休了,否则也没有愿意加班。
南京下了几次馆子,吃了肥肠鱼,感觉就是水煮鱼哈,回味鸭血粉丝也吃了,确实比较好吃,至少比我们这里好吃多了。还吃了一次火锅,东西到不算很贵,菜都按小盘,1~5元,肉19一大盘,但是调料真的是太难吃了,麻酱感觉像刷锅水,白腐乳油乎乎的,他们吃火锅不蘸料的吗?蘸料的话,这么难吃的调料怎么吃下去的。
南京给我的感觉路都很窄,路边还都停着车,到处都是小摩托(电动自行车),开起来不管不顾直愣愣的,还总带着人,在北方,冬天这么开车,保证南京人至少损失一半。还有就是南京的红灯,到处都是路口,而且等待的时间都7、80秒,坑爹啊。
南京还很潮湿,我睡的枕头潮乎乎的,最后没有办法,我用的线衣当枕巾睡的。
南京的出租车相对也比较贵,9(2.4)+2,比我们这里贵了近一倍了。
去逛了南京的夫子庙,很小的地方啊,都是些买工艺品和特产的,大部分一看就都是伪劣产品。
南京的盐水鸭吃了,感觉并不太好吃,很普通的味道。其他的特产都买了一样,南京的十二钗糖都是粉末,夫子庙茴香豆和状元豆,都很硬,很难吃。果然如我们在南京的办事处员工说的,南京啥特产都没有,都太难吃了。
嗯,大概就这些了,感觉还是家乡好啊。
-
张老师的生日问题(ruby版)
2011-11-25 19:49:27
一个烂大街的题,前两天刚好看到别人解这个题,用c++实现的,网上还有很多的java版的等等,我就改成了ruby版的,ruby版的程序算是比较短的了吧,还是有些函数式的影子,而不是纯粹的ruby化面向对象。
小明和小强都是张老师的学生,张老师的生日是M月N日,2人都知道张老师的生日
是下列10组中的一天,张老师把M值告诉了小明,把N值告诉了小强,张老师问他们知道他的生日是那一天吗?
3月4日 3月5日 3月8日
6月4日 6月7日
9月1日 9月5日
12月1日 12月2日 12月8日
小明说:如果我不知道的话,小强肯定也不知道
小强说:本来我也不知道,但是现在我知道了
小明说:哦,那我也知道了
请根据以上对话推断出张老师的生日是哪一天
ruby版程序,就是按照条件排除,把数组内值非设定的都为nil,剩下的就是张老师的生日了。
month = [3,3,3,6,6,9,9,12,12,12] # 月份
date = [4,5,8,4,7,1,5,1,2,8] #日期
#单一日期对应月份的值全部设置为nil
date.each_index do |i|
month.each_index { |j| date[j] = nil if month[j] ==month[i] } if date.count(date[i]) == 1
end
#剩余的日期,去掉重复的
date.each do |i|
date.each_index { |j| date[j] = nil if i == date[j] } if date.count(i) ==2
end
#把日期为nil的对应月份也设置为nil
date.each_index do |i|
month[i] = nil if date[i] == nil
end
#去掉重复的月份
month.each do |i|
month.each_index { |j| month[j] = nil if i == month[j] } if month.count(i) ==2
end
#月份nil对应的日期为nil
month.each_index do |i|
date[i] = nil if month[i] == nil
end
#剩下的日期就是张老师的生日了。
print "Teacher's birthday is #{month.compact[0]}-#{date.compact[0]}"
-
2011年下半年项目管理师论文
2011-11-13 08:41:37
项目管理师的论文,是考试的一大难点,一是不是做管理工作,不知道应该写什么,二是要求的字数多,很多时候都没有内容可以说,三就是只有2个小时的时间,通常要求摘要250字,正文2500字以上,而大家平时都很少写字,提笔就忘字,或者写的慢了,论文都难通过。
我复习论文的时候,把全部能找到的论文示例都看了一遍,最后一天,没有干别的,就是看各种各样的论文,研究别人如何写,论文写那些内容,论文的结构什么样,还有如何凑字数。
在考试前,我押题的论文是质量和沟通,项目管理师网(cnitpm)考前押题是质量和人力,所以最后我就写了质量管理、人力资源管理、沟通管理三篇做准备,其中的沟通管理,是用笔写的,主要是熟悉写字的感觉,还有控制段落分布,满足字数要求。我写好后,我的同事看了,说字写的太差了,根本看不清楚,让我考试的时候一定要好好写。但是实际考试中,有时间限制,内容还比较多,很难认认真真的写,大部分内容,还是随手划拉了。
其实在看过别人的论文后,感觉自己写的论文其实不怎么合格,因为概念性的东西,本人还是背了很多的,但是实践几乎没有,所以写论文的时候,大部分都是理论性的内容,联系实际的地方不多,虽然可以说面面俱到,但是实质上的内容很少。其实大家写论文的时候,只要先说说理论,剩下的都可以按照项目写实际如何做,只要突出其中的几点就可以,不需要按照理论都写相关内容。
今年的项目管理师论文,是质量控制和项目团队管理,我记得原先没有出过这样的题,都是9大块里面的大范围的题,今天就要求只写其中的一个部分,不知道有多少人掉进去了,因为即使事先准备了,真的要写,只能使用其中的一小部分而已。以后也许都会这样出题吧,因为9大块都考的差不多了,只能抽出里面的小点当试题了。
考试的时候,我最开始还在思考选哪个,把两个题的大纲都列了一下,质量控制主要就是测试的内容,项目团队管理,我记得的工具是观察和对话、绩效管理、冲突管理,是否还有一个问题日志,有些记不清楚了。写完大纲后,比较了一下,还是质量控制比较有把握,本身就是测试人员么,写本行还是相对容易些。
写论文的时候,最好先写正文,最后半个小时写简介,因为简介就是论文的摘要,先写正文,简介自然就出来了。
正文,首先介绍自己管理的项目情况,还有此项目对质量控制的要求,要加强做质量控制相关内容,还有质量的三个阶段,着重说明下面都是质量控制的内容,这个大概就是600字左右。接着就是分别写质量控制的相关管理。第一点我写的制定质量标准,质量控制都依托于标准进行。主要写了质量标准的意义、重要性,质量标准的来源,质量标准的制定和更改等,这部分大概400字左右;第二点是全员质量控制,每个人都要对质量做自己的贡献。主要内容就是在项目初期就强调质量的重要性,并且给每个人规划自己的质量任务,我主要写了结合项目,程序员使用TDD和Review对代码质量进行控制。这部分大概400字,第三点是分阶段测试。首先说明质量不是质保和测试人员的责任,而是全体人员的任务,质量控制最重要的活动就是测试,测试贯穿于研发的各个阶段,比如在设计阶段写测试方案,编码阶段写测试用例。讲了测试的四个阶段,分别介绍了每个阶段所做的测试工作。单元测试就是上一点的TDD和Review,集成测试自下而上,最后集成完毕,测试也完成。系统测试主要在测试部进行,开发人员的责任就是修改缺陷,项目经理需要监控缺陷修改情况。验收测试我玩了点花样,说明本来应该由甲方提供,但是他们技术能力不足,就委托我方开发,这样看起来就像那么回事了。测试方面写了800字左右。第四点就是在质量控制过程中,工具的使用。论文写到这里的时候,时间实在不够了,就只能匆忙的写了Review用专用工具,缺陷使用软件管理,对缺陷进行pareto分析,项目经理对缺陷的监控几点,有时间应该还写控制图、因果分析图什么的,实在没时间了啊,这部分大概300字左右。再用100字说明执行上面的内容,质量得到了控制,上线后没有发现重大质量问题,得到了客户好评之类的,都是套话了。
正文写完就写摘要,把上面的内容大概说一遍,就200字了,再说说项目情况,自己的工作职责,用户好评什么的,就300字了。
论文从总体感觉,写的还是比较顺利的,至于能否通过,个人就不太清楚了。
大概就是这些内容了。
-
今天参加了项目管理师考试
2011-11-12 22:15:54
06年的时候,就已经通过了软件评测师。
今年公司鼓动大家都报名中项和高项,并请了老师来讲课,我也就趁这个机会冲击一下高项了。
请的中培教育的贾育老师,讲了5天的项目管理,还给了我们很多的资料,这次如果能通过,贾老师的功劳很大。
从十一后,每天都抽出2~4小时,看书,看题,把所有能找到的题都做了一遍,看的题加做的题,大概能有2000道左右,最后两周的时候,把2010年2次和2011上半年的真题当考试做了一遍,2010上47分,下53分,2011上半年比较难,63%的准确率,上午选择题在考试前感觉就基本没问题了,即使偏一些,通过的机会也很大。
论述题我买了书,也看了很多的资料,但是因为自己一直没有做过项目管理工作,感觉答题的时候,还是有些抓不住要点。
论文要感谢cnitpm网站,考前押了质量和人力资源,考试的时候,既然真的就是这两个方向。我事先准备的时候,就准备的质量、沟通、人力三篇。
在最后一周的时候,就是看题,补漏,并背诵大量内容,因为短期记忆的效果能更好些,最后一天,看了一天的论文,就是为学习别人如何凑字数,呵呵。
经过1个月的准备,上考场的时候,还是比较有信心的。
这次的高项,上午题真的很简单,比上半年感觉简单太多了,即使没有看过书,很多的送分题一眼都能瞅出答案,我计算了一下,自己有把握对的题就有42道,其他题运气再差,50分应该是最低的估计,现在就看能否突破55分。另外,上午的英文题很坑爹,除了计算的那道,其他都没有把握,感觉比历年的英文题都难。
下午既然出了一道计算题,难道出题的人不知道,计算题就是送分题吗,而且题中基本没有什么陷阱,只要看过书,想答错都难。另外两题就很难了,特别是外包,很少的关注相关的内容,我想如果这次论述不通过,就载到这上面了。
作文上面说了,押题押对了,而且考试内容既然是让写质量控制,哈哈,想想我们是做什么的吧,噼里啪啦的就把测试的内容都写上了。正文写了2600字,最后时间不够了,就匆忙结尾,否则应该再多写200字左右。摘要310字,看来自己的控制能力大幅度提升。论文题我怕的就是自己写字太丑,很多地方着急比较划拉,老师看不懂就不通过。
一切都等待2个月后,希望能一次通过,考试复习实在是很痛苦的事情。
-
Mantis解析(四)
2011-08-19 19:39:54
(四)core.php到底做了什么
下面的分析,我没有解释全部代码,只是挑选主要的说明Mantis都在后面做了哪些魔法,感兴趣的可以直接去看完整的代码。
1. constant_inc.php
45行:require_once( dirname( __FILE__ ).DIRECTORY_SEPARATOR.'core'.DIRECTORY_SEPARATOR.'constant_inc.php' );
这个是Mantis中定义的常量,在各种函数中,调用的很多不是硬编码,而是对应的常量数值。
在50,51行的
if ( file_exists( dirname( __FILE__ ).DIRECTORY_SEPARATOR.'custom_constants_inc.php' ) ) {
require_once( dirname( __FILE__ ).DIRECTORY_SEPARATOR.'custom_constants_inc.php' );}
这个是如果你需要定义自己的常量,请在根目录下面新建custom_constants_inc.php文件,把自己定义的常量定义到此文件中。按照基本的原则,没有绝对必要,不要修改Mantis中原有的文件,Mantis本身已经给你留下了自定义的接口文件,此custom_constants_inc.php文件就是。
下面还有很多类似的情况,有一个缺省的Mantis配置文件,就有一个对应的用户自定义文件。
2. config_defaults_inc.php
62行:require_once( dirname( __FILE__ ).DIRECTORY_SEPARATOR.'config_defaults_inc.php' );
config_defaults_inc.php是Mantis系统默认的各种参数。此文件和下面config_inc.php是同样作用的文件,但是config_defaults_inc.php是系统预设的,config_inc.php是用户自己定义的。
3. config_inc.php
64-67行
# config_inc may not be present if this is a new install
if ( file_exists( dirname( __FILE__ ).DIRECTORY_SEPARATOR.'config_inc.php' ) ) {
require_once( dirname( __FILE__ ).DIRECTORY_SEPARATOR.'config_inc.php' );
$t_config_inc_found = true;}
安装或升级Mantis的时候,自动把数据库等信息写到此constant_inc.php文件中。如果需要自己定义一些参数,也都是在此文件中写入,可以写入的参数参考doc目录内administration_guide.pdf的Chapter 5. Configuration章节。在根目录的config_inc.php.sample文件内也有一些相关的示例。总之,自己需要定义的参数,就在config_inc.php中实现。
如果config_inc.php和config_defaults_inc.php参数有重复的情况,以config_inc.php中定义的为准。
4. custom_function_api.php
244行:
require_once( 'custom_function_api.php' );
用户自定义的函数,请加入到此文件中,缺省没有此文件,需要的时候自己建立。
5.其他
Core.php里面还定义了很多内容,比如载入core目录下面的各种api文件,定义时区,出否加载wiki等,但是主要的,还是上面的几个文件。
总结,core.php主要加载Mantis使用的资源和库文件,不妨当成缺省的命名空间,而且预留了用户的接口,主要就是变量config_inc.php、常量custom_constants_inc.php、函数custom_function_api.php,后两个文件缺省没有,需要的时候由用户手工建立。在自己定义或开发的过程中,不要修改Mantis的原文件,都使用此三个文件即可。
具体的示例,参考doc目录内administration_guide.pdf的Chapter 7. Customizing MantisBT。
-
Mantis解析(三)
2011-08-19 19:39:17
(三)Mantis的结构分析
其实这个应该放到最后的,因为修改后,才发现很多的东西,Mantis都已经想到了,东西都在代码中,而不是在页面配置里面,所以很多时候,想要的功能,直接修改源码参数即可。等到(四)的时候,大家就可以具体的了解其中的内容了,此节仅仅对Mantis的结构进行说明。
我本人不是开发出身,原先也不了解php,都是此次因为需要使用,才现看的php内容,好在不是需要开发一个没有的系统,而是在一个现有的体系下找到其中的节点和关键,这个就方便多了,所以下面的内容,仅仅代表本人的一些看法,可能有不对的地方,大家可以随时指出,谢谢。
Mantis的目录很多,但是关键的目录目录只有一个,就是core目录,当然了,因为汉化的缘故,lang目录的strings_chinese_simplified.txt,也是我们关心的内容。还有就是根目录下面的各个php文件。
其实感觉Mantis的结构安排不尽合理,php目录下面的大部分内容,都应该放置到一个专门的目录,因为都是一些功能页面文件。而用户定义的内容,比如config_inc.php,应该放置在根目录或者专门的配置目录中,现在的安排显得很混乱,主次不清。
如果看过Mantis的源码,会发现很多php中都首先引入require_once( 'core.php' );core.php是我们第一个需要分析的文件,把此文件分析完,Mantis什么样子,我们也就知道了。
-
Mantis解析(二)
2011-08-19 19:38:33
(二)Mantis的配置和开发环境
Mantis的配置其实蛮复杂的,需要自己修改config_inc.php,统计图形那里的配置也不很方便,但是网上都有相应的说明,自己找找就能找到。建议对Mantis配置感兴趣的,都看看doc目录下的administration_guide和developers两个文档,自己试验里面的参数和功能,对Mantis的理解能加深不少。当然了,不求甚解的,直接使用问题也不大。
因为后期做了Mantis的开发,所以使用了Zend Studio,查看函数中的参数来源和在不同的函数之间跳转,跟踪代码也很方便。
另外还用了UltraEdit和e-texteditor,UltraEdit主要用来在多文件中查找,当然Zend也能实现,但是很多时候未必查找zend工程内的东西。e-texteditor是很方便的代码查看器,简单的修改代码看实现在e-texteditor中即可。
我进行Mantis修改开发的时候,www目录中有3个Mantis目录,一个是Mantis,是正式上线使用的版本;一个是Mantis1,是开发新功能用的,在zend的工程就是Mantis1目录;还有一个就是MantisBT,是原版没有修改过的,当修改参照。
当一个功能,在Mantis1工程中开发完没有问题了,再在Mantis中进行相应的修改;有问题了,和原版的MantisBT进行对照,很方便的。
在同期,我还配置了Testlink,后期,增加了dokuwiki,这是另外一个故事了,有时间详细的说说Testlink和dokuwiki中的奥秘。
-
Mantis解析(一)
2011-08-19 19:37:36
(一)缺陷管理软件的选择和相关的软件环境
既然决定用缺陷管理软件,那么就面临一个问题,用哪个缺陷管理软件。
常见的缺陷管理软件,就是商业的QC(TestDirector)、Jira、ClearQuest,开源的Bugzilla、Mantis、Bugfree、禅道。
ClearQuest排除,原因最开始就说了。
TestDirector排除,第一商业,第二局域网病毒太多,而TestDirector因为构建很容易中病毒,第三至少我很久前用的7.2版的时候,有一些bug。
Jira,我去下载了一个破解版,但是没有安装上,也许安装过程中需要联网和配置邮箱的缘故吧,放弃。
Bugzilla,有网络的情况下,我都没有信心能一次安装,在断网的条件下,还是放弃吧,而且Bugzilla是perl开发的,也和现在的php主流不符,修改等费事。
剩下的就是Mantis、Bugfree、禅道了,都是php开发的,需要安装配置php环境。
Php集成软件也很多,选了使用EasyPHP,建议大家不要下最新的EasyPHP-5.2.11版,无法解包。建议大家下载5.2.10版,可以直接解压,不需要安装,参照install_script.iss文档中的内容进行修改和配置,直接可以使用,这样有问题后,直接复制此easyphp目录就可以完成移植。
EasyPHP有点小bug, PhpMyAdmin固定就是80端口,在非80端口使用的时候需要注意一下端口。
EasyPHP配置启动完毕后,没有问题了,就可以开始安装各个缺陷管理软件了。
去Mantis、Bugfree、Zentao官网下载最新的版本,解压到www目录中,按照网上的说明进行相应的安装和配置。
Bugfree安装后,在首页有错误,去网上找了找,因为php.ini中allow_call_time_pass_reference参数的问题,修改后就好了。还有其他的问题,总出现Fatal error,对Bugfree的质量印象不是很好。Bugfree本身支持测试用例管理和缺陷管理,从总体的感觉上,Bugfree简陋且山寨,建议Bugfree重新进行页面的设计,请美工人员进行页面的调整和配色。功能不提,界面上看,绝对是10年前的个人网站效果,没有任何的美工,条目的排列也很嘈杂混乱,后台管理简陋至极,测试人员自己用可以,但是给开发看,绝对不会有什么好的感觉。
禅道按照Scrum开发方法设计,里面有需求、用例、TODO等内容,软件本身不予评价,但是功能太多了,我想用的仅仅是一个缺陷管理软件,也许按Scrum开发的团队使用禅道更合适。
剩下的就是Mantis了,单纯的缺陷管理软件,但是可以和其他的软件进行集成,比如测试用例管理软件Testlink。
-
Mantis解析-序章
2011-08-19 19:36:33
此系列文章,整理后,删改一些内容为《Mantis深入学习》,发表在了《51测试天地》第23期电子杂志上,在这里感谢51testing的编辑。
序章
文章的题目比较大,说mantis解析可能过了些,只是说些自己在使用mantis过程中,如何分析和处理mantis源码,以适合自己的需求。
我原先一直是ClearQuest的支持者,虽然用的是盗版,虽然用的是很老的2002和2003版。ClearQuest的功能就我感觉在各种缺陷管理软件中定制功能最为强大,而给非测试人员使用的ClearQuest Web客户端却是各种缺陷管理软件中最简易的。ClearQuest的强大定制功能,易于测试人员对缺陷管理流程和字段、页面等进行控制;Web端的易用(屏蔽一切与缺陷管理无关的内容)很利于开发人员的培训和使用。但是ClearQuest也有问题,一是软件安装太大且慢,二是需要使用SQL Server或Oracle数据库,三是配置起来过于麻烦,四是导出和备份都脱离了时代。其实我遇到的最大烦恼就是:ClearQuest的移植性不好。因为我换过几次的服务器,都需要很麻烦的步骤才能完成。感兴趣的,可以看看我曾经写过的关于ClearQuest的帖子,就能了解一些相关的内容。
我从3、4年前开始,就没有怎么使用过缺陷管理软件了,发现其实txt或Excel在小项目上也挺好用的,最多的时候7、8个测试人员,200多条缺陷,用Excel虽然麻烦些,但是也能很好的管理和记录缺陷。
但是近期有一个稍大些的项目,3个测试,10个开发,预期千条数量级的缺陷,再用Excel很明显不合适了,所以需要一个缺陷管理软件。因为服务器经常中病毒,所以随时的准备重新安装系统和相关软件,缺陷管理软件最好具有很高的移植性。
说下我们公司的网络环境,为了安全,我们公司的局域网完全和广域网进行物理隔离,无法上广域网,也无法使用邮箱。但是同事中很多人有笔记本,可以去专门的地方上网,局域网内电脑无法方便的升级操作系统和杀毒软件,笔记本又会从外网带来很多病毒,所以服务器常中病毒也是很正常的事情了。
上面的内容和技术没有太多的关系,只是简单介绍一下背景,因为下面的内容我的一些做法就和上面的背景和环境相关。
正式开始了。
-
测试人员如何给予合理的考核呢?
2011-07-24 14:37:17
很老的帖子了,2005年的,在csdn上的讨论,想看讨论的在http://topic.csdn.net/t/20050224/19/3804392.html,下面的只是我自己的看法。
csdn论坛上,有人问如何考核测试人员,我回了几个帖子,下面就是我回帖的内容,可以代表我对此事的一些看法。
一: 测试人员的工作评价比较的难办,因为测试人员没有具体的工作产品产出。
测试人员一般做的也就是测试用例的编写和测试缺陷的提交。而这些可以说都不是看技术,而且看职业道德。所以我更多的认为,测试人员最重要的是责任心,是想 做测试而不是开发什么的。一个测试人员提出1个问题或提出10个,对软件最终的质量影响可能并不像大家想的那么严重。 如果真的要考核,只能从工作产品考核,提交的缺陷不可能做为考核的目标,因为分配的模块、测试人员的视角、开发人员的技术差异等都可能会造成相当大的振 荡。所以通常都是从测试用例的角度来进行评价。 这样可以换个角度来说关于测试用例。
测试用例可以说是最变幻莫测的东西,因为至今没有一个严格的标准和理论来阐示测试用例的编写(记住,是测试用例, 不是别的什么)。而且测试是软件工程收尾的工作,很难有大的时间和精力去编写详细的测试用例,但简略的用例根本用不上,只能提供一个大概的思路。并不合适考核的条件和标准。 所以真的想考核,可以,把你们单位的各种关系理顺,完全按照软件工程的方式一点一点的来(RUP,CMM等都可以,因为里面的工作都很容易度量),如果不是按照这样,凭空的说考核测试人员,还不如经理直接拍脑门决定好了。
二: 上面说的多,但中心只有一个:想考核,就必须有一个可以比较的标准,所以首先要想好自己的公司是否存在这么一个东西。如果没有,还是不要考核好了。 用bug数考核测试人员,就像用代码行数考核程序员一样可笑。
三: 现在别说测试人员,就是程序员又有几个公司可以做到让大家都满意的考核?
测试应该可以说都是在摸着石头过河,有理论,但实际很难做。 所以我一再强调测试人员的责任心,因为测试工作本身几乎无法度量,就像你写的,做一个小时和做8个小时从工作成果上并不能很好的体现出来。 为什么没几个愿意做测试,因为测试即幸苦又无聊,工资也比较少,成果还总被忽视。 其实谁做的多少、好坏,大家心里都有杆秤,只要在奖惩的时候,经理能做到一碗水端平,即使没有实际的比较标准,大家也不会过多的说什么。 管理对的是人,不是机器,不要妄图制定一个完美的标准,即使有,还会有人不服气的。 只要心中无愧,做什么随便让别人去说好了。
四: 前两天才看到有人在讨论测试用例写的时机,觉得很有道理。
如果按照标准的软件流程,测试人员可以参与到需求、设计阶段,测试用例当然比较的容易写。 但现在更多的情况,是程序开发完毕了,才交给测试人员,这样如果写用例,一是时间的问题,二是对程序不一定熟悉。所以说真的,写测试用例有些不和适宜。 而最常见的是测试完毕后补测试用例(嗯,怎么和程序员一样了,鄙视自己和大家,哈哈),这样一般都是为了应付上面和客户用的,只能说是一个总结,因为问题都找出来了,自然容易按照问题写用例,可以比较的完美。 所以我建议写测试思路,特别是有多业务流程的时候,这样做不容易遗漏。
至于那种白痴照着做都可以发现问题的测试用例,反正我们是没有这个时间和精力,而且很多的时候,觉得测试都是一门艺术(再鄙视自己一次),发现问题更多是直觉(也许是错误的操作),这些都是用例无法表达的。 如果真要写,可以写一个简单的,随着测试的展开,对程序的熟悉认识再逐渐的补充。这样测试的差不多了,用例也基本写好了。 测试用例其实最难掌握的就是一个度,写到多详细,而这一般和测试时间呈线性关系。
-
测试需要业务
2011-07-18 22:20:48
今天看到一个人问电梯测试,这样的问题很多,大部分都是面试题,也许考官看的是一个人的分析能力和思路吧,但是我却不是很喜欢这样的题目。
作为一个专业的测试人员,你做的到底是什么性质的工作??
在国外,测试人员很多可以接触到前端,也就是从需求、设计、编码等阶段切入软件开发过程,如果开发分工的比较细,可能随着不同的组变化,测试人员也一直在同步跟踪软件。这时一个很理想化的过程,对测试要求很高,但是对软件的理解和缺陷的跟踪,测试人员本身应该是比较清楚的。
在国内,我想大部分测试人员接触的是黑盒系统测试吧,而且大部分公司规模不大,文档也未必很多,这个时候,测试更多凭借的是测试人员的能力和经验。
其实在我个人看来,测试最终的落实点在业务。测试理论,如果肯耐心的学习,半年时间足矣。一些工具的经验,也可以随用随学。
我想大部分测试人员,工作3年左右,就会发现到了一个瓶颈,很难再进一步了,所有的东西都在原地踏步,这个时候,如果没有升到领导阶层,就会很容易陷入一 个循环,发现自己每天做的都是类似的东西,一点新东西都没有。学习的东西也不一定在工作里面用的上。周围的人其实也差不多。
这个时候,区分测试人员的,更多不是能力,而是你对你所在的范围是否熟悉。也就是你所拥有的业务经验,才是和其他测试人员相分离的。
比如你作为一个测试人员,跳槽到其他公司,你的优势是什么?你的测试经验?别人未必比你差多少。但是对于新公司软件的熟悉了解,你却很不如。这就是业务的差异。不深入到一行,不会知道那行的规则。其实不止软件,每个公司也都是自己内部运行的规律吧。
随便写写,很乱,我的思路也很乱,也没有太表达明白自己的意思。就当灌水了吧。
标题搜索
我的存档
数据统计
- 访问量: 70081
- 日志数: 47
- 图片数: 2
- 文件数: 2
- 建立时间: 2006-11-24
- 更新时间: 2023-01-29