发布新日志

  • 测试感触二(纯属一家之言)

    2007-09-14 16:54:03

       在看游戏测试时,得之创造高质量的游戏产品,除了设计,技术外,还有一个重要的是过程。

       对于过程的规划与控制,需要人为的按部就班,按质按时的进行管理。

       其实在公司待这么久了,发现我们公司的管理还是有一定问题的。最主要原因是一些事情并不是按规范做的。

       比如,工作的分配上。开发人员就干开发人员做的事,测试人员就做测试人员该做的事。可发现我们开发人员竟然做测试人员做的事情。有次,经理安排他们写测试报告,还有什么测试用例什么的?当时是相当的纳闷。可后来也想,我们的测试部门刚成立不久,对公司产品没有他们熟悉,而且,我们的开发人员好像进行过测试方面的培训。所以,他们兼职两份工作。

       可既然我们存在了,就让我们做测试人员该做的事情呀!哎,无语。

       还有一个问题,我们的服务执行力不够。究其原因,是大家长久放松的心态问题,感觉没有太大的压力,没有严肃起来。或许,是能力没有用武之地。

      可不管怎样,自己还是要不断学习的。做事要认真负责的,要以客户为中心。将其培养成一种习惯。

     

      

  • 提交bug有感

    2007-09-05 20:04:18

        身边有一个高级主管,就是幸福。

        有什么错误,哪些工作不到位,他都很耐心的给你提出来。不过,也有烦的时候,就是他忙的时候。

        最近在提交bug时,出现了不完美的地方。这不,头儿又给俺做指导了。

       两个大问题 :

       1,summary不够概括,简练。太罗嗦

       2,提交的bug report过于罗嗦,不易看懂。

       发现问题就要解决问题,为此,本人结合自身特点,从网上找到相关资料,加以总结。

      提交有效bug需要注意以下几点:

    n    短小简练:通过使用关键词,可以使软件缺陷的标题的描述短小简练,又能准确解释产生缺陷的现象;
    主页的导航栏在低分辨率下显示不整齐主页导航栏分辨率等是关键词。
    n    单一准确:每一个报告中针对一个Bug; 在一个报告中报告多个软件缺陷的弊端是常常会导致缺陷部分被注意和修复,不能得到彻底的修正.
     
    n    步骤清晰:要清楚地描述出Bug的发生场景,包括前置条件和操作的详细
     
    n    特定条件:许多软件功能在通常情况下没有问题,而是在某种特定条件下会存在缺陷;
     如特定的操作系统、浏览器或某种设置等,能够提供帮助开发人员找到原因的线索。
     
    n    可以再现: 提供缺陷的精确操作步骤,使开发人员容易看懂,可以自己再现这个缺陷,通常情况下,开发人员只有再现了缺陷,才能正确地修复缺陷。
     
    n    不做评价:在报告Bug时只描述事实,不做评价,也不要有人身攻击
     
    n   补充完善:必要的时候可以添加注释(remarks);可以上载屏幕抓图和其他附件。
     
       PS:发现有一个相对简单的方法,不知道怎么概述summary时,就先进行bug report,随后,总结精华。

       

  • 测试感触(纯属一家之言)

    2007-08-20 21:09:15

      虽然搞测试才只有半年而已,然而有些想法感觉与其他人不一样。

       搞测试,并不是只有做过开发,才能搞测试。没有做过开发,照样也能搞测试。当然,这两种说法都各有各的说法。不过,不可否认的是,只有你对测试有兴趣,保持你的这份兴趣,就能玩好它。

       执行test case时,并不是随便拉来一个人就可以做的。而最开始我接触的一些人,一些书中,都多少有点这些意思。首先说设计测试用例,这并不是一件简单的事。它需要设计人员熟悉产品的业务流程及逻辑设计。我说的都是普遍情况。对于执行者来说,也需要了解甚至熟悉设计测试用例人员的设计思路,并不是简单的设计人员怎么设计,你就怎么执行。首先,你需要把握他的设计思路,将干巴巴的文字在自己的思维中有血有肉。

       开发人员和测试都是一家人,为什么那么多人说,开发瞧不起测试,两人不和?人与人之间肯定都是有矛盾的。就看你以什么样的心态和方式去解决它?自己没有找到好的方式解决,就随便说些不负责任的话。如果你心平气和地告诉开发人员,我们大家所作地一切都是为了客户,为了我们的公司,当然也为了我们自己,并给他时间,让他烦躁的心情放松一下,他会不同意吗?虽然说是这样说,但就看你会不会做了。

       我在一些测试群中看到好多刚介入测试的人,基本上都有一个共同的特点。就是急于求成,急于玩测试工具。

       在好多文章中都看到这样的一些观点,不论是关于测试流程,还是涉及到测试用例,等等等等。当说到解决流程不规范,或用例流程不规范的这些问题时,作者总说,要做好,避免在后期投入更大代价的做法就是,从需求阶段做起。

        我肯定这种说法,从需求做起,可以避免以后带来更大损失。可我们在每次测任一产品时,都能保证从需求阶段做起吗?除非你的软件在开发阶段的工作做得很到位。

        还有一点,尽管我们的测试行业目前很吃香。不少人也很感兴趣。但你真的是应为想在测试道路上有一番作为而加入测试的,还是仅仅为了找一份可靠的工作。做好测试工作,一个基本的条件是要对它有足够的热情和兴趣。 

       测试是一个持续进行的过程,而不是一个阶段。在一次又一次的进行回归测试时,能否很有耐心的并高效率的出色的完成工作呐?

       测试确实是一门艺术。其中的滋味只有体会了,才懂得其具有的内涵。

  • 一些典型的测试方面的误解(摘记)

    2007-06-08 13:21:07

    在我们每天的工作中,我们可能时时都在面对着对测试的批评和指责中。开发人员或管理人员试着用这种或那种的理由要求我们在测试过程中更负责,更仔细些。但是你认为他们对你的要求或指责都是正确抑或合理的吗?作为一个测试人员,你是否在工作中固执己见?作为一个管理者,你是否一味地追求高深的技术或测试自动化呢?本文参照了国外一些资深的测试专家的观点,并结合本人多年的经验而成。希望我们能够更理性的把测试工作做的更好。

    测试的角色

      ◆认为测试小组应负责保证产品的质量

      -这是经常被开发人员和管理人员滥用的一句话。经常出现在出现问题时,对测试小组的指责中。就是由于这个观念的存在,导致很多问题在开发晚期或测试后期才发现,可能需要大量的返工甚至拖延了产品的发布时间。其实在开发过程中的每一人都有可能影响产品的质量。这就像建房子一样,房子出现问题了,只是检查人员的问题吗?我想如果每一个人都心怀以“质量为中心”,小心谨慎的做好自己的工作,产品的质量会上一个很多的台阶。 (实际没那么严重,请教过测试群里的高手。)

      ◆认为测试就是为了发现错误

      -在很多“软件测试”的定义中,都提到类似“软件测试是为了发现错误”的话。其实这个观点是提醒人们在测试过程要以查找错误为中心,而不是证明软件的正确功能。

    (有点模糊,不太明白。)

    但是很多人仅凭着字面的意思就认为发现错误是测试的唯一目的,那些找不出任何错误或很少错误的测试都不是成功的测试,这是错误的。

      其实测试不仅仅只是为了发现错误,还需要分析错误产生的原因和其分布情况,为开发人员,管理层提供参考,指出产品或开发过程中存在的主要问题。而且随着人们对产品质量的要求的提高,出现了多样的测试类型。象易用性测试,性能测试,覆盖率测试,恢复性测试,完整性测试等,这些测试都不是完全为了发现错误,而是找出和预期标准不同的问题。

      所以个人认为还是IEEE在1983年提出的:“使用人工或自动手段来运行或测定某个系统的过程,其目的在于检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差别。”比较权威。

      ◆认为测试不能发现重要的错误

      -有些开发人员认为单纯的手工测试只是发现系统的一些皮毛问题,因此从心里看低测试人员。但有过经验的开发人员知道,测试人员也发现了很多重要的问题。我曾经看过一些在开发小组中特别有权威的测试人员,他们虽然也只作黑盒测试,但他们发现的错误都是重量级的。

  • 测试工程师报BUG的感悟

    2007-05-10 21:24:20

    对于初次接触测试的测试工程师,他们的心里是“尽可能多的找出BUG来”,因为找出大量的bug可以从一定角度反映出测试工程师的工作量和工作能力。虽然这种想法是值得肯定的,但是测试工程师不能忽略了这么一点:报BUG的技巧。

          所有的测试工程师必须明白这么一点:发现bug并不是你的工作目的,只是你的工作任务。在一个团队中,所有的工程师都应该对质量负责,测试工程师更甚。那么测试工程师发现的bug最后还是应该得由开发工程师解决的,所以报有用的bug,报高效的bug是衡量测试工程师的工作能力的一个重要指标。

           所以:测试工程师应该对该bug的现象,概率等有深刻的认识,同时应尽可能多的提出对与解决这个bug有用的信息。

           测试工程师们不要把“报尽可能多的bug”做为你们的工作任务,而应该把“报高效的bug”做为你的工作重心,这样才可以成长为一个优秀的测试工程师

  • 测试工具相关

    2007-05-10 21:23:27

    测试工具大全                   

    Author: Vince      来源:http://blog.csdn.net/vincetest

  • 软件国际化测试和本地化测试

    2007-05-09 20:06:50


    关于什么是测试就不多说了,大家都知道的。关键是理解什么是本地化,什么是国际化?还要理解对什么产品进行本地化和国际化。这里仅以软件作为本地化和国际化的对象进行讨论(实际上,除了软件之外,网站和电子课件都可以进行国际化和本地化)。

    软件的国际化和软件的本地化是开发用于全球发行的软件的两个过程和技术。

    首先软件在开发阶段要在结构设计和数据类型支持上,满足世界各地用户的需要。例如,微软开发的Word 2003,它最先是用英文开发的。但是,英文的Word 2003可以安装在简体中文的Windows XP Professional上,而且支持中文输入法(IME),能够正确的输入、显示、打印和保存,而不是乱码。这就是代码能够支持汉字的双子节字符集。

    另外,Word 2003能够支持中文的数据格式,例如日期采用年月日,而不是月日年。另外就是中文关键词排序,简体中文词组按照第一个字的汉语拼音的顺序排序,而英文单词按照首字母排序。说明软件能够支持不同国家用户的特殊数据类型。

    所以软件国际化是在软件设计和文档开发过程中,使得功能和代码设计能处理多种语言和文化习俗,使创建不同语言版本时,不需要重新设计源程序代码的软件工程方法。

    那么什么是软件本地化呢?

    还是拿Word 2003为例说明,前面说了,英文Word 2003能够在简体中文Windows 2003上安装和使用,但是大家很少直接使用英文的Word 2003,为什么呢? 因为使用英文的软件不如使用中文的软件更易于理解。

    把英文Word 2003经过语言处理和技术加工,重新制作成简体中文Word 2003的过程,称为英文Word 2003的软件本地化。当然除了简体中文之外,Word 2003还有几十种其他语言的本地化,例如,日语、德语、法语,繁体中文的Word 2003。

    所以,软件本地化是对原始语言(例如,英文)开发的软件进行语言转换和工程处理,生成不同语言版本的技术。

    最后说说什么是国际化测试和本地化测试?

    单独说“本地化测试”和“国际化测试”很容易引起误解,最好限定测试对象。最好的说法是“本地化软件测试”,“软件国际化测试”和“国际化软件测试”。

    “本地化软件测试”前面已经说了,就是在本地化的操作系统上测试本地化软件,例如在简体中文Windows XP Professional上测试简体中文的Word 2003。

    “软件国际化测试”和“国际化软件测试”是两个不同的概念。“国际化软件”也称为“全球化软件”,是在世界多个国家和地区发行的软件。完整的国际化软件需要经过软件国际化设计和软件的本地化加工两个阶段。

    “国际化软件测试”的内容分为“软件国际化测试”和“本地化软件测试”,“软件国际化测试”是“国际化软件测试”的子集。

    国际化软件测试首先要经过软件国际化测试,等到本地化软件开发出来后,再进行本地化软件测试。
    软件国际化测试的对象是采用国际化方法进行设计的软件,例如英文的Word 2003。 测试的环境是各种不同语言的操作系统,例如简体中文、繁体中文、德语、日语等的Windows 操作系统。
    国际化测试的内容包括产品的安装和卸载,是否支持不同区域设置的数据格式(日期、时间、度量衡、地址、电话号码、纸张格式),是否支持不同字符集的编码和输入、编辑、显示和保存。

    软件本地化的对象是经过本地化后的软件,例如,简体中文的Word 2003。
    对于简体中文的Word 2003的本地化测试的环境是简体中文的Windows,对于德语Word 2003而言测试环境是德语的Windows。
    软件本地化测试的内容包括:软件的本地化内容是否准确,软件经过本地化后功能是否失效,软件控件(例如按钮的大小和按钮上的文字)的大小和位置是否适当。 

    Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1492357


    [收藏到我的网摘]   scmcopew发表于 2007年01月24日 16:56:00



     

  • 关于建立测试套件的问题

    2007-05-09 19:57:45

     


    在TestManager中建立测试套件的时候。
    是这样的步骤: New Suite->( 我选择 Functional Testing Wizard-> OK->下一步->在Test scrīpts里选择GUI脚本,却出现如下文字:


    “An unknown error was encountered selecting a type from the AutoScheWizard2 property page"
    请问各位大侠,该如何解决这个问题:
    这个问题我解决了:
    新建一个工程文件,将原工程的TestDatastore\DefaultTestscrīptDatastore  (数据文件)拷贝到新工程里面,然后利用rational  doctor更新就可以了

  • 软件工程师角色定位

    2007-05-09 19:55:56

    角色不明,责任不清,行为就失去了参照目标,结果就可能很不理想了。轻则降低了工作质量和效率,重则被视为工作能力低下,可能要退出软将项目组的舞台了。


    软件测试工程师承担的任务

        角色决定工作内容和承担的任务。测试工程师的角色应该承担什么任务呢?这没有统一的答案。因为,这与软件公司的规模,软件项目管理制度,公司领导和项目经理的管理风格,以及具体软件项目自身的特点有很大关系。而且,测试工程师也有普通和高级之分。

        笼统的答案列举如下:

    设置软件测试环境,安装必要的软件工具。
    运行软件,发现和报告软件缺陷或错误。尤其需要快速定位软件中的严重的错误。
    对软件整体质量提出评估
    确认软件达到某种具体标准
    以最低的成本,最短的时间,完成高质量的测试任务
    ......
        在这其中,最重要的是要明确,程序员的责任和目标。在执行任何具体测试任务前,都要在项目组内对于责任和目标达成共识,以免带来后续工作的相互推诿。


    提高测试质量的要诀

        另外一个值得注意的方面就是工作效率和质量,或许高级测试工程师与普通测试工程师的主要区别在于高级测试工程师可以更快地发现更多软件中的严重错误。对此,有什么可以借鉴的诀窍吗?请尝试以下方法,保证不会是您失望。

    首先测试程序的核心功能,然后测试辅助功能。
    首先测试功能,然后测试性能。
    首先测试常见情况,然后测试异常情况。
    首先测试经过变更的部分,然后测试没有变更的部分。
    首先测试影响大的问题,然后测试影响小的问题。
    首先测试必须测试的部分,然后测试可选或没有要求测试的部分

     


    软件测试工程师避免犯的几个错误

        前文已经指出测试工程师应该明确角色,明确任务和责任。知道哪些是自己份内的事,哪些是不属于自己的事。一定要尽最大努力完成份内的事,不要做不属于自己的事情,以免弄巧成拙。

        为了更好的扮演软件测试工程师的角色,尽量避免犯下面的错误:

    承诺完成测试的软件没有质量问题
        软件测试只是保证质量的一种方法,软件测试工程师的工作不会直接提高软件质量,因为绝大多数软件错误都需要程序员修复。软件测试只能证明软件存在错误,不能保证软件没有错误,不可能找出全部软件错误。个人的能力和对质量的影响范围很小,软件质量的提高要靠软件项目团队全体成员的共同努力。  

    承担软件的发布权利
        不要因为软件中存在还没有修复的错误,而试图提出更改软件发布的计划。也不要认为已经完成了测试计划,自己决定可以发布软件。因为,改变软件发布计划可能要失去进入市场的良机和很多客户,对此造成的经济和公司市场的损失将不是测试工程师能够承担的。另外,软件发布后,如果用户发现了新的软件错误,公司领导或项目经理可能将过错加在软件测试人员的头上,因为他们同意发布软件。通常软件发布的权利由产品经理、项目经理、测试经理、市场经理共同集体讨论决定。  

    扮演过程改进成员的角色
        软件测试工程师必须报告错误,有时也要分析错误的类型、特征和产生错误的原因。但是,不要主动提出改进软件过程的具体改进措施,更不要直接干涉程序员的工作方式,以免出力不讨好,影响今后的愉快合作。软件过程改进的方法是软件质量控制部门的事情,这是他们的本职工作。

     


     

  • 工具类别

    工具名称

    生产厂商

    相关网站

    通用功能自动化测试工具

    Winrunner

    Mercury

     

    Quicktest pro

    Mercury

     

    Xrunner

    Mercury

     

    QARun

    Compuware

     

    TestPartner

    Compuware

     

    WebKing

    Parasoft

    http://www.parasoft.com

    Robot

    IBM Rational

    http://www.ibm.com/cn

    Visual Test

    IBM Rational

    http://www.ibm.com/cn

    Functional Tester

    IBM Rational

    http://www.ibm.com/cn

    SilkTest

    Segue

     

    SilkTest International

    Segue

     

    e-Tester

    Empirix

     

    WebFT

    Radview

     

    TestComplete

    AutomatedQA

     

    QA Wizard

    Seapine

     

    Software EggPlant

    RedStone

     

    Test Edition

    Microsoft Visual Studio

     

    PureTest

    Minq

     

    Autotester

    Autotester

     

    Testbench400

    Original Software

     

    TestExpert

    VEReCOMM

     

    TestRunner

    Qronus

     

    TTCN suite

    Telelogic

    http://www.telelogic.com.cn

    QC/Replay

    Centerline

     

    Web

    AutoTester

     

    eValid

    Software Research

     

    WebART

    OCLC

     

    MaxQ

    开源

     

    WebInject

    开源

     

    Marathon

    开源

     

    性能测试/监控工具

    LoadRunner

    Mercury

     

    SiteScope

    Mercury

     

    Topaz

    Mercury

     

    QaLoad

    Compuware

     

    PerformaSure/benchmark

    Quest

     

    Silkperformer

    Segue

     

    Silkperformer Lite

    Segue

     

    SilkCentralTM Performance Manager

    Segue

     

    e-Load

    Empirix

     

    Robot

    IBM Rational

    http://www.ibm.com/cn

    Performance Tester

    IBM Rational

    http://www.ibm.com/cn

    WebLoad

    RadView

     

    Web applicaton stress tool 

    Microsoft

     

    Application center test

    Microsoft

     

    PureLoad

    Minq

     

    Athene APR

    Metron