Diseo OO

1. Diseo de Software
El diseo es tcnicamente la parte central de la ingeniera del software. Durante el diseo se desarrollan,
revisan y se documentan los refinamientos progresivos de las estructuras de datos, de la estructura del
programa y de los detalles procedimentales.
El diseo es la nica forma mediante la que podemos traducir con precisin los requisitos del cliente en
un producto o sistema acabado. El diseo de software es la base de todas las partes posteriores del
desarrollo y de la fase de prueba.
En otras palabras se puede decir que el diseo de software son las metodologas, tcnicas y actividades
que permiten estructurar y construir un producto de software a partir de los requerimientos del cliente y
con el fin de satisfacer las necesidades del mismo.
Las fases de diseo, codificacin y prueba, absorben el 75% o ms del coste de la ingeniera del software
(excluyendo el mantenimiento). Es aqu donde se toman las decisiones que afectarn finalmente al xito
de la implementacin del programa, y tambin, a la facilidad de mantenimiento que tendr el software.
Mediante algunas metodologas de diseo se realiza el diseo de datos, el diseo arquitectnico, el diseo
procedimental y diseo de interfaz.
El diseo de datos transforma el modelo de campo de informacin, creado durante el anlisis, en
las estructuras de datos que se van a requerir para implementar el software.
El diseo arquitectnico define las relaciones entre los principales elementos estructurales del
programa.
El diseo procedimental transforma los elementos estructurales en una descripcin procedimental
del software.
Diseo de la Interfaz. Establece la disposicin y los mecanismos para la interaccin HombreMquina.
Sin diseo, nos arriesgamos a construir un sistema inestable, un sistema que falle cuando se realicen
pequeos cambios, un sistema que sea difcil de probar, un sistema cuya calidad no pueda ser evaluada
hasta ms adelante, cuando quede poco tiempo y ya sea haya gastado mucho dinero.
2. Fundamentos del diseo de software
Los fundamentos del diseo ayudan al desarrollador de software a responder a estas preguntas:
Qu criterios puedo utilizar para dividir el software en componentes individuales?
Cmo se separan los detalles de una funcin o de la estructura de los datos de la representacin
conceptual del software?
Existen criterios uniformes que definan la calidad tcnica de un diseo de software?
Abstraccin
Cuando se considera una solucin modular para cualquier problema, pueden formularse varios niveles de
abstraccin.
En el nivel superior de abstraccin se establece una solucin en trminos generales, en lenguaje natural.
En los niveles inferiores de abstraccin se utiliza una orientacin ms procedimental. Por ltimo, en el
nivel ms bajo de abstraccin, se establece una solucin, de forma que pueda implementarse
directamente. Se puede decir por ejemplo que una abstraccin de datos es un conjunto de datos que

describen un objeto, como puede ser el DNI de una persona, que est compuesta por conjunto de partes de
informacin, pero que nos podemos referir a todos los datos mencionando el nombre de la abstraccin de
datos.
Estas abstracciones permiten al diseador representar un objeto a diferentes niveles de detalle.
Refinamiento
Comenzamos con una declaracin de la funcin (o una descripcin de la informacin) definida a un nivel
superior de abstraccin. Es decir, la declaracin describe la funcin o la informacin conceptualmente,
pero no proporciona informacin sobre el funcionamiento interno de la funcin o sobre la estructura
interna de la informacin, sino que se va a realizando sucesivamente, dando cada vez ms detalles.
Modularidad
El software se divide en componentes con nombres y ubicaciones determinados, que se denominan
mdulos y que se integran para satisfacer los requisitos del proveedor.
El software monoltico (es decir, un programa grande compuesto de un solo mdulo) no puede ser
estudiado fcilmente por un lector, ya que el nmero de caminos de control, el nmero de variables y la
complejidad global haran el cdigo prcticamente indescifrable.
Arquitectura del Software
La arquitectura del software se obtiene mediante un proceso de particin, que relaciona los problemas del
mundo real (definidos en el anlisis de requerimientos) con las soluciones software para resolver los
problemas software.
Jerarqua de Control tambin se le conoce como estructura del programa, y representa la
organizacin jerrquica de los mdulos de un programa e implica una jerarqua de control.
Estructura de Datos La estructura de datos es una representacin de la lgica que existe entre
los elementos individuales de informacin, la estructura de datos es tan importante como la
estructura del programa en la representacin de la arquitectura del software.
Procedimientos del Software El procedimiento debe proporcionar una especificacin precisa del
procesamiento, incluyendo la secuencia de sucesos, los puntos concretos de decisiones, la
repeticin de operaciones e incluso la organizacin/estructura de los datos.
Ocultamiento de Informacin Por tanto se trata de definir una serie de mdulos independientes
que se comuniquen slo a travs de la informacin necesaria para realizar la funcin de software.
El uso de ocultamiento de informacin en el diseo facilitar las modificaciones, prueba y
mantenimiento del software, ya que como la mayora de los datos y de los procedimientos estn
ocultos a otras partes del software, ser menos probable que los errores que se introduzcan
durante la modificacin se propaguen a otros mdulos del software.
3. Diseo Orientado a Objetos
El Diseo Orientado a los Objetos (DOO) crea una representacin del problema del mundo real y la hace
corresponder con el mbito de la solucin, que es el software, en otras palabras, es la disciplina que define
los objetos y sus interacciones para resolver un problema que fue identificado y documentado durante el
anlisis orientado a objetos.

