希望能找到能与我共同进步的知心朋友!

发布新日志

  • 认识单元测试

    2009-02-10 11:00:44

    下面是我准备让开发人员了解的单元测试知识,从而有利于测试人员进行系统测试。不足之处请大家指出!多谢!

    认识单元测试

     

    一、单元测试的重要性

      单元测试是软件测试的基础,因此单元测试的效果会直接影响到软件的后期测试,最终在很大程度上影响到产品的质量。从如下几个方面就可以看出单元测试的重要性在何处。

      时间方面:如果认真的做好了单元测试,在系统集成联调时非常顺利,因此会节约很多时间,反之那些由于因为时间原因不做单元测试或随便做做的则在集成时总会遇到那些本应该在单元测试就能发现的问题,而这种问题在集成时遇到往往很难让开发人员预料到,最后在苦苦寻觅中才发现这是个很低级的错误而在悔恨自己时已经浪费了很多时间,这种时间上的浪费一点都不值得,正所谓得不偿失。

      测试效果:根据以往的测试经验来看,单元测试的效果是非常明显的,首先它是测试阶段的基础,做好了单元测试,在做后期的集成测试和系统测试时就很顺利。其次在单元测试过程中能发现一些很深层次的问题,同时还会发现一些很容易发现而在集成测试和系统测试很难发现的问题。再此单元测试关注的范围也特殊,它不仅仅是证明这些代码做了什么,最重要的是代码是如何做的,是否做了它该做的事情而没有做不该做的事情。

      测试成本:在单元测试时某些问题就很容易发现,如果在后期的测试中发现问题所花的成本将成倍数上升。比如在单元测试时发现1个问题需要1个小时,则在集成  测试时发现该问题需要2个小时,在系统测试时发现则需要3个小时,同理还有定位问题和解决问题的费用也是成倍数上升的,这就是我们要尽可能早的排除尽可能  多的bug来减少后期成本的因素之一。

      产品质量:单元测试的好与坏直接影响到产品的质量,可能就是由于代码中的某一个小错误就导致了整个产品的质量降低一个指标,或者导致更严重的后果,如果我们做好了单元测试这种情况是可以完全避免的。

      综上所述,单元测试是构筑产品质量的基石,我们不要因为节约单元测试的时间不做单元测试或随便做而让我们在后期浪费太多的不值得的时间,我们也不愿意因为由于节约那些时间导致开发出来的整个产品失败或重来!

     

    二、单元测试与功能测试比较

    单元测试好比房屋建筑现场的建筑监理员,他关心房屋的各个内部系统,如地基、构架、供电系统和管道设备等。房屋每部分工作都安全、正常。 单元测试是从开发者的角度来编写的。它们确保类的每个特定方法成功执行一系列特定的任务。每一个测试都要保证对于给定的一个已知的输入应该得到所期望的输出。

           
    功能测试类似于视察同一建筑现场的房主,他假定内部系统将正常运作,并假定建筑监理员在执行其任务。房主关心的是住在这所房子里将会怎样。他关心房子的外观如何,各个房间的大小是否合适,房子能否满足家庭的需要,以及窗户的位置是否有利于采光。
        

    三、单元测试内容和步骤

    单元测试的内容

    单元测试的对象是软件设计的最小单位——模块或函数;

    单元测试的依据是详细设计描述,测试者要根据详细设计说明书和源程序清单,了解模块的I/O条件和模块的逻辑结构。

    主要采用白盒测试的测试用例,辅之以黑盒测试的测试用例,使之对任何合理和不合理的输入都能鉴别和响应。要求对所有的局部和全局的数据结构、外部接口和程序代码的关键部分进行桌面检查和代码审查。

    单元测试任务包括:1 模块接口测试;2 模块局部数据结构测试;3 模块边界条件测试;4 模块中所有独立执行通路测试;5 模块的各条错误处理通路测试。

      

    1、模块接口:模块接口测试是单元测试的基础。只有在数据能正确流入、流出模块的前提下,其他测试才有意义。测试接口正确与否应该考虑下列因素:
      1 输入的实际参数与形式参数的个数是否相同;
      2 输入的实际参数与形式参数的属性是否匹配;
      3 输入的实际参数与形式参数的顺序是否一致;
      4 调用其他模块时所给实际参数的个数是否与被调模块的形参个数相同;
      5 调用其他模块时所给实际参数的属性是否与被调模块的形参属性匹配;
      6调用其他模块时所给实际参数的量纲是否与被调模块的形参顺序一致;
      7 调用预定义函数时所用参数的个数、属性和顺序是否正确;
      8 是否存在与当前入口点无关的参数引用;
      9 是否修改了只读型参数;
      10 对全程变量的定义各模块是否一致;
      11是否把某些约束作为参数传递。

      2、局部数据结构测试:检查局部数据结构是为了保证临时存储在模块内的数据在程序执行过程中完整、正确。局部数据结构往往是错误的根源,应仔细设计测试用例,力求发现下面几类错误:
      1检查不正确或不一致的数据类型说明;
      2使用尚未赋值或尚未初始化的变量;
      3错误的初始值或错误的默认值;
      4变量名拼写错误或书写错误;
      5不一致的数据类型。

      

    3、独立执行通路:在模块中应对每一条独立执行路径进行测试,单元测试的基本任务是保证模块中每条语句至少执行一次。此时设计测试用例是为了发现因错误计算、不正确的比较和不适当的控制流造成的错误。此时基本路径测试和循环测试是最常用且最有效的测试技术。计算中常见的错误包括:
      1 误解或用错了算符优先级;
      2混合类型运算;
      3变量初值错;
      4精度不够;
      5表达式符号错。

      4、错误处理通路:一个好的设计应能预见各种出错条件,并预设各种出错处理通路,出错处理通路同样需要认真测试,测试应着重检查下列问题:
      1输出的出错信息难以理解;
      2记录的错误与实际遇到的错误不相符;
      3在程序自定义的出错处理段运行之前,系统已介入;
      4异常处理不当;
      5错误陈述中未能提供足够的定位出错信息。

    5、边界条件:边界条件测试是单元测试中最后,也是最重要的一项任务。众的周知,软件经常在边界上失效,采用边界值分析技术,针对边界值及其左、右设计测试用例,很有可能发现新的错误。

     

    2、单元测试的步骤

    1 理解需求和设计

      理解设计是很重要的,特别是要搞清楚被测试模块在整个软件中所处的位置,这对测试的内容将会有很大的影响。需要记住的一个原则就是:好的设计,各模块只负责完成自己的事情,层次与分工是很明确的。在单元测试的时候,可以不用测试不属于被测试模块所负责的功能,以减少测试用例的冗余,集成测试的时候会有机会测试到的。

    2 概览源代码

      浏览一下源代码,主要任务:

      (1)初步检查源代码的编码风格与规范

      (2)大致估算测试工作量,比如:需要多少的测试用例、需要写多少的驱动模块和桩模块等。

      (3)确定模块的复杂程度,初步制定测试的优先级等。

    3  精读源代码

      认真阅读和分析代码,主要任务:

      (1)理解代码的业务逻辑。

      (2)检查代码与设计是否相符,如果详细设计没有该模块的流程图的话,先去画出流程图。

      (3)仔细研究逻辑复杂的模块

      (4)可以采用一些检查列表来检查程序可能会出现的问题。如果没有检查列表,那么,可以根据程序的特点,有针对性地检查容易出问题的地方(记得把经验总结下来供下次使用)。

    4  设计测试用例

      综合运用白盒测试方法(和结合黑盒测试方法)来设计测试用例,包括功能测试性能测试等,要达到一定的测试覆盖率。在设计测试用例的过程中,流程图或控制流图是分析的好帮手。

    5  搭建单元测试环境

      使用XUnit或自己写的框架将有助于单元测试的实施。在这个阶段主要就是写桩模块和驱动模块,第4步所设计的测试用例是通过驱动模块传递给被测试模块的,然后驱动模块想办法获取被测试模块对数据的处理结果,并判定返回的实际结果与测试用例的预期结果是否一致,通过测试框架来记录执行的结果,对于出现的错误,还需要统计错误的信息,供执行完之后分析。

      搭建单元测试环境要避免在main函数中使用printfscanf函数来跟测试人员交互来达到获取测试用例数据的信息。这样的测试还是没有摆脱手工测试方式,效率是低下的。同时,对于测试结果是否通过测试也不要使用printf方式打印被测试函数的返回结果值,避免要人工去检查结果。

    6  执行测试

      运行写好的驱动模块完成对被测试模块的测试。

    7  补充和完善测试用例

      单元测试也是个循序渐进的过程,可能一开始考虑的不够全面,或预期的覆盖标准太低,需要在测试过程中不断补充测试用例,直到满足要求为止。

    8  分析结果,给出评价

      根据测试的结果分析、查找错误的原因,并找到解决的办法。测试结束之后,根据测试过程的数据统计,给出被测试对象评价

     

     

  • 如何复现不可复现的严重Bug

    2008-12-05 08:53:16

    从标题来看大家可能会觉得晕,这里说到的不可复现是指这些Bug有时出现,有时候不出现。相信大家在测试过程中肯定遇到过这种Bug,不少这种不可复现的Bug定位起来非常困难,可能很长时间都不能得到解决。能否复现这些不可复现的Bug成为大家关注的一个话题,最近国外的测试专家James Bach、Jonathan Kohl等对这个话题进行了一些探讨,这里把他们的一些思路理出来和大家分享。
        要想复现不可复现的Bug,需要先提到一个概念就是ET(Exploring Test),也就是探索式测试,这种测试方法是由James Bach首先提出来的,在所掌握的被测对象的信息不是很充分的情况下,这是一种很有效的测试方法,如果大家感兴趣,我再整理一篇ET的文章出来。
        在给大家阐述如何复现不可复现的Bug的思路之前,先说说为什么要复现这些不可复现的Bug(废话两句^_^)。对于整个项目或者产品而言,如果这些不可复现的Bug是很严重的Bug,比如导致系统崩溃等,如果不能及时、准确的定位和解决,最终发布出来的软件到达用户手中后,一旦出现势必会影响软件已经公司在用户心中的形象,严重的会“迫使”用户选择竞争对手的产品,这些显然都是公司所不愿看到的。而对于测试人员而言,出现了这些不可复现的Bug,实际上是一次很好的锻炼和提高机会,如果只是提交缺陷报告将这个大皮球踢给开发人员,不仅丧失了一次提高测试水平的机会,还有可能破坏和开发人员之间的关系。
        废话完了,进入正题。当出现不可复现的Bug时,大家可以从以下五个方面来进行考虑:
    1、被测对象的版本信息
        我测试的到底是哪个版本,这主要是有两个作用:一是确认我测试的是正式的软件版本,如果不是就先记录下该问题,然后选择正式的版本进行测试(开发人员基于尝试的一次非正规的修改可能会导致不可复现的Bug);二是可以和其它版本进行对比,如果其它的版本没有类似的问题,就可以去对比这两个版本之间的区别。
    2、环境
        这里的环境是指出现不可复现的Bug时所对应的测试环境等,比如测试所用的计算机,如果出现不可复现的Bug,那我换一台机器是不是还会出现类似的问题,也就是说通过环境的改变来进一步搜集不可复现Bug的相关信息。
    3、模式
        这里的模式是指我对这个Bug如何出现的一个理解,先给这个Bug设定一个模式,比如是不是数据库通信中断,然后再进行测试,收集更多的信息去修改和完善这个模式,这样不断进行,最终直到Bug能完全复现为止,这个时候只要使用这个模式就可以复现出Bug了。
    4、人
        这里提到的人有两个含义:一是测试是由人来进行的,人的操作、人的思维方式会有不同,通过分析这些信息也有可能找到这些不可复现的Bug的蛛丝马迹;二是想复现不可复现的Bug,往往需要多个人之间的相互协作,比如测试人员、开发人员等,通过大家的沟通和协作就能更容易去复现了。
    5、测试工具
        通过一些debug工具或者log工具等搜集内存等信息,根据这些信息来进行分析,找出不同信息之间的共同点,比如某一块内存始终都会被改写等,通过这种方式来去复现Bug。
        上面的五个方面都是和ET的思想紧密相关的,通过不断的测试和不断的信息收集和分析,逐步的把模糊的、不确定的测试变成清晰的、确定的测试,这样就能复现那些不能复现的Bug了。考虑信息时可以从以上五个方面来进行考虑。
  • 国外优秀测试网址

    2008-08-26 16:19:27

    http://bdonline.sqe.com/ 一个关于网站测试方面的网页,对这方面感兴趣的人可以参考
    http://citeseer.nj.nec.com/ 一个丰富的电子书库,内容很多,而且提供著作的相关文档参考和下载,是作者非常推荐的一个资料参考网站
    http://groups.yahoo.com/group/LoadRunner 性能测试工具LoadRunner的一个论坛
    http://groups.yahoo.com/grorp/testing-paperannou-nce/messages 提供网站上当前发布的软件测试资料列表
    http://satc.gsfc.nasa.gov/homepage.html 软件保证中心是美国国家航天局(NASA)投资设立的一个软件可靠性和安全性研究中心,研究包括了度量、工具、风险等各个方面
    http://seg.iit.nrc.ca/English/index.html 加拿大的一个研究软件工程质量方面的组织,可以提供研究论文的下载
    http://sepo.nosc.mil/ 内容来自美国SAN DIEGO的软件工程机构(Sofrware Engineering Process Office)主页,包括软件工程知识方面的资料
    http://www.asq.org/ 是世界上最大的一个质量团体组织之一,有着比较丰富的论文资源,不过是收费的
    http://www.automated-testing.com/ 一个自动化软件测试和自然语言处理研究页面,属于个人网页,上面有些资源可供下载
    http://www.benchmarkresources.com/ 提供有关标杆方面的资料,也有一些其它软件测试方面的资料
    http://www.betasoft.com/ 包含一些流行测试工具的介绍、下载和讨论,还提供测试方面的资料
    http://www.brunel.ac.uk/~csstmmh2/vast/home.html VASTT研究组织,主要从事通过切片技术测试技术和转换技术来验证和分析系统,对这方面技术感兴趣的人是可以在这里参考一些研究的项目及相关的一些主题信息
    http://www.cc.gatech.edu/aristotle/ Aristole研究组织,研究软件系统分析、测试和维护等方面的技术,在测试方面的研究包括了回归测试、测试套最小化、面向对象软件测试等内容,该网站有丰富的论文资源可供下载
    http://www.computer.org/ IEEE是世界上最悠久,也是在最大的计算机社会团体,它的电子图书馆拥有众多计算机方面的论文资料,是研究计算机方面的一个重要资源参考来源
    http://www.cs.colostate.edu/testing/ 可靠性研究网站,有一些可靠性方面的论文资料
    http://www.cs.york.ac.uk/testsig/ 约克大学的测试专业兴趣研究组网页,有比较丰富的资料下载,内容涵盖了测试的多个方面,包括测试自动化、测试数据生成、面向对象软件测试、验证确认过程等
    http://www.csr.ncl.ac.uk/index.html 学校里面的一个软件可靠性研究中心,提供有关软件可靠性研究方面的一些信息和资料,对这方面感兴趣的人可以参考
    http://www.dcs.shef.ac.uk/research/groups/vt/ 学校里的一个验证和测试研究机构,有一些相关项目和论文可供参考
    http://www.esi.es/en/main/ ESI(欧洲软件组织),提供包括CMM评估方面的各种服务
    http://www.europeindia.org/cd02/index.htm 一个可靠性研究网站,有可靠性方面的一些资料提供参考
    http://www.fortest.org.uk/ 一个测试研究网站,研究包括了静态测试技术(如模型检查、理论证明)和动态测试(如测试自动化、特定缺陷的检查、测试有效性分析等)
    http://www.grove.co.uk/ 一个有关软件测试和咨询机构的网站,有一些测试方面的课程和资料供下载
    http://www.hq.nasa.gov/office/codeq/relpract/prcls-23.htm NASA可靠性设计实践资料
    http://www.io.com/~wazmo/ Bret Pettichord的主页,他的一个热点测试页面连接非常有价值,从中可以获得相当大的测试资料,很有价值
    http://www.iso.ch/iso/en/ISOOnline.frontpage 国际标准化组织,提供包括ISO标准系统方面的各类参考资料
    http://www.isse.gmu.edu/faculty/ofut/classes/ 821-ootest/papers.html 提供面向对象和基于构架的测试方面著作下载,对这方面感兴趣的读者可以参考该网站,肯定有价值
    http://www.ivv.nasa.gov/ NASA设立的独立验证和确认机构,该机构提出了软件开发的全面验证和确认,在此可以获得这方面的研究资料
    http://www.kaner.com/ 著名的测试专家Cem Kanner的主页,里面有许多关于测试的专题文章,相信对大家都有用。Cem Kanner关于测试的最著名的书要算Testing Software,这本书已成为一个测试人员的标准参考书
    http://www.library.cmu.edu/Re-search/Engineer- ingAndSciences/CS+ECE/index.html 卡耐基梅陇大学网上图书馆,在这里你可以获得有关计算机方面各类论文资料,内容极其庞大,是研究软件测试不可获取的资料来源之一
    http://www.loadtester.com/ 一个性能测试方面的网站,提供有关性能测试、性能监控等方面的资源,包括论文、论坛以及一些相关链接
    http://www.mareinig.ch/mt/index.html 关于软件工程和应用开发领域的各种免费的实践知识、时事信息和资料文件下载,包括了测试方面的内容
    http://www.mtsu.ceu/-storm/ 软件测试在线资源,包括提供目前有哪些人在研究测试,测试工具列表连接,测试会议,测试新闻和讨论,软件测试文学(包括各种测试杂志,测试报告),各种测试研究组织等内容
    http://www.psqtcomference.com/ 实用软件质量技术和实用软件测试技术国际学术会议宣传网站,每年都会举行两次
    http://www.qacity.com/front.htm 测试工程师资源网站,包含各种测试技术及相关资料下载
    http://www.qaforums.com/ 关于软件质量保证方面的一个论坛,需要注册
    http://www.qaiusa.com/ QAI是一个提供质量保证方面咨询的国际著名机构,提供各种质量和测试方面证书认证
    http://www.qualitytree.com/ 一个测试咨询提供商,有一些测试可供下载,有几篇关于缺陷管理方面的文章值得参考
    http://www.rational.com/ IBM Rational的官方网站,可以在这里寻找测试方面的工具信息。IBM Rational提供测试方面一系列的工具,比较全面
    http://rexblackconsulting.com/Pages/publicat-ions.htm
    Rex Black的个人主页,有一些测试和测试管理方面的资料可供下载
    http://www.riceconsulting.com/ 一个测试咨询提供商,有一些测试资料可供下载,但不多
    http://www.satisfice.com/ 包含James Bach关于软件测试和过程方面的很多论文,尤其在启发式测试策略方面值得参考
    http://www.satisfice.com/seminars.shtml 一个黑盒软件测试方面的研讨会,主要由测试专家Cem Kanar和James Bach组织,有一些值得下载的资料
    http://www.sdmagazine.com/ 软件开发杂志,经常会有一些关于测试方面好的论文资料,同时还包括了项目和过程改进方面的课题,并且定期会有一些关于质量和测试方面的问题讨论
    http://www.sei.cmu.edu/ 著名的软件工程组织,承担美国国防部众多软件工程研究项目,在这里你可以获俄各类关于工程质量和测试方面的资料。该网站提供强有力的搜索功能,可以快速检索到你想要的论文资料,并且可以免费下载
    http://www.soft.com/Institute/HotList/ 提供了网上软件质量热点连接,包括:专业团体组织连接、教育机构连接、商业咨询公司连接、质量相关技术会议连接、各类测试技术专题连接等
    http://www.soft.com/News/QTN-Online/ 质量技术时事,提供有关测试质量方面的一些时事介绍信息,对于关心测试和质量发展的人士来说是很有价值的
    http://www.softwaredioxide.com/ 包括软件工程(CMM,CMMI,项目管理)软件测试等方面的资源
    http://www.softwareqatest.com/ 软件质量/测试资源中心。该中心提供了常见的有关测试方面的FAQ资料,各质量/测试网站介绍,各质量/测试工具介绍,各质量/策划书籍介绍以及与测试相关的工作网站介绍
    http://www.softwaretestinginstitute.com/ 一个软件测试机构,提供软件质量/测试方面的调查分析,测试计划模板,测试WWW的技术,如何获得测试证书的指导,测试方面书籍介绍,并且提供了一个测试论坛
    http://www.sqatester.com/index.htm 一个包含各种测试和质量保证方面的技术网站,提供咨询和培训服务,并有一些测试人员社团组织,特色内容是缺陷处理方面的技术
    http://www.sqe.com/ 一个软件质量工程服务性网站,组织软件测试自动化、STAR-EASE、STARWEST等方面的测试学术会议,并提供一些相关信息资料和课程服务
    http://www.stickyminds.com/ 提供关于软件测试和质量保证方面的当前发展信息资料,论文等资源
    http://www.stqemagazine.com/ 软件策划和质量工程杂志,经常有一些好的论文供下载,不过数量较少,更多地需要通过订购获得,内容还是很有价值的
    http://www.tantara.ab.ca/ 软件质量方面的一个咨询网站,有过程改进方面的一些资料提供
    http://www.tcse.org/ IEEE的一个软件工程技术委员会,提供技术论文下载,并有一个功能强大的分类下载搜索功能,可以搜索到测试类型、测试管理、 测试分析等各方面资料
    http://www.testing.com/ 测试技术专家Brain Marick的主页,包含了Marick 研究的一些资料和论文,该网页提供了测试模式方面的资料,值得研究。总之,如果对测试实践感兴趣,该网站一定不能错过
    http://www.testingcenter.com/ 有一些测试方面的课程体系,有一些价值
    http://www.testingconferences.com/asiastar/home 著名的AsiaStar测试国际学术会议官方网站,感兴趣的人一定不能错过
    http://www.testingstuff.com/ Kerry Zallar的个人主页,提供一些有关培训、工具、会议、论文方面的参考信息
    http://www-sqi.cit.gu.edu.au/ 软件质量机构,有一些技术资料可以供下载,包括软件产品质量模型、再工程、软件质量改进等
  • LoadRunner7.8测试流程(转载)

    2007-09-05 14:18:39

    04 10:56:38 / 个人分类:性能测试
    Loadrunner中参数设置详细分析,相信对大家会有用的,这个版本是基于7.8的。
    做负载或者压力测试时,很多人选择使用了Loadrunner测试工具。该工具的基本流程是先将用户的实际操作录制成脚本,然后产生数千个虚拟用户运行脚本(虚拟用户可以分布在局域网中不同的PC机上),最后生成相关的报告以及分析图。但是在录制脚本的过程中会遇到很多实际的问题,比如不同的用户有不同的使用数据,这就牵涉到参数的设置问题。本文就Loadrunner中参数的设置进行说明,希望对大家有所帮助。
        在录制程序运行的过程中,VuGen(脚本生成器)自动生成了包含录制过程中实际用到的数值的脚本。如果你企图在录制的脚本中使用不同的数值执行脚本的活动(如查询、提交等等),那么你必须用参数值取代录制的数值。这个过程称为参数化脚本。
        本文主要包括如下内容:理解参数的局限性、建立参数、定义参数的属性、理解参数的类型、为局部数据类型设置参数的属性、为数据文件设置参数的属性、从已经存在的数据库中引入数据。
        除了GUI,以下的内容适合于各种类型的用户脚本。
    一、关于参数的定义
        在你录制程序运行的过程中,脚本生成器自动生成由函数组成的用户脚本。函数中参数的值就是在录制过程中输入的实际值。
        例如,你录制了一个Web应用程序的脚本。脚本生成器生成了一个声明,该声明搜索名称为“UNIX”的图书的数据库。当你用多个虚拟用户和迭代回放脚本时,也许你不想重复使用相同的值“UNIX”。那么,你就可以用参数来取代这个常量。结果就是你可以用指定的数据源的数值来取代参数值。数据源可以是一个文件,也可以是内部产生的变量。
        用参数表示用户的脚本有两个优点:
    ① 可以使脚本的长度变短。
    ② 可以使用不同的数值来测试你的脚本。例如,如果你企图搜索不同名称的图书,你仅仅需要写提交函数一次。在回放的过程中,你可以使用不同的参数值,而不只搜索一个特定名称的值。
        参数化包含以下两项任务:
    ① 在脚本中用参数取代常量值。
    ② 设置参数的属性以及数据源。
        参数化仅可以用于一个函数中的参量。你不能用参数表示非函数参数的字符串。另外,不是所有的函数都可以参数化的。
     
    二、参数的创建
        可以指定名称和类型来创建参数。不存在对脚本中参数个数的限制。在Web程序的用户脚本中,你可以使用如下过程在基于文本的脚本视图中创建参数。或者,也可以在基于图标的树形视图中创建参数。
        在基于文本的脚本视图中创建一个参数:
    1、 将光标定位在要参数化的字符上,点击右键。打开弹出菜单。
    2、 在弹出菜单中,选择“Replace with a Parameter”。选择或者创建参数的对话框弹出。
    3、 在“Parameter name”中输入参数的名称,或者选择一个在参数列表中已经存在的参数。
    4、 在“Parameter type”下拉列表中选择参数类型。
    5、点击“OK”,关闭该对话框。脚本生成器便会用参数中的值来取代脚本中被参数化的字符,参数用一对“{}”括住。
        注意:在参数化CORBA或者General-Java 用户脚本的时候,必须参数化整个字符串,而不是其中的部分。另外注意:除了Web或者WAP,缺省的参数括号对于任何脚本都是 “{}”。你可以在“General Options”对话框中的“Parameterization”标签(Tools>General Options)中定义参数括号种类。
    6、用同样的参数替换字符的其余情况,选中参数,点击右键,弹出菜单。从弹出的菜单中,选择“Replace More Occurrences”。搜索和替换对话框弹出。“Find What”中显示了你企图替换的值。“Replace With”中显示了括号中参数的名称。选择适当的检验框来匹配整个字符或者大小写。如果要搜索规则的表达式(.,!,?等等),选中“Regular Expression”检验框,然后点击“Replace”或者“Replace All”。
        注意:小心使用“Replace All”,尤其替换数字字符串的时候。脚本生成器将会替换字符出现的所有情况。
    7、如果想用以前定义过的参数来替换常量字符串的话,选中该字符串,点击右键,然后选择“Use Existing Parameter”,子菜单“Use Existing Parameters”弹出。从子菜单“Use Existing Parameters”选择参数,或者用“Select from Parameter List”来打开参数列表对话框。
        注意:如果用以前定义过的参数来替换常量字符串的话,那么,使用“Parameter List”非常方便。同时,还可以查看和修改该参数的属性。
    8、对于已经用参数替换过的地方,如果想取回原来的值,那么,就在参数上点击右键,然后选择“Restore Original value”。
        在Web用户脚本的树形视图中创建参数:
    1、将光标定位在企图参数化的地方,点击右键,从弹出的菜单中选择“Properties”。则相关的属性对话框打开。
    2、点击在要参数化的参量的旁边的“ABC”形状的图标。“Select or Create Parameter”对话框打开。
    3、在“Parameter name”中输入参数的名称,或者从列表中选择一个已经存在的参数。
    4、在“Parameter type”中输入参数的类型。
    5、点击“OK”关闭该对话框。用户脚本生成器会用参数来替换最初的字符串常量,并用一个表格形状的图标替换“ABC”形状的图标。
    6、要恢复参数化以前的值,点击图标,然后从弹出的菜单中选择“Undo Parameter”,则以前的值便会重现。
     
    三、定义参数的属性
        创建参数完成后,就可以定义其属性了。参数的属性定义就是定义在脚本执行过程中,参数使用的数据源。在Web用户脚本中,你既可以在基于文本的脚本视图中定义参数属性,也可以在基于图标的树形视图中定义参数属性。下面的过程将教你如何在基于本文的脚本视图中定义参数属性。
        在基于文本的脚本视图中定义参数属性步骤:
    1、 在参数上点击右键,有菜单弹出。
    2、 在弹出的菜单中,选择“Parameter Properties”。参数属性对话框打开,显示和当前参数类型相关的属性。
    3、 输入参数的属性值。
    4、 点击“Close”关闭参数属性对话框。
        在Web用户脚本的树形视图中定义参数的属性:
    1、将关标定位在参数上,然后点击右键,选择“Properties”。属性对话框打开。
    2、点击要定义属性的参数旁边的表格形状按钮,点击右键,选择“Parameter Properties”。参数属性对话框打开,和参数类型相关的属性显示出来。
    3、 输入参数的属性。
    4、 点击“Close”关闭参数属性对话框。
        使用参数列表:
      使用参数列表可以在任意时刻查看所有的参数,创建新的参数、删除参数,或者修改已经存在参数的属性。
    1、 点击参数列表按钮或者用“Vuser>Parameter List”。参数列表对话框打开。
    2、要创建新的参数,点击“New”按钮。新的参数则被添加在参数树中,该参数有一个临时的名字,你可以给它重新命名,然后回车。设置参数的类型和属性,点击“OK”,关闭参数列表对话框。
        注意:不要将一个参数命名为“unique”,因为这个名称是用户脚本生成器本身的。用户脚本生成器创建新的参数,但是不会自动用该参数在脚本中替换任意选中的字符串。
    3、要删除已有的参数,那么,要先从参数树中选择该参数,点击“Delete”,然后确认你的行为即可。
    4、要修改已有参数,那么,要先从参数树中选择该参数,然后编辑参数的类型和属性。
    四、理解参数的类型
      在你定义参数属性的时候,要指定参数值的数据源。你可以指定下列数据源类型的任何一种:
    Internal Data―― 虚拟用户内部产生的数据。
    Data Files ――存在于文件中的数据。可能是已存在的文件或者是用脚本生成器新创建的。
    User-Defined Functions―― 调用外部DLL函数生成的数据
      Internal Data包括以下几种:
    1、 Date/Time
      Date/Time用当前的日期/时间替换参数。要指定一个Date/Time格式,你可以从菜单列表中选择格式,或者指定你自己的格式。这个格式应该和你脚本中录制的Date/Time格式保持一致。
    2、 Group Name
      Group Name 用虚拟用户组名称替换参数。在创建scenario的时候,你可以指定虚拟用户组的名称。当从用户脚本生成器运行脚本的时候,虚拟用户组名称总是None。
    3、 Load Generator Name
      Load Generator Name用脚本负载生成器的名称替换参数。负载生成器是虚拟用户在运行的计算机。
    4. Iteration Number
      Iteration Number用当前的迭代数目替换参数。
    5、 Random Number
      Random Number用一个随机数替换参数。通过指定最大值和最小值来设置随机数的范围。
    6、 Unique Number
      Unique Number用一个唯一的数字来替换参数。你可以指定一个起始数字和一个块的大小。
    7、 Vuser ID
      Vuser ID用分配给虚拟用户的ID替换参数,ID是由Loadrunner的控制器在scenario运行时生成的。如果你从脚本生成器运行脚本的话,虚拟用户的ID总是-1。
    五、数据文件
      数据文件包含着脚本执行过程中虚拟用户访问的数据。局部和全局文件中都可以存储数据。可以指定现有的ASCII文件、用脚本生成器创建一个新的文件或者引入一个数据库。在参数有很多已知值的时候数据文件非常有用。数据文件中的数据是以表的形式存储的。一个文件中可以包含很多参数值。每一列包含一个参数的数据。列之间用分隔符隔开,比如说,用逗号。
      对数据文件设置参数属性
      如果使用文件作为参数的数据源,必须指定以下内容:文件的名称和位置、包含数据的列、文件格式,包括列的分隔符、更新方法。
      如果参数的类型是“File”,打开参数属性(Parameter Properties)对话框,设置文件属性如下:
    1、 在“File path”中输入文件的位置,或者点击“Browse”指定一个已有文件的位置。缺省情况下,所有新的数据文件名都是“parameter_name.dat”,注意,已有的数据文件的后缀必须是.dat。
    2、点击“Edit”。记事本打开,里面第一行是参数的名称,第二行是参数的初始值。使用诸如逗号之类的分隔符将列隔开。对于每一新的表行开始一行新的数据。
      注意:在没有启动记事本的情况下如果想添加列,就在参数属性对话框中点击“Add Col”,那么“Add new column”对话框就会弹出。输入新列的名称,点击“OK”。脚本生成器就会添加该列到表中,并显示该列的初始值。
    3、 在“Select Column”部分,指明包含当前参数数据的列。你可以指定列名或者列号。列号是包含你所需要数据的列的索引。列名显示在每列的第一行(row 0)。
    4、 在“Column delimiter”中输入列分隔符,你可以指定逗号、空格符等等。
    5、 在“First data line”中,在脚本执行的时候选择第一行数据使用。列标题是第0行。若从列标题后面的第一行开始的话,那就在“First data line”中输入1。如果没有列标题,就输入0。
    6、 在“Select next row”中输入更新方法,以说明虚拟用户在脚本执行的过程中如何选择表中的数据。方法可以是:连续的、随机的、唯一的、或者与其它参数表的相同行。
      6.1、顺序(Sequential):该方法顺序地给虚拟用户分配参数值。如果正在运行的虚拟用户访问数据表的时候,它会取到下一行中可用的数据。
      6.2、随机(Random):该方法在每次迭代的时候会从数据表中取随机数
      6.3、 使用种子取随机顺序(Use Random Sequence with Seed):如果从Loadrunner的控制器来运行scenario,你可以指定一个种子数值用于随机顺序。每一个种子数值在测试执行的时候代表了一个随机数的顺序。无论你何时使用这个种子数值,在scenario中同样的数据顺序就被分配给虚拟用户。如果在测试执行的时候发现了一个问题并且企图使用同样的随机数序列来重复测试,那么,你就可以启动这个功能(可选项)。
      6.4、唯一(Unique):Unique方法分配一个唯一的有顺序的值给每个虚拟用户的参数。
      6.5 、与以前定义的参数取同一行(Same Line As <parameter>):该方法从和以前定义过的参数中的同样的一行分配数据。你必须指定包含有该数据的列。在下拉列表中会出现定义过的所有参数列表。注意:至少其中的一个参数必须是Sequential、Random或者Unique。
        如果数据表中有三列,三个参数定义在列表中:id1,name1和title1,如下:。
    ID Name Title
    132 Kim Manager
    187 Cassie Engineer
    189 Jane VP
        对于参数id1,你可以指示虚拟用户使用Random方法,而为参数name1和title1就可以指定方法“Same Line as id1”。所以,一旦ID“132”被使用,那么,姓名(Name)“Kim”和职位(Title)“Manager”同时被使用。
    7、Updta value on数据的更新方法
    7.1、Each iteration――每次反复都要取新值
    7.2、Each occurrence――只要发现该参数就重新取值
    7.3、Once――在所有的反复中都使用同一个值
    8、When out of values超出范围:(选择数据为unique时才可用到)
    8.1、Abort Vuser――中止
    8.2、Continue in a cyclic manner――继续循环取值
    8.3、Continue with last value――取最后一个值
    9、Allocate Vuser values in the Controller在控制器中分配值:(选择数据为unique时才可用到)
      9.1、 Automatically allocate block size――自动分配
      9.2、Allocate()values for each Vuser――指定一个值
    六、从已存在的数据库中导入数据
      Loadrunner允许你利用参数化从已经存在的数据库中导入数据。可以使用下列两种方式之一:
    1、 使用Microsoft Query(要求在系统上先安装MS Query)。
    2、 指定数据库连接字符串和SQL语句。
        用户脚本生成器在从数据库中导入数据的过程中提供了一个向导。在向导中,你指明如何导入数据-通过MS Query创建查询语句或者直接书写SQL语句。在导入数据以后,以.dat为后缀并作为正规的参数文件保存。要开始导入数据库中数据的过程,在参数属性对话框中点击“Data Wizard”,则,数据库查询向导弹出。
      要创建新的查询
    1、 选择“Create new query”。如果需要MS Query的帮助,选择“Show me how to use Microsoft Query”,然后点击“Finish”。
    如果你还没有安装Microsoft Query,Loadrunner会提示你这个功能不可用。在进行之前,从Microsoft Office中安装MS Query。
    2、 在Microsoft Query中遵循以下步骤,导入期望的表和列。
    3、 在完成数据的导入后,选择“Exit and return to Virtual User Generator”,然后点击“Finish”。在参数属性对话框中数据库记录以data文件的形式显示出来。
    要在MS Query中编辑并查看数据,选择“View data or edit in Microsoft Query”。若要结束,则选择“File>Exit and return to Virtual User Generator”返回到脚本生成器。
    4、 在“Select Column”部分,指定包含当前参数数据的列可以指定列号或者列名。注意:列标题默认为第0行(row 0)。
    5、 从“Select next row”列表中选择一个更新方法来告诉虚拟用户在脚本指定的过程中如何选择表中的数据。可选项是:Sequential、Random、Unique或者Same Line As。其中每一项的含义文章前面已经讲述,就不再赘述。
    6、 如果选择“Advance row each iteration”,虚拟用户在每次迭代的时候会使用新的一行的数据而不是重复同样的数据。
      要指定数据库连接或者SQL语句
    1、 选择“Specify SQL Statement”,然后点击“Next”。
    2、点击“Create”指定一个新的连接字符串。选择数据源的窗口弹出。
    3、选择已有的数据源,或者点击“New”创建一个新的数据源。向导将提示你穿过创建ODBC数据源的过程。在完成后,连接字符串就会在连接字符串框中显示出来。
    4、 在SQL框中,输入或者粘贴SQL语句。
    5、点击“Finish”继续SQL语句并导入数据。数据库记录将以data文件的形式显示在参数属性框中。
    6、 在“Select Column”部分中,指定包含当前参数数据的列。你可以指定列号或者列名。
    7、 从“Select next row”列表中选择一个更新方法来告诉虚拟用户在脚本指定的过程中如何选择表中的数据。可选项是:Sequential、Random、Unique或者Same Line As。
    8、 如果从Update out of values中,选择“each iteration”,虚拟用户在每次迭代的时候会使用新的一行的数据而不是重复同样的数据。
     
  • 软件测试检查表

    2007-09-04 16:03:23

    1        针对测试组长或测试经理
    1.1   测试管理工作检查表:
    1.      检查每轮测试开始时测试环境是否准备好(包括软件硬件、测试基本数据等);
    2.      确保测试环境(数据和程序)与开发分离,除了测试组之外其他人不能更新测试环境的数据和程序;
    3.      每轮测试根据上一轮的情况和总体测试计划做分工调整;
    4.      检查case库的填报情况,抽查执行过的case;
    5.      检查BUG提交情况,抽查提交的BUG是否规范;
    6.      每天晚上统计BUG情况,填写每天的BUG报告;
    7.      根据每天的测试情况,决定是否开发组要发布新的BUILD;
    8.      每轮测试结束后填写测试总结。
    2        下面是针对测试执行人员的:
    2.1   输入、编辑功能的验证检查点:
    1.       必输项是否有红星标记,如果不输入提示是否跟相应的Label对应,提示的顺序是否跟Form输入域的排列次序一致;
    2.       输入的特殊字符是否能正确处理:`~!@#$%^&*()_+-={}[]|\:;”’<>,./?;
    3.       Form下拉菜单的值是否正确,下拉菜单的值通过维护后是否正确显示并可用;下拉菜单比如是机构编码,要到机构编码的维护界面查询一下是否Form列出的与其一致;
    4.       涉及到下拉菜单的编辑修改Form,要检查在编辑和修改From中,下拉菜单是否能正确显示当前值;
    5.       Form提交后,要逐项检查输入的内容跟通过查询的结果一致;
    6.       有多层下拉菜单选择的情况要校验两层菜单的选择是否正确,比如:
    a)       部门 人员
           部门 财务软件开发部人员 张三
    7.       备注字段的超常检查;
    8.       提交保存后能否转到合适的页面;
    9.       编辑Form显示的数据是否跟该记录的实际数据一致;
    10.    编辑权限的检查,比如:user1的数据user2不能编辑等;
    11.    可编辑数据项的检查,比如:数据在正式提交之前所有的属性都可以编辑,在提交之后,编号、状态等不能编辑,要根据业务来检查是否符合需求;
    12.    对于保存有事务Trasaction提交,比如一次提交对多表插入操作,要检查事务Trasaction的处理,保证数据的完整和一致;
    13.    其他的合法性校验。
    2.2   查询功能检查点:
    1.       查询输入Form是否正常工作,不输入数据是否查询到全部记录;
    2.       当查询的数据非常多的时候,性能有无问题;
    3.       查询的下拉菜单列出的数据是否正确;
    4.       查询结果是否正确;对于复杂的查询要通过SQL来检查结果;
    5.       如输入%*?等统配符是否会导致查询错误;
    6.       查询结果列表分页是否正确,在点击下一页上一页时,查询条件是否能带过去,不能点击翻页时又重新查询;
    7.       对于数据量比较大的表查询时,不容许无条件查询,避免性能问题的出现;
    8.       对于查询输入项的值是固定的要用下拉菜单,比如状态、类型等;
    9.       分页的统计数字是否正确,共X页,第N页,共X条记录等;
    10.    对于查询有统计的栏目,比如:总计、合计等要计算数据是否正确;
    11.    查询结果有超链接的情况要检查超链接是否正确;
    12.    查询权限的检查,比如:user1不能查询到user2的数据等;
    2.3   删除功能检查点:
    1.       必须有“确认删除”的提示;
    2.       根据需求检查是软删除还是硬删除,来检查数据库中是否还存在该条记录;
    3.       是否有相关的数据删除,如果有要确认该相关的数据也已经删除,并且在同一事务中完成;
    4.       是否有删除约束,如果有删除约束,要检查该记录是否被约束,如果被约束该记录不能被删除;
    5.       如果是软删除,用查询、统计界面检查该条记录能否被查询出来,数据是否被统计进去;
    6.       检查因为业务约束不能删除的数据能否被保护不能手工删除,比如:流程中已经审批的文件不能被删除;
    7.       跟删除相关的权限问题,比如:需求要求只有管理员和该记录的创建人能够删除该记录,那就以不同的用户和角色登录进去,执行删除操作,检查是否与需求匹配;
    2.4   上传附件检查点:
    1.       检查是否能正确上传附件文件;
    2.       检查上传的文件是否能正确下载并打开;
    3.       至少检查下列大小的文件能正确上传,100k,1M,2M,4M,10M,20M等;
    4.       如果没有指定类型的限制,至少上传以下几种类型的文件能否正确上传并正确打开,类型有:.doc, .xls, .txt, .ppt, .htm, .gif, .jpg, .bmp, .tif, .avi等;
    5.       如果有文件类型的限制还要检查能上传的文件的类型;
    6.       上传同名的文件,在打开的时候是否出错;
    7.       有中文文件名的文件能否正确上传;
    2.5   影响操作性能的检查点:
    (不能代替系统的性能测试和压力测试,主要看系统在正常操作情况下的响应和处理能力)
    1.       对数据记录条数比较多的表的查询操作,避免全表查询,比如对银行用户账号的查询就不能缺省全部查出,必须让用户输入查询条件;
    2.       菜单树,测试大量数据时菜单树的响应情况;
    3.       有日志的查询或者统计,要注意查询的效率;
    4.       大报表的处理或者批处理的操作,要关注效率,比如:银行对帐、财务年终结算、财务年报表、系统初始化等;
    5.       大报表的排序sort、组函数的使用等;
    6.       大数据量的处理,如导入、导出、系统备份、文件传输等;
  • 因果图基础知识

    2007-08-14 14:17:57

    暂无
  • 测试方法

    2007-08-14 14:16:55

    暂无
  • 软件测试与开发

    2007-08-14 14:16:10

    暂无
  • 软件测试培训

    2007-08-03 17:28:38

    暂无
  • 软件测试培训

    2007-08-03 17:27:15

    暂无
  • 测试与质量的关系

    2007-07-16 16:57:29


          测试有助于提高软件的质量,但是提高软件的质量不能依赖于测试。测试与质量的关系很象在考试中“检查”与“成绩”的关系。
          学习好的学生,在考试时通过认真检查能减少因疏忽而造成的答题错误,从而“提高”了考试成绩(取得他本来就该得的好成绩)。
          而学习差的学生,他原本就不会做题目,无论检查多么细心,也不能提高成绩。
          所以说,软件的高质量是设计出来的,而不是靠测试修补出来的。
  • Perl语言

    2007-07-05 17:13:20

    暂无
  • 软件测试之常用的功能测试方法解析(转载)

    2007-04-04 10:41:14

    功能测试就是对产品的各功能进行验证,根据功能测试用例,逐项测试,检查产品是否达到用户要求的功能。常用的测试方法如下:

      1. 页面链接检查:每一个链接是否都有对应的页面,并且页面之间切换正确。

      2. 相关性检查:删除/增加一项会不会对其他项产生影响,如果产生影响,这些影响是否都正确。

      3. 检查按钮的功能是否正确:如update, cancel, delete, save等功能是否正确。

      4. 字符串长度检查: 输入超出需求所说明的字符串长度的内容, 看系统是否检查字符串长度,会不会出错.

      5. 字符类型检查: 在应该输入指定类型的内容的地方输入其他类型的内容(如在应该输入整型的地方输入其他字符类型),看系统是否检查字符类型,会否报错.

      6. 标点符号检查: 输入内容包括各种标点符号,特别是空格,各种引号,回车键.看系统处理是否正确.

      7. 中文字符处理: 在可以输入中文的系统输入中文,看会否出现乱码或出错.

      8. 检查带出信息的完整性: 在查看信息和update信息时,查看所填写的信息是不是全部带出.,带出信息和添加的是否一致

      9. 信息重复: 在一些需要命名,且名字应该唯一的信息输入重复的名字或ID,看系统有没有处理,会否报错,重名包括是否区分大小写,以及在输入内容的前后输入空格,系统是否作出正确处理.

      10. 检查删除功能:在一些可以一次删除多个信息的地方,不选择任何信息,按”delete”,看系统如何处理,会否出错;然后选择一个和多个信息,进行删除,看是否正确处理.

      11. 检查添加和修改是否一致: 检查添加和修改信息的要求是否一致,例如添加要求必填的项,修改也应该必填;添加规定为整型的项,修改也必须为整型.

      12. 检查修改重名:修改时把不能重名的项改为已存在的内容,看会否处理,报错.同时,也要注意,会不会报和自己重名的错.

      13. 重复提交表单:一条已经成功提交的纪录,back后再提交,看看系统是否做了处理。

      14. 检查多次使用back键的情况: 在有back的地方,back,回到原来页面,再back,重复多次,看会否出错.

      15. search检查: 在有search功能的地方输入系统存在和不存在的内容,看search结果是否正确.如果可以输入多个search条件,可以同时添加合理和不合理的条件,看系统处理是否正确.

      16. 输入信息位置: 注意在光标停留的地方输入信息时,光标和所输入的信息会否跳到别的地方.

      17. 上传下载文件检查:上传下载文件的功能是否实现,上传文件是否能打开。对上传文件的格式有何规定,系统是否有解释信息,并检查系统是否能够做到。

      18. 必填项检查:应该填写的项没有填写时系统是否都做了处理,对必填项是否有提示信息,如在必填项前加*

      19. 快捷键检查:是否支持常用快捷键,如Ctrl+C Ctrl+V Backspace等,对一些不允许输入信息的字段,如选人,选日期对快捷方式是否也做了限制。

      20. 回车键检查: 在输入结束后直接按回车键,看系统处理如何,会否报错。

  • 测试工作指导书

    2007-02-12 15:38:58

    暂无
Open Toolbar