- Notas relacionadas
- Primeros pasos
- Instalación y configuración
- Proyectos de automatización
- Acerca de la publicación de proyectos de automatización
- Diseñar automatizaciones
- Gestionar paquetes de actividades
- Configuración de los Ajustes del Proyecto de Actividades
- Firma de paquetes
- Control
- Importar entidades
- Experiencia de diseño moderna
- Vincular un proyecto a una idea en Automation Hub
- Usar Data Manager
- Dependencias
- Tipos de flujos de trabajo
- Comparación de archivos
- Mejores prácticas de automatización
- Integración del control de código fuente
- Depuración
- La herramienta de diagnóstico
- Analizador de flujo de trabajo
- Acerca del analizador de flujo de trabajo
- ST-NMG-001: convención sobre nombres de variables
- ST-NMG-002: convención de nombres de argumentos
- ST-NMG-004: duplicación de nombres de visualización
- ST-NMG-005: anulación de variables
- ST-NMG-006: argumentos de anulación de variables
- ST-NMG-008: longitud variable excedida
- ST-NMG-009: variables de datos prefijados
- ST-NMG-011: argumentos de prefijo Datatable
- ST-NMG-012: valores predeterminados de los argumentos
- ST-NMG-016: longitud del argumento excedida
- ST-DBP-002: recuento de Argumentos elevado
- ST-DBP-003: bloque de Catch vacío
- ST-DBP-007: múltiples capas de diagramas de flujo
- ST-DBP-020: propiedades de salida no definidas
- ST-DBP-023: flujo de trabajo vacío
- ST-DBP-024: comprobación de actividad de persistencia
- ST-DBP-025: requisito previo para la serialización de variables
- ST-DBP-026: retraso en el uso de la actividad
- ST-DBP-027: mejor práctica de persistencia
- ST-DBP-028: requisito de serialización de argumentos
- ST-USG-005: argumentos de actividad codificados
- ST-USG-009: variables no utilizadas
- ST-USG-010: dependencias sin utilizar
- ST-USG-014: restricciones de los paquetes
- ST-USG-020: mensajes de registro mínimos
- ST-USG-024: guardado sin usar para más adelante
- ST-USG-025: uso incorrecto de los valores guardados
- ST-USG-026: restricciones de actividad
- ST-USG-027: paquetes necesarios
- ST-USG-028: Restringir la invocación de plantillas de archivo
- ST-USG-032 - Etiquetas obligatorias
- ST-USG-034 - URL Automation Hub
- Variables
- Argumentos
- Espacios de nombres importados
- Grabación
- Elementos de la IU
- Flujo de control
- Selectores
- Repo. de objetos
- Extracción de datos
- Automatización de imágenes y texto
- Acerca de la automatización de imágenes y texto
- Actividades con el ratón y el teclado
- Ejemplo de uso de la automatización de ratón y teclado
- Actividades de texto
- Ejemplo de uso de la automatización de texto
- Actividades de OCR
- Actividades de imagen
- Ejemplo de uso de la automatización de OCR y la automatización de imágenes
- Citrix Technologies Automation
- Automatización RDP
- Automatización de Salesforce
- Automatización SAP
- Automatización de VMware Horizon
- Registro
- La herramienta ScreenScrapeJavaSupport
- El protocolo WebDriver
- Conjunto de pruebas - Estudio
- Extensiones
- Solución de problemas
- Acerca de la resolución de problemas
- Compatibilidad y limitaciones de Microsoft App-V
- Solución de problemas de Internet Explorer x64
- Problemas de Microsoft Office
- Identificación de elementos de la interfaz de usuario en PDF con opciones de accesibilidad
- Reparar Soporte Active Accessibility
- Automatizar aplicaciones que se ejecutan en un usuario de Windows diferente
- Validation of large Windows-legacy projects takes longer than expected
Casos de prueba
Las pruebas de aplicaciones en Studio funcionan tanto en VB como en C#. Puedes crear proyectos de automatización individuales para escenarios como la verificación de datos o la integración con tus canalizaciones CI/CD. Diseña tu flujo de trabajo en Studio. Puedes realizar pruebas automatizadas de aplicaciones en VB o C#
- Realizar pruebas de aplicaciones mediante casos de prueba y casos de prueba basados en datos.
- Los proyectos de automatización de pruebas pueden tener varios puntos de entrada si contienen varios casos de prueba con ejecución lineal, ya que las actividades están organizadas de forma secuencial.
- La ejecución del flujo de trabajo se realiza por cada caso de prueba, a menos que se invoquen otros archivos
XAML
. - Puedes convertir los flujos de trabajo en casos de prueba, importarlos de otros proyectos o crear otros nuevos.
Puedes crear un caso de prueba invocando un flujo de trabajo desde un proyecto existente.
- Abre tu flujo de trabajo en Studio.
-
En el panel de Proyectos, haz clic con el botón derecho en el flujo de trabajo y selecciona Crear caso de prueba.
-
(Opcional) Selecciona el Flujo de trabajo simulado bajo prueba al crear tu caso de prueba si quieres hacer una copia de tu flujo de trabajo donde puedas simular actividades específicas. Si tienes un archivo simulado existente que quieres usar, lo puedes seleccionar desde la lista desplegable deSimulacros. Para obtener más información, consulta Simulacros de pruebas.
- (Opcional) Selecciona una Plantilla de la lista desplegable si creaste una previamente. Para obtener más información, consulta Plantillas de casos de prueba.
- (Opcional) Añade el caso de prueba a una Plantilla de ejecución. Necesitas haber creado antes una plantilla de ejecución. Para obtener más información, consulta Crear una plantilla de ejecución.
- Haz clic en Siguiente si quieres añadir datos de prueba.
-
Haz clic en Crear para confirmar los cambios.
Se crea un archivoXAML
de caso de prueba que invoca el flujo de trabajo con los siguientes contenedores: Dado, Cuando y Entonces. El archivo es invocado dentro de la actividad Invocar archivo de flujo de trabajo, que forma parte del contenedor When.
Los argumentos desde el flujo de trabajo se importan automáticamente. Para ver o añadir más argumentos, haz clic en el botón Importar argumentos, parte de la actividad Invocar archivo de flujo de trabajo.
Tanto los casos de prueba como los casos de prueba basados en datos son creados como borradores de forma predeterminada. Antes de publicar en Orchestrator es necesario configurar los casos de prueba como publicables. Puedes configurar casos de prueba individuales o múltiples como publicables al hacer clic con el botón derecho en los flujos de trabajo y después seleccionar Configurar como publicable.
XAML
se tornará azul como indicación de que el caso de prueba ya está listo para ser publicado y empaquetado en un archivo NUPKG
. Para regresar al borrador del flujo de trabajo, haz clic con el botón derecho en el flujo de trabajo y selecciona Ignorar desde la publicación.
Puedes publicar los casos de prueba en Orchestrator, en los valores predeterminados de Robot o en una ruta personalizada. Si quieres publicar en Orchestrator, asegúrate de que tu Robot o Asistente de UiPath está conectado a Orchestrator.
También es necesario publicar a Orchestrator cuando quieras ejecutar pruebas automatizadas a través de Test Manager. Asegúrate de que publicas el paquete a la fuente del proceso de tenant de Orchestrator y, después, enlaza los casos de prueba con Test Manager. La publicación del paquete en una carpeta diferente puede provocar errores de ejecución.
Para convertir los flujos de trabajo en casos de prueba, haz clic con el botón derecho en el flujo de trabajo en el panel Proyecto y selecciona Convertir en caso de prueba:
Resultado: El flujo de trabajo se convierte en Prueba Caso y se regenera en base a la plantilla Caso de prueba BDD.
XAML
se agregan a tu proyecto como borrador de casos de prueba.
Igual que importas colecciones de datos en bibliotecas de Automatización de pruebas de API, puedes importar dichas colecciones en tus procesos de Prueba de aplicación utilizando el asistente de Servicio nuevo.