CN107924361B

CN107924361B - 用于自动化软件应用测试过程的方法和系统

Info

Publication number: CN107924361B
Application number: CN201680040953.8A
Authority: CN
Inventors: 卢卡斯·克罗克; 塔拉斯·佩列沃尔斯基; 米尔科·内德利科维奇
Original assignee: Siyou Taist Co ltd
Current assignee: Siyou Taist Co ltd
Priority date: 2015-05-12
Filing date: 2016-05-11
Publication date: 2021-06-15
Anticipated expiration: 2036-05-11
Also published as: KR20180008581A; EP3295311A1; US20180121340A1; KR102529142B1; EP3295311B1; WO2016180894A1; CN107924361A; US11023364B2

Abstract

本发明涉及一种用于根据至少一个测试场景在至少一个TV设备(18)上测试交互应用的方法和系统。测试场景通过与该至少一个TV设备(18)分离的测试驱动系统(14)来运行和监控，其中，测试场景包括一系列用户交互步骤以及在指定用户交互步骤之后要实现的应用和/或至少一个TV设备(18)的至少一个目标状态；该方法包括以下步骤：a.将测试定义助手库(15)集成到交互应用中，其中，测试定义助手库(15)被配置为获取有关交互应用和/或至少一个TV设备(18)的状态的信息；b.向至少一个TV设备(18)提供修改后的交互应用；c.运行至少一个测试场景，其中，测试驱动系统(14)在至少一个TV设备(18)上非透明地执行一系列用户交互步骤；以及d.将测试定义助手库获取的有关交互应用和/或至少一个TV设备的状态的信息与在指定用户交互步骤之后的至少一个目标状态相比较。

Description

用于自动化软件应用测试过程的方法和系统

技术领域

本发明涉及一种用于根据至少一个测试场景在至少一个TV设备上测试交互应用的方法和系统。

背景技术

连接的TV设备近来正快速普及，并且已存在大量用于TV设备的交互应用。每一交互应用在发布生产之前都必须适当测试，以确保所有执行路径运行正常，覆盖边缘情况，并且该应用程序与目标平台上的所有TV设备完全兼容。手动测试交互应用存在许多缺点，除了因人为过失导致的潜在错误外，还具有上市时间长、QA团队和测试设备的成本的增加等。已知的自动测试方法(诸如，如美国8185877B1所述)无法用于在TV设备上的交互应用的测试。因此，TV设备的测试需要技术娴熟的技术员，工作流程和开发周期的变化对交互应用开发模式提出了许多的条件和限制。

发明内容

鉴于此，本发明的目的是提供一种用于在TV设备上测试交互应用的方法和系统，从而提供一种简单并且用户友好的方式来定义和执行测试场景。

该目的通过独立权利要求的特征来解决。优选实施例在从属权利要求中进行了描述。

根据本发明，测试场景通过与至少一个TV设备分离的测试驱动系统来运行和监控。测试场景包括一系列用户交互步骤以及在指定用户交互步骤之后要实现的应用和/或至少一个TV设备的至少一个目标状态。该方法包括以下进一步的步骤：

a.将测试定义助手库集成到交互应用中，其中，测试定义助手库被配置为获取有关交互应用和/或至少一个TV设备的状态的信息；

b.向至少一个TV设备提供修改后的交互应用；

c.运行至少一个测试场景，其中，测试驱动系统在至少一个TV设备上非透明地执行一系列用户交互步骤；以及

d.将测试定义助手库获取的有关交互应用和/或至少一个TV设备的状态的信息在与指定用户交互步骤之后的至少一个目标状态相比较。

首先解释一下本发明中所使用的一些术语。在下文中，术语“TV设备”用来指电视或与电视连接使用、以在电视上显示图像和/或视频内容的设备。此种TV设备的实例包括但不限于：电视机、机顶盒、或其他能够广播或传输图像和/或视频内容至TV的设备，诸如，口袋PC(PC stick)、游戏机、广播设备、多媒体设备、流媒体设备、电话、平板电脑以及其他移动设备或其他具有屏幕发送能力的设备。

大多数目前的TV设备平台支持可使用设备制造商提供的常用网络技术或SDK、或定制软件建立的交互应用。术语“交互应用”是指可在TV设备上运行的任何一种应用。在本发明的含义内，交互应用特别地包括可从设备制造商门户安装的应用以及补充TV频道的应用。来自第一组的应用在下文中称为SmartTV应用。来自第二组的应用在不同的国家适用不同的技术标准，其中，现行技术标准为混合广播/宽带TV(HbbTV)。来自第二组的应用在下文中称为广播应用。应当认识到，本发明支持对广播应用和SmartTV应用的测试。

在本发明中，术语“目标状态”是指在交互应用和/或TV设备正常运行的情况下，在对应的指定用户交互步骤之后期望的交互应用和/或TV设备的状态。

测试驱动系统(TDS)以对正在测试的应用和/或TV设备非透明的方式来运行测试场景。术语“非透明的”在本文中是指用户交互步骤或一系列用户交互步骤执行的应用和/或TV设备不能区别来自TDS的用户交互步骤和来自终端用户的常规(即，手动)用户输入信号。

TDHL集成到交互应用中。在本发明中，术语“修改后的交互应用”用以表示包括测试定义助手库的交互应用。