A diferencia con otros mtodos de diseo, el DOO produce un diseo que interconecta objetos de datos y
operaciones de procesamiento para esos objetos, de forma que se modulariza la informacin y el
procesamiento, en lugar de aislar el procesamiento.
La mayora de metodologas de diseo de software intentan basarse en estos tres aspectos:
Abstraccin
Ocultamiento de informacin
Modularidad
Algunas de las actividades del AOO y el DOO son:
En el AOO deben llevarse a cabo las siguientes actividades:
La identificacin de clases semnticas, atributos y servicios
Identificacin de las relaciones entre clases (generalizaciones, agregaciones y asociaciones).
El emplazamiento de las clases, atributos y servicios.
La especificacin del comportamiento dinmico mediante paso de mensajes.
En el DOO deben llevarse a cabo las siguientes actividades:
Aadir las clases interfaz, base y utilidad.
Refinar las clases semnticas.
Debemos comprender la diferencia entre el Anlisis Orientado a Objetos, que es una actividad de
clasificacin, y el Diseo Orientado a Objetos, que define los objetos que se derivan de cada clase, se
tiene que indicar las relaciones que existen entre ellos mediante una notacin.
El DOO tiene que comenzar con una descripcin en lenguaje natural de la estrategia de solucin, y a
partir de esta descripcin, el diseador identifica los objetos y operaciones.
4. Conceptos del DOO
4.1. Abstraccin Expresa las caractersticas esenciales de un objeto, las cuales distinguen al objeto de los
dems. Adems de distinguir entre los objetos provee lmites conceptuales.
4.2. Encapsulacin es un mecanismo que consiste en organizar datos y mtodos de una estructura,
conciliando el modo en que el objeto se implementa, es decir, evitando el acceso a datos por cualquier
otro medio distinto a los especificados. Por lo tanto, la encapsulacin garantiza la integridad de los datos
que contiene un objeto, es decir, que es un mecanismo el cual permite ocultar los detalles de
implementacin de un objeto. Permite empaquetar en una unidad los datos y las funciones que operan
sobre dichos datos.
4.3. Objetos
Componente del mundo real que se hace corresponder con el software. En un Sistema de Informacin
basado en Computador, un objeto es un producto o consumidor de informacin, o un elemento de
informacin. Asimismo se refiere a un objeto como la instancia de una de clase.
Combinan tanto datos como procedimientos
Se relacionan con otros objetos heredando su estado y sus comportamientos, o actuando como
clientes de la funcionalidad que otros ofrecen
Tienen identidad propia
Son siempre ejemplares de una cierta clase
Tienen un identificador nico mediante el que otros objetos pueden referenciarlos
Tienen un estado

 Atributos: valor de los datos que contienen o referencias a otros objetos con los que comunicarse para
