Durante el proceso de desarrollo del software es necesario realizar un

conjunto de pruebas que permiten verificar que el software que se está

creando es correcto y cumple con las especificaciones impuestas.

Las pruebas de software consisten en verificar y validar un producto software

antes de su puesta en marcha.

La ejecución de pruebas de un sistema involucra una serie de etapas:

- Planificación de pruebas.
- Diseño y construcción de los casos de prueba.
- Definición de los procedimientos de prueba.
- Ejecución de las pruebas.
- Registro de resultados obtenidos.
- Registro de errores encontrados.
- Depuración de los errores.
- Informe de los resultados obtenidos.

Para llevar a cabo el diseño de casos de prueba se utilizan dos técnicas o

enfoques:
- Prueba caja blanca(enfoque estructural): se centra en validar la
estructura interna del programa osea el Estudio de la estructura
INTERNA .
- se necesitan conocer los detalles procedimentales del código.
- Prueba ideal: Probar TODOS los posibles caminos de ejecución,
a través de las instrucciones del código.
- Estas pruebas solo las puede realizar el programador

- Prueba caja negra(enfoque funcional): se centra en validar los

requisitos funcionales sin fijarse en el funcionamiento interno del
programa osea el Estudio de la especificación de las funciones, la
entrada y la salida para derivar los casos.
- Se necesita saber la funcionalidad que el código ha de
proporcionar.
- Prueba ideal: probar todas las posibles entradas y salidas del
programa.
- Estas pruebas las puede realizar también el cliente como
prueba de aceptación.

Prueba de caja blanca

También llamadas pruebas estructurales o de caja de cristal.
Se basan en el minucioso examen de los detalles procedimentales del código
de la aplicación
- Garanticen que se ejecutan al menos una vez todos los caminos
independientes de cada módulo.
- Ejecuten todas las sentencias al menos una vez.
- Ejecuten todas las decisiones lógicas en su parte verdadera y en su
parte falsa.
- Ejecuten todos los bucles en sus límites.
- Utilicen todas las estructuras de datos internas para asegurar su
validez.
- Una de las técnicas utilizadas para desarrollar los casos de prueba de
caja blanca es la prueba del camino básico.

Prueba de caja negra

También llamadas pruebas de comportamiento, se llevan a cabo sobre la
interfaz del software, no es necesario conocer la estructura interna del
programa.
- Se pretende obtener casos de prueba que demuestren que las
funciones del software son operativas:
- Las salidas que devuelve la aplicación son las esperadas en
función de las entradas.

Con este tipo de pruebas se intenta encontrar errores de las siguientes

categorías: Funcionalidades incorrectas o ausentes Errores de interfaz
Errores en estructuras de datos o en accesos a bases de datos externas
Errores de rendimiento Errores de inicialización y finalización Existen
diferentes técnicas para confeccionar los casos de prueba de caja negra,
algunos son: Clases de equivalencia, Análisis de los valores límite, Métodos
basados en grafos, Pruebas de comparación, etc.

La estrategia de prueba del software se puede ver en el contexto de una

espiral.

En el vértice de la espiral comienza la prueba de unidad

- Se centra en la unidad más pequeña del software, el módulo tal como
está implementado en código fuente.
La prueba avanza para llegar a la prueba de integración
- Se toman los módulos probados mediante la prueba de unidad y se
construye una estructura de programa que esté de acuerdo con lo que
dicta el diseño.
La espiral avanza llegando a la prueba de validación
- Se validan los requisitos establecidos en el análisis comparándolos con
el sistema que ha sido construido.
Finalmente se llega a la prueba del sistema
- Verifica que cada elemento encaja de forma adecuada y se alcanza la
funcionalidad y rendimiento total.

Prueba de Unidad
En este nivel se prueba cada unidad o módulo con el objetivo de eliminar
errores en la interfaz y en la lógica interna.
Esta actividad utiliza técnicas de caja negra y caja blanca.
Se realizan pruebas sobre:
- La interfaz del módulo.
- Las estructuras de datos locales, para asegurar que mantienen su
integridad durante todos los pasos de ejecución del programa
- Las condiciones límite.
- Todos los caminos independientes de la estructura de control.

Para las pruebas de unidad se van a mostrar diferentes técnicas que

