¿Qué son las pruebas de aplicaciones?
Tomas Hamilton
⚡ Resumen inteligente
Las pruebas de aplicaciones validan el producto de software completo, no solo una unidad, abarcando la interfaz, la funcionalidad, la base de datos y el comportamiento bajo carga. Esta página explica el ciclo de vida de cuatro etapas, las tres metodologías de prueba, la planificación de pruebas, las herramientas, las métricas y las prácticas específicas para dispositivos móviles.
¿Qué son las pruebas de aplicaciones?
Las pruebas de aplicaciones se definen como un tipo de prueba de software realizada a través de scripts con el motivo de encontrar errores en el software. Se trata de pruebas para toda la aplicación.
Ayuda a mejorar la calidad de sus aplicaciones al mismo tiempo que reduce costos, maximiza el retorno de la inversión y ahorra tiempo de desarrollo.
En Ingeniería de Software, las pruebas de aplicaciones se pueden realizar en varias categorías como GUI, funcionalidad, base de datos (backend), prueba de carga, etc.
Para las pruebas de aplicaciones, los ciclos de vida de las pruebas implican varias fases que incluyen análisis de requisitos, planificación de pruebas, análisis de pruebas, diseño de pruebas, ejecución de pruebas e informes de errores, etc.
Esas fases se resumen en un ciclo de vida corto y repetible que sigue toda aplicación.
¿Cómo probar una aplicación?
Las aplicaciones y productos de software tienen una serie de variaciones en términos de las características que admiten y los procesos que implementan. Por lo tanto, las pruebas de aplicaciones garantizan que un programa o aplicación en particular funcione correctamente.
El ciclo de vida de las pruebas de aplicaciones consta de cuatro etapas.
- Nivel 1) Diseñar planes de prueba basados en los requisitos de la aplicación.
- Nivel 2) Desarrollar casos de prueba manuales y scripts de prueba automatizados.
- Nivel 3) Ejecutar pruebas funcionales para validar los requisitos de la aplicación.
- Nivel 4) Ejecute pruebas de carga y ajuste el rendimiento de la aplicación
El tipo de pruebas ejecutadas depende del tipo de aplicación bajo prueba. Las pruebas de aplicaciones se clasifican en 3 segmentos.
- Pruebas de aplicaciones web
- Pruebas de aplicaciones de escritorio
- Prueba de aplicaciones móviles
| Prueba de aplicación | Tipos de pruebas realizadas |
|---|---|
|
|
|
|
|
|
Comparativa de pruebas de aplicaciones web, de escritorio y móviles
Los tres segmentos comparten un ciclo de vida, pero difieren notablemente en lo que realmente falla. Saber dónde se concentra el riesgo permite determinar dónde invertir el presupuesto para las pruebas.
| Punto de diferencia | Web (Opcional) | Escritorio | Móvil |
|---|---|---|---|
| Se ejecuta en | Un navegador a través de una red | Una máquina instalada | Un teléfono o una tableta |
| Variable principal | Navegador y versión | Operasistema de ting y hardware | Dispositivo, versión del sistema operativo y tamaño de la pantalla |
| dependencia de la red | Siempre conectado | A menudo desconectado | Intermitente, y debe sobrevivir a la pérdida. |
| El mayor riesgo | Renderizado y carga entre navegadores | Instalación y compatibilidad | Fragmentación entre dispositivos |
| Manejo de interrupciones | Rara vez relevante | Rara vez relevante | Llamadas, notificaciones y batería baja |
| Ruta de actualización | Servidor, instantáneo para todos | El usuario instala un parche | Revisión en la tienda de aplicaciones, lanzamiento por fases |
Los dispositivos móviles presentan la mayor cantidad de variables incontrolables, por lo que se tratan por separado más adelante en esta página.
Metodologías de prueba de aplicaciones
La metodología de pruebas es la forma estructurada de garantizar que una aplicación de software se haya probado exhaustivamente. Una metodología de pruebas desorganizada y deficiente puede dar lugar a un producto inestable.
Hay tres formas de realizar las pruebas.
- Negro Box Pruebas
- Blanco Box Pruebas
- Gris Box Pruebas
Negro Box Pruebas
Negro Box Pruebas La técnica se utiliza comúnmente para realizar pruebas. Pruebas funcionales, Pruebas no funcionales, y pruebas de regresión. En las pruebas de caja negra, las estrategias utilizadas son:
- Prueba de clase de equivalencia
- Prueba de valor límite
- Tabla de decisiones
- Tablas de transición de estado
Blanco Box Pruebas
Prueba de caja blanca Se utiliza normalmente para probar el código del software para comprobar fallos de seguridad internos, rutas rotas o mal estructuradas, funcionalidad de bucles condicionales, etc. En las pruebas de caja blanca, las estrategias utilizadas son:
- Code Análisis de cobertura
- Cobertura de ruta
Gris Box Pruebas
Esta técnica de prueba es una combinación de Black Box Pruebas y pruebas de caja blanca. Se lleva a cabo para encontrar Defectos basado en una estructura o uso inadecuado de la aplicación.
Plan de pruebas para pruebas de aplicaciones
El Plan de prueba El documento se deriva del Producto. Description, especificación de requisitos de software SRS o documentos de casos de uso. El objetivo de la prueba es qué probar, cómo probar, cuándo probar y quién lo probará. El documento del plan de pruebas se utiliza como medio de comunicación entre el equipo de pruebas y los administradores de pruebas.
Un plan de pruebas estándar para pruebas de aplicaciones debe definir las siguientes características:
- Definir el alcance de las pruebas.
- Definir el objetivo de la prueba.
- Enfoque para la actividad de prueba.
- Calendario de pruebas
- Error tracrey y reportes
Criterios de entrada y salida para las pruebas de la aplicación
El plan de pruebas incluye criterios formales de entrada y salida como buena práctica, pero conviene detallarlos. Sin ellos, una fase de pruebas comienza con una versión inestable o se prolonga sin un objetivo definido.
Los criterios de ingreso debe cumplirse antes de que comience la ejecución.
- Se revisan y se establecen los requisitos y el SRS.
- El plan de pruebas y los casos de prueba están redactados y aprobados.
- La compilación se implementa en un entorno de prueba estable y supera una prueba básica.
- Los datos de prueba y las cuentas o dispositivos necesarios están disponibles.
- Un defecto tracLa herramienta King está configurada y el equipo tiene acceso.
Criterio de salida demostrar que la fase ha cumplido su propósito.
- Se ejecutan todos los casos de prueba planificados y se registran los resultados.
- No quedan defectos críticos o de alta gravedad sin resolver.
- Se logra la cobertura acordada con respecto a los requisitos.
- Los defectos restantes de baja gravedad se documentan y son aceptados por la empresa.
- El informe resumido de la prueba está firmado.
Herramientas de prueba de aplicaciones
Existen varias herramientas de prueba para las pruebas de aplicaciones. La selección de herramientas depende del tipo de prueba que desee realizar. Para diferentes plataformas se recomiendan diferentes herramientas. Las herramientas de prueba de aplicaciones garantizan el rendimiento, la usabilidad y la funcionalidad de las aplicaciones en una variedad de dispositivos.
Éstos son algunos de ellos.
- Selenium
- IBM Rational Functional Tester (RFT)
- LoadRunner (Ahora es el OpenText LoadRunner, anteriormente HP y Micro Focus)
- Apache JMeter
💡 Nota: IBM Rational Robot, que figuraba desde hace tiempo junto con RFT, ha sido retirado del mercado. Rational Functional Tester es el actual IBM ofreciendo, por lo que los nuevos proyectos no deberían planificarse en torno a Robot.
Métricas clave para las pruebas de aplicaciones
La ejecución de pruebas demuestra actividad, no eficacia. Un pequeño conjunto de métricas muestra si las pruebas realmente detectan defectos y si la aplicación se está acercando a la calidad de lanzamiento.
- Cobertura de prueba: Porcentaje de requisitos con al menos un caso de prueba mapeado. Una cobertura baja significa que el comportamiento no ha sido probado, independientemente de lo que indique la tasa de aprobación.
- Densidad de defectos: Los defectos se clasifican por tamaño, generalmente por cada mil líneas de código o por módulo. Esto permite identificar los componentes que necesitan reelaboración en lugar de realizar más pruebas.
- Fuga por defecto: Defectos detectados en producción divididos por el total de defectos detectados. El aumento de las fugas es la señal más clara de que las pruebas previas al lanzamiento no cumplen con los requisitos.
- Eficiencia en la eliminación de defectos: Defectos detectados antes del lanzamiento como porcentaje del total de defectos. Un valor superior al noventa por ciento es un objetivo común.
- Tasa de ejecución de pruebas: Los casos se ejecutan contra los casos planificados, tracked por ciclo para que el deslizamiento sea visible pronto en lugar de en la puerta de salida.
TracEs importante analizar la tendencia en lugar de una sola lectura. Un ciclo aislado no aporta mucha información.
Mejores prácticas de prueba para pruebas de aplicaciones
Seleccionar la estrategia adecuada para las pruebas de aplicaciones es una forma garantizada de detectar defectos en la aplicación. Por lo tanto, resulta extremadamente importante que el equipo de control de calidad siga un conjunto de procesos estándar para detectar más errores y en menos tiempo.
Para las pruebas de aplicaciones, algunas de las mejores prácticas incluyen
- Definir especificaciones funcionales.
- RevVistas e inspecciones
- Criterios formales de entrada y salida
- Variaciones de pruebas funcionales
- Pruebas multiplataforma
- Ejecución de pruebas automatizada
Desafíos de las pruebas de aplicaciones
Al probar una aplicación, un evaluador puede encontrarse con muchos desafíos.
- Los problemas solo se identifican cuando el usuario llama
- Incapacidad para anticipar el impacto del cambio.
- Sin visibilidad de los errores operativos y de aplicación
- Pérdida de tiempo
Prueba de aplicaciones móviles
Al igual que las pruebas de aplicaciones web, Móvil Las pruebas de aplicaciones también se basan en la misma estrategia y metodología de prueba. La diferencia podría estar en las herramientas utilizadas para las pruebas; algunas herramientas comunes utilizadas para las pruebas de aplicaciones móviles son: Appium, TestComplete, Robotium, y Espresso.
Los tipos de aplicaciones móviles se clasifican en tres secciones.
- Aplicación web: los usuarios acceden a ella a través de una red como Internet o una intranet.
- Aplicación nativa: está desarrollada para una plataforma específica y se instala en un dispositivo informático.
- Aplicación híbrida: combina elementos tanto web como nativos, por ejemplo Facebook.
Para la mayoría de las plataformas móviles, puede utilizar CSS, HTML, JS, etc. simples.
Casos de prueba de ejemplo para pruebas de aplicaciones móviles
Una estrategia completa de aplicación de prueba móvil incluye infraestructura de red y dispositivo, selección de dispositivos de destino y una combinación efectiva de herramientas de prueba manuales y automatizadas para cubrir ambos. pruebas funcionales y no funcionales.
Para aplicaciones móviles, las cosas que se deben probar son
- Instalación
- OTA
- Wi-Fi
- Cable de datos
- Bluetooth
- Desinstalación
- Logotipo de la aplicación
- chapoteo
- Memoria baja
- Comentarios visuales
- Solicitud de salida
- Inicio/Reinicio de la Aplicación
Desafíos de las pruebas móviles
Con el creciente número de usuarios y dispositivos móviles, probar una aplicación móvil se vuelve cada vez más complejo. Probar una aplicación móvil es significativamente diferente a probar una aplicación web de escritorio. Los desafíos comunes que se presentan durante las pruebas móviles son:
- Cobertura integral de pruebas
- Gestión de la fragmentación (diferente versión del sistema operativo, procesador, memoria)
- Falta de plan de prueba
- La presión del tiempo
- Falta de dispositivos físicos
- Diversidad en plataforma y sistema operativo
