叶子,软件测试sky下度过四载生涯。 若干手机测试和web测试经验,对性能测试和测试工具稍有所得。希望以后能更加踏实的走向属于我的明天~~ 希望在测试的道路上有更多的同路人。

我的最新日志

  • 我是一只笨鸟

    2008-8-26

    这首小诗

    其实写在很久以前

    自己在深圳的项目结束了,在飞回大连的飞机上,偶有所感

    只是突然想起,贴于此处,自勉!

    希望自己山高水长,永远不失去的,是那份执著和自信!

    在新的项目里面,我是一个菜鸟,太多的东西需要学习,我也本着自己一贯的笨鸟精神,努力去!

    ******************

    我是一只笨鸟

    我是一只笨鸟
    不知道自己的天空
    还会有多高

    我是一只笨鸟
    飞过天空
    都要留下一片羽毛

    我是一只笨鸟
    走过一个城市
    总要衔起一片树叶当风向标

    我是一只笨鸟
    珍惜这个世界
    珍惜所有回忆

    笨鸟

    我快乐
    因为我是笨鸟
    我忧伤
    因为我是笨鸟

    一只喜欢留下自己味道的笨鸟

  • 新的战斗打响了

    2008-8-21

    8-15,在结束了旧的项目的当日,我拎着我的笔记本,来到了新的办公场所。

    在这个公司,其实比较吸引我的东西之一就是,人随项目走。每个项目的业务不同,客户不同,参与的设计,开发,测试,管理的人都不一样。所以每换一个项目,你都会有机会认识很多新的人,学习新的技术以及业务知识,还有就是不同的工作风格和貌似一致其实还有有所区别的流程。

    对我来说,每一个项目都是一个宝藏,闪闪发光,等着我去挖掘,我能掘动的东西。

    这个项目,也是除了我3年来对日之外的最长的一个项目了。到现在我只是知道参与的日期,不知道什么时候能结束。这话也是被项目老大看了,估计会很失望,这丫头怎么才来了就想走啊。呵呵~~说说而已,在贫瘠的土地也有珍宝,何况一个做了若干年的项目,有很多的东西值得我花时间去了解和掌握。

    其实某种程度上,作为一个测试者,我是失败的。虽然经过我参与的测试项目,至今还没有客户说我的能力如何差,只是听到他们说我如何出色。唯一的抱怨就是我深挖到底,没有结论誓不罢休的精神偶尔会让他们苦恼,如何来给我一个理由,结束我所提出的问题。。

    我的失败之处在于,我永远游离于技术之外。会的编程,数据库,计算机软硬件知识,总是那么一点点。。所以我的天地目前势必也只有那么一点点。目前来说,我只能从事黑盒测试,而且只是这其中的一部分。对于白盒测试,我虽然不十分喜欢,但是也希望能有一个机会,一窥其貌。。不过目前,虽然我想,但是也没有项目组的人敢冒这个风险,把那样的项目拿来给我做,唉~~)

    新的项目,我将会在数据库的应用上,再上一个台阶,在finace的业务上,也将了解更多。这一点是极为高兴的。其他的东西,就要看自己的发掘力了。我相信自己的能力,更相信,一向抠门的自己,绝对不会少挖金子回去。。:)

    新的战斗打响,无限期待。。

  • 分享:国际化软件测试简介

    2008-8-19

    文章作者:崔启亮   文章来源:中国本地化网   发表时间:2005-7-13 11:08:00

    国际化软件测试是近年来逐渐发展的新兴测试领域,与传统的面向单一区域和语言的常规软件测试相比,具有很多不同的特征,表现在跨区域的全球测试、测试内容广泛、测试周期时效性强等多个方面。

    1. 跨国家/地区的全球测试

    国际化测试的各方分布在不同的国家和地区,是典型的全球分布测试,离岸外包测试的兴起使得全球测试的特征愈加明显。由于测试各方相隔遥远,因地区时差、文化观念和办公时间等的差异增加了国际化软件测试管理的复杂程度,要求测试管理人员具有较强的区域协调能力、交流沟通能力、远程项目跟踪和控制能力。

    国际化软件测试的参与各方包括软件开发商的质量保证人员、技术支持人员和软件开发人员以及测试管理人员;软件测试服务商的软件测试人员、质量保证人员和测试管理人员;软件开发商在各个国家/地区的分支机构或其邀请委托的行业领域专家(技术和语言方面);软件外包测试服务商邀请委托的行业领域专家(技术和语言方面)。

     2. 核心功能测试为基础,软件国际化和本地化测试为重点

    国际化测试的测试内容广泛,包括核心功能/性能测试、国际化特征测试和本地化测试。

    核心功能测试以测试软件的功能和性能为主。从测试阶段可以细分为单元测试、集成测试、系统测试和验收测试;从测试实现方式上可以分为手工测试和自动测试。

    国际化特征测试包括国际化支持能力测试和本地化能力测试。国际化支持能力测试在于发现软件支持不同区域数据的能力,例如日期、时间、数字、货币和不同语言字符集;本地化能力测试在于检测软件是否考虑了本地化的方便性,是否容易实现本地化而不需要修改软件源代码。

    本地化测试包括本地化功能测试和本地化语言质量测试。本地化功能测试检测软件本地化后的软件的功能是否全部可用,不会丢失某些功能;本地化语言质量测试在于测试软件本地化的文字是否准确、一致、符合当地用户的表达习惯,还包括对软件的用户界面进行外观测试,本地化的字符串能够完整地显示在软件界面上。依据本地化软件的语言数量,多种语言的版本往往与源语言版本同时展开测试。

    3. 复杂的测试项目管理

    国际化软件是一项复杂的系统工程,参与的公司和人员分布在全球各地,需要同步本地化的语言可能超过几十种,报告的软件缺陷数量可能多达几千上万,而且由于软件外包将带来很多交流和管理的问题。因此,对国际化软件测试管理提出了更高的要求,项目计划和预算管理与跟踪,测试文档管理、测试缺陷管理、技术支持和沟通交流等都比传统的软件测试项目复杂。

    4. 测试周期时效性强

    随着软件市场全球竞争的加剧,软件的开发周期不断缩短,对于全球发布的国际化软件来说,越来越多的国际大型软件公司追求多语言版本与源语言版本同时发布或者相隔时间尽量缩短。为了达到同步发布的目的,软件的国际化测试和本地化测试以及核心功能测试需要与软件开发过程并行进行。由于软件测试依赖于软件开发过程,而且随着软件项目周期的缩短,留给软件测试的时间经常比较紧张,尤其在软件即将发布的后期测试,对测试时间提出了较为苛刻的要求。

     

  • 项目结束了

    2008-8-15

    从二月份的春寒料峭到8月的桃李芬芳,我的项目居然也作了半年。

    8。15,一个历史的纪念日,中国抗日战争胜利63周年纪念日。

    我也告别了这个项目.

    回想起半年多来的这个项目,真是感慨万千。

    每个人都需要学习,在他经历的每一件事情里面。

    在这个项目里面,我学到最深刻的东西就是,协作。感受最多的是合作。

    测试工作需要太多的沟通和合作,任何一个人的不合作都会导致整个项目的失败。从业4年来,也深刻的体会这一点。

    这个项目,属于我第一个参与的,国际化的项目,开发,设计,测试,沟通和管理都由不同地域和国家的人来组成。对我来说,新鲜感十足!:)同时,也因为大家来自不同的地域,不同的国家,工作的习惯包括交流的方式都是不同的。所以,要格外的注意至少不要用对方无法接受的方式与对方沟通。这一点,好在我从头贯彻到尾。

    这个项目,我做得很累,但是很开心。

    不仅仅是因为到了项目的后期,我一个人可以承担起整个中华区的沟通和测试作业,让我足足满足了一把。

    也不仅仅因为跟我沟通的美国客户对我赞赏有加。。

    从对日改到欧美,这个项目让我真实地感受到,我真的没有选择错,我就应该在这样的空气里面生存。

    在对日的项目中,即使我在力求完美,却无时无刻不在担心日本客户吹毛求疵般的review我提交上的东西,然后发过来一堆指摘。。我感觉自己的每一根神经都在通过他们的审查之前,崩的快要断了。。半夜都会梦到自己测试的结果,提交的周报出了问题。。

    我确实从对日项目的三年经验里面学了很多规范的流程,严谨的态度。这些让我至今收益。。但是我不愿意再去过那样的近似于自我摧残的生活。

    每当我发行一个bug,我第一个念头不是考虑这个bug的详细分析,不去考虑是不是可以给开发人员提供更多的帮助,让他们可以尽快地找到问题点,更快地解决这类问题。。而是格式是否正确?资料是否齐全,如何搜寻到更多的证据来证明自己发行的确实是个bug。。

    欧美的项目中,我依然也需要为发行一个bug提供若干的资料和数据,但是类似的行为却又不一样的目的。我会受到的不再是质疑,指摘而且友好的询问和感谢。然后让我帮助他们分析,是否在什么地方进行了某个操作,他们为什么会如此推断。。让我也加入到这个分析中来。。

    从某种意义上讲,我第一次真切地感受到了自己的价值,第一次感觉的自己和他们是平等的。

    我所作的项目是一个关于中国古老文化的项目,作为根本不懂中国文化的海外同事,每每因为文化差异的不同理解错了某个场景的设计,我们都会在文化的交流上得到一番新的感受。第一次知道自己熟知的那些文化礼仪,原来在西方人的眼中是那个样子。。

    8。15,项目宣告结束了。准确说,是我撤出了这个项目,因为经费不足,也因为这个项目的负责人虽然在后期认识到了测试人员的重要性却无力回天。。

    美国的客户,虽然我们在项目过程中因为彼此工作习惯的不同有过几次摩擦,却给与我了一个很高的评价。最后一天工作,负责沟通的那个美籍台湾人说,when i told the developers that 8/15 is your last date of this projects, they all very happy..see how great job you have did..You are great helper. We helped them too much in the project, and you did most of it. Thanks all your help...

    不可否认的,因为这个评价,我美了一天。。那种感觉,似乎比接到她从大洋彼岸给我寄来的礼物还要兴奋很多。。

    我不知道以后的项目还会遇到些什么事情什么人,会不会再一次遇到如她这样nice的人,但是我知道,我的工作还会继续。。我也会更加努力的去实践testing life is part of my life的诺言

     

  • 外派的出路

    2008-8-01

    外派,一个在IT领域一点都不陌生的词汇。外语一般称之为on-site

    在中国已经有一段时间的历史了。

    外派,最初对于所有人来说都是一个美丽的梦

    因为门槛或者技术或者外语等等限制,想到世界top级别公司上班却无法去的人,可以作为某一个外派公司员工的身份,可以以技术,外语以及门槛略低的条件进入那样的公司工作。如果表现突出,则可以找到合适的时机,成为梦想中的公司的正式员工。

    外派,走到了今天,又几乎成了很多人的一个伤痛

    因为外派,工作地点不在自己的公司,除了当初找自己进门的hr,公司小的领导会认识你,公司大的领导都不会知道你这个人的存在,除非你惹出了大的麻烦。。公司的福利待遇,公司的免费培训,公司的员工的归属感,优越感。。等等都与你天生没有关系。。

    而你派往的那家公司,即使知名度很高,既是薪资待遇很高,福利很高,对员工很人性化,跟你也没有关系。因为你不是他们的员工,他们的待遇几乎可以说是天经地义的跟你没有任何关系。虽然你在为他们干活。

    劳动力成本在上升,公司在缩减成本第一个想到的就是把项目到期,后续项目没有消息的你,开出去。。

    于是,你回到了似乎陌生又似乎熟悉的自己的公司。

    面对的是公司老总一张阴沉不定的脸。良久,告诉你说,因为你没有项目了,暂时无法给公司创造价值。所以经过公司领导的商议,决定给你开基本工资-800抑或1000,等你找到项目,工资再行调整。。

    于是,你无语问苍天,于是,你终于知道,外派,原来是这样的一个过程。。

    这不是开玩笑,是真实的发生在我身边很多外派同仁的故事。

    写到这里,我想说,如此的待遇,如果你是外派员工,你还会以外派的身份工作多久?还能坚持多久?

    同样,秉承着有项目有待遇,只能从员工汗水中榨取剩余价值,却无法为员工分担风险的外包公司?你的路还能走多远?

  • 软件测试的目的

    2008-7-29

    一个很古老的话题

    每一本书都会有自己的解释,无论作者有多少的测试体会

    每一个人都会有自己的觉悟,而不论有多少的经验

    民间的包括所谓官方的(IEEE),如果你愿意,可以在网络上都到成千上万也不同的说法。

    软件测试的目的到底是什么?

    相信每一个步入测试领域的人都曾经问过或者想过这样的问题

    这个问题也曾在我学习的过程中困扰了我许久许久。

    最终,至少在理论上我们可以找到这样的答案:

    软件测试的目的在于通过各种手段来验证需求的正确性

    软件测试的目的在于尽早的发现bug..

    但是实际的测试中,我们发现,我们测试的目的其实是两者兼有的。

    如果说测试的目的在于验证需求的正确性,没有什么不对。验证的方法也多种多样,比如静态/动态的测试,比如通过性和破坏性测试,比如黑盒测试和白盒测试,比如手动测试和自动化测试。。

    只不过,验证需求的正确性作为目的话似乎也不全面。原因在于,1.发行bug一定程度上可以激发测试人员的测试积极性。在很多的公司,也是考核测试人员绩效的一个很重要的数据。2.用最少的测试用例,在最短的时间内发现迄今为止没有发现出来的bug,特别是对系统影响深远的bug对于一个产品的成败有着很大的意义,对于客户的修复成本也有重要的意义。如果仅仅因为验证需求,有一些潜在的问题就不会有人有那么大的兴趣去挖掘。最终的结果就会导致,测试的质量在某种程度上难以保证。

    但是发行bug也绝对不是软件测试的唯一目的。其道理很简单。一味的强调bug的重要性,发行bug作为测试的唯一目的势必导致测试人员盲目的为了发行defect而偏离了测试的重心。

    所以软件测试的目的应该是双方面的,通过各种手段验证软件的需求,并且尽早的发现bug以促使软件得到尽快的修复。

    首先,保证了第一方面,验证软件的需求,可以保证测试的覆盖率,客户关注的功能可以不被忽视。尽早的发现和发行bug,可以促使问题可以得到早日的解决,对于客户来说,也可以节约大量的修复成本。

    测试之路,路漫漫,其修远兮,吾将上下而求索。。

     

     

  • 测试同化现象

    2008-7-28

    前几日,和同事讨论起这个问题,偶有所感

    1。 何谓测试同化现象

    所谓同化现象,一方面是指随着时间的推移,开发人员会逐渐影响测试人员的思维和对缺陷的判断能力,尤其是针对同一产品,同一组开发人员和同一组测试人员共同配合了很长时间,很多本来是缺陷的问题,由于测试人员对软件“习惯成自然”的使用,会不被当成缺陷,尤其是在开发人员的解释和说服下。这是从主观上讲,也就是说从人的主观能动性上来讲这个现象。

    此类同化现象的发生可能意味着“恶性循环”的开始:测试人员会帮着开发人员解释一个个缺陷的合理性,一轮有一轮的测试都不会发现问题。可是这种没有问题却真正的意味着软件风险的扩大。


    从另外一方面来讲,测试同化现象也被称之为“杀虫剂现象。术语“杀虫剂现象”(1990年,Boris Berizer在其《software testing techniques》中杜撰了“杀虫剂怪事”)用来描述软件测试越多,其对测试的免疫力就越强的现象。同样的事情发生在对昆虫使用杀虫剂上。如果你总是用同样一种农药,害虫最后就有了抵抗力,杀虫剂将不再发挥作用。

    这样的现象是从客观角度来看。不是因为人为的疏忽而是一种客观无法回避的事实。

    2。如何避免测试的同化

    很多人建议说,应该多发布测试版本,应该多招聘新的测试人员来避免这样的事情。而实际上,这不是能解决这个问题的根本。

    从主观来说,主观方面造成测试同化的原因是在于人的因素。是习惯了开发人员思维,并且相信了开发人员解说的人造成的一部分测试同化。对于这样的原因,用招聘新的测试人员来觉得其实是不明智的。

    首先要加强测试人员的自我修养,让他们认识到测试的原则在哪里,而且要挖掘自己的怀疑精神(怀疑精神是测试人员的必要的素质之一),不能轻易相信开发人员似是而非的理论。要学会一切用事实证据说话,没有证据证明的东西不要轻易的去相信。

    另外要加强测试员之间的互动,不能由一个测试员总是测试相同的测试项目/模块。而是要时常进行轮换,这样一方面可以避免之前被遗漏的点尽快地被找出来,也会避免因为太熟悉而忽略某个测试的严格度。当然对于主观上确保降低测试同化,也起到很大的作用。

    对于客观方面成就的测试同化,测试员应该养成从多角度来观察问题的习惯。并且在自己之前设计的测试用例,几轮之后已经无法测试出bug的时候,要学会补充设计新的测试用例,从而从别的角度发现新的问题。

  • 软件测试的原则

    2008-7-28

     
    1)1.在测试工作开始以前,不应设想程序中没有缺陷或找不出缺陷。(测试心理学)
    2)2.测试以前应预知测试的结果数据。
    3)3.程序员尽可能避免测试自己写的程序。坚持独立测试原则,必要的情况下建立独立测试机构。
    4)4.测试用例应兼顾有效输入和无效输入。即 不仅要检验程序是否做了该做的事,还应检验是否做了不该做的事。 事实也证明,忽视无效输入的测试往往会遗漏在复杂或者非常态下的重大问题。5)6)测试的充分性。
    7)5.测试的有效性。
    8)6.限于人力、物力,测试工作适可而止。最优化测试的图表还记得吗?(测试经济学)
    9)7.保留一切测试用例。 这些测试用例也属于测试成果物的一部分。此外还有提交的缺陷文件,测试数据等等。这对于测试结束后,下一个版本的更新都是重要的参考资料。
    10)8.任何已测程序的变更都应重新进行测试。这也是回归测试的重要意义和原则。不能因为以前没有问题,在发生版本变更或者程序修改的时候就忽视对其的测试。不进行相对的充分测试,是无法知道修改到底是否导致了多少个模块发生了变化。
     
  • 测试的边界

    2008-7-24

    我这里指的边界,不是指黑盒测试中的那种测试方法--“限界值”测试。而是说,作为一个测试者,我们的覆盖面到底有多宽。。

    这种感叹,自然就来源于我的测试生活。

    今天,美国的客户抱怨了,也让我觉得很头疼。

    我不忍于她羸弱的身躯和年迈,很多事情,已经主动为她承担,可是,这样的抱怨,是对我测试工作的不负责任。我自然接收不了。于是,PK了一次。

    结果是--没有结果。女人和女人的战争是没有结论的,这句话居然在工作中也适用,真是让我郁闷。

    她不愧是炎黄的子孙,虽然对于中国的某些东西已经生疏,表面上已经是一个非常到位的香蕉人。但是,接触到现在,我发现了,骨子里还是那样的。。含蓄且让人咬牙切齿。。

    她表扬我是一个excellent tester, help her so much.但是,她抱怨说我的测试过界了,说我发现了一些虽然是很严重但是却超出她测试设计的问题。说我没有很好地把握测试的原则,这样将会让这份本来已经delay 了很久的工作继续无休止下去。

    唇枪舌剑的PK之后,老太太去睡觉了,我却无法平静。

    我早就意识到她测试设计的有问题,但是因为负责项目的人是她而不是我,我只能从她的角度去理解。

    何谓测试的边界?

    根据她的理解,自然是超出她测试设计范围的都是边界外的东西,也就是说,有时间的话可以测试,没有时间的话,可以测试。

    对于我找出的这些,任何一个足以搞垮整个系统的问题,她自然无法说,那不是问题,心里面却是另外一番想法。。

    而对于我来说,测试的边界取决于UI的文档,取决于需求文档对于功能的描述。不涉及在这些文档中的功能,必然不再测试设计之内,如果进行测试,时间充裕的话,无可厚非;如果时间来不及,不测试也应当。但是没有针对需求或者UI设计文档,或者不足以覆盖全部的功能,除非有变更,否则就是一份失败的测试计划。

    严格按照这样的测试计划来进行的测试,当然就会遗漏很多的问题。

    我不过就是参照文档,把她落掉的功能测试了而已。。

    看别人的足迹,总是可以为自己的前进找到道路,于是我更加知道了,在以后的测试道路上,我该如何更好地去做。stable

    ******编外

    一直很感激自己当初的决定,没有去国企或者与我专业对口的行业。

    我是一个比较向往自由和平等的人。不怎么惧怕权威,我信服的是能力而不是领导的架子。

    也很高兴能做这样的项目,虽然职位上有高有低,有了争执,有了问题,大家可以心平气和的协商,无论是否有结果,都不会影响到后续的工作和合作。

    我想,心有所系,时刻记得自己是领导的人应该不适合作领导,只有肚里能撑船的人才适合做宰相,也不是没有道理的。。

  • 转:改变小巷思维

    2008-7-03

    前一段看电视剧《奋斗》,房地产老总徐继森说的这句话对我启发很大。的确人如果身处在小巷之中,就很难有回旋余地,只能一直向前,即便前面是高山火海,也没有办法退却。这样思维就会受到很大的限制,甚至是很危险的。所以,突破小巷思维才能有更为广阔的空间。

         我以为,自己长期以来就处在小巷思维之中。小巷思维说白了就是一种僵化的思维,就是不懂变通的思维,这在今天变革的社会里是难有立足之处的。以前我曾以自己有这种执著而骄傲,今天它却成了我工作、生活中的“阻力”,成了我需要花大气力克服的难题。这就验证了一句哲学名言:一切都是发展变化的。

          发展变化是永恒的规律,所以个人的思想观念也要随着客观形势的发展变化而改变,虽然这种改变有时是痛苦的、艰难的,但为了能有一个更好的将来,你就不得不放弃你曾经苦苦追求才得到的东西、你经过苦苦思索才求证的真理、有时甚至是做人的一些准则。它真是一种脱胎换骨的改变!

          现在我为自己能有这种认识感到欣慰。这也是形势推着自己不得不去改变,有句话说得好:变则通、变则达。这条路不通,就换另一条路走,这种办法不行,就换另一种办法。办法总比困难多,条条道路通罗马。没有比脚更长的路,没有比人更高的山。在今天的社会里,要生存、要发展,就要充分发挥个人的主观能动性,就要懂得变通,这也是一种智慧!

     
Open Toolbar