Ejercicios "amistosos"
VERIFICACIÓN & VALIDACIÓN DEL SOFTWARE
La verificación y validación no son la misma cosa. La verificación es para mostrar que un programa cumple su especificación. La validación es para mostrar que el programa hace lo que el usuario requiere.
Los planes de pruebas incluyen una descripción de elementos a probar, la administración de las pruebas, los procedimientos para administrar los procesos de las pruebas, los requerimientos de hardware y software y los problemas que puedan surgir en las pruebas. Las técnicas de verificación estática comprenden el examen y análisis del código fuente del programa para detectar errores. Se utilizan con las pruebas del programa como parte del proceso de V & V.
Las inspecciones de programas son efectivas para encontrar errores. El propósito de una especificación es localizar las fallas. Los analizadores estáticos son herramientas de software que procesan el código fuente del programa y pone atención a las anomalías como las secciones de código no utilizadas y las variables sin inicializar. Estas anomalías son el resultado de las fallas en el código.
El desarrollo de software de 'Sala Limpia' es un enfoque para el desarrollo de software que cuenta con técnicas estáticas para la verificación de programas y estadísticas para la certificación de la fiabilidad del sistema. Ha tenido éxito en la producción de sistemas con un alto nivel de fiabilidad.
Pruebas del Software: Es más importante probar las partes del sistema que se utilizan más frecuentemente que las partes que raramente se ejecutan. Las pruebas de caja negra no necesitan acceder al código fuente. Los casos de pruebas se derivan de la especificación del programa. Las pruebas estructurales analizan un programa para determinar las trayectorias y utilizan éste análisis para ayudar en la selección de los casos de prueba. Las pruebas de integración se enfocan en probar las interacciones entre los componentes de un sistema y las interfaces de los componentes. Los defectos de la interfaz surgen debido a errores cometidos en la lectura de la especificación, a mala interpretación o errores de la especificación, o a suposiciones de tiempo no válidas. Las pruebas de interfaz pretenden descubrir defectos en las interfaces de los objetos o módulos.
Cuando se prueban clases de objetos, se diseñan pruebas que se implementan en todas las operaciones asociadas con una clase, asignan y evalúan todos los atributos del objeto y prueban el objeto en todos los estados posibles. Los sistemas orientados a objetos se integran alrededor de clústers naturales de objetos como los asociados con un caso de uso particular o con un conjunto de casos de uso, o con cadenas de objetos.
-
Discuta las diferencias entre la verificación y la validación del software y explique por qué la validación es un proceso particularmente difícil.
-
Explique por qué no es necesario que un programa esté completamente libre de defectos antes de que se entregue a sus clientes. Hasta dónde se pueden utilizar las pruebas para validar que el programa cumple con su propósito?
-
Utilizando el conocimiento que tiene de C, C++, Java o cualquier otro lenguaje de programación, derive una lista de verificación de errores comunes que no pueden ser detectados por un compilador, pero que podrían detectarse en una inspección del programa.
-
Explique por qué a una organización con una cultura elitista y competitiva le será difícil introducir inspecciones de programas como una técnica de V & V.
-
Explique por qué las inspecciones de programas son una técnica efectiva para descubrir errores en un programa. ¿Qué tipo de errores no es posible descubrir en las inspecciones?
-
Discuta las diferencias entre las pruebas de caja negra y caja blanca.
-
Implemente (con Java o C++) una clase de objetos denominada SYMBOL_TABLE que se pueda utilizar como parte de un sistema de compilación. Debe incluir operaciones para agregar un nombre y la información de tipos asociada a la tabla, borrar un nombre, modificar la información asociada con un nombre y buscar en la tabla. Organice una inspección del programa de este objeto y lleve cuidadosamente la cuenta de los errores descubiertos. Pruebe el objeto utilizando un enfoque de caja negra y compare los errores descubiertos en las pruebas con los descubiertos por la inspección.