应当认识到，将TDHL集成至应用的过程非常简单，常常仅需要1-4行代码。例如，如果是使用Web技术来建立的TV应用，则TDHL以及唯一应用标识(UAID)可通过添加脚本标签集成至应用的每一HTML页面。如果是使用其他技术来建立的应用，则这通常意味着包括库并且执行预定义初始化调用来越过该UDID。应当认识到，TDHL是一款制作非常精细的软件，通常对应用的整体运行没有任何影响或影响非常小。因为TDHL通常对应用没有提出任何条件，因此开发人员不用对应用代码进行任何调整，即开发过程可直接忽略TDHL的存在。应当认识到，在一些实施例中，TDS可实现利用UAID将TDHL自动注入应用，而无需开发人员的手动介入。

就在开发人员对应用进行签字移交进行测试之前，就将TDHL注入至应用。TDHL可在app运行的设备和TDS之间创建持久性的数据连接。但是，通常并非一直都需要持久性的数据连接。在一些实施例中，TDHL可被配置为持续收集测试相关结果并且在数据连接可用之后一次性将结果传送至TDS。优选地，该TDHL作为用户输入和应用之间的中间人。在运行过程中，TDHL可维持至TDS的持久性的或非持久性的连接，从而实时提供应用运行内部相关的信息。TDS可指导TDHL对应用各UI元件及其非视觉特性进行检查，从而执行测试。

本发明的主要思路之一是将测试定义助手库集成到交互应用中，其中，测试定义助手库被配置为获取有关交互应用和/或至少一个TV设备的状态的信息。因此，本发明建议修改待测试的交互应用。直接向交互应用提供获取有关交互应用和/或至少一个TV设备的状态的信息的功能。而不必从交互应用“外部”监控该交互应用的状态，例如，通过捕获和分析TV设备应用的显示输出。换言之，相关信息直接由集成至交互应用的TDHL获取并且可转发至测试驱动系统进行进一步的分析。这极大地简化了测试过程，原因在于，TDS可以很容易地被配置为在每一设备上监督测试执行、收集每一设备的结果并汇编成综合报告。

本发明的另一优点是涉及TDS，该TDS被配置为在至少一个TV设备上非透明地执行一系列用户交互步骤。由于非透明性，因此TV设备不能区别TDS产生的用户交互步骤和终端用户产生的常规用户输入信号。这对于提供与TV设备“真实操作场景”没有区别的实际测试场景是至关重要的。

在本发明中，已做出努力使TV设备的自动化测试更加容易实现并且更为未获得过任何技术知识的个人所理解。针对测试过程本身，应当认识到，执行测试的人员无需深入了解应用的内部。测试操作员只需要了解应用的规范，即预期行为以及对特定用户行为的响应。测试操作员可以借助于可选地设置的图形用户界面(GUI)自行决定在任意TV设备上建立一系列测试案例。进而在准备好测试案例之后，可安排在许多TV设备(应用所针对的)上进行独立地执行。

在优选实施例中，测试定义助手库获取的数据被传输至测试驱动系统，其中，在步骤d中的比较优选地通过测试驱动系统来执行。因此，可有效分析并进一步处理有关应用和TV设备的信息。

优选地，测试定义助手库获取的有关交互应用和/或至少一个TV设备的状态的信息包括下面中的至少一个：

TV设备标识值；

有关交互应用的运行对象的信息；

有关交互应用的视图对象的信息；

有关交互应用引起的数据流量的信息；

交互应用的控制台输出；

操作系统运行变化；和/或

共享的存储器状态。

获取一个或多个以上说明的数据，从而生成有关交互应用和/或TV设备的状态的精确分析。

进一步优选的是，测试驱动系统包括翻译模块，以将测试场景的用户交互步骤翻译成适于至少一个TV设备中每一个的用户输入信号。

该交互TV应用可以为SmartTV应用或广播应用，其中，测试驱动系统优选地被配置为在至少一个TV设备上自动安装或提供修改后的交互应用。利用能够自动向至少一个TV设备提供修改后的交互应用的测试驱动系统的思路特别有利，原因在于其极大地简化了测试准备过程。特别地，该思路无需单独处理每个TV设备来安装修改后的应用。因此节约了时间和成本。

如果该交互应用为广播应用，则优选为测试驱动系统向至少一个TV设备提供电视信号，优选为DVB信号，其中，电视信号优选地适于向至少一个TV设备提供修改后的交互应用。此处，术语“DVB信号”是指被配置为传送数字电视的信号，诸如，尤其是DVB-T、DVB-T2、DVB-S、DVB-S2、DVB-C、DVB-C2等。优选地，DVB信号包括应用信息表(AIT)。通过这一思路，本发明提供了一种用于自动向至少一个TV设备提供修改后交互应用的特别有利的方法。在本实施例中，在至少一个TV设备上无需执行任何修改或调整。简单地将至少一个TV设备置于接收测试驱动系统提供的电视信号的常用操作模式下，其中，通过电视信号来提供修改后的交互应用。

在优选实施例中，测试驱动系统包括用于在至少一个TV设备上非透明地执行一系列用户交互步骤的红外发射器、无线电波发送器和/或网络连接模块。由于这一措施，可通过测试驱动系统来执行典型的用户交互步骤。无线电波发送器可以例如采用

