¿Cuántos tipos de pruebas de software hay?

Suponga que ya sabe qué son las pruebas de software, así que solo hablo sobre los diferentes tipos de pruebas que se pueden usar para probar un software.

Prueba manual

La prueba manual incluye probar un software de forma manual, es decir, sin utilizar ningún software automatizado.
herramienta o cualquier script. En este tipo, el probador asume el rol de usuario final y prueba
el software para identificar cualquier comportamiento inesperado o error. Hay diferentes etapas de
pruebas manuales como pruebas unitarias, pruebas de integración, pruebas de sistema y usuario
test de aceptación.
Los probadores usan planes de prueba, casos de prueba o escenarios de prueba para probar un software y garantizar que
integridad de las pruebas. Las pruebas manuales también incluyen pruebas exploratorias, como probadores
Explore el software para identificar errores en él.

Pruebas de automatización

La prueba de automatización, que también se conoce como Automatización de prueba, es cuando el probador escribe
scripts y utiliza otro software para probar el producto. Este proceso implica la automatización.
de un proceso manual. Las pruebas de automatización se utilizan para volver a ejecutar los escenarios de prueba que fueron
realizado de forma manual, rápida y repetida.

Además de las pruebas de regresión, las pruebas de automatización también se utilizan para probar la aplicación.
desde el punto de vista de la carga, el rendimiento y el estrés. Aumenta la cobertura de prueba,
mejora la precisión y ahorra tiempo y dinero en comparación con las pruebas manuales.

¿Qué automatizar?

No es posible automatizar todo en un software. Las áreas en las que un usuario puede
realizar transacciones como el formulario de inicio de sesión o los formularios de registro, cualquier área donde sea grande
El número de usuarios que pueden acceder al software simultáneamente debe ser automatizado.

Además, todos los elementos GUI, conexiones con bases de datos, validaciones de campo, etc. pueden ser
probado eficientemente mediante la automatización del proceso manual.

¿Cuándo automatizar?

¿Por qué debería aplicar la automatización de prueba?

La automatización de pruebas se debe utilizar considerando los siguientes aspectos de un software:

• Proyectos grandes y críticos.
• Proyectos que requieren probar las mismas áreas con frecuencia
• Los requisitos no cambian con frecuencia
• Accediendo a la aplicación para carga y rendimiento con muchos usuarios virtuales
• Software estable con respecto a las pruebas manuales.
• Disponibilidad de tiempo

¿Cómo automatizar?

La automatización se realiza mediante el uso de un lenguaje informático de apoyo como VB scripting y un
Aplicación de software automatizada. Hay muchas herramientas disponibles que pueden usarse para escribir
guiones de automatización. Antes de mencionar las herramientas, identifiquemos el proceso que puede ser
utilizado para automatizar el proceso de prueba:

• Identificar áreas dentro de un software para la automatización.
• Selección de la herramienta adecuada para la automatización de pruebas.
• Escribir guiones de prueba
• Desarrollo de trajes de prueba.
• Ejecución de guiones
• Crear informes de resultados
• Identifique cualquier error potencial o problemas de rendimiento

Herramientas de prueba de software

Las siguientes herramientas se pueden utilizar para pruebas de automatización:

• HP Quick Test Professional
• Selenio
• Katalon Studio
• TestComplete
• WinRunner
• WATIR

Puede consultar este artículo para obtener más detalles sobre cómo elegir la mejor herramienta para su proyecto de automatización.

Hola,

Sería genial saber que las pruebas de software se dividen en diferentes categorías y cada una de ellas tiene un objetivo definido, una estrategia de prueba y entregas de prueba. El objetivo básico de tener un tipo de prueba es validar la Aplicación bajo prueba (AUT) para el Objetivo de prueba definido. Los siguientes servicios de prueba están cubiertos por casi todos los principales proveedores de servicios de garantía de calidad.

Las técnicas de prueba comunes se mencionan a continuación.

1. Pruebas funcionales o pruebas funcionales comerciales :
Todas las funciones en las aplicaciones se prueban contra el documento de requisitos para asegurarse de que el producto cumpla con las especificaciones (requisitos funcionales). Verificar que las funciones comerciales cruciales estén funcionando en la aplicación. Las funciones comerciales se definen generalmente en el documento de requisitos. Cada función comercial tiene ciertas reglas, que no se pueden romper. Ya sea que estén relacionados con la interfaz de usuario o el back-end, ambos niveles deben ser verificados. Las funciones comerciales pueden abarcar varias ventanas o varias opciones de menú, por lo que simplemente probar que todas las ventanas y menús pueden usarse no es suficiente para verificar las funciones comerciales. Debe verificar las funciones comerciales como unidades discretas como,
* Estudiar SRS
* Identificar funciones de la unidad
* Identificar clase de equivalencia (ECP)
* Formulario de casos de prueba
* Casos de prueba de formulario para valores límite
* De casos de prueba para adivinar errores
* Función de unidad de formulario v / s Casos de prueba, matriz de referencia cruzada

a. Prueba de humo
Las pruebas de humo generalmente están automatizadas y su ejecución demora menos de 2-3 horas. Estos casos de prueba verifican la funcionalidad principal en un nivel superior. El objetivo es determinar si es posible realizar más pruebas. Estos casos de prueba enfatizan más la amplitud que la profundidad. Todos los componentes se tocan, y la prueba de humo prueba brevemente todas las características principales. Si alguna prueba de humo falla, lo más probable es que sea un problema crítico / mayor / bloqueante.

si. Prueba de cordura
Normalmente, un esfuerzo de prueba inicial para determinar si una nueva versión de software está funcionando lo suficientemente bien como para aceptarla para un esfuerzo de prueba importante. Las pruebas de cordura siguen un enfoque estrecho y profundo con pruebas detalladas de algunas características limitadas.

do. Pruebas de regresión
El objetivo de las pruebas de regresión es garantizar que el software permanezca intacto. Se mantiene y ejecuta un conjunto básico de datos y scripts para verificar que los cambios introducidos durante el lanzamiento no hayan “deshecho” ningún código anterior. Los resultados esperados de la línea de base se comparan con los resultados del software que se prueba la regresión. Todas las discrepancias se resaltan y se tienen en cuenta, antes de proceder a nuevas compilaciones.

re. Prueba de regresión de errores
Cada error que estaba “Abierto” durante la compilación anterior, pero marcado como “Corregido, necesita volver a probar” para la compilación actual bajo prueba, deberá ser regresado. Una vez que se completa la prueba de humo, todos los errores resueltos deben ser regresados.

2. Pruebas de automatización
Requiere herramientas para escribir y ejecutar casos de prueba, Tester no tiene participación manual mientras ejecuta un conjunto de pruebas automatizadas. El probador escribe los guiones de prueba y los casos de prueba utilizando la herramienta y luego los agrupa en conjuntos de pruebas. Después de la ejecución, el probador debe buscar cualquier falla o Falso positivo y analizarlo. El script se actualiza / modifica en consecuencia y se ejecuta nuevamente hasta que se obtienen los resultados requeridos / esperados.

3. Pruebas de rendimiento
a. Las pruebas de rendimiento están diseñadas para probar el rendimiento en tiempo de ejecución del software en un sistema integrado. Si todos los elementos del sistema no están completamente integrados y certificados como libres de defectos, el verdadero rendimiento de un sistema no se puede lograr con éxito.

si. Las pruebas de rendimiento a menudo se combinan con pruebas de estrés y a menudo requieren infraestructura de hardware y software. Es necesario medir la utilización de los recursos. La instrumentación externa puede monitorear intervalos, registrar eventos. A través de esta prueba, el probador puede descubrir situaciones que conducen a la degradación y posible falla del sistema.

do. Prueba de volumen
Pruebe las aplicaciones con una gran cantidad de datos y vea si la aplicación produce los resultados anticipados. ( Grandes cantidades de datos )

re. Pruebas de estrés
Probar la respuesta de la aplicación cuando hay escasez de recursos del sistema ( demasiados usuarios, demasiados datos, muy poco tiempo y muy poco espacio )

mi. Prueba de carga
Verifica el rendimiento del servidor bajo el estrés de muchos clientes que solicitan datos al mismo tiempo ( Gran cantidad de usuarios )

7. Pruebas de seguridad
Las pruebas de seguridad proporcionan seguridad contra todos los ataques cibernéticos. Prueba todo el área de seguridad de la aplicación.

8. Pruebas de base de datos
Se realiza manualmente en tiempo real, verifica el flujo de datos entre el front-end y el back-end. La prueba de la base de datos requiere que el probador tenga experiencia en la realización de consultas.

9. Pruebas unitarias
Prueba de unidad, una técnica de prueba que requiere probar la funcionalidad mientras se crea su módulo. El objetivo principal es aislar cada unidad del sistema. Esto es realizado principalmente por los desarrolladores.

10. Pruebas de integración
Una vez completadas las pruebas de cada unidad, el probador lo prueba agregando módulos individuales y probándolos como una sola unidad. Este tipo de prueba es realizada por el Equipo de prueba.

11. Prueba del sistema
La prueba del equipo de prueba completa la prueba del sistema después de combinar cada módulo y submódulo. Las pruebas del sistema se consideran completas cuando los resultados reales y los resultados esperados están en línea o las diferencias son explicables / aceptables en función de los comentarios del cliente.

Dependiendo de los requisitos del proyecto, los equipos de control de calidad realizan los tipos de pruebas anteriores.

Espero que la información descrita anteriormente ayude a comprender varios tipos de pruebas realizadas en la industria de TI. Avíseme si necesita información sobre alguna prueba específica. Estaría más feliz de compartir información y mi experiencia en esa área.

Saludos,
Anand

La prueba de software es el proceso de evaluación de un elemento de software para detectar diferencias entre la entrada dada y la salida esperada. También para evaluar la característica de un elemento de software. Las pruebas evalúan la calidad del producto. La prueba de software es un proceso que debe realizarse durante el proceso de desarrollo. En otras palabras, la prueba de software es un proceso de verificación y validación.

Conceptos básicos de las pruebas de software.

Hay dos conceptos básicos de las pruebas de software: pruebas de Blackbox y pruebas de whitebox.

Prueba de Blackbox

La prueba de caja negra es una técnica de prueba que ignora el mecanismo interno del sistema y se enfoca en la salida generada contra cualquier entrada y ejecución del sistema. También se llama prueba funcional.

Prueba de caja blanca

La prueba de caja blanca es una técnica de prueba que tiene en cuenta el mecanismo interno de un sistema. También se llama prueba estructural y prueba de caja de vidrio.

Las pruebas de recuadro negro a menudo se usan para la validación y las pruebas de recuadro blanco a menudo se usan para verificación.

Tipos de pruebas

Hay muchos tipos de pruebas como

Examen de la unidad

Pruebas de integración

Pruebas Funcionales

Prueba de sistema

Pruebas de estrés

Pruebas de rendimiento

Pruebas de usabilidad

Test de aceptación

Pruebas de regresión

Prueba beta

Examen de la unidad

La prueba de unidad es la prueba de una unidad individual o grupo de unidades relacionadas. Se incluye en la clase de pruebas de caja blanca. A menudo el programador lo hace para probar que la unidad que ha implementado está produciendo la salida esperada contra la entrada dada.

Pruebas de integración

Las pruebas de integración son pruebas en las que se combina un grupo de componentes para producir resultados. Además, la interacción entre software y hardware se prueba en pruebas de integración si los componentes de software y hardware tienen alguna relación. Puede caer bajo la prueba de caja blanca y la prueba de caja negra.