dar rdenes, enviar o recibir informacin
Mtodos: procedimientos que es capaz de ejecutar pudiendo, segn su estado, operar sobre sus
atributos o delegar parte del trabajo aprovechndose de los comportamientos de otros objetos
4.4. Aspectos de diseo
Por lo general se sugieren cinco criterios para la evaluacin de un mtodo de diseo a partir de la
modularidad.
Descomponibilidad: Facilidad con la que un mtodo de diseo ayuda al diseador a descomponer un
problema en sub problemas ms sencillos.
Componibilidad: Grado en el que un mtodo de diseo permite la reutilizacin de mdulos.
Compresibilidad: Facilidad para comprender un componente del programa sin tener que hacer referencia
a otros mdulos.
Continuidad: Capacidad de realizar cambios en un programa y que esos cambios afecten a un nmero
mnimo de mdulos.
Proteccin
El principio de ocultamiento de informacin se consigue cuando toda la informacin del mdulo est
oculta para el acceso desde el exterior, a menos que la informacin se defina explcitamente de forma
pblica.
Si bien estos principios son aplicables a cualquier tipo de diseo, el mtodo de Diseo Orientado a
Objetos consigue alcanzar estos principios de forma ms eficiente que el resto de los enfoques,
consiguiendo arquitecturas ms modulares.
4.5. Clases, instancias y herencia
Una clase es un conjunto de objetos que tienen las mismas caractersticas. As, un objeto es una instancia
de una clase mayor.
Describe sus atributos y sus mtodos
Es el punto de partida para crear nuevos objetos
Relaciones entre clases
Generalizacin y su inversa (especializacin)
Se realiza mediante la herencia entre clases
Composicin (parte de) y su inversa (todo)
Se realiza mediante la inclusin de referencias a los objetos que son partes en los atributos del objeto
que es todo
Asociacin (usa a) y su inversa (es usado por). Tambin se realiza mediante inclusin de referencias a
los objetos usados en los atributos del objeto que los usa
4.6. Descripciones de los objetos
La descripcin del diseo de un objeto (una instancia de una clase o de una subclase) est compuesta de
dos partes:
Descripcin de la interfaz: Establece la interfaz del objeto, definiendo los mensajes que puede recibir el
objeto y las operaciones que puede realizar cuando el objeto recibe el mensaje. En palabras simples se
dice que son un conjunto de mensajes con sus comentarios correspondientes

Descripcin de la implementacin: Los detalles de implementacin incluyen informacin sobre la parte

privada del objeto, es decir, los detalles de las estructuras de datos y los detalles procedimentales que
describen las operaciones.
Por tanto, el paradigma orientado a objetos persigue la encapsulacin, es decir, mostrar slo las
operaciones visibles, y ocultar los detalles de implementacin, creando una sensacin de cajas negras a
las que se envan mensajes, pero no se conocen los detalles de implementacin de la gestin de esos
mensajes.
5. Principios Fundamentales del DOO
Encapsulamiento Encapsulamiento al ocultamiento del estado, variable o atributo, es decir, del dato
miembro de un objeto de manera que slo se pueda modificar mediante las operaciones definidas para ese
objeto.
Herencia Relacin entre clases de objetos que permite incluir (rehusar) los atributos y operaciones
definidas en otra clase ms general de la cual se hereda o deriva.
Polimorfismo Se refiere a la propiedad por la que es posible enviar mensajes sintcticamente iguales a
objetos de tipos distintos. El nico requisito que deben cumplir los objetos que se utilizan de manera
polimrfica es saber responder al mensaje que se les enva.
La pirmide del DOO
La capa del subsistema. Contiene una representacin de cada
uno de los subsistemas que le permiten al software conseguir los
requisitos definidos por el cliente e implementar la
infraestructura tcnica que los soporta.
La capa de clases y Objetos. Contiene las jerarquas de clase
que permiten crear el sistema usando generalizaciones y
especializaciones mejor definidas. Esta capa tambin contiene
representaciones de diseo para cada objeto.
La capa de mensajes. Contiene los detalles que le permiten a
cada objeto comunicarse con sus colaboradores. Esta capa
establece las interfaces externas e internas para el sistema.
La capa de responsabilidades. Contiene las estructuras de
datos y el diseo algortmico para todos los atributos y
operaciones de cada objeto. Esta pirmide de diseo se centra entonces en el diseo de un producto o
sistema especfico.
6. Pasos del Diseo Orientado a Objetos
El proceso de diseo orientado a objetos por lo general consta de cuatro pasos:
a) Identificacin y definicin de objetos y clases
b) Organizacin de relaciones entre clases
c) Extraccin de estructuras en una jerarqua de clases
d) Construccin de bibliotecas de clases reutilizables
Como en todas las fases de Ingeniera del Software, el DOO es cclico, es decir, los diseadores
comienzan definiendo un conjunto de clases, que se amplan, modifican y vuelta a empezar.
7. Ventajas del Anlisis Orientado a Objetos y el DOO
1) Establece un lenguaje de enlace para expresar el modelado de datos entre analistas, usuarios,
programadores y en general, personas involucradas en un proyecto de desarrollo.

