ES3023333T3

ES3023333T3 - Device testing arrangement

Info

Publication number: ES3023333T3
Application number: ES21701833T
Authority: ES
Inventors: Jari Nurminen
Original assignee: Segron Automation S R O
Current assignee: Segron Automation S R O
Priority date: 2020-02-05
Filing date: 2021-02-02
Publication date: 2025-05-30
Anticipated expiration: 2041-02-02
Also published as: EP4100837C0; PL4100837T3; EP4100837B1; EP3862884A1; US20230050723A1; EP4100837A1; WO2021156243A1

Abstract

Un sistema para pruebas automatizadas de dispositivos móviles que comprende un sistema de aprendizaje para aprender a usar dispositivos de prueba que no se ajustan a un patrón de caso de prueba previamente definido. En el sistema, el sistema de aprendizaje genera instrucciones para realizar un conjunto de tareas. Estas tareas se ejecutan en el dispositivo móvil que se está probando. El dispositivo móvil proporciona retroalimentación en forma de mensajes de error/éxito, capturas de pantalla, código fuente, valores de retorno, etc. Con base en la retroalimentación y la información acumulada previamente, la entidad de aprendizaje puede generar un nuevo conjunto de instrucciones para ejecutar las tareas correctamente. (Traducción automática con Google Translate, sin valor legal)

Description

DESCRIPCIÓN

Disposición de prueba de dispositivos

La presente divulgación se refiere a la prueba de dispositivos y, en particular, a la prueba de una funcionalidad de red de diversos tipos de dispositivos mediante un enfoque de prueba automática.

Los dispositivos vendidos a usuarios finales y otros clientes empresariales suelen someterse a pruebas. Dependiendo de la categoría del dispositivo, las pruebas pueden realizarse para todos los dispositivos producidos o realizándose una selección aleatoria para las pruebas. Cuando se realizan pruebas para un gran número de dispositivos, suelen utilizarse enfoques de prueba automática.

Cuando se prueba un dispositivo móvil tal como un teléfono móvil o un dispositivo similar conectado a una red de comunicaciones móviles, la disposición de prueba suele estar configurada para realizar una secuencia de pruebas que comprende una pluralidad de funciones deseadas. Estas pueden tener por objeto funcionalidades que se ejecuten por completo en el dispositivo o funcionalidades que interactúen con la red u otros dispositivos. Un ejemplo de las primeras es el cambio de ajustes del dispositivo móvil y un ejemplo de las segundas es la realización de una llamada a otro dispositivo móvil. Puesto que los dispositivos móviles son complicados, tienen un número elevado de casos de uso diferentes que hay que probar. Por ejemplo, al probar la conectividad de la red de prueba puede ser necesario probar las llamadas, el envío de mensajes y la conexión a Internet utilizando varias tecnologías de red diferentes (por ejemplo, 4G, 5G, wifi). En consecuencia, aumenta el número de casos que hay que probar.

La verificación de la conectividad de la red aumenta la complejidad de la disposición de prueba, ya que las redes de comunicación modernas son muy complejas y pueden configurarse de muchas formas distintas. Esto aumenta aún más el número de casos que hay que probar, puesto que el alcance de las pruebas debe tener en cuenta los servicios suscritos (por ejemplo, los usuarios de prepago y a los que se les factura a posteriori), las tecnologías de red y la configuración de la red (por ejemplo, si el usuario tiene activo un servicio de datos de alta velocidad). Esto también añade complejidad a la arquitectura de la disposición de prueba. A modo de ejemplo: los dispositivos tienen que estar registrados en la red objetivo (es decir, la red que se está probando), por ejemplo, se necesita una tarjeta SIM del operador de red y el dispositivo se encuentra en una ubicación con cobertura de la red objetivo. Para verificar distintos aspectos de la conectividad de la red, pueden ser necesarias diversas ubicaciones.

Los dispositivos móviles modernos varían desde los integrados (por ejemplo, chips IoT) hasta pequeños ordenadores que disponen de un sistema operativo y, a menudo, de una interfaz gráfica de usuario para él. Mediante las interfaces del sistema operativo y la interfaz gráfica de usuario, el usuario puede controlar el dispositivo de diversas maneras. Esto aumenta aún en mayor medida el número de posibles casos de uso. Cuando estos modernos dispositivos móviles se prueban en un entorno de prueba de gran volumen, es fundamental que el entorno de prueba automatizado pueda realizar todas las pruebas. Sin embargo, este puede no ser siempre el caso. Por ejemplo, la actualización del sistema operativo puede tener cambios deseados y no deseados en el comportamiento del dispositivo. Si la interfaz de usuario se ha modificado, la funcionalidad no se puede encontrar desde la misma ubicación y, en tal caso, el entorno de prueba automatizado no puede realizar la prueba. En algunos casos, las pruebas pueden ser realizadas por un técnico o ingeniero de pruebas; sin embargo, si los objetos probados vienen en grandes volúmenes, puede ser necesario cambiar el entorno de prueba.

La publicación de MEHMET CAGRI CALPUR Y OTROS «Hacia la consecución de una nube de dispositivos móviles especializada en las pruebas de software», INGENIERÍA Y SISTEMAS MÓVILES DE SOFTWARE, ACM, 2 PENN PLAZA, SUITE 701 NUEVA YORK NY 10121-0701 EE.UU., 14 de mayo de 2016, páginas 9-10, , divulga una plataforma de pruebas en la nube novedosa especializada en pruebas de software.

La publicación de THI ANH TUYET VUONG Y OTROS «Un enfoque basado en el aprendizaje por refuerzo para las pruebas automatizadas de las aplicaciones Android», ACTAS DEL 9° TALLER INTERNACIONAL ACM SIGSOFT SOBRE LA AUTOMATIZACIÓN DEL DISEÑO, LA SELECCIÓN Y LA EVALUACIÓN DE LOS CASOS DE PRUEBAS, A-TEST 2018, 5 de noviembre de 2018, LAKE BUENA VISTA, FL, EE.UU., 1 de noviembre de 2018 (01-11-2018), páginas 31-37, Nueva York, Nueva York, EE.UU., divulga una disposición para realizar pruebas automáticas de aplicaciones móviles con el menor esfuerzo humano posible.

El documento US 8924938 divulga un sistema y un método para analizar un programa informático que incluye realizar un análisis estático en un programa para determinar la corrección de propiedades.

