5. Las pruebas representan un interesante reto para los ingenieros de software, quienes por naturaleza son personas constructivas.

Las tcnicas de prueba del software requieren que el desarrollador descarte nociones preconcebidas de los que es correcto en el software y entonces disee difciles casos de prueba para romperlo. 5.1. 5.2. Describa: facilidad de prueba, operatividad, observabilidad, controlabilidad, capacidad para descomponer, simplicidad, estabilidad, Facilidad de comprensin Identifique por cada autor como describen las tcnicas tales: pruebas de caja negra, caja blanca y ejemplifique cada una de sus pruebas.

Operatitividad: Mientras mejor funcione, mas eficiente puede probarse. Si un sistema se disea e implementa teniendo como objetivo la calidad, relativamente pocos errores bloquearan la ejecucion de las prueba, lo que permitira avanzar en ellas sin interrupciones. Observabilidad. Lo que ves es lo que prueba . Las entradas proporcionadas como parte de las pruebas producen distintas salidas. Los estados del sistema y las variables son visibles o consultables durante la ejecucion. Las salida incorrecta se identifica con facilidad. Los errores internos se detectan y se reportan de manera automatica. El codigo fuente es accesible. Controlabilidad. Mientras mejor pueda controlar el software, mas podra automatizar y optimizar las pruebas. Todas las salidas pueden generarse a traves de alguna combinacion de entradas, y los fromatos de entrada/salida (E/S) son consistentes y estructurados. Todo codigo es ejecutable a traves de alguna combinacion de entradas. El ingeniero de pruebas puede controlar directamente los estado sdel software, del hardware y las variables. Las pruebas pueden especificarse, automatizarse y reproducirse convenientemente. Descomponibiliad. Al controlar el ambito de las pruebas, es posiible aislar mas rapidamente los problemas y realizar pruebas nuevas mas inteligentes. El sistema de software se construye a partir de modulos independientes que puedan probarse de manera independiente. Simplicidad. Mientras halla menos que probar, mas rapidamente se le puede probar. El programa debe mostrar simplicidad funcional (por ejemplo, el conjunto caracteristico es el minimo necesario para satisfacer los requerimientos); simplicidad estructural. Estabilidad. Mientras menos cambios, menos perturbaciones para probar. Los cambios al software son raros, se controlan cuando ocurren y no validan las pruebas existentes. El software se recupera bien de los fallos. Comprensibilidad. Mientras mas informacion se tenga, se probara con mas inteligencia. El diseo arquitectonico y las dependencias entre componentes internos externos y compartidos son bien aprendidos. La documentacin tcnica es accesible al instante, esta bien organizada, es especifica, detallada y precisa. Los cambios al diseo son comunicados a los examinadores.

6. El diseo de casos de prueba es una parte de las pruebas de componentes y sistemas en las en las que se disean los casos de prueba (entradas y salidas esperadas) para probar el sistema. El objetivo del proceso de diseo de casos de prueba es crear un conjunto de casos de prueba que sean efectivos descubriendo defectos en los programas y muestren que el sistema satisface sus requerimientos. Existen varias aproximaciones que pueden seguirse para disear casos de prueba. 6.1. Describe las siguientes pruebas y ejemplifica cada una: Pruebas basadas en requerimientos, pruebas de particiones y pruebas estructurales. Pruebas basadas en requerimientos. En donde lo casos de prueba se disean para probar los requerimientos del sistema. Esta aproximacin se utiliza principalmente en la etapa de pruebas

del sistema, ya que los requerimientos del sistema normalmente se impleme por varios componentes. Para cada requerimiento, se identifica casos de prueba que puedan demostrar que el sistema satisface ese requerimiento. Por ejemplo hablemos del siguiente requerimiento. El usuario sera capaz de buscar en un conjunto inicial de bases de datos o bien seleccionar un subconjunto de estas. Posibles pruebas para este requerimiento serian suponiendo que se ha probado una funcion de busqueda. Iniciar la busqueda de usuario para elementos de los que se conoce que estan presentes y ara elementos que se sabe que no estan presentes, en las que el conjunto de bases de datos incluye una base de datos. Iniciar busquedas de usuario para elementos de los que se sabe que estan presentes y para elementos que se sabe que no estan presentes. En las que el conjunto de bases de datos incluye dos bases de datos. Seleccionar mas de una base de datos del conjunto de bases de datos e iniciar bsqueda de usuario para elementos de los que se sabe que estan presentes y para elementos de los que se sabe que no estan presentes. Pruebas basadas en particiones. En donde se identifican particiones de entrada y salida y se disean pruebas para que el sistema ejecute entradas de todas las particiones y genere salidas en todas las particiones. Las particiones son grupos de datos que tienen caracteristicas comunes, como todos los numeros negativos, todos los nombres con menos de 30 caracteres, todos los eventos provocados por la eleccion de opciones en un menu y asi sucesivamente. En la fig 6.1 cada particion es representada mediante un elipse estas son conjuntos de datos en donde todos los miembros de los conjuntos deberian ser procesados de forma equivalente.

SISTEMA
Entradas invalidas Entradas validas

SALIDA

Fig. 6.1

Pruebas estructurales en donde se utiliza el conocimiento de la estructura del programa. Esencialmente cuando se prueba un programa, deberia intentarse ejecutar cada sentencia al menos una vez. Las pruebas estructurales ayudan a identificar casos de prueba que puedan hacer esto posible. Estas son una aproximacion al diseo de casos de prueba n donde la pruebas se derivan a partir del conociemiento de la estructura e implementacion del software. Esta aproximacion es denominada a veces como caja blanca o caja de cristal o caja transparente.

Datos de prueba

Pruebas

Deriva en Codigo componente Salidas de prueba

8. Explique por qu no es necesario que un programa est completamente libre de defectos antes de que sea entregado a sus clientes. No es necesario que est libre de defectos ya que al realizar las pruebas, s o b r e todo las pruebas de defectos, algunas de stas son las que n o s demostrarn que el programa cumple con sus requerimientos. A parte no s e puede demostrar que el software est en su totalidad libre de defectos o que se comporte como hayamos especificado en X circunstancia. Siempre es posible que una prueba que demos por alto descubra ms problemas en el sistema. Las pruebas pueden mostrar slo la presencia de errores, mas no su ausencia.

11 . la prueba exhaustiva (en caso de que sea posible en programas muy pequeos) garantiza que el programa es totalmente correcto? No ya que no es necesario hacer pruebas exhaustivas ya que es mejor hacer un subconjunto de posibles casos de pruebas. Las pruebas exhaustivas no pueden comprobar que el sistema este libre de defectos o que se comportara siempre de manera tal como se especifico. 12. Describa por qu la clase es la menor unidad razonable para la prueba dentro de un sistema orientado a objetos. ( Roger P.) La prueba de clase se activa mediante operaciones encapsuladas por la clase y por el comportamiento de estado de la misma.