2) Permite llegar de manera guiada y prcticamente automtica, a un diseo y desarrollo correcto y

normalizado (siempre y cuando la definicin de objetos sea correcta de acuerdo a la realidad de negocio).
3) Proximidad de los conceptos de modelado respecto a objetos del mundo real.
4) Conduce de manera fcil y rpida a un incremento de la productividad.
5) Tambin usa tcnicas de razonamiento similar usadas para resolver problemas en otros dominios
8. Desventajas del DOO
No es recomendable para proyectos pequeos, debido a su alto costo.
Testing de sistemas software
1. Que es testing y porqu es necesario
Porqu del testing
Ahora bien, las pruebas de software buscan calidad, y la calidad es la aptitud para el uso, as como la
conformidad con los requisitos. Estas definiciones formales se diferencian debido a que la aptitud para
el uso implica que aquellos que lo usaran o usan debern determinar si posee la calidad deseada o no. Sin
embargo la conformidad con los requisitos, por el contrario solo necesita que trabaje de acuerdo a un
documento, entonces aqu en donde el documento de las especificaciones del sistema cumple un papel
importantsimo para determinar la implementacin correcta del software.
Qu es testing?
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 evaluacin es realizada de un aspecto
del sistema o componente.
De esta manera se puede concluir que es un proceso que intenta proporcionar confianza en el software y
cuyo objetivo fundamental es demostrar el desarrollo, depurar el software y comprobar al cliente que se
cumple con las especificaciones de los requerimientos que se plantearon y que buscan en el programa.
Objetivos de las pruebas de software (testing)
Entre estos objetivos los ms importantes son:
Detectar defectos en el software.
Verificar la integracin adecuada de los componentes.
Verificar que todas las especificaciones y requisitos del cliente se han implementado
correctamente y operan de acuerdo a ellos
Identificar y asegurar que los defectos encontrados se han corregido antes de entregar el software
al cliente.
Probar si el software hace lo que no debe, es decir, si provoca efectos secundarios adversos.
Encontrar el mayor nmero de errores con la menor cantidad de tiempo y esfuerzo posibles.
Disear casos de prueba que sistemticamente saquen a la luz diferentes clases de errores,
hacindolo con la menor cantidad de tiempo y esfuerzo
Probar si el software no hace lo que debe.
Principios generales de las pruebas de software
De igual forma mencionaremos los principios generales de las pruebas de software

Las pruebas muestran presencia de defectos mostrar los defectos que estn presentes en el
producto de software, pero no puede probar que no existan defectos en dicho producto.
Pruebas exhaustivas es imposible probar de todo, incluyendo todas las combinaciones de
insumos y condiciones no es posible.
Pruebas tempranas: las prueba deben comenzar tan pronto como sea posible y debe centrarse
en objetivos definidos.
Agrupacin de defectos: Un pequeo nmero de mdulos contiene la mayora de los defectos
descubiertos durante las pruebas de pre-lanzamiento o muestra los fracasos operacionales
La paradoja de Pesticidas: Si el mismo tipo de pruebas se repiten una y otra vez, con el tiempo
el mismo conjunto de casos de prueba ya no ser capaz de encontrar nuevos errores.
La prueba de acuerdo a contexto La prueba es bsicamente dependiente del contexto. Por
ejemplo, la seguridad - crticos software ha sido probado de forma diferente a partir de un sitio
de comercio electrnico.
Falacia de ausencia de errores: Si el sistema construido es inutilizable y no cumple con las
necesidades y expectativas del usuario, encontrar y corregir defectos no ayuda.