标准。例如，若通过Api调用来控制在TV设备上运行的交互应用，则网络连接模块可适于发送这些HTTP Api调用，从而非透明地执行一系列的用户交互步骤。作为另一实例，若TV设备为标准键盘可导航的口袋电脑，则网络连接模块可被配置为发送模拟键盘信号至口袋电脑，从而非透明地执行一系列的用户交互步骤。

测试驱动系统可被配置为拦截至少一个TV设备的网络流量，以提供交互TV应用所请求的预定义版本的网络资源。

本发明的主题进一步为一种用于定义上述测试方法中使用的测试场景的方法，其中，该方法使用参考TV设备并且包括以下步骤：

b.向参考TV设备提供修改后的交互应用；

c.向参考TV设备提供手动用户输入信号，其中，测试定义助手库和/或测试驱动系统被配置为监控手动用户输入信号；

d.监控继步骤c中提供的手动用户输入信号之后的有关交互应用和/或参考TV设备的状态的信息；

e.定义测试场景对应的目标状态以及指定的用户交互步骤，其中，指定的用户交互步骤基于所监控到的手动用户输入信号，并且其中，目标状态基于在步骤d中获取的交互应用和/或参考TV设备的所监控到的状态。

参考TV设备优选为已经测试过交互应用的TV设备，其中，交互应用在该参考TV设备上正常运行。因此，参考TV设备可用于定义测试场景的目标状态以及对应的用户交互步骤。由于手动用户输入信号可简单地在参考TV设备进行定向，因此本发明方法高效、简单地定义了测试场景，其中，手动用户输入信号和交互应用和/或TV设备的目标状态能够被自动监控并用于定义测试场景。

本发明的主题进一步为一种适用于执行上述测试方法的测试系统，其中，系统包括：测试驱动系统以及至少一个TV设备。该至少一个TV设备包括交互应用，其中，测试定义助手库被集成至交互应用。测试定义助手库被配置为获取有关交互应用和/或至少一个TV设备的状态的信息。此外，TDS被适配为通过在至少一个TV设备上非透明地执行一系列用户交互步骤来运行至少一个测试场景。系统进一步被适配为将测试定义助手库获取的有关交互应用和/或至少一个TV设备的状态的信息与在指定用户交互步骤之后的至少一个目标状态相比较。

优选地，测试驱动系统被适配为执行比较。

在优选实施例中，测试驱动系统包括翻译模块，被配置为将测试场景的用户交互步骤翻译成适应于至少一个TV设备中的每一个的用户输入信号。

进一步优选的是，测试驱动系统包括：执行单元，被配置为发射适于至少一个TV设备中的每一个的用户输入信号，其中，该执行单元优选包括红外发射器、无线电波发送器和/或网络连接模块。优选地，为至少一个TV设备中的每一个提供执行单元。

在另一实施例中，测试驱动系统进一步包括：学习单元，被配置为接收适于至少一个TV设备的手动用户输入信号，其中，测试驱动系统包括：转换模块，被配置为将手动用户输入信号转换成测试场景的用户交互步骤。

测试驱动系统可包括：广播单元，被配置为在至少一个TV设备上自动安装或提供修改后的交互应用，其中，交互应用优选为广播应用；其中，广播单元优选地向至少一个TV设备提供电视信号，优选为DVB信号；其中，电视信号优选地适于向至少一个TV设备提供修改后的交互应用。

上述与本发明方法相关的目的和有利效果同样适用于本发明系统。本发明系统可进一步通过已描述的与本发明方法相关的特征来进行开发。

应该认识到，通常可将本发明的思路应用到与其实施技术或目标平台无关的任何软件应用。但是，如当前独立权利要求所定义的，本发明明确限制了对在TV设备上运行的交互应用进行测试。

附图说明

下面结合附图及本发明优选实施例的示例性描述,本发明的特征、目的和优点将变得非常明显。在图中：

图1示出了本发明示例性实施例的示意图；

图2示出了本发明中心服务器用途的本发明的第二实施例的示意图；

图3示出了包括路由单元的第三示例性实施例的示意图；

图4示出了包括图像捕获单元的本发明的另一实施例的部分元件的示意图。

具体实施方式

本发明系统的示例性实施例如图1所示。系统的主要组件为测试驱动系统(TDS)14和测试定义助手库(TDHL)15，该测试定义助手库(TDHL)15集成至在TV设备18上运行的交互应用。

TDS14包括中心服务器24、控制单元21、执行单元20、翻译单元19、广播单元17、学习单元22以及转换模块23。图形用户界面(GUI)13在中心服务器24上运行，并且可通过网络进行访问。图1所示的TDS14的元件的局部布局仅为示例性布局，并不表示对这些元件实际位置的任何限制。

中心服务器24为网络服务器，驻留(host)着所有的TDS14软件。中心服务器24可分布在不同的物理计算机上，这些物理计算机可位于不同的地理位置。中心服务器24连接至控制TV设备18的控制单元21。控制单元21和TV设备18位于相同的IP网络中。如图2所示，中心服务器24可连接至不同组27的TV设备18，其中，每一组都由单独的控制设备(未示出)进行控制，并且其中，每一组27和相关控制设备都构成独立IP网络的一部分。多个测试操作员26可通过用户账号与中心服务器24连接，并同时在多组27TV设备18上进行测试操作。

