Menú

Tipos de pruebas de software: diferentes tipos de pruebas con detalles

types software testing

Pruebe Nuestro Instrumento Para Eliminar Los Problemas

¿Cuáles son los diferentes tipos de pruebas de software?

Nosotros, como probadores, conocemos los diversos tipos de pruebas de software, como pruebas funcionales, pruebas no funcionales, pruebas de automatización, pruebas ágiles y sus subtipos, etc.

Cada uno de nosotros se habría encontrado con varios tipos de pruebas en nuestro viaje de pruebas. Es posible que hayamos escuchado algunas y es posible que hayamos trabajado en algunas, pero no todos tienen conocimiento sobre todos los tipos de pruebas.

Diferentes tipos de pruebas de software

Cada tipo de prueba tiene sus propias características, ventajas y desventajas también. Sin embargo, en este artículo, he cubierto casi todos y cada uno de los tipos de pruebas de software que usamos habitualmente en nuestra vida diaria de pruebas.

Vamos a echarles un vistazo.

Lo que vas a aprender:

Diferentes tipos de pruebas de software

A continuación se muestra la lista de algunos tipos comunes de pruebas de software:

Los tipos de pruebas funcionales incluyen:

  • Examen de la unidad
  • Pruebas de integración
  • Prueba del sistema
  • Pruebas de cordura
  • Prueba de humo
  • Prueba de interfaz
  • Pruebas de regresión
  • Prueba beta / de aceptación

Los tipos de pruebas no funcionales incluyen:

  • Pruebas de rendimiento
  • Prueba de carga
  • Pruebas de estrés
  • Prueba de volumen
  • Pruebas de seguridad
  • Prueba de compatibilidad
  • Instalar prueba
  • Prueba de recuperación
  • Prueba de confiabilidad
  • Pruebas de usabilidad
  • Pruebas de conformidad
  • Prueba de localización

Veamos más detalles sobre estos tipos de pruebas.

Tipos de pruebas de software

# 1) Prueba Alfa

Es el tipo de prueba más común utilizado en la industria del software. El objetivo de esta prueba es identificar todos los posibles problemas o defectos antes de lanzarlo al mercado o al usuario.

VPN gratis Japón

Las pruebas alfa se llevan a cabo al final de la fase de desarrollo del software pero antes de las pruebas beta. Aún así, se pueden realizar cambios de diseño menores como resultado de tales pruebas.

Prueba alfa se lleva a cabo en el sitio del desarrollador. Se puede crear un entorno de usuario virtual interno para este tipo de prueba.

# 2) Prueba de aceptación

Un Examen de ingreso lo realiza el cliente y verifica si el flujo de un extremo a otro del sistema se ajusta a los requisitos comerciales o no y si se ajusta a las necesidades del usuario final. El cliente acepta el software solo cuando todas las características y funcionalidades funcionan como se esperaba.

Es la última fase de la prueba, después de la cual el software entra en producción. Esto también se llama Prueba de aceptación del usuario (UAT).

# 3) Pruebas ad-hoc

El propio nombre sugiere que esta prueba se realiza en un ad-hoc base, es decir, sin referencia al caso de prueba y también sin ningún plan o documentación para tal tipo de prueba.

El objetivo de esta prueba es encontrar los defectos y romper la aplicación ejecutando cualquier flujo de la aplicación o cualquier funcionalidad aleatoria.

Las pruebas ad-hoc son una forma informal de encontrar defectos y cualquier persona del proyecto puede realizarlas. Es difícil identificar defectos sin un caso de prueba, pero a veces es posible que los defectos encontrados durante las pruebas ad-hoc no se hayan identificado utilizando los casos de prueba existentes.

# 4) Prueba de accesibilidad

El objetivo de Pruebas de accesibilidad es determinar si el software o la aplicación es accesible para personas discapacitadas o no.

