大话人生

  IT博客 :: 首页 :: 新随笔 :: 联系 :: 聚合  :: 管理 ::
  299 随笔 :: 0 文章 :: 73 评论 :: 0 Trackbacks
re: Selenium使用介绍 大话人生 2009-06-30 18:05
但是waitr不能够使用在firefox以及sofari
@MM
你说的有些对,但是绝大部分很抨击公司的女孩子。
楼上的美女,不好意思,我不是有意针对女孩子,可能是女孩子比较多让你产生了这样的看法。我没有歧视公司女同志的看法,女孩子在目前的测试行业中的优点是细心,耐心,很有责任感这是女孩子的优势,他们能够发现软件中的很多问题。但是有些人满足于现状,没有对自身技术上以及知识上更严格的要求,觉得自己不错了,一直停留在刚开始的阶段,没有想办法去提高自己。我在这不是说他们做不好测试,而是如何去做好测试。只有更高的去要求自己觉,提高自己的能力才能更加深入的去开展测试,也才能够让测试人员扬眉吐气。如果真有伤及到你了的话,我道歉。


自动化测试,你的观点我很认同,确实可以从小自动化测试开始。但是对于公司现行项目使用企业版的测试工具合适吗?需求变更如此迅速,而且还是两三个月就要提交上产品,对于这样的项目我想自动化测试根本是不现实的。

公司目前的项目有很多适合,为什么?因为目前公司的很多项目处于后期的维护阶段,并没有对流程进行大的改进,伤筋动骨。但是每次更新一个小的需求,大家都要完整的走一次流程,还要担心有的功能是否有测试到,连自己都没底,不是吗?我们为什么这个时候不借用自动化测试工具了?
还有自动化测试工具不是说一定要版本稳定了,只要你所使用的工具能满足你的测试需求,减轻你的工作量就已经达到了自动化测试,比如一个网站的所有链接要你去测试你怎么测试?一个一个点还是使用网页链接测试工具Xenu了?

我觉得测试应该是从需求开始,我觉得现在大多数测试人员根本不懂需求,何来测试设计,测试用例。

需求开始没错,话又说回来,如果在需求阶段,你是否需要考虑开发采取的何种开发模式或者框架技术,设计到了哪些方面是需要侧重测试的如何测试的了?你要知道客户有时给你的根本不是一个完整的文档,而是需要技术人员去按照用户的需求整理成我们想要的需求规格说明书等,实际意义上我们现在项目拿到的不是用户真正意义上的需求而是由JBH等同事整理的需求规格说明书。所以更加认真的读懂和理解需求是需要阅历加上技术来支撑的。像你说的那样的测试人员,建议让公司裁掉,呵呵~~~


现行的中国测试局面就是这样,找个合格的测试人员本来就难,何况公司的人员招聘是与北大青鸟搭线。你想想北大青鸟去就读的又是什么人?

这个你可能要挨批了,进北大青鸟的也有名牌学校的同学,只适合在大学里可能学到的东西觉得在社会上不至于立足才去继续深造的。


呵呵~~~~~~看你上面说了那么多,我们公司的问题大家都看到了,问题是如何来解决,怎么来解决的问题?难道上面不关注了,我们也不学习了吗?总之,现在为了公司测试的明天也是你我测试的明天。大家一起努力吧
@d
恩,哈哈,看来我们平时私下里很少交流,这里却成为了我们讨论的一块小区域。

你说的那些道理我都能理解。我并非一个理想主义者,而是一个现实的人。说白了,我进公司前是想做开发的,但是出于当时公司的考虑,不能说我有多么伟大,我确实牺牲了点自己的利益,做起了测试工作,一做就到现在。从当时的对测试的不理解到现在的推崇。

不是说测试职业有多么伟大,而是既存在即合理。现在软件行业的发展壮大已经细化到很小的部门和职业。可以说测试这个东西自从有了计算机开始就拥有了测试,只是前10几年把他作为了一门独立的学科来分类(我指国外)。

公司成立测试部门的初衷也是希望测试人员替开发人员减压,使开发人员能够把更多的精力投入到产品的研发过程中,也从而更高标准的产出我们的软件。从当时clochase的精英团队(我当时的认为)到现在的水平参差不齐,没有门槛,白菜萝卜一起抓的现状。我真的有点失望,不是说公司不能够容纳有水平高低不同的人,公司是要具有形形色色的同志。但是目前的现状和人员梯次根本就是毫无界定。没有一个团队的梯队模式,没标准,想要人了,不问情况往里招,不好了有的能力不怎么样的还不忍心裁掉。这些招进来的人又能创造多少价值了,有的可能反而成为了一种负担。我在这也不是指责我们的上层,而是希望能够有个评判的标准,一个入门的门槛。