返回图1，控制单元21控制所有TV设备18并且向中心服务器24报告。控制单元21创建和维持了至中心服务器24的持久性连接。在与用户账号配对之后，可侦听来自中心服务器24的命令并且将命令转发至控制单元21或其他位于不同IP网络的控制单元、或收集本地指标。当与路由单元(下面解释)串联使用时，可提供能够翻译域并且注入测试脚本的http代理。控制单元21可以为微型计算机，诸如Raspbery

但是，具有CPU架构的基于例如

x86或

和运行

或

的任何计算设备可被部署为控制单元。本领域技术人员应当认识到，任何现代家庭电脑都适应于作为控制单元21。

广播单元17用于广播包括应用信息表(AIT)的DVB信号，该DVB信号由TV设备18接收。TV设备18能够运行广播应用并且调谐至通过广播单元17广播的DVB信号。DVB信号包括交互应用，所述TDHL集成至该交互应用。由于DVB信号AIT内的自动启动记录，因此包括TDHL的交互应用自动在TV设备18上启动。本领域技术人员应当认识到，存在至少一种通过将静态AIT和特别制作的自动启动应用(连接至TDS14并且然后本身以TDS14的名义启动目标应用)一起使用来达到此的其他方式。本发明的广播单元可以为电缆/陆地调制器，诸如DekTec

或具有上述能力的其他任何设备。

TDHL15为这样的软件组件：能够检查交互应用的运行时间和/或查看应用的对象；侦听、收集和/或传输应用导致的网络流量至TDS；侦听和/或收集和/或传输应用的控制台输出至TDS；在设备屏幕上执行呈现(rendering)的屏幕截图或视频捕获和/或将其传输至TDS14。在一些实施例中，TDHL15可以利用可用的平台工具在正在测试的应用外部执行检查和测量，例如，检查共享内存或系统内部。TDHL15被写成、编译和/或转译成正在测试的交互应用平台所支持的语言。例如，广播应用的TDHL15被写成、编译和/或转译成Java脚本。TDHL15的另一特征是对TV设备18和在此设备上运行的交互应用没有任何限制。

GUI13为基于网络的图形用户界面应用，但在其他实施例中可以为能够在个人电脑或类似设备上运行的任何其他类型的应用。GUI13用于定义用户交互步骤以及完整的测试场景。GUI13通过中心服务器24与控制单元21通信。GUI13通常不直接和系统的其他组件通信。GUI13可以基于历史测试执行以及统计情况提供用于执行高级数据分析的构件。GUI13为图形用户界面应用，并且可用于：创建和管理测试案例、查看测试结果并报告、查看测试记录、管理当前在系统中的设备或添加新的设备、和其他用户分享设备、管理app配置和基于之前测试和机器学习算法的自动测试创建。

GUI13允许采用下面描述的自然测试语言创建测试。在一些实施例中，GUI13同样可允许添加除上述外的不同类型的测试，例如，单元测试或集成测试。GUI13直接与TDS14交互。在一些实施例中，GUI13可帮助测试操作员自动创建测试条件。测试操作员打开GUI13并且打开在TV设备18上的待测试的应用。测试操作员按下GUI13中的“选择视图元素”，其触发元素选择模式。在元素选择模式中，GUI13可能使测试操作员选择特殊视图元素并且自动检索当前属性。如果是在个人电脑或类似设备上启动GUI13，则在一些实施例中，按下“选择视图元素”可能致使附着在PC(GUI13在其上运行)上的鼠标运动与TV设备18上的视觉指示器的运动匹配。点击鼠标按钮可检索所述指示器当前指向元素的属性。在一些实施例中，可能给定测试操作员选项，以指定选择器字符串(用于在应用视图树内识别视图元素)。若正在测试的应用为基于HTML的应用，则该字符串可以为CSS或XPath选择器字符串。可选地，字符串可以是由TDHL15或底层平台识别的任意格式。

GUI13同样可以向用户提供TDHL15自动预选的或测试操作员手动保存的视图元素的储存库。然后，可在应用中突出显示所选的视图元素，从而向测试操作员提供更好的定向(orientation)。本领域技术人员应当认识到，存在有许多选择特定视图元素的其他方式。

GUI13可进一步提供测试的历史和对比分析的构件。特别地，可提供工具以全自动化地或部分自动化地确定应用启动失败的点以及导致该失败的原因。在一些实施方式中，GUI13可生成文本报告和图形报告并且允许更深入地了解测试结果和应用内部。

GUI13同样可作为应用调试和/或开发工具。例如，GUI13可提供在查看应用所导致的网络流量及其控制台输出的工具的同时，提供启动应用的工具。GUI13通过仅让TDHL15执行应用的检验程序就可全自动地报告应用中的错误或潜在错误。

在一些实施例中，GUI13同样可提供在一个或多个TV设备上迭代(一步一步地)运行测试或一次性执行所有测试的构件。GUI13同样可提供在一个或多个TV设备上远程或本地安排测试执行的构件。

在一些实施例中，GUI13同样可提供在设备上同步测试进程和应用状态的构件。本领域技术人员应当认识到，测试(任何UI测试)在本质上是一系列修改应用状态的用户输入步骤。GUI13或许可以警告测试操作员TV设备18上的应用的状态是否与GUI13内部的测试进程对应。