Aquí, discapacidad significa sordos, daltónicos, discapacitados mentales, ciegos, ancianos y otros grupos discapacitados. Se realizan varias comprobaciones, como el tamaño de fuente para discapacitados visuales, el color y el contraste para daltonismo, etc.

# 5) Prueba Beta

Prueba Beta es un tipo formal de prueba de software que realiza el cliente. Se realiza en el entorno real antes de lanzar el producto al mercado para los usuarios finales reales.

Las pruebas beta se llevan a cabo para garantizar que no haya fallas importantes en el software o el producto y que satisfagan los requisitos comerciales desde la perspectiva del usuario final. La prueba beta tiene éxito cuando el cliente acepta el software.

Por lo general, esta prueba la realizan usuarios finales u otras personas. Es la prueba final que se realiza antes de lanzar una aplicación con fines comerciales. Por lo general, la versión Beta del software o producto lanzado está limitada a un cierto número de usuarios en un área específica.

Entonces, el usuario final realmente usa el software y comparte los comentarios con la empresa. La empresa toma las medidas necesarias antes de lanzar el software a todo el mundo.

# 6) Pruebas de back-end

Siempre que se ingresa una entrada o datos en una aplicación de front-end, se almacena en la base de datos y la prueba de dicha base de datos se conoce como Prueba de base de datos o Prueba de backend.

Existen diferentes bases de datos como SQL Server, MySQL y Oracle, etc. La prueba de base de datos implica probar la estructura de la tabla, el esquema, el procedimiento almacenado, la estructura de los datos, etc.

En Back-end Testing, la GUI no está involucrada, los probadores están conectados directamente a la base de datos con el acceso adecuado y los probadores pueden verificar fácilmente los datos ejecutando algunas consultas en la base de datos.

Puede haber problemas identificados como pérdida de datos, interbloqueo, corrupción de datos, etc.durante esta prueba de back-end y estos problemas son fundamentales para solucionarlos antes de que el sistema entre en funcionamiento en el entorno de producción.

# 7) Prueba de compatibilidad del navegador

Es un subtipo de prueba de compatibilidad (que se explica a continuación) y lo realiza el equipo de pruebas.

Prueba de compatibilidad del navegador se realiza para aplicaciones web y garantiza que el software se pueda ejecutar con la combinación de diferentes navegadores y sistemas operativos. Este tipo de prueba también valida si la aplicación web se ejecuta en todas las versiones de todos los navegadores o no.

# 8) Prueba de compatibilidad con versiones anteriores

Es un tipo de prueba que valida si el software recientemente desarrollado o el software actualizado funciona bien con la versión anterior del entorno o no.

La prueba de compatibilidad con versiones anteriores comprueba si la nueva versión del software funciona correctamente con el formato de archivo creado por una versión anterior del software; también funciona bien con tablas de datos, archivos de datos y estructura de datos creada por la versión anterior de ese software.

Si se actualiza alguno de los programas, debería funcionar bien sobre la versión anterior de ese software.

# 9) Prueba de caja negra

El diseño del sistema interno no se considera en este tipo de pruebas. Las pruebas se basan en los requisitos y la funcionalidad.

Información detallada sobre las ventajas, desventajas y tipos de pruebas de caja negra puede ser visto Aquí .

# 10) Prueba de valor límite

Este tipo de prueba verifica el comportamiento de la aplicación en el nivel de los límites.

Prueba de valor límite se realiza para comprobar si existen defectos en los valores límite. La prueba de valor límite se utiliza para probar un rango diferente de números. Hay un límite superior e inferior para cada rango y las pruebas se realizan en estos valores límite.

Si la prueba requiere un rango de prueba de números del 1 al 500, la prueba del valor límite se realiza en los valores 0, 1, 2, 499, 500 y 501.

# 11) Prueba de rama

Es un tipo de prueba de caja blanca y se lleva a cabo durante la prueba unitaria. Prueba de rama, el nombre en sí sugiere que el código se prueba a fondo atravesando cada rama.