Pruebas Funcionales

La prueba funcional es la prueba para garantizar que funcione la funcionalidad especificada requerida en los requisitos del sistema. Se incluye en la clase de pruebas de caja negra.

Prueba de sistema

La prueba del sistema es la prueba para garantizar que al poner el software en diferentes entornos (por ejemplo, sistemas operativos) todavía funciona. La prueba del sistema se realiza con la implementación completa del sistema y el entorno. Se incluye en la clase de pruebas de caja negra.

Pruebas de estrés

La prueba de esfuerzo es la prueba para evaluar cómo se comporta el sistema en condiciones desfavorables. Las pruebas se realizan más allá de los límites de las especificaciones. Se incluye en la clase de pruebas de caja negra.

Pruebas de rendimiento

La prueba de rendimiento es la prueba para evaluar la velocidad y la eficacia del sistema y para asegurarse de que está generando resultados dentro de un tiempo específico como en los requisitos de rendimiento. Se incluye en la clase de pruebas de caja negra.

Pruebas de usabilidad

Las pruebas de usabilidad se realizan desde la perspectiva del cliente, para evaluar cómo la GUI es fácil de usar. ¿Con qué facilidad puede aprender el cliente? Después de aprender a usar, ¿qué tan eficientemente puede funcionar el cliente? ¿Qué tan agradable es usar su diseño? Esto cae dentro de la clase de pruebas de caja negra.

Test de aceptación

Las pruebas de aceptación a menudo son realizadas por el cliente para garantizar que el producto entregado cumpla con los requisitos y funcione como el cliente esperaba. Se incluye en la clase de pruebas de caja negra.

Pruebas de regresión

La prueba de regresión es la prueba después de la modificación de un sistema, componente o un grupo de unidades relacionadas para garantizar que la modificación funcione correctamente y no dañe ni imponga otros módulos para producir resultados inesperados. Se incluye en la clase de pruebas de caja negra.

Prueba beta

La prueba beta es la prueba que realizan los usuarios finales, un equipo externo al desarrollo o publican una versión previa completa del producto que se conoce como versión beta. El objetivo de las pruebas beta es cubrir errores inesperados. Se incluye en la clase de pruebas de caja negra.

De hecho son 2:

1. Pruebas funcionales (prueba de la aplicación con los requisitos del negocio. Las pruebas funcionales se realizan usando las especificaciones funcionales proporcionadas por el cliente o usando las especificaciones de diseño como los casos de uso proporcionados por el equipo de diseño)
2. Pruebas no funcionales (Prueba de la aplicación contra el cliente y los requisitos de rendimiento. Las pruebas no funcionales se realizan en función de los requisitos y escenarios de prueba definidos por el cliente).

Incluyen:

Funcional:
Examen de la unidad
Prueba de humo / prueba de cordura
Pruebas de integración (prueba de arriba hacia abajo, de abajo hacia arriba)
Prueba de interfaz y usabilidad
Prueba de sistema
Pruebas de regresión
Prueba de aceptación previa al usuario (alfa y beta)
Pruebas de aceptación del usuario
Prueba de caja blanca y caja negra
Pruebas de globalización y localización

No funcional

Prueba de carga
Prueba de ergonomía
Pruebas de estrés y volumen
Pruebas de compatibilidad y migración
Prueba de conversión de datos
Pruebas de seguridad / penetración
Pruebas de preparación operacional
Prueba de instalación
Pruebas de seguridad (ApplicationSecurity, Network Security, System Security)

Los subtipos anteriores a su vez pueden tener su propio subconjunto, es decir, las pruebas de carga incluyen pruebas de rendimiento, pruebas de estrés, pruebas de remojo, etc., tal como se describe en Por qué las pruebas de carga “normales” no son suficientes | BlazeMeter

La lista de los tipos de pruebas de software más comunes:

• La prueba de carga se realiza para ver el comportamiento del software bajo uso intensivo.
• La prueba de esfuerzo presupone la prueba de funciones específicas del software mientras el sistema está altamente cargado.
• Las pruebas de usabilidad se realizan para verificar si el software es comprensible y fácil de usar.
• Prueba de instalación está comprobando si el usuario no tendrá problemas para instalar el software.
• Pruebas de recuperación comprueba la rapidez con que un sistema puede recuperarse después de una falla.
• Las pruebas de compatibilidad se realizan para determinar en qué entornos se puede ejecutar el software.
• Las pruebas exploratorias pueden llamarse improvisación. Es un tipo de prueba que se realiza sin escenarios preparados.
• Prueba alfa es la prueba inicial del software por parte de los empleados de la compañía.
• La prueba beta es una prueba opcional realizada por usuarios potenciales del producto.
• Las pruebas de seguridad presuponen la verificación del potencial del sistema para resistir los ataques y daños.
• Pruebas de localización es la verificación de la versión localizada del software.
• La prueba ad hoc es un tipo de prueba un poco “caótica” cuando no hay especificaciones para el software probado.
• La prueba de la interfaz de usuario es un proceso de verificación de la interfaz del software para ver si es funcional y adecuado para los usuarios.
• La prueba entre navegadores es una comprobación del sistema en varios navegadores.
• La prueba de SEO es la prueba de software de acuerdo con factores internos y externos de SEO.

Aunque todos estos tipos de pruebas se centran en diferentes aspectos del ciclo de vida del software, todos se han desarrollado para mejorar la calidad del software y hacer que incluso los usuarios más exigentes estén satisfechos con lo que obtienen en el resultado.

En primer lugar, aclare la confusión: Agile, Integration, Acceptance, UAT, White-box, Beta y Dynamic NO son los ‘Tipos de prueba’. ¡Sí! Casi todo lo que lees en línea confunde un concepto con otro. Antes de leer este artículo, ¡Atención! ¡Aclare sus hechos antes de enfrentar una entrevista!

Los tipos de prueba definen los diferentes aspectos del software que cubrirá como parte de sus esfuerzos de prueba, es decir, el objetivo. ¿Será solo funcional? ¿O también vas a medir el rendimiento del sistema? ¿Qué pasa con el esquema de la base de datos? ¿Qué sucede si la aplicación bancaria que está probando es segura o no? ¿Funcionará también en móviles? Existen numerosos tipos de pruebas que uno puede elegir hoy en día, por ejemplo, pruebas funcionales, de seguridad, de rendimiento, de compatibilidad, pruebas de bases de datos, etc.

……………………………………………………………………………………………………

En términos generales, los tipos de prueba se pueden distinguir como funcionales o no funcionales, es decir, debe validar los aspectos funcionales como funciones, compatibilidad, interfaz de usuario, etc. O debe validar el rendimiento y los aspectos de seguridad.

Pruebas Funcionales

El tipo de prueba más esencial, la prueba funcional, se enfoca en probar el software contra documentos de diseño, casos de uso y documentos de requisitos, que realiza correctamente todas sus funciones requeridas.

Pruebas no funcionales

Aquí, no está probando el software para ninguna funcionalidad. En cambio, el enfoque se centra en aspectos no funcionales como el rendimiento, la carga, la accesibilidad, la localización, la seguridad, la confiabilidad, la recuperación, etc.

………………………………………………………………………………………………………

Funcionales y no funcionales son los tipos de pruebas de raíz y todos los demás tipos pertenecen a una de las categorías. Hoy en día, la popularidad y la criticidad de las pruebas no funcionales ha disminuido la brecha entre los dos, es decir, hay una diferencia de línea muy delgada entre los dos días. ¡Pero como profesional de pruebas, debe tener en cuenta la diferencia básica como se destacó anteriormente!

1. Implementación, instalación, configuración y pruebas de desinstalación

2. Pruebas de rendimiento

3. Prueba de carga

4. Prueba de esfuerzo

5. Prueba de volumen

6. Pruebas de seguridad

7. Pruebas de penetración

8. Pruebas de vulnerabilidad

9. Pruebas de recuperación

10. Pruebas de integridad de datos y bases de datos

11. Prueba de GUI (interfaz gráfica de usuario)

12. Pruebas de compatibilidad

13. Pruebas de usabilidad

14. Pruebas de accesibilidad

15. Pruebas de portabilidad

16. Pruebas de escalabilidad

17. Pruebas de estabilidad

18. Tolerancia a fallas, manejo de errores y prueba de failover

19. Pruebas de internacionalización / localización

20. Pruebas de conformidad y cumplimiento

¿Qué significan estos diferentes tipos de prueba? ¿Cuál es el objetivo para cada uno? ¿Cómo están relacionados estos? ¿Cuáles son los más comunes e importantes? Casi todos los diferentes tipos de pruebas caen dentro de una de las categorías anteriores.

Implementación, instalación, configuración y pruebas de desinstalación

Espero que esto se explique por sí mismo: probar los procesos de implementación, instalación, configuración del software en un entorno específico y finalmente la desinstalación. Un software debe funcionar como se espera después de la implementación, instalación y configuración, con respecto a la funcionalidad, el rendimiento y la seguridad. ¿Qué pasa si hay una actualización de la versión del software? El objetivo es probar las actividades de configuración del software y el proceso de desinstalación.

Pruebas de rendimiento

El objetivo no es funcional, sino descubrir problemas de rendimiento, como retraso de la red, procesamiento de datos, procesamiento de transacciones de la base de datos, equilibrio de carga entre servidores, rendimiento, tiempo de respuesta, etc. (velocidad y eficiencia del sistema). Las pruebas de rendimiento son críticas para las aplicaciones comerciales intensivas, como el comercio de acciones, las transacciones financieras, etc. Es un conjunto más amplio de tipo de prueba que incluye pruebas de carga, tensión y volumen, generalmente realizadas con herramientas de automatización.

Precaución : No es hasta que todos los elementos del sistema estén completamente integrados y certificados como libres de defectos, se puede determinar el verdadero rendimiento de un sistema. Al medir el rendimiento de la aplicación, para medir con precisión el entorno (requisitos de hardware) debe ser como será en el entorno de producción.

Prueba de carga

Cargue como al probar la ‘capacidad’ de la aplicación bajo prueba. ¿No lo entendiste? El escenario común en la mayoría de las empresas de TI: no se puede acceder al portal de la empresa tan pronto como reciba la noticia de que se han publicado cartas de evaluación J La razón: no se realizaron pruebas de carga J El portal no pudo manejar la prisa de los Usuarios o acceso concurrente al sistema.

El objetivo es verificar el comportamiento del software en condiciones normales y en condiciones de carga máxima, en qué momento el tiempo de respuesta del sistema se degrada o falla. La prueba de carga generalmente se realiza utilizando herramientas de prueba automatizadas como JMeter, Load Runner y Silk Performer: se pueden crear varios usuarios virtuales y luego se puede ejecutar un script para verificar cómo se comporta el software cuando varios usuarios intentan acceder al sistema simultáneamente.

Pruebas de estrés

¿Cuándo te estresas? ¡Sí! Cuando no podemos manejar la presión. Hasta cierto límite, podemos manejar la tensión pero más allá: estresada.