在通过GUI13定义用户交互步骤之后，TDS14的翻译模块19将用户交互步骤翻译成适应于至少一个TV设备中每一个的用户输入信号。该用户输入信号被转发至执行单元20，每一个所述执行单元20都包括红外发射器。红外发射器能够发射可由TV设备18接收的、940nm长的红外波。通过红外发射器将用户输入信号发射至TV设备18。通过用户输入信号改变交互应用和/或TV设备18的状态。在其他一些实施例中，执行单元20可进一步地或可选地包括配置为发射用户输入信号至TV设备18的

发射器和/或网络连接模块。

执行单元20进一步包括能够通过接口(诸如，USB、以太网、无线网络、

)连接至控制单元21的接口。

本领域技术人员应当认识到，执行单元20可能需要附加模块或可能仅是软件。例如，若通过HTTP Api调用来控制TV设备，则执行单元20可以为在控制单元21上运行的一个软件。另一实例：若设备可通过标准键盘来导航，则控制单元21可包括键盘模拟控制器。另一实例：若TV设备的远程控制是基于

标准，则本发明可使用配置有可编程

接口的执行单元20。

测试语言

每一测试都由一定步骤组成。每一步骤都可采用综合性的、人类可读的语言来表示。测试的目的是对QA过程中实际测试仪的实际行为进行建模。假设MyApp为响应于导航光标按钮的app。此处为导航测试的实例，具有7个步骤：

1.打开MyApp或在5000ms之后超时而失败；

2.按按钮“下”一次；

3.按按钮“右”三次；

4.若不存在“视频片头(video teaser)”，则测试失败；

5.若“视频片头”背景颜色不等于rgba(0，0，0，1)，则测试失败；

6.按按钮“是”一次；

7.等待直到出现元素“视频播放器”或在5000ms之后超时而失败。

从测试定义明显看出，该示例性简单测试的目的是打开app，执行4次按钮按下，验证元素“视频片头”的存在并且最后检查是否具有正确的背景颜色。然后，按下“是”按钮并且将出现期望的视频播放器。

应当认识到，该测试定义适用于任何TV设备平台上的任何交互应用。该测试所做的唯一假设是应用响应于导航按钮。本发明系统的一些实施例可制定适用于包括特定平台导航规定的导航条款。

本发明GUI13通常可像上述一个实例来精确定义测试。操作员可通过选择修改步骤(从非常通用到非常狭小)的选项来定义每一步。例如，创建具有测试条件的步骤：

1.操作员按下按钮“添加条件步骤”。

2.在测试案例中插入以下步骤：若[条件]，则[继续测试]。

3.操作员点击[条件]并且在适当选项中选择条件类型。基于平台和正在测试的应用类型，选项的精确选择会有所不同。但是应当认识到，可用条件在此基础之上允许描述应用的任何当前状态。例如，就基于网络的应用而言，列表将不限于以下：[查看元素、视频播放器、页面位置、变量值]。为了示例，假设操作员选择的[条件]是[视频播放器]的值。

4.像这样变换步骤：若[视频播放器][具有][属性]，则[继续测试]。

5.操作员可如步骤3中扩展[条件]部分一样以相同方式扩展[属性]部分。如果必要的话，也可改变[具有]部分。假设操作员针对[属性]选择属性“状态”。

6.像这样变换步骤：若[视频播放器][具有][状态][等于][停止]，则[继续测试]。GUI试着尽可能自动完成从而减少操作员的努力，因此将在“播放”填写背景颜色当前状态的值。通过步骤6，条件被完全扩展并且操作员可继续测试案例中的下一步。

本发明使操作者能够定义例如若条件结果为真，则应视步骤为成功。这由[继续测试]部分控制。操作员能将此改变成继续测试、测试失败、停止测试、发出警告中的一个。

测试定义

示例性系统中的每一测试案例都可基于单一规则。假设应用的内容数据保持不变，则和应用的任意用户交互固定顺序都必须使应用在执行后在每一目标设备上进入相同的状态。即，若用户对应用进行了相同的事情，则应返回该用户相同的结果。

测试定义过程假设测试操作员自行决定具有“参考TV设备”。例如，TV设备18中的一个可以为参考TV设备。可选地，参考设备可连接至除TV设备18之外的系统。在参考TV设备上，待测试应用运行无误。具有至少一个这种设备通常是必要的，原因在于如果不依赖于应用状态，那么测试步骤就没有任何价值。

应当认识到，本发明能将特定测试步骤和应用和/或TV设备18对应的状态进行同步。应当认识到，GUI13可使测试操作员快速前进或倒回任何测试步骤并且在TV设备18上查看应用状态。这是本发明非常重要的特征，原因在于测试操作员基于应用的捕获状态正在编辑测试案例，捕获状态是测试步骤唯一可靠的信息来源。

示例性系统进一步允许在每次交互之后记录引向至应用和/或参考TV设备18的手动用户输入信号以及应用和/或TV设备的状态。换言之，可通过像终端用户相同的方式简单地利用应用来记录测试案例。为启动记录，测试操作员在参考TV设备上打开包含TDHL15的应用，在GUI13登录自己的账户并且在GUI13中按下“启动记录测试”按钮。这激活了TDHL15中的监视功能，其在每一手动用户输入信号传递(pass over)至应用之前，拦截每一手动用户输入信号，并在此次交互之后检查应用状态。TDHL15将其结果发送至TDS14，继而TDS14转发结果至GUI13。因此，即刻就会在GUI13内部出现测试案例的新步骤。