你说的开发是根本,我基本同意,而我的理解是计算机技术能力的支撑应该才是根本。软件行业毕竟是门技术活,无论开发,测试,IT支撑或者网络管理等等的IT人员啊没有技术的支撑想在技术的行当里混下去,或者说没有扎实的技术想有质的提高是不现实的。

我目前承认测试在公司是增值,但是我的目的就是,竟然入了这一行,为什么不把他做好,为什么不能直接去创造利润?为什么一定要去成为一个附属品了?公司竟然成立了测试部门为什么就不能够把测试部门做的更好去创造更多的价值?我想当初公司成立测试部门的初衷也不是基于国内测试行业兴起的跟风。而且测试行业的外包增值在市场上还是有利润的。我们为什么不能抓住这个切入点让公司去支撑下了?我并不是说我能力有多大,而是希望带着可能自认为的一些理想在这里想和公司赢得共赢的机会。所以路还很远,但是我一直在像这方面有努力,成效永远胜于口水仗。

对于你说的公司的女测试人员又或者是才培训出来的人员,我跟你有同样的感觉。有些同志连基本的SQL语句都不会写,又或者根本就不了解一些开发的基础知识,不了解什么进程,什么线程。什么是session什么是cookie之类的基础知识你说如何去做好测试?不对测试的项目进行深入的理解,不了解大致实现的机制和框架,如何更深入的去展开测试?我在这并不是说一些女同志,而是一些同志,有些女同志还是不错的。
貌似我们公司的测试人员连基本的开发能力都不要求就抓进来了。连随便用种语言写出1+2+······+100都写不出来。在这种情况下我们公司想实施自动化测试就是天方夜谭。自动化测试的前提就是要具备扎实的开发功底。这也是实现测试人员自我价值提升和涨米米关键点,我曾经也美好的设想过公司为什么不可以分成STE和STDE?一个美好的梦。

说是几点,说这么多,做这么多无非希望得到公司的关注,关注测试,关注测试的发展,也如你说的提升我们的米米,但是如何提升,我不可能每天指望老板和上层来发现,而是希望通过成效和实际行动来自我增值。但是我现在缺少的就是和其他测试人员的沟通(内在的一些原因,大家都很清楚,呵呵~~~),还有就是缺少上层给予的支持。如果有了这两点,我相信做起来会比现在轻松许多。

你是一个工作了多年的好leader,哈哈,很感谢你对我的回答,能够这么热诚和诚心的告诫和提点。希望能够以后更多的探讨。
哈哈,说了这个多,其实我提出的很多问题,有些是心里有点底的,也是事实在在存在的问题。这个东西也发公司的论坛了,我的目的只是希望上面给予更多的关注和支持,如果没有支持,我想我再有更多的想法或者建议都没法去实现和实施。哈哈,目前也只能作为一种建议和反馈

不过还是很感谢大哥的支持。公司论坛一片叫好之声没有太多意义。这样的拍砖才实在。
以后多来踩踩,多拍拍砖,有些建议还是很可取的。^O^
@d
呵呵,这么晚了,上来看看,又看到仁兄的发言了。可能我们还是有些观点不一致。

1:如果需要对工作流程进行监控和优化,那么QA是有必要出现的。项目经理就是干这个的。老板也是干这个的。并且谈优化监控。职位一定很高。水准一定相对牛。让这样的人做QA。公司请的起吗?愿意花这个钱请吗?

目前BOSS,项目经理可能都把经历放在这方面,但是他们长期以往的主要职责和工作重心是这个吗?又或者说质量监控只是一时的不需要长期进行下去的工作吗?如果工作重心是这个的话,未免这些牛人也太贵了。QA只是一个职位,并不代表他的能力和地位高低。
请逆向思维考虑下,为什么不可以安置QA做质量监控,然后配合项目经理,又或者以后的技术监督部门来一起监控和反馈质量信息了?为什么不把一些愿意做相关工作的测试人员或者同事安排来做QA了,QA难道就不可以上升为以后的项目经理了吗?为什么公司一直要求测试人员再三的说保证质量,保证质量,但是确没有给予测试人员保证质量的机会了?质量监控是一个长期的工作,而不是一时的热血沸腾的想法。

2:测试的价值问题
这样说吧。如果一个产品10分的价值。开发7分,测试3分。至少目前的公司是这样。我这样折你不会不同意吧。如果这样按照价值折合工资。是不是老板会给开发7000,只给测试3000呢。或者给你6:4,开放6000工资。测试4000工资。这个就是现状。和开发并行的测试。创造了价值,不过不够多的价值
只有独立。才有10分的价值,这样才能牛