El documento US 2012/198279 divulga técnicas para probar un dispositivo. En algunas implementaciones, se recibe en un servidor una solicitud para llevar a cabo una instrucción de prueba en uno o más de una pluralidad de dispositivos informáticos. La instrucción de prueba puede estar configurada para probar una aplicación o función asociada al o a los dispositivos informáticos.

La publicación de ISABEL K VILLANES ROJAS Y OTROS «Marco para probar apps móviles basadas en la nube», PRUEBAS SISTEMÁTICAS Y AUTOMATIZADAS DE SOFTWARE, ACM, 2 PENN PLAZA, SUITE 701 NUEVA YORK NY 10121-0701 EE.UU., 19 de septiembre de 2016 (19-09-2016), páginas 1-10, , divulga una disposición para probar aplicaciones móviles.

RESUMEN

Se divulga una disposición para probar dispositivos móviles de manera automatizada. La disposición comprende una disposición para aprender a utilizar dispositivos de prueba que no coincidan con las pruebas ya realizadas con anterioridad. En la disposición, el algoritmo de aprendizaje genera tareas para realizar los pasos necesarios para automatizar

Para generar la configuración de automatización de pruebas de dispositivo, resulta beneficioso utilizar la disposición de aprendizaje, de modo que se pueda tener en cuenta la experiencia de dispositivos probados con anterioridad al generar la configuración de automatización de pruebas de dispositivo. La entidad de aprendizaje es capaz de aprender una solución cuando las instrucciones generadas con anterioridad no dan resultado. Además, puede realizar reintentos para una funcionalidad con una probabilidad mejorada de intentar la acción correcta, de modo que no sea necesario probar con todas las acciones posibles. El aprendizaje puede ser iterativo o cualquier otro aprendizaje tradicional por tanteo y, en implementaciones más avanzadas, el aprendizaje puede basarse, al menos parcialmente, en el aprendizaje automático.

En una implementación, el método comprende además transmitir la configuración de automatización de pruebas de dispositivo generada a un servidor de pruebas de dispositivo para probar una pluralidad de dispositivos móviles de conformidad con la configuración de automatización de pruebas de dispositivo generada. La configuración de automatización de pruebas de dispositivo transferible es beneficiosa, ya que no es necesario generarla en la entidad de prueba.

En una implementación, el método comprende además utilizar la retroalimentación recibida y la información generada con anterioridad como entrada en un algoritmo de aprendizaje automático para generar instrucciones para el dispositivo móvil. Es beneficioso utilizar la retroalimentación recibida para mejorar la probabilidad de elegir la funcionalidad correcta. La retroalimentación revela con facilidad, por ejemplo, que se trata de otro tipo de control y que debe utilizarse de otra manera.

En una implementación, se proporciona una pluralidad de instrucciones en un conjunto de instrucciones. Es beneficioso tener la posibilidad de proporcionar tareas en un solo conjunto, de modo que se pueda ejecutar una pluralidad de tareas si no se necesita retroalimentación de inmediato. Así se reduce la mensajería y el tiempo necesario para obtener la retroalimentación cuando se necesita.

En una implementación, se recibe retroalimentación como respuesta a uno o más conjuntos de instrucciones. Es beneficioso poder recibir retroalimentación sobre un conjunto de instrucciones en su totalidad. Esto reduce la mensajería, ya que a veces la retroalimentación solo se necesita para el último paso.

En una implementación, el método comprende además analizar la retroalimentación. Es beneficioso que se analice la retroalimentación para que las siguientes instrucciones se puedan generar con la ayuda de la retroalimentación más reciente.

En una implementación, la retroalimentación comprende una captura de pantalla del dispositivo probado. Es beneficioso disponer de capturas de pantalla, puesto que muestran el aspecto de la interfaz de usuario del dispositivo. Asimismo, algunas de las tareas no dan buen resultado aunque no se haya generado ningún mensaje de error. A partir de la captura de pantalla es posible determinar el estado aunque no se haya recibido ninguna otra retroalimentación.

En una implementación, la retroalimentación comprende un código fuente de una pantalla del dispositivo probado. El código fuente de la pantalla proporciona información exacta de la pantalla y de lo que aparece en ella.

En una implementación, la retroalimentación comprende salidas de los comandos ejecutados. Las salidas de los comandos comprenden información acerca de si la tarea se ha realizado correctamente o no. Los mensajes de error comprenden a veces una razón explícita por la que la tarea no ha tenido buen resultado.

En una implementación, la retroalimentación comprende un registro de dispositivo. La información de registro ofrece la posibilidad de analizar qué ha ocurrido en el dispositivo antes de la tarea actual. Puede ser necesario reconsiderar también los pasos anteriores, puesto que pueden estar causando el problema.

En un aspecto se divulga un programa informático. El programa informático comprende código de programa informático que está configurado para hacer que se lleve a cabo un método como el descrito anteriormente, cuando el programa informático se ejecuta en un dispositivo informático.

En un aspecto se divulga un aparato para generar una configuración de automatización de pruebas de dispositivo para un dispositivo móvil. El aparato comprende al menos un procesador configurado para ejecutar programas informáticos; al menos una memoria configurada para almacenar programas informáticos y datos relacionados; al menos una conexión de red para recibir y transmitir instrucciones a dispositivos externos; donde el aparato está configurado para realizar un método como el descrito anteriormente.

DESCRIPCIÓN BREVE DE LOS DIBUJOS

Los dibujos adjuntos, que se incluyen para proporcionar una mayor comprensión de la disposición de prueba de dispositivos y constituyen una parte de esta memoria descriptiva, ilustran formas de realización y, junto con la descripción, ayudan a explicar los principios de la disposición de prueba de dispositivos. En los dibujos:

la figura 1 es un diagrama de bloques de un ejemplo de una disposición de prueba de dispositivos, la figura 2 es un diagrama de flujo de un método según un ejemplo de una disposición de prueba de dispositivos,

la figura 3 es un gráfico de señalización que ilustra un ejemplo de señalización en una disposición de prueba de dispositivos,

la figura 4 es un ejemplo de proceso de aprendizaje de un dispositivo,

la figura 5 es un ejemplo de un caso de uso relacionado con la habilitación o deshabilitación del uso de datos móviles en un dispositivo móvil,

la figura 6 es un ejemplo de gráfico de señalización que divulga con más detalle el procedimiento para habilitar un conmutador, y

la figura 7 es otro ejemplo de señalización.

DESCRIPCIÓN DETALLADA

A continuación, se va a hacer referencia en detalle a las formas de realización, de las que se ilustran ejemplos en los dibujos adjuntos.