Del mismo modo, un software está construido para manejar una determinada carga, más allá de eso se rompe. El objetivo de ‘Stress Testing’ es probar el software en condiciones de carga anormales (más allá del límite aceptable) y luego se controla su rendimiento para observar cómo se comportaría el software en el punto de interrupción. Hay muchas formas de crear condiciones anormales: la base de datos se puede apagar y encender, las consultas complejas de la base de datos, la entrada continua al sistema, la carga de la base de datos o los puertos de red se pueden cerrar o reiniciar aleatoriamente. El resultado deseado es una degradación elegante bajo carga que conduzca a una falla no catastrófica. La forma más común de realizar pruebas de estrés es iniciando procesos que consuman muchos recursos. Las pruebas de resistencia permiten verificar algunos de los atributos de calidad, como la solidez y la fiabilidad.

Prueba de volumen

Las pruebas de volumen (que significan “a granel”) se llevan a cabo para encontrar la respuesta del software con diferentes tamaños de los datos que se envían / ​​reciben o se procesan. Por ejemplo, si tuviera que probar Microsoft Word, la prueba de volumen aseguraría que Word pueda abrir, guardar y trabajar en archivos de diferentes tamaños (10 a 100 MB).

Pruebas de seguridad

¿Qué sucede si alguien que inicia sesión en Facebook puede acceder a los datos de su perfil y puede publicar en su nombre? Infracción crítica de seguridad, ¿verdad?

Como su nombre lo indica, el objetivo de las pruebas de seguridad es verificar cuán seguro es el software frente a las amenazas externas o internas de humanos y programas maliciosos. Por ejemplo, el mecanismo de autorización del software, qué tan fuerte es la autenticación, el mantenimiento de la confidencialidad e integridad de los datos, etc. En otras palabras, las pruebas de seguridad aseguran que el personal autorizado solo acceda al programa. La autenticación (se verifican las credenciales de inicio de sesión) y la autorización (privilegios para acceder a funciones restringidas) se consideran dos aspectos muy importantes de las pruebas de software. La seguridad es especialmente importante para las aplicaciones que requieren firewalls, encriptación, autenticación de usuarios, transacciones financieras o acceso a bases de datos con datos confidenciales. Las pruebas de seguridad requieren un buen conocimiento de las herramientas de prueba de aplicaciones, tecnología, redes y seguridad.

Además de la autenticación y la autorización, las pruebas de seguridad también se ocupan de la confidencialidad, integridad, disponibilidad, no repudio, seguridad de datos de software, fallas de inserción de SQL, ataques de secuencias de comandos entre sitios y otras preocupaciones relacionadas con la seguridad, que es una experiencia de tema completamente diferente en sí misma.

Pruebas de penetración

También conocido como PenTest en resumen, es un tipo de prueba de seguridad. El objetivo es medir qué tan seguros son el software y sus entornos (hardware, sistema operativo y red) cuando están sujetos a ataques por parte de un intruso externo o interno. El intruso puede ser un humano / hacker o programas maliciosos. Pentest utiliza métodos para entrometerse por la fuerza (por ataque de fuerza bruta) o mediante el uso de una debilidad (vulnerabilidad) para obtener acceso a un software o datos o hardware con la intención de exponer formas de robar, manipular o corromper datos, archivos de software o configuración. La prueba de penetración es una forma de piratería ética, un probador de penetración experimentado utilizará los mismos métodos y herramientas que usaría un hacker, pero la intención del probador de penetración es identificar la vulnerabilidad y repararla antes de que un pirata informático real o un programa malicioso la explote.

Pruebas de vulnerabilidad

Vulnerabilidad o debilidad en el sistema de software que expone su funcionalidad o datos importantes a un acceso no autorizado. Las pruebas de vulnerabilidad implican identificar y exponer las vulnerabilidades de software, hardware o red que pueden ser explotadas por piratas informáticos y otros programas maliciosos, como virus o gusanos. Con el aumento en el número de piratas informáticos y programas maliciosos, la prueba de vulnerabilidad es crítica para el éxito de un negocio.

Pruebas de recuperación

¿Qué pasa si el sistema falla? Aunque no lo hará después de que se hayan completado todas las pruebas, aún así debemos estar preparados para lo peor, es decir, probar qué tan bien se recupera un sistema de fallas, fallas de hardware u otros problemas catastróficos.

Pruebas de integridad de datos y bases de datos

Después de todo, todo en línea trata sobre los datos. ¿Cómo podemos excluir la base de datos entonces? La prueba de integridad de datos tiene como objetivo verificar si los datos almacenados en la base de datos son precisos y producen resultados de acuerdo con las expectativas: si es posible recuperar información en blanco de la base de datos o no, los datos se validan correctamente antes de guardarlos en la base de datos. los datos almacenados en la base de datos se actualizan, ¿puede ejecutar pruebas para todo tipo de archivos de datos, etc.? En otras palabras, las pruebas de integridad de datos se llevan a cabo para garantizar que los datos sean precisos y consistentes durante todo su ciclo de vida.

La integridad de la base de datos, por otro lado, trata con la prueba de todos los métodos y procesos necesarios que son importantes para acceder a la base de datos y administrar los datos que contiene. Los datos no deben corromperse y no deben eliminarse, actualizarse o crearse sin saberlo, y debe haber casos de prueba para realizar estas validaciones.

El enfoque manual consiste en examinar cuidadosamente el flujo de datos entre el backend y el frontend. La creación, actualización o eliminación de los datos del front-end se refleja con éxito en el back-end, verifique los campos obligatorios de la base de datos, las restricciones y reglas de la base de datos o verifique el procedimiento utilizando el analizador de consultas SQL.

Prueba de GUI (interfaz gráfica de usuario)

Como su nombre lo indica, el objetivo es probar la GUI (interfaz gráfica de usuario) del software, para garantizar que cumpla con los requisitos según el diseño. Por ejemplo, diseño, colores, fuente, enlaces, tipo y longitud de los campos de entrada de formulario, etc. La GUI no solo se verifica para la funcionalidad adecuada sino también para su cumplimiento de los estándares de calidad definidos.

Nota : La mayoría de las herramientas de automatización de pruebas funcionales funcionan con capacidades de captura y reproducción de GUI.

Pruebas de compatibilidad

La compatibilidad como en su software es adecuada tanto para hombres como para mujeres J jaja … Es broma J Siguiendo el ejemplo de las relaciones humanas (las personas deben ser compatibles entre sí para crear una sociedad cohesionada), ¿con qué interactúa el software? ? ¡Sí! Los recursos de hardware como memoria, unidades de disco y CPU, el sistema operativo, bases de datos, servidores web, servidores de aplicaciones, diferentes navegadores, etc., que un cliente puede usar. ¿Qué pasa si falla en alguna interacción?

El objetivo de las pruebas de compatibilidad es garantizar que el software (o su última versión) sea adecuado para su entorno: hardware, servidores, sistema operativo, CPU, etc. Determina la configuración mínima y óptima de hardware y software para la aplicación bajo prueba para realizar perfectamente. La forma de compatibilidad más popular es: compatibilidad del navegador (la aplicación funciona bien en todos los navegadores dentro del alcance) y compatibilidad de versiones (la versión más nueva es compatible con versiones anteriores o no). Las pruebas de compatibilidad se pueden realizar manualmente o pueden ser conducidas por un conjunto de pruebas de regresión o funcional automatizado.

Pruebas de usabilidad

En términos simples: probar la “facilidad de uso”. ¿Por qué crees que algunos sitios web son más fáciles de usar? Implica verificar si un nuevo usuario puede entender, aprender y usar la aplicación fácilmente, contenidos de ayuda, navegación del sistema, diseño agradable, etc.

Nota : La prueba de usabilidad es desde la perspectiva del cliente o del usuario final, es decir, es subjetiva y depende del usuario final o cliente objetivo. Se pueden utilizar entrevistas a usuarios, encuestas, grabaciones de video de sesiones de usuarios y otras técnicas.

Pruebas de accesibilidad

Acceda como en el ‘derecho de uso’, es decir, ¿TODO su software puede acceder? Digamos, ¿qué pasa si una persona ciega quiere acceder a su software? ¿Se aseguró de que los discapacitados puedan acceder al software? Por ejemplo, soporte de audio para usuarios ciegos, color y contraste para daltónicos, tamaño de fuente para personas con discapacidad visual, reconocimiento de voz, etc. ¡El objetivo de la prueba es garantizar la ‘accesibilidad de la aplicación por TODOS’!

Prueba de portabilidad

Portabilidad, o en otras palabras, movilidad o transferibilidad de un software o aplicación. Movilidad como en los cambios en el entorno, como hardware, sistema operativo o navegador. El software puede instalarse en más de un entorno o sus ejecutables pueden crearse y ejecutarse en diferentes plataformas. Esta forma de prueba es importante si el cliente tiene la intención de utilizar la aplicación de software en más de una plataforma.

Pruebas de escalabilidad

El objetivo es probar la ‘Escalabilidad’ del software: la capacidad del software para escalar con un mayor número de usuarios, mayores transacciones, aumento del tamaño de la base de datos, etc., es decir, cuánta más carga de trabajo puede soportar el software con la expansión de la base de usuarios, las transacciones y el almacenamiento de datos etc.

Prueba de estabilidad

Las pruebas de estabilidad se centran en probar qué tan estable es el software cuando está sujeto a cargas a niveles aceptables, cargas máximas, cargas generadas en picos, con más volúmenes de datos para procesar, etc.

Tolerancia a fallas, manejo de errores y prueba de failover

En la era actual de los pagos en línea, ocasionalmente encontramos una situación en la que se carga el monto pero la transacción falla. Ahora, ¿cómo te sentirías si la compañía de software no hiciera nada al respecto? ¿Volverá a usar el mismo software o aplicación nuevamente? ¡Obviamente no!

Aquí es donde entra en escena la tolerancia a fallas, el manejo de errores y las pruebas de conmutación por error. ¿Qué sucede si se produce algún error o falla en la aplicación? ¿El software muestra un mensaje de error adecuado? ¿El sistema procesa correctamente las transacciones erróneas? ¿Se puede revertir? Las pruebas se llevan a cabo para verificar cómo reaccionaría una aplicación si ocurriera alguna falla en un escenario en tiempo real, por ejemplo, un error de conexión con la red, un problema de conexión con el servidor de aplicaciones, no poder conectarse a una base de datos, etc. Y probar la capacidad del software para recuperarse de problemas severos inesperados como fallas de hardware o fallas. Esta forma de prueba explica qué tan bien el sistema se restaurará a su estado original en caso de cualquier tipo de falla.

Pruebas de internacionalización / localización

Para internacionalizarse, el software debe ser compatible con la localización. ¿Confuso? ¡Es simple!

Digamos que el Software bajo prueba se utilizará en todas las geografías: ¿cuál es el primer obstáculo para su uso? ¡Sí! El idioma J, el objetivo de este tipo de prueba es garantizar que el software pueda admitir el uso de diferentes idiomas (mostrar y aceptar entradas), diferentes conjuntos de caracteres, configuraciones de datos y hora, moneda local, etc. con respecto a un entorno local particular (como Francés, alemán o español). Una vez que la configuración se establece para un entorno local particular, se espera que el software se adapte y funcione como se espera (sin impacto funcional debido al cambio de entorno).

Pruebas de conformidad y cumplimiento

Las pruebas de conformidad verifican la conformidad de la implementación con los estándares de la industria, es decir, producen pruebas que verifican que la implementación del software cumple con los estándares de la industria con respecto a diferentes aspectos como la portabilidad, interoperabilidad y / o compatibilidad.

Las pruebas de conformidad verifican si el sistema se desarrolló de acuerdo con estándares, procedimientos y pautas. Por ejemplo, las pruebas de cumplimiento normativo facilitan la resolución de problemas de cumplimiento y la presentación de la documentación necesaria para cumplir con los lineamientos y mandatos reglamentarios.