# 12) Prueba de comparación

La comparación de las fortalezas y debilidades de un producto con sus versiones anteriores u otros productos similares se denomina Prueba de comparación.

# 13) Prueba de compatibilidad

Es un tipo de prueba en el que valida cómo se comporta y se ejecuta el software en un entorno, servidores web, hardware y entorno de red diferentes.

Pruebas de compatibilidad asegura que el software pueda ejecutarse en una configuración diferente, una base de datos diferente, diferentes navegadores y sus versiones. Las pruebas de compatibilidad las realiza el equipo de pruebas.

# 14) Prueba de componentes

En su mayoría, los desarrolladores lo realizan después de completar las pruebas unitarias. Prueba de componentes implica probar múltiples funcionalidades como un solo código y su objetivo es identificar si existe algún defecto después de conectar esas múltiples funcionalidades entre sí.

# 15) Prueba de extremo a extremo

Similar a las pruebas del sistema, Pruebas de extremo a extremo implica probar un entorno de aplicación completo en una situación que imita el uso en el mundo real, como interactuar con una base de datos, usar comunicaciones de red o interactuar con otro hardware, aplicaciones o sistemas, si corresponde.

# 16) Partición de equivalencia

Es una técnica de prueba y un tipo de prueba de caja negra. Durante esto Partición de equivalencia , se selecciona un conjunto del grupo y se toman algunos valores o números para probarlos. Se entiende que todos los valores de ese grupo generan el mismo resultado.

El objetivo de esta prueba es eliminar los casos de prueba redundantes dentro de un grupo específico que genera la misma salida pero no ningún defecto.

Supongamos que la aplicación acepta valores entre -10 y +10, por lo que, al utilizar la división de equivalencia, los valores recogidos para la prueba son cero, un valor positivo y un valor negativo. Entonces, el Particionamiento de Equivalencia para esta prueba es de -10 a -1, 0 y de 1 a 10.

# 17) Prueba de ejemplo

Significa pruebas en tiempo real. La prueba de ejemplo incluye el escenario en tiempo real, también involucra los escenarios basados ​​en la experiencia de los probadores.

# 18) Pruebas exploratorias

Las pruebas exploratorias son pruebas informales realizadas por el equipo de pruebas. El objetivo de esta prueba es explorar la aplicación y buscar defectos que existen en la aplicación.

A veces puede suceder que durante esta prueba se descubra un defecto importante que incluso pueda provocar una falla del sistema.

Durante las Pruebas exploratorias, es aconsejable llevar un registro de qué flujo ha probado y qué actividad realizó antes del inicio del flujo específico.

Una técnica de prueba exploratoria se realiza sin documentación ni casos de prueba.

# 20) Prueba funcional

Este tipo de prueba ignora las partes internas y se enfoca solo en la salida para verificar si cumple con el requisito o no. Es una prueba de tipo caja negra orientada a los requisitos funcionales de una aplicación. Para obtener información detallada sobre las pruebas funcionales, haga clic en Aquí .

# 21) Prueba de interfaz gráfica de usuario (GUI)

El objetivo de esta prueba de GUI es validar la GUI según los requisitos comerciales. La GUI esperada de la aplicación se menciona en las pantallas de maqueta del Documento de diseño detallado y de la GUI.

La prueba de GUI incluye el tamaño de los botones y el campo de entrada presentes en la pantalla, la alineación de todo el texto, las tablas y el contenido de las tablas.

cómo usar el selector css en selenium

También valida el menú de la aplicación, luego de seleccionar diferentes menús y elementos de menú, valida que la página no fluctúe y la alineación permanece igual después de pasar el mouse sobre el menú o submenú.

# 22) Prueba de gorila