En la siguiente divulgación, el servidor de pruebas de dispositivo es una entidad de ejecución de pruebas que está conectada a uno o más dispositivos y que está ejecutando uno o más Paquetes de Pruebas. Puede haber una o varias entidades de ejecución de pruebas. La conexión es tal que puede ejecutar los comandos de prueba en el dispositivo probado. Puede tratarse de una conexión inalámbrica, por cable, un dispositivo de acoplamiento o similares.

El paquete de pruebas es una colección de casos de prueba cuyo objetivo es verificar un área funcional. Por ejemplo, el paquete de pruebas «Llamadas de voz móviles» comprende casos de prueba para probar la funcionalidad de las llamadas de voz.

Un caso de prueba es una colección de casos de uso cuyo objetivo es verificar un escenario funcional. Por ejemplo, un caso de prueba relativo a «Llamada de voz móvil a móvil en red 3G». Un caso de uso es una secuencia de pasos necesarios para alcanzar el objetivo del caso de uso. Por ejemplo, el caso de uso «Activar la red 3G» podría constar de los pasos «Abrir la aplicación de Ajustes», «Abrir el menú de modo de red», «Establecer la red preferida como solo 3G». Los casos de uso son los elementos básicos que los ingenieros de pruebas combinan para crear casos de prueba para diversos escenarios funcionales («Llamada 3G», «Llamada 4G», «A llama a B», «B llama a A», etc.). Una configuración de automatización de pruebas de dispositivo vincula los pasos abstractos del caso de uso a tareas específicas del dispositivo que logran el objetivo del caso de uso. Por ejemplo, en un dispositivo el paso «Abrir el menú de modo de red» podría consistir en navegar por submenús, por ejemplo «Conectividad», «Redes móviles», «Modo de red» y, en otro dispositivo, el «Modo de red» podría estar en la primera pantalla.

Al generar la configuración de automatización de pruebas de dispositivo, la disposición de aprendizaje de dispositivo envía instrucciones al dispositivo. La instrucción es un conjunto de tareas que se ejecutan en el dispositivo. La retroalimentación contiene los resultados de las instrucciones que se utilizan para generar la configuración de automatización de pruebas de dispositivo para un dispositivo determinado.

Las tareas comprenden comandos, instrucciones de computación, instrucciones o similares que son ejecutadas por un procesador o un dispositivo de procesamiento similar y que cuando se realizan juntas hacen que el dispositivo probado realice una acción solicitada.

En la figura 1 se muestra un diagrama de bloques de un ejemplo de disposición de prueba de dispositivos. En la figura 1 se muestra un servicio de aprendizaje de dispositivo 100 junto con un servidor de aprendizaje de dispositivo 110 y un servidor de pruebas de dispositivo 120. El servidor de aprendizaje de dispositivo 110 y el servidor de pruebas de dispositivo 120 están conectados al servicio de aprendizaje de dispositivo 100 mediante Internet 130 o una conexión de red de área local. La conexión puede ser al menos parcialmente inalámbrica y estar implementada mediante redes de comunicación móviles. En otro ejemplo, todas estas entidades están implementadas dentro de un dispositivo informático concreto; sin embargo, el ejemplo de la figura 1 proporciona más flexibilidad y la posibilidad de proporcionar más material de aprendizaje para el servicio de aprendizaje 100.

El servicio de aprendizaje de dispositivo 100 comprende al menos una unidad de procesamiento 101, al menos una memoria 102 y al menos una conexión de red 103. La al menos una unidad de procesamiento 101 puede ser un procesador de propósito general o una unidad de procesamiento que comprenda unidades de procesamiento de propósito especial. La al menos una unidad de procesamiento 101 está configurada para ejecutar programas informáticos y realizar tareas informáticas de conformidad con los programas informáticos ejecutados. La al menos una memoria 102 puede comprender memorias volátiles y no volátiles que estén configuradas para almacenar programas informáticos y datos relacionados durante el procesamiento. La al menos una conexión de red 103 puede comprender uno o más adaptadores de red que incluyan conexiones por cable e inalámbricas. Las implementaciones a modo de ejemplo del servicio de aprendizaje de dispositivo 100 incluyen una entidad de computación en la nube, un ordenador servidor o una entidad informática similar que está configurada para realizar las acciones solicitadas de conformidad con la siguiente descripción. La expresión computación en la nube debe interpretarse aquí con una funcionalidad equivalente a la de un servidor. De este modo, la entidad de computación en la nube que presta el servicio solicitado es capaz de proporcionar una funcionalidad similar a la de un servidor aportando capacidad de procesamiento y memoria para las necesidades de almacenamiento.

El servidor de aprendizaje de dispositivo 110 comprende al menos una unidad de procesamiento 111, al menos una memoria 112 y al menos una conexión de red 113. Estas pueden ser similares a los componentes correspondientes del servicio de aprendizaje de dispositivo. Sin embargo, la capacidad de procesamiento y la capacidad de memoria suelen ser inferiores en comparación con el servicio, ya que el propósito del servidor de aprendizaje de dispositivo 110 es conectar un nuevo dispositivo 114 que se ha de aprender al servicio de aprendizaje de dispositivo 100. El servidor de aprendizaje de dispositivo 110 lleva a cabo las instrucciones, que recibe del servicio de aprendizaje de dispositivo 100, en el dispositivo probado 114, y transmite los resultados como retroalimentación al servicio de aprendizaje de dispositivo 100. Por ejemplo, el servidor de aprendizaje de dispositivo 110 puede recibir del servicio de aprendizaje de dispositivo 100 instrucciones para llamar a un número o enviar un mensaje SMS a un número concreto. El servidor de aprendizaje de dispositivo 110 lleva a cabo estas instrucciones utilizando las interfaces adecuadas y obtiene retroalimentación, por ejemplo, en forma de mensajes de error y de éxito recibidos de una API y/o realizando una captura de pantalla que muestre el mensaje de error o de éxito. El dispositivo 114 se acopla al servidor de aprendizaje de dispositivo 110 a través de medios disponibles, tales como una conexión por cable o una conexión de red inalámbrica. Las interfaces apropiadas pueden incluir, por ejemplo, la adquisición de información sobre botones o elementos de menú situados en la pantalla y la elección del botón o elemento de menú con el contenido adecuado, como un título o subtítulo. Otro ejemplo consiste en analizar la pantalla y producir un toque simulado en la pantalla táctil en un lugar deseado. El toque simulado puede incluir también un gesto. Así, puede ser necesario transmitir una pluralidad de coordenadas a la API o entidad que recibe la entrada de la pantalla táctil y la traduce a un conjunto de coordenadas u otros medios de entrada. El servidor de aprendizaje de dispositivo 110 puede existir múltiples veces en la disposición de prueba.

