Prueba de automatización

Para sacar el máximo partido a tus esfuerzos de prueba, considera las siguientes prácticas recomendadas de automatización de pruebas basadas en las pruebas RPA o de aplicación.

Prueba de aplicación

• Utiliza la plantilla Marco de automatización de pruebas para implementar proyectos de automatización estables y escalables.
• Los casos de prueba deben ser independientes entre sí. Un caso de prueba no debería depender de la ejecución de otro caso de prueba.
• Un caso de prueba solo debe tener un propósito específico. Cada flujo de trabajo de prueba debe contener solo una verificación.
• Cada característica debe tener una prueba de unidad. Si se permiten excepciones, crea una prueba y una excepción independientes para cada caso de prueba.
• En una estructura de caso de prueba Dado-Cuando-Entonces, si la parte dada se está volviendo demasiado extensa e inmanejable, trata de redefinir el caso de prueba. Podría necesitar más granularidad o refactorización.
• Mantén los casos de prueba y actualízalos después de cualquier solicitud de cambio.
• Considera establecer una lógica de gestión de pruebas para tener una única manera de definir casos de prueba.
• Para aumentar la reutilización entre proyectos de prueba individuales, así como entre proyectos de prueba y RPA, trata de usar bibliotecas y repositorios de objetos siempre que sea posible.
• Incluye las pruebas en el proceso de CI/CD.
• Las pruebas funcionales como parte de tu proceso de CI deberían ejecutarse lo más rápido posible para no retrasar tu diseño. Por lo tanto, trata de ejecutar estas pruebas en paralelo con tantos robots como sea posible.
• Los nombres de actividad deben reflejar la acción realizada. En los comportamientos no evidentes, considera la posibilidad de utilizar anotaciones en tus actividades.
• Considera usar un registro detallado y el manejo de excepciones para depurar el proceso y evitar resultados negativos falsos.
• Planifica la recuperación o reintenta en caso de error en diferentes etapas para evitar resultados fallidos.
• Considera tener una estructura de carpetas dedicada a probar y usar la misma convención de denominación de casos de prueba en todos sus proyectos.
• Usa activos para variables que sean susceptibles de cambiar y usarse muchas veces.
• Para escenarios en los que el estado de una aplicación deba validarse antes de continuar con ciertos pasos en un proceso, considera la posibilidad de aplicar medidas de validación. Estas medidas pueden incluir el uso de actividades adicionales que esperan el estado de la aplicación deseado antes de otras interacciones (los retrasos codificados no se consideran buenas prácticas).
• Considera usar simulación de clic/escribir o enviar mensajes de Windows siempre que sea posible.
• No elimines, muevas ni renombres los casos de prueba fuera de Studio. Realiza estas acciones solo en Studio. Usa Importar casos de prueba en caso de que haya casos de prueba de otro proyecto que deban referenciarse.

Prueba de RPA

