用户界面自动化测试方法、电子设备及存储介质

技术领域

本公开涉及软件自动化测试领域，更具体地涉及一种用户界面（User Interface，UI）自动化测试方法、一种电子设备以及一种计算机可读存储介质。

背景技术

近年来，随着市场竞争日益激烈，对软件质量的要求越来越严格。通常，在发布某一软件版本前，需要对该软件版本进行充分的测试，以发现潜在的缺陷，从而提高软件质量。

传统的手工测试需要测试人员逐步执行测试用例中的步骤，并且观察软件的实际运行结果是否符合预期。然而，由于目前软件数量较多、软件版本迭代速度较快，测试软件的工作量较大。如果完全依赖测试人员手工测试，则难以在有限的时间内完成如此庞大的测试工作。

自动化测试的目的就在于解决上述的人力、时间等问题。自动化测试通过预先编写的测试软件控制被测软件执行测试用例中的步骤，并按照预定的条件判断软件的实际运行结果是否符合预期。由于自动化测试可以由计算机等电子设备来执行测试用例、处理运行结果，从而节省了人力、时间、硬件等资源，提高了测试效率。

在实际应用中，由于在UI软件的测试中需要进行大量重复的操作（例如，重复点击某一按钮），使用自动化测试来测试UI软件（即，UI自动化测试）是一种常见的测试方式。

在此部分中描述的方法不一定是之前已经设想到或采用的方法。除非另有指明，否则不应假定此部分中描述的任何方法仅因其包括在此部分中就被认为是现有技术。类似地，除非另有指明，否则此部分中提及的问题不应认为在任何现有技术中已被公认。

发明内容

根据本公开的一方面，提供一种用户界面自动化测试方法，该方法包括对测试用例中的至少一个测试步骤执行如下操作：判断是否能够获取该测试步骤所对应的控件的自动化元素（AutomationElement）；响应于判断到能够获取该测试步骤所对应的控件的AutomationElement，调用应用程序自动化（UI Automation）框架以执行该测试步骤，响应于判断到不能获取该测试步骤所对应的控件的AutomationElement，调用视窗操作系统（Windows）应用程序接口以执行该测试步骤。

根据本公开的另一方面，提供一种电子设备，该电子设备包括：处理器；以及存储程序的存储器，该程序包括指令，该指令在由处理器执行时使处理器执行如本公开中所述的方法。

根据本公开的又一方面，提供一种存储程序的非暂态计算机可读存储介质，该程序包括指令，该指令在由一个或者多个处理器执行时，致使一个或者多个处理器执行如本公开中所述的方法。

附图说明

附图示例性地示出了实施例并且构成说明书的一部分，与说明书的文字描述一起用于讲解实施例的示例性实施方式。所示出的实施例仅出于例示的目的，并不限制权利要求的范围。在所有附图中，相同的附图标记指代类似但不一定相同的要素。

图1示出了根据本公开的示例性实施例的UI自动化测试系统的框图；

图2示出了根据本公开的示例性实施例的UI自动化测试方法的流程图；

图3示出了根据本公开的示例性实施例的调用Windows应用程序接口以执行测试步骤的方法的流程图；

图4示出了根据本公开的示例性实施例的设置测试所使用的测试用例的方法的流程图；并且

图5是示出能够应用于实现示例性实施例的示例性电子设备的示意性框图。

具体实施方式

在本公开中，除非另有说明，否则使用术语“第一”、“第二”等来描述各种要素不意图限定这些要素的位置关系、时序关系或重要性关系，这种术语只是用于将一个元件与另一元件区分开。在一些示例中，第一要素和第二要素可以指向该要素的同一实例，而在某些情况下，基于上下文的描述，它们也可以指代不同实例。

在本公开中对各种所述示例的描述中所使用的术语只是为了描述特定示例的目的，而并非旨在进行限制。除非上下文另外明确地表明，如果不特意限定要素的数量，则该要素可以是一个也可以是多个。此外，本公开中所使用的术语“和/或”涵盖所列出的项目中的任何一个以及全部可能的组合方式。

现有的UI自动化测试通过测试程序模拟用户操作UI软件的行为，测试软件的运行情况。但是，现有的UI自动化测试中至少存在以下问题：

1）由于现有UI软件中的控件的数量、种类较多，需要测试人员具有一定的编程能力，以开发用于UI自动化测试的测试软件；