在一些情况下，TDHL15可能无法拦截手动用户输入信号。因此，示例性TDS14进一步包括被配置为接收手动用户输入信号的学习单元。该手动用户输入信号可以为，例如，光学信号(诸如，通过传统远程控制发送的红外信号)、HTTP Api调用或标准键盘输入信号。接收到的信号转发至转换模块23，从而将信号转换成对应的用户交互步骤。此外，在每次手动用户输入之后，应用的状态由TDHL15进行监控并转发至控制单元21。通过将用户交互步骤与应用的监控状态相结合，可创建测试场景。

学习单元22为电子装置，该电子装置可包括以下进一步的元件：

-能够通过USB、以太网、Wi-Fi、

中的任何一个连接至控制单元21的接口或任何其他接口；

-光学传感器，其可由测量载波频率的传感器或分别过滤不同载波频谱的一组传感器补充(complemented)；

-用于处理光学传感器捕获的数据的微控制器。

如上所述，特定TV设备18可能的特征在于可替换传统远程控制的控制方法。例如，TV设备18或许可以响应通过HTTP发送的API命令。因此，学习设备22同样能够接收这些可替换的控制方法。本发明的每一个控制单元21都可利用特定设备组中的一个或多个学习单元22。

此外，示例性实施例的TDHL15记录了测试记录会话过程中出现的其他事件：数据通信、操作系统运行时变化、存储器状态等。为了获得最大精确度，TDHL15过滤出用户交互(具有发生过于频繁(每秒数百次)的app或事件)本不可能导致的事件。这些事件可在记录的测试案例中记录为单独的步骤。

测试操作员可删除或修改记录的一部分，以进一步强化或扩展测试。测试操作员同样可通过直接选择定义参考元素。

应当认识到，示例性实施例采用了预测建模算法和模式识别，以基于静态输入参数自动创建测试。例如，标记应用的特定元素将使TDHL15发现其“同族”(siblings)(即具有相似属性的元素)，重复初始针对标记元素(适应于同族环境)定义的行为并且针对运行结果是否正确执行智能猜测。另一实例：若一定顺序的用户输入致使应用失败一次，则TDHL15将能够检测出经过相同或类似用户输入顺序可能应用再次失败的情形。在这种情况下，TDHL15计算统计变量，确定最可能失败的场景。因此在无监督下，TDHL15生成综合测试执行计划，以包含可能失败的用户输入场景。

应当认识到，示例性实施例能够控制与上述不同的测试的执行。例如，系统能够执行并且收集单元测试、集成测试或其他类型的由软件开发人员/QA人员通常创建的测试的结果。

测试执行

虽然每个平台的测试原理相同，但每个平台的实际测试执行却各不相同，并且用于控制过程的系统的复杂性也大相径庭。示例性实施例的TDS14组件将平台差异进行封装，提供了统一的应用程序接口(API)，用于并行控制特定平台的任意数量的TV设备18。示例性TDS15可执行以下方法：安装应用、启动应用、发送用户输入(按键事件、鼠标事件、触摸事件、其他HID事件)、删除(destroy)应用、从应用失败中恢复、报告应用状态、重新启动/重新初始化设备、报告组件状态、报告运行时状态、运行壳(shell)或平台特殊命令。

在测试执行部分，TDS通常将参考TV设备(用于测试定义)和测试设备(用于待测试案例的独自的(unattended)执行)予以区别。参考TV设备的功能如上所述。应当认识到，API方法同时对任意数量的测试TV设备18有效，并且设备可在任意时间点加入和离开设备池而不影响TDS14的运行。应当认识到，本发明允许TV设备18自由加入测试设备池。一组测试设备例如在相同(IP)网络上也称为“设备园”(equipment zoo)。

TV设备18组成的设备园由控制单元21控制，该控制单元21为具有预装软件的专用电脑，预装软件为TDS14的一部分。在这种情况下，控制单元21也称为园管理员(zoomaster)。园管理员和其他园成员在相同的网络上。例如，Raspberry

可用作园管理员。取决于平台，可要求额外的硬件和软件来管理与园成员相关的应用。进一步地，系统或许可以在终端用户不使用设备时利用终端用户的设备来执行测试。

具体示例实施例

在下文中，术语“模拟器”是指模拟某一TV设备行为的计算机软件。本领域技术人员应当了解，硬件制造商的惯例是发行虚拟机，该虚拟机包含了在TV设备上安装的相同的软件。“模拟器”应指该虚拟机。

在下文中，术语“平台”是指离开生产场地(manufacturing premises)预安装在设备上的软件以及该软件修改后的版本。例如，这包括设备固件、操作系统或安装在设备上的特殊应用集。单个物理设备可安装并且支持一个或者多个平台。

本发明支持不同类型的TV设备18，这些设备位于不同的地理位置并且为不同用户或实体所有。

图3描述了本发明的进一步实施例。在图3的实施例中，TDS14包括路由单元30和网络中间件单元31。路由单元30为特殊配置的网络路由设备。TV设备18通过以太连接(实线)或通过无线网络连接32连接至路由单元。路由单元30反过来连接至控制单元21并且进一步连接至中心服务器24。TV设备18和控制单元21和/或中心服务器24之间的网络流量流经路由单元30。路由单元30可检查网络流量并且以控制单元21和/或中心服务器的名义收集ip地址、mac地址、欺骗(spoof)的DNS记录，重写目的ip或提供VPN服务。