dependen del tipo de enfoque utilizado:
De caja blanca
- Prueba del camino básico.
- Se generan casos de prueba que garanticen que cada sentencia
del programa se ejecute al menos 1 vez.
- Se dibuja el grafo de flujo asociado.
- El grafo de flujo representa el flujo de control de nuestro
programa
- Se basa en los elementos:
- Nodo: Se dibuja como un círculo. Sirve para
representar un conjunto de sentencias sin
bifurcación.
- Aristas: Se dibuja como una flecha. Representan el
flujo de control de nuestro programa.
- Regiones: Áreas delimitadas por aristas y nodos.

- Se obtiene una medida de la complejidad lógica de un programa.

- La complejidad ciclomática V(G) nos da una medida de
cuántos caminos independientes hemos de tener.
- Pueden calcularse de 3 formas distintas:
- Número de regiones del grafo de flujo.
 - V(G)= A-N+2, donde A es el número de aristas y N
es el número de nodos.
- V(G)= P+1, donde P es el número de nodos
predicado (que son los nodos que representan
condiciones)
- Definimos un conjunto básico de caminos de ejecución.
- Por cada camino de ejecución generamos un caso de prueba.
- Diseñar pruebas que fuercen la ejecución de los caminos
independientes que conforman el conjunto básico.
- Cada sentencia del programa se ejecuta al menos
una vez.
- Cada condición del programa se prueba al menos
dos veces (verdadero y falso).
- Cada camino independiente se ejecuta al menos una
vez.

De caja negra
- Partición o clases de equivalencia.
- Los errores suelen ocurrir en los límites de las clases
equivalentes.
- Podemos reforzar los casos de prueba probando los valores
límite.
- Si una condición de entrada especifica un rango de valores.
- Se debe diseñar casos de prueba para los límites del rango
y para los valores justo por encima y por debajo del rango.
- Si una condición de entrada especifica un número de valores.
 - se deben diseñar casos de prueba que ejerciten los valores
máximo, mínimo, un valor justo por encima del máximo y
un valor justo por debajo del mínimo.
- Análisis de los valores límite.

Prueba de Integración
En este tipo de prueba se observa cómo interaccionan los distintos módulos,
se ha probado que todos los módulos funcionan por separado, se valida la
integración, se trata de comprobar si funcionan juntos.

Existen dos enfoques:

- Integración no incremental o big bang
- Se prueba cada módulo por separado y luego se combinan todos
de una vez y se prueba todo el programa completo.
- En este enfoque se encuentran gran cantidad de errores y la
corrección se hace difícil.
- Integración incremental
- El programa completo se va construyendo y probando en
pequeños segmentos, los errores son más fáciles de localizar
- Se dan dos estrategias:
- Ascendente: la construcción y prueba del programa
empieza desde los módulos de los niveles más bajos de la
estructura del programa.
- Descendente: la integración comienza en el módulo
principal moviéndose hacia abajo por la jerarquía de
control.
Prueba de Validación
La validación se consigue cuando el software funciona de acuerdo con las
expectativas razonables del cliente definidas en el documento de
especificación de requisitos del software.

Se llevan a cabo una serie de pruebas de caja negra para comprobar se

cumplen requisitos:
- Prueba Alfa
- Se lleva a cabo por el cliente o usuario en el lugar de desarrollo.
- El cliente utiliza el software de forma natural bajo la observación
del desarrollador que irá registrando errores y problemas de uso.
- Prueba Beta
- Se lleva a cabo por los usuarios finales del software en su lugar
de trabajo. El desarrollador no está presente.
- El usuario registra todos los problemas que encuentra e informa
al desarrollador.
- Como resultado de los problemas el desarrollador lleva a cabo
las modificaciones y prepara una nueva versión del producto.

Prueba de Sistema
La prueba del sistema está formada por un conjunto de pruebas cuya misión
es ejercitar profundamente el software.
- Pruebas de recuperación
- En este tipo de prueba se fuerza el fallo del software y verifica
que la recuperación se lleva a cabo apropiadamente.
- Pruebas de seguridad
- En esta prueba se intenta verificar que el sistema está protegido
contra accesos ilegales.
- Pruebas de resistencia (Stress)
- Trata de enfrentar el sistema con situaciones que demandan gran
cantidad de recursos.

