Planificación
- Temas:
- Developing
Creado para:
- Developer
Este documento describe lo que debe saber para planificar la prueba. Además, debe responder a estas preguntas antes de realizar las pruebas:
Antes de comenzar
Antes de comenzar con el análisis real y la definición de pruebas, revise la siguiente información:
Arquitectura AEM - Consulte Conceptos básicos para presentarse a la arquitectura y los principios básicos de AEM.
Documentación - Para obtener más información, consulte cualquiera de las secciones de documentación o los artículos Instrucciones de uso.
Principios básicos de las pruebas - Debe conocer los principios básicos del Software Testing y Quality Assurance. Preferentemente, debería tener experiencia en proyectos de prueba.
Hay muchos sitios web, libros y cursos que tratan de esos principios y por lo tanto no se tratarán en detalle en este documento.
Supuestos que se deben evitar - El mayor supuesto (hecho regularmente) es que su sitio web necesitará atender millones de solicitudes cada día. En determinadas circunstancias, esto puede ser cierto, pero no puede suponerse.
Aunque los números futuros no se pueden predecir con una precisión del 100 %, observar el sitio existente y el tráfico experimentado dará una buena indicación. A continuación, puede hacer que las estimaciones dependan del factor por el que espera / espera que aumente el tráfico.
Compromiso con la calidad - Es de suma importancia que cualquiera que realice pruebas permanezca neutral e informe simplemente de los resultados de las pruebas realizadas.
El Administrador de proyectos es responsable de decidir e iniciar acciones en función de los resultados.
Involucrarse - Aunque es responsabilidad del director del proyecto garantizar que todas las partes participen plenamente en cualquier reunión (estado, talleres, etc.), también debe tratar de participar lo antes posible en el ciclo del proyecto, incluidos los procesos de recopilación de información y análisis de requisitos.
Involucrar al cliente - En un tema similar, intente involucrar al cliente (cuando sea posible) al definir sus casos de prueba y su plan.
Tipos de pruebas
Existen varias clasificaciones estándar de pruebas que son adecuadas para su uso al probar un proyecto AEM. Debe estar familiarizado con estos para decidir cuál usará:
Pruebas de unidades - Pruebas (normalmente) realizadas por el equipo de desarrollo para garantizar que los elementos individuales se comporten correctamente, aunque de forma aislada.
Pruebas de integración : Módulos de pruebas cuando se combinan. Estas pruebas se realizan después de la prueba de unidad, pero antes de la prueba del sistema.
Pruebas de humo - Son pruebas rápidas y sucias que se utilizan para probar que el software se está ejecutando y que la funcionalidad de alto nivel está disponible. Los detalles no se prueban.
Pruebas funcionales - Se utilizan para probar la funcionalidad del software. Se diseñará una serie de pruebas para cubrir todos los detalles funcionales, con entradas esperadas e inesperadas y/o erróneas.
Las pruebas en caja negra son pruebas funcionales de una unidad completa/componente/módulo, realizadas sin conocer el funcionamiento interno del elemento en cuestión.
Pruebas del sistema - Ensayan todo el sistema una vez que se ha integrado e instalado completamente en una plataforma adecuada.
Proban la funcionalidad en un cuadro negro.
Pruebas de rendimiento - Las pruebas de rendimiento son cruciales cuando se realiza la prueba AEM.
Se utilizan para ilustrar el rendimiento en condiciones diferentes:
-
Normal
Condiciones que experimentará el sitio durante, por ejemplo, el 90% de las veces. Por ejemplo, cuando solo una proporción de los autores utiliza el sistema.
-
Pico
Condiciones que se experimentarán durante un tiempo proporcionalmente breve debido a circunstancias especiales; por ejemplo, cuando todos los autores utilizan el sistema de forma simultánea o cuando se publica contenido nuevo y aumenta el número de visitantes que ven el sitio.
-
Extremo
Se puede utilizar para emular el pronóstico de rendimiento cuando se publica contenido nuevo y extremadamente interesante en su sitio web. Entonces se puede ver un pico extremo -aunque esto puede no ser siempre totalmente predecible.
Estas circunstancias a veces se ven cuando se ponen a disposición entradas para eventos específicos, o cuando se publica por primera vez un muy esperado sitio web.
Los resultados se utilizan para ajustar la aplicación.
Pruebas de estrés - Se realizan pruebas de estrés para confirmar el comportamiento de un componente o aplicación en condiciones extremas. En concreto, estas pruebas se utilizan para mostrar cómo se deteriora el comportamiento, cuándo falla el elemento y cómo.
Pruebas de regresión - Las pruebas de regresión se utilizan para confirmar que la funcionalidad ya probada en una versión anterior del software sigue funcionando correctamente.
Las pruebas de regresión son buenas candidatas para la automatización (si es posible) para garantizar que se puedan repetir de forma rápida y coherente.
Pruebas de aceptación - Las pruebas de aceptación son una categoría especial, ya que se utilizan para indicar la aceptación del cliente del proyecto.
La lista de pruebas de aceptación puede contener una combinación de pruebas de las distintas categorías anteriores y se seleccionan para verificar que el proyecto cumple los requisitos del cliente
Consulte Aceptación y desactivación para obtener más información.
Introducción
Antes de comenzar con los casos de prueba y el plan de pruebas detallados, puede:
Definir los objetivos - Defina sus objetivos de alto nivel para que actúen como punto de partida para el ajuste a medida que avancen las pruebas. Desea:
- Pruebe la funcionalidad de acuerdo con la Especificación de requisitos detallada.
- Rendimiento de la prueba según el Métricas de Target.
entre otros.
Recopilar estadísticas de tráfico del sitio web existente : Esta información se puede extraer de los archivos de registro. Consulte Supervisión del rendimiento para obtener más información.
Estas cifras darán una indicación del tráfico actual (volumen y difusión) en el sitio web existente y pueden utilizarse para formar un punto de base para el nuevo sitio web.
Recopilar estadísticas de tráfico de sitios web externos - Si es posible, puede intentar recopilar estadísticas de tráfico de otros sitios web para compararlas, pero estas cifras no siempre se publican.
Confirmar métricas de Target - Las métricas se utilizan para definir mediciones cuantitativas de la calidad del sitio web, ya que representan los objetivos de rendimiento que se deben alcanzar.
Deben definirse al principio del proyecto, junto con el cliente. Consulte Métricas de Target para obtener más información.
Experience Manager
- Información general sobre el desarrollo de la guía del usuario
- Introducción para desarrolladores
- Introducción al desarrollo de AEM Sites: Tutorial de WKND
- AEM Conceptos principales
- Estructura de la interfaz de usuario táctil AEM
- Conceptos de la IU táctil AEM
- Desarrollo de AEM: directrices y prácticas recomendadas
- Uso de bibliotecas del lado del cliente
- Desarrollo y diferencia de página
- Limitaciones del editor
- Marco de protección del CSRF
- Modelado de datos - Modelo de David Nuescheler
- Contribución a AEM
- Seguridad
- Materiales de referencia
- Creación de un sitio web con todas las funciones (IU clásica)
- Diseños y Designer (IU clásica)
- Plataforma
- Hoja de referencia de Sling
- Uso de los adaptadores de Sling
- Bibliotecas de etiquetas
- Plantillas
- Uso de la fusión de recursos de Sling en AEM
- Superposiciones
- Convenciones de nomenclatura
- Creación de un nuevo componente de campo de interfaz de usuario de Granite
- Query Builder
- Etiquetado
- Personalización de páginas que muestra el Controlador de errores
- Tipos de nodos personalizados
- Adición de fuentes para la renderización gráfica
- Conexión a bases de datos SQL
- Externalización de direcciones URL
- Creación y consumo de trabajos para descarga
- Configuración del uso de cookies
- Cómo acceder mediante programación al JCR de AEM
- Integración de servicios con la consola JMX
- Desarrollo del Editor por lotes
- Desarrollo de informes
- eCommerce
- Componentes
- Componentes principales
- Sistema de estilos
- Información general sobre componentes
- Componentes AEM: conceptos básicos
- Desarrollo de componentes AEM
- Desarrollo de componentes de AEM: ejemplos de código
- Exportador JSON para servicios de contenido
- Activación de la exportación de JSON para un componente
- Editor de imágenes
- Etiqueta decorativa
- Uso de Ocultar condiciones
- Configuración de varios editores in situ
- Modo de desarrollador
- Prueba de la interfaz de usuario
- Componentes para fragmentos de contenido
- Obtención de información de página en formato JSON
- Internacionalización
- Componentes de la IU clásica
- Administración de experiencias sin objetivos
- Sin cabezal e híbrido con AEM
- Activación de la exportación de JSON para un componente
- Aplicaciones de una sola página
- Introducción y tutorial de SPA
- Tutorial de SPA WKND
- Introducción a SPA en AEM: React
- Introducción a SPA en AEM: Angular
- Implementación de un componente de React para SPA
- Profundización en SPA
- Información general del editor de SPA
- Desarrollo de SPA para AEM
- Modelo SPA
- Componente de página SPA
- Asignación de modelos dinámicos a componentes para SPA
- Enrutamiento de modelo SPA
- Integración de SPA y Adobe Experience Platform Launch
- SPA y procesamiento en el servidor
- SPA Materiales de referencia
- API HTTP
- Fragmentos de contenido
- Fragmentos de experiencias
- Herramientas de desarrollo
- Herramientas de desarrollo
- Herramientas de modernización de AEM
- Editor de cuadro de diálogo
- Herramienta Conversión de cuadro de diálogo
- Desarrollo con CRXDE Lite
- Administración de paquetes con Maven
- Desarrollo de AEM proyectos con Eclipse
- Cómo crear AEM proyectos con Apache Maven
- Desarrollo de AEM proyectos con IntelliJ IDEA
- Cómo utilizar la herramienta VLT
- Cómo utilizar la herramienta Proxy Server
- Extensión de AEM Brackets
- Herramientas para desarrolladores de AEM para Eclipse
- AEM Repo Tool
- Personalización
- ContextHub
- Referencia de la API de JavaScript de ContextHub
- Ampliación de ContextHub
- Agregar ContextHub a páginas y acceder a tiendas
- Ejemplos de candidatos a la tienda de ContextHub
- Tipos de módulos de interfaz de usuario de ContextHub de muestra
- Diagnóstico de ContextHub
- Desarrollo para contenido de destino
- Client Context
- Ampliación de AEM
- Personalización de la creación de páginas
- Personalización de las consolas
- Personalización de vistas de propiedades de página
- Configuración de la página para la edición masiva de las propiedades de página
- Personalizar y ampliar fragmentos de contenido
- Extensión de flujos de trabajo
- Desarrollo y ampliación de flujos de trabajo
- Creación de modelos de flujo de trabajo
- Ampliación de la funcionalidad del flujo de trabajo
- Interactuar con flujos de trabajo mediante programación
- Referencia de pasos de flujo de trabajo
- Prácticas recomendadas del flujo de trabajo
- Referencia del proceso de flujo de trabajo
- Ampliación del administrador de varios sitios
- Seguimiento y análisis
- Cloud Services
- Creación de extensiones personalizadas
- Forms
- Integración de servicios con la consola JMX
- Desarrollo del Editor por lotes
- Ampliación de la IU clásica
- Pruebas
- Planificación
- ¿Qué entornos de prueba se necesitarán?
- Definición de los casos de prueba
- Pruebas: ¿cuándo y con quién?
- Compilar el plan de prueba
- Seguimiento de resultados y envío de comentarios
- Herramientas de prueba y seguimiento
- Aceptación y desactivación
- La próxima versión…
- Listas de comprobación
- Día duro
- Prueba de la interfaz de usuario
- Prácticas recomendadas
- Información general sobre prácticas recomendadas
- Directrices de desarrollo de AEM y prácticas recomendadas
- Prácticas recomendadas de desarrollo
- Arquitectura de contenido
- Arquitectura de software
- Implementación de referencia de We.Retail
- Implementación de referencia de We.Retail
- Probar fragmentos de contenido en We.Retail
- Prueba de componentes principales en We.Retail
- Probar plantillas editables en We.Retail
- Probar un diseño interactivo en We.Retail
- Cómo probar la estructura de sitios globalizados en We.Retail
- Cómo probar fragmentos de experiencias en We.Retail
- Consejos de codificación
- Precauciones del código
- Paquetes OSGI
- Integración de JCR
- Ejemplos de código
- Solución de problemas de consultas lentas
- Web móvil