Saltar al contenido principal
Antes del lanzamiento, debe haber completado todas las pruebas que correspondan a su entorno. El aseguramiento de la calidad es importante para identificar problemas antes de que afecten a sus clientes y, según la naturaleza de su proyecto, hay varios tipos de pruebas de calidad que conviene considerar como parte de su integración con Auth0:
  • ¿Su aplicación es fácil de entender y usar, incluso para personas con alguna discapacidad?
  • ¿Su aplicación debe funcionar en distintos navegadores y dispositivos?
  • ¿Su aplicación debe funcionar en entornos multinacionales y/o internacionales?
  • ¿Cómo se comportará su aplicación cuando se someta a cargas de producción imprevistas?
  • ¿Cómo puede asegurarse de que su aplicación esté protegida frente a vulnerabilidades de seguridad?
Auth0 Universal Login y los widgets de interfaz de usuario asociados (como Lock) ya se han diseñado y desarrollado conforme a las prácticas recomendadas de usabilidad y accesibilidad, y ofrecen compatibilidad probada, lista para usar, con una amplia variedad de navegadores y dispositivos. También se ofrece compatibilidad inmediata con la internacionalización (I18N), con mecanismos de extensibilidad integrados para casos personalizados de varios idiomas y localización (L10N). Para garantizar que se cumplan los requisitos funcionales y que los eventos inesperados se gestionen correctamente, se ofrece orientación para probar la integración entre su(s) aplicación(es) y Auth0, así como para las pruebas unitarias de módulos de extensibilidad individuales (como RulesHooks y scripts de base de datos personalizada). También se ofrece orientación sobre la política de pruebas de penetración de Auth0 para ayudarle a realizar pruebas de vulnerabilidades de seguridad, así como sobre cómo las pruebas con Mock pueden utilizarse junto con nuestra política de pruebas de carga para ayudar a garantizar que su(s) aplicación(es) rindan correctamente ante cargas imprevistas.

Pruebas unitarias

El objetivo de las pruebas unitarias es probar unidades individuales de código. Si crea código personalizado en Auth0 en forma de Rules, Hooks o script de Custom DB, debería considerar usar un marco de pruebas (como Mocha) para probar su código. Las empresas que han tenido más éxito con Auth0 han comprobado que resulta útil ejecutar estas pruebas unitarias antes de implementar automáticamente la configuración del inquilino de Auth0 y los recursos relacionados.

Pruebas de integración

Una práctica recomendada es configurar distintos inquilinos para desarrollo, pruebas y producción, como se explica en la guía de arquitectura sobre soporte para SDLC. Auth0 le permite configurar variables disponibles desde la extensibilidad personalizada; pueden considerarse variables de entorno para su inquilino de Auth0. En lugar de codificar de forma fija referencias que cambian al mover código entre entornos de desarrollo, pruebas y producción, puede usar un nombre de variable configurado en el inquilino y al que haga referencia el código de extensibilidad personalizado. Esto facilita que el mismo código personalizado funcione, sin cambios, en distintos inquilinos, ya que el código puede hacer referencia a variables que se rellenarán con valores específicos del inquilino en tiempo de ejecución:
  • Para usar variables en Rules, consulte cómo configurar valores
  • Para usar variables en Hooks, consulte cómo configurar secretos en el editor
  • Para usar variables en Actions, consulte Explorar flujos y activadores
  • Para usar variables en Custom DB Scripts, consulte los parámetros de configuración

Práctica recomendada

Se recomienda usar variables para almacenar valores específicos del inquilino, así como cualquier secreto sensible que no deba exponerse en su código personalizado. Si su código personalizado está desplegado en GitHub, usar una variable específica del inquilino evita exponer valores sensibles a través de su repositorio de GitHub.

Automatización de pruebas

Puede automatizar su proceso general de compilación incorporando la automatización de la implementación y de las pruebas. Esto le permite implementar nuevas versiones de la configuración y/o del código personalizado en Auth0, y ejecutar pruebas automatizadas. Si las pruebas detectan algún fallo, puede usar las capacidades de automatización de la implementación para revertir a la última versión funcional. Para obtener más información, consulte la guía de automatización de la implementación.

Pruebas con Mock

Como punto de equilibrio entre la política de pruebas de carga de Auth0 y la necesidad de realizar pruebas de carga, es habitual que los clientes de Auth0 simulen los endpoints de Auth0. Esta práctica es útil para garantizar que su aplicación funcione con las interfaces esperadas sin tener que limitar las pruebas, y puede apoyarse en herramientas como MockServer, JSON Server o incluso Postman.

Pruebas de penetración (opcional)

