Tema: fundamentos y tipos de pruebas realizadas al software.

Objetivo: Comprender el proceso de ejecución de las pruebas.

La ingeniería de software es una disciplina diferente a las demás, pues busca

integrar principios de matemáticas y ciencias de la computación con principios
de la ingeniería que permiten desarrollar el software de una manera más
completa pues hay toma de decisiones, análisis de costos y beneficios, análisis
y diseño apropiado de un problema, basado en experiencia y validaciones
propias que requiere esta disciplina.
En la ingeniería de software, los ingenieros realizan muchas tareas como la
investigación, desarrollo, diseño, pruebas, administración, consultoría,
capacitación, uso de herramientas para aplicar los procesos de manera
sistemática diseño de artefactos y reutilización de código.
La prueba es un proceso que se enfoca sobre la lógica interna del software y
las funciones externas.

Objetivos de las pruebas:

1. La prueba es el proceso de ejecución de un programa con la intención de
descubrir un error.
2. Un buen caso de prueba es aquel que tiene una alta probabilidad de
descubrir un error no encontrado hasta entonces.
3. Una prueba tiene éxito si descubre un error no detectado hasta entonces.
No sólo se prueba el código: también documentación y ayuda.

Principios de las pruebas

 A todas las pruebas se les debería poder hacer un seguimiento hasta los
requisitos del cliente.
 Las pruebas deberían planificarse mucho antes de que empiecen.
 Las pruebas deberían empezar por “lo pequeño” y progresar hacia “lo
grande”.
 No son posibles las pruebas exhaustivas.
 Para ser más eficaces (pruebas con la más alta probabilidad de
encontrar errores), las pruebas deberían ser realizadas por un equipo
independiente.
  Se debe inspeccionar a conciencia el resultado de cada prueba para,
así, poder descubrir posibles síntomas de defectos.
 Cada caso de prueba debe definir el resultado de salida esperado.
 Al generar casos de prueba, se deben incluir tanto datos de entrada
válidos y esperados como no válidos e inesperados Las pruebas deben
centrarse en dos objetivos (es habitual olvidar el segundo)
 Probar si el software no hace lo que debe hacer
 Probar si el software hace lo que no debe hacer, es decir si provoca
efectos secundarios
 Se deben evitar los casos desechables.
 No deben hacerse planes de prueba suponiendo que, prácticamente, no
hay defectos en los programas, y dedicando pocos recursos a las
pruebas.
 La experiencia indica que donde hay un defecto hay otros.
 Las pruebas son una tarea creativa como el desarrollo de software.
Las pruebas deben ser realizadas por un equipo independiente al que realizó el
software, porque este inconscientemente tratará de demostrar que el software
funciona y no que no lo hace, por lo que la prueba puede tener menos éxito.

Fiabilidad: Probabilidad de operación libre de fallos de un programa de

computadora en un entorno determinado y durante un tiempo específico.

ESTRATEGIAS DE PRUEBA PARA SOFTWARE

Existen muchas estrategias que pueden usarse para probar el software. En un
extremo, puede esperarse hasta que el sistema esté completamente construido
y luego realizar las pruebas sobre el sistema total, con la esperanza de
encontrar errores. Este enfoque, aunque atractivo, simplemente no funciona.
En el otro extremo, podrían realizarse pruebas diariamente, siempre que se
construya alguna parte del sistema. Este enfoque, aunque menos atractivo
para muchos, puede ser muy efectivo.
Una estrategia de prueba que eligen la mayoría de los equipos de software se
coloca entre los dos extremos. Toma una visión incremental de las pruebas,
comenzando con la de unidades de programa individuales, avanza hacia
pruebas diseñadas para facilitar la integración de las unidades y culmina con
pruebas que ejercitan el sistema construido.
Los 5 tipos de prueba del software
 Especificación: Este tipo de prueba incluye probar la aplicación en
contra de la documentación que se hizo antes, por ejemplo, que los
procesos concuerden con los algoritmos hechos a papel, o que la
aplicación tenga todas las funciones que se habían planeado.
 Usabilidad: Este tipo de prueba se refiere a asegurar de que la interfaz
de usuario (o GUI) sea intuitiva, amigable y funcione correctamente.
 Unidad: Este tipo de prueba solo aplica a proyectos grandes. Se divide
el proyecto a unidades y cada unidad es sometida a prueba
individualmente.
 Integración: Prueba varias unidades juntas para asegurar que
funcionen bien. También se asegura de que las nuevas aplicaciones se
integren con aplicaciones antiguas o aplicaciones complementarias.
 Regresión: Esta prueba incluye todas las pruebas anteriores en caso de
que se le haga algún cambio a algún modulo después de haber sido
puesto en ambiente de producción.

VERIFICACIÓN Y VALIDACIÓN
La prueba del software es un elemento de un tema más amplio que suele
denominarse verificación y validación.
Verificación: Es el conjunto de tareas que garantizan que el software
implementa correctamente una función específica
 ¿Estamos construyendo el producto correctamente?
Validación: Es un conjunto diferente de actividades que aseguran que el
software que se construye sigue los requerimientos del cliente
 ¿Estamos construyendo el producto correcto?