• Los casos de prueba deben ser independientes entre sí. Un caso de prueba no debería depender de la ejecución de otro caso de prueba.
• Considera crear pequeños flujos de trabajo que aborden el menor número de acciones posible. De esta manera, será más fácil entenderlo y realizar pruebas de unidad.
• Un caso de prueba solo debe tener un propósito específico. Cada flujo de trabajo de prueba debe contener solo una verificación.
• Cada característica debe tener una prueba de unidad. Si se permiten excepciones, crea una prueba separada para cada caso de prueba.
• Para aumentar la reutilización entre proyectos de prueba individuales, así como entre proyectos de prueba y RPA, trata de usar bibliotecas y repositorios de objetos siempre que sea posible.
• En una estructura de caso de prueba Given-When-Then (Dado-Cuando-Entonces), si la parte Dado se está volviendo demasiado extensa e inmanejable, intenta redefinir el caso de prueba. Podría necesitar más granularidad o refactorización. La modularidad es la clave para una buena prueba unitaria. Las pruebas de escritura podrían actuar como comentarios/revisión de código en el desarrollo.
• Usa la simulación siempre que existan pasos complejos que sean irrelevantes para el propósito del caso de prueba que puedan reemplazarse.
• Considera establecer una lógica de gestión de pruebas para tener una única manera de definir casos de prueba.
• Mantén los casos de prueba y actualízalos después de cualquier solicitud de cambio.
• Incluye las pruebas en el proceso de CI/CD.
• Ejecuta tus casos de prueba cada vez que realices un cambio en RPA para asegurarte de que no se introduzca ningún error.
• Prepara un conjunto de pruebas RPA que pueda ejecutar el equipo de TI en un entorno de preproducción, siempre que planee implementar un cambio de entorno (como una actualización de Windows) para que puedas detectar problemas potenciales antes de que lleguen a la fase de producción.
• Los nombres de actividad deben reflejar la acción realizada. En los comportamientos no evidentes, considera la posibilidad de utilizar anotaciones en tus actividades.
• Planifica la recuperación o reintenta en caso de error en diferentes etapas para evitar resultados fallidos.
• Considera tener una estructura de carpetas dedicada a probar y usar la misma convención de denominación de casos de prueba en todos sus proyectos.
• Usa activos para variables que sean susceptibles de cambiar y usarse muchas veces.
• Para escenarios en los que el estado de una aplicación deba validarse antes de continuar con ciertos pasos en un proceso, considera la posibilidad de aplicar medidas de validación. Estas medidas pueden incluir el uso de actividades adicionales que esperan el estado de la aplicación deseado antes de otras interacciones (los retrasos codificados no se consideran buenas prácticas).
• Considera usar simulación de clic/escribir o enviar mensajes de Windows siempre que sea posible.
• No elimines, muevas ni renombres los casos de prueba fuera de Studio. Realiza estas acciones solo en Studio. Usa Importar casos de prueba en caso de que haya casos de prueba de otro proyecto que deban referenciarse.

Pruebas RPA de automatizaciones atendidas

En el siguiente tema, puedes aprender cómo realizar pruebas de RPA de tus automatizaciones atendidas en función de escenarios de prueba específicos.

Nota: Asegúrate de tener una licencia de trabajo tanto para Orchestrator como para Test Manager.

Prueba de aceptación de usuario atendida

Quién realiza la prueba	Procedimiento de prueba	Captura de resultados de la prueba	Requisitos de licencia
• Probadores manuales • UAT o PYMEs comerciales	El equipo de control de calidad define los casos de prueba manuales en Test Manager, de la siguiente manera: a. Pasos de requisito previo b. Ejecución de la automatización c. Aserciones Los probadores de UAT ejecutan un caso de prueba manual en Test Manager. Los probadores de UAT preparan el entorno para la automatización atendida Los probadores de UAT ejecutan la automatización atendida a través de UiPath® Assistant. Los probadores de UAT verifican las aserciones después de que se haya ejecutado la automatización.	Los resultados, incluidas las capturas de pantalla y los documentos, están disponibles para el probador de UAT en Test Manager.	El probador de UAT requiere una licencia de automatización atendida. Puedes administrar tus licencias en función de tu tipo de implementación: • Local Puedes resolver esto según dos escenarios: • Publicar los paquetes de automatización en tu entorno de producción de Orchestrator que tiene una licencia de automatización atendida asignada para el probador de UAT. • Asignar un subconjunto de licencias de usuario atendidas a tu entorno non-production en Orchestrator.

Pruebas de regresión no atendida

Quién realiza la prueba	Procedimiento de prueba	Captura de resultados de la prueba	Requisitos de licencia
UiPath Robot unattended de prueba.	El equipo de control de calidad define los casos de prueba en Test Manager de la siguiente manera: a. Pasos de requisito previo b. Ejecución de la automatización c. Aserciones Los Automation Developers crean casos de prueba en automatizaciones existentes. Las acciones de usuario attended se simulan mediante . Los desarrolladores de automatización vinculan los casos de prueba de Studio a Test Manager. Los Automation Developers publican casos de prueba en Orchestrator y luego los agrupan en conjuntos de pruebas (en función de los requisitos del negocio). La prueba desatendida puede ejecutarse manualmente a través de Orchestrator y Test Manager, o mediante la programación en Orchestrator. (Opcional) Si las herramientas de CI/CD están disponibles, pueden aprovecharse para realizar las pruebas e implementación totalmente automatizados. UiPath proporciona integración de CI/CD a través de lo siguiente: • Extensión de Azure DevOps • Complemento de Jenkins	Los robots de prueba desatendidos proporcionan detalles y eventos de ejecución.	Pruebas de tiempos de ejecución