El servidor de pruebas de dispositivo 120 es la entidad que está realizando las pruebas reales. El dispositivo móvil 124 está acoplado o conectado al servidor de pruebas de dispositivo 120. El servidor de pruebas de dispositivo recibe la configuración de automatización de pruebas de dispositivo del servicio de aprendizaje de dispositivo 100. Los casos de prueba, que utilizan la configuración de automatización de pruebas de dispositivo, comprenden secuencias de prueba que son ejecutadas por al menos un procesador 121 y los resultados se recogen en al menos una memoria 122. Las instrucciones se reciben utilizando al menos una conexión de red 123. El dispositivo 124 se acopla al servidor de pruebas de dispositivo 120 por medio de medios disponibles, tales como una conexión por cable o una conexión de red inalámbrica. La configuración de automatización de pruebas de dispositivo recibida del servicio de aprendizaje de dispositivo 100 puede almacenarse en la al menos una memoria 122 para su uso posterior. Por lo tanto, solo hay que recibirlas una vez del servicio de aprendizaje de dispositivo 100, o pueden recibirse múltiples veces a petición. La configuración de automatización de pruebas de dispositivo incluye información sobre cómo realizar las acciones necesarias con el dispositivo 124 probado. Por ejemplo, un subconjunto de la configuración de automatización de pruebas de dispositivo puede ser una secuencia de comandos necesarios para apagar el adaptador de red inalámbrico o activar el modo silencio. En tal caso, la secuencia comprende la apertura del menú correcto y la activación de un elemento de menú correcto desde allí. El servidor de aprendizaje de dispositivo 120 puede existir múltiples veces en la disposición de prueba.

Las secuencias de tareas se organizan de tal manera que cada tarea es una parte de un código de programa necesario para realizar un paso del caso de uso. Un caso de uso comprende una pluralidad de pasos. Así, las tareas requeridas para realizar un caso de uso incluyen normalmente tareas requeridas para realizar una pluralidad de pasos. Además de los comandos reales, las tareas pueden comprender información adicional tal como la ubicación de un botón. Por ejemplo, cuando el propósito de una tarea es provocar la pulsación de un botón, es necesario saber dónde está el botón. Si no se conoce la ubicación, puede ser necesario averiguar la ubicación del botón para poder adaptar la información para ese dispositivo concreto.

La disposición de memoria divulgada anteriormente puede utilizarse de varias formas diferentes. Por ejemplo, se le puede requerir manualmente a la disposición que descargue la configuración de automatización de pruebas de dispositivo a la al menos una memoria 122 para su uso posterior. Por otra parte, es posible utilizar la al menos una memoria 122 como memoria caché o almacenamiento temporal para la configuración de automatización de pruebas de dispositivo recuperada a demanda. En una implementación más avanzada, la al menos una memoria 122 almacena la configuración de automatización de pruebas de dispositivo para un uso posterior; sin embargo, el servidor de aprendizaje de dispositivo puede estar configurado para comprobar de manera automática si hay un conjunto actualizado de configuración de automatización de pruebas de dispositivo. Implementaciones más avanzadas pueden comprender una funcionalidad, donde la configuración de pruebas de dispositivo se almacene en la memoria y, cuando comience un evento de prueba, el servidor de pruebas de dispositivo compruebe si tiene la última versión de la configuración de automatización de pruebas de dispositivo. Si hay disponible una versión más reciente, entonces la configuración de automatización de pruebas de dispositivo puede recuperarse por completo o parcialmente de manera que se recupere la parte cambiada. En otra opción, la configuración de automatización de pruebas de dispositivo se recupera por partes. En tal implementación, se determina qué parte de la configuración de automatización de pruebas de dispositivo tiene que recuperarse. Esto resulta especialmente beneficioso cuando existe un número muy elevado de configuraciones de automatización de pruebas de dispositivo y las pruebas no implican utilizarlas siempre todas. En tales casos, se puede ahorrar memoria recuperando solo aquellas partes de una configuración de automatización de pruebas de dispositivo que realmente se necesitan.

Cuando el servidor de pruebas de dispositivo 120 realiza una prueba, todas las funciones deben obtener un buen resultado. Si el dispositivo 124 no realiza la acción solicitada, puede ser indicativo de que el dispositivo es defectuoso o funciona incorrectamente. Sin embargo, en algunos casos también puede tratarse de un pequeño cambio en el dispositivo, de modo que las antiguas secuencias de comandos ya no funcionen incluso aunque el dispositivo esté funcionando correctamente. El pequeño cambio puede ser intencionado o no, como un error. En este caso, el dispositivo puede ser reintroducido en el servidor de aprendizaje de dispositivo 110 con una solicitud para que se realice y se vuelva a aprender la prueba fallida.

Durante el proceso de aprendizaje, el dispositivo 114 que está acoplado o conectado al servidor de aprendizaje de dispositivo 110 recibe instrucciones que han sido determinadas por el servicio de aprendizaje de dispositivo 100. Así, el servicio de aprendizaje de dispositivo 100 está enviando instrucciones y espera recibir retroalimentación. Basándose en la retroalimentación recibida y en los datos ya acumulados de dispositivos aprendidos con anterioridad, la al menos una unidad de procesamiento 101 utiliza un algoritmo basado en el aprendizaje automático, o un algoritmo similar capaz de ajustar las instrucciones como respuesta a la retroalimentación, para determinar cómo debe requerirle al dispositivo que realice las tareas asociadas a un caso de uso, por ejemplo, cómo poner el dispositivo en modo silencio. Las instrucciones se adaptan mientras sea necesario para que la operación se ejecute con éxito.

La figura 2 muestra un ejemplo de método para una disposición de prueba de dispositivos. El método puede realizarse, por ejemplo, en un servicio de aprendizaje de dispositivo 100, donde la comunicación se realiza con un servidor de aprendizaje de dispositivo 110. El ejemplo de la figura 1 se menciona aquí solo como una opción y pueden utilizarse otras disposiciones similares para llevar a cabo el método.