2）由于用户需求变化较快，需要频繁改动UI软件中的UI界面和控件名称，导致测试人员设置测试用例的工作量较大。

针对上述问题，本公开的实施例提供了一种UI自动化测试方法、电子设备以及计算机可读存储介质。在下面的描述中，将涉及以下术语：

1）测试用例：对软件产品进行特定测试任务的描述信息，其内容包括：测试目标、测试环境、输入数据、测试步骤、预期结果等；

2）控件：控件是用户通过直接操纵来读取或编辑有关应用程序信息的软件部件，例如，按钮、滚动条、列表框等；

3）UI Automation框架：是Microsoft Windows的辅助功能框架，可以提供对UI界面上大多数控件的编程访问；

4）AutomationElement：是UI Automation框架中的UI自动化元素，其中，每个AutomationElement对应于UI界面的一个部件（例如，一个控件），并且包含作为UIAutomation框架中的标识符的值；

5）Windows应用程序接口：是Microsoft Windows操作系统中提供的核心应用程序编程接口（Application Programming Interface, API）集，可以提供创建、控制、管理UI界面上的控件的功能；

6）句柄：是用来标识对象或者项目的标识符，可以标识应用程序实例、窗口、控件、位图、GDI对象、资源、文件等。

下面将参考附图并结合实施例来详细说明本公开。

图1示出了根据本公开的示例性实施例的UI自动化测试系统100的框图。

如图1所示，该UI自动化测试系统100包括测试端101和被测端102。其中，测试端101模拟用户行为向被测端102发出相应指令，检测被测端102的执行结果，并判断该执行结果是否符合预期。根据一些实施例，测试端101和被测端102可以为客户端/服务器端架构，其中，测试端101为客户端，而被测端102为服务器端。

根据一些实施例，测试端101可以包括测试端界面1011、测试端后台程序1012。测试人员可以通过测试端界面1011控制软件测试，例如，设置测试用例、开始或停止测试等；测试人员还可以通过测试端界面1011查看测试结果或测试进度。测试端界面1011与测试端后台程序1012可以双向交互：

一方面，测试端界面1011将测试人员输入的指令传递到测试端后台程序1012，响应于接收到来自测试端界面1011的指令，测试端后台程序1012执行所接收到的指令对应的操作，例如，当测试人员通过测试端界面1011选中某一测试用例时，测试端后台程序1012从测试用例库中调取该测试用例，作为当前测试用例；

另一方面，测试端界面1011接收并显示来自测试端后台程序1012的信息，例如，当测试端后台程序1012发现异常状态时，测试端后台程序1012向测试端界面1011报告异常状态信息（例如，错误类型、错误发生时间），测试端界面1011接收并显示这些异常状态信息，以便于测试人员发现异常状态。

根据一些实施例，被测端102包括被测端界面1021、被测端后台程序1022。根据一些实施例，被测端界面1021包含一个或多个控件，例如，如图1所示，被测端界面1021包括第一控件1021a、第二控件1021b、第三控件1021c。根据一些实施例，与测试端101类似，被测端界面1021与被测端后台程序1022可以双向交互：

一方面，被测端界面1021将通过各个控件1021a-1021c接收到的指令传递到被测端后台程序1022，响应于接收到来自被测端界面1021的指令，被测端后台程序1022执行所接收到的指令对应的操作，例如，被测端界面1021接收到点击第一控件1021a的指令，并将该指令传递到被测端后台程序1022，使得被测端后台程序1022执行该指令对应的操作；

另一方面，被测端界面1021接收并显示来自被测端后台程序1022的信息，例如，在被测端后台程序1022完成来自被测端界面1021的某一指令之后，可以将该指令的执行结果传回被测端界面1021，使得被测端界面1021可以显示该指令的执行结果。

根据一些实施例，被测端102可以接收来自用户的指令（例如，用户通过键盘输入的指令）或来自测试端101的指令（例如，测试端后台程序1012按照测试用例中的当前步骤所发出的指令）。根据一些实施例，测试端101可以模仿用户操作被测端102中的各个控件1021a-1021c的行为，向被测端102发送指令以操作控件1021a-1021c。根据另一些实施例，测试端101可以读取被测端102在被测端界面1021上所显示的信息，例如，在向被测端102发送某一测试步骤对应的指令后，测试端101从被测端界面1021上读取执行结果，以判断该执行结果是否为期望结果。