2. Verificacin y validacin de software (V&V)

Verificacin: Implica comprobar que el software este de acuerdo con su especificacin, se debe
comprobar que se cumplen con los requisitos funcionales y no funcionales, la verificacin ayuda en la
reduccin de defectos en las etapas posteriores del desarrollo.
Reduce las posibilidades de fallas en la aplicacin de software o producto.
Le ayuda en la construccin del producto de acuerdo con las especificaciones y necesidades del cliente.
Validacin:
Es un proceso ms general, su objetivo es el aseguramiento de que el sistema satisface su especificacin
para demostrar que el software realice lo que el cliente espera de este.
La validacin se realiza durante la pruebas como prueba caracterstica, pruebas de integracin, pruebas
del sistema, pruebas de carga, pruebas de compatibilidad, pruebas de esfuerzo, etc.
Por lo tanto, la validacin ayuda a desplegar la funcionalidad exacta de las caractersticas y ayuda a los
probadores para entender el producto en forma mucho mejor. Le ayuda en la elaboracin del producto
ms fcil de usar.
3. Tipos de pruebas de software
No hay una clasificacin formal u oficial de acuerdo a los tipos de prueba de software, pero hay una gran
inclinacin a:
Pruebas de tipo Caja Negra (Balck Box Testing)
Son pruebas funcionales, se parte de los requisitos funcionales a muy alto nivel, para disear pruebas que
se puedan aplicar sin tener conocimiento de la estructura o funcionamiento interno del sistema, de aqu es
que viene derivado el nombre de caja negra por desconocer el interior.
El objetivo en este tipo de pruebas es seleccionar entradas que tienen una alta probabilidad de generar
fallos de ejecucin del sistema por ejemplo elegir entradas que fuerzan a que el sistema genere todos los
mensajes de error o forzar a que se generen salidas invlidas, tambin forzar resultados de clculos que
sean demasiado grandes o demasiado pequeos.
Pruebas de tipo Caja Blanca (White Box Testing)

Se centran en lo que hay codificado o diseado a bajo nivel por lo que no es necesario conocer la
especificacin de requisitos.
Los mtodos de caja blanca permiten derivar casos de prueba que
Garanticen que todas las rutas independientes dentro del mdulo se ejecuten al menos de una vez.
Ejecuten los lados verdadero y falso de todas las decisiones lgicas.
Ejecuten las estructuras de datos internas para asegurar su validez
Eliminan errores tipogrficos.
En resumen las pruebas de caja banca se centran en la estructura de control del programa. Se obtienen
casos de prueba que aseguren que durante la prueba se han ejecutado al menos una vez todas las
sentencias del programa.
4. Pruebas de Integracin e Integracin Continua*
4.4 Pruebas de integracin
Prueba que se realiza a los distintos componentes, todos de manera integrada, el mtodo es de forma
progresiva y est centrada en el diseo y la construccin de la arquitectura de software. Cuando se
desarrolla el esqueleto del sistema y luego los componente se le llama integracin descendente, Por el
contrario si se integran primero los componentes de la infraestructura que proporcionan servicios y luego
los componentes funcionales se les llama integracin ascendente.
Para este tipo de pruebas el equipo que realizara el testeo debe tener acceso al cdigo fuente del sistema.
4.5 Pruebas de entregas
Este tipo de pruebas est dirigido a las versiones del software que podran ser entregadas al usuario, En
este caso se busca validar que el sistema satisface los requerimientos respectivos adems de asegurar por
medio de estas que el sistema es confiable.
Esta prueba est basada en pruebas de caja negra donde el equipo simplemente busca demostrar si el
sistema funciona o no correctamente.
4.6 Pruebas de rendimiento
Cuando el sistema est integrado en su totalidad, es posible realizar las propiedades emergentes de
sistema, como el caso del rendimiento. Las pruebas de rendimiento buscan probar si el sistema es capaz
de procesar la carga esperada. Como sucede en el resto de las pruebas, las de rendimiento buscan
demostrar tanto que el sistema satisface los requerimientos como descubrir problemas y defectos.
Con esta metodologa en las pruebas se espera cumplir con:
Probar cmo se comporta el programa una vez que falla
Sobrecargar el sistema puede provocar que se muestren defectos.
4.7 Pruebas de compones (pruebas de unidad)
Las pruebas de componentes lo que pretende es probar individualmente los componentes del sistema. El
proceso de estas pruebas es para encontrar defectos en los componentes.
Entre los componentes que pueden probarse en esta etapa son:
Funciones individuales o mtodos dentro de un objeto.
Objetos que poseen varios atributos y mtodos.
Componentes compuestos que estn formados por varios objetos o funciones.
Por otra parte las pruebas a objetos deben ser diseadas para incluir todas las caractersticas del mismo.
Entre los puntos que deben incluir son:
Pruebas aisladas para cada una de operaciones que posee el objeto.

 Consultas as como asignacin a todos los atributos del objeto.