El método se inicia mediante la recepción de una solicitud para que se genere una nueva configuración de automatización de pruebas de dispositivo, paso 200. La configuración de automatización de pruebas de dispositivo significa aquí una configuración que es necesaria para realizar pruebas de conformidad con uno o más casos de uso que también se reciben, paso 201. La configuración de automatización de pruebas de dispositivo incluye información sobre la configuración del dispositivo entre la que se incluye, por ejemplo, la información relativa a la ubicación de botones u otros comandos acerca de cómo se pueden ejecutar los casos de uso. Es posible que al realizar una función se puedan utilizar varias formas diferentes. En el contexto de esta solicitud, un caso de uso se refiere a una forma concreta de realizar una función o una acción. Por ejemplo, para desactivar los datos móviles puede ser necesario activar el menú de ajustes, escoger una red de un primer menú, escoger gestionar tarjetas sim de un segundo menú que se haya abierto como resultado de escoger la red del primer menú y, a continuación, finalmente desactivar los datos móviles desde el segundo menú. Puesto que los dispositivos móviles son complicados, hay cientos o incluso miles de casos de uso diferentes que deben probarse.

Para realizar una prueba de una función o acción deseada es necesario generar un conjunto de tareas para llevar a cabo la acción. Las tareas no pueden recuperarse directamente de una base de datos, ya que la configuración de automatización de pruebas de dispositivo se refiere a un nuevo caso que implica un dispositivo completamente nuevo o un dispositivo antiguo con modificaciones. El primer paso de generación 202 puede implicar la generación de un conjunto inicial de tareas para un caso de uso. A continuación, el conjunto inicial se adapta basándose en los dispositivos similares y, posteriormente, basándose también en la retroalimentación recibida del dispositivo, paso 203. El conjunto de tareas se proporciona entonces al dispositivo móvil para su ejecución, paso 204. El dispositivo móvil intenta ejecutar las tareas. Al ejecutarlas, es posible que se obtenga un resultado positivo, negativo o nada. El resultado positivo puede ser, por ejemplo, un mensaje de éxito o el inicio de una acción a partir de la cual pueda determinarse el éxito. El resultado negativo puede ser un mensaje de error o el inicio de una acción no deseada y a partir de la cual se pueda determinar un resultado negativo. También es posible que no ocurra nada, puesto que las tareas generadas provocaron un toque simulado en una ubicación que no está asociada a ninguna funcionalidad o la funcionalidad se deshabilitó sin respuesta. Esto suele interpretarse como un resultado negativo, ya que las tareas no consiguieron provocar un toque simulado en una ubicación correcta.

Las tareas ejecutadas y la retroalimentación recibida, paso 205, se proporcionan a un algoritmo de aprendizaje que intenta corregir las tareas basándose en el conocimiento obtenido de la retroalimentación recibida y la retroalimentación anterior relativa a dispositivos anteriores. Esto puede realizarse adaptando las tareas siempre que se consigan resultados positivos. Por tanto, si la retroalimentación no es positiva, el método vuelve entonces al paso 203 y adapta la información. El proceso de aprendizaje no tiene que aprender siempre todo desde cero. Por ejemplo, si un segundo caso de uso implica activar los mismos elementos de menú, tocar los mismos botones o similares, las tareas correctas son más fáciles de generar, puesto que ya se han aprendido la ubicación y la activación de la función o acción solicitada. Así, es posible combinar subsecuencias aprendidas durante casos de uso anteriores. Por último, la configuración de automatización de pruebas de dispositivo se almacena para su uso posterior, paso 206. Las configuraciones de automatización de pruebas de dispositivo almacenadas pueden recuperarse cuando los dispositivos reales se prueban en volumen.

En la figura 3 se muestra un ejemplo de secuencia de señalización de identificación de dispositivo. Se vincula o conecta un nuevo dispositivo al servidor de aprendizaje, que a su vez está conectado al servicio de aprendizaje de dispositivo. El servidor de aprendizaje utiliza las interfaces disponibles de la plataforma del dispositivo, tales como Android, iOS o Windows, para recuperar los datos del dispositivo. Estos datos pueden incluir el fabricante, el modelo, el hardware, la resolución de pantalla, el firmware y la versión del sistema operativo, aplicaciones instaladas y sus versiones. La SIM (módulo de identidad del abonado) también puede ser relevante para los datos del dispositivo, ya que tiene repercusión en las pantallas. Por ejemplo, algunos menús pueden tener etiquetas diferentes. Los datos del dispositivo son únicos para cada tipo de dispositivo.

En la figura, primero se envía una solicitud de conexión, paso 300. Como respuesta a una solicitud de conexión exitosa, el servidor de aprendizaje solicita información del dispositivo, paso 301. El dispositivo responde a la solicitud transmitiendo los datos del dispositivo al servidor de aprendizaje, paso 302. El servidor de aprendizaje reenvía esta información al servicio de aprendizaje de dispositivo, paso 303. El servicio de aprendizaje de dispositivo está configurado para analizar la información del dispositivo, paso 304.

El paso de análisis comprende analizar los errores de los ajustes del dispositivo, por ejemplo, la ausencia de la tarjeta SIM impediría probar muchas funciones de la red. El análisis comprende además el análisis de recomendaciones, por ejemplo, el dispositivo ya existe con otro ajuste de idioma-propone utilizar el idioma existente en lugar de aprender a utilizar el dispositivo con el idioma solicitado. El análisis también puede comprender el análisis de funciones opcionales que podrían estar habilitadas en el firmware del dispositivo, por ejemplo, VoLTE, VoWiFi o 5G. El análisis también puede incluir el análisis de problemas conocidos con dispositivos similares, por ejemplo, el dispositivo no está disponible después de reiniciarse. En tal caso, se propone intentar reiniciar primero u omitir los reinicios por completo. Los pasos de análisis pueden incluir la solicitud de una confirmación por parte del usuario.

Los resultados del análisis se devuelven al servidor de aprendizaje, paso 305, que le solicita al usuario que los confirme, paso 306. Si el usuario decide actualizar los ajustes del dispositivo, el flujo comienza entonces desde el principio y se envía un nuevo conjunto de datos del dispositivo al servicio de aprendizaje de dispositivo. Si el usuario acepta los resultados, los ajustes se confirman y se envían al servicio de aprendizaje de dispositivo, paso 307. A continuación, se confirma la recepción de este mensaje, paso 308.