我看关于测试的价值问题,我们不用这么深究,对于国内的现状是,测试行业很火,但是重视程度不高。门槛低,被认为是没有多少开发能力或者能力不行的人所从事的职业。
对于你说的价值,我不明白你的绝对价值是什么?如果说一个发布的产品,我们怎么看待他的是价值了?我们不拿阿波罗号事件啊,掉颗螺丝啊就一切88的的科研东西来打比。如果说一个产品,没有经过测试人员的严格测试和最终的评定审核。他发布出去的风险有多大?从我的朋友那里一些公司是没有测试人员的,发布出去的东西没有严格测试,漏洞百出,问题多多(并不是人家开发不牛X,我想再牛的开发在压力中也难免会犯一些错误吧)。最后就是人家不买你的单,说你做的东西操作性不强,使用不方便。问题还超级多,当你拿着这样的东西让人买单的时候,价值几乎要接近0了,呵呵~~~但是话又说回来如果一个成功的,质量有保证的产品一经发出,那么开发和测试的价值比是多少,谁去衡量了?可能一个当时让你的产品变成0的BUG被测试发现了,挽救了你价值为0的产品怎么去评估?是10还是0,又或者是7还是3?你能告诉我吗?测试人员能力有高低,只是目前我们公司的测试人员能力还不足(这一直是困扰我的一个大问题),所以说请尊重测试人员的价值?所以说做测试难,做成功的测试人员更难。
如果说测试人员外包项目去创造的米米,那个似乎不叫价值了,那叫公司的外快或者说是给自己公司创造的利润给被外包公司创造的价值了。哈哈~~~~~~~~

4:自己编写一些小工具为什么就不能做自动化测试了
这个我能够理解为简单的自动化测试吗?或者自己写你不觉得成本更贵。
如果公司推行的是你这种简单的自动化测试。就不是真正意义的自动化测试

什么是真正的自动化测试?世界有没有真正的自动化测试?看来你这个要去GOOGLE或者BAIDU下了,世界上目前上还没有完全意义上的自动化测试。按公司的大小和成本的收益比,当你的花费的构建自动化框架能节省你的成本就是自动化了。
例如:我们公司经常要认为的对比文字的正确与否,我们为什么不写一个方便益用的核对工具,让人能够很容易和准确的去识别这些差别,而不用去一个一个文字的核对了?(目前的ULTRAEDIT工具的核对功能并不好使)这个工具不是一时所需可能是以后的项目中经常要使用的,你说这个是不是自动化测试?(可以看我写的其他BLOG)
另例如:如果我要测试一个用户登录网站退出网站100次或者更多来验证,登录中是否有bug又或者其他的流程操作N次,(这个问题曾经在BELL项目中已有应用)这时,使用自动化工具来测试这算不算自动化了?
再比如:我们每次提交BUG要开发人员去看BUG,然后开发人员改了个BUG就提醒测试人员去验证,依次反复,是不是浪费时间了?我们为什么不对BUG管理器进行邮件提示,当改完一个BUG或者提交一个BUG会自动邮件给相关人员了?
所谓的自动化不是说开个机器在那里,程序就一直跑,跑出BUG来的自动化测试是不符合现实社会的,这种自动化只能是美丽的泡沫。我所说的自动化就是让机器代替人为的体力活去做一些重复的工作。
再说了多完美的自动化测试也是从小的自动化测试开始的,只有让人尝到甜头,大家才会去向这个方向发展和拓进。我的想法是小范围小甜头到大范围大成果。

现在的LR,QTP工具确实是最流行的工具,只能说流行,并没有你想像的那么强大。IBM的那一套工具益用性相对是较差,但是非常的强大和体系,只是一般公司更用不了,也不理解IBM的工作模式和工作理念。任何的测试工具都有自身局限性,在我用过的QTP和LR进行项目测试都有自己的局限性,不是说任何项目都可以使用HP的或者MECURY的万能工具解决的。都需要自己来改写脚本,进行脚本的开发和维护来完成项目的自动化测试的。而且并不是完全的自动化。
可以再打个比方,MS是从来都不用上面的那些他们认为不入流的工具的,MS的话,呵呵。他们有自己的一套自动化工具开发,而且这些工具并不是万能的,都是根据现有项目的实际情况和成本核算来开发的。

沟通使用工具不是说不可以,而不能说培训,因为目前公司自身能熟练掌握这些工具的人几乎没有。而且未必人家对这个东西感兴趣,如果说讨论也是针对感兴趣的人而言的。所以这是我提出的为什么要引入自动化测试,要引导,要渐进。而不是强制大家用, 一定要让大家尝到甜头,才能更多的开展工作。
@d
呵呵,很感谢公司的这位同志拍板砖
也谢谢对我所提的问题的点评