PRUEBAS ALFA Y BETA

La prueba alfa es conducida por un cliente en el lugar de desarrollo. Se usa el
software de manera natural, con el encargado de desarrollo "mirando por
encima del hombro" del usuario" y registrando errores y problemas de uso. Las
pruebas alfa se llevan a cabo en un entorno controlado.
La prueba beta se lleva a cabo en uno o más lugares de clientes por los
usuarios finales del software. A diferencia de la prueba alfa, el encargado de
desarrollo, normalmente, no está presente. La prueba beta es una aplicación
"en vivo" del software en un entorno que no puede ser controlado por el equipo
de desarrollo. El cliente registra todos los problemas (reales o imaginarios) que
encuentra y los informa a intervalos regulares. Como resultado, el equipo de
desarrollo lleva a cabo modificaciones y así prepara una versión del producto
para toda la base de clientes.
Los Métodos de Prueba de Software tienen el objetivo de diseñar pruebas
que descubran diferentes tipos de errores con menor tiempo y esfuerzo.
A continuación, se presentan los Mecanismos de Prueba de Software más
conocidos:
 La lógica interna del programa utilizando técnicas de diseño de casos de
prueba de "caja blanca”
Las pruebas de caja blanca se basan en un examen minucioso de los detalles
procedimentales, comprobando los caminos lógicos del programa,
comprobando las condiciones y ciclos; examinando el estado del programa en
varios puntos. (Criterios basados en el contenido de los módulos).
 Los requisitos del software utilizando técnicas de diseño de casos de
prueba de "caja negra"
Las pruebas de caja negra se aplican a la interfaz del software, examinando el
aspecto funcional del sistema. Pretenden demostrar que las funciones del
software son operativas, que la entrada se acepta de forma adecuada y que se
produce una salida correcta. (Criterios basados en las interfaces y las
especificaciones de los módulos).

MÉTODO DE LA CAJA NEGRA

A la mayor parte de los usuarios de programas extensos no les interesa los

detalles de su funcionamiento; lo único que desean es conseguir respuestas. Es
decir, desean tratar el programa como una caja negra a la cual le introducen
datos de entrada y obtienen de ella los datos de salida que esperan. De ahí el
nombre de este método. De manera análoga, los datos de prueba se escogerán
atendiendo a las especificaciones del problema, sin importar los detalles internos
del programa, a fin de verificar que éste corra bien.

El Método de la Caja Negra se centra en los requisitos fundamentales del

software y permite obtener entradas que prueben todos los requisitos funcionales
del programa. Con este tipo de pruebas se intenta encontrar:

 Funciones incorrectas o ausentes.

 Errores de interfaz.
 Errores en estructuras de datos o en accesos a las bases de datos
externas.
 Errores de rendimiento.
 Errores de inicialización y terminación.
TIPOS DE PRUEBA DE CAJA NEGRA

 Métodos gráficos de prueba

 Partición Equivalente
 Análisis de valores límite
 Prueba de tabla ortogonal
 Pruebas de interfaces gráficas
 Prueba de arquitectura cliente/servidor
 Pruebas de servidor
 Pruebas de base de datos
 Pruebas de transacción
 Pruebas de comunicación de red
 Pruebas de documentación
 Pruebas de sistemas de tiempo real

Criterios mínimos que deben guiarnos al escoger los datos de prueba de

nuestros programas:

1. Valores fáciles El programa se depurará con datos de fácil

comprobabilidad. Más de un estudiante, que ensayó un programa
exclusivamente con datos complicados y que creyó que funcionaba bien,
se ha sentido apenado cuando su instructor aplicó el programa a un
ejemplo trivial.
2. Valores típicos realistas Siempre se ensayará un programa con datos
seleccionados para que representen cómo se aplicará. Tales datos han
de ser suficientemente sencillos, de modo que los resultados sean
verificables en forma manual.
3. Valores extremos Muchos programas cometen errores en los límites de
sus rangos de aplicaciones. Es muy fácil que las instrucciones que
incluyen a los contadores de ciclos o que hacen referencia a las
dimensiones de un arreglo se equivoquen por uno.
4. Valores ilegales "Basura entra, basura sale" es un viejo refrán en los
círculos de computación y conviene respetarlo. Cuando en un programa
entra basura, su reacción inmediata habrá de ser por lo menos un
mensaje de error adecuado para el usuario. Es preferible que el programa
ofrezca a éste alguna indicación de probables errores detectados en los
datos de entrada que se han ingresado y que realice cálculos que sigan
siendo factibles luego de desechar la entrada equivocada, o intente
funcionar con datos predefinidos evitando así que el programa colapse.
PRUEBA DE LA CAJA BLANCA

Las pruebas de caja blanca intentan garantizar que:

• Se ejecutan al menos una vez todos los caminos independientes de

cada módulo
• Se ejecutan las decisiones en su parte verdadera y en su parte falsa
• Se ejecuten todos los bucles en sus límites
• Se utilizan todas las estructuras de datos internas para comprobar su
validez.