根据一些实施例，测试端101和被测端102可以位于同一电子设备上，该电子设备可以是服务器计算机、工作站计算机、台式计算机、膝上型计算机、笔记本计算机、Microsoft® Surface®设备、个人数字助理（PDA）、诸如Apple iPadTM的平板计算机、上网本或其他类型的电子设备。根据另一些实施例，测试端101和被测端102可以位于不同的电子设备上，测试端101通信地耦合到被测端102。其中，每个电子设备可以是上述电子设备中的任一种，也可以是其它类型的电子设备。

对于Windows系统（例如，Windows XP、Windows Vista、Windows 7、Windows 8、Windows 10等），微软提供了用于UI自动化测试的UI Automation框架。通过UI Automation框架，测试端101可以方便地操作被测端102上的大部分控件，并检测被测端102的状态。然而，在实际应用中，在被测端102上可能存在部分不能通过UI Automation框架操作的控件（例如，事先封装好的第三方开发的插件）。为了解决这一问题，本公开提供了一种UI自动化测试方法，该方法包括对测试用例中的至少一个测试步骤执行如下操作：判断是否能够获取该测试步骤所对应的控件的AutomationElement；响应于判断到能够获取该测试步骤所对应的控件的AutomationElement，调用UI Automation框架以执行该测试步骤，响应于判断到不能获取该测试步骤所对应的控件的AutomationElement，调用Windows应用程序接口以执行该测试步骤。

图2示出了根据本公开的示例性实施例的UI自动化测试方法200的流程图。

在步骤S201中，判断是否能够获取测试步骤所对应的控件的AutomationElement。如果能够获取测试步骤所对应的控件的AutomationElement（步骤S201，“是”），则进入步骤S203，否则（步骤S201，“否”），则进入步骤S205。

根据一些实施例，根据测试步骤所包含的控件信息（例如，控件所属的对话框名称、控件名称、控件类型）来搜索所对应的控件的AutomationElement，如果能够搜索到所对应的控件的AutomationElement，则判断能够获取测试步骤所对应的控件的AutomationElement，如果不能搜索到所对应的控件的AutomationElement（例如，搜索过程所返回的值为无效值），则判断不能获取测试步骤所对应的控件的AutomationElement。

根据一些实施例，可以直接使用测试步骤所包含的控件信息（例如，控件名称、控件类型）构建搜索条件，例如，可以搜索名为“Scene”的ListBox类控件；根据另一些实施例，可以现根据测试步骤所包含的控件信息搜索该控件的AutomationIdProperty（例如，通过UI Spy工具），再按照该控件的AutomationIdProperty来搜索该控件。

在实际的UI界面中，在不同的对话框中可能存在相同名称、类型的控件，例如，在不同聊天对话框中都存在名为“发送”的按钮。为了避免混淆不同对话框中的相同名称、类型的控件，当直接使用测试步骤所包含的控件信息来构建搜索条件时，可以限定仅在以该控件所在对话框中搜索符合搜索条件的控件；当使用AutomationIdProperty来构建搜索条件时，由于每个控件都具有唯一的AutomationIdProperty，则不会混淆。

根据一些实施例，可以通过TreeWalker类的GetFirstChild和GetLastChild方法来搜索测试步骤所对应的控件的AutomationElement。根据另一些实施例，可以通过AutomationElement类的FindFirst和FirstAll方法来搜索测试步骤所对应的控件的AutomationElement。

如上所述，响应于判断到能够获取测试步骤所对应的控件的AutomationElement，则进入步骤S203。在步骤S203中，调用UI Automation框架以执行测试步骤。

根据一些实施例，基于所检索到的测试步骤所对应的控件的AutomationElement，对该控件执行测试步骤中的操作。以测试步骤为在文本框控件中输入字符串“123456”为例，首先通过该控件的AutomationElement获取该文本框控件的对应ValuePattern类，然后通过该控件的ValuePattern类的SetValue方法将该文本框控件的字符串的值设置为“123456”。如上所述的设置控件的字符串的值的示例性代码如下所示：

public static void SetValueToValuePattern(AutomationElement element,string value) /*设置指定控件中的字符串值*/

{

ValuePattern valuePattern = GetValuePattern(element); /*获取控件对应的ValuePattern类*/

valuePattern.SetValue(value); /*将该控件的字符串的值设为指定值*/

}

public static ValuePattern GetValuePattern(AutomationElement element) /*获取控件对应的ValuePattern类*/