La prueba de software es el proceso de evaluación de un elemento de software para detectar diferencias entre la entrada dada y la salida esperada. También para evaluar la característica de un elemento de software. Las pruebas evalúan la calidad del producto. La prueba de software es un proceso que debe realizarse durante el proceso de desarrollo. En otras palabras, la prueba de software es un proceso de verificación y validación.

Prueba de caja negra : el diseño del sistema interno no se considera en este tipo de prueba. Las pruebas se basan en los requisitos y la funcionalidad.

Prueba de caja blanca : esta prueba se basa en el conocimiento de la lógica interna del código de una aplicación. También conocido como prueba de caja de vidrio. El software interno y el funcionamiento del código deben ser conocidos para este tipo de pruebas.

Prueba unitaria : prueba de componentes o módulos de software individuales. Normalmente lo realiza el programador y no los probadores, ya que requiere un conocimiento detallado del diseño y el código interno del programa.

Pruebas de integración incremental : enfoque ascendente para pruebas, es decir, pruebas continuas de una aplicación a medida que se agrega nueva funcionalidad; La funcionalidad y los módulos de la aplicación deben ser lo suficientemente independientes como para probarlos por separado. hecho por programadores o probadores.

Descripción general sobre los tipos de pruebas de software

Pruebas de integración: las pruebas de integración son la fase de las pruebas de software donde los módulos de software individuales se combinan y se prueban como un grupo. Se realiza después de las pruebas unitarias y antes del inicio de las pruebas de validación. Los módulos de entrada se prueban en la unidad antes de realizar las pruebas de integración.

Pruebas funcionales : es la prueba más básica que se aplica a cualquier aplicación. Asegura que su aplicación funcione según los requisitos predefinidos. Esta forma de prueba considera los diversos escenarios que pueden surgir durante una experiencia de usuario y elimina cualquier problema técnico que pueda surgir.

Prueba del sistema : todo el sistema se prueba según los requisitos. Las pruebas de tipo caja negra que se basan en especificaciones de requisitos generales, cubren todas las partes combinadas de un sistema.

Pruebas de sanidad : pruebas para determinar si una nueva versión de software está funcionando lo suficientemente bien como para aceptarla para un esfuerzo de prueba importante.

Pruebas de aceptación: normalmente, este tipo de pruebas se realiza para verificar si el sistema cumple con los requisitos especificados por el cliente.

Prueba de carga – Es una prueba de rendimiento para verificar el comportamiento del sistema bajo carga. Probar una aplicación bajo cargas pesadas, como la prueba de un sitio web en un rango de cargas para determinar en qué punto el tiempo de respuesta del sistema se degrada o falla.

Pruebas de tensión : el sistema se somete a tensión más allá de sus especificaciones para verificar cómo y cuándo falla. Realizado bajo una gran carga, como poner un gran número más allá de la capacidad de almacenamiento, consultas complejas de la base de datos, entrada continua al sistema o carga de la base de datos.

Pruebas de rendimiento – Probar el rendimiento móvil significa probar el rendimiento de la aplicación del cliente, el rendimiento del servidor y el rendimiento de la red. Los escenarios de Pruebas de rendimiento deben poder cubrir todas estas áreas y solo entonces la prueba tendrá éxito. Se presta más atención a la experiencia del usuario con una prueba de rendimiento de la aplicación del lado del cliente, que prueba la capacidad de respuesta de la aplicación ante las interacciones del usuario. Término a menudo usado indistintamente con pruebas de ‘estrés’ y ‘carga’. Para verificar si el sistema cumple con los requisitos de rendimiento. Utilicé diferentes herramientas de rendimiento y carga para hacer esto.

Pruebas de usabilidad: comprobación de facilidad de uso. Se prueba el flujo de la aplicación. ¿Puede el nuevo usuario entender la aplicación fácilmente? Se documenta la ayuda adecuada cada vez que el usuario se atasca en cualquier punto. Básicamente, la navegación del sistema se verifica en esta prueba.

Pruebas de seguridad : el sistema puede ser penetrado por cualquier forma de piratería. Prueba de qué tan bien protege el sistema contra el acceso interno o externo no autorizado. Se verificó si el sistema, la base de datos está a salvo de ataques externos.

Tipos de pruebas de software

Pruebas ad-hoc
Este tipo de prueba de software es muy informal y no estructurado y puede ser realizado por cualquier parte interesada sin referencia a ningún caso de prueba o documentos de diseño de prueba.
La persona que realiza las pruebas Ad-hoc comprende bien el dominio y los flujos de trabajo de la aplicación para tratar de encontrar defectos y romper el software. Las pruebas ad-hoc están destinadas a encontrar defectos que no se encontraron en los casos de prueba existentes.

Test de aceptación
La prueba de aceptación es un tipo formal de prueba de software que realiza el usuario final cuando las características han sido entregadas por los desarrolladores. El objetivo de esta prueba es verificar si el software confirma sus necesidades comerciales y los requisitos proporcionados anteriormente. Las pruebas de aceptación normalmente se documentan al comienzo del sprint (en forma ágil) y es un medio para que los evaluadores y desarrolladores trabajen hacia una comprensión común y un conocimiento de dominio comercial compartido.

¿Qué son las pruebas de aceptación en Agile?

Pruebas de accesibilidad
Al realizar pruebas de accesibilidad, el objetivo de las pruebas es determinar si las personas con discapacidad pueden acceder fácilmente al contenido del sitio web. Varias comprobaciones como el color y el contraste (para personas daltónicas), el tamaño de fuente para personas con discapacidad visual, texto claro y conciso que es fácil de leer y comprender.

Prueba ágil
Agile Testing es un tipo de prueba de software que se adapta al enfoque y las prácticas de desarrollo de software ágil. En un entorno de desarrollo ágil, las pruebas son una parte integral del desarrollo de software y se realizan junto con la codificación. Las pruebas ágiles permiten codificación y pruebas incrementales e iterativas.

Prueba de API
La prueba de API es un tipo de prueba que es similar a la prueba unitaria. Cada una de las API de software se prueba según las especificaciones de la API. Las pruebas de API se realizan principalmente por el equipo de prueba, a menos que las API sean probadas o complejas y necesiten una codificación extensa. Las pruebas de API requieren comprender tanto la funcionalidad de API como poseer buenas habilidades de codificación.

Pruebas automatizadas
Este es un enfoque de prueba que utiliza herramientas de prueba y / o programación para ejecutar los casos de prueba utilizando software o utilidades de prueba desarrolladas a medida. La mayoría de las herramientas automatizadas proporcionaron la función de captura y reproducción, sin embargo, hay herramientas que requieren escribir una amplia programación o programación para automatizar casos de prueba.

Todas las pruebas de pares
También conocido como prueba por pares, es un enfoque de prueba de caja negra y un método de prueba donde cada entrada se prueba en pares de entradas, lo que ayuda a probar que el software funciona como se espera con todas las combinaciones de entrada posibles.

Prueba beta
Este es un tipo formal de prueba de software que realizan los clientes finales antes de lanzar o entregar el software a los usuarios finales. La finalización exitosa de las pruebas Beta significa la aceptación del software por parte del cliente.

Prueba de caja negra
La prueba de caja negra es un método de prueba de software donde los probadores no están obligados a conocer la codificación o la estructura interna del software. El método de prueba de caja negra se basa en pruebas de software con varias entradas y validación de resultados con la salida esperada. Más información sobre las pruebas de caja negra.

Pruebas de compatibilidad con versiones anteriores
Tipo de prueba de software realizada para verificar que la versión más reciente del software puede funcionar con éxito sobre la versión anterior del software y que la versión más nueva del software funciona tan bien con la estructura de la tabla, las estructuras de datos y los archivos creados por versión anterior del software.

Prueba de valor límite (BVT)
La Prueba de valor límite es una técnica de prueba que se basa en el concepto de “agregados de error en los límites”. En esta técnica de prueba, la prueba se realiza ampliamente para verificar defectos en condiciones límite.

Pruebas de integración de Big Bang
Este es uno de los enfoques de prueba de integración, en las pruebas de integración de Big Bang todos o la mayoría de todos los módulos se desarrollan y luego se combinan.

Pruebas de integración de abajo hacia arriba
La prueba de integración ascendente es un enfoque de prueba de integración donde la prueba comienza con piezas o subsistemas más pequeños del software hasta cubrir todo el sistema de software. Las pruebas de integración ascendente comienzan con pequeñas porciones del software y eventualmente se amplían en términos de tamaño, complejidad e integridad.

Pruebas de integración en grande

Pruebas de integración en pequeños

Prueba de rama
Es un método de prueba de caja blanca para diseñar casos de prueba para probar el código para cada condición de ramificación. El método de prueba de rama se aplica durante las pruebas unitarias.

Pruebas de compatibilidad del navegador
Es uno de los subtipos de pruebas de pruebas de compatibilidad realizadas por el equipo de prueba. La prueba de compatibilidad del navegador se realiza para aplicaciones web con combinaciones de diferentes navegadores y sistemas operativos.

Pruebas de compatibilidad
La prueba de compatibilidad es uno de los tipos de prueba que realiza el equipo de prueba. Las pruebas de compatibilidad verifican si el software puede ejecutarse en hardware, sistema operativo, ancho de banda, bases de datos, servidores web, servidores de aplicaciones, periféricos de hardware, emuladores, configuraciones diferentes, procesadores, navegadores diferentes y diferentes versiones de los navegadores, etc.

Prueba de componentes
Este tipo de prueba de software es realizada por los desarrolladores. La prueba de componentes se lleva a cabo después de completar las pruebas unitarias. La prueba de componentes implica probar un grupo de unidades como código en conjunto en lugar de probar funciones individuales, métodos.

Prueba de cobertura de condición
La prueba de cobertura de condición es una técnica de prueba utilizada durante la prueba unitaria, donde el desarrollador prueba todas las declaraciones de condición como si, si no, caso, etc., en el código que se prueba la unidad.

Pruebas Dinámicas
Las pruebas se pueden realizar como pruebas estáticas y pruebas dinámicas, las pruebas dinámicas son un enfoque de prueba donde las pruebas solo se pueden realizar ejecutando código o el software se clasifica como prueba dinámica. Pruebas unitarias, pruebas funcionales, pruebas de regresión, pruebas de rendimiento, etc.

Prueba de cobertura de decisiones
Es una técnica de prueba que se utiliza en las pruebas unitarias. El objetivo de la prueba de cobertura de decisiones es ejercer y validar cada bloque de decisión en el código, por ejemplo, si, si no, declaraciones de casos.

Pruebas de extremo a extremo
El equipo de prueba realiza las pruebas de extremo a extremo y el objetivo es probar los flujos de extremo a extremo, por ejemplo, desde la creación del pedido hasta el informe o la creación del pedido hasta la devolución del artículo, etc. y la verificación. Las pruebas de extremo a extremo generalmente se centran en imitar escenarios y usos de la vida real. Las pruebas de extremo a extremo implican probar el flujo de información entre las aplicaciones.

Prueba exploratoria
Las pruebas exploratorias son un tipo informal de pruebas realizadas para aprender el software al mismo tiempo en busca de errores o comportamiento de la aplicación que no parece obvio. Las pruebas exploratorias generalmente son realizadas por probadores, pero pueden ser realizadas por otras partes interesadas, así como analistas de negocios, desarrolladores, usuarios finales, etc., interesados ​​en aprender las funciones del software y, al mismo tiempo, buscar errores o comportamientos no parece obvio. .