Gorilla Testing es un tipo de prueba realizado por un evaluador y, a veces, también por el desarrollador. En Gorilla Testing, un módulo o la funcionalidad en el módulo se prueba de manera exhaustiva y exhaustiva. El objetivo de esta prueba es comprobar la solidez de la aplicación.

# 23) Prueba de camino feliz

El objetivo de Happy Path Testing es probar una aplicación con éxito en un flujo positivo. No busca condiciones negativas o de error. La atención se centra solo en las entradas válidas y positivas a través de las cuales la aplicación genera la salida esperada.

# 24) Prueba de integración incremental

Prueba de integración incremental es un enfoque ascendente para las pruebas, es decir, la prueba continua de una aplicación cuando se agrega una nueva funcionalidad. La funcionalidad y los módulos de la aplicación deben ser lo suficientemente independientes como para probarlos por separado. Esto lo hacen programadores o probadores.

# 25) Prueba de instalación / desinstalación

Prueba de instalación y desinstalación se realiza en procesos de instalación / desinstalación completos, parciales o de actualización en diferentes sistemas operativos en diferentes entornos de hardware o software.

# 26) Prueba de integración

La prueba de todos los módulos integrados para verificar la funcionalidad combinada después de la integración se denomina Pruebas de integración .

Los módulos son típicamente módulos de código, aplicaciones individuales, aplicaciones de cliente y servidor en una red, etc. Este tipo de prueba es especialmente relevante para los sistemas cliente / servidor y distribuidos.

# 27) Prueba de carga

Es un tipo de prueba no funcional y el objetivo de la prueba de carga es verificar cuánta carga o carga de trabajo máxima puede manejar un sistema sin ninguna degradación del rendimiento.

Las pruebas de carga ayudan para encontrar la capacidad máxima del sistema bajo una carga específica y cualquier problema que cause una degradación del rendimiento del software. La prueba de carga se realiza utilizando herramientas como JMeter , LoadRunner, WebLoad, Silk performer, etc.

# 28) Prueba de mono

Prueba de mono Lo lleva a cabo un probador asumiendo que si el mono usa la aplicación, entonces el modo de entrada aleatorio, los valores serán ingresados ​​por el mono sin ningún conocimiento o comprensión de la aplicación.

El objetivo de Monkey Testing es comprobar si una aplicación o sistema se bloquea proporcionando valores / datos de entrada aleatorios. Monkey Testing se realiza de forma aleatoria y no se escriben casos de prueba y no es necesario

Monkey Testing se realiza de forma aleatoria y no se codifican casos de prueba y no es necesario conocer la funcionalidad completa del sistema.

# 29) Prueba de mutación

Prueba de mutación es un tipo de prueba de caja blanca en la que se cambia el código fuente de uno de los programas y verifica si los casos de prueba existentes pueden identificar estos defectos en el sistema.

El cambio en el código fuente del programa es mínimo para que no afecte a toda la aplicación, solo el área específica que tiene el impacto y los casos de prueba relacionados deberían poder identificar esos errores en el sistema.

# 30) Prueba negativa

Los probadores que tienen la mentalidad de 'actitud para romper' y que utilizan pruebas negativas lo validan si el sistema o la aplicación se rompe. Una técnica de prueba negativa se realiza utilizando datos incorrectos, datos no válidos o entrada. Valida que si el sistema arroja un error de entrada no válida y se comporta como se esperaba.

# 31) Pruebas no funcionales

Es un tipo de prueba para la cual cada organización tiene un equipo separado que generalmente se denomina equipo de prueba no funcional (NFT) o equipo de rendimiento.

Pruebas no funcionales implica probar requisitos no funcionales como pruebas de carga, pruebas de estrés, seguridad, volumen, pruebas de recuperación, etc. El objetivo de las pruebas NFT es garantizar si el tiempo de respuesta del software o la aplicación es lo suficientemente rápido según los requisitos comerciales.

No debería llevar mucho tiempo cargar ninguna página o sistema y debería mantenerse durante la carga máxima.

