- Introducción a Test Suite
- Información general
- Prácticas recomendadas de automatización
- Studio
- Orchestrator
- Testing Robots
- Test Manager
![](https://docs.uipath.com/_next/static/media/grid.05ebd128.png?w=3840&%3Bq=100)
Prácticas recomendadas 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.
- 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 separada 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 esperen el estado de 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.
- 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 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. La modularidad es la clave para una buena prueba de unidad. Escribir pruebas podría actuar como comentario/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 esperen el estado de 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.
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.
Quién realiza la prueba |
Procedimiento de prueba |
Captura de resultados de la prueba |
Requisitos de licencia |
---|---|---|---|
• Probadores manuales • UAT o PYMEs comerciales |
|
Los resultados, incluyendo capturas de pantalla y documentos, están disponibles para el probador de UAT en Test Manager. |
El probador de UAT requiere una licencia de automatización atendida. Puede gestionar sus licencias en función de su tipo de implementación. 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. |
Quién realiza la prueba |
Procedimiento de prueba |
Captura de resultados de la prueba |
Requisitos de licencia |
---|---|---|---|
| Pruebas de tiempos de ejecución |