{

object currentPattern;

if (!element.TryGetCurrentPattern(ValuePattern.Pattern, outcurrentPattern))

{

throw new Exception(string.Format("Element with AutomationId '{0}' and Name '{1}' does not support the ValuePattern.",

element.Current.AutomationId, element.Current.Name));

}

return currentPattern as ValuePattern;

}

如上所述，响应于判断到不能获取测试步骤所对应的控件的AutomationElement，则进入步骤S205。在步骤S205中，调用Windows应用程序接口以执行测试步骤。

根据一些实施例，可以通过测试步骤所对应的控件的句柄来操作测试步骤所对应的控件；根据另一些实施例，可以使用鼠标事件函数以操作测试步骤所对应的控件。

在如结合图2所描述的UI自动化测试方法中，通过判断能否获取测试步骤所对应的控件的AutomationElement，动态地调用UI Automation框架或Windows应用程序接口来执行测试步骤，从而既保证了优先调用UI Automation框架来执行测试步骤，又保证了能够通过Windows应用程序接口来操作不能通过UI Automation框架操作的控件。

另外，对于能够通过UI Automation框架来操作的控件，本方法也并未增加操作复杂度。如上所述，在UI Automation框架中，需要测试步骤所对应的控件的AutomationElement来执行相应操作，因此，判断能否获取测试步骤所对应的控件的AutomationElement属于通过UI Automation框架来操作控件的必需环节。

因此，本公开提供了一种灵活、高效的UI自动化测试方法，弥补了UI Automation不能操作UI界面上部分控件的问题，且并未增加操作复杂度。

根据本公开中的示例性实施例，调用Windows应用程序接口以执行测试步骤包括：判断是否能够获取测试步骤所对应的控件的句柄；根据判断是否能够获取测试步骤所对应的控件的句柄的判断结果来选择使用测试步骤所对应的句柄或鼠标事件函数以执行测试步骤。

根据一些实施例，根据判断是否能够获取测试步骤所对应的控件的句柄的判断结果来选择使用测试步骤所对应的句柄或鼠标事件函数以执行测试步骤包括：响应于判断到能够获取测试步骤所对应的控件的句柄，使用测试步骤所对应的控件的句柄以执行测试步骤。根据另一些实施例，根据判断是否能够获取测试步骤所对应的控件的句柄的判断结果来选择使用测试步骤所对应的句柄或鼠标事件函数以执行测试步骤包括：响应于判断到不能获取测试步骤所对应的控件的句柄，使用鼠标事件函数以执行测试步骤。

图3示出了根据本公开的示例性实施例的调用Windows应用程序接口以执行测试步骤的方法300的流程图。

在步骤S301中，判断是否能够获取当前测试步骤所对应的控件的句柄。如果能够获取当前测试步骤所对应的控件的句柄（步骤S301，“是”），则进入步骤S303，否则（步骤S301，“否”），则进入步骤S305。

根据一些实施例，根据当前测试步骤所包含的控件信息（例如，控件所属的对话框名称、控件名称、控件类型）来获取该控件的句柄，如果能够获取到所对应的控件的句柄，则判断能够获取当前测试步骤所对应的控件的句柄，如果不能获取到所对应的控件的句柄（例如，获取过程所返回的值为无效值），则判断不能获取当前测试步骤所对应的控件的句柄。

如上所述，响应于判断到能够获取当前测试步骤所对应的控件的句柄，则进入步骤S303。在步骤S303中，使用测试步骤所对应的控件的句柄以执行测试步骤。

根据一些实施例，基于所检索到的当前测试步骤所对应的控件的句柄，对该控件执行当前测试步骤中的操作。以当前测试步骤为对某一窗口执行操作（例如，最大化该窗口）为例，通过该窗口的句柄，可以执行对该窗口的操作。如上所述的通过窗口句柄来执行对该窗口的操作的示例性代码如下所示：

public static void Window (IntPtr hWnd, int nCmdShow) /*设置窗口句柄和窗口操作类型*/

{

ShowWindow(hWnd, nCmdShow);

}

如上所述，响应于判断到不能获取当前测试步骤所对应的控件的句柄，则进入步骤S305。在步骤S305中，使用鼠标事件函数以执行测试步骤。

根据一些实施例，可以预先获取当前测试步骤所对应的控件的位置以模拟鼠标操作，例如，该控件在测试环境（例如，被测端界面1021）中的X轴坐标、Y轴坐标。