En la figura 4 se muestra un ejemplo de proceso de aprendizaje de dispositivo. En el proceso, el servidor de aprendizaje de dispositivo solicita una lista de casos de uso, paso 400, del servicio de aprendizaje de dispositivo una vez finalizada la identificación del dispositivo. El servicio de aprendizaje de dispositivo responde, paso 401, con una lista de casos de uso aplicables para el dispositivo solicitado. Estos dependen, por ejemplo, de los casos de uso que conozca en la actualidad el servicio de aprendizaje de dispositivo y de los datos del dispositivo conectado, por ejemplo, algunos casos de uso solo están disponibles en determinadas plataformas de dispositivos.

Los casos de uso aplicables se presentan al ingeniero que dirige al cliente de aprendizaje de dispositivo, quien tiene la posibilidad de añadir o eliminar casos de uso antes de iniciar el proceso de aprendizaje de dispositivo automatizado, paso 402. Una vez seleccionados los casos de uso objetivo, el cliente de aprendizaje de dispositivo activa el aprendizaje de dispositivo que automatizará todos los casos de uso seleccionados en el nuevo dispositivo objetivo. El mantenimiento de los casos de uso en el servicio de aprendizaje de dispositivo significa también que los casos de uso admitidos pueden ampliarse sin cambiar/actualizar el servidor de aprendizaje de dispositivo.

Una vez seleccionados los casos de uso, puede iniciarse entonces el aprendizaje mediante un método de aprendizaje en bucle. Tal y como se muestra en la figura 4, el bucle 403 puede ejecutarse varias veces para que el servidor de aprendizaje reciba instrucciones del servicio de aprendizaje de dispositivo, las aplique al dispositivo probado y, a continuación, proporcione retroalimentación al servicio de aprendizaje de dispositivo. El bucle se puede realizar tanto tiempo como sea necesario para completar con éxito el caso de uso que se esté probando o se haya alcanzado otra condición para la finalización, tal como un número de bucles iterados.

La figura 5 es un ejemplo de un caso de uso relacionado con la habilitación o deshabilitación del uso de datos móviles en un dispositivo móvil. El método es iniciado por el servidor de aprendizaje de dispositivo enviando una señal al servicio de aprendizaje de dispositivo, paso 500. El servicio de aprendizaje de dispositivo crea una sesión de caso de uso, paso 501, donde se determina que la primera tarea es habilitar el menú o la aplicación de ajustes en el dispositivo móvil. Como consecuencia, se envía una señal para iniciar la aplicación de ajustes al servidor de aprendizaje de dispositivo, paso 502, que a su vez la envía al nuevo dispositivo que se está aprendiendo, paso 503. El dispositivo intenta ejecutar el comando. Como resultado, un mensaje de éxito y capturas de pantalla sobre la pantalla actual se envían como retroalimentación al servidor de aprendizaje de dispositivo, paso 504. El servidor de aprendizaje de dispositivo envía una señal al servicio de aprendizaje de dispositivo, paso 505. La señal proporciona la información relativa a que la aplicación se ha iniciado y también proporciona la captura de pantalla para su posterior análisis. El análisis lo realiza el servicio de aprendizaje de dispositivo, paso 506.

Como resultado, el servicio de aprendizaje del dispositivo determina que la aplicación de ajustes se ha iniciado correctamente. La información sobre cómo iniciar los ajustes se almacena en caché. El siguiente paso es encontrar el elemento del menú que controla las redes móviles. El servicio de aprendizaje de dispositivo envía una señal con una instrucción para que se realice un toque simulado sobre el elemento de menú de redes móviles, paso 507. Las instrucciones se proporcionan además al dispositivo probado, paso 508. De nuevo, se envía un mensaje de éxito junto con capturas de pantalla, paso 509. El servidor de aprendizaje de dispositivo reenvía este mensaje al servicio de aprendizaje de dispositivo, paso 510, que lo utiliza como retroalimentación. Se analiza la retroalimentación, paso 511 y, a continuación, se almacenan las instrucciones sobre cómo hacer clic en el elemento de menú de redes móviles. La siguiente instrucción es habilitar el conmutador de datos móviles, que habilita o deshabilita la conexión de datos móviles. Las instrucciones de habilitación se envían al servidor de aprendizaje de dispositivo, paso 512, que reenvía la señal al dispositivo, paso 513. Como respuesta, se recibe un mensaje de éxito con capturas de pantalla, paso 514. El servidor de aprendizaje de dispositivo los reenvía al servicio de aprendizaje de dispositivo, paso 515. Los mensajes recibidos y las capturas de pantalla se utilizan de nuevo como retroalimentación y se analizan, paso 516. En el ejemplo de la figura 5, la habilitación se realizó correctamente y las instrucciones para habilitar el conmutador de datos móviles se almacenan en la memoria caché. A continuación, se verifica el estado de los datos móviles. Se envía una solicitud de verificación al servidor de aprendizaje de dispositivo, paso 517. El servidor de aprendizaje de dispositivo reenvía a su vez el mensaje al dispositivo probado, paso 518. El resultado de la verificación y las capturas de pantalla se reciben como retroalimentación, paso 519. El servidor de aprendizaje de dispositivo envía los resultados al servicio de aprendizaje de dispositivo, paso 520. El servicio de aprendizaje de dispositivo sabe ahora que los datos móviles están activados y qué aspecto tiene la pantalla tras la activación. Los resultados, incluida la captura de pantalla, se analizan de nuevo, paso 521. Puesto que la activación se ha realizado correctamente, el caso de uso se encuentra al final. Todos los datos relevantes relacionados con el caso de uso y las instrucciones necesarias para realizar el caso de uso se almacenan, directamente o utilizando una caché, en la base de conocimientos o base de datos, paso 522. Estos datos relevantes, una configuración que consiste en información sobre cómo llevar a cabo un caso de uso, se almacenan para poder recuperarlos en un momento posterior, de modo que los dispositivos puedan probarse sin necesidad de aprender de nuevo el caso de uso. Se envía una señal al servidor de aprendizaje de dispositivo para finalizar el caso de uso, paso 523.

