Saltar al contenido principal
Antes del lanzamiento, debe haber completado todas las pruebas aplicables a su entorno. El aseguramiento de la calidad es fundamental 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 responderá su aplicación cuando se someta a cargas de producción inesperadas?
  • ¿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 siguiendo prácticas recomendadas de usabilidad y accesibilidad, y ofrecen compatibilidad probada desde el primer momento con una amplia variedad de navegadores y dispositivos. También se ofrece soporte para la internacionalización (I18N) desde el primer momento, con extensibilidad integrada pensada para escenarios 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 realizar pruebas unitarias de módulos individuales de extensibilidad (como Rules, Hooks 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 aprovechar las pruebas Mock junto con nuestra política de pruebas de carga para ayudar a garantizar que su(s) aplicación(es) funcionen correctamente ante cargas inesperadas.

​
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 y/o script de Custom DB, debería considerar usar un framework 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 y el material relacionado del inquilino de Auth0.

​
Pruebas de integración

Como práctica recomendada, configure distintos inquilinos para desarrollo, pruebas y producción, como se describe en la guía de arquitectura sobre compatibilidad con SDLC. Auth0 le permite configurar variables disponibles desde la extensibilidad personalizada; puede considerarlas 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 personalizada. Esto facilita que el mismo código personalizado funcione, sin cambios, en distintos inquilinos, ya que puede hacer referencia a variables que se rellenarán con valores específicos del inquilino en el momento de la 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 desencadenadores
  • Para usar variables en script de Custom DB, 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 confidencial 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 confidenciales 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, así como la automatización de pruebas. Esto puede usarse para 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, las capacidades de automatización de la implementación pueden usarse para volver a la última versión funcional. Para obtener más información, consulte la guía de automatización de la implementación proporcionada.

​
Pruebas 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 entre los clientes de Auth0 simular los endpoints de Auth0. Esta práctica es valiosa para garantizar que su aplicación funcione con las interfaces esperadas sin tener que limitar sus 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 aviso previo a Auth0 para que no se confundan con actividad maliciosa ni se bloqueen.

​
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 notificar 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 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 tiempo de antelación necesario para revisar una solicitud y de dejar suficiente tiempo 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 orientación puede ayudarle a evitar errores y resultados de prueba incorrectos.
  • Ejecute un rastreo HTTP durante 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 incluirlas en la prueba 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) invocará el sandbox de código personalizado de Auth0, y esto puede tener un mayor costo en términos de rendimiento. Desactive Rules a menos 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 la prueba de rendimiento en consecuencia para obtener un resultado realista. Los distintos endpoints tienen diferentes costos de rendimiento. No diseñar una prueba representativa dará como resultado conclusiones engañosas.
  • 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 incorporar una demora puede no ser suficiente.
  • Asegúrese de implementar un manejo de errores adecuado. 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 de conexiones OAuth personalizadas) provocados por excepciones no controladas en ese código.
  • Las pruebas de carga deben diseñarse para comenzar en un nivel bajo e incrementar la carga gradualmente, capturando datos en cada nivel, para 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 que sea necesario ejecutar una prueba de rendimiento varias veces, posiblemente ajustando el código sometido a prueba o el arnés/la configuración de prueba. Asegúrese de comenzar las pruebas con suficiente antelación para disponer de tiempo para más de una iteración.
  • Use su propia cuenta de proveedor de correo y asegúrese de gestionar con antelación una cuota suficiente de envío de correos, o el proveedor de correo puede aplicarle límites de frecuencia. Desactive el envío de correos 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 -> {nombre de la conexión}—para ver instrucciones sobre cómo agregar 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 su proveedor o proveedores
  • Para evitar la limitación de frecuencia y simular con mayor precisión la carga real, sus pruebas deberán enviar solicitudes para distintos usuarios, no todas 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 finalizar 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 de prueba programado.

​
Guía de planificación del proyecto

Ofrecemos 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 B2B IAM