# 32) Prueba de rendimiento

Este término a menudo se usa indistintamente con pruebas de 'estrés' y 'carga'. Pruebas de rendimiento se realiza para comprobar si el sistema cumple con los requisitos de rendimiento. Se utilizan diferentes herramientas de rendimiento y carga para realizar esta prueba.

# 33) Prueba de recuperación

Es un tipo de prueba que valida qué tan bien la aplicación o el sistema se recupera de fallas o desastres.

La prueba de recuperación determina si el sistema puede continuar la operación después de un desastre. Suponga que la aplicación está recibiendo datos a través del cable de red y, de repente, el cable de red se ha desconectado.

Algún tiempo después, conecte el cable de red; entonces el sistema debería comenzar a recibir datos desde donde perdió la conexión debido a que el cable de red se desconectó.

# 34) Prueba de regresión

Probar una aplicación como un todo para la modificación en cualquier módulo o funcionalidad se denomina Prueba de regresión. Es difícil cubrir todo el sistema en Pruebas de regresión , tan típicamente Herramientas de prueba de automatización se utilizan para este tipo de pruebas.

# 35) Pruebas basadas en riesgos (RBT)

En Pruebas basadas en riesgos , las funcionalidades o requisitos se prueban en función de su prioridad. Las pruebas basadas en riesgos incluyen pruebas de funciones muy críticas, que tienen el mayor impacto en el negocio y en las que la probabilidad de falla es muy alta.

La decisión de prioridad se basa en la necesidad empresarial, por lo que una vez que se establece la prioridad para todas las funcionalidades, primero se ejecutan las funciones de alta prioridad o los casos de prueba, seguidas de las de prioridad media y luego de baja.

La funcionalidad de baja prioridad puede probarse o no probarse en función del tiempo disponible.

La prueba basada en riesgos se lleva a cabo si no hay suficiente tiempo disponible para probar todo el software y el software debe implementarse a tiempo y sin demora. Este enfoque es seguido únicamente por la discusión y aprobación del cliente y la alta dirección de la organización.

# 36) Prueba de cordura

Pruebas de cordura se realiza para determinar si una nueva versión de software está funcionando lo suficientemente bien como para aceptarla para un esfuerzo de prueba importante o no. Si una aplicación falla durante el uso inicial, el sistema no es lo suficientemente estable para realizar más pruebas. Por lo tanto, se asigna una compilación o una aplicación para solucionarlo.

# 37) Prueba de seguridad

Es un tipo de prueba realizada por un equipo especial de probadores. Un sistema puede ser penetrado por cualquier método de piratería.

Pruebas de seguridad se realiza para comprobar cómo el software, la aplicación o el sitio web están protegidos frente a amenazas internas y externas. Esta prueba incluye cuánto software está protegido del programa malicioso, virus y qué tan seguros y sólidos son los procesos de autorización y autenticación.

También verifica cómo se comporta el software ante cualquier ataque de piratas informáticos y programas maliciosos, y cómo se mantiene el software para la seguridad de los datos después de dicho ataque.

# 38) Prueba de humo

Siempre que el equipo de desarrollo proporciona una nueva compilación, el equipo de pruebas de software valida la compilación y se asegura de que no exista ningún problema importante.

El equipo de pruebas se asegura de que la construcción sea estable y se lleve a cabo un nivel detallado de pruebas. Prueba de humo comprueba que no exista ningún defecto en la construcción, lo que evitará que el equipo de pruebas pruebe la aplicación en detalle.

Si los evaluadores descubren que la funcionalidad crítica principal se descompone en la etapa inicial, el equipo de prueba puede rechazar la compilación e informar al equipo de desarrollo en consecuencia. Las pruebas de humo se llevan a cabo a un nivel detallado de cualquier prueba funcional o de regresión.

# 39) Prueba estática