根据一些实施例，当测试步骤为模拟用户通过鼠标操作该控件的行为（例如，右击某一按钮）时，通过Windows应用程序接口模拟鼠标以执行测试步骤。根据一些实施例，通过鼠标事件函数来模拟鼠标以执行测试步骤，其中，根据控件位置（例如，控件在桌面中的X轴坐标、Y轴坐标）定位鼠标位置，并且按照测试步骤所模拟的用户操作来定义鼠标事件类型。如上所述的模拟鼠标右击的示例性代码如下所示：

public static void RightClick(double x, double y) /*设置鼠标沿x/y轴的绝对位置*/

{

mouse_event(MouseEventRightDown, (UInt32)x, (UInt32)y, 0,IntPtr.Zero); /*模拟鼠标右键按下*/

mouse_event(MouseEventRightUp, (UInt32)x, (UInt32)y, 0,IntPtr.Zero); /*模拟鼠标右键松开*/

Thread.Sleep(100); /*等待100ms*/

}

根据另一些实施例，当测试步骤为模拟用户通过键盘操作该控件的行为时（例如，在文本框中输入字符）时，可以调用Windows系统的屏幕键盘以执行测试步骤。根据一些实施例，首先，使用鼠标事件函数打开Windows控制面板中的屏幕键盘；其次，使用鼠标事件函数模拟点击控件的行为，使得该控件可以接收来自屏幕键盘的输入；最后，通过鼠标事件函数逐一点击屏幕键盘中的相应键，输入所期望的输入值。

在实际应用中，由于开发者的特殊处理，可能不能获取某些控件的句柄，从而不能使用句柄来操作该控件。在如结合图3所描述的UI自动化测试方法中，对于不能获取句柄的控件，选择使用鼠标事件函数以执行测试步骤，从而解决了上述问题。

另外，对于获取句柄的控件，本方法也并未显著地增加操作复杂度。如上所述，必须首先获取测试步骤所对应的控件的句柄，才能使用句柄来执行相应操作，因此，判断能否获取测试步骤所对应的控件的句柄属于使用句柄来操作控件的必需环节，而并未增加操作复杂度。

根据本公开中的示例性实施例，通过一个测试接口来调用UI Automation框架或Windows应用程序接口。根据一些实施例，采用抽象工厂模式来实现测试接口，其中，将实现调用UI Automation框架或调用Windows应用程序接口的方法分别封装为抽象工厂的两个类。

根据一些实施例，测试接口实现为接口（Interface）。其中，在该测试接口所对应的接口中，存在对应于调用UI Automation框架的接口、对应于调用Windows应用程序接口的接口，而对应于调用UI Automation框架的接口、对应于调用Windows应用程序接口的接口分别由实现调用UI Automation框架的类、实现调用Windows应用程序接口的类来实现（Implement）。

根据另一些实施例，测试接口实现为抽象类（Abstract Class）。其中，该测试接口所对应的抽象类包含对应于UI Automation框架的抽象方法、对应于调用Windows应用程序接口的抽象方法，而对应于调用UI Automation框架的抽象方法、对应于调用Windows应用程序接口的抽象方法分别由实现调用UI Automation框架的类、实现调用Windows应用程序接口的类来实现。

在如本公开中所述的UI自动化测试方法中，由于提供了调用UI Automation框架或调用Windows应用程序接口的统一测试接口，使得测试人员无需关注实现调用UIAutomation框架或调用Windows应用程序接口的具体细节，而只需关注测试用例的参数设置，降低了对测试人员的编程能力的要求。

根据本公开中的示例性实施例，该UI自动化测试方法还包括设置测试用例，其中，设置测试用例包括：选择测试用例库中最接近测试需求的测试用例；判断所选择的测试用例是否完全符合测试需求，其中，响应于判断到所选择的测试用例完全符合测试需求，不调整所选择的测试用例，响应于判断到所选择的测试用例不能完全符合测试需求，调整所选择的测试用例，并且将调整后的测试用例保存在测试用例库中。

图4示出了根据本公开的示例性实施例的设置测试所使用的测试用例的方法400的流程图。

在步骤S401中，选择测试用例库中最接近测试需求的测试用例。

根据一些实施例，根据测试用例的名称或测试目标来选择最接近测试需求的测试用例。例如，当当前测试需求为测试设置相机参数的功能时，可以在测试用例库中搜索名称或测试目标中含有“设置相机参数”的测试用例。