Partición de equivalencia
La partición de equivalencia también se conoce como Partición de clase de equivalencia es una técnica de prueba de software y no un tipo de prueba en sí misma. La técnica de partición de equivalencia se utiliza en los tipos de prueba de caja negra y caja gris. La partición de equivalencia clasifica los datos de prueba en clases de equivalencia como clases de equivalencia positivas y clases de equivalencia negativas, tal clasificación asegura que se prueben las condiciones positivas y negativas.

Pruebas Funcionales
Las pruebas funcionales son un tipo formal de pruebas realizadas por probadores. Las pruebas funcionales se centran en probar el software contra el documento de diseño, los casos de uso y el documento de requisitos. La prueba funcional es un tipo de prueba de caja negra y no requiere el funcionamiento interno del software, a diferencia de las pruebas de caja blanca.

Prueba de fuzz
La prueba de fuzz o fuzzing es una técnica de prueba de software que implica pruebas con entradas inesperadas o aleatorias. El Software es monitoreado por fallas o mensajes de error que se presentan debido a los errores de entrada.

Prueba de GUI (interfaz gráfica de usuario)
Este tipo de prueba de software tiene como objetivo probar que la GUI (interfaz gráfica de usuario) del software cumpla con los requisitos mencionados en las maquetas de GUI y en los documentos detallados diseñados. Para, por ejemplo, verificar la longitud y la capacidad de los campos de entrada proporcionados en el formulario, el tipo de campo de entrada proporcionado, por ejemplo, algunos de los campos de formulario se pueden mostrar como un cuadro desplegable o un conjunto de botones de opción. Por lo tanto, las pruebas de GUI garantizan que los elementos de GUI del software cumplan con las maquetas de GUI aprobadas, los documentos de diseño detallados y los requisitos funcionales. La mayoría de las herramientas de automatización de pruebas funcionales funcionan con capacidades de captura y reproducción de GUI. Esto hace que la grabación de guiones sea más rápida al mismo tiempo que aumenta el esfuerzo en el mantenimiento del guión.

Prueba de caja de vidrio
La prueba de caja de vidrio es otro nombre para la prueba de caja blanca. La prueba de caja de vidrio es un método de prueba que implica probar declaraciones individuales, funciones, etc. La prueba de unidad es uno de los métodos de prueba de caja de vidrio.

Prueba de gorila
Este tipo de prueba de software es realizado por el equipo de prueba de software, ¿tiene un nombre aterrador? El objetivo de Gorilla Testing es ejercer una o pocas funcionalidades exhaustiva o exhaustivamente haciendo que varias personas prueben la misma funcionalidad.

Prueba de ruta feliz
También conocido como prueba de ruta de oro, este tipo de prueba se enfoca en la ejecución exitosa de pruebas que no ejercen el software en condiciones negativas o de error.

Pruebas de integración
Las pruebas de integración son uno de los tipos de pruebas de software más comunes e importantes. Una vez que los desarrolladores prueban que las unidades o componentes individuales funcionan, el equipo de prueba ejecutará pruebas que probarán la conectividad entre estas unidades / componentes o múltiples unidades / componentes. Existen diferentes enfoques para las pruebas de integración, a saber, las pruebas de integración de arriba hacia abajo, las pruebas de integración de abajo hacia arriba y una combinación de estas dos conocidas como pruebas de brujas de arena.

Prueba de interfaz
La Prueba de interfaz es necesaria cuando un software proporciona soporte para una o más interfaces como “Interfaz gráfica de usuario”, “Interfaz de línea de comandos” o “Interfaz de programación de aplicaciones” para interactuar con sus usuarios u otro software. Las interfaces sirven como medio para que el software acepte la entrada de un usuario y proporcione una salida al usuario. El enfoque para las pruebas de interfaz depende del tipo de interfaz que se está probando, como GUI o API o CLI.

Pruebas de internacionalización
La prueba de internacionalización es un tipo de prueba que realiza el equipo de prueba de software para verificar en qué medida el software puede admitir la internacionalización, es decir, el uso de diferentes idiomas, diferentes conjuntos de caracteres, caracteres de doble byte, etc., por ejemplo: Gmail, es una aplicación web eso es utilizado por personas de todo el trabajo con diferentes idiomas, conjuntos de caracteres de uno o varios bytes.

Prueba basada en palabras clave
La prueba basada en palabras clave es más un enfoque de prueba de software automatizado que un tipo de prueba en sí. Las pruebas basadas en palabras clave se conocen como pruebas basadas en acciones o pruebas basadas en tablas.

Prueba de carga
La prueba de carga es un tipo de prueba no funcional; La prueba de carga se realiza para verificar el comportamiento del software en condiciones normales y en condiciones de carga pico. La prueba de carga generalmente se realiza utilizando herramientas de prueba automatizadas. La prueba de carga tiene la intención de encontrar cuellos de botella o problemas que impiden que el software se desempeñe según lo previsto en sus cargas de trabajo máximas.

Diferencia entre pruebas de rendimiento y pruebas de carga

Pruebas de localización
Pruebas de localización de un tipo de prueba de software realizada por probadores de software, en este tipo de prueba, se espera que el software se adapte a una configuración regional particular, debe admitir una configuración regional / idioma particular en términos de visualización, aceptando entradas en esa configuración regional, visualización, fuente, fecha, hora, moneda, etc., relacionados con un entorno local particular. Por ejemplo, muchas aplicaciones web permiten elegir entornos locales como inglés, francés, alemán o japonés. Entonces, una vez que el entorno local se define o establece en la configuración del software, se espera que el software funcione como se espera con un idioma / entorno local establecido.

Pruebas negativas
Este tipo de enfoque de prueba de software, que llama la “actitud para romper”, estas son pruebas funcionales y no funcionales que están destinadas a romper el software al ingresar datos incorrectos como fecha, hora o cadena incorrecta o cargar un archivo binario cuando los archivos de texto se supone que debe cargar o ingresar una cadena de texto enorme para los campos de entrada, etc. También es una prueba positiva para una condición de error.

Pruebas no funcionales.
La mayoría de los softwares están diseñados para cumplir requisitos funcionales y no funcionales, requisitos no funcionales como rendimiento, usabilidad, localización, etc., hay muchos tipos de pruebas como pruebas de compatibilidad, pruebas de cumplimiento, pruebas de localización, pruebas de usabilidad, pruebas de volumen, etc. que se llevan a cabo para verificar los requisitos no funcionales.

Prueba de par
es una técnica de prueba de software que pueden realizar probadores de software, desarrolladores o analistas de negocios. Como su nombre indica, dos personas están unidas, una para evaluar y otra para monitorear y registrar los resultados de la prueba. La prueba de pares también se puede realizar en combinación de tester-desarrollador, analista de tester-business o combinación de desarrollador-analista de negocios. La combinación de probadores y desarrolladores en pruebas de pares ayuda a detectar defectos más rápido, identificar la causa raíz, corregir y probar la solución.

Pruebas de rendimiento
es un tipo de prueba de software y parte de la ingeniería de rendimiento que se realiza para verificar algunos de los atributos de calidad del software, como estabilidad, confiabilidad y disponibilidad. Las pruebas de desempeño son realizadas por el equipo de ingeniería de desempeño. A diferencia de las pruebas funcionales, las pruebas de rendimiento se realizan para verificar los requisitos no funcionales. Las pruebas de rendimiento verifican qué tan bien funciona el software en cargas de trabajo anticipadas y pico. Existen diferentes variaciones o subtipos de rendimiento como pruebas de carga, pruebas de estrés, pruebas de volumen, pruebas de remojo y pruebas de configuración.

Pruebas de penetración
Es un tipo de prueba de seguridad. Las pruebas de penetración se realizan para comprobar la seguridad del software y sus entornos (hardware, sistema operativo y red) cuando están sujetos a ataques por parte de un intruso externo o interno. Un intruso puede ser un humano / hacker o programas maliciosos. Pentest utiliza métodos para entrometerse por la fuerza (por ataque de fuerza bruta) o mediante el uso de una debilidad (vulnerabilidad) para obtener acceso a un software o datos o hardware con la intención de exponer formas de robar, manipular o corromper datos, archivos de software o configuración. La prueba de penetración es una forma de piratería ética, un probador de penetración experimentado utilizará los mismos métodos y herramientas que usaría un hacker, pero la intención del probador de penetración es identificar la vulnerabilidad y repararla antes de que un pirata informático real o un programa malicioso la explote.

Pruebas de regresión
es un tipo de prueba de software que realizan los probadores de software como pruebas de regresión funcional y los desarrolladores como pruebas de regresión de unidades. El objetivo de las pruebas de regresión es encontrar defectos que se introdujeron en las reparaciones de defectos o la introducción de nuevas características. Las pruebas de regresión son candidatos ideales para la automatización.

Retesting y pruebas de regresión

Retesting
es un tipo de reevaluación que realizan los probadores de software como parte de la verificación de reparación de defectos. Por ejemplo, un probador está verificando una corrección de defecto y digamos que hay 3 casos de prueba fallidos debido a este defecto. Una vez que un probador verifica la solución del defecto como resuelta, el probador volverá a probar o probar la misma funcionalidad nuevamente ejecutando los casos de prueba que fallaron antes.

Pruebas basadas en riesgos
es un tipo de prueba de software y un enfoque diferente para probar un software. En las pruebas basadas en el riesgo, los requisitos y la funcionalidad de un software a probar se priorizan como Crítico, Alto, Medio y bajo. En este enfoque, se prueban todas las pruebas críticas y de alta prioridad, seguidas de media. La funcionalidad de baja prioridad o de bajo riesgo se prueba al final o puede que no se pruebe en absoluto, según las escalas de tiempo.

Por qué las pruebas basadas en riesgos son importantes en proyectos ágiles

Prueba de humo
es un tipo de prueba que realizan los probadores de software para verificar si la nueva compilación proporcionada por el equipo de desarrollo es lo suficientemente estable, es decir, la funcionalidad principal está funcionando como se espera para llevar a cabo pruebas adicionales o detalladas. La prueba de humo está destinada a encontrar defectos de “show stopper” que pueden evitar que los evaluadores prueben la aplicación en detalle. La prueba de humo realizada para una compilación también se conoce como prueba de verificación de compilación.

Pruebas de seguridad
es un tipo de prueba de software realizada por un equipo especializado de probadores de software. El objetivo de las pruebas de seguridad es asegurar el software frente a amenazas externas o internas de humanos y programas maliciosos. Las pruebas de seguridad básicamente verifican qué tan bueno es el mecanismo de autorización del software, qué tan fuerte es la autenticación, cómo el software mantiene la confidencialidad de los datos, cómo mantiene el software la integridad de los datos, cuál es la disponibilidad del software en caso de un ataque contra el El software de piratas informáticos y programas maliciosos es para pruebas de seguridad que requiere un buen conocimiento de las aplicaciones, la tecnología, las redes y las herramientas de prueba de seguridad. Con un mayor número de aplicaciones web, las pruebas de seguridad se han vuelto más importantes que nunca.

Prueba de cordura
es un tipo de prueba que se lleva a cabo principalmente por probadores y en algunos proyectos también por desarrolladores. La prueba de cordura es una evaluación rápida del software, el entorno, la red, los sistemas externos están en funcionamiento y el entorno del software en su conjunto es lo suficientemente estable como para proceder con pruebas exhaustivas. Las pruebas de cordura son estrechas y la mayoría de las veces las pruebas de cordura no están documentadas.