路由单元30包括运行

或

的开放式API。路由单元30被配置为自动向在TV设备18上运行的交互应用提供TDHL15(未示出)，从而省去手动开发人员的努力。

进一步地，图4实施例的TDS14包括网络中间件单元31。该网络中间件单元31用作路由单元30的补充，但在其他一些实施例中，网络中间件单元31同样可以用作路由单元30的替代选择。网络中间件单元31包括专用软件，该专用软件允许至少部分流量拦截和检查。网络中间件单元提供交互TV应用请求的预定义版本的网络资源。实现方法如下：

在GUI13(未示出)内部，用户将指定待测试应用的URL；此外，用户在测试该应用时将表明应当部署网络中间件单元。在这种情况下，中心服务器24将与网络中间件单元31协商网络地址映射。例如，考虑在域example.com上运行的并且使用来自a.example.com和b.example.com的资源的app。进一步地，假设域*.invention.tld被设置为解决相同网络中间件单元31的IP地址。

因此，基于来自中心服务器24的请求，网络中间件单元31能够为这些实例域创建以下映射：

example.com x.invention.tld

a.example.com y.x.invention.tld

b.a.example.com z.y.x.invention.tld

中心服务器24将通过以上表格管理自身。当启动example.com的测试时，将指导TV设备从上述映射打开对应的域，在这种情况下为x.invention.tld。由于中心服务器24解析网络中间件单元31，因此请求将到达网络中间件单元31。网络中间件单元31将x.invention.tld识别成为自身生成的、并且执行至example.com(映射中对应的域)的网络请求，从而从该资源获取数据。在检索数据之后，将在数据内使用x.invention.tld替换所有example.com事件。将进一步根据上述表格执行替换。

本领域技术人员应当认识到，本方法将致使example.com的资源以及所有相关及关联的资源都将以x.invention.tld的别名(根据表格中所述的映射)发送至TV设备。

图4示出了本发明进一步实施例的几个元件。为每个TV设备18设置执行单元20。执行单元20连接至控制单元21。进一步地，学习单元与控制单元21连接。

与图1的实施例相比，图3的实施例包括几个图像捕获单元25，每一个图像捕获单元都专用于TV设备18。图像捕获单元25为安装为允许拍摄TV设备18屏幕的摄像头设备。图像捕获单元25将捕获的图像数据传回至控制单元21，该控制单元21进一步发送该捕获的图像数据至中心服务器24(未示出)。控制单元21或中心服务器24将捕获的图像分派给当前进程中的测试结果。通常，本发明不执行图像识别，也不从图像数据中挖掘任何数据。图像仅用于说明测试周期。但在其他一些实施例中，图像数据可用作相关交互应用和/或至少一个TV设备的状态的额外信息源。这就是说，除通过本发明TDHL获取信息外，通过对图像数据进行图像识别或其他类型的数据挖掘都可获得进一步的信息。

本发明的一些实施例同样支持不用屏幕来从设备(诸如机顶盒)捕获图像。

示例性实施例的部分或所有元件都可组合成单个电子设备，从而安装更为便宜或更为容易。

例如，控制单元21和执行单元20可以组合，例如通过将红外发射器和用作控制单元21的Rasberry

相结合。学习单元21和执行单元20可以组合。在这种情况下，它们分享着相同的微控制器和通信协议，并且组合后的设备可以具有传感器和发射器。若控制单元21具有一个以上的网络接口，则路由单元30可集成至控制单元21。例如，如果控制单元21为具有指向测试设备的网络摄像头的笔记本电脑，则图像捕获单元21同样可集成至控制单元21。

Claims

1.一种用于根据至少一个测试场景在至少一个TV设备（18）上测试交互应用的方法，其中，所述测试场景通过与所述至少一个TV设备（18）分离的测试驱动系统（14）来运行和监控，其中，所述测试场景包括一系列用户交互步骤以及在指定用户交互步骤之后要实现的所述交互应用和/或所述至少一个TV设备（18）的至少一个目标状态；所述方法包括以下步骤：

a.将测试定义助手库（15）集成到所述交互应用中，其中，所述测试定义助手库（15）被配置为获取有关所述交互应用和/或所述至少一个TV设备（18）的状态的信息，其中通过将所述测试定义助手库集成到所述交互应用中来修改所述交互应用，以提供修改后的交互应用；

b.向所述至少一个TV设备（18）提供修改后的交互应用；

c.运行所述至少一个测试场景，其中，所述测试驱动系统（14）在所述至少一个TV设备（18）上非透明地执行所述一系列用户交互步骤，其中，由所述测试驱动系统非透明地执行的所述用户交互步骤与由所述TV设备的终端用户生成的相应的用户交互步骤不可区分；以及d.通过测试定义助手库TDHL获得关于所述交互应用或所述至少一个TV设备的状态的信息，其中所述信息包括关于所述交互应用的运行时对象的信息；

e.将由所述测试定义助手库（15）获取的有关所述交互应用和/或所述至少一个TV设备（18）的状态的信息与在所述指定用户交互步骤之后的所述至少一个目标状态相比较, 其中所述交互应用是智能TV应用或广播应用。