Si va a realizar pruebas de penetración, debe conocer y cumplir la política de pruebas de penetración de Auth0. Las pruebas de penetración requieren notificar a Auth0 con antelación para que no se confundan con actividad maliciosa ni se interrumpan.

Pruebas de carga (opcional)

Si va a realizar pruebas de carga, debe conocer la política de pruebas de carga de Auth0 y cumplirla. Las pruebas de carga requieren avisar a Auth0 con antelación. Al planificar sus pruebas de carga, también deberá tener en cuenta los límites de frecuencia de la API de Auth0. Las pruebas de carga requieren la aprobación previa de Auth0, como se explica en la política de pruebas de carga de Auth0. Asegúrese de tener en cuenta el plazo necesario para revisar una solicitud y de dejar tiempo suficiente tanto para la revisión como para la ejecución de las pruebas. Si su solicitud de prueba de carga ha sido aprobada, la siguiente guía puede ayudarle a evitar errores y resultados de prueba inexactos.
  • Ejecute un rastreo HTTP en una ejecución de prueba de su aplicación para identificar todas las llamadas que su aplicación o la prueba prevista deben realizar, y asegúrese de que la prueba las incluya para que sea representativa de lo que ocurrirá en producción.
  • Diseñe su prueba teniendo en cuenta los límites de frecuencia de la API de Auth0.
  • El uso de cualquier código personalizado en Auth0 (Actions, Rules, Hooks, scripts de base de datos personalizada, conexiones personalizadas de ) invocará el sandbox de código personalizado de Auth0, y esto puede suponer un mayor costo en términos de rendimiento. Desactive las Rules, salvo que sean esenciales para la prueba. Si están desactivadas, tendrá un mayor rendimiento que si están activadas.
  • Estime la carga total esperada para su entorno de producción y el porcentaje de llamadas a cada endpoint, y estructure su prueba de rendimiento en consecuencia para obtener un resultado realista. Los distintos endpoints tienen costos de rendimiento diferentes. No diseñar una prueba representativa dará lugar a resultados engañosos.
  • No realice llamadas que dependan de los resultados de llamadas anteriores sin comprobar que las llamadas o respuestas previas necesarias se hayan completado. Limitarse a introducir un retraso puede no ser suficiente.
  • Asegúrese de implementar una gestión de errores adecuada. Una causa frecuente de problemas durante las pruebas son los errores en el código personalizado (Actions, Rules, Hooks, scripts de base de datos personalizada, scripts personalizados de conexión OAuth) provocados por excepciones no controladas en el código personalizado.
  • Las pruebas de carga deben escribirse de modo que comiencen en un nivel bajo y aumenten la carga gradualmente, capturando datos en cada nivel, a fin de obtener los resultados más útiles. Comenzar en un nivel alto y fallar de inmediato aporta menos información sobre lo que el sistema puede soportar.
  • Es normal tener que ejecutar una prueba de rendimiento varias veces, posiblemente ajustando el código sometido a prueba o la infraestructura/configuración de la prueba. Asegúrese de comenzar las pruebas con antelación para disponer de tiempo suficiente para más de una iteración.
  • Use su propia cuenta de proveedor de correo y asegúrese de disponer con antelación de una cuota suficiente de envío de correo, o el proveedor de correo podría aplicarle límites de frecuencia. Desactive el envío de correo si no lo utiliza.
  • Asegúrese de usar las credenciales de su propia cuenta para todas las conexiones sociales en lugar de las claves de desarrollo de Auth0. En el , vaya a Connections -> Social -> {name of connection}—para ver instrucciones sobre cómo añadir a la conexión las credenciales de su propia cuenta del proveedor social. Nota: algunos proveedores sociales no permiten pruebas de carga. Consulte la política de sus proveedores.
  • Para evitar los límites de frecuencia y simular con mayor precisión una carga real, sus pruebas deberán enviar solicitudes de distintos usuarios, no todas las solicitudes para el mismo usuario. Si usa solo uno o unos pocos usuarios, el almacenamiento en caché puede reducir la carga efectiva y no proporcionar resultados realistas.
  • Asegúrese de mantenerse dentro de los parámetros acordados para la prueba y de la política de pruebas de carga de Auth0. Auth0 se reserva el derecho de interrumpir cualquier prueba de rendimiento/carga que no se mantenga dentro de los límites de los parámetros acordados o que se extienda más allá del período programado para la prueba.

Guía de planificación del proyecto

Ponemos a su disposición una guía de planificación en formato PDF que puede descargar y consultar para obtener más información sobre nuestras estrategias recomendadas. Guía de planificación del proyecto de IAM B2C