Fases del desarrollo de una aplicacin.

Pruebas: Es una fase del ciclo de vida clsico de un producto software para garantizar
la calidad del producto final.

Tipos de pruebas:
Pruebas de mdulo o unitarias: Es una forma de probar el correcto funcionamiento de
un mdulo de cdigo. Para comprobar que cada mdulo funciona correctamente por
separado.

Caja blanca: Verifican que las lneas especficas de cdigo funcionan tal
y como estn definidas, se utilizan las decisiones en su parte verdadera y
en su parte falsa, se ejecutan todos los bucles en sus lmites y se utilizan
todas las estructuras de datos internas.
Caja negra: Se centran en los requisitos funcionales, sobre la interfaz del
software, enfocadas a las entradas y salidas y no en el cdigo fuente.

Pruebas de integracin: Es una forma de probar el funcionamiento de los mdulos en

conjunto.
Pruebas de aceptacin: Esta fase la debe realizar el cliente o usuario que va a hacer uso
de dicha aplicacin, en el sistema donde dicha aplicacin ser usada. La funcionalidad
principal de esta prueba es que el cliente pruebe la aplicacin en condiciones reales y
reporte cualquier irregularidad que perciba (fase alpha y beta de las aplicaciones).

Uno de los sntomas que dieron lugar a la crisis del software fue la falta de fiabilidad,
los programas fallaban muy a menudo.
A partir de esta crisis es cuando surge la ingeniera del software como un medio para
solventar muchos de los problemas detectados y obtener as un software de calidad.
Debe tener anotaciones que expliquen/aclaren lo que realiza el cdigo // /**/
Testear, validar y verificar que esa aplicacin cumple los requisitos.
Diferencias:

Verificacion:

Validacin: 2008

V&V 8

Definicin de V&V

Sommerville
Verificacin
o
Busca comprobar que el sistema cumple con los
reque
rimientos
especificados (funcionales y no funcionales)
o
El software est de acuerdo con su especificacin?

Validacin
o
Busca comprobar que el software hace lo que el
usua
rio espera.
o
El software cumple las expectativas del cliente?

ISO 9000:2005 Fundamentos y Vocabulario: 3.8.4 Verificacin: Confirmacion, atraves

de la provisin de evidencia objetiva de que los requisitos especificados se han
cumplido. Puede ser: la verifcacin vs. especificaciones, realizacion de pruebas y
demostraciones,
revisar
documentos
antes
de
publicarlos.
Esta actividad se puede realizar en etapas de libercion de equipo, procesos y
productos, previas a produccion en masa, durante la calibracion.
ISO 9000:2005 Fundamentos y Vocabulario: 3.8.5 Validacion: Confirmacion, atraves de
la provisin de evidencia objetiva de que los requisitos para intenciones o aplicaciones
de uso especifico se han cumplido. Las condiciones para la validacin pueden ser
reales
o
simuladas.
Esta actividad se puede realizar durante etapas de produccion, por ejemplo;
inspeccionar o validar X caracteristica con un gage para simular la funcionalidad en el
campo, de que el producto es funcional, validar que el producto cumple con las diseo
intenciones de diseo y los requisitos del cliente; ajuste, instalacion, dimensional,
electrico,
tiempo
de
vida.
Espero haber contribuido.

Prueba:
-Conjunto de tcnicas que permiten determinar la calidad de un producto software
-proceso de ejecucin de un programa con la intecin de descubrir errores
-Es cualquier actividad dirigida a evaluar la capacidad de un programa y determinar que
alcanza los resultados requeridos por el cliente.
Las pruebas deben realizarse en diferentes momentos del desarrollo del software y NO
solo al final del mismo.
Se entiende por cobertura de las pruebas el porcentaje del cdigo de la aplicacin que se
cubre con un determinado grupo de pruebas.
Algunas de las cosas que se comprueban con la realizacin de pruebas son:

Los componentes funcionan correctamente de forma individual.