1.第一个问题,测试部门的定位
质量控制是公司要过CMM等认证才需要的。说的有点太绝对。

难道质量控制只需要在过了CMM吗?仁兄是有点说的绝对了,CMM等只是一个帮助改进工作流程保证工作质量的的一个模型而已,难道要真有了CMM才有质量保证吗?犹如CET-4考试,难道过了CET-4就是具有了英语的四级水平了?

对于公司的QA,貌似这个问题其实很早就意识到了,公司测试人员的职责就是测试,所以我的目的就是要去掉扣在脑袋上面的那个头衔,那个自始自终都要保证质量安全的QA头衔。但是话也说回来,如果公司对软件质量的重视继续加强,如果需要对工作流程进行监控和优化,那么QA是有必要出现的。这是后话了,呵呵~~

第二个问题,测试部门的发展方向
他们做出产品,测试只是确保,严格意义没创造价值
至于谈独立团队。非常不现实。除非是纯粹的软件外包公司。测试才能创造属于自己的独特价值,不然永远是开发的附属品目前我觉得测试团队会一直附属。

这点,我很不认同仁兄。测试没创造价值,需要测试干嘛,养帮测试干嘛。测试和开发的价值刚好体现在两个有形和无形价值两个方面。测试团队的独立体现在多方面,可以是工作方式的独立也可以是创造价值方面的独立,就像你说的,去承接外包测试,那样的有实物的价值可能更加让人认可而已。

(1)测试管理流程不规范
说的不错,基本同意你的观点,这也是需要在整个项目计划以及开发计划和测试计划中来实施和调整的,改变这种测试完全跟着开发进度跑的局面。

但是不认同你的‘让你和开发人员沟通。你能沟通出什么呢?’
测试为什么不能和开发沟通,而且沟通是必不可少的。
首先进行完一轮测试,我们首先来定位这些问题主要集中在哪些方面,是由什么情况导致的?是否有开发的态度问题(例如自己不先测试过,或者对自己开发的代码都没有信心就抛出测试)。是否有业务理解方面的差异,又或者是框架本来设计就有问题,测试在开发的过程中能够提供一些必要的数据以帮助开发人员能够更加快捷的进行开发设计。

(2)测试用例的编写与管理以及执行力度不足

很同意你的观点,用例没必要一开始就代入数据,那样在需求变更的情况下,维护的成本更大,而应更多的考虑他的实效性,以及通用性,大家都能够使用同一套用例进行同样的测试,这个用例境界还是比较高的,但是会像这方面努力

(3)测试过后没有测试报告
为什么不能够从bug管理工具导出来的。。。导出来的难道不是测试报告吗?不能给你一个标准衡量下吗?

仁兄可能不在公司很久了吧,还是没用过公司的这些bug工具,目前的这些bug工具如mantis之流还不具备测试报告的发布以及分析功能,这也是为什么我提出要走自动化道路的原因,所谓自动化就是融入人的思想,让计算机替俺们办事

(4)自动化测试的实施基本上不存在
你的想法非常不对。引进自动化测试需要很多前提条件。自动化测试绝对不会节约时间。
自动化测试只适合非常稳定的产品。
培训可以内部培训。今天你讲QTP。明天他讲LR。。这样也节约成本啊。
想开展自动化测试。

你可能还不了解自动化测试的真正含义吧,不是所有测试都需要版本稳定了才去做的,自己编写一些小工具为什么就不能做自动化测试了,难道一定需要在系统测试的时候,版本稳定的时候进行自动化测试吗?你指的可能是QTP和LR这些大型工具,按你的培训思路,这样是需要技术力量支撑的,在自己都没有完全掌握这些工具的时候如何去给人家培训?这个成本貌似也很大啊。

(5)测试团队内部缺乏有沟通

沟通是必然的,没必要一定去开个会,但是开会是最容易拉近大家距离的方式,而且看下公司的各位一个闷声发大财的,也不会搞个topic就来和你跟帖吧。

(6)测试人员需要在技术方面进行提高
技术方面=编程,看代码
其他的一切都不重要。什么linux。数据库啊。。那些都是辅助的技术方面,不会编程一切等于白搭

恩,这个讲的很实在,目前测试部门就是欠缺这方面的技术才能,也是我提出来的疑问,其实更加需要开发背景的人员加入

(7)质量如何保证?测试不仅仅是测试人员的专利
下面的不写了。。哈。因为觉得你这样写没有半点用。不用浪费时间了、

但是也很感谢你对我的观点和疑问拍砖,希望继续拍砖,帮助提高,谢谢了:)
re: 我讨厌测试的10件事 大话人生 2008-04-17 09:46
@路人甲
别急,下个星期,也是翻译到别人的