Simular todos los eventos que provocan los cambios de estado de un objeto.
5. Diseo de casos de pruebas el objetivo de los diseos de casos de pruebas es que se crean un conjunto
de casos de prueba que sean efectivos descubriendo defectos en los programas y muestren que el sistema
satisface los requerimientos.
Para disear un caso de prueba se selecciona una caracterstica del sistema o componente que se desee
probar, luego se selecciona un conjunto de entradas y se documentan las salidas esperadas o los rangos de
salida y donde sea posible, se disea una prueba automatizada que indique que las salidas reales y las
esperadas sean las mismas. Se pueden dar distintas aproximaciones para elaborar el diseo de casos de
prueba, entre ellos tenemos las pruebas basadas en requerimientos, pruebas de particiones, y pruebas
estructurales.
5,1 Pruebas basadas en Requerimientos
las pruebas basadas en requerimientos son una aproximacin sistemtica al diseo de casos de prueba en
donde el usuario considera cada requerimiento y deriva un conjunto de pruebas para cada uno.
Este es un tipo de prueba de validacin, esto quiere decir que el usuario no intentar demostrar que el
sistema falle, sino demostrar que el sistema cumpla de manera eficaz la implementacin de los
requerimientos de una manera apropiada.
Tomaremos como ejemplo el siguiente requerimiento de un sistema apoyndonos en las pruebas basadas
en requerimientos para mostrar algunas de las posibles pruebas:
El usuario ser capaz de buscar en un conjunto inicial de base de datos o bien seleccionar un conjunto
de estas.
Las posibles pruebas para el requerimiento anterior, suponiendo que se ha probado una funcin de
bsqueda son:
Iniciar bsquedas de un usuario para elemento de los que se conoce estn presentes y para elementos
que se sabe no estn presentes, en las que el conjunto de base de datos incluye una base de datos.
5.2 Pruebas basadas en particiones
Un programa normalmente se pude agrupar en varias clases diferentes, esto porque los datos de entrada y
los resultados de salida del programa cuentan con caractersticas comunes, tal como selecciones de men,
nmeros negativos, u otros. Debido a este comportamiento equivalente, estas clases se les llama
particiones de equivalencia o dominios (Bezier, 1990). En la utilizacin de casos de pruebas se basa en
identifica todas las particiones para un sistema o componente. Estos casos se disean para que las
entradas o salidas pertenezcan a estas particiones. Una vez identificado los conjuntos de particiones, se
eligen casos de prueba para cada una de ellas, una prctica exitosa para elegir estos casos de prueba son
los de elegir pruebas en los lmites y la zona media de las porciones.
Algunas recomendaciones para disear casos de prueba basadas en particiones, si se considera que se
prueba con secuencias, vectores o listas son las siguientes:
Probar con secuencias que tienen un solo valor.
Utilizar varias secuencias de diferentes tamaos para distintas pruebas.
Generar pruebas para acceder al primer elemento, al elemento central y al ltimo.
5.2 Pruebas basadas en estructurales

