路漫漫其修远兮,吾将上下而求索

发布新日志

  • (转) QTP录制脚本小技巧

    2014-02-07 09:56:46

  • (转)手机测试种类

    2008-03-28 19:05:22

    最近一直在做智能手机小应用的跟踪验证测试,故障单是由测试高手提供的,是一个非常完善的测试队,连我们的开发团队都感叹他们的敏锐,能发现潜在的Bug。
       在验证之余,我认真研究了他们出的故障单,做了一些总结。
       1、手机软件系统测试的角度分为:功能模块测试,交叉事件测试,压力测试,容量
    性能测试,性能测试和用户手册测试等。
       2、功能模块测试:首先应分析功能模块的功能项,测试每个功能项是否能够实现对应的功能。一般根据测试案例(Test Case)或软件本身的流程就可以完成基本
    功能测试。(相对简单,故障也较容易解决)
       3、交叉事件测试:又叫事件或冲突测试,是指一个功能正在执行过程中,同时另外一个事件或操作对该过程进行干扰的测试。例如通话过程中接收到短信或来响闹。应该以执行干扰的冲突事件不会导致手机死机或花屏等严重的问题。
       交叉事件测试非常重要,能发现很多应用中潜在的性能问题。另外有中英文模式的切换的手机要注意中英文模式切换后的功能实现存在的问题,通常会被测试人没忽略。
       4、压力测试:又叫边界值容错测试或极限负载测试,即测试过程中,已经达到某一软件功能的最大容量,边界值或最大的承载极限,仍然对其进行相关操作。例如连续进行短信的接收和发送,超过收件箱和PIM卡所能存储的最大的条数,仍然进行短消息的接收或发送,以检测软件在超常态条件下的表现,来评估用户能否接受。
       压力测试用手工测试非常繁锁,可以考虑
    自动化测试,目前没有比较大量使用的工具,一般都是由开发人员配合开发出的工具,或者高级的测试人员编写出的脚本。
       5、容量测试:又叫满记忆体测试,包括手机的用户可用内存和SIM/PIM卡的所有空间被完全使用的测试。此时再对可编辑的模块进行和存储空间有关的任何操作测试,如果软件的极限容量状态下处理不好,有可能导致死机或严重的花屏等问题的出现。
       与压力测试有些类似,也可考虑自动化测试。
       6、兼容性测试:也就是不同品牌手机,不同网络,不同品牌和不同容量大小的SIM/PIM卡之间的互相兼容的测试,以短消息为例:中国电信的小灵通接收到从中国移动或中国联通GSM发来的短消息,接收,显示和回复功能是否正常等
       另外从我测试的这几个小模块中,按与时间相关和文字两方面容易出现故障的地方总结如下:
       1、与时间相关:首先是时间的输入域,是否有输入限制,如:文字、标点符号、小时大于24或12、分钟大于60、秒大于60、月大于12、日大于31(按月情况而定)等
       特别注意日期变更分界点如23:59或12:59的变化。以及12/24小时切换模式的测试。
       2、文字输入相关:当界面过多时,注意功能按钮的点击事件能否正常完成相应功能的实现。超过文字字数限制时的系统提示等。
        先暂总结到此,有什么补充的地方,请同行指出。

  • SilkTest产品介绍

    2008-03-09 21:50:11

     

  • 转 Mercury QuickTest Professional 9

    2008-03-09 21:31:21

    Mercury QuickTest Professional是一款先进的自动化测试解决方案,用于创建功能和回归测试。它自动捕获、验证和重放用户的交互行为。
    Mercury QuickTest Professional
    为每一个重要软件应用和环境提供功能和回归测试自动化的行业最佳解决方案。


    使用QuickTest Professional关键词视图、自动文档(Auto-documentation)和活动屏幕(Active Screen),无需一行代码,就可以创建和修改测试脚本。

    QuickTest Professional
    是新一代自动化测试解决方案,采用了关键词驱动(Keyword-Driven)测试的理念,能完全简化测试的创建和维护工作。QuickTest关键词驱动方式独有之处在于,测试自动化专家可以通过一个整合的脚本和纠错环境,拥有对基础测试脚本和对象属性的完全访问权限,这些脚本和纠错环境与关键词视图(Keyword View)可以互为同步。

    QuickTest Professional
    同时满足了技术型和非技术型用户的需求,让各个公司有能力部署更高质量的应用,同时部署的速度更快,费用更低,风险也更小。

    QuickTest Professional
    和我们新的测试自动化系统Mercury Business Process Testing的紧密结合,可以将非技术型的业务专家(SME, Subject-Matter Experts)引入质量流程,这一意义重大的引入可以将IT和业务更好地融合,最终建立起更出色的应用。

    有了该产品,QA机构可以获取多方面的优势
    :
    用最少的培训赋予整个小组创建成熟测试方案的能力;确保跨所有环境、数据包和业务流程的正确功能点;为开发人员全面记录和复制缺陷,使他们能更快地修复缺陷,满足最后上线期限;对不断变化的应用和环境展开便捷的回归测试;成为帮助整个机构实现高质量产品和服务、提高总收入和收益率的关键角色。

    易操作

    QuickTest Professional
    易于操作,即使是初级的测试人员也能在短时间内对其驾轻就熟。您可以使用无需脚本的关键词视图来表现测试的每个步骤,仅由此就可创建一个测试。您还可以通过QuickTest Professional所集成的录制能力来捕获测试步骤。该产品用简单的英语以文档形式记录每个步骤,并通过活动屏幕将文档与一个集成截屏相结合。

    传统的脚本记录工具所生产的脚本不易修改.与此不同的是,QuickTest Professional的关键词驱动方式能让您便捷地插入、修改、数据驱动(data-drive)和移除测试步骤。

    功能测试

    那些在Mercury WinRunner测试工具上投入大量资金,并想转入Mercury QuickTest Professional的用户,可以使用Mercury Functional Testing来实现这种转变。Mercury Functional TestingQuickTest ProfessionalWinRunner结合成一种集成产品,它不仅可以使用WinRunner脚本,也可以使用QuickTest Professional脚本,使测试资源得到极大地利用。质量工程师可以使用Mercury Functional Testing来创建复合脚本测试。Mercury Functional TestingWinRunnerQuickTest Professional的集成,产品间可以相互调用脚本。

    质量中心的组成部分

    Mercury QuickTest Professional
    Mercury质量中心(Mercury Quality Center)的组成部分之一,Mercury质量中心集成了一整套软件、服务和最佳实践,用于自动化关键质量活动,包括需求管理、测试管理、缺陷管理、功能测试和业务流程测试。

    特点和优势

    ·
    具有行业领先的便于使用的特性,以及支持提前配置环境的功能,确保了快速的投资回报。

    ·
    可独立运行,也可以同Mercury Business Process TestingMercury质量中心集成。

    ·
    引进了QuickTest Professional 8.0中新一代的零配置关键词驱动测试技术,从而实现了快速建立测试、测试脚本更易维护,和更强大的数据驱动能力。

    ·
    通过集成的数据表,可数据驱动任意对象、方式、检查点和输出值等。............

  • 网站压力测试工具was(转贴)

    2008-03-03 15:54:07

    Microsoft Web Application Stress Tool 是由微软的网站测试人员所开发,专门用来进行实际网站压力测试的一套工具。透过这套功能强大的压力测试工具,您可以使用少量的Client端计算机仿真大量用户上线对网站服务所可能造成的影响,在网站实际上线之前先对您所设计的网站进行如同真实环境下的测试,以找出系统潜在的问题,对系统进行进一步的调整、设置工作。
    Microsoft Web Application Stress具有以下几个特性:
      * 可以数种不同的方式建立测试指令:包含以手动、录制浏览器操作步骤、或直接录入IIS的记录文件、录入网站的内容及录入其它测试程序的指令等方式。
      * 支持多种客户端接口:标准的网站应用程序C++的客户端,使用Active Server Page 客户端,或是使用Web Application Stress对象模型建立您自定的接口。.
      * 支持多用户利用多种不同的认证方式仿真实际的情况,包含了DPA, NTLM 及 SSL等。
      * 支持使用动态的cookie仿真定制网站实际运作场景及对话(session)的支持。
      * 在客户端的计算机以NT 服务的方式执行仿真的工作,可在不中断测试的情况下将某些客户端的测试计算机删除。
      * 透过集中式的Microsoft Web Application Stress 管理员,您可以使用任意数目的客户端计算机同时进行测式的工作。
      * 具有Bandwidth throttling (带宽遏流)的功能以仿真用户使用调制解调器上线的效果。
      * 内建的query-string 编辑器可帮助您建立name-value pair组合的模板,并可在不同的场景测试中重复使用。
      * 可程序化的对象模式让您可以建立您自己的测试客户端。
      * 汇总的测试报告及丰富的性能测试资料。
      * 支持域名系统(DNS)让您可以测试整个群集(Cluster)的机器。
      * 使用Page group的方式来控制文件的组及测试指令的执行程序。
      * 可自定的header让您可以仿真各种不同种类的浏览器。
      * 可自定的指令延迟让您以更接近真实环境的方式进行测试。
    网站测试概述
    为了正确使用WAS进行网站的压力测试,您需要对于网站测试的方法有一初步的了解。以下的讨论将包含一些基本的概念以供参考。
    网站的测试可大略分成三个主要的类别:
      * 网站性能测试 (Performance testing)
      * 压力测试下的网站稳定性 (Stability or stress testing)
      * 网站承受能力评估 (Capacity planning)
    网站性能测试的第一件工作就是使用测试工具对网站加压以测量网站服务器每秒可以承受的请求(Request Per Second) 的最大值。第二件工作就是找出系统性能限制的原因所在,举例来说,CPU、内存、或是后端系统所造成的反应延迟等。
    在许多状况下,网站服务器的CPU是主要的性能瓶颈。测试时您可以持续加压直到性能表现开始下降,再慢慢的降低压力的程度。此时您所测试出来的最大性能即为该网站所能达到的最高值。在实际测试时,您可以通过增加压力线程(thread),或是增加执行WAS测试程序的客户端来加压。
    在网站服务器端,您可以使用性能监视工具如Performance Monitor来监视如 "System: % Total Processor Time" 及 "Web Service: Connection Attempts/sec" 或 "Active Server Pages: Requests Queued"等指针。如果CPU的资源指针已达到80%到85%,则CPU的处理能力最有可能就是整个系统的瓶颈所在。若是在压力测试的过程中CPU所被使用的比例不高而”Requests Queued”的指针一直居高不下,可能是程序正在调用服务器上的COM组件而这个组件无法有效的执行完所有的命令,因而造成了系统性能的降低。在这种情形下,服务器上的COM组件才是真正的瓶颈。
    目前市场上最热门的定制网站应用程序也会对网站的性能表现有重大的影响。WAS包含了数种特性可有效的帮助您测试定制的网站应用程序。例如,您可以建立用户,让WAS可以设置并储存每一个用户的cookie。您也可以使用QueryString 编辑器帮助您建立并储存数个不同的name-value pair以便在每一次执行request时进行测试。
    一般的网站测试问题
      * 错误的测试平台,和实际上线的 production server(生产环境服务器)不同,无法测出实际的问题。
      * 错误的测试指令,无法正确的仿真出实际上线系统真正的反应。
      * 线程安全性问题以及不稳定的服务器COM组件。
      * Active Server Page 的错误及GLOBAL.ASA 设置的问题。
     

    使用说明


    一、建立新脚本
        方法一、启动WAS软件后会自动显示建立新脚本的提示页面,选择[manual]按钮就可完成建立新脚本的功能。
        方法二、启动WAS软件后点击[new scrīpt]按钮。

    二、编辑脚本内容
        1、在选择脚本名称的右侧会出现相应的设置
            [server]中输入要进行测试的服务器IP地址或计算机名称;
            [verb]中选择脚本运行方式 get、post、head;
            [path]中输入向服务器提交的文件或字符串。
        2、[content tree]该项在默认情况下不做更改。
        3、[settings]设置测试持续时间
            在“test run time”各项中输入相应数字即可。
        4、[perf counters]该项在默认情况下不做更改。
        5、[page groups]该项在默认情况下不做更改。
        6、[users]选项下双击[default]或单击[show users]快捷键进入用户设置页面。
            在[user name]和[password]中输入服务器认可的用户和密码,点击[create]按钮完成        添加用户功能。
            删除用户时只需要点中用户左侧按钮选中该行后点击[删除]快捷键。
            [number of new]项不能设为“0”,否则添加无效。
        7、[clients]双击[default]进入设置页面
            在[machine]输入添加客户的计算机名后点击[add]按钮,在默认状态下只有        “localhost”客户连接,添加的其他客户均离线。选中的客户会在报告中显示。
        8、[cookies]自动显示用户的状态。

    三、web测试
        1、选择运行脚本名称
        2、在[scrīpt]菜单中选择[run]或者点击[运行脚本]快捷键

    四、测试报告
        1、点击[report]快捷键出现报告目录
        2、选择脚本名称以及详细测试时间文件
        说明:TTFB 表示从请求开始到WAS收到的时间
               TTLB 表示最后一个请求从WAS反馈到客户端的时间

    五、删除脚本
        选择要删除的脚本名称后点击[删除]快捷键

    六、菜单说明
        1、[file]下的[new]初始化WAS软件,并非新建立;
        2、[file]下的[open]打开以前保存的文件。
  • [转]GUI的自动化测试的三种类型

    2008-03-03 14:42:21

    原文索引:http://bbs.51testing.com/thread-562-1-1.html


    GUI的自动化测试可以由简入难分成三种类型:
    1)纪录回放类:
    这一类不需要太多的计划,编程和调试。优点在于简单,方便。缺点在于稳定性差,所以脚本运行寿命短,而且与不同配置的兼容性差。同时由于缺少结果的验证部分,基本上找不到什么Bug。可考虑在产品开发接近尾声时,用于尚未自动化的已知Bug的回归检验。

    2)测试用例自动化类:
    这一类是指将需要反复测试或在多种配置下重复测试的用例自动化。基本实现过程通常为:
    - 设计测试计划
    - 设计测试用例
    - 针对每一个用例评估自动化的可行性和经济性
    - 将决定要自动化的用例作详细步骤分解。
    - 编写公用步骤,公用资源库(Logging 和 exception handling 部分是必不可少的)
    - 编写自动化程序 (别忘了结果的验证部分)
    - 调试
    - 实际运行

    这一类自动化测试最为灵活,也能发现较多的Bug。又能较好的与测试计划相协调。当前多数测试做的比较好的企业都主要使用这种类型的自动化。

    3)自动测试类:
    这一类是指自动生成测试用例并自动运行。这类自动化测试的最大的优点在于它的无限可能性。另外它通常能发现手工测试极难发现的错误。而且一旦实现了这种自动化,其维护费用实际上是大大低于前两类测试的。不过这类测试自动化的初始投入非常高,而且它的效果受其智能化程度的制约也非常大。除非是专业测试公司或是象微软、IBM这类超大型企业,多半都没有实力来研究这类测试自动化。
    不过从长远来说,只要有较好的工具能将这类自动化的初始投入降下来,这类测试自动化才是软件测试发展的必然方向。
    这一类测试的基本实现过程通常是:
    - 购买或开发基本测试自动化框架
    - 编写必要的接口,钩子,及其他公用资源。
    - 建立软件、组件、或功能的行为模型
    - 设立测试目标等参数
    - 自动生成测试用例及测试计划
    - 筛选并运行测试用例
    - 评估结果
  • 以RUP原则实施软件自动化测试 第一部分

    2008-03-02 21:46:24

     

     
    将此页作为电子邮件发送

     


    级别: 初级

    张振兴 (sinckyzhang@hotmail.com), 测试工程师

    2005 年 6 月 01 日

    本文将根据IBM Rational的RUP原则来讲解实施软件测试自动化的过程,以此必将避免以上失败,使自动化测试真正在软件开发活动中发挥其强大优势。全文第一部分重点阐述:自动化测试的优势、自动化测试的四个关键过程、优秀开发过程具备的要素、企业为软件测试自动化提供的组织支持。

    内容概要

    很多人理解软件测试自动化,就是找到一款自动化工具,然后在软件项目里开始使用。但是大抵最后都会失败,甚至还会浪费很多不必要的资源和时间。一般来说,自动化测试项目失败的原因有两个方面:

    • 不合理的期望
    • 不合适的实现

    本文将根据IBM Rational的RUP原则来讲解实施软件测试自动化的过程,以此必将避免以上失败,使自动化测试真正在软件开发活动中发挥其强大优势。全文第一部分重点阐述如下主题:

    • 自动化测试的优势
    • 自动化测试的四个关键过程
    • 优秀开发过程具备的要素
    • 企业为软件测试自动化提供的组织支持

    第二部分将讲解以下主题:

    • 成功自动化测试的计划过程
    • 自动化测试的最优化设计




    回页首


    前言

    众所周知,软件测试是目前软件工程领域唯一的朝阳行业;所谓朝阳行业,就意味着挑战与机遇并存!有人说软件测试既是科学又是艺术,但凡称为既是科学又是艺术的学科就是不成熟的学科,软件测试也如此,它也是不成熟的领域,在其发展道路上还存在着太多的不足和难以克服的困难;因此,很多国内外的专家和公司都在积极的探求着更规范化和标准化的测试流程,以及更成熟、更易实现的技术方法。

    从宏观意义讲,软件测试可以划分为以下三个方面:

    • 软件测试管理:测试流程管理、测试职业管理,测试技能方法管理等
    • 软件测试技术方法:根据软件测试的不同阶段、不同测试类型、不同软件类型等,深入研究软件测试的技术及方法
    • 软件测试自动化:自动化测试流程、自动化测试管理、自动化测试工具等

    软件测试大致分为以上三类,每类可细化为更多子方面,例如第二类根据测试类型还可细化为功能测试、性能测试、安全测试等,根据测试方法可细化为黑盒测试、白盒测试、灰盒测试等。这里,之所以讲软件测试自动化单独列出来,是考虑到软件测试自动化既包括技术方法方面,又包含管理方面;更重要的是,软件测试自动化是软件测试领域无法逾越的发展阶段,随着应用软件程序规模的不断扩大,业务逻辑的不断复杂,以及从业者协作关系的日益重要,在软件的开发周期里适当使用自动化测试是非常必要的!





    回页首


    自动化测试介绍

    一)自动化测试的神话和现实

    自动化测试能增强软件测试的规范化和标准化,如果实施方法得当,它可以:

    • 减少浪费在重复性手工测试工作上的时间
    • 创建优良可靠的测试过程,减少人为错误
    • 增强测试的覆盖率以及产品质量

    但是,测试自动化不能:

    • 完全代替手工测试
    • 立即降低测试投入,提高测试效率
    • 保证100%的测试覆盖率
    • 补偿劣质的测试过程

    要对自动化测试形成正确的认识,切不可好高骛远,脱离实际的以为企业实施了测试自动化,就可以克服从前的一切问题。实际上,软件测试自动化在企业内部的推广,也是一个与时俱进的持续性过程。

    二)自动化测试工具

    自动化测试定义为通过测试自动化工具开发和执行测试脚本,以评估软件的需求。测试工具分为两类:

    • 找错工具(fault-finding):根据既定的测试标准寻找被测程序中的缺陷,包括静态分析工具(一些白盒测试工具例如parasoft的jtest含有该功能)、动态测试工具(市面众多的测试工具robot、winrunner、qarun等)
    • 测试支持工具:测试管理工具(如testmanager、testdirecter等)、其他支持工具(如clearquest、clearcase等)

    三)自动化测试成功的关键要素

    企业购买了自动化测试工具,下一步就是要在公司内部推广自动化测试。那么,自动化工具能够给企业的测试流程带来多少变更呢?如何在测试工作中使用自动化测试工具呢?RUP提出这样的自动化测试关键要素:

    • 自动化测试必须看成一个软件开发项目,因为测试脚本是代码,而测试代码是自动化测试的根本;有效的开发并维护良好的测试脚本,是自动化测试的重中之重。
    • 自动化测试同样需要经历计划、设计、开发、维护、版本控制过程,具体而言,包括四个关键过程:
      • 清晰的定义和可持续的实现过程
      • 获得企业组织管理上的支持
      • 审思成熟的项目计划
      • 稳定的结构设计

    以下逐一讲解每个关键过程。





    回页首


    定义测试过程

    一)定义测试过程的重要性

    所谓过程,是为了构建某目标而设计的一系列分步执行的动作;软件工程里,目标是构建软件系统或增强现有软件系统;软件测试里,目标是高效的测试软件程序,发现软件缺陷并确认软件需求。

    一个定义良好并严格根据其实施的测试过程,是自动化测试成功的关键。所谓凡事预则立,不预则废,在一个随机或非系统性的测试环境里,很难实施测试自动化;缺乏稳定的测试过程,拿起工具就开始录制脚本等,这样的方式是愚蠢的,所做的投入也必将导致失败。

    二)RUP简介

    RUP(Rational Unified Process)是IBM Rational software提出的软件工程实施过程,在业界经历了数千个软件项目的实践,是当前最为成功的软件工程方法论之一!RUP是一种迭代的、以架构为中心的、用例驱动的软件开发方法;RUP是一种具有明确定义和结构的软件工程过程,它明确规定了人员的职责、如何完成各项工作以及何时完成各项工作,以及软件开发生命周期的结构,定义了主要里程碑和决策的关系;RUP也是一个过程产品,提供了可定制的软件工程的过程框架,支持过程定制、过程创作和多种类型的开发过程,可通过装配过程产品得到过程配置。RUP配置可以用于不同规模的开发团队和规范程度不同的开发方法,RUP产品包含过程配置和过程视图,以指导项目经理、开发人员、测试人员等角协作开发软件。

    RUP的核心包含几个基本原理,它们支持应用迭代方法进行软件开发:

    • 尽早并且不断的化解重大风险
    • 确保满足客户的需求
    • 把注意力集中放到可执行的软件上
    • 尽早在项目中适应变化
    • 在早期确定一个可执行架构
    • 使用构件构造软件系统
    • 建立高效团结的开发团队
    • 始终重视质量

    从管理角度观察RUP,即业务和经济方面,对应项目的进展,软件生命周期包括四个阶段:

    • 起始阶段-构建最终产品的设想和业务案例,确定项目范围
    • 细化阶段-计划必要的活动和资源,详细确定功能并设计架构
    • 构建阶段-构建产品,直到一个可交付用户的产品完成
    • 移交阶段-产品交付用户,包括制造、交付、培训、支持、维护等


    从技术角度看,软件开发可视为一连串的迭代过程,通过迭代开发软件得以增量演进,每个迭代都以一个可执行的产品发布而结束,每次发布都伴随支持性工件:版本描述、用户文档等。一次迭代可包括以下活动:计划、分析、设计、实现、测试,据其在开发周期的位置不同,所占比重也不同。



    三)优秀测试过程的要素

    RUP提出的开发过程可以有效应用到测试和自动化测试中,因此,根据RUP原则,我们得出优秀测试过程所应具备的几大要素,列举出来供大家参考:

    • 初始计划-定义测试目标
    • 定义需求-确定测试什么,可落实到《测试需求说明书》
    • 分析设计-决定如何测试,划分测试阶段、类型,以及测试方法等
    • 实现-创建与实现测试,编写测试用例或开发测试脚本,并文档化
    • 测试-调试测试(针对自动化测试脚本)
    • 执行-执行测试
    • 评估-评估测试结果并改进测试过程
    • 配置与变更管理-测试脚本的版本控制和测试缺陷的跟踪
    • 环境-定义支持测试所需的环境

    企业在实施自动化测试前,可根据上述内容定义软件项目的自动化测试过程,做到每条项目都有所规范,任何测试成员都据此实行。至于内容详细程度和文档格式,不必统一,重要的是内容规定了这些原则,并且在实际工作中有所贯彻。





    回页首


    对自动化测试的组织层支持

    一) 获得组织层支持的必要性

    企业实施自动化测试,不是单纯测试部门的事情,更不是几个测试工程师单靠对测试工具的强烈兴趣,就能够在企业内部推广使用的。有数据表明,很多自动化测试项目的失败,并非技术的限制,更多的是缺乏企业组织管理层的支持,组织管理层的支持与否可以瞬间中断一个项目,而且没有领导层的支持,购买工具、测试环境与资源的花销,根本无从实现;而且推广自动化测试,势必影响企业内部软件的开发流程,试想没有高层的审批,实施工作根本无从下手。因此,为最大程度的保证自动化测试的实施,花费一定的时间获得上层组织的支持和必要的项目资源是非常必要的!

    二) 正确看待自动化测试项目

    绝对不要把自动化测试简单的看作是运用一套自动化测试工具的过程,实施软件测试自动化决不单单如此。我们应该把实施自动化测试的软件看成一个项目,并且把自动化测试项目看成一个企业中新的里程!一个新里程有两个要素:

    • 开创里程-确定自动化测试的涉众
    • 维持里程-改进组织管理过程以适应自动化测试

    三)自动化测试的涉众

    涉众,是RUP中的名词,表示软件开发中涉及到的各种角色,如用户、设计人员、开发人员乃至测试人员等。实施软件测试自动化,必须获得涉众的支持,这也是自动化测试涉众的根本任务。那么,需要获得那些涉众的支持呢?

    1) 企业高层领导--从企业的高层领导获得

    • 自动化测试的可信度
    • 对测试工具、培训方面的财务支持
    • 企业其他部门人员的支持,如审批、招聘等

    在和企业高层领导交涉时,应该如实放映自动化测试,说明自动化测试并非一定获得投资回报,也并非能立即获得回报,并从企业角度设定切实可行的期望目标,例如只是在某类软件项目的某种测试类型或阶段实施自动化测试。

    2) 测试主管--测试主管或经理直接监督企业整个测试过程的实行,并确定测试日程、战略、资源分配及工作细节,故而有必要获得测试主管对自动化测试的支持。

    在和测试主管或经理交涉时,要让他们清楚自动化测试的功效,说明如何使测试工作更加有效,还要让他们通晓如何计划、实施自动化测试项目等。

    3) 测试人员--和测试人员沟通,因为一旦实施了自动化测试,必将改变测试人员的原有工作方式,需要他们学习新的技能,与开发人员之间也要保持更紧密的合作,另外,也需要他们严格遵守新的测试流程和规范。我们需要测试人员理解自动化如何提高工作效率,并清楚遵守测试流程的必要性,还要明确认识自动化测试和手工测试的平等关系,并非所有人都要成为自动化测试专家,自动化测试也无法完全取代手工测试,以免造成不必要的心理失衡。

    4) 开发人员--获得开发人员对自动化测试的支持是非常关键的,我们需要鼓励开发人员开发优质的代码,增强软件的可测性,并通过有效沟通提高测试的覆盖率。另外,RUP提倡开发人员执行每个发布版本的冒烟测试。

    四)自动化测试规范的制订

    为什么需要制订企业级的自动化测试规范呢?

    自动化测试规范是企业高层对该方案的授权见证,同时加强与企业其他部分的交流与合作;没有该规范,遇到问题时会手无足措,例如对于自动化测试的负责人,将会缺少执行的可信度,对于自动化测试实行人,将会遭受各种阻力。另外,企业没有清晰明确的测试目标和方案,各部门制订各自的规范必将在实行时发生冲突,从而导致项目的最终失败。

    企业级自动化测试规范是对企业的测试流程及规范进行高标准的定义和描述,它定义了组织的测试目标、实施方式及遵循的标准,并包含了自动化测试在整个测试过程里的具体实施步骤。

    那么,谁来制订自动化测试规范呢?RUP并没有规定非要由何人来制订,实际上,可以是任何有自动化测试技能或经验的人,例如自动化测试的倡导者、测试主管等。制订完成后,需要得到企业高层如CTO/VP的审批。

    以下是某公司的自动化测试规范样例:

    XYZ公司自动化测试规范
    介绍:
    该规范定义了XYZ公司的自动化测试过程,适用于公司所有的软件测试活动,对我公司的软件测试活动的方法和步骤以及测试资源进行文档化。任何测试活动都要遵循该规范规定的标准和结构,但是对于特定项目的测试活动,可制订项目级的测试策略文档。
    目标:
    XYY公司的软件测试目标是通过定制标准衡量软件系统的功能及其他非功能指标,以适应公司的商务运作,并以此衡量过程作为评测软件发布的通道;个别测试项目还需参考项目的相关测试策略及计划文档。
    方式:
    我公司测试标准以rational unified process(RUP)为参考,并符合RUP规范。
    组织:
    我公司采用手工测试和rational自动测试工具结合的方式实施软件测试
    XYZ公司采用有资格认证的人员确定测试方案,并通过技能培训保证相关人员在各自测试区域得到最大发挥。
    步骤:
    … …

    五)自动化测试的成员构成

    首先说一下自动化测试成员的技能需求。一般来说,自动化测试项目成员的全部技能大致包括:

    测试技能:理解GUI测试设计和标准、理解被测软件的商务逻辑、理解软件测试等测试管理技能:包含测试数据管理、测试设计和开发、测试战略定义、自动化测试项目管理等自动化测试技能:包含自动化测试工具使用、编程、测试套件的设计等技术技能:包含操作系统、数据管理、网络与硬件等软件开发技能:包含编程、软件系统设计、软件开发支持工具(配置与变更管理等)因此,构成软件自动化测试的项目成员包括(实际中可做相应调整或合并):

    • 测试战略定义者
    • 项目管理者
    • 测试数据管理者
    • 测试设计和开发者
    • 测试执行者
    • 测试支持者(配置管理与变更管理等)
  • 自动化测试的术语定义与工具

    2008-03-02 21:38:30

             Architecture(体系结构)一个系统在其环境中的最高级别的概念(IEEE)。软件系统(在某一给定时刻)的体系结构是通过接口互相联系的主要组件的组织方式或结构,这些组件相应的是由更小的组件和接口构成的。

    ü         Artifact(产物)某过程所创建的任何产品、交付物或文档。

    ü         Build(构建版本)一个构建版本由一个或多个组件(通常是可执行的)组成,每一个组件通常又由其他组件通过编译和连接源代码而构成。

    ü         Component(组件)系统中的一个实际的可替换的部分,它包括功能的实现、提供并配合接口的实现。

    ü         DataDriven Testing(数据驱动测试)这是一种测试脚本的功能及执行由外部数据所引导的自动测试方法。这种方法将测试及控制数据与测试脚本本身分离开了。

    ü         Functional Decomposition Approach(功能分解方法)这是一种将测试用例缩减为基本任务、导航、功能测试、数据验证和返回导航的自动化测试方法,也称作框架驱动方法(FrameworkDriven Approach)。

    ü         Key WordDriven Testing(关键字驱动测试)这种方法是由SAS研究所的Carl Nagle开发的,并作为自由软件发布在互联网上。关键字驱动测试是数据驱动方法学的提高。

    ü         Performance Testing(性能测试)通过这类测试的实现和执行可以对索要测试的应用程序与性能相关的特征作出描绘和评估。这些测试包括时间调度情况、执行流畅、响应时间以及操作可靠性和限制。

    ü         Procedure(程序)当执行一个任务时所要遵循的行动过程的文档化描述,通过遵循这种一步接一步的方法可以保证达到各项标准。

    ü         Process(过程)可活动产品或服务的一系列步骤;可生成出产品或服务的劳动。

    ü         Process Control(过程控制)保持产品或服务符合规格说明的自我调节操作。

    ü         Product(产品)某个过程所创建的任何产物、交付物以及文档。

    ü         Rational ClearCase  Rational公司提供的配置管理软件

    ü         Rational ClearQuest 这是Rational公司提供的跟踪缺陷及需要更改管理系统。

    ü         Rational Robot RobotRational Suite TestStudio 2001软件的捕获/回放组件。

    ü         Rational TestManager  TestManagere Rational公司提供的管理所有测试活动-计划、设计、实现、执行和分析-的中心控制台。

    ü         Rational Unified Process 这是Rational公司提供的软件工程过程,此过程为在一个开发组织中分配任务和责任提供了严谨的方法。

    ü         Specifications(规格说明)为客户提供的产品和服务时期望能达到的标准。

    ü         Test Artifact Set(测试产物集)搜集和形成与所进行测试相关的信息。

    ü         Test Case(测试用例)时一套为特定目标开发的测试输入、执行条件和预期结果,例如执行一跳特殊程序路径或者在特定要去下验证一致性。

    ü         Test Condition(测试条件)测试所涉及的各种环境因素。

    ü         Test Data(测试数据)在测试中所用到的实际数值或执行测试所必须的数值。测试数据是测试条件(作为输入或预存在的数据)的具体例化,用于验证已成功实现的特定要求(通过将实际结构与期望结果比较)。

    ü         Test Inputs(测试输入)是工作过程的产物,用于标志和定义发生在测试期间的动作。这些产物可能是从测试组之外的软件开发过程中产生的,例如功能需求规格说明和设计规格说明。它们也可能是从前期测试阶段产生的并被留给了后续的测试活动。

    ü         Test Plan(测试计划)包括项目中的测试目标和目的的信息。此外,测试计划还明确了测试实现的策略和所需要的资源。

    ü         Test Procedure(测试程序)是一套详细的指示,用于某特定测试用例(或一套测试用例)的建立、执行和结构评估。

    ü         Test Requirement(测试需求)是关于某具体测试目标的声明以及确认测试是否通过所要达到的标准。

    ü         Test Results(测试结果)执行测试所捕获的数据,并被用于计算测试的不同关键测度。

    ü         Test scrīpt(测试脚本)这是计算机可读懂的能令测试程序(或一部分测试程序)自动执行的指令。测试脚本可以由人创建(复制)或者由自动测试工具产生,它使用编程语言限制,或者由记录、生成和编程混合创建。

    ü         Test Strategy(测试策略)描述了测试获得的通用目标合方法。

    ü         Test Suite(测试套件)是指在执行时将某一测试场景具体化的一套测试。

    ü         Test Workspace(测试工作区)这是测试者的“私有”区域,在这里测试者能够根据项目采用的标准对代码进行安装和测试,从而与开发人员保持了相对的隔离。

    Resource:《Just Enough Software Test AutomationDaniel JMosley

    《软件测试自动化》邓波等译 机械工业出版社

    posted on 2007-11-23 14:35 Cinderella 阅读(58) 评论(1)  编辑  收藏 所属分类: 基本技能功能测试他山之玉
  • 软件自动化测试工具的评测方法

    2008-03-02 20:32:52

           软件测试的主要评测方法包括测试覆盖和质量评测。测试覆盖是对测试完全程度的评测,它是由测试需求和测试用例的覆盖或已执行代码的覆盖表示的。质量评测是对测试对象(系统或测试的应用程序)的可靠性、稳定性以及性能的评测,它建立在对测试结果的评估和对测试过程中确定的变更请求(缺陷)分析的基础上。
    1 覆盖评测
           覆盖指标提供了“测试的完全程度如何?”这一问题的答案。最常用的覆盖评测是基于需求的测试覆盖和基于代码的测试覆盖。简而言之,测试覆盖是就需求(基于需求的)或代码的设计/实施标准(基于代码的)而言的完全程度的任意评测,如用例的核实(基于需求的)或所有代码行的执行(基于代码的)。
          ◆基于需求的测试覆盖
           基于需求的测试覆盖在测试生命周期中要评测多次,并在测试生命周期的里程碑处提供测试覆盖的标识(如已计划的、已实施的、已执行的和成功的测试覆盖)。 测试覆盖通过以下公式计算:
    测试覆盖 = T^(p,i,x,s) / RfT
    其中:T是用测试过程或测试用例表示的测试 (Test) 数(已计划的、已实施的或成功的)。RfT 是测试需求 (Requirement for Test) 的总数。
          ◆基于代码的测试覆盖
          基于代码的测试覆盖评测测试过程中已经执行的代码的多少,与之相对的是要执行的剩余代码的多少。代码覆盖可以建立在控制流(语句、分支或路径)或数据流的基础上。基于代码的测试覆盖通过以下公式计算:
    测试覆盖 = I^e / TIic
    其中:I^e 是用代码语句、代码分支、代码路径、数据状态判定点或数据元素名表示的已执行项目数。TIic (Total number of Items in the code) 是代码中的项目总数。
    2 质量评测
           测试覆盖的评估提供对测试完全程度的评测,对在测试过程中已发现缺陷的评估提供了最佳的软件质量指标。因为质量是软件与需求相符程度的指标,所以在这种环境中,缺陷被标识为一种更改请求,该更改请求中的测试对象与需求不符。
          ◆缺陷报告
           一般,可以将缺陷计数作为时间的函数来报告,即创建缺陷趋势图或报告;也可以将缺陷计数作为一个或多个缺陷参数的函数来报告,如作为缺陷密度报告中采用的严重性或状态参数的函数。这些分析类型分别为揭示软件可靠性的缺陷趋势或缺陷分布提供了判断依据。
           ◆性能评测
           评估测试对象的性能行为时,可以使用多种评测,这些评测侧重于获取与行为相关的数据,如响应时间、计时配置文件、执行流、操作可靠性和限制。这些评测主要在“评估测试”活动中进行评估,但是也可以在“执行测试”活动中使用性能评测评估测试进度和状态。
    主要的性能评测包括:
          ◆动态监测 - 在测试执行过程中,实时获取并显示正在执行的各测试脚本的状态。

          ◆响应时间/吞吐量 - 测试对象针对特定主角和/或用例的响应时间或吞吐量的评测。 

          ◆百分位报告 - 数据已收集值的百分位评测/计算。

          ◆比较报告 - 代表不同测试执行情况的两个(或多个)数据集之间的差异或趋势.
  • 四款主流测试工具的测试流程

    2008-02-26 16:50:53

     
    文章出处:网络 作者: 发布时间:2006-05-30
    主流测试工具的测试流程
    ========winrunner
    1 启动时选择要加载的插件
    2 进行一些设置(如录制模式等)
    3 识别应用程序的GUI,即创建map(就是学习被测试软件的界面)
    4 建立测试脚本(录制及编写)
    5 对脚本除错及调试(保证能够运行完)
    6 插入各种检查点(图片,文字,控件等)
    7 在新版应用程序中执行测试脚本
    8 分析结果,回报缺陷
     
    =========quicktestpro========
    1 准备录制
    打开你要对其进行测试的应用程序,并检查QuickTest中的各项设置是否适合当前的要求。
    2 进行录制
    打开QuickTest的录制功能,按测试用例中的描述,操作被测试应用程序。
    3 编辑测试脚本
    通过加入检测点、参数化测试,以及添加分支、循环等控制语句,来增强测试脚本的功能,使将来的回归测试真正能够自动化。
    4 调试脚本
    调试脚本,检查脚本是否存在错误。
    5 在回归测试中运行测试
    在对应用程序的回归测试中,通过QuickTest回放对应用程序的操作,检验软件正确性,实现测试的自动化进行。
    6 分析结果,报告问题
    查看QuickTest记录的运行结果,记录问题,报告测试结果。

    ====TestDirect============
    安装好后,先进入站点管理
    1 创建域及工程
    2 添加用户
    3 编辑licenses及本服务器
    4 编辑数据库
    --TD
    1 选择新建的工程进行定制(列表,用户,组,版本等)
    2 在require中增加需求
    3 把需求转化为plan
    4 在testlab中由计划新建测试具体用例与执行

    5 发现bug,在defect中提交bug
    (每一部分都可以相对独立地使用)

    ======loadrunner
    1 制定负载测试计划
    (分析应用程序, 确定测试目标,计划怎样执行LoadRunner)
    2 开发测试脚本
    (录制基本的用户脚本,完善测试脚本)
    3 创建运行场景
    (选择场景类型为Manual Scenario,选择场景类型,理解各种类型,场景的类型转化)
    4 运行测试
    5 监视场景
    (MEMORY 相关,PROCESSOR相关,网络吞量以及带宽,磁盘相关,WEB应用程序 ,IIS5.0,SQL SERVER,NETWORK DELAY等)
    6 分析测试结果
    (分析实时监视图表,分析事务的响应时间,分解页面,确定WEBSERVER的问题,其他有用的功能)
  • IBM Rational Robot介绍

    2008-02-26 16:48:57

     
    文章出处:www.ibm.com 作者: 发布时间:2005-11-07

     

    突出特点
    • 2002年 Yphise 奖最佳功能测试工具
    • 支持多种 IDE:
      Microsoft VisualStudio .NET
      Oracle Developer/2000
      Delphi
      PeopleSoft
      PowerBuilder
    • 支持多种语言:
      Java
      HTML 和 DHTML
      Visual Basic
      Visual C++
      ActiveX
      XML
    • 自动 GUI 功能测试
    • 执行分布式功能测试
    • 测试所有 .NET 本机控件,包括 VB.NET、C#、J#、Managed C++
    • 允许在记录时查看和编辑测试脚本
    屡获大奖的 IBM® Rational® Robot V2003 将图形用户界面 (GUI) 的功能测试自动化。

    Rational Robot 可以对使用各种集成开发环境 (IDE) 和语言建立的软件应用程序,创建、修改并执行自动化的功能测试、分布式功能测试、回归测试和集成测试。

    使新测试人员轻松进入自动化
    IBM Rational Robot 是业界最顶尖的功能测试工具,它甚至可以在测试人员学习高级脚本技术之前帮助其进行成功的测试。它集成在测试人员的桌面 IBM Rational TestManager 上,在这里测试人员可以计划、组织、执行、管理和报告所有测试活动,包括手动测试报告。这种测试和管理的双重功能是自动化测试的理想开始。

    为高级测试人员提供强大的工具
    IBM Rational Robot 是一种可扩展的、灵活的功能测试工具,经验丰富的测试人员可以用它来修改测试脚本,改进测试的深度。使用 Rational Robot V2003,您可以:
    ·将回归测试和配置测试自动化
    ·用条件逻辑扩展测试脚本并调用任何 DLL 或 Windows API 功能。

     

    IBM Rational Robot 可以捕获所有 HTML 和 DHTML 特征,包括链接目标和不可见数据

    Rational Robot 为菜单、列表、字母数字字符及位图等对象提供了测试用例,测试人员可以创建用户定义的调用外部 DLL 或可执行构架的测试用例。它为特定环境的对象,例如 Java 控件、PowerBuilder DataWindows、ActiveX 控件、Special Oracle Forms 对象、OCXs、Visual Basic 对象和 VBXs等,提供了特殊的测试用例。

    快速便捷的可视分析
    IBM Rational Robot 自动记录所有测试结果,并在测试日志查看器中对这些结果进行颜色编码,以便进行快速可视分析。双击某一项,Rational Robot 就直接带您进入测试脚本中对应的行,以便快速分析。

    多种 IDE 和语言支持 Java 环境
    使用 IBM Rational Robot,测试人员可以对复杂环境中所有的 JavaTM 小程序、Java 应用和基于 Web 的集成应用程序进行功能测试。它支持很多通用的 Java 开发环境,包括 Sun 的 JDK、Symantec Visual Café 和 Microsoft Visual J++。Rational Robot 中包含 Robot Java Open API,因此用户可以拓展对新的和现有的 Java 类库的支持。

    Microsoft Visual Studio.NET
    IBM Rational Robot V2003 是测试 .NET 应用程序的首选工具,因为它是唯一可以为 .NET 控件(包括 VB.NET、C#、J# 和 Managed C++)的测试提供全面的本机支持的测试工具,Rational Robot V2003 将基于 Microsoft Visual Studio.NET WinForms 和 WebForms 构架的应用程序的功能测试、分布式功能测试和回归测试自动化,并将 .NET 应用程序的配置测试加以简化和自动化。

    HTML、XML 和 DHTML 应用程序

    IBM Rational Robot 提供了多种测试代码的方式。例如,您可以测试 HTML 链接和链接目标自动变化的动态 HTML 以及表单。此外,Rational Robot 还可以对不可见的特征进行测试,例如嵌入式 SQL 语句和控制事件行为的特征。

    Oracle Developer/2000
    IBM Rational Robot 已与 Oracle Developer/2000 进行了对象级集成。对象脚本的编程可以访问 Oracle Developer/2000 对象的特征,包括记录组和值列表 (LOV)。

    Visual Basic 应用程序

    IBM Rational Robot 检查并验证所有 Visual Basic 对象的特征,包括内置和 ActiveX 控件。它处理这些对象的方式与 Visual Basic 完全相同,都显示同样的特征名称和值,并使用相同的方法获取数据。

    PowerBuilder 应用程序
    IBM Rational Robot 可以可靠地回放自动测试的过程。它可以捕获在 DataWindow 或 DropDown 控件内所有的可见和不可见数据,并检查和验证 OLE 控件及 PowerBuilder 对象的所有属性。

    借助 IBM Rational 的服务加速成功
    IBM Rational Robot 获得了一家全球服务组织的支持,该组织有丰富的在线资源,而且能够提供个性化的培训、咨询和技术支持。IBM Rational Developer NetworkSM 在线提供了很多文章、白皮书、课件及更多内容,它是为使用 IBM Rational 工具和最佳实践的开发专业人员开辟的在线社区。

    通过 IBM Rational Suite 统一您的团队
    IBM Rational Robot 是 IBM Rational Suite® 产品家族中的一员。Rational Suite 家族提供了综合的开发平台,可统一您的团队、优化个体效率并简化 IBM Rational 解决方案的实施。

     
      规格说明
     
    系统要求
    ·PC 兼容的 486 处理器(推荐使用 Pentium 处理器)
    ·200 MB 可用磁盘空间
    ·Windows NT、Windows 2000、Windows XP、Windows 98
    ·32 MB 内存

  • TestDirector介绍

    2008-02-26 16:30:11

     全球测试管理系统

      TestDirector 是业界第一个基于Web的测试管理系统,它可以在您公司内部或外部进行全球范围内测试的管理。通过在一个整体的应用系统中集成了测试管理的各个部分,包括需求管理,测试计划,测试执行以及错误跟踪等功能,TestDirector极大地加速了测试过程。

      电子商务正影响着许多公司制定计划和建立自己的IT系统。很快,一个Web应用软件就能被创建,开发并立即展现在您的客户、供应商或合作伙伴的面前。然而,由于紧凑的开发计划和复杂的系统基构,Web应用软件的测试经常是被忽视的。为了与新经济同步, 您必须开发经过系统测试的高品质的网络应用软件。

      您需要设立一个中央点来管理测试过程。一套基于Web的测试管理系统提供了一个协同合作的环境和一个中央数据仓库。由于测试人员分布在各地,您需要一个集中的测试管理系统能让测试人员不管在何时何地都能参与整个测试过程。IT部门增长地会非常快,人员也会不断流动。您必须以最快的速度培训新的测试人员,教会他们所有与测试有关的知识技术。重点在于管理复杂的开发和测试过程,改善部门间的沟通,加速您测试的成功。

      TestDirector能消除组织机构间、地域间的障碍。它能让测试人员、开发人员或其它的IT人员通过一个中央数据仓库,在不同地方就能交互测试信息。TestDirector将测试过程流水化——从测试需求管理,到测试计划,测试日程安排,测试执行到出错后的错误跟踪——仅在一个基于浏览器的应用中便可完成,而不需要每个客户端都安装一套客户端程序。

      需求管理

      程序的需求驱动整个测试过程。TestDirector 的Web 界面简化了这些需求管理过程,以此您可以验证应用软件的每一个特性或功能是否正常。通过提供一个比较直观的机制将需求和测试用例、测试结果和报告的错误联系起来,从而确保能达到最高的测试覆盖率。

      一般有2 种方式可将需求和测试联系起来。其一,TestDirector 捕获并跟踪所有首次发生的的应用需求。您可以在这些需求基础上生成一份测试计划,并将测试计划(?)对应与您的需求。例如,您或许有25 个测试计划(?)可对应同一个应用需求。您一定能方便地管理需求和测试计划(?)之间可能存在的一种多配多的关系,确保每一个需求都经过测试。其二,由于Web 应用是不断更新和变化的,需求管理允许测试人员加减或修改需求,并确定目前的应用需求已拥有了一定的测试覆盖率。它们帮助决定一个应用软件的哪些部分需要测试,哪些测试需要开发,是否完成的应用软件满足了用户的要求。对于任何动态地改变Web 应用,必须审阅您的测试计划是否准确,确保其符合最当前的应用要求。

      计划测试

      测试计划的制定是测试过程中至关重要的环节。它为整个测试提供了一个结构框架。TestDirector的Test Plan Manager 在测试计划期尖,为测试小组提供一个关键要点和Web 界面来协调团队间的沟通。

      Test Plan Manager 指导测试人员如何将应用需求转化为具体的测试计划。这种直观的结构能帮助您定义如何测试您的应用软件,从而您能组织起明确的任务和责任。Test Plan Manager提供了多种方式来建立完整的测试计划。您可以从草图上建立一份计划,或根据您用Require-ments Manager所定义下的应用需求,通过Test Plan Wizard 快捷地生成一份测试计划。如果您已经将计划信息以文字处理文件形式,如Microsoft Word 方式储存,您可以再利用这些信息,并将它导入到Test Plan Manager。它把各种类型的测试汇总在一个可折叠式目录树内,您可以在一个目录下查询到所有的测试计划(?)。例如,你可以将人工和自动测试,如功能性的,还原和负载测试方案结合在同一位置。

      Test Plan Manager 还能进一步的帮助您完善测试设计和以文件形式描述每一个测试步骤,包括对每一项测试,用户反应的顺序,检查点和预期的结果TestDirector 还能为每一项测试连加附属文件,如Word ,Excel ,HTML ,用于更详尽的记录每次测试计划。

      Web 网络应用日新月异,您的应用需求也随之不断改变。您需要相应地更新您的测试计划,优化测试内容。即使频繁的更新,TestDirector 仍能简单地将应用需求与相关的测试对应起来。TestDirector 还可支持不同的测试方式来适应您公司特殊的测试流程。

      多数的测试项目需要一个有人工与自动测试的结合,包括健全,还原和系统测试。但即使符合自动测试要求的工具,在大部分情况下也需要人工的操作。启用一个演变性的而非革新性的自动化切换机制,能让测试人员决定哪些重复的人工测试可转变为自动脚本以提高测试速度。

      TestDirector 还能简化将人工测试切换到自动测试脚本的转化,并可立即启动测试设计过程。

  • LoadRunner介绍

    2008-02-26 16:24:51

     
    文章出处:51CMM 作者:SPIN-CS 发布时间:2006-01-28
    工业标准级负载测试工具

      LoadRunner 是一种预测系统行为和性能的负载测试工具。通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题,LoadRunner 能够对整个企业架构进行测试。通过使用LoadRunner ,企业能最大限度地缩短测试时间,优化性能和加速应用系统的发布周期。

      目前企业的网络应用环境都必须支持大量用户,网络体系架构中含各类应用环境且由不同供应商提供软件和硬件产品。难以预知的用户负载和愈来愈复杂的应用环境使公司时时担心会发生用户响应速度过慢,系统崩溃等问题。这些都不可避免地导致公司收益的损失。Mercury Interactive 的 LoadRunner 能让企业保护自己的收入来源,无需购置额外硬件而最大限度地利用现有的IT 资源,并确保终端用户在应用系统的各个环节中对其测试应用的质量,可靠性和可扩展性都有良好的评价。

      LoadRunner 是一种适用于各种体系架构的自动负载测试工具,它能预测系统行为并优化系统性能。LoadRunner 的测试对象是整个企业的系统,它通过模拟实际用户的操作行为和实行实时性能监测,来帮助您更快的查找和发现问题。此外,LoadRunner 能支持广范的协议和技术,为您的特殊环境提供特殊的解决方案。

      轻松创建虚拟用户

      使用LoadRunner 的Virtual User Generator,您能很简便地创立起系统负载。该引擎能够生成虚拟用户,以虚拟用户的方式模拟真实用户的业务操作行为。它先记录下业务流程(如下订单或机票预定),然后将其转化为测试脚本。利用虚拟用户,您可以在Windows ,UNIX 或Linux 机器上同时产生成千上万个用户访问。所以LoadRunner能极大的减少负载测试所需的硬件和人力资源。另外,LoadRunner 的TurboLoad 专利技术能。

      提供很高的适应性。TurboLoad 使您可以产生每天几十万名在线用户和数以百万计的点击数的负载。
    用Virtual User Generator 建立测试脚本后,您可以对其进行参数化操作,这一操作能让您利用几套不同的实际发生数据来测试您的应用程序,从而反映出本系统的负载能力。以一个订单输入过程为例,参数化操作可将记录中的固定数据,如订单号和客户名称,由可变值来代替。在这些变量内随意输入可能的订单号和客户名,来匹配多个实际用户的操作行为。

      LoadRunner 通过它的Data Wizard 来自动实现其测试数据的参数化。Data Wizard 直接连于数据库服务器,从中您可以获取所需的数据(如定单号和用户名)并直接将其输入到测试脚本。这样避免了人工处理数据的需要,Data Wizard 为您节省了大量的时间。

      为了进一步确定您的Virtual user 能够模拟真实用户,您可利用LoadRunner 控制某些行为特性。例如,只需要点击一下鼠标,您就能轻易控制交易的数量,交易频率,用户的思考时间和连接速度等。

      创建真实的负载

      Virtual users 建立起后,您需要设定您的负载方案,业务流程组合和虚拟用户数量。用LoadRunner 的Controller,您能很快组织起多用户的测试方案。Controller 的Rendezvous 功能提供一个互动的环境,在其中您既能建立起持续且循环的负载,又能管理和驱动负载测试方案。

      而且,您可以利用它的日程计划服务来定义用户在什么时候访问系统以产生负载。这样,您就能将测试过程自动化。同样您还可以用Controller 来限定您的负载方案,在这个方案中所有的用户同时执行一个动作---如登陆到一个库存应用程序----来模拟峰值负载的情况。另外,您还能监测系统架构中各个组件的性能---- 包括服务器,数据库,网络设备等----来帮助客户决定系统的配置。

      LoadRunner 通过它的AutoLoad 技术,为您提供更多的测试灵活性。使用AutoLoad ,您可以根据目前的用户人数事先设定测试目标,优化测试流程。例如,您的目标可以是确定您的应用系统承受的每秒点击数或每秒的交易量。

      定位性能问题

      LoadRunner 内含集成的实时监测器,在负载测试过程的任何时候,您都可以观察到应用系统的运行性能。这些性能监测器为您实时显示交易性能数据(如响应时间)和其它系统组件包括application server, web server,网路设备和数据库等的实时性能。这样,您就可以在测试过程中从客户和服务器的双方面评估这些系统组件的运行性能,从而更快地发现问题。

      再者,利用LoadRunner 的ContentCheck TM ,您可以判断负载下的应用程序功能正常与否。ContentCheck 在Virtual users 运行时,检测应用程序的网络数据包内容,从中确定是否有错误内容传送出去。它的实时浏览器帮助您从终端用户角度观察程序性能状况。

      分析结果以精确定位问题所在

      一旦测试完毕后,LoadRunner 收集汇总所有的测试数据,并为您提供高级的分析和报告工具,以便迅速查找到性能问题并追溯原由。使用LoadRunner 的Web 交易细节监测器,您可以了解到将所有的图象、框架和文本下载到每一网页上所需的时间。例如,这个交易细节分析机制能够分析是否因为一个大尺寸的图形文件或是第三方的数据组件造成应用系统运行速度减慢。另外,Web 交易细节监测器分解用于客户端、网络和服务器上端到端的反应时间,便于确认问题,定位查找真正出错的组件。例如,您可以将网络延时进行分解,以判断DNS 解析时间,连接服务器或SSL 认证所花费的时间。通过使用LoadRunner 的分析工具,您能很快地查找到出错的位置和原因并作出相应的调整。

      重复测试保证系统发布的高性能

      负载测试是一个重复过程。每次处理完一个出错情况,您都需要对您的应用程序在相同的方案下,再进行一次负载测试。以此检验您所做的修正是否改善了运行性能。

      Enterprise Java Beans的测试

      LoadRunner 完全支持EJB 的负载测试。这些基于Java 的组件运行在应用服务器上,提供广泛的应用服务。通过测试这些组件,您可以在应用程序开发的早期就确认并解决可能产生的问题。

      利用LoadRunner, 您可以很方便地了解系统的性能。 它的Controller 允许您重复执行与出错修改前相同的测试方案。它的基于HTML 的报告为您提供一个比较性能结果所需的基准,以此衡量在一段时间内,有多大程度的改进并确保应用成功。由于这些报告是基于HTML 的文本,您可以将其公布于您公司的内部网上,便于随时查阅。

      最大化投资回报

      所有Mercury Interactive 的产品和服务都是集成设计的, 能完全相容地一起运作。由于它们具有相同的核心技术,来自于LoadRunner和ActiveTest TM 的测试脚本,在Mercury Interactive 的负载测试服务项目中,可以被重复用于性能监测。借助Mercury Interactive的监测功能--Topaz TM 和ActiveWatch TM ,测试脚本可重复使用从而平衡投资收益。更重要的是,您能为测试的前期布署和生产系统的监测提供一个完整的应用性能管理解决方案。

      支持无线应用协议

      随着无线设备数量和种类的增多,您的测试计划需要同时满足传统的基于浏览器的用户和无线互联网设备,如手机和PDA。LoadRunner 支持2 项最广泛使用的协议:WAP和I-mode。此外,通过负载测试系统整体架构,LoadRunner 能让您只需要通过记录一次脚本,就可完全检测上述这些无线互联网系统。

      支持Media Stream应用

      LoadRunner 还能支持Media Stream应用。为了保证终端用户得到良好的操作体验和高质量Media Stream,您需要检测您的Media Stream应用程序。使用LoadRunner ,您可以记录和重放任何流行的多媒体数据流格式来诊断系统的性能问题,查找原由,分析数据的质量。

      完整的企业应用环境的支持

      LoadRunner 支持广泛的协议,可以测试各种IT 基础架构。

  • WinRunner介绍(转)

    2008-02-26 16:18:00

    WinRunner:强大的企业级自动化测试工具

      Mercury Interactive公司的WinRunner是一种企业级的功能测试工具,用于检测应用程序是否能够达到预期的功能及正常运行。通过自动录制、检测和回放用户的应用操作,WinRunner能够有效地帮助测试人员对复杂的企业级应用的不同发布版进行测试,提高测试人员的工作效率和质量,确保跨平台的、复杂的企业级应用无故障发布及长期稳定运行。

      企业级应用可能包括Web应用系统,ERP系统,CRM系统等等。这些系统在发布之前,升级之后都要经过测试,确保所有功能都能正常运行,没有任何错误。如何有效地测试不断升级更新且不同环境的应用系统,是每个公司都会面临的问题。

      如果时间或资源有限,这个问题会更加棘手。人工测试的工作量太大,还要额外的时间来培训新的测试人员等等。为了确保那些复杂的企业级应用在不同环境下都能正常可靠地运行,你需要一个能简单操作的测试工具来自动完成应用程序的功能性测试。

      轻松创建测试

      用WinRuuner创建一个测试,只需点击鼠标和键盘,完成一个标准的业务操作流程,WinRunner自动记录你的操作并生成所需的脚本代码。这样,即使计算机技术知识有限的业务用户轻松创建完整的测试。你还可以直接修改测试脚本以满足各种复杂测试的需求。WinRunner提供这两种测试创建方式,满足测试团队中业务用户和专业技术人员的不同需求。

      插入检查点

      在记录一个测试的过程中,可以插入检查点,检查在某个时刻/状态下,应用程序是否运行正常。在插入检查点后,WinRunner会收集一套数据指标,在测试运行时对其一一验证。WinRunner提供几种不同类型的检查点,包括文本的、GUI、位图和数据库。例如,用一个位图检查点,你可以检查公司的图标是否出现于指定位置。

      检验数据

      除了创建并运行测试,WinRunner还能验证数据库的数值,从而确保业务交易的准确性。例如,在创建测试时,可以设定哪些数据库表和记录需要检测;在测试运行时,测试程序就会自动核对数据库内的实际数值和预期的数值。WinRunner自动显示检测结果,在有更新/删除/插入的记录上突出显示以引起注意。

      增强测试

      为了彻底全面地测试一个应用程序,需要使用不同类型的数据来测试。WinRunner的数据驱动向导( Data Driver Wizard)可以让你简单地点击几下鼠标,就可以把一个业务流程测试转化为数据驱动测试,从而反映多个用户各自独特且真实的行为。

      以一个订单输入的流程为例,你可能希望把订单号或客户名称作为可变栏,用多套数据进行测试。使用Data Driver Wizard,你可以选择订单号或客户名称用数据表格文件中的哪个栏目的数据替换。你可以把订单号或客户名称输入数据表格文件,或从其它表格和数据库中导入。数据驱动测试不仅节省了时间和资源,又提高了应用的测试覆盖率。

      WinRunner还可以通过Function Generator增加测试的功能。使用Function Generator可以从目录列表中选择一个功能增加到你的测试中以提高测试能力。例如,你可以选择”calendar”,然后从日历功能的下属目录中选择,如Calendar_select_date(),然后你可以直观地输入参数,把这个功能插入到你的测试中。

      针对相当数量的企业应用里非标准对象,WinRunner提供了Virtual Object Wizard来识别以前未知的对象。使用Virtual Object Wizard,你可以选择未知对象的类型,设定标识和命名。在录制使用该对象的测试时,WinRunner会自动对应它的名字,从而提高测试脚本的可读性和测试质量。

      运行测试

      创建好测试脚本,并插入检查点和必要的添加功能后,你就可以开始运行测试。运行测试时,WinRunner会自动操作应用程序,就象一个真实的用户根据业务流程执行着每一步的操作。测试运行过程中,如有网络消息窗口出现或其它意外事件出现,WinRunner也会根据预先的设定排除这些干扰。

      分析结果

      测试运行结束后,你需要分析测试结果。WinRunner通过交互式的报告工具来提供详尽的、易读的报告。报告中会列出测试中发现的错误内容、位置、检查点和其它重要事件,帮助你对测试结果进行分析。这些测试结果还可以通过Mercury Interactive的测试管理工具TestDirector来查阅。

      维护测试

      随着时间的推移,开发人员会对应用程序做进一步的修改,并需要增加另外的测试。使用WinRunner,你不必对程序的每一次改动都重新创建你的测试。WinRunner可以创建在整个应用程序生命周期内都可以重复使用的测试,从而大大地节省时间和资源,充分利用你的测试投资。

      每次记录测试时,WinRunner会自动创建一个GUI Map文件以保存应用对象。这些对象分层次组织,既可以总览所有的对象,也可以查询某个对象的详细信息。一般而言,对应用程序的任何改动都会影响到成百上千个测试。通过修改一个GUI Map文件而非无数个测试,WinRunner可以方便地实现测试重用。

      帮助你的应用程序为无线应用作准备

      随着无线设备种类和数量的增加,你的应用程序测试计划需要同时满足传统的基于浏览器的用户和无线浏览设备,如移动电话、传呼机和个人数字助理(PDA)。
    无线应用协议是一种公开的、全球性的网络协议,用来支持标准数据格式化和无线设备信号的传输。
        使用WinRunner,测试人员可以利用微型浏览模拟器来记录业务流程操作,然后回放和检查这些业务流程功能的正确性。

    http://www.51testing.com/html/27/1150.html

  • webload工具介绍

    2008-02-21 11:31:05

    webload工具介绍(转)


    Webload3.01使用指南
    1. 工具的使用范围
    l 需要对web进行负载/压力、稳定性测试,如果适当的调整可以进行极限。
    2. WEBLOAD概述
    l webload是RadView公司推出的一个性能测试和分析工具,它让web应用程序开发者自动执行压力测试;webload通过模拟真实用户的操作,生成压力负载来测试web的性能, 当前最高版本是6.0
    l 用户创建的是基于javascrīpt的测试脚本,称为议程agenda,用它来模拟客户的行为,通过执行该脚本来衡量web应用程序在真实环境下的性能
    l 如有需要可以在做负载测试的同时,使用服务器监控工具对服务器端的内容进行记录那样使负载测试更加全面。

  • Apache JMeter简介

    2008-02-21 11:29:07

    Apache JMeter简介     CSDN Blog推出文章指数概念,文章指数是对Blog文章综合评分后推算出的,综合评分项分别是该文章的点击量,回复次数,被网摘收录数量,文章长度和文章类型;满分100,每月更新一次。

      Apache jmeter 是一个100%的纯java桌面应用,用于压力测试和性能测量。它最初被设计用于Web应用测试但后来扩展到其他测试领域。 

     
    Apache jmeter 可以用于对静态的和动态的资源(文件,ServletPerl脚本,java 对象,数据库和查询,FTP服务器等等)的性能进行测试。它可以用于对服务器,网络 或对象模拟繁重的负载来测试它们的强度或分析不同压力类型下的整体性能。你可以使用它做性能的图形分析或在大并发负载测试你的服务器/脚本/对象。

        Apache jmeter
    的特性包括:

     能够对HTTPFTP服务器进行压力和性能测试, 也可以对任何数据库进行同样的测试(通过JDBC)。
     完全的可移植性和100 java
     完全 Swing 和轻量组件支持(预编译的JAR使用 javax.swing.*)包。
     完全多线程 框架允许通过多个线程并发取样和 通过单独的线程组对不同的功能同时取样。
     精心的GUI设计允许快速操作和更精确的计时。
     缓存和离线分析/回放测试结果。
     高可扩展性:
        可链接的取样器允许无限制的测试能力。
        各种负载统计表和可链接的计时器可供选择。
        数据分析和可视化插件提供了很好的可扩展性以及 以及个性化。
        具有提供动态输入到测试的功能(包括Javascrīpt)。
        支持脚本变成的取样器(在1.9.2及以上版本支持BeanShell)。

  • 自动化测试软件

    2008-02-04 17:29:08

    当前主流的自动化测试软件有哪些呢

Open Toolbar