1. Tipos de Pruebas de Software
1.1. Pruebas de Códigos:
1.1.1. Son revisiones de código fuente para identificar defectos. Ejemplo: Un programador revisa manualmente el código para detectar errores de sintaxis o lógicos.
1.2. Pruebas Unitarias
1.2.1. : Se prueban componentes individuales del software, como funciones o métodos, para verificar que funcionan correctamente de manera aislada. Ejemplo: Probar una función de suma para asegurarse de que devuelva el resultado correcto para diferentes entradas.
1.3. Pruebas de Integración
1.3.1. Se combinan y prueban múltiples módulos o componentes para asegurarse de que funcionan correctamente en conjunto. Ejemplo: Verificar que un módulo de login funcione correctamente con el módulo de base de datos.
1.4. Pruebas de Sistema
1.4.1. Se prueba el sistema completo para asegurar que cumpla con los requisitos especificados. Ejemplo: Simular el uso completo de una aplicación para asegurarse de que todas las funciones operen correctamente en conjunto.
1.5. Pruebas de Aceptación
1.5.1. Se verifican si el software cumple con las expectativas del usuario y los requisitos de negocio antes de su lanzamiento. Ejemplo: Un cliente final prueba la aplicación para asegurarse de que todas las funciones necesarias estén presentes y operativas.
1.6. Pruebas de Caja Blanca
1.6.1. Evalúan la estructura interna del software. Se requiere conocimiento del código fuente y se prueban caminos específicos. Ejemplo: Analizar y probar cada posible camino de ejecución en un algoritmo para asegurar que todos funcionen correctamente.
1.7. Pruebas de Caja Negra
1.7.1. Evalúan la funcionalidad del software sin tener en cuenta la estructura interna. Se basa en entradas y salidas. Ejemplo: Probar una función de login ingresando diferentes combinaciones de nombre de usuario y contraseña sin ver el código que las maneja.
2. Análisis Comparativo
2.1. Diferencias clave
2.1.1. Caja Blanca: Se enfoca en la estructura interna del software, como los flujos de control y los caminos de datos. Caja Negra: Se enfoca en la funcionalidad externa sin preocuparse por el código interno.
2.2. Situaciones adecuadas
2.2.1. Caja Blanca: Es útil cuando se necesita asegurar la cobertura completa del código, como en escenarios donde la calidad interna y la eficiencia son cruciales. Caja Negra: Es adecuada cuando se quiere probar la funcionalidad general del software desde la perspectiva del usuario final, sin conocer los detalles técnicos.
3. Definiciones
3.1. Funcionalidad:
3.1.1. Se refiere a la capacidad del software para cumplir con las tareas y funciones para las que fue diseñado. Esto incluye la correcta implementación de las características, la capacidad de producir los resultados esperados y la adherencia a los requisitos especificados.
3.2. Rendimiento
3.2.1. Mide la eficiencia con la que un software opera bajo condiciones específicas, como la velocidad de respuesta, el tiempo de procesamiento, la utilización de recursos y la capacidad de manejar una cantidad determinada de usuarios o datos simultáneamente.
3.3. Usabilidad
3.3.1. Se refiere a la facilidad con la que los usuarios pueden aprender a usar el software y la satisfacción que obtienen al interactuar con él. Esto incluye aspectos como la interfaz de usuario, la accesibilidad y la experiencia general del usuario.
3.4. Seguridad
3.4.1. Se enfoca en la protección del software frente a amenazas como ataques cibernéticos, accesos no autorizados, y la capacidad de salvaguardar la integridad, confidencialidad y disponibilidad de los datos manejados por el software.