在步骤S403中，判断所选择的测试用例是否完全符合测试需求。如果所选择的测试用例完全符合测试需求（步骤S403，“是”），则无需调整所选择的测试用例，结束设置测试所使用的测试用例的过程；否则（步骤S403，“否”），则进入步骤S405。

根据一些实施例，逐步比较所选择的测试用例中的步骤是否符合测试需求，其中，只要发现其中一个步骤不符合测试需求，则判断所选择的测试用例不完全符合测试需求，仅在所有测试步骤均符合测试需求时，才判断所选择的测试用例完全符合测试需求。

在步骤S405中，调整所选择的测试用例。根据一些实施例，调整所选择的测试用例包括以下操作中的至少之一：调整所选择的测试用例中的测试步骤的顺序、增添新的测试步骤、删减所选择的测试用例中的测试步骤、或者修改所选择的测试用例中的一个或多个测试步骤。

在步骤S407中，将调整后的测试用例保存在测试用例库中，以便在以后的测试中使用。

根据一些实施例，设置测试所使用的测试用例还包括：在初次测试前，在所述测试用例库中存入常用的测试用例。

根据本公开中的示例性实施例，UI自动化测试方法还包括：根据执行所述测试用例的结果，形成测试报告，其中，所述测试报告包括在执行所述测试用例的过程中记录的测试日志和录制的测试视频。

根据一些实施例，测试日志可以包括每个测试步骤的执行时间、执行结果以及对执行结果的初步分析（例如，某一步骤的执行结果是否符合期望）。根据一些实施例，如果存在一个或多个执行结果不符合期望的测试步骤，则在测试日志中首先列出这些执行结果不符合期望的测试步骤的信息，或者在测试日志中用红字示出这些执行结果不符合期望的测试步骤的信息，以便于测试人员进一步分析被测程序可能存在的问题。

根据本公开中的示例性实施例，UI自动化测试方法还包括：如果在执行所述测试用例的过程中发生异常状态，则停止执行所述测试用例。

根据一些实施例，如果某一测试步骤的执行结果不符合期望，则判断为被测程序发生异常状态，并停止执行测试用例，以便于测试人员及时发现被测程序中存在的问题；根据另一些实施例，仅当被测程序报错时（例如，被测程序弹出报错窗口），才判断被测程序发生异常状态并停止执行测试用例，使得能够更高效地进行整个测试用例的测试。

根据本公开中的示例性实施例，提供一种电子设备，包括：处理器；以及存储程序的存储器，所述程序包括指令，所述指令在由所述处理器执行时使所述处理器执行如上所述的UI自动化测试方法。

根据本公开中的示例性实施例，提供一种存储程序的非暂态计算机可读存储介质，所述程序包括指令，所述指令在由一个或者多个处理器执行时，致使所述一个或者多个处理器执行如上所述的UI自动化测试方法。

下面结合图5来描述这样的电子设备和计算机可读存储介质的示例。图5示出了能够应用于实现示例性实施例的示例性电子设备500。

电子设备500可以是各种不同类型的设备，例如服务提供商的服务器、与客户端（例如，客户端设备）相关联的设备、片上系统、和/或任何其它合适的电子设备或计算系统。电子设备500的示例包括但不限于：台式计算机、服务器计算机、笔记本电脑或上网本计算机、移动设备（例如，平板电脑或者phablet设备、蜂窝或其他无线电话（例如，智能电话）、记事本计算机、移动台）、可穿戴设备（例如，眼镜、手表）、娱乐设备（例如，娱乐器具、通信地耦合到显示设备的机顶盒、游戏机）、电视或其他显示设备、汽车计算机等等。因此，电子设备500的范围可以从具有大量存储器和处理器资源的全资源设备（例如，个人计算机、游戏控制台）到具有有限的存储器和/或处理资源的低资源设备（例如，传统的机顶盒、手持游戏控制台）。

电子设备500可以包括能够诸如通过系统总线514或其他适当的连接彼此通信的至少一个处理器502、存储器504、（多个）通信接口506、显示设备508、其他输入/输出（I/O）设备510以及一个或更多大容量存储装置512。

处理器502可以是单个处理单元或多个处理单元，所有处理单元可以包括单个或多个计算单元或者多个核心。处理器502可以被实施成一个或更多微处理器、微型计算机、微控制器、数字信号处理器、中央处理单元、状态机、逻辑电路和/或基于操作指令来操纵信号的任何设备。除了其他能力之外，处理器502可以被配置成获取并且执行存储在存储器504、大容量存储装置512或者其他计算机可读介质中的计算机可读指令，诸如操作系统516的程序代码、应用程序518的程序代码、其他程序520的程序代码等。