La figura 6 es un ejemplo de gráfico de señalización que divulga con más detalle el procedimiento para habilitar un conmutador. El conmutador puede ser el conmutador para habilitar los datos móviles del ejemplo anterior. El método se inicia obteniendo instrucciones, paso 600. El algoritmo de aprendizaje de dispositivo en el servicio de aprendizaje de dispositivo genera un conjunto de instrucciones que se transmiten al servidor de aprendizaje de dispositivo para su ejecución, paso 601. Las instrucciones de aprendizaje de dispositivo pueden comprender las siguientes tareas. En primer lugar, se verifica que el conmutador no esté seleccionado. A continuación, tras una verificación positiva, se genera un toque simulado, o cualquier otro medio para hacer un clic sobre el conmutador. Tras el clic, se verifica el estado del conmutador. Como resultado de la verificación, se recibe el conmutador seleccionado. A continuación, se obtiene una captura de pantalla para su posterior análisis. En el ejemplo de la figura 6, además de la captura de pantalla se adquiere el código fuente de la pantalla. A continuación, esta información se transmite al servicio de aprendizaje de dispositivo, que determina que todas las tareas se han realizado correctamente, paso 602. En el ejemplo de la figura 6, únicamente el servicio de aprendizaje de dispositivo realiza alguna determinación basada en los resultados recibidos. Esto se debe a que, en caso de ejecución fallida de las instrucciones, es el servicio de aprendizaje de dispositivo el que determina cómo reaccionar. A continuación, se analiza la retroalimentación recibida, paso 603. Por último, se almacena la información. Ha de señalarse que la información puede almacenarse en relación con las instrucciones, o el conjunto de tareas, y también puede utilizarse como entrada de la disposición de aprendizaje, tal como una red neuronal u otro algoritmo de aprendizaje automático como material de entrenamiento.

En la figura 7 se muestra otro ejemplo de señalización. El ejemplo de la figura 7 implica realizar el mismo procedimiento de la figura 6, aunque la figura 7 ilustra el escenario en el que el procedimiento falla al menos parcialmente. Incluso si en las figuras 6 y 7 se utiliza un conmutador como ejemplo, los mismos principios pueden aplicarse a procedimientos y controles diferentes.

Por consiguiente, el ejemplo de la figura 7 se inicia, paso 700, tras lo cual las instrucciones generadas se envían al servidor de aprendizaje de dispositivo, paso 701. A continuación, las instrucciones se ejecutan en un dispositivo probado, paso 702. Se da por hecho que estos pasos son idénticos a los del ejemplo de la figura 6. Sin embargo, la retroalimentación recibida indica ahora que el clic sobre el conmutador no tuvo un resultado positivo. En consecuencia, también falla la verificación de que el conmutador esté habilitado. Este resultado se analiza, paso 703. Los resultados y el análisis se utilizan entonces al determinar las nuevas instrucciones, paso 704. El proceso es similar al anterior; sin embargo, esta vez el servicio de aprendizaje de dispositivo ya sabe que las instrucciones anteriores fallaron y las nuevas instrucciones se basan en la retroalimentación y los datos acumulados anteriores.

Las nuevas instrucciones se envían entonces al dispositivo probado, paso 706. En el ejemplo de la figura 7, el toque simulado está configurado para provocar un deslizamiento sobre el conmutador en lugar de un simple clic. El proceso de ejecución puede ser el mismo que en la prueba anterior, pero, puesto que ya se sabe que el conmutador no está habilitado, no es necesario volver a comprobarlo. Por lo tanto, la retroalimentación también comprende una indicación relativa a que el deslizamiento se realizó correctamente, el conmutador está habilitado, la captura de pantalla y la fuente de pantalla, paso 706. La retroalimentación se analiza y almacena de nuevo, paso 707. Los resultados comprenden información sobre cómo verificar el estado del conmutador y cómo habilitarlo. Asimismo, la captura de pantalla y el código fuente de la pantalla se utilizan como material didáctico. El servicio de aprendizaje de dispositivo funciona de manera que también es capaz de utilizar los intentos exitosos como base para la siguiente generación de instrucciones. Por ejemplo, si el servicio de aprendizaje de dispositivo está provisto de una serie de dispositivos en los que se utiliza un deslizamiento en lugar de un clic, la generación de instrucciones empezará entonces finalmente a producir instrucciones que incluyan el deslizamiento en el primer conjunto de instrucciones. No sucede necesariamente al probar el siguiente dispositivo similar, ya que el uso del deslizamiento en el dispositivo puede ser una excepción, ya sea intencionada o no.

En la descripción anterior se proporcionan ejemplos para una mejor comprensión de la disposición de prueba de dispositivos actual. No se pretende que los ejemplos constituyan una lista exhaustiva, sino simplemente que faciliten la implementación. Por ejemplo, los casos de uso o secuencias de instrucciones que comprenden tareas no están limitados a habilitar la conexión de datos móviles. Otros ejemplos incluyen habilitar/deshabilitar el modo avión, seleccionar el modo de red preferido, realizar una llamada, responder a una llamada y similares. En principio, un caso de uso puede definirse para cada una de las funciones del dispositivo móvil. Los casos de uso del aprendizaje de dispositivo pueden organizarse en grupos de nivel superior. Por ejemplo, el grupo «gestión básica de llamadas» contiene todos los casos de uso necesarios para realizar, responder y rechazar llamadas, el grupo «gestión avanzada de llamadas» contiene todos los casos de uso necesarios para mantener en espera, conectar y combinar llamadas.

La lista de casos de uso disponibles puede solicitarse al servicio de aprendizaje de dispositivo una vez realizada la identificación del dispositivo. La lista se formula a partir de todos los casos de uso disponibles basándose en el dispositivo conectado. Los casos de uso aplicables se presentan al ingeniero que dirige el servidor de aprendizaje de dispositivo, quien tiene la posibilidad de añadir o eliminar casos de uso antes de iniciar el proceso de aprendizaje de dispositivo automatizado. Una vez seleccionados los casos de uso objetivo, el servidor de aprendizaje de dispositivo activa el aprendizaje de dispositivo que automatizará todos los casos de uso seleccionados en el nuevo dispositivo objetivo.

En aras de la claridad, en los ejemplos anteriores las instrucciones se envían de una en una; sin embargo, en aplicaciones de la vida real las instrucciones pueden enviarse como paquetes. Las instrucciones agrupadas también pueden ejecutarse como un paquete siempre que no requieran retroalimentación o instrucciones adicionales que impidan la ejecución como un paquete.