Tipos de Prueba de Caja Blanca:

 Prueba de la Ruta Básica

 Pruebas de la estructura de control
 Prueba de condición
 Prueba del flujo de datos
 Prueba de bucles

PRUEBA DE CAMINO BÁSICO O RUTA BÁSICA (Mc Cabe)

 Permite obtener una medida de la complejidad lógica de un diseño

procedimental y usar esa medida como guía para la definición de un
conjunto básico de caminos de ejecución.
 Hace uso de la representación del flujo de control mediante un grafo de
flujo (o grafo del programa).
 Se basa en la representación del código a probar a través de círculos y
arcos que indican el flujo de control. Cada círculo representa una o más
sentencias.

Pasos a realizar para aplicar esta técnica:

 Representar el programa en un grafo de flujo
 Calcular la complejidad ciclomática del grafo obtenido
 Determinar el conjunto básico de caminos independientes.
 Derivar los casos de prueba que fuerzan la ejecución de cada camino (que
permitan la ejecución de cada camino básico).
 Ejecutar cada paso de prueba y comparar con los resultados esperados.

Camino independiente es aquel que introduce un nuevo conjunto de sentencias

o una nueva condición. Una arista que no haya sido recorrida antes.
Elementos:

 Nodos: representan condiciones o secuencias de instrucciones. Cero, una

o varias sentencias en secuencia. Comprende como máximo una
sentencia de decisión.
 Arcos, Aristas o enlaces: representan flujo de control del programa. Son
las líneas que unen dos nodos.
 Región: área que se limita por aristas y nodos. Cuando se contabilizan las
regiones de un programa debe incluirse el área externa como una región
más.
 Nodo predicado: Es un nodo que contiene una condición y se caracteriza
porque de él salen dos o más aristas. Una de las características para
comprobar si un grafo de flujo está bien diseñado es que los únicos nodos
de los que pueden partir dos aristas son los nodos predicado. Cuando en
una condición aparecen uno o más operadores lógicos (and, or, xor,..) se
crea un nodo distinto por cada una de las condiciones simples. Cada nodo
generado de esta forma se denomina nodo predicado.

CARACTERÍSTICAS DEL GRAFO DE FLUJO

 Existe un solo nodo inicial

 Existe un solo nodo final
 Cada nodo representa una secuencia de instrucciones, que puede ser
vacía
 Un nodo puede tener uno o dos sucesores
 Un nodo puede tener uno o muchos antecesores
 Un nodo tendrá dos sucesores, si existen dos caminos posibles,
dependiendo de una condición.
  Los casos de for, while, Repeat y Case, se pueden reducir a grupos de
nodos con dos sucesores

El grafo contendrá dos tipos de elementos:

a) nodos que representan una o más instrucciones secuenciales, y

b) arcos que representan cambios de dirección

En principio cada instrucción se representará como un nodo. Existen dos tipos

de instrucción:

a) Las que tienen un sucesor único, como las asignaciones y las instrucciones
de lectura.

b) Las que tienen dos o más sucesores posibles, como el If, la condición del
For y el case.

Las instrucciones con sucesor único, es decir las secuenciales, pueden

representarse una sola en cada nodo o varias de ellas en uno solo, ya que si se
ejecuta la primera se ejecutarán las siguientes una tras otra.

Formas de representar una sucesión de instrucciones, siendo todas ellas

equivalentes para los propósitos de cálculo de complejidad y de preparación de
pruebas.

 Una arista debe de terminar en un nodo incluso si el nodo no representa

ningún enunciado de procedimiento.
 Una secuencia de cajas de proceso y un rombo de decisión pueden
mapearse en un solo nodo.
 Cuando se cuentan las regiones, el área afuera del gráfico se incluye
como región.
PRUEBA DE APLICACIONES ORIENTADAS A OBJETOS

La prueba del software, comienza con la prueba de unidad, luego avanza hacia
la prueba de integración y culmina con las pruebas de validación y sistema. Estas
estrategias de prueba cambian en la naturaleza de los programas orientado a
objetos (OO).

Prueba de unidad en el contexto OO

La “unidad” comprobable más pequeña en el software OO es la clase. La prueba

de clase se activa mediante las operaciones encapsuladas por la clase y por el
comportamiento de estado de la misma.

Actividad: Investigar contestar

1. ¿Que son los métodos de Pruebas Orientadas a Objeto?

2. ¿Cuáles son las Indicaciones para realizar pruebas?
3. ¿Qué son los Modelos de pruebas AOO y DOO?
4. ¿Que son las Prueba de validación en un contexto OO?
5. ¿Cómo está compuesto Un proceso de pruebas formal?
6. ¿Qué son las Pruebas Software no Funcionales?
7. ¿Qué son las Pruebas Software Funcionales?
8. ¿Qué son las Pruebas Software Estructurales?
9. ¿Qué son las Pruebas Software de Regresión y las Re-pruebas?
10. ¿Cale son las estrategias de pruebas orientadas a objeto?
11. ¿Que son los métodos de pruebas aplicados a nivel de clases?
12. ¿Cuáles son los Niveles de Prueba del Software?
13. ¿Qué son los patrones de pruebas?