El componente se ensambla bien con los dems componentes.
Las interfaces del sistema con otros sistemas son correctas.
El sistema cumple las expectativas del usuario.
Los cambios sobre un componente no tienen efectos colaterales adversos sobre
otros componentes.

Principios de las pruebas:

Algunos de los principios que deben tenerse en cuenta cuando se realiza el proceso
de pruebas son:
1.
2.
3.
4.
5.
6.

Una prueba tiene xito si descubre un error no detectado hasta el momento.

Las pruebas deberan planificarse mucho antes de que empiecen.
No es posible realizar pruebas completas.
Las pruebas deberan empezar por lo pequeo y progresar hacia lo grande.
No son posibles las pruebas exhaustivas.
Se deben probar tanto condiciones de entrada validas como invalidas o
inesperadas.
7. Se deben conservar y mantener los casos de prueba
8. A todas las pruebas se les debera poder hacer un seguimientos hasta los
requisitos del cliente.
9. Las pruebas del software se realizan tanto para ver que el sistema hace lo que
tiene que hacer como para ver si hace algo que se supone algo que no debe
hacer
10. Para ser mas eficaces las pruebas deberan ser realizadas por un equipo
independiente ya que un programador no debe probar sus propios programas
Tipos de pruebas de software:
1. Estaticas: se realizan sin ordenador analizan el objeto de la prueba sin necesidad
de ejecutarlo genricamente se denominan revisiones. (fases de anlisis y de
diseo)
a. Sobre cdigo
i. Inspecciones: consiste en que un equipo realiza una lista de
situaciones tpicas de error en un tipo de proyecto y se renen
para leer el cdigo y descubrir las situaciones de error
ii. Walkthrough: consiste en sentar alrededor de una mesa a los
desarrolladores y a una serie de crticos bajo las ordenes de n
moderador. El mtodo consiste en que los revisores lleen el
programa lnea a line y piden explicaciones de todo aquello que
nno esta claro para ellos, puede ser que simplemente falte un
comentario explicativo o que detecten un error considerable o que
detecten que el cdigo es complejo y difcil de entender
independientemente de que el cdigo funcione
b. Sobre documentos
i. Revisin de requisitos: consiste en realizar un contraste de los
requisitos funcionales con los usuarios , se intenta probar si existe
algn requisito no identificado, si estn identificadas todas las
funcionalidades, si puede ser especificado o eliminado algn
requisito

ii. Revisin diseo: consiste en comprobar como encaja el diseo

con otros componentes adicionales
2. Dinamicas: con ordenador. Son aquellas que requieren la ejecucin de casos de
pruebas sobre un ordenador.
a. Segn el mbito de la aplicacin: segn que parte de la aplicacin vaya a
probar
i. Unitarias: prueban de forma individual todos los componentes del
sistema que se desarrolla.
ii. De integracin: se prueba la integracin entre los componentes
del sistema para demostrar que encajan correctamente.
iii. Del sistema: comprueban la integracin de todos los modulos
mas el entorno funcional que compone el proyecto.
iv. De aceptacin: comprobamos que el cliente acepta la aplicacin
porque cumple sus requisitos iniciales.
v. De regresin: son aquellas pruebas que miden la elasticidad de la
aplicacin o del software ante posibles versiones futuras de la
misma.
b. segn la estrategia a seguir
i. pruebas de caja blanca: pruebas estructurales, permiten examinar
la estructura interna de los programas, con independencia de la
funcionalidad establecida para el mismo
ii. pruebas de caja negra: comprueban el correcto funcionamiento de
los componentes del sistema, analizando las entradas y salidas y
verificando que el resultado es el esperado

Proceso de pruebas
Los pasos o actividades que debe incormporar cualquier estrategia de pruebas son:
1) Planificacion de la prueba a realizar: se deben obtener los objetivos del proceso de
prueba, la relacin de los objetivos a probar, el alcance de la prueba, los mtodos y
recursos a utilizar, planificacin temporal de las mismas y el reparto de
responsabilidades.
2) Diseo de los casos de pruebas: en los que se debe indicar cuales son los objetivos
de ese caso de prueba, cuales son las entradas propuestas y cuales son las salidas
esperadas.
3) Ejecucin de la prueba
4) Agrupacin y evaluacin de los datos resultantes.