Pruebas de escalabilidad
es una prueba no funcional destinada a probar uno de los atributos de calidad del software, es decir, “escalabilidad”. La prueba de escalabilidad no se centra solo en una o pocas funcionalidades del software, sino en el rendimiento del software en su conjunto. Las pruebas de escalabilidad generalmente las realiza el equipo de ingeniería de rendimiento. El objetivo de las pruebas de escalabilidad es probar la capacidad del software para escalar con un mayor número de usuarios, mayores transacciones, aumento del tamaño de la base de datos, etc. No es necesario que el rendimiento del software aumente con el aumento de la configuración del hardware, las pruebas de escalabilidad ayudan a descubrir cómo mucha más carga de trabajo que el software puede soportar con la expansión de la base de usuarios, transacciones, almacenamiento de datos, etc.

Prueba de estabilidad
es una prueba no funcional destinada a probar uno de los atributos de calidad del software, es decir, “Estabilidad”. Las pruebas de estabilidad se centran en probar qué tan estable es el software cuando está sujeto a cargas a niveles aceptables, cargas máximas, cargas generadas en picos, con más volúmenes de datos para procesar. Las pruebas de escalabilidad implicarán realizar diferentes tipos de pruebas de rendimiento como pruebas de carga, pruebas de estrés, pruebas de picos, pruebas de remojo, pruebas de picos, etc.

Prueba estática
es una forma de prueba en la que, en enfoques como las revisiones, se emplean tutoriales para evaluar la exactitud de la entrega. En las pruebas estáticas, el código del software no se ejecuta, sino que se revisa en busca de sintaxis, comentarios, convenciones de nomenclatura, tamaño de las funciones / métodos, etc. Las pruebas estáticas generalmente tienen listas de verificación con las que se evalúan los resultados. Las pruebas estáticas se pueden aplicar para requisitos, diseños, casos de prueba mediante el uso de enfoques como revisiones o tutoriales.

Pruebas de estrés
es un tipo de prueba de rendimiento, en la que el software está sujeto a cargas máximas e incluso a un punto de interrupción para observar cómo se comportaría el software en el punto de interrupción. Las pruebas de esfuerzo también prueban el comportamiento del software con recursos insuficientes como CPU, memoria, ancho de banda de red, espacio en disco, etc. Las pruebas de estrés permiten verificar algunos de los atributos de calidad como la solidez y la confiabilidad.

Prueba de sistema
Esto incluye múltiples tipos de pruebas de software que permitirán validar el software en su conjunto (software, hardware y red) según los requisitos para los que fue construido. Se realizan diferentes tipos de pruebas (pruebas de GUI, pruebas funcionales, pruebas de regresión, pruebas de humo, pruebas de carga, pruebas de estrés, pruebas de seguridad, pruebas de estrés, pruebas ad-hoc, etc.) para completar las pruebas del sistema.

Prueba de remojo
es un tipo de prueba de rendimiento, donde en el software se somete a una carga durante un período de tiempo significativo, la prueba de remojo puede durar unos días o incluso algunas semanas. La prueba de remojo es un tipo de prueba que se realiza para encontrar errores que resultan en la degeneración del rendimiento del software con el uso continuo. Las pruebas de remojo se realizan extensivamente para dispositivos electrónicos, que se espera que funcionen continuamente durante días o meses o años sin reiniciar o reiniciar. Con el crecimiento de las aplicaciones web, las pruebas de inmersión han adquirido una importancia significativa, ya que la disponibilidad de las aplicaciones web es fundamental para el mantenimiento y el éxito de los negocios.

Pruebas de integración de sistemas
conocido como SIT (en resumen) es un tipo de prueba realizada por el equipo de prueba de software. Como su nombre lo indica, el enfoque de las pruebas de integración del sistema es probar los errores relacionados con la integración entre diferentes aplicaciones, servicios, aplicaciones de terceros, etc., como parte de SIT, se prueban escenarios de extremo a extremo que requerirían que el software interactúe (enviar o recibir datos) con otras aplicaciones, servicios, llamadas de aplicaciones de terceros, etc.

Examen de la unidad
es un tipo de prueba que realizan los desarrolladores de software. La prueba de unidad sigue el enfoque de prueba de caja blanca donde un desarrollador probará unidades de código fuente como declaraciones, ramas, funciones, métodos, interfaz en OOP (programación orientada a objetos). Las pruebas unitarias generalmente implican el desarrollo de trozos y controladores. Las pruebas unitarias son candidatos ideales para la automatización. Las pruebas automatizadas pueden ejecutarse como pruebas de regresión de unidades en nuevas compilaciones o nuevas versiones del software. Hay muchos marcos útiles de pruebas unitarias, como Junit, Nunit, etc., disponibles que pueden hacer que las pruebas unitarias sean más efectivas.

Pruebas de usabilidad
es un tipo de prueba de software que se realiza para comprender qué tan fácil de usar es el software. El objetivo de las pruebas de usabilidad es permitir que los usuarios finales usen el software, observen su comportamiento, su respuesta emocional (si a los usuarios les gustó usar el software o estaban estresados ​​al usarlo, etc.) y recopilar sus comentarios sobre cómo se puede hacer que el software sea más utilizable o fácil de usar e incorpora los cambios que hacen que el software sea más fácil de usar.

Prueba de aceptación del usuario (UAT)
La prueba de aceptación del usuario es imprescindible para cualquier proyecto; es realizado por clientes / usuarios finales del software. Las pruebas de aceptación del usuario permiten a las PYME (expertos en la materia) del cliente probar el software con su negocio real o escenarios del mundo real y verificar si el software cumple con sus requisitos comerciales.

Prueba de volumen
es un tipo de prueba no funcional realizada por el equipo de ingeniería de rendimiento. La prueba de volumen es uno de los tipos de pruebas de rendimiento. Las pruebas de volumen se llevan a cabo para encontrar la respuesta del software con diferentes tamaños de los datos que se reciben o procesan. Por ejemplo, si estuviera probando Microsoft Word, la prueba de volumen sería ver si MS Word puede abrir, guardar y trabajar en archivos de diferentes tamaños (10 a 100 MB).

Pruebas de vulnerabilidad
implica identificar y exponer las vulnerabilidades de software, hardware o red que pueden ser explotadas por los piratas informáticos y otros programas maliciosos como virus o gusanos. La prueba de vulnerabilidad es clave para la seguridad y disponibilidad del software. Con el aumento de los piratas informáticos y los programas maliciosos, las pruebas de vulnerabilidad son fundamentales para el éxito de una empresa.

Prueba de caja blanca
La prueba de caja blanca también se conoce como prueba de caja clara, prueba de caja transparente y prueba de caja de vidrio. La prueba de caja blanca es un enfoque de prueba de software, que tiene la intención de probar software con conocimiento del funcionamiento interno del software. El enfoque de prueba de recuadro blanco se utiliza en las pruebas unitarias, que generalmente realizan los desarrolladores de software. La prueba de caja blanca tiene la intención de ejecutar el código y las declaraciones de prueba, ramas, ruta, decisiones y flujo de datos dentro del programa que se está probando. Las pruebas de caja blanca y las pruebas de caja negra se complementan entre sí, ya que cada uno de los enfoques de prueba tiene el potencial de descubrir una categoría específica de errores.

Conceptos básicos de pruebas de software

Déjame explicarte en base a mi experiencia. Trataré de simplificar lo más posible. Mi explicación dada a continuación no será definición. Será más una transferencia de conocimiento según mi experiencia profesional.

¿Qué es la prueba?
La prueba es un proceso en el que probamos algunos productos para identificar defectos. El recién llegado a la industria de las pruebas lo hará la mayor parte del tiempo. Aquí el producto puede ser una aplicación móvil, una aplicación web, una aplicación de escritorio, una aplicación basada en ETL o puede ser cualquier cosa.

¿Qué es el control de calidad?
El control de calidad es un proceso para verificar que tenemos un proceso de desarrollo adecuado y que el producto desarrollado es utilizable. El responsable de control de calidad se dedicará principalmente a escribir casos de prueba y a asegurarse de que el producto sea la etapa utilizable y que se cumplan todos los criterios de aceptación.

¿Qué es un caso de prueba?
Un caso de prueba es un conjunto de instrucciones / pasos que debe seguir para probar una aplicación. P.ej. La funcionalidad de inicio de sesión simple para una aplicación de comercio electrónico puede tener 6 casos de prueba diferentes para probarla. El caso de prueba debe ser subjetivo y cualquier recién llegado debe poder ejecutar el caso de prueba. Debería tener instrucciones muy detalladas. Consulte la captura de pantalla a continuación.

Hay muchos tipos de pruebas. Pero a continuación se presentan un conjunto de técnicas / términos de prueba de bajo nivel que generalmente se siguen en la industria.
Pruebas unitarias : esto lo realiza el desarrollador. Él / Ella escribirá el código para probar su propio código. El probador / QA realmente no tiene que preocuparse por esta parte.
Prueba de humo : esta es una prueba básica que hacemos en un producto para asegurarnos de que el producto sea comprobable.
Pruebas de regresión : en el conjunto de pruebas de regresión, vamos a tener un conjunto de pruebas que creemos que necesitamos ejecutar cada vez que se cambia la funcionalidad de un producto o se agrega nueva funcionalidad. Esta prueba generalmente lleva mucho tiempo. Entonces, antes de saltar a él, nos aseguramos de que el producto esté en condiciones comprobables mediante la ejecución de un conjunto básico de casos de prueba seleccionados para la prueba de humo.
Nueva prueba : esto generalmente se hace cuando se resuelve un error. Entonces, como probador, levanto un error. Mientras tanto, incluso selecciono un conjunto de casos de prueba a través de los cuales identifiqué esos errores. Una vez que el error se marca como solucionado o resuelto, ejecuto ese conjunto de casos de prueba para asegurarme de que el error ya no se encuentre. Si el error no está relacionado con ningún caso de prueba, escribo nuevos casos de prueba y los ejecuto.
Pruebas de aceptación / UAT : una vez que haya terminado con las pruebas, su producto será entregado al equipo comercial que obtuvo el requisito. Harán sus propias pruebas para asegurarse de que puedan transmitir el producto al cliente o al consumidor.

Además de los cuatro tipos de pruebas anteriores, a continuación hay algunas pruebas que hacemos. Todos los siguientes son generalmente completos o parte de las pruebas de regresión dependiendo del producto.
Pruebas de integración : en las pruebas de integración, nos aseguramos de que todos los módulos del producto estén integrados correctamente. Por ejemplo, verifique que Gmail esté correctamente integrado con Google Drive.
Prueba de interfaz y usabilidad : Esto es para verificar que el producto conserve su interfaz y funciones de la misma manera en todas las combinaciones de plataformas. Por ejemplo, para verificar que el sitio de comercio electrónico se carga de la misma manera en todos los navegadores diferentes en todas las computadoras de escritorio y tabletas.
Pruebas funcionales : en las pruebas funcionales, nos aseguramos de que el producto sea funcional en plataformas específicas. P.ej. Para asegurarse de que el usuario pueda cargar un archivo desde la máquina Windows y desde la máquina Mac también con la combinación diferente de navegadores.
Prueba del sistema : en las pruebas del sistema, prueba todo el sistema para asegurarse de que funciona bien antes de la UAT.

