Pruebas de Software

Nota:

• Definicion

1. Una prueba es una actividad en la que un sistema o un componente es ejecutado bajo condiciones especificadas, los resultados son observados o registrados, y una evaluación es realizada de un aspecto del sistema o componente

   Nota:

   • Segun IEEE Std.610.12-1990]
2. Una prueba es una actividad ejecutada para evaluar y mejorar la calidad del producto a través de la identificación de defectos y problemas

   Nota:

   • Segun [SWEBOK]

1. Evitar redundancias: traen consigo una pérdida o desaprovechamiento de tiempo por lo que hay que intentar ejecutar las pruebas más adecuadas a cada situación y lo más rápido posible.
2. Reducir costes:Habría que cerciorarse de que realmente fueran necesarias y de que existe el tiempo y las habilidades suficientes para emplearlas de manera ventajosa.

1. El nivel de confianza requerido depende de tres factores:
   1. El propósito o función del sistema. El nivel de confianza necesario depende de lo crítico que sea el software para una organización.
   2. Las expectativas del usuario. es menos aceptable entregar sistemas no fiables, por lo que las compañías deben invertir más esfuerzo en llevar a cabo las actividades de verificación y validación.
   3. Entorno de mercado actual. Cuando un sistema se comercializa, los vendedores del sistema deben tener en cuenta los sistemas competidores,
2. la Validación en CMMI® es demostrar que un producto o componente del mismo satisface el uso para el que se creó al situarlo sobre el entorno previsto.siguiente pregunta: ¿Se está construyendo el producto correcto?
3. El propósito de la Verificación en CMMI® es asegurar que los productos seleccionados cumplen los requisitos especificados.¿Se está construyendo el producto de la manera correcta?

1. En función de qué conocemos.
   1. a. Pruebas de caja negra
      1. probar dando distintos valores a las entradas
      2. Este tipo de prueba se centra en los requisitos funcionales del software y permite obtener entradas que prueben todos los flujos de una funcionalidad
      3. Funcionalidades incorrectas o ausentes.
      4. Errores de interfaz.
      5. Errores en estructuras de datos o en accesos a las bases de datos externas.
      6. Errores de rendimiento.
      7. Errores de inicialización y finalización.
   2. b. Pruebas de caja blanca
      1. Consiste en realizar pruebas para verificar que líneas específicas de código funcionan tal como esta definido.
      2. Se ejecutan al menos una vez todos los caminos independientes de cada módulo
      3. Se utilizan las decisiones en su parte verdadera y en su parte falsa
      4. Se ejecuten todos los bucles en sus límites
      5. Se utilizan todas las estructuras de datos internas.
      6. Para esta prueba, se consideran tres importantes puntos.
         1. Conocer el desarrollo interno del programa, determinante en el análisis de coherencia y consistencia del código.
         2. Considerar las reglas predefinidas por cada algoritmo.
         3. Comparar el desarrollo del programa en su código con la documentación pertinente.
2. Según el grado de automatización
   1. a. Pruebas manuales
      1. Las pruebas manuales ayudarán a descubrir cualquier problema relacionado con la funcionalidad de su producto, especialmente defectos relacionados con facilidad de uso y requisitos de interfaces.
   2. Pruebas automáticas
      1. tipo de pruebas, se usa un determinado software para sistematizarlas y obtener los resultados de las mismas.
3. En función de qué se prueba
   1. Pruebas unitarias
      1. Se aplican a un componente del software. Podemos considerar como componente (elemento indivisible) a una función, una clase, una librería, etc.
      2. Para que una prueba unitaria, tenga éxito se deben cumplir los siguientes requisitos:
         1. Automatizable: no debería existir intervención manual. Esto es, especialmente, útil para la integración continua.
         2. Completas: deben cubrir la mayor cantidad de código.
         3. Repetibles o Reutilizables: no se deben crear pruebas que sólo puedan ser ejecutadas una sola vez. También, es útil para integración continua.
         4. Independientes: la ejecución de una prueba no debe afectar a la ejecución de otra.
         5. Profesionales: las pruebas deben ser consideradas igual que el código, con la misma profesionalidad, documentación, etc.
      3. Estas pruebas aisladas proporcionan cinco ventajas básicas:
         1. Fomentan el cambio: Las pruebas unitarias facilitan que el programador cambie el código para mejorar su estructura (lo que se llama refactorización),
         2. Simplifica la integración: Puesto que permiten llegar a la fase de integración con un grado alto de seguridad de que el código está funcionando correctamente.
         3. Documenta el código: Las propias pruebas son documentación del código puesto que ahí se puede ver cómo utilizarlo.
         4. Los errores están más acotados y son más fáciles de localizar: dado que tenemos pruebas unitarias que pueden desenmascararlos.
         5. Separación de la interfaz y la implementación: Dado que la única interacción entre los casos de prueba y las unidades bajo prueba son las interfaces de estas últimas, se puede cambiar cualquiera de los dos sin afectar al otro.
   2. Pruebas de integración
      1. Consiste en construir el sistema a partir de los distintos componentes y probarlo con todos integrados.
   3. c. Pruebas de aceptación
      1. lleva a cabo el equipo de desarrollo. Consiste en comprobar si el producto está listo para ser implantado para el uso operativo
         1. Podemos distinguir entre dos tipos de pruebas
            1. Pruebas alfa: las realiza el usuario en presencia de personal de desarrollo del proyecto haciendo uso de una máquina preparada para las pruebas.
            2. Pruebas beta: las realiza el usuario después de que el equipo de desarrollo les entregue una versión casi definitiva del producto.
   4. Pruebas funcionales
      1. se realiza sobre el sistema funcionando, comprobando que cumpla con la especificación (normalmente a través de los casos de uso). Para estas pruebas, se utilizan las especificaciones de casos de prueba.
   5. e. Pruebas de rendimiento
      1. se basan en comprobar que el sistema puede soportar el volumen de carga definido en la especificación