Unidad 4 Pruebas de Software

4.1 Definiciones

4.1.1 Prueba, Caso de Prueba, Defecto, Falla, Error ,Verificacion, Validacion

Prueba: La prueba de software es un conjunto de herramientas, técnicas y métodos que hacen a la excelencia del desempeño de un programa, así como también la mejor publicidad que una empresa dedicada a la producción de software pueda tener.

Caso de prueba: Casos de prueba o Test Case son un conjunto de condiciones o variables bajo las cuáles el analista determinará si el requisito de una aplicación es parcial o completamente satisfactorio.

Defecto: Un defecto de software (computer bug en inglés), es el resultado de un fallo o deficiencia durante el proceso de creación de programas de ordenador o computadora (software).

Falla: Puede presentarse en cualquiera de las etapas del ciclo de vida del software aunque los más evidentes se dan en la etapa de desarrollo y

programación.

Error: Es una equivocación cometida por un desarrollador. Algunos ejemplos de errores son: un error de tipeo, una malinterpretación de un requerimiento o de la funcionalidad de un método. El estándar 829 de la IEEE coincide con la definición de diccionario de error como “una idea falsa o equivocada”.

Verificación: La verificación del software es el proceso a través del cual se corrobora que el software satisface sus objetivos.

Validación: El proceso de evaluación de un sistema o de uno de sus componentes durante o al final del proceso de desarrollo para determinar si satisface los requisitos marcados por el usuario.

Verificación de software

 Validación. Estamos fabricando el producto correcto? Programa → usuario

 Verificación. Estamos fabricando correctamente el producto? Programa → especificación

 Todas las actividades que se emprenden para asegurar que el software cumple sus objetivos”

 Se deduce que tanto el proceso como el producto deben ser V&V.

 Es el proceso de todo un ciclo vital: La V & V debe aplicarse en cada etapa del software.

 Tiene dos objetivos principales

o El descubrimiento de defectos en el sistema

o La evaluación de si el sistema es útil y utilizable en una situación operacional o no.

Metas de la V&V.

La verificación y la validación deberían establecer la confianza de que el software es adecuado al propósito.

 Esto NO significa que esté completamente libre de defectos.

 Sino que debe ser lo suficientemente bueno para su uso previsto y el tipo de uso determinará el grado de confianza que se necesita.

Confianza de la V&V.

 Depende del propósito del sistema, las expectativas del usuario y el entorno de marketing

 Función del software

 El nivel de confianza depende de lo crítuco que es el sistema para una organización.

 Expectativas del usuario

 Los usuarios pueden tener bajas expectativas para ciertas clases de software.

 Entorno de marketing

 Introducir un producto en el mercado pronto puede ser más importante que encontrar defectos en el programa

Inspecciones de software. Se ocupa del análisis de representaciones estáticas del sistema para describir problemas (verificación estática)

 Pueden ser complementadas por documentos basados en herramientas y análisis del código

 Pruebas del software. Se ocupa de la ejercitación y la observación del comportamiento del producto (verificación dinámica)

 El sistema se ejecuta con datos de pruebas y se observa su comportamiento operativo.

Prueba del programa

 Pruebas de defectos

 Pruebas diseñadas para descubrir defectos en el sistema.

 Una prueba de defectos exitosa es aquella que revela la presencia de defectos en un sistema.

 Pruebas de validación

 Previsto para mostrar que el software cumple sus requerimientos.

 Una prueba con éxito es aquella que muestra que un requerimiento se ha implementado correctamente.

Tipos de pruebas

 Las pruebas de defectos y depuración son distintos procesos.

 La verificación y validación se ocupan de establecer la existencia de defectos en un programa.

 La depuración se ocupa de ubicar y reparar estos errores.

 La depuración implica formular una hipótesis sobre el comportamiento del programa y después probar esta hipótesis y encontrar el error del sistema.