En los ejemplos anteriores de pruebas se han analizado dispositivos móviles. Se pueden utilizar principios similares en las pruebas de redes que utilizan los dispositivos particulares. Las pruebas de la red pueden requerir que el dispositivo móvil utilice la red de una manera que normalmente no utilizaría. Así, al probar la funcionalidad de la red, los casos de uso pueden ser diferentes a aquellos en los que una funcionalidad similar, por ejemplo, realizar llamadas, se prueba en una prueba de dispositivo. Sin embargo, el servidor de pruebas de dispositivo utiliza las instrucciones de dispositivo aprendidas para ordenar a un dispositivo seleccionado que realice todas las acciones necesarias para probar la red. En una disposición de prueba en red, el dispositivo utilizado normalmente se ha aprendido por completo; sin embargo, es posible que una actualización de software, un error u otro motivo impida utilizar el dispositivo de conformidad con las instrucciones anteriores. En tal caso, es posible que el servidor de pruebas de dispositivo se comunique con la nube de aprendizaje de dispositivo y realice acciones similares con el servidor de aprendizaje de dispositivo. Por ejemplo, en caso de error inesperado, es posible utilizar el servicio de aprendizaje de dispositivo para determinar si el error se debe a un mal funcionamiento del dispositivo o de la red, o si se ha cambiado el dispositivo. Un ejemplo de tal cambio detectable es que, de conformidad con las instrucciones, hay que marcar una casilla de verificación, pero en el lugar indicado hay un cursor.

El método mencionado anteriormente puede implementarse como un programa informático que se ejecuta en un dispositivo informático capaz de comunicarse con un dispositivo móvil. Cuando el software se ejecuta en un dispositivo informático, está configurado para llevar a cabo el método inventivo descrito anteriormente. El software se incorpora en un medio legible por ordenador de modo que pueda proporcionarse al dispositivo informático tal como el servicio de aprendizaje de dispositivo 100 de la figura 1.

Tal y como se ha indicado anteriormente, los componentes de las formas de realización a modo de ejemplo pueden incluir medios o memorias legibles por ordenador para almacenar instrucciones programadas de conformidad con las enseñanzas de la presente invención y para almacenar estructuras de datos, tablas, registros y/u otros datos descritos en el presente documento. El medio legible por ordenador puede incluir cualquier medio adecuado que participe en el suministro de instrucciones a un procesador para su ejecución. Las formas habituales de medios legibles por ordenador pueden incluir, por ejemplo, un disquete, un disco flexible, un disco duro, una cinta magnética, cualquier otro medio magnético adecuado, un CD-ROM, un CD registrable, un CD regrabable, un DVD, un DVD-RAM, un DVD regrabable, un DVD registrable, un DVD HD, un DVD registrable HD, un DVD regrabable HD, un DVD-RAM HD, un disco Blu-ray, cualquier otro medio óptico adecuado, una RAM, una PROM, una EPROM y una EPROM tipo «flash», cualquier otro chip o cartucho de memoria adecuado, una onda portadora o cualquier otro medio adecuado del que pueda leer un ordenador.

Para un experto en la materia es obvio que, con el avance de la tecnología, la idea básica de la disposición de prueba de dispositivos se puede implementar de diversas maneras. Por tanto, la disposición de prueba de dispositivos y sus formas de realización no están limitadas a los ejemplos descritos anteriormente, sino que pueden variar dentro del alcance de las reivindicaciones.

Claims

REIVINDICACIONES

1. Método para generar una configuración de automatización de pruebas de dispositivo que comprende secuencias de instrucciones que han de llevarse a cabo con un dispositivo probado para probar funciones de red de un dispositivo móvil que comprende:

recibir (200) una solicitud de generación de una nueva configuración de automatización de pruebas de dispositivo para un dispositivo móvil desde un servidor cliente al que está conectado el dispositivo móvil; recibir (201) al menos un caso de uso que comprende un conjunto de pasos que han de llevarse a cabo en una prueba de funcionalidad del dispositivo móvil, donde cada uno de los pasos comprende un conjunto de tareas para llevar a cabo el paso respectivo;

generar (202) instrucciones para llevar a cabo los pasos de al menos un caso de uso recibido, donde dicha generación comprende además llevar a cabo los siguientes pasos al menos una vez:

- generar (202) un conjunto inicial de instrucciones para un caso de uso;

- adaptar (203) el conjunto de instrucciones basándose en la información generada con anterioridad para dispositivos móviles similares;

- requerirle (204) al dispositivo móvil que lleve a cabo los pasos de conformidad con los casos de uso recibidos; y

- recibir (205) retroalimentación del dispositivo móvil, donde la retroalimentación se utiliza al adaptar las instrucciones;

almacenar (206) la configuración de automatización de pruebas de dispositivo que comprende los casos de uso basados en las instrucciones generadas para el dispositivo móvil en una base de datos para su uso posterior.

2. Método según la reivindicación 1, donde el método comprende además transmitir la configuración de automatización de pruebas de dispositivo generada a un servidor de pruebas de dispositivo para probar una pluralidad de dispositivos móviles de conformidad con la configuración de automatización de pruebas de dispositivo generada.

3. Método según la reivindicación 1 o 2, donde se utiliza la retroalimentación recibida y la información generada con anterioridad como entrada en un algoritmo de aprendizaje automático para generar instrucciones para el dispositivo móvil.

4. Método según cualquiera de las reivindicaciones anteriores 1 - 3, donde se proporciona una pluralidad de instrucciones en un conjunto de instrucciones.

5. Método según cualquiera de las reivindicaciones anteriores 4, donde se recibe retroalimentación como respuesta a uno o más conjuntos de instrucciones.

6. Método según cualquiera de las reivindicaciones anteriores 1 - 5, donde el método comprende además analizar la retroalimentación.

7. Método según cualquiera de las reivindicaciones anteriores 1 - 6, donde la retroalimentación comprende una captura de pantalla del dispositivo probado.

8. Método según cualquiera de las reivindicaciones anteriores 1 - 7, donde la retroalimentación comprende un código fuente de una pantalla del dispositivo probado.

9. Método según cualquiera de las reivindicaciones anteriores 1 - 8, donde la retroalimentación comprende salidas de las instrucciones ejecutadas.

10. Método según cualquiera de las reivindicaciones anteriores 1 - 9, donde la retroalimentación comprende un registro de dispositivo.

11. Programa informático que comprende código de programa informático que está configurado para hacer que se lleve a cabo un método según cualquiera de las reivindicaciones 1 - 10, cuando el programa informático se ejecuta en un dispositivo informático.

12. Aparato para generar una configuración de automatización de pruebas de dispositivo para probar funciones de red de un dispositivo móvil que comprende, dicho aparato comprende además:

al menos un procesador (101) configurado para ejecutar programas informáticos;

al menos una memoria (102) configurada para almacenar programas informáticos y datos relacionados; al menos una conexión de red (103) para recibir y transmitir instrucciones a dispositivos externos; donde el aparato está configurado para realizar un método según cualquiera de las reivindicaciones anteriores 1 -10.