存储器504和大容量存储装置512是用于存储指令的计算机存储介质的示例，所述指令由处理器502执行来实施前面所描述的各种功能。举例来说，存储器504一般可以包括易失性存储器和非易失性存储器二者（例如RAM、ROM等等）。此外，大容量存储装置512一般可以包括硬盘驱动器、固态驱动器、可移除介质、包括外部和可移除驱动器、存储器卡、闪存、软盘、光盘（例如CD、DVD）、存储阵列、网络附属存储、存储区域网等等。存储器504和大容量存储装置512在本文中都可以被统称为存储器或计算机存储介质，并且可以是能够把计算机可读、处理器可执行程序指令存储为计算机程序代码的非瞬时性介质，所述计算机程序代码可以由处理器502作为被配置成实施在本文的示例中所描述的操作和功能的特定机器来执行。

多个程序模块可以存储在大容量存储装置512上。这些程序包括操作系统516、一个或多个应用程序518、其他程序520和程序数据522，并且它们可以被加载到存储器504以供执行。这样的应用程序或程序模块的示例可以包括例如用于实现以下组件/功能的计算机程序逻辑（例如，计算机程序代码或指令）：方法200、方法300、方法400（包括方法200、300或400的任何适合的步骤）和/或本文描述的另外的实施例。

虽然在图5中被图示成存储在电子设备500的存储器504中，但是模块516、518、520和522或者其部分可以使用可由电子设备500访问的任何形式的计算机可读介质来实施。如本文所使用的，“计算机可读介质”至少包括两种类型的计算机可读介质，也就是计算机存储介质和通信介质。

计算机存储介质包括通过用于存储信息的任何方法或技术实施的易失性和非易失性、可移除和不可移除介质，所述信息诸如是计算机可读指令、数据结构、程序模块或者其他数据。计算机存储介质包括而不限于RAM、ROM、EEPROM、闪存或其他存储器技术，CD-ROM、数字通用盘（DVD）、或其他光学存储装置，磁盒、磁带、磁盘存储装置或其他磁性存储设备，或者可以被用来存储信息以供电子设备访问的任何其他非传送介质。

与此相对，通信介质可以在诸如载波或其他传送机制之类的已调数据信号中具体实现计算机可读指令、数据结构、程序模块或其他数据。本文所定义的计算机存储介质不包括通信介质。

电子设备500还可以包括一个或更多通信接口506，以用于诸如通过网络、直接连接等等与其他设备交换数据，正如前面所讨论的那样。这样的通信接口可以是以下各项中的一个或多个：任何类型的网络接口（例如，网络接口卡（NIC））、有线或无线（诸如IEEE802.11无线LAN（WLAN））无线接口、全球微波接入互操作（Wi-MAX）接口、以太网接口、通用串行总线（USB）接口、蜂窝网络接口、BluetoothTM接口、近场通信（NFC）接口等。通信接口506可以促进在多种网络和协议类型内的通信，其中包括有线网络（例如LAN、电缆等等）和无线网络（例如WLAN、蜂窝、卫星等等）、因特网等等。通信接口506还可以提供与诸如存储阵列、网络附属存储、存储区域网等等中的外部存储装置（未示出）的通信。

在一些示例中，可以包括诸如监视器之类的显示设备508，以用于向用户显示信息和图像。其他I/O设备510可以是接收来自用户的各种输入并且向用户提供各种输出的设备，并且可以包括触摸输入设备、手势输入设备、摄影机、键盘、遥控器、鼠标、打印机、音频输入/输出设备等等。

虽然在附图和和前面的描述中已经详细地说明和描述了本公开，但是这样的说明和描述应当被认为是说明性的和示意性的，而非限制性的；本公开不限于所公开的实施例。通过研究附图、公开内容和所附的权利要求书，本领域技术人员在实践所要求保护的主题时，能够理解和实现对于所公开的实施例的变型。在权利要求书中，词语“包括”不排除未列出的其他元件或步骤，不定冠词“一”或“一个”不排除多个，并且术语“多个”是指两个或两个以上。在相互不同的从属权利要求中记载了某些措施的仅有事实并不表明这些措施的组合不能用来获益。