Todo lo anterior fue para asegurarse de que el software funciona en diferentes entornos / plataformas o dispositivos. Entonces, en general, los llamamos pruebas de funcionalidad. A continuación se muestra una lista de las pruebas que realizamos en el producto de software donde no necesitamos conocer la funcionalidad completa del producto. Por eso los llamamos pruebas no funcionales.
Prueba de carga / Prueba de esfuerzo : aquí colocamos la carga en el producto para asegurarnos de que funcione bien. Por ejemplo, si está desarrollando la aplicación móvil, nos aseguramos de que, después de activar todas las funcionalidades, siga siendo funcional. En el caso de una aplicación de comercio electrónico, verificamos que el sitio se carga incluso si miles de usuarios acceden al mismo tiempo desde diferentes ubicaciones.
Pruebas de compatibilidad y migración : en esto, nos aseguramos de que el sistema no se rompa si se migra a la plataforma diferente. Si se requiere un sistema para no romperse. P.ej. Se espera que la aplicación basada en Java Swing funcione incluso si se migra de Windows a Mac / Linux.
Prueba de conversión de datos : como su nombre lo indica, por ejemplo, tiene todos sus datos en CSV o Excel y es necesario cargarlos en MSSQL DB, debe asegurarse de que todas las tablas y relaciones se creen correctamente.
Pruebas de seguridad / penetración: si tiene una aplicación que se enfrenta a una gran audiencia, debe asegurarse de la seguridad de la aplicación realizando varias pruebas de seguridad en la misma.
Pruebas de instalación : aquí se asegura de que si su sistema tiene un proceso de instalación, funcione bien en todas las plataformas requeridas.

Además, la gente generalmente me pregunta qué haces en las pruebas de caja negra o en la prueba de caja blanca . Por lo tanto, los términos prueba de caja negra y prueba de caja blanca son tipos de agrupación de tipos de prueba o casos de prueba. Usted prueba el sistema sin comprender los algoritmos internos. Son pruebas de caja negra. P.ej. Funcionalidad de búsqueda en la aplicación de comercio electrónico. Su caso de prueba es parte de la prueba de regresión aquí. En las pruebas de caja blanca, sabe cómo fluyen los algoritmos internos y los datos. P.ej. En el producto basado en ETL, debe saber de principio a fin, cómo se extraen los datos y se mueven a una tabla diferente y qué lógicas comerciales se aplican. Por lo general, no existe un concepto de prueba de caja negra hoy en día. Como, los probadores se están convirtiendo en expertos en tecnología y conocen el sistema internamente, incluidos los algoritmos y el flujo de datos. Por lo general, lo llamamos prueba de caja gris .

Términos de la industria.
Hay pocos términos acuñados por empresarios y ejecutivos de alto nivel como pruebas de escritorio , pruebas móviles , pruebas ETL , pruebas de BI , etc. Por lo tanto, todas esas son palabras de alto nivel donde se le da un producto, puede ser un producto basado en ETL, Producto BI, producto basado en IOT. Entonces, cuando escuche las pruebas IOT, es más como probar una aplicación IOT. Como QA, debe definir qué probar y también definir su suite de humo y su suite de regresión.

Automatización de pruebas: hay muchas pruebas que probará, una y otra vez, diga todas sus pruebas de humo y todas sus pruebas de regresión. Esas pruebas las puede automatizar usando varias herramientas como selenio, QTP. El proceso de automatización de tales pruebas se llama automatización de pruebas.

src: ¿Me puede dar algunos conceptos básicos de las pruebas de software?

Consulte la publicación original aquí: Tipos de pruebas de software | Recursos de automatización de prueba

¿Qué son los tipos de pruebas de software?

Los tipos de prueba de software son las diferentes formas y estrategias que lleva a cabo para verificar un software o aplicación por completo, cada tipo se enfoca en un objetivo de prueba particular con una estrategia de prueba diferente. Para ayudarlo a descubrir qué tipo de prueba es la más adecuada para sus proyectos, este artículo aclarará los tipos de prueba más populares junto con la definición detallada y el objetivo.

1. Pruebas funcionales

La prueba funcional es un tipo de prueba de software que aclara el desempeño de funciones particulares de una aplicación de software.

La responsabilidad de las pruebas funcionales es asegurarse de que la aplicación y todas sus funciones funcionen exactamente como los requisitos comerciales y califiquen todas las especificaciones. Es un método de prueba primario para verificar que la salida proporcionada por cada función de la aplicación es la misma que la esperada.

2. Prueba de GUI

La prueba de la interfaz gráfica de usuario (GUI) es un procedimiento para garantizar que la función de la interfaz de usuario: los elementos visuales siguen sus especificaciones e identifican los defectos. Los elementos que deben verificarse pueden incluir el diseño, barras de menú, barras de herramientas, colores, fuentes, tamaños, iconos, contenido, botones, etc. ¿Cómo interactúan con las acciones del usuario?

3. Pruebas de rendimiento

Las pruebas de rendimiento se realizan principalmente para determinar cómo se comporta un sistema en términos de capacidad de respuesta, estabilidad y confiabilidad bajo cargas de trabajo individuales. Con diferentes tipos de pruebas de rendimiento, recibirá diferentes datos. Por ejemplo, los KPI informan sobre una cantidad de usuarios virtuales, número de aciertos o errores por segundo, tiempo de respuesta y las correlaciones entre ellos. A partir de eso, puede descubrir los cuellos de botella, los errores y los errores … fácilmente.

4. Prueba de carga

La prueba de carga es un tipo de prueba de rendimiento que evalúa la carga natural en cualquier software, aplicación o sitio web. Observa cómo se comporta el sistema de cargas normales a altas y determina si puede manejar cargas altas dada la gran demanda de los usuarios finales. Esta herramienta generalmente se realiza cuando el proyecto está a punto de ser lanzado.

Los beneficios de las pruebas de carga son descubrir obstáculos antes del lanzamiento del producto, controlar el tiempo de inactividad del sistema, aumentar la satisfacción del usuario y disminuir los costos por fallas.

5. Pruebas de seguridad

Security Testing es un proceso de prueba que garantiza que la aplicación y el sistema estén libres de posibles lagunas y debilidades que pueden generar un gran problema para las empresas, como la pérdida de información privada.

El propósito de la Prueba de seguridad es proteger la información de la organización y verificar si la aplicación está bajo un ataque vulnerable cuando el hacker intenta destruir el sistema o iniciar sesión sin autenticación.

6. Pruebas unitarias

Una prueba de unidad es una pequeña parte individual de un programa que se puede probar, puede ser desde funciones completas hasta un pequeño botón del software, debe asegurarse de que todas las unidades pequeñas puedan funcionar individualmente antes de confirmar que todo el software está funcionando. Listo para trabajar.

Los desarrolladores de software pueden realizar pruebas unitarias para garantizar que el código siga el diseño y las especificaciones y reaccione como se espera.

El objetivo de las pruebas unitarias es separar la aplicación en partes particulares para verificar que funcionen correctamente.

7. Pruebas de integración

Como nombre de las pruebas de integración, este tipo de prueba es verificar la interfaz y la integración entre componentes, interacciones entre otras partes del sistema, como el sistema operativo, el sistema de archivos y el hardware …

Las pruebas de integración parecen ser similares a las pruebas unitarias, excluyendo una cosa: mientras que las pruebas unitarias están segregadas de otros elementos, las pruebas de integración no lo están.

8. Pruebas de usabilidad

La prueba de usabilidad es el proceso de verificar la facilidad de uso de un diseño dentro de un grupo de usuarios objetivo. A menudo implica observar la flexibilidad en el manejo de los controles y la capacidad del sistema para cumplir sus objetivos. Es un proceso repetido desde el desarrollo temprano hasta el lanzamiento.

El papel principal de las pruebas de usabilidad es descubrir los problemas de usabilidad en un diseño lo antes posible, para que puedan resolverse antes de que el diseño se aplique en producción. Además, las pruebas de usabilidad generalmente se implementan en prototipos más que en productos finales.

9. Pruebas de accesibilidad

Como subconjunto de las pruebas de usabilidad, las pruebas de accesibilidad son un proceso para garantizar que los usuarios de todas las capacidades y todos los niveles puedan usar su software o aplicación. Particularmente, generalmente se usa para probar software, hardware, aplicaciones móviles y sitios web.

En un proceso de prueba de accesibilidad, el probador usa el producto como un usuario deshabilitado. Las discapacidades pueden incluir sordos o con problemas de audición, discapacidad intelectual, discapacidad visual o debilidad funcional de las extremidades.

10. Pruebas exploratorias

Las pruebas exploratorias son una técnica de prueba sin guión que se centra en la autonomía y la creatividad del control de calidad. Este es un enfoque práctico en el que los evaluadores participan mucho en la ejecución de la prueba pero no mucho en la planificación. Las pruebas exploratorias se utilizan para descubrir problemas desconocidos durante y después del procedimiento de desarrollo de software. Además, el probador puede aplicar este tipo de prueba para descubrir errores específicos, esa es una manera de aprender sobre la aplicación y diseñar casos de prueba funcionales y de regresión que se ejecutarán en el futuro.

Hay muchos tipos de pruebas como

• Examen de la unidad
• Pruebas de integración
• Pruebas Funcionales
• Prueba de sistema
• Pruebas de estrés
• Pruebas de rendimiento
• Pruebas de usabilidad
• Test de aceptación
• Pruebas de regresión
• Prueba beta

Esto incluye múltiples tipos de pruebas de software que permitirán validar el software en su conjunto (software, hardware y red) según los requisitos para los que fue construido. Se llevan a cabo diferentes tipos de pruebas (pruebas de GUI, pruebas funcionales, pruebas de regresión, pruebas de humo, pruebas de carga, pruebas de estrés, pruebas de seguridad, pruebas de estrés, pruebas ad-hoc, etc.) para completar las pruebas del sistema.

Consulte el siguiente enlace:

8 escenarios de prueba de aplicaciones móviles que todo control de calidad debe probar – Humble Bits

Pruebas de portabilidad en QA

21 de marzo de 2017 Pruebas de software, curso de pruebas de software en pune, prueba de software en pune, instituto de pruebas de software en pune, prueba de portabilidad de pruebas de software, QA, clases de pruebas de software en pune, curso de pruebas de software en pune, curso de pruebas de software en Pune con colocación, instituto de pruebas de software en pune, capacitación en pruebas de software en pune

Aquí hay otro concepto de las pruebas de software. Se llama como prueba de portabilidad. Vamos a estudiar más o menos lo mismo, en este artículo. Busque cursos de prueba en Pune, para obtener el tipo adecuado de capacitación en este campo. Te ayudaría a largo plazo. Clases de prueba en Pune , realizar tales cursos.

Ahora, centremos nuestra atención en las pruebas de portabilidad.

Las pruebas de portabilidad aluden al proceso de probar la sencillez con la que un módulo o aplicación de software basado en computadora se puede cambiar de un entorno a otro, por ejemplo, la transferencia de cualquier aplicación de Windows 2000 a Windows 10. Esto normalmente se mide en la medida de lo posible. Se permite una medida extrema de esfuerzo. Los resultados se miden con respecto al tiempo requerido para mover el software y completar las actualizaciones relacionadas con la documentación.

Tener la capacidad de cambiar el software comenzando con una plataforma de máquina y luego a la siguiente, ya sea al principio o desde un entorno actual. Alude al software del sistema o la programación de aplicaciones que se pueden volver a compilar para una plataforma alternativa o al software que es accesible para al menos dos entornos únicos.