Las pruebas estructurales son una proximidad a casos de prueba, estas proceden a partir del conocimiento
de la estructura e implementacin del sistema.Estas ayudan a identificar particiones adicionales y casos de
prueba.
Al examinar el cdigo de este ejemplo sobre bsqueda binaria, se puede ver que la rutina de bsqueda
binaria divide el espacio de bsqueda en tres partes, siendo cada una de esas partes una particin de
equivalencia. As mismo se disean los casos de prueba, los cuales se situaran en los lmites de cada una
de estas porciones. Todo este anlisis da nacimiento a un conjunto de casos de prueba
5.2 Pruebas basadas en caminos
Este tipo de pruebas es una estratega de las pruebas estructurales, tiene como fin probar cada camino de
ejecucin independiente en un componente o programa. Esto con el fin de ejecutar todas las sentencias de
cada componente al menos en una oportunidad. En las sentencias condicionales se comprueban los casos
verdadero y falso. Cabe mencionar que en un diseo orientado a objetos se pueden utilizar pruebas de
caminos cuando se prueban los mtodos asociados a objetos.
Cabe mencionar que los caminos que existen en un programa son proporcional al tamao del mismo. Una
vez calculada se descubrir el nmero de caminos independientes, disean los casos de prueba para
ejecutar cado uno de estos caminos independientes ya calculados.
Cuando es difcil descubrir el perfil de ejecucin de programas complejos, se puede hacer uso de
herramientas, tal como el caso de algn analizador dinmico de programas, los cuales muchas veces
trabajan conjuntamente con los compiladores.
6. Automatizacin
Las pruebas es un proceso laborioso y puede resultar caro, como consecuencia a la necesidad de brindar
productos robustos y efectivos as como fieles a los requerimientos que el cliente necesita. Se ofrecen
herramientas con una serie de facilidades y que sin duda reducen el costo de las mismas.
Algunos de los elementos bsicos que un banco de prueba debe poseer son los siguientes:
Gestores de pruebas: Gestiona la ejecucin de las pruebas del programa, el gestor de pruebas mantiene
un registro de los datos, resultados, habilidades del programa que han sido probados. Un ejemplo de ellos
es JUnit como gestor de pruebas.
Generador de datos de prueba: Concibe datos de prueba para el programa a probar.
Orculo: Generador de predicciones de resultados esperados de las pruebas, estos pueden ser versiones
previas del programa o sistemas prototipos.
Comparador de ficheros: Compara resultados del mismo programa con resultados previos del mismo
creando informes sobre estos datos. Son muy utilizados en pruebas de regresin, cuando son
automatizadas estos comparadores son invocados desde las mismas pruebas.
Generador de informes: Son facilitadores de generadores de informes para los resultados de las
pruebas e preparar los resultados manualmente.

Importancia de las pruebas de software Las pruebas de software han venido

incrementando su importancia en los ltimos aos en el desarrollo del software.
Como ventajas principales de las pruebas de software tenemos:
Mejora de calidad de software
La presencia de errores en los productos de software pueden causar daos crticos y prdidas irreparables,
por lo tanto la calidad del software es de suma importancia ya que se asegura que el software cumpla con
los estndares de calidad establecidos.
Verificacin y validacin del software
La verificacin y validacin de un producto de software permite que se determine que el sistema cumple
con los objetivos predefinidos y sus salidas son las correctas.
Fiabilidad del producto
Desde el punto de vista del usuario la fiabilidad es que tan confiable es el producto, ya que en muchos
casos estos ayudan en la toma de decisiones vitales en las organizaciones, por lo tanto se deben
comprobar a fondo su la funcionalidad del software es el correcto.
Prevenir defectos de migracin
La mayora de los errores suelen introducirse en los requisitos de software fase de recopilacin. Si se
detectan los errores temprano, se puede evitar que la migracin a la fase de desarrollo posterior. La
deteccin temprana y la depuracin de errores conducen a un gran ahorro en los costes de desarrollo de
software.
Ahorro de costes
Se da un ahorro de costes a la hora de evitar o reducir los errores en un sistema en su proceso de
desarrollo, debido a que luego ser ms costoso corregir dichos errores una vez puesto en funcionamiento.
En resumen las pruebas de software son una etapa muy importante en el desarrollo de software ya que
estos ayudan a que el producto de software sea de calidad y confianza, y que ayuden a reducir costos por
errores inesperados.