2.根据权利要求1所述的方法，其特征在于，由所述测试定义助手库（15）获取的数据被传输至所述测试驱动系统（14），其中，在步骤e中的所述比较由所述测试驱动系统（14）来执行。

3.根据权利要求1或2所述的方法，其特征在于，由所述测试定义助手库（15）获取的有关所述交互应用和/或所述至少一个TV设备（18）的状态的信息包括以下至少之一：

TV设备标识值；

有关所述交互应用的运行对象的信息；

有关所述交互应用的视图对象的信息：

有关所述交互应用引起的数据流量的信息：

所述交互应用的控制台输出；

操作系统运行时间变化；和/或

共享的存储器状态。

4.根据权利要求1所述的方法，其特征在于，所述测试驱动系统（14）包括将所述测试场景的所述用户交互步骤翻译成适于所述至少一个TV设备（18）中的每一个的用户输入信号的翻译模块（19）。

5.根据权利要求1所述的方法，其特征在于，所述测试驱动系统（14）被配置为在所述至少一个TV设备（18）上自动安装或提供所述修改后的交互应用。

6.根据权利要求5所述的方法，其特征在于，所述交互应用为广播应用；其中，所述测试驱动系统（14）向所述至少一个TV设备（18）提供电视信号；其中，所述电视信号被适配为向所述至少一个TV设备（18）提供所述修改后的交互应用。

7.根据权利要求1所述的方法，其特征在于，所述测试驱动系统（14）包括用于在所述至少一个TV设备（18）上非透明地执行所述一系列用户交互步骤的执行单元（20），其中，所述执行单元（20）包括红外发射器、无线电波发送器和/或网络连接模块。

8.根据权利要求1所述的方法，其特征在于，所述测试驱动系统（14）被配置为拦截所述至少一个TV设备（18）的网络流量，以提供所述交互应用请求的预定义版本的网络资源。

9.根据权利要求6所述的方法，其特征在于，所述电视信号为DVB信号。

10.一种用于定义在根据权利要求1至9中的一项所述的方法中使用的测试场景的方法，其中，所述方法使用参考TV设备（18）并且包括以下步骤：

a.将测试定义助手库（15）集成到交互应用中，其中，所述测试定义助手库（15）被配置为获取有关所述交互应用和/或所述参考TV设备（18）的状态的信息；

b.向所述参考TV设备（18）提供修改后的交互应用；

c.向所述参考TV设备（18）提供手动用户输入信号，其中，所述测试定义助手库（15）和/或所述测试驱动系统（14）被配置为监控所述手动用户输入信号；

d.监控继步骤c中提供的所述手动用户输入信号之后的有关所述交互应用和/或所述参考TV设备（18）的状态的信息；

e.定义所述测试场景对应的目标状态以及指定的用户交互步骤，其中，所述指定的用户交互步骤基于所监控到的手动用户输入信号；并且其中，所述目标状态基于在步骤d中获取的所述交互应用和/或所述参考TV设备（18）的所监控到的状态。

11.一种被适于执行根据权利要求1至9中的一项所述的测试方法的测试系统，包括测试驱动系统（14）以及至少一个TV设备（18），

其中，所述至少一个TV设备（18）包括交互应用，其中，测试定义助手库（15）被集成至所述交互应用，其中，所述测试定义助手库（15）被配置为获取有关所述交互应用和/或所述至少一个TV设备（18）的状态的信息；

其中，所述测试驱动系统（14）适于通过在所述至少一个TV设备（18）上非透明地执行所述一系列用户交互步骤来运行所述至少一个测试场景；

其中，所述系统进一步适于将由所述测试定义助手库获取的有关所述交互应用和/或所述至少一个TV设备（18）的状态的信息与在指定用户交互步骤之后的至少一个目标状态相比较。

12.根据权利要求11所述的测试系统，其特征在于，所述测试驱动系统（14）适于执行所述比较。

13.根据权利要求11或12所述的测试系统，其特征在于，所述测试驱动系统（14）包括翻译模块（19），所述翻译模块（19）被配置为将所述测试场景的所述用户交互步骤翻译成适于所述至少一个TV设备（18）中的每一个的用户输入信号。

14.根据权利要求11所述的测试系统，其特征在于，所述测试驱动系统（14）进一步包括执行单元（20），所述执行单元（20）被配置为发射适于所述至少一个TV设备（18）中的每一个的用户输入信号，其中，所述执行单元（20）包括红外发射器、无线电波发送器和/或网络连接模块。

15.根据权利要求11所述的测试系统，其特征在于，所述测试驱动系统进一步包括学习单元（22），所述学习单元（22）被配置为接收适于所述至少一个TV设备的手动用户输入信号，其中，所述测试驱动系统包括转换模块（23），所述转换模块（23）被配置为将所述手动用户输入信号转换成所述测试场景的用户交互步骤。

16.根据权利要求11所述的测试系统，其特征在于，所述测试驱动系统（14）包括广播单元（17），所述广播单元（17）被配置为在所述至少一个TV设备（18）上自动安装或提供修改后的交互应用；其中，所述交互应用为广播应用，其中，所述广播单元（17）向所述至少一个TV设备（18）提供电视信号；其中，所述电视信号适于向所述至少一个TV设备（18）提供所述修改后的交互应用。

17.根据权利要求16所述的测试系统，所述电视信号为DVB信号。