El ciclo de desarrollo repetitivo e incremental infiere que las pruebas de portabilidad se realizan con frecuencia de manera repetitiva e incremental.

Las pruebas de portabilidad deben automatizarse si se va a realizar una prueba de regresión óptima. Para saber más sobre las pruebas de regresión, ingrese a un curso de prueba de software en Pune .

Pruebas que forman parte de las pruebas de portabilidad:

• Adaptabilidad:

La adaptabilidad es la capacidad del software para ajustarse a varias condiciones determinadas sin aplicar acciones o medios distintos a los acomodados por este motivo para el sistema.

• Instalabilidad:

La prueba de instalabilidad se lleva a cabo en el producto utilizado para instalar otros softwares en su entorno objetivo.

• Reemplazabilidad:

La capacidad de reemplazo es la capacidad del software para ser utilizado como parte del lugar de otro producto predefinido por una razón similar en un entorno similar.

• Compatibilidad:

La concurrencia es la capacidad del producto de software de existir junto con otros productos de software autónomos en situaciones típicas que comparten activos comunes.

Ilustraciones de pruebas de portabilidad de una aplicación que resulta ser portátil en una serie de:

• Sistemas operativos (implica paquetes de servicio y versiones).
• Navegadores (que incluyen tipos y versiones, ambos).
• Plataformas relacionadas con el hardware (que incluye servidores, clientes, dispositivos de entrada, dispositivos de salida y dispositivos de conexión de red).

Objetivos de prueba de portabilidad:

• Valide el sistema de forma parcial (es decir, para determinar si cumple con los requisitos previos de portabilidad):

– Determine si el sistema se puede portar a cada uno de sus entornos relacionados:

– Espacio en disco y RAM de hardware.

– Velocidad del procesador y hardware.

– Resolución del monitor.

– Versión y marca del sistema operativo.

– Tipo y versión del navegador.

– Determine si el aspecto de las páginas del sitio es comparativo y funcional en los diferentes tipos de navegadores y sus variantes.

• Causar decepciones con respecto a los requisitos previos de portabilidad que ayudan a distinguir los defectos que no se encuentran de manera competente en medio de las pruebas de unidad e integración.
• Informe estos defectos a los equipos de desarrollo para que las fallas relacionadas puedan resolverse.
• Ayude a decidir el grado en que el sistema está preparado para un lanzamiento.
• Ayudar a proporcionar métricas de estado del proyecto (por ejemplo, cantidad de rutas de casos de uso efectivamente probadas).
• Contribuya al esfuerzo de investigación de tendencias de defectos.

Por lo tanto, vimos algunos detalles relacionados con las pruebas de portabilidad. Espero que tenga una buena idea sobre las pruebas de portabilidad.

Para un enfoque detallado hacia la portabilidad y otros tipos de pruebas, la capacitación en pruebas de software en Pune sería de gran ayuda.

En realidad, hay una gran variedad de ellos. Manual, automatizado, funcional, carga, humo, exploratorio, usabilidad, interfaz de usuario, regresión, navegador cruzado, prueba multiplataforma. http://testmatick.com/our-qa-ser … puede consultar este sitio web y obtener más información sobre las pruebas y sus tipos.
El proceso de prueba se puede clasificar en
1) el acceso a un código fuente
– prueba de caja negra
– prueba de caja blanca

2) si es necesario llevar a cabo un código fuente
– pruebas dinámicas
– pruebas estáticas

3) cobertura de la aplicación probada
– examen de la unidad
– pruebas de integración
– prueba del sistema
– pruebas alfa y beta

4) áreas probadas de la aplicación
– prueba de humo
– pruebas funcionales
– Prueba de carga
– pruebas de seguridad
– pruebas de usabilidad

Las pruebas de software garantizan la calidad. Evalúa el software contra los requisitos recopilados de los clientes. Las pruebas de software forman parte del proceso de desarrollo de software. Los casos de prueba deben escribirse antes de escribir el código tan pronto como se capturen los requisitos. Esto ayuda a identificar los errores y corregirlos rápidamente.

Hay muchas pruebas diferentes disponibles, pero estas son las principales que son esenciales para crear software de trabajo.

1. Pruebas unitarias

2. Pruebas de integración

3. Prueba funcional

4. Pruebas de rendimiento

5. Prueba del sistema

6. Pruebas de usabilidad

7. Pruebas de seguridad

Para garantizar la calidad y el rendimiento de su producto según los requisitos del cliente, las pruebas de software son imprescindibles. Para saber más sobre las técnicas y métodos de prueba de software, estamos allí para ayudarlo.

Ubiquity Techs es una de las empresas de desarrollo de software más importantes de la India.

Tipos de pruebas

Las pruebas de software siempre son responsables. No probamos el código, probamos cómo funciona. Una vez que se ha implementado una característica, los ingenieros de control de calidad realizan pruebas funcionales. Estas pruebas verifican cómo funciona la lógica. Después de eso, ejecutamos pruebas de IU. Se necesitan para ver si la interfaz está en línea con el diseño y los estándares elegidos (pautas). Al final de cada sprint, hay una prueba de humo de software , tiene que demostrar que la lógica comercial principal se ha implementado correctamente y funciona a la perfección junto con la funcionalidad principal.

Hay cuatro tipos de pruebas que realizamos aquí en Cleveroad. Son:

Servicios de prueba de control de calidad

La prueba de desarrollo básica es una verificación después de la cual no hay bloqueadores ni errores críticos. Después de las pruebas de desarrollo avanzadas , los especialistas en control de calidad detectan todos los errores más importantes (si los hay) y los desarrolladores los reparan.

Las pruebas básicas y avanzadas ya están incluidas en el precio del desarrollo y los clientes no pagan por ellas.

Después de estas comprobaciones básicas y avanzadas, un producto de calidad no debe tener ningún bloqueador, defectos críticos importantes. Pero puede tener pocos defectos menores y algunos defectos triviales.

En caso de que un error menor o trivial sea fácil de ver y un ingeniero de control de calidad lo encuentre, los desarrolladores también lo solucionan y un cliente no tiene que pagar más por eso.

(Más información en el artículo completo ¿Qué son las pruebas de software y cómo lo ejecutamos en Cleveroad siguiendo los más altos estándares de calidad? )

La prueba de software es un proceso de investigación en el que varios aspectos del tiempo de ejecución coinciden con los aspectos requeridos. Las pruebas pueden clasificarse aún más en muchos tipos. Como el desarrollo cubre un dominio grande, de manera similar las pruebas también cubren un dominio grande. Los tipos de pruebas de software se analizan a continuación brevemente:

Tipos de pruebas de software

Prueba de WhiteBox:

Las pruebas se basan en la lógica interna de la parte de codificación. La prueba de caja de vidrio es también uno de los nombres populares para la prueba de caja blanca. Esta parte de las pruebas es realizada principalmente por desarrolladores que se convirtieron en probadores con experiencia.

Prueba de BlackBox:

El diseño del sistema interno o la parte de codificación no se consideran en este tipo de pruebas. Principalmente se verifican diversas funcionalidades.

Pruebas de integración:

Como su nombre lo indica claramente, las pruebas se realizan cada vez que se agrega una nueva funcionalidad al producto. En este tipo de prueba se utiliza un enfoque ascendente.

Examen de la unidad:

Examen de la unidad de módulos de software individuales. Este tipo de prueba la realiza el programador.

Pruebas funcionales:

Las pruebas funcionales se centran en los componentes principales y pequeños de la funcionalidad. Este tipo de prueba no tiene nada que ver con el código de la aplicación.

Prueba del sistema:

Se verifica todo el sistema de solicitud completa. Las pruebas de caja negra cubren las pruebas del sistema.

Pruebas de regresión:

La prueba de regresión se realiza cada vez que se realiza algún cambio en la funcionalidad. Siempre existe la posibilidad de que alguna funcionalidad se vea afectada cuando reparamos cualquier otra funcionalidad. Esta prueba se realiza principalmente con el uso de cualquier herramienta de prueba de automatización.

Test de aceptación:

Este tipo de prueba se realiza para verificar la aceptación según los requisitos del cliente.

Prueba de carga:

La prueba de carga se realiza para asegurarse de que el sitio web o el software puedan funcionar correctamente bajo carga.

Pruebas de estrés:

La aplicación se prueba aumentando la carga más allá de ciertas especificaciones. El comportamiento de la aplicación se observa bajo condiciones de estrés. Se intenta averiguar el punto donde falla la aplicación.

Prueba alfa:

Este tipo de prueba se realiza al final del equipo de desarrollo. El entorno de usuario virtual se crea para verificar la aplicación.

Prueba beta:

Este tipo de prueba es realizada por varios usuarios finales. Este tipo de prueba se realiza justo antes del lanzamiento final de la aplicación.

1) Prueba de caja negra :
El diseño del sistema interno no se considera en este tipo de pruebas.
Es un método de prueba de software en el que los probadores no están obligados a conocer la codificación o la estructura interna del software.
Las pruebas se basan en los requisitos y la funcionalidad.

2) Prueba de caja blanca :
La prueba de caja blanca también se conoce como prueba de caja clara, prueba de caja transparente y prueba de caja de vidrio.
Esta prueba se basa en el conocimiento de la lógica interna del código de una aplicación.
El enfoque de prueba de recuadro blanco se utiliza en las pruebas unitarias que generalmente realizan los desarrolladores de software.

3) Prueba unitaria :
Prueba de componentes o módulos de software individuales.
Lo realiza el programador y no los probadores, ya que requiere un conocimiento detallado del diseño y el código interno del programa.
Las pruebas unitarias generalmente implican el desarrollo de trozos y controladores. Las pruebas unitarias son candidatos ideales para la automatización.

4) Pruebas de integración incremental :
El enfoque de abajo hacia arriba para las pruebas es la prueba continua de una aplicación a medida que se agrega una nueva funcionalidad.
Lo hacen programadores o probadores.

Leer más Tipos de pruebas de software

Para una pregunta como esta y dado que usted pregunta, ‘cuándo se debe usar cada una’, recomendaría comprender lo que se está probando. Una vez que comprenda que puede darse cuenta de que hay muchas técnicas . También hay mucha jerga.

Para mí, un buen comienzo es pensar que las pruebas son preguntas no intuitivas sobre el software que se está probando. Esto es muy similar a las preguntas que se hacen en http://Quora.com :

¿Por qué los hombres prefieren realizar sus negocios mientras están de pie? por Nilanjan Bhattacharya en Contrafactuals

Creo que la mayoría de la gente no está segura de esta idea general sobre las pruebas.

Solo marcaría una diferencia entre las pruebas de desarrollador, como las pruebas unitarias o las pruebas de caja blanca y las pruebas realizadas por probadores.

¡Hay tantas maneras de responder esta pregunta!

Puede clasificar los tipos de pruebas de muchas maneras: lo que prueban, cómo las ejecuta, cuándo las ejecuta, etc.

Aquí, ayudé a clasificar las pruebas basadas en los diferentes factores de calidad del software definidos por la Organización Internacional de Normalización. Terminaron siendo 8 “tipos” de pruebas. La rueda a continuación ofrece una visión general amplia y buena, y la publicación adjunta ofrece muchos más detalles sobre todas las pruebas que se incluyen en cada tipo.

Lea esta publicación para más detalles:

La rueda de pruebas de software

Mira este también:

Existen 100 tipos de pruebas de software que nunca conociste

¡Espero que esto ayude!