Control de Versiones
Un Sistema de Control de Versiones (VCS, Version Control System) es una
herramienta CASE, utilizada en la fase de codificación, integración y
mantenimiento.

Las dos funciones principales de los VCS :

- El almacenamiento de un histórico de la evolución del desarrollo.
 - El control de conflictos cuando haya más de una persona trabajando
sobre el mismo fichero.

El funcionamiento de un VCS:
- Se almacenan los ficheros del código fuente en un servidor.
- Los ficheros de ese servidor no se modifican directamente.
- Cada desarrollador tiene su propia copia del código
- Si un desarrollador quiere modificar un fichero informa que va a realizar
dicha modificación
- Cuando la modificación está realizada, actualiza el fichero del servidor
- Cuando dos usuarios modifican el mismo fichero, el sistema resuelve
los conflictos automáticamente línea por línea.
- En el caso de que ambos programadores modifiquen las mismas
líneas, el sistema avisa para que el último desarrollador resuelva el
conflicto de manera manual.

Hay que usar un VCS cuando un desarrollador debería siempre utilizar un

VCS para controlar su código.

Sistemas de control de versiones local, se puede instalar GIT local, el

repositorio lleva un registro de todos los cambios realizados sobre los
archivos de nuestro proyecto.
Sistemas de control de versiones centralizado, Necesitamos tener un
repositorio remoto común donde todos tengan acceso de envío (push) y
recepción (pull).

Áreas de trabajo en un proyecto Git

- Directorio de trabajo(Working Directory) ficheros sobre los que
trabajamos
- Área de preparación(Staging Area) Donde se preparan los
archivos que han sido modificados y se quieren incluir en el
siguiente commit.
- directorio de Git(Git directory o Repository) Donde se almacenan
las instantáneas del estado del área de preparación en el momento
de hacer un commit.

Ramas
Una rama es un mecanismo que integran algunos CVS para permitir aislar de
la línea de desarrollo principal cambios que se quieren realizar.
- En Git a esa rama principal se le llama MASTER.
init: Se inicia el repositorio.
checkout: Cambiar a otra rama.
commit: creas una nueva revisión.
tags: etiquetar cada versión del fichero para saber que fue lo que se compró
en una determinada fecha.
diff: ver en qué se ha modificado la lista entre dos versiones.
branch: abre una rama.
merge: mezclar el archivo de la rama.
Fast-Forward: queremos mezclar 2 ramas donde un desciende del último
commit de la otra
Merging: Queremos mezclar 2 ramas divergentes.
Rebase: Se reorganizan las ramas para mantener un histórico lineal.

JUNIT
JUnit es una herramienta para realizar pruebas unitarias automatizadas.
Las pruebas unitarias se realizan sobre una Clase para probar su
comportamiento de forma aislada independientemente del resto de clases de
la aplicación.
En la Clase de Prueba se van a generar los métodos de prueba con un
código prototipo:
- El método de prueba llamará al método que va a ser evaluado.
Aserciones
- Los método assert() se utilizan para hacer las pruebas.
- Estos métodos permiten comprobar si la salida del método que se está
probando concuerda con los valores esperados.
- Todos devuelven tipo void.
- Inicializadores y Finalizadores.
- El método setUp es un método de inicialización de la prueba y se
ejecuta antes de cada caso de prueba en la clase de prueba.
- El método tearDown es un método finalizador de prueba y se
ejecutará después de cada test en la clase prueba.

Se trata de palabras clave que se colocan antes de los métodos de test e

indican a las librerías Junit instrucciones concretas:
- @RunWith
- @Before
- Si anotamos a un método con esta etiqueta el código será
ejecutado antes de cada método de prueba.
- Puede haber varios métodos con esta anotación.
 - Se usa para ejecutar actividades intensivas como conectar a una
base de datos
- El método marcados @BeforeClass necesita ser definidos como
static
- @After
- Si anotamos un método con esta etiqueta el código será
ejecutado después de cada método de prueba.
- Podemos tener varios métodos con esta anotación.
- Se usa para actividades de limpieza, como por ejemplo,
desconectar de la base de datos.
- El método marcados @BeforeClass necesita ser definidos como
static
- @Test
- La anotación @Test identifica el método que sigue como método
de prueba o método test.