El proceso de pruebas debe estar reflejado en un documento denominado plan de

pruebas sobre el que se apoya todo el proceso.
Podemos definir el plan de pruebas como el documento que contiene las pruebas,
revisiones y ensayos a los que va a ser sometido el programa y diremos que un buen
plan de pruebas ser aquel que permita descubrir el mayor numero de errores en el
menor tiempo posible y con el menor coste.
Un plan de pruebas debe incluir:
Identificador del plan y preferiblemente este identificador debe generarse de alguna
forma nemotecnica que permita relacionarlo con su alcance.
Adems debe distinguir la versin y la fecha del plan.
En el alcance se indica el tipo de prueba y las propiedades o elementos del software que
se van a probar
Items a probar: indica la configuracin a probar y las condiciones minimas que debe
cumplir para comenzar el plan. Es difcil probar una configuracin que contenga aun
errores.
Si se espera a que todos los modulos funcionen perfectamente puede que detectemos
fallas graves demasiado tarde.
Estrategia: describe la tcnica o patrn a utilizarse en los diseos de los casos de prueba
Categorizacion de la configuracin: ser necesario especificar aqu las condiciones bajo
las cuales el plan debe ser suspendido, repetido, culminado, etc.
Tangibles: se exponen los documentos a entregar al culminar el proceso previsto por el
plan.
Procedimientos especiales: Identifican el grafo de las tareas necesarias para preparar y
ejecutar las pruebas, asi como cualquier habilidad especial que se requiera.
Recursos: se expecifican las propiedades necesarias del ambiente de prueba, incluyendo
caractersticas del hardware y del software, cualquier otro software que fuera necesario,
adems de una estimacin de los recursos humanos necesarios para llevar a cabo el
proceso
Calendario: aqu se expecifican cuales son los hitos y el grafo de dependencia en el
tiempo de las tareas a realizar
Responsables: se expecifica quien el responsable de cada una de las tareas especificadas
en el plan
Responsables: se expecifica quien el responsable de cada una de las tareas especificadas
en el plan

Pruebas unitarias son aquellas que centran el proceso de verificacin en la menor unidad
del diseo de software, es decir el componente o el modulo, es una forma de probar el
correcto funcionamiento de un modulo de cdigo, para asegurar que cada uno de los
modulos de forma independiente, funciona correctamente.
A continuacin, mediante las pruebas de integracin, podremos asegurar el correcto
funcionamiento del sistema o subsistema en cuestin.
La idea de las pruebas unitarios es escribir casos de prueba para cada uno de los
mtodos del modulo a probar de forma que cada caso de prueba sea independiente del
resto.

Pruebas de integracin: son aquellas que se realizan en el mbito del desarrollo de

software, una vez que han sido aprobadas las pruebas unitarias. Para ello se prueba la
aplicacin en un entorno similar al de produccin para verificar que funciona sobre el
hardware y/o el software que nos encontraremos en el entorno de produccin y para
verificar que no aparecen problemas al trabajar con los datos que hay en el entorno de
produccin.
Se prueba la respuesta de grupos de modulos interconectados con el fin de detectar
fallos resultantes en la interaccion de los componentes. La principal dificultad de este
tipos de pruebas es localizar errores que se descubren durante este proceso y es por ello
que se recomienda utilizar una integracin incremental en vez de una integracin no
incremental (todo a la vez).

Pruebas del sistema: con el fin de comprobar que se cumplen los requisitos
especificados. Consisten en comprobar la integracion de todos los modulos mas el
entorno funcional que compone el proyecto, es decir, el software ya validado se integra
con el resto del sistema.
Incluyen el siguiente conjunto de pruebas:
1. Rendimiento: determinar que los tiempos de respuesta estn dentro de los
intervalos establecidos en las especificaciones del sistema. Tambien determina el
espacio que ocupa el modulo en disco o en memoria
2. Seguridad: verificar que los mecanismos de proteccin incorporados en el
sistema lo protegern de accesos impropios para evitar alteraciones indebidas en
los datos.

