背景
I.图形用户接口
在一些现代的计算机***中,用户通过图形用户接口(“GUI”)与软件程序相互作用。基本上,GUI是计算机和用户之间的接口,它利用图像而不仅是文字来请求用户输入和显示程序的输出。典型的GUI由用户接口元件(“UI元件”)组成,这些元件是能够被用户看见、听到,或相反被感知或相互作用的计算机***或程序的那些方面。例如,UI元件包括诸如图标、按钮、对话框、编辑框、列表框、组合框、滚动条、选项表、按钮、单选按钮和互联网页中的各种元件(例如,超链接和图像)的选项。在一个典型的计算机程序里常遇到几乎数千个UI元件。
虽然单个的GUI元件可以作为一个单一选项显示给用户,实际上它可能由许多单独选项或被组合在一起的子元件所构成。例如,一个工具条选项可以由一个列表元件,一个组合框元件,一个滚动条元件等等组成。此外,每一个这些子元件自身可以由其它子元件组成。用这种方式,UI元件能够作为结构单元用于构建其它的,更复杂的UI元件。这种方法是有用的,因为当将它们装配成组合元件时,软件管理的用户接口可以重新使用某些公共单元的定义。
GUI环境中的许多UI元件表示程序的特征且显示在计算机屏幕上显示,因此用户可以通过选择,加亮,存取和操作它们与程序相互作用。当光标指向UI元件时,通过操纵屏幕上的光标(典型地通过鼠标或者键盘控制)和按压或者点击按扭来完成与用户的相互作用。例如,在文字处理软件中,用户可以操纵鼠标选择程序的菜单条上的选项,点击工具条上的图标,或者加亮浏览窗内的文本字块。同样,用户可以使用键盘输入来与计算机应用程序相互作用。例如,在文字处理程序中,用户可以按压“ALT-F”,“CTRL-B”,或者其它预定义的按键组合来访问程序性能。根据鼠标或键盘的输入,计算机增加,改变和操作显示屏上的显示。GUI技术为用户与计算机***相互作用提供了方便的,用户友好的环境。
II.UI自动化
UI自动化(“UIA”)是一个用于Microsoft Windows的可访问性机构,通过提供有关用户接口(“UI”)的编程访问信息,用于访问辅助技术产品和自动检测机构的需求。例如,UIA允许屏幕阅读器程序访问关于文字处理软件的UI信息,提供具有该信息的阅读器程序,它需要将可听提示提供给视力差的用户。通过应用编程接口(“API”)设置的方法,UIA提供用于创建和与UI相互作用的优良结构机制。通过现有的或新的软件(可能由其他人编写)来访问程序菜单和其它UI元件,控制和应用程序开发者们利用UIAAPI组以使他们的产品更容易被不同的用户所理解。例如,盲人显示屏,屏幕阅读器(讲解器),放大器,和其它Microsoft Windows中的软件可以使用UIA使没有使用过计算机的用户容易使用计算机。
实际上,UI自动化利用位于树型结构中的UI元件的分级结构来给操作***和计算机应用程序提供可靠的UI信息。为了准确地描述它们的结构,GUI元件可以被认为是彼此内的嵌套。例如,在树型结构的最高处是一个桌面元件,它是GUI的“桌面”或默认背景区域的代表。桌面元件内部具有许多用于应用程序的应用程序元件,根据用户的指令,该应用程序已被调用并准备执行(例如,典型的Microsoft Windows桌面可以有许多被装载并准备执行的应用程序的例子诸如Microsoft Word,Microsoft Excel等等)。在树型结构层次里的较低层是与应用程序有关的结构(例如,文字处理应用软件在某些给定的时间可以有许多用户看得见的结构)。每个框架之内可以有许多文档,每个文档中包含许多UI元件(例如,按钮,列表框等等)。UI元件自身可以由其它UI元件组成。例如,对话框或组合框包含诸如按钮控制的其它UI元件。此外,按钮元件仍可以包括其它UI元件。根据用户接口和它的组成部分,这样的嵌套可以被任意的深入和包含任意数目的分支。
对于一些操作***平台,UI元件的实例是分配一个标识符来帮助区分特殊UI元件与其它UI元件。例如,在基于操作***的Microsoft Windows中,应用程序与识别给定桌面环境内的应用程序的模块标志符相关。同样,一些用户接口平台(例如,Microsoft Windows,用于Java的Swing)对某些UI元件使用数字标志符(控制ID)。在一些计算环境中,诸如Microsoft Windows环境,UI元件经常和控制它们所属类别的类别名相关。例如,在基于***的MicrosoftWindows中,诸如组合框,列表框和按钮的公共UI元件分别与诸如ComboBox类,ListBox类和Button类的类名相关。同样,其它UI结构可以有用于它们各自UI元件类的名称。
值得注意的是,这些技术识别UI元件的对象分类或类型,但是不能单独地提供一个稳定的标识符,该标识符通过重新启动正在运行程序的计算机,当仍然在开发时通过创建不同的程序,通过同一程序的另一个例子的公开来唯一地识别UI元件,或用于打开另一台计算机上的相同程序。
UIA通过生成在GUI树型结构里唯一识别UI元件的组合ID克服了这些不足之处。UIA通过增加直接与UI元件相关的标识信息(例如,控制名或控制类型)产生组合标识符用于分级标识信息(例如,母控制,子控制,和/或同级控制)以及控制特定图形信息(例如,树型结构中UI元件的深度)。例如,可以通过收集与母UI元件相关的识别信息生成目标UI元件的标识符,该母UI元件描述桌面上目标叶UI元件和根元件之间的分级排列。通过路径的概念,用于UI元件的唯一层次和从属关系的相关标识符可以被平衡以便唯一和持续地识别它。
该唯一的标识符(持久ID)提供单个UI元件的简单访问,以便程序主机UI元件的功能可以被编程和测试,并且以便特殊UI元件可以与其它程序模块相一致。对于有关UIA的附加信息,例如,参见通过Microsoft Developer Network获得的文件。
III.宏编制器和UI记录器
在GUI环境中记录和重放用户和计算机的相互作用的这种能力具有使多种团体受益的潜能,包括企业(或其它大型组织),用户,软件开发者,测试人员,和计算机保障人员。例如,通过自动化大量的过程,企业组织可以使商业过程流水线,诸如支持连锁管理的软件的使用。通过创建将一系列的输入行为结合为重放行为的宏或者脚本,用户可以在单一的步骤中触发。软件开发者们可以使用这种能力来记录用户的行为,有助于为开发中的软件生成测试案例。测试者可以使用记录和重放工具来建立测试以便执行自动回归测试。计算机保障人员可以记录用户的行为来发现计算机崩溃或中止的原因,或者用来帮助用户了解怎样使用软件。
A.商业的宏编制器
许多传统的宏编制器程序生成显示由计算机或应用程序执行的内部指令和行为的脚本,用于执行一个功能。可是,在一些例子里,用户必须根据一组脚本指令和复杂的程序结构独立地开发脚本。因此,用户必须懂得程序逻辑,并且在某种程度上懂得受控程序的基础逻辑以便建立和使用宏。例如,AutoMate,宏程序,使用拖放式任务生成器,通过按照它们的执行顺序拖动和放下的具体步骤来创建一个宏脚本,这意味着AutoMate用户必须了解怎样以及按照什么顺序发布指令。Macro Scheduler是一种宏创建程序,它允许用户使用多于200条脚本指令和程序结构(不包括实际声明的变量和其他用户定义的结构)编写宏脚本。该复杂性要求创建和编辑由这些宏程序生成的脚本,实际上由这些宏生成器生成的脚本不表示UI活动的实际上一步步的可读记录,减少了那些宏程序的有效性,特别对于初学用户和计算机保障人员以及努力调试问题的软件开发者。
B.内部宏语言
作为一种商业宏编制软件的替换,一些应用程序具有内置能力,利用它们自身特定用途的应用控制语言(“宏语言”)记录和重放宏。应用程序的宏语言对该应用程序是典型唯一的且通常基于应用程序的内部目标模型(“IOM”)。当不用面向对象的技术可能创建宏语言时,多数内部模型使用程序结构的面向对象的表示。IOM为程序提供可访问的轮廓或者类,属性,操作,参数,关系的模块,以及基于对象的关联。宏语言访问它们应用程序的IOM并嵌入其通信机构(诸如事件请求)以访问和调用应用程序内的功能。例如,Microsoft Word的用户能够记录一条宏以自动格式化文本。然而,大部分宏语言的一个主要缺点是它们是具体的应用程序。由一个应用程序记录的宏通常不被其他应用程序所支持,特别是如果两个应用程序由对抗的软件公司开发。在一些情况下,用于应用程序的一个版本的宏记录不被该应用程序以后的版本所支持。
C.与宏的依存关系
开发宏会很困难,且许多用户和商户不愿意去做任何破坏其现有的宏的事情。商户特别的不愿做可能会消极影响他们商务处理的任何事情。实际上,许多用户和商户因为害怕“破坏”某些事情不愿意升级软件乃至安装补丁。例如,假设商户使用扫描收到的传真的自动商务处理(例如,以宏的形式),在传真上自动执行光学字符识别(“OCR”)来产生传真的文本文件版本,将文本文件里的数据与电子表格中的条目进行比较以便核对帐号信息,最后发送一个确认邮件给传真的发送者。这个商务处理很可能使用一组可能复杂宏的组合和多种软件包来适当地运行(例如,扫描仪程序,OCR程序,电子表格程序,文本文件程序,等等)。商户和用户经常担心升级宏或软件除非他们确保他们的自动化处理中的当前投资将保持原样。
D.其它UI记录器
许多传统的UI记录器具有与上述的那些宏工具类似的缺点,因为他们使用复杂的脚本指令和程序结构来表示数据。另一个缺点是传统的重放非常依赖于记录计算机的先前存在的状态。例如,重放可能依赖于某些硬件配置,软件安装,和/或运行时环境的动态(诸如用于特殊记录相互作用的UI元件的位置或有效性)。使用传统的重放工具,那些先前存在状态的任何改变可能导致重放失败。
作为一个例子,假设用户重新配置应用程序用户接口。一些基于GUI的应用程序允许用户为程序特征移动按钮,重新配置菜单,添加或者删除其它UI元件,将连接添加到菜单条的宏上,或执行其它UI更改。尽管个性化菜单功能是一个有用的特征(例如,使用户能够为他们的具体需求定制UI),它可能导致许多记录和重放工具失败,因为UI元件不在他们希望的位置。
例如,当鼠标按钮被点击时,Microsoft Windows 3.1宏记录器试图通过记录鼠标运动和鼠标坐标来重复GUI中的用户操作。重放过程中,如果UI元件不在它被希望的地方,重放会失败。关于在Microsoft Windows 3.1里有关宏记录的附加信息,例如,参见题为《User`s Guide for Microsoft Windows forWorkgroups》的参考文献的第137页。作为另一个例子,假设用户在低分辨率的监视器/桌面下记录UI操作。稍后,用户将其变成较高分辨率的监视器/桌面。在这种情况下,如上所述,重放很可能失败,因为改变了UI元件的显示屏状态。因此,当计算机环境改变时重放变得格外不可靠。
最后,需要简单的,全***宏和UI记录工具与现有的宏语言和特定应用程序宏记录器相适应。同时,需要简单的,全***宏和UI记录工具与动态的用户接口一起工作。
详细描述
下面的描述涉及基于GUI的不同软件的宏和UI记录和播放的技术和工具。例如,根据被记录的用户活动的类型和被使用的应用程序的记录能力(在这里有时被称为“智能”记录),全***宏和UI记录工具使用适当的记录技术。工具可利用基于UIA的记录机制来记录与兼容UIA的应用程序相对的用户活动。如果该应用程序与UIA不兼容(或者即使希望用另外的机制记录),该工具可以记录用户执行的与应用程序相互作用的原始步骤(例如,鼠标按钮点击,击键)。该工具可以在不同的环境中使用一种特殊的记录机制。这些环境包括记录用特定应用程序内部宏语言描述的操作(应用程序利用它自身内部记录机制来记录)和记录与动态用户接口相对的操作。在这里描述的工具可以记录与不同种类的应用程序,操作***软件,或其它软件相对的活动。
2004年6月15日申请的序号为No.aa/bbb,ccc的题为“Recording/PlaybackTools for UI-based Applications”的U.S.专利申请,在这里结合参考其公开的内容,描述了多种记录和重放工具。部分这些工具根据UI元件的识别值(“UID”)使用UIA结构来记录输入。UIA在GUI中生成唯一识别UI元件的组合ID。该UID至少部分地取决于用户接口中UI元件的位置和它与其它UI元件的相互关系。当工具使用UID来记录和重放涉及具体UI元件的操作时,改变该元件的位置可以导致重放失败。
例如,假设用户通过删除菜单条按钮重新配置用户接口。当重放工具试图启动该删除按钮时,重放失败。如另一个例子,经常在升级一个应用程序的时候特征被移动和/或重命名以适应新的特特。例如,假设在一个版本中“Open File”特征作为第三选项设置在“File”菜单上。在以后的释放中,该“Open File”特征被移动以适应一个“New File”特征,“Open File”变为第四个选项列于该“File”菜单上。根据旧的用户接口宏可以中断因为UI元件被移动了和/或UID被改变了。
在一些实施例中,全***宏和UI记录工具使用智能记录来阐明这些类问题。应用程序用应用程序的内部宏语言记录用户操作。在记录之后,用应用程序的内部宏语言表示的已记录的步骤作为不透明的已记录步骤的令牌从应用程序传送到宏和UI记录工具。然后全***宏和UI记录工具可以进一步封装已记录步骤的令牌和/或与标志信息关联的已记录步骤的令牌。在一些实施例中,每个宏指令被转换成分离的记录步骤令牌。换句话说,一系列相关的宏语言指令被封装为一个已记录的步骤令牌。那些令牌保留基于宏语言指令的暂时顺序以便允许它们被应用程序播放,如同它们被记录时那样,也允许用统一的全***宏和UI记录工具相互操作。在接收已记录的步骤令牌之后,该工具选择性地生成反映记录步骤的代码。随后,可以播放这些代码以便再现已记录的步骤或者,可选地,可以为测试,故障诊断或其他目的编辑该代码。
例如,假设文字处理软件有一个用来打开命名为“文件名”的宏语言指令“打开(文件名)”,该指令嵌入在应用程序的内部目标模块中。在使用智能记录工具记录期间,该宏指令作为一个已记录的步骤令牌被传送,结合其他适当的信息,并且储存用于重放,这时该基础指令“打开(文件名)”作为已记录的步骤令牌从智能记录工具传回到应用程序。这就允许应用程序使用他们自身的本地记录环境在全***UI记录和重放结构内记录和重放UI操作。全***宏可以被编写得不受与自定义菜单相关问题的影响并且在与软件更新相关的用户接口中改变,只要基础宏语言与软件的先前版本保持兼容。此外,全***记录结构提供统一的记录和重放接口。在组合的宏和UI记录处理中,它也简化不同应用程序的宏和其他UI记录的分解。
作为全***UI记录结构的一部分,当应用程序不能使用内部宏记录器或其他特殊应用程序UI记录器时,可以使用不同的记录机制。例如,使用基于UIA的记录***,如题为“Recording/Playback Tools for UI-based Applications”的美国专利申请所述,其很好地用于记录与具有静态菜单组的应用程序相对的用户接口操作。换句话说,如果应用程序不能根据UI自动体系结构支持操作,全***UI记录结构RPF可以简单地记录用户执行的作为他或她与基于UI的应用程序相互作用的原始步骤。有时,各种记录技术被组合使用。例如,在一些测试实例中的原始用户输入的基于UIA的数据,以及内部宏记录器数据都被记录。
记录与基于UI的应用程序相互作用的用户执行的原始步骤(例如,鼠标点击,键盘击键)是相当简单的;难题是当应用程序有一个可配置的用户接口(例如,允许菜单和菜单项被任意的重新排列的接口)时,当一个应用程序升级修改用户接口时,或者当应用程序用内部语言处理宏或UI记录信息时,如何表示和处理这些信息。概念地,通过将被记录的应用程序的内部记录能力与文摘相结合这里描述的一些技术和工具增强了记录性能,用户通过友好用户接口可以将已记录的步骤和输入转换成为重放代码。如上所述,具有各自内部记录能力的应用程序可以调用他们的内部记录器将用户的行为映射到应用程序的内部目标模块,因此通过简单的菜单/菜单项记录来解决“升级封锁”和菜单重新配置的问题。
在一些实施例中,利用令牌技术,收集特殊应用程序宏或UI记录数据然后转换成已记录的步骤令牌。技术和工具创建不透明的令牌来定义用户与应用程序的互相作用。一旦生成已记录步骤的令牌,其它已记录的行为(例如,UIA事件也在令牌中)可以被转换成用于在同一或别的计算机上重放的程序代码,具有生成应用程序已记录步骤令牌可能仍嵌入在程序代码中。
在多种共同的情况下,这里描述的该技术和工具允许全***宏或UI记录工具与各种不同类型的软件程序(例如,UIA兼容的应用程序,具有内部宏记录器的应用程序,不适应UIA的应用程序)以及各种类型的用户接口(例如,静态的,动态的)相互作用。在适当的时候这些技术和工具通过使用应用程序各自内部的记录能力使记录可靠和坚固。此外,该工具和技术提供给用户一致的宏或UI记录接口。该技术和工具能够以不同方式实现,并且可被组合或单独使用。
I.UI记录和重放结构
UI记录和重放框架(“UI RPF”)是一个被设计用来使与应用程序或其他软件程序相对的UI活动容易记录和重放的可扩展的结构。可***模块的结构包括过滤器,聚集器,令牌生成器和代码生成器。图1示出了一个典型的UI RPF 100,在这里描述的各种技术可在其中被执行。基本上,该UIPRF 100记录(或与其它记录软件一起工作)用户正在干什么以及在同一或别的计算机上复制(或与其它复制软件一起工作)他或她的操作。UI RPF 100是交叉应用程序(例如,***级)结构,其可以结合多种应用程序以及在许多配置中使用,并且它被设计用来使各种不同类型用户操作的记录和重放变得容易。它是记录和重放工具能够被创建的基础。UIRPF100可以使用由UI***结构软件120提供的服务,诸如微软UI自动化,来使UI记录变得容易,但是这不是结构100的要求。
图1示出了与UIRPF 100相关的各种模块。该UIRPF 100与UI***结构软件120相互作用,其将已记录的UI输入数据诸如鼠标点击,键盘击键以及从应用程序125,126的输入转换成对于UI记录和重放来说更有意义的数据。通过UI***结构软件120,结构100接收来自诸如文本编辑器125和计算器126的应用程序的已记录步骤,或者作为令牌传送封装***用户接口操作。在一些实施例中,在题为“Recording/Playback Tools for UI-based Applications”的U.S.专利申请中描述了UIRPF 100使用UI记录和重放机制来记录和重放通过UI***结构软件120接收的UI操作。换句话说,UI RPF 100使用不同的UI记录和重放机制。
UI RPF 100的模块也包括智能记录和重放模块110用于与具有各自的本地宏记录器的应用程序相互作用。通过传递UI***结构软件120,该结构100从诸如文字处理器115,电子表格116和图片编辑器117的应用程序中接收已记录的步骤或已记录步骤令牌中的其它宏信息。应用程序115,116,117具有各自的内部记录功能用于将用户的输入映射到该应用程序本地记录环境中的操作,然后应用程序115,116,117通过智能UI记录和重放模块110将内部的记录操作作为令牌传送到结构100。
该UI RPF 100维护应用程序列表,通过这样宏或UI活动可以被记录。由UI RPF 100查看的新应用程序被查询,至少该应用程序第一次就被启动,看其是否支持通过智能记录接口的相互作用。如果该应用程序不支持通过智能接口的相互作用,则根据该应用程序的记录能力,用户操作可以被记录并通过该接口来回传递。换句话说,通过应用程序的内部记录机制(具有通过智能记录接口传送的数据)以及通过UI***结构软件120记录用户的操作,其中这两种选项都是可能的。或者,即使这两个选项都是可能的,用户,应用程序,或全***工具可以确定使用应用程序的内部记录机制或通过UI***结构软件120的记录,但不是两个。或者,用户,应用程序,或全***工具可以单独地或与其他已记录数据一起确定记录与用户的操作相关的原始步骤(例如,鼠标移动,鼠标按钮点击,击键)。
通过智能接口,当UI RPF依次记录通过应用程序内部记录机制记录的用户活动时,应用程序把已记录的用户操作事件转化为令牌。在Visual Basic forApplications(“VBA”)中或在一些其他的语言或由应用程序使用的目标模块中,这些令牌的内容被定义。最后,存储在这些令牌的“有效负载”的信息不被UI RPF100解释,但是只被各自的应用程序解释,这样信息是本地格式。UI RPF 100可以进一步令牌化已记录步骤令牌并且将该数据与其他相关的数据诸如应用程序名称相关联。
在全***工具中,已记录步骤令牌数据可以与从其他应用程序获得的已记录步骤令牌数据,与本地记录器,或与通过该UI***结构软件120获得的已记录数据相连接,以便执行***级记录和重放。
除记录宏和UI数据外,结构100可以产生复制已记录操作的重放代码和/或允许其它软件复制已记录操作的封装数据。
例如,在Microsoft Windows环境里,用户开始记录UI操作,然后点击Windows的“Start”按钮,并且启动与智能记录接口一起工作文的字处理软件。在UI RPF环境中,包括在“Start”按钮上点击鼠标的用户操作被记录。当启动文字处理软件时,UI RPF查看文字处理软件是否与智能记录接口兼容。如果兼容,UI RPF调用文字处理软件本身内部的固有工具来记录由它执行的用户操作。如果文字处理软件也能够与UI***结构软件一起工作,该工具也可以与UI***结构软件一起记录用户操作(UI自动化事件)。另外,该工具也可以记录与用户操作相关的原始步骤(例如,鼠标按钮点击,击键),如果文字处理程序不支持智能记录接口并且不能与UI***结构软件一起工作,其可能特别相关。因此,UI RPF可以使用交换机制来记录和重放。
这个结构100可以包括软件和/或硬件元素。该关系在图1中表示主信息流的模块之间示出;为了简单起见,没有示出其它关系。根据执行,模块可以被添加,省略,分成多个模块,与其它模块组合,和/或用类似的模块代替。换句话说,这里描述了具有不同模块的结构和/或执行一个或多个UI记录和重放技术的模块的其他结构。
II.智能记录
图2示出了一种全***UI记录工具220,结合该工具可实现这里所述的各种技术。图1中的UI RPF包括记录工具220。换句话说,该记录工具220被用作另一个UI结构的一部分。
该记录工具220是全***的,因为它与某些应用程序记录UI***结构信息用于UI记录,但是也在它们各自的本地宏记录环境中与记录用户接***动的应用程序相互作用。该本地记录应用程序通过特殊本地记录接口(如图2中示出的智能RPFAPI)将已记录的宏或UI数据与该工具220进行交换。这就允许该工具220使用(并且相互作用)应用程序各自的记录能力,这样便允许动态用户接口的UI记录和/或变化用户接口的可重放UI记录用于应用程序的不同版本。
当记录宏或UI数据时,记录工具220控制使用的机制。例如,根据用户输入、用户设置、或其他标准,工具220判定是否使用本地应用程序记录、UI***记录、或上述两者作为特殊应用程序。该工具也可以单独地或与其他记录机制结合来记录来自用户鼠标和键盘的原始UI输入。工具220可以为使用中的多个应用程序中的一个,或者为使用中的多个应用程序中所选择的应用程序同时记录宏或UI数据。例如,如果用户配置记录工具220以便只记录文字处理软件程序中的数据,由于用户将电子表格程序数据的剪切和粘贴记录到文字处理软件,只有与文字处理软件相关的步骤被记录。
A.本地记录路径
作为本地宏或UI记录,用户使用用户输入装置诸如鼠标、键盘、触摸板、触摸屏、布莱叶盲文屏、操纵杆、麦克风、或其他类似装置与应用程序240相互作用。由于用户与应用程序240相互作用,通过宏/UI记录器245处理和记录用户的输入,如同在应用程序本地宏记录环境中的步骤,如同用诸如VBA、PerfectScript、M4、TeX的语言或其他宏语言表示的那样。应用程序的内部记录能力提供坚固的结构用于获得可以由应用程序可预测和可靠地播放的数据。已记录的步骤仅受应用程序本地记录环境的局限性限制。例如,如果应用程序允许用户在宏中声明变量,那些变量可被记录和令牌化。
应用程序240令牌化已记录的步骤(如令牌生成器247所示)因此他们能够被传送到工具220。然后,该应用程序通过接口将已记录步骤的令牌传送到工具220。令牌对于工具220是不透明的,这意味着工具220不连续地处理已记录步骤的令牌,不透明的大部分数据的内容没有被工具220解释。另一方面,应用程序240可以解释和响应已记录步骤的令牌内容。该内容是应用程序240的本地格式。例如,该应用程序240封装作为令牌的已记录宏指令以打开一个文件,正如他们被记录时那样(例如,作为二进制数据、文本指令、或DLL指令)。
应用程序240将每个离散的已记录步骤转换成令牌,或者应用程序240将多个已记录的步骤分为单一的令牌。至于令牌生成器的结构,应用程序240可将已记录的步骤数据组合成一个或多个令牌数据结构字段,然后通过复制或参考该字段被传送到工具220。或者,应用程序240可将已记录的步骤数据作为方法调用的参数来传送,这样工具220可将其作为不透明的数据进行接收和处理。应用程序240可以使用XML规则表(其定义一系列用于令牌化已记录步骤的数据的规则)来重新格式化或将记录步骤的数据重新组成令牌。或者,应用程序240使用一些其他的令牌生成机制。概念地,令牌生成可看作是用令牌数据结构代替已记录步骤的数据,或用令牌信息包装该记录步骤的数据。在这里从工具“隐藏”宏语言指令,建立一个独立于宏语言的令牌,但其内容在适当的本地记录环境中是可识别的。
当令牌化数据时,应用程序240可预先挂起、添加、或相反将标记数据加到该记录的步骤中。标记数据提供用于重放的相关详细资料,例如,应用程序信息(例如,应用程序的名称和它的版本)、指出序列的时间信息、特权信息(例如,播放该步骤需要什么样的权利),等等。
工具220通过特殊的本地记录接口接收从一个或多个应用程序传送的令牌(如令牌接收器235所示)。然而该工具220不解释记录步骤令牌的内容,它可以(代替或除了该应用程序)将附加的数据层添加到记录步骤的令牌中和/或将该令牌与标记信息相关联,这些信息诸如应用程序名称、时间信息、索引值等等,以便可以通过正确的应用程序并且以适当的顺序播放该步骤。至少在这种意义上,工具220可被认为也执行令牌生成。
应用程序240支持本地记录接口,因为它通过该接口将格式化的信息传送到工具220,通过该接口产生适当的调用,执行所述工具220调用的回调方法等等。工具220支持该接口,在这种意义上它执行应用程序调用的方法,处理由应用程序传送的所预期的信息,调用应用程序的回调方法等等。用于该接口的精确调用和处理机制从属地执行。
B.UI***记录路径
具有内部宏记录器的应用程序240和/或另一个应用程序260可通过UI***结构软件120支持与***记录工具220的相互作用。作为UI***结构记录,记录工具220的各种元件225收集(a)用户输入数据,(b)监视其他UI活动(诸如焦点变化、选择变化、窗口的创建等等),(c)跟踪有关环境的信息诸如运行应用程序、OS版本、定位信息、默认UI语言、当前UI语言、硬件装置和结构、安全模式、和/或可能有助于描述或重建适当的重放环境的其他数据,(d)将用户输入的数据分解成由用户输入影响的用户接口元素,以及(e)将用户的活动表示为逻辑记录事件。这些逻辑记录事件有助于提供可读的UI记录输出和可靠的UI记录重放。逻辑记录事件可被认为是一种UI记录令牌,但是不同于具有有本地记录数据的不透明记录步骤令牌,工具220解释该逻辑记录事件令牌用于浏览、编辑、换算为代码等等。
在一些实施例中,工具220执行具有过滤器和聚合器的UI***结构记录,如题为“Recording/Playback Tools for UI-based Applications”的U.S专利申请中所述的。换句话说,工具220使用用于UI***结构记录的另一技术。
工具220可在诸如调试程序窗口、源代码浏览器、或文本编辑器的浏览器中显示记录的UI***结构步骤,因此用户可以阅读和浏览错误的数据。典型地,工具220不显示关于带有本地记录数据的记录步骤令牌信息,因为这些令牌的内容对工具220来说是不透明的。当记录步骤的令牌与来自应用程序或用户的诸如应用程序名称、时间标记、操作标签或其他注释的标记信息相关联时,工具220可显示上述信息。数据可以类似地存储于诸如稍候分析的日志文件的文件中。
C.其他的用户输入
记录工具220的多种元件225也可收集原始用户输入数据以及类似地监视其他UI活动、与环境有关的跟踪信息诸如正在运行的应用程序等等。记录这些信息有助于应用程序与智能记录接口或UI***结构不兼容的情况。这些被记录的操作也可以在浏览器中显示,因此用户可以读取和浏览错误数据。典型地,用于播放的原始用户操作中的数据不如背景技术中解释的其他类型的记录令牌易读和可靠。然而,当其他记录技术不适用时,将在全***UI RPF中提供一种用于记录非UIA和非本地记录器应用程序数据的机制。原始用户操作记录的数据可类似地被存于诸如稍候分析的日志文件的文件中。
D.重放代码
在一些实施例中,工具220通过隔行扫描数据组合不同应用程序的令牌和单个文件中的记录模式。例如,不同本地记录器的本地记录操作的记录步骤令牌被组合成一个输入流,连同用于UI***结构操作的令牌和任何其他的用户输入。典型地,用户输入以连续的方式被接收并且用该方式排序的令牌流保持着适当的顺序。时间标记、索引值、以及应用程序信息可标明令牌以帮助保持适当的顺序。或者,工具220为不同应用程序和记录模式创建单独的文件。
作为UI***操作令牌,工具220使用代码生成器230从令牌中产生重放代码250。这能够自动地或当用户选择工具220中的一个“生成代码”选项时被完成。重放代码250可以各种格式输出,包括C#、XML、C++、JAVA、或任何其他程序、脚本、宏、或面向文件的语言、或重放接口的其他命令或指令或其他机制来驱动基于UI的应用程序。例如,代码生成器230将UI***操作令牌映射到重放代码250中的相应指令。对于UI***结构环境中的代码生成的附加描述,参见题为“Recording/Playback Tools for UI-based Applications”2004年7月15日申请的U.S专利申请。
工具220以正确的时间顺序选择地将本地记录操作的记录步骤令牌***到重放代码250中,诸如维护记录步骤令牌的脚本文件。或者,工具220使用代码生成器230产生重放代码250,该代码包括记录步骤的令牌。值得注意的是,封装本地记录数据的记录步骤的令牌对工具220来说是不透明的,因此该令牌被典型地传送到重放代码250,并且不被用于转换成其他表达示的工具220所解释。
重放代码250可被浏览、存储、编辑、修改、添加、删除、编译、或者相反用于提前重放,结合预期的限制在一定程度上该工具可以浏览、修改等不透明记录步骤的令牌。能够编辑重放代码250为用户提供方便有效的机制,该机制用于创建宏、生成自动检测实例、程序中的自动化步骤等。所生成的代码可以被编辑,用于增加条件表达式、改变变量、在代码中增加循环和其他程序指令。例如,重放时,假定一段重放代码改变了***文件并要求具有管理员权限的用户登录。因此,条件表达式被添加到该重放代码中,在运行这段代码前该条件表达式检查适当的权限。如另一个例子,假定软件开发者需要通过再三地重复同样的指令串来过载测试一个程序,因此,“循环”被添加到该重放代码中,这样就使该重放代码被重复若干次。
然后该重放代码250可用于管理已记录活动的重放,如下所述。该代码250可在同一计算机或不同计算机上播放。
E.工具的结构和使用
通常,工具220的各种模块是可***的,这意味着对于不同的应用程序,他们可以被具有同样功能的其他模块所代替。例如,工具220中的代码生成器230是可***的,因此开发者能够重用工具220的一些部分只是改变了由交换代码生成器所产生的方式代码。因此该工具220是可扩展的;对于不同的应用程序可以改变它的功能。在一些实施例中,工具220给出可插模块的选项菜单,因此允许用户控制加载适当的用户所期望功能的适当模块。
例如,在“重量级”记录模式中,工具220收集关于UI活动的详细信息并广泛登录该信息。这提供了更可靠的重放但很可能扰乱软件的执行,与其相对的活动被记录。或者,在“轻便的”记录模式中,工具220收集较少的信息并且,因此,不大可能扰乱软件的执行,与其相对的活动被记录。然而,这仍然可以提供足够的信息,用于在同一环境中重放、用于将用户活动显示给保障人员、或用于其他目的。
类似地,工具220可以在交互模式中记录信息,在该模式中通过限定矩形或闪光来突出UI单元以显示记录了什么。其他闪光反馈可用于把已记录的UI数据的应用程序显示给用户。或者,在交互模式中,用户被提示输入每个操作或工具220或应用程序240无法分辨的操作的描述注释信息。或者,工具220可以在该背景中操作以便记录UI活动而不干扰用户。
工具220负责装载其他需要的可插模块(例如,用于收集数据、令牌化数据、生成代码等的模块),加强保密性(例如,特权检查),产生记录进程,同步模块间的活动,建立和维护用于记录的队列,记录错误(例如,到局部文件或随意到网络服务或服务器),以及收集记录信息(例如,OS版本、定位信息、硬件结构等)。
图2中模块间示出的关系表明了信息的主流;为了简单起见其他关系未示出。根据实施例,模块能够被增加、省略、分成多个模块、与其他模块组合、和/或用相同的模块替代。换句话说,具有不同模块的工具和/或模块的其他结构执行这里描述的一个或多个记录技术。
工具220的用户接口可以是位于记录窗口周围,停放在计算机屏幕的顶部或底部,或被最小化为任务条的类似VCR的接口。该接口包括特征按钮诸如“记录”、“暂停”、“停止”、以及“播放”,和当该说明可获得时用于给出记录步骤的说明的区域。作为该接口的例子,参见题为“Recording/Playback Tools forUI-based Applications”的U.S专利申请。
F.记录技术,记录的定时
存在两种在记录期间用于将令牌传送到工具220的模式:批处理模式和交互模式。通常,在批处理模式中,当请求时在应用程序收集记录步骤令牌并传送到工具220。当焦点远离该记录应用程序时这些检索已收集令牌的请求会发生,并且还会发生定期地分配记录负担。
在交互模式中,相反,由于他们的发生令牌从被记录的应用程序传送到工具220中。交互地传送令牌的一个缺点是增加了CPU的交叉处理负载。在特殊情况下,根据被记录的应用程序,被记录的数据总量,以及产生记录步骤令牌的速度的快慢,批处理或交互模式的一个会优于另一个。
图3示出了用全***UI记录工具记录本地应用程序宏活动的技术300。工具和应用程序诸如图2中示出的记录工具220和应用程序240执行该技术300。换句话说,另一种工具和/或应用程序执行该技术300。
该工具检查310应用程序是否使用了智能本地记录接口。一些应用程序不支持通过接口的相互作用。其他应用程序可能支持通过接口的相互作用,但是用户或工具决定不使用本地记录。例如,当用户首先启动应用程序时该工具查看应用程序是否支持通过智能本地记录接口的相互作用,如果支持,将应用程序的名称加入到支持通过接口相互作用的应用程序列表中。或者,在记录开始时工具查看应用程序是否支持智能本地记录接口。如果应用程序不支持通过接口的相互作用,该工具可将应用程序加入到不支持的应用程序列表中。
如果没有使用智能本地记录接口,该工具使用315另一个记录器记录UI活动。例如,该工具将UIA软件记录器用于UIA启动应用程序中,或者代替地,将原始的UI输入记录器用于不启动UIA的应用程序。然而图3示出了选择的记录路径,相反该工具既可以同时使用本地记录和其他记录。
当使用智能本地记录接口时,应用程序接收用户输入并且记录320宏数据。因此,应用程序的本地记录器记录步骤由与应用程序相对的用户执行。
继续记录宏数据的过程直到应用程序或工具确定325它不用再继续。这种检查可估算任意种情况,包括是否用户已经选择地终止记录过程,是否工具已经从批处理模式的应用程序中请求了令牌,是否批处理或交互模式中的计数器或计时器已经终止,是否用于令牌化的资源是可获得的,是否已经访问了指定的UI元件,是否达到了规定的记录步骤的数量,等等。
然后应用程序令牌化330已记录的宏数据,产生一个或多个对工具来说是不透明的令牌。例如,应用程序使用上述的令牌生成机制和/或如上所述增加标记信息。或者,工具执行一些或所有令牌化或信息添加。
工具或应用程序估算335是否继续记录宏数据。此外,这种检查可以估算任意种情况,包括是否用户已经选择地终止了记录过程,是否已经请求用户输入令牌化成功或注释信息,等等。
工具选择地将它接收的令牌转换340成代码诸如其中嵌入了令牌的脚本。例如,如上所述,该工具使用代码生成机制。
换句话说,技术300的各种阶段被单独地或与其他阶段结合执行。例如,图3示出了在宏数据记录320之后发生的令牌化330以及转换340,可选地,一个或所有这些操作随着记录320同时被执行.
III.智能重放
图4示出了一种全***UI重放工具420,结合该工具这里描述的各种技术可以被实现。图1中的UI RPF包括该重放工具420。换句话说,重放工具420用作另一个UI结构的一部分。
重放工具通过接收重放代码以及通过UI***服务驱动应用程序,通过将令牌传送到用于在它们各自的本地记录环境中进行解释的应用程序,或者通过播放与UI活动相关的原始步骤来复制UI活动。该重放工具420是全***的,因为它处理UI***结构信息的重放用于具有某些应用程序的UI记录重放,但是也在它们各自的本地宏记录器环境中与重放用户接***动的应用程序相互作用。该本地记录器应用程序通过专用本地重放接口(如图4中所示的智能RPFAPI)用工具420交换已记录的宏或UI数据。这就允许该工具420控制(和相互作用)应用程序自己的记录能力,因此,这允许动态用户接口的UI重放和/或应用程序的不同版本的已改变的用户接口的UI重放。
当重放宏或UI数据时,重放工具420控制所使用的路径。例如,根据已经记录的数据,工具420决定是否使用本地应用程序记录器重放,UI***重放,或使用二者。换句话说,该工具也可以重放原始记录的步骤。该工具420可以为使用中的每个应用程序,或者为使用中的多个应用程序中所选择的应用程序同时重放宏或UI数据。
A.阅读器
作为输入,重放工具420从代码生成器诸如图2中或其他地方说明的代码生成器230接收重放代码450。该重放代码450可以是各种格式,包括C#、XML、C++、JAVA,或任何其他程序,脚本,宏,或面向文件的语言,或其他命令或指令,用于重放接口或其他机制以便驱动基于UI应用程序的UI***操作。本地记录操作的已记录步骤的令牌可包含在代码450中,诸如脚本文件(其可被直接传送到令牌传送器435)或嵌入在其他代码450中。
在一些实施例中,重放工具420通过隔行扫描数据从不同的应用程序和记录模式中接收结合代码和令牌的单一文件。例如,不同本地记录器的本地记录操作的已记录步骤的令牌,连同UI***结构操作代码和任何其他已记录的用户输入一起被组合成一个流。或者,工具420接收不同应用程序和记录模式的分离文件。
在该重放工具420中,阅读器410接收重放代码450并检验代码450的正确性。例如,重放工具接收包含重放代码的文件并且试图证实该文件内部一致并且与当前***的状态一致。如果发现任何不一致,通知该用户,并且,在一些实施例中,要求该用户手动结束该步骤。换句话说,终止重放。
对于根据UI***结构重放路径的重放,阅读器410将代码450传送到UI***结构播放器425用于编程控制由代码450所指定的应用程序。对于根据本地记录重放路径的重放,阅读器410将用于本地记录数据的记录步骤令牌传送到令牌传送器435。
B.本地记录器重放路径
对于本地宏或UI记录器重放,重放工具420将令牌(如所示的令牌传送器435)从工具420传送到应用程序440,该应用程序包括适当的本地记录环境。工具420通过专用本地重放接口传送令牌。在传送之前,工具420可以解释增加到已记录步骤令牌中的数据的附加层,包括标记信息诸如应用程序名称、时间标记、索引值、等等,以至于通过正确应用程序以适当的顺序重放该步骤。
不同于代码450中其他类别的信息,本地记录数据的已记录步骤令牌不直接由重放工具420解释。相反,令牌作为不透明的大部分数据由令牌传送器435传送到应用程序440(如所示的令牌接收器442元件)。应用程序440解释令牌,将宏记录数据从令牌传送到宏播放器445。在应用程序440中,已记录宏数据在应用程序的本地宏记录环境中被解释。用诸如VBA、PerfectScript、M4、TeX的语言或另一种宏语言表示宏数据。应用程序的内部记录能力提供坚固和可靠的重放结构,有时允许通过UI***结构进行不可能的重放。
应用程序440提取已记录的步骤为重放该已记录的步骤作准备。应用程序440可以从单一的令牌中提取一个已记录步骤的操作,或者该应用程序440可以从单一的令牌中提取多个已记录步骤的操作。至于反向令牌生成机制,应用程序440可以从令牌的一个或多个数据结构的字段中读取已记录步骤操作数据,该数据通过复制和引用从工具420中被传出。或者,应用程序440可以拆开作为方法调用的参数被传递的已记录步骤的操作数据。或者,应用程序440使用一些其他的机制从令牌提取已记录步骤的操作。概念地,该提取可被看作是从令牌数据结构中读取已记录步骤的操作数据,或从令牌信息中打开该已记录步骤的操作数据。这里“揭示的”宏语言指令在适当的本地记录环境中是可识别的。
应用程序440也可以处理标记数据,这些数据被预先挂起、添加、或相反当令牌化这些数据时被加入到已记录步骤的操作数据中。该标记数据提供相关的重放细节,例如,应用程序信息(例如,应用程序的名称和它的版本),指示顺序的时间标记,特权信息(例如,播放该步骤所需的权力),等等。
工具420支持专用本地重放接口,在一定意义上该工具通过接口格式化传送到应用程序440的信息,通过该接口产生适当的调用,执行该应用程序440调用的回调方法,等等。应用程序440支持该接口,在一定意义上该应用程序执行工具420调用的方法,处理由工具传入的预期信息,调用工具420的回调方法,等等。用于该接口的精确调用和处理机制是从属执行的。
C.UI***重放路径
根据具有UI***结构播放器425的UI***结构,具有本地宏记录器重放的应用程序440和/或另一个应用程序460可以支持重放。该播放器425本质上是一个引擎用于编程控制基于UI的应用程序的特征。对于该重放路径,重放工具420处理具有播放器425的代码450以便通过编程的与基于UI的应用程序的相互作用复制已记录的步骤和UI活动。
在一些实施例中,工具420用元件执行UI***结构重放,如2004年6月15日申请的、题为“Recording/Playback Tools for UI-based Applications”的美国专利申请中所述的。换句话说,工具420使用另一种UI***结构重放技术。
在重放开始时,可以比较当前的条件和进行UI记录时的条件。如果检测到显著的变化,通知用户,并且提供选项以便继续。
有时,重放代码是自动执行的并要求没有附加输入或操作的控制。换句话说,UI***操作被***到内部重放队列中,这就允许播放器模块425按顺序处理每个已记录的步骤。播放器425从队列中获得已记录的步骤,等待可以获得适当的应用程序,等待准备输入的处理,执行已记录的步骤,并且向重放工具420或别处报告步骤的执行结果。如果任何一步失败,调用简单的睡眠功能并且试图再次复制已记录步骤之前该播放器425仅仅等待某一段时间。或者,当不能执行步骤时,通知并要求用户结束该步骤。这就允许适度地处理重放故障而不需要破坏重放工具或任何其他相关的应用程序。
不依靠播放器425,一些应用程序也可以代替他们自己的重放工具来运行所产生的代码。
D.工具的结构和使用
通常,工具420的各种模块是可***的,这意味着对于不同的应用程序,可以用具有相同功能的其他模块代替他们。因此工具420是可扩展的;对于不同的应用程序可以改变它的功能。该工具420可以给出可插模块的菜单选项,因此允许用户控制用户所期望功能的适当模块的装载。
重放工具提供各种结构选项。重放工具420可被配制用于指示怎样发生重放。例如,重放工具可被配置得当操纵“暂停”按钮时暂停重放。或者,当要求用户进行输入以继续处理该重放代码时该工具420暂停。重放工具可被配置得执行重放,如同计算机***运行能够“着色”的代码那样快。换句话说,重放可以尽可能快地发生而不用等着色完成。在一些实施例中,与单独的应用程序相对的多个重放序列被同时运行。
为了提高重放的安全性,图2的记录工具220可以加密重放代码和/或嵌入在其中的令牌。如果这样,重放工具420解密该代码和/或令牌。其他的安全措施包括重放时要求用户重新输入用户名和密码,不记录该数据,检查与用户的安全模式相对的重放安全模式(例如,为用户请求管理员状态并试着播放管理员级脚本),以及仅在当前的时间允许缓冲器重放(从不在文件中的代码和/或令牌中重放),当它可以被证实时,该缓冲器的内容由当前用户记录。
工具420根据需要负责装载其他的可插模块,增强安全性(例如,检查特权),产生重放线程,模块间的同步活动,建立和维护用于重放的队列,记录错误(例如,到局部文件或选择地到网络服务器或服务),以及收集重放信息。
图4中模块间所示的关系指出信息的主流;为了简单起见没有示出其他关系。根据实施例,模块能够被添加、省略、分成多个模块、与其他模块组合、和/或用类似的模块代替。换句话说,具有不同模块和/或其他结构模块的工具执行这里描述的一个或多个重放技术。
工具420的用户接口可以是位于重放窗口周围,停放在计算机屏幕顶部或底部,或最小化成任务条的类似VCR的接口。该接口包括特征按钮诸如“暂停”,“停止”,和“播放”,以及当可以获得该说明时用于显示被重放步骤的说明的区域。作为该接口的例子,参见题为“Recording/Playback Tools for UI-basedApplications”的美国专利申请。
E.重放技术
图5示出一种用于管理具有全***UI重放工具的本地应用程序宏活动的重放技术500。工具和应用程序诸如图4中所示的重放工具420和应用程序440执行该技术500。或者,另一个工具和/或应用程序执行该技术500。
工具接收510具有已记录步骤令牌的代码。例如,该代码是包含令牌的脚本文件。或者,该代码是具有在其中嵌入令牌的程序语言代码。
然后该工具检验520代码。该工具可检验令牌的正确性,顺序,以及内部一致性,或证实该工具以及应用程序准备好纠正该重放。在这种情况下,工具可以考虑加入到令牌中用于标识或排队的标记信息。例如,该工具使用上述的验证机制。如果已记录操作不能被验证,该用户可以被提示终止重放或,换句话说,执行操作。
然后该工具将该已记录步骤的令牌传送到540适当的应用程序。应用程序处理550该令牌,提取已记录的宏数据,以及在应用程序的本地记录重放环境中重放已记录的本地宏操作,以便重复由用户执行的与应用程序相对的步骤。处理本地已记录的操作典型地包括尽可能平稳地重复已记录的UI活动而没有或几乎没有用户的干涉。因此,***UI记录器工具可有效地管理并且与具有高可靠性的应用程序的内部记录环境相互作用。
该工具或应用程序确定560是否继续重放。例如,当代码或令牌被完全重放时,当用户终止重放时,或者当由于错误终止重放时,该工具以及应用程序结束,或者当重放停止并请求用户输入数据时,该工具以及应用程序等待。
换句话说,该技术500的各种阶段被单独执行或与其他阶段组合执行。例如,图5示出了当验证520和传送540发生在令牌处理550之前时,或者在流水线上一个或所有这些操作与令牌处理550同时执行。
IV.计算环境
上述用于宏和UI记录和重放的工具用于不同的基于GU的软件(例如,图2中的工具200)以及宏和UI记录技术能够在任何类型的计算装置和环境中执行,包括各种形状因素的计算机(个人的,工作站,服务器,手持式,膝上型,写字板,或其他可移动的),分布式计算网络,以及网络服务,如一些常用的例子。该宏和UI记录工具和技术可以用硬件电路执行,也可以用计算机或其他计算环境中的宏记录、处理和浏览软件980执行,诸如图6中所示的一种。
图6说明了适当计算环境600的一般实例,在该环境中上述的技术能够被执行。该计算环境600不用于暗示这里所述的工具和技术的功能或使用范围的任何限制,因为他们可以在不同的通用目的或专用目的计算环境中执行。
参考图6,该计算环境600包括至少一个处理单元610和存储器620。在图6中,这个最基本的结构630包含在虚线中。处理单元610执行计算机可执行指令并且可以是真实或虚拟的处理器。在一个多处理***中,多处理单元执行计算机可执行指令以提高处理能力。存储器620可以是易失性存储器(例如,寄存器,高速缓存,RAM),非易失性存储器(例如,ROM、EEPROM、闪存,等等),或一些二者的组合。存储器620存储执行智能记录工具和技术的软件680。
计算环境可具有附加特征。例如,计算环境600包括存储器640,一个或多个输入装置650,一个或多个输出装置660,以及一个或多个通信连接670。互连机制(未示出)诸如总线、控制器、或互连计算环境600的元件的网络。典型地,操作***软件(未示出)为在计算环境600中执行的其他软件提供操作环境,并且调整计算环境600的元件的活动。
存储器640可以是可移动的或不可移动的,并包括磁盘,磁带和磁盒,CD-ROMs,CD-RWs,DVDs,或其他任何能用于存储信息和在计算环境600中能被访问的介质。该存储器640存储用于宏以及UI记录以及重放软件680的指令。
输入装置650(例如,用于控制装置连接结构中的点的装置)可以是触摸输入装置诸如键盘,鼠标,笔,或跟踪球,声音输入装置,扫描设备,或其他将输入提供到计算环境600的装置。作为音频,该输入装置650可以是声卡或以模拟或数字形式接收音频输入的类似装置,或将音频采样提供到计算环境的CD-ROM阅读器。输出装置660可以是显示器,打印机,扬声器,CD记录器,或其他提供从计算环境600输出的装置。
通信连接670能够通过通信介质与另一个计算实体进行通信。该通信介质传送诸如计算机可执行指令信息、音频/视频或其他介质信息,或已调制数据信号中的其他数据。已调制数据信号是一种具有一个或多个各自的特征集或在信号中以某种形式转变的关于编码信息的信号。作为例子,而不是限制,通信介质包括用电、光学、RF、红外线、声学、或其他载体执行的有线或无线技术。
这里的宏和UI记录和重放技术能够用计算机可读介质的一般上下文描述。计算机可读介质是任何可获得的介质,该介质能够在计算环境中被访问。作为例子,而不是限制,同该计算环境600一样,计算机可读介质包括内存620、存储器640、通信介质、以及上述装置的任何组合。
计算机可执行指令的一般上下文描述这里的技术,诸如那些包含在程序模块中,在目标真实或虚拟的处理器上的计算环境中执行的指令。通常,程序模块包括例程、程序、程序库、对象、类、元件、数据结构等等,他们执行特殊任务或执行特殊抽象数据类型。程序模块的功能可以被组合或在各种实施例中所期望的程序模块间被分离。用于程序模块的计算机可执行指令可以在局部或分布式计算环境中执行。
为了介绍,该详细说明使用术语“确定”,“产生”,“调整”,以及“应用”来描述计算环境中的计算机操作。这些术语是计算机执行的操作的极度抽象,并不应与由人类执行的行为相混淆。与这些术语相应的实际计算机操作根据实施例而改变。
由于本发明的原理可以应用到许多可能的实施例,我要求保护与本发明所有这些实施例相同的、会出现在下列权利要求中的范围和精神内的以及等效的实施例。