La prueba estática es un tipo de prueba que se ejecuta sin ningún código. La ejecución se realiza sobre la documentación durante la fase de prueba.

Implica revisiones, recorridos e inspección de los entregables del proyecto. Static Testing no ejecuta el código en lugar de la sintaxis del código, se verifican las convenciones de nomenclatura.

Pruebas estáticas también es aplicable para casos de prueba, plan de prueba, documento de diseño. Es necesario realizar pruebas estáticas por parte del equipo de pruebas, ya que los defectos identificados durante este tipo de pruebas son rentables desde la perspectiva del proyecto.

# 40) Prueba de estrés

Esta prueba se realiza cuando un sistema se esfuerza más allá de sus especificaciones para verificar cómo y cuándo falla. Esto se realiza bajo una carga pesada, como colocar un gran número más allá de la capacidad de almacenamiento, consultas complejas de bases de datos, entrada continua al sistema o carga de la base de datos.

# 41) Prueba del sistema

Debajo Técnica de prueba del sistema , todo el sistema se prueba según los requisitos. Es una prueba de tipo caja negra que se basa en especificaciones de requisitos generales y cubre todas las partes combinadas de un sistema.

la mejor herramienta de captura de pantalla para Windows 10

# 42) Prueba unitaria

La prueba de un componente o módulo de software individual se denomina Examen de la unidad . Por lo general, lo realiza el programador y no los probadores, ya que requiere un conocimiento detallado del diseño y el código internos del programa. También puede requerir el desarrollo de módulos de controlador de prueba o arneses de prueba.

# 43) Pruebas de usabilidad

Debajo Pruebas de usabilidad , Se realiza la verificación de facilidad de uso. El flujo de la aplicación se prueba para saber si un nuevo usuario puede entender la aplicación fácilmente o no. Se documenta la ayuda adecuada si un usuario se atasca en algún momento. Básicamente, la navegación del sistema se verifica en esta prueba.

# 44) Prueba de vulnerabilidad

Las pruebas que implican la identificación de debilidades en el software, el hardware y la red se conocen como pruebas de vulnerabilidad. Programas maliciosos, el hacker puede tomar el control del sistema, si es vulnerable a este tipo de ataques, virus y gusanos.

Por lo tanto, es necesario verificar si esos sistemas se someten a pruebas de vulnerabilidad antes de la producción. Puede identificar defectos críticos, fallas en la seguridad.

# 45) Prueba de volumen

Prueba de volumen es un tipo de prueba no funcional realizada por el equipo de pruebas de rendimiento.

El software o la aplicación se somete a una gran cantidad de datos y las pruebas de volumen verifican el comportamiento del sistema y el tiempo de respuesta de la aplicación cuando el sistema encuentra un volumen de datos tan alto. Este alto volumen de datos puede afectar el rendimiento del sistema y la velocidad del tiempo de procesamiento.

# 46) Prueba de caja blanca

Prueba de caja blanca se basa en el conocimiento de la lógica interna del código de una aplicación.

También se conoce como prueba de caja de vidrio. El software interno y el funcionamiento del código deben ser conocidos para realizar este tipo de pruebas. Bajo estas pruebas se basan en la cobertura de declaraciones de código, ramas, rutas, condiciones, etc.

Conclusión

Los tipos de pruebas de software mencionados anteriormente son solo una parte de las pruebas. Sin embargo, todavía hay una lista de más de 100 tipos de pruebas, pero no todos los tipos de pruebas se utilizan en todos los tipos de proyectos. Así que he cubierto algunos tipos comunes de pruebas de software que se utilizan principalmente en el ciclo de vida de las pruebas.

Además, existen definiciones o procesos alternativos utilizados en diferentes organizaciones, pero el concepto básico es el mismo en todas partes. Estos tipos de pruebas, procesos y sus métodos de implementación siguen cambiando a medida que cambian el proyecto, los requisitos y el alcance.

Lectura recomendada

^