3. Resistencia o de estrs: determinan hasta donde puede soportar el programa

determinadas condiciones extremas, como por ejemplo un numero excesivo de
usuarios utilizando de forma simultanea la aplicacin (dentro del mbito, un
poco por encima)
4. Usabilidad: se refiere a la facilidad o nivel de uso, al grado en el que el diseo de
un programa facilita o difuculta su manejo. Con este tipo de prueba
aseguraremos que la interfaz de usuario es amigable, intuitiva y que funciona
correctamente.
5. Instalacion: funciona correctamente la instalacin y la desinstalacin en su
entorno definitivo

Pruebas de aceptacin: tienen como objetivo comprobar que el sistema completo

cumple con el funcionamiento esperado, es decir, con los requisitos planteados en la
especificacin que cubre las necesidades de los clientes desde el punto de vista de su
funcionalidad y su rendimiento.
Sern llevadas a cabo por el usuario o cliente, por tanto. se realizan sobre el
producto terminado
1. Alpha: aquellas que se llevan a cabo con el cliente en el lugar de desarrollo.
Consiste en que el cliente usa el software con el desarrollador observndolo
y anotando los posibles errores o problemas de uso.
2. Beta: se llevan a cabo por usuarios finales en los lugares de trabajo de los
clientes y el desarrollador no esta presente

Pruebas de regresin: estn asociadas a la parte de mantenimiento y su objetivo es que

los cambios efectuados sobre un componente del sistema no introduce un
comportamiento no deseado o errores adicionales en componentes no modificados.
Se ejecutan cada vez que se produce un cambio en el sistema y normalmente implican la
repeticin de las pruebas que ya han sido realizadas previamente

1. Prueba de caja blanca:

a. Cobertura de caminos o camino bsico: consiste en garantizar que
durante la prueba se ejecuta por lo menos una vez cada sentencia del
programa. Es necesario seguir una serie de pasos:
i. Utilizar el cdigo de la aplicacin para elaborar el grafo de flujo
del mismo.

ii. Determinar o calcular la complejidad ciclomatica del grafo de

flujo. (determina el numero de caminos independientes
necesarios y suficientes para determinar una prueba de caja
blanca como valida) .
iii. Determinar un conjunto bsico de caminos linealmente
independientes.
iv. Preparar los casos de prueba que forzaran la ejecucin de cada
camino bsico encontrado en el paso anterior.
( grafo de flujo ) Cada nodo representara una o mas sentencias
secuenciales y cada lista representara el flujo de control o el
camino/direccin a seguir.
A la hora de generar el grafo de flujo de una aplicacin debemos
tener en cuenta lo siguiente:
1. Todo grafo de flujo tiene un nico nodo inicial y un nico
nodo final.
2. Cada nodo representa una secuencia de instrucciones
3. Un nodo puede tener uno o dos sucesores
4. Un nodo puede tener uno o muchos antecesores
Ej cdigo:
Int n;
System.out.println(Introduzca numero);
N=interger.parseint(bf.readline());
If(n%2==0)
Syso(n+es par);
Else syso(n+ es impar);
Para calcular la complejidad ciclomatica(V(G)) existen 3 formulas:
1. V(G) = Numero de aristas numero de nodos + 2
2. V(G) = numero de bifurcaciones + 1
3. V(G) = numero de zonas o regiones independientes
EJ: V(G)=2
Para identificar los caminos independientes:
Conociendo la complejidad ciclomatica conocemos el numero de caminos (o
posibles rutas de ejecucin). En este paso hay que identificar los caminos.
EJ: camino1= 1,2,3,5

Camino2= 1,2,4,5

Camino
1-2-3-5
1-2-4-5
Ejercicio practico

Entrada
N=8
N=9

Salida
8 es par
9 es impar