Pruebas de Software

Las pruebas de software consisten en la dinámica de la verificación del

comportamiento de un programa en un conjunto finito de casos de prueba,
debidamente seleccionados de por lo general infinitas ejecuciones de dominio, contra
la del comportamiento esperado. Son una serie de actividades que se realizan con el
propósito de encontrar los posibles fallos de implementación, calidad o usabilidad de
un programa u ordenador; probando el comportamiento del mismo.

Objetivos de las pruebas de software.

La prueba de software es un elemento crítico para la garantía del correcto
funcionamiento del software. Entre sus objetivos están:

1. Detectar defectos en el software.

2. Verificar la integración adecuada de los componentes.
3. Verificar que todos los requisitos se han implementado correctamente.
4. Identificar y asegurar que los defectos encontrados se han corregido
antes de entregar el software al cliente.
5. Diseñar casos de prueba que sistemáticamente saquen a la luz
diferentes clases de errores, haciéndolo con la menor cantidad de
tiempo y esfuerzo.

Para lograr los objetivos propuestos, un ingeniero de software deberá conocer

los principios básicos que guían las pruebas del software.

Principios de las pruebas de software.

Las pruebas se rigen por una serie de principios, una buena comprensión de
estos facilitará el posterior uso de los métodos en un efectivo diseño de casos
de prueba. A continuación se citan:

 La prueba puede ser usada para mostrar la presencia de errores, pero

nunca su ausencia.
 La principal dificultad del proceso de prueba es decidir cuándo parar.
 Evitar casos de pruebas no planificados, no reusables y triviales a menos
que el programa sea verdaderamente sencillo.
 Una parte necesaria de un caso de prueba es la definición del resultado
esperado.
 Los casos de pruebas tienen que ser escritos no solo para condiciones de
entrada válidas y esperadas sino también para condiciones no válidas e
inesperadas.
 El número de errores sin descubrir es directamente proporcional al número
de errores descubiertos.

Estas leyes que definen básicamente la aplicación de las pruebas de software

ayudan a refinar el producto de software a través de las etapas involucradas.

Etapas involucradas en las pruebas de software.

1. Seleccionar qué es lo que debe medir la prueba, es decir, cuál es su
objetivo, para qué exactamente se hace la prueba.
2. Decidir cómo se va a realizar la prueba, es decir, qué clase de prueba se
va a utilizar para medir la calidad y qué clase de elementos de prueba
se deben usar.
3. Desarrollar los casos de prueba. Un caso de prueba es un conjunto de
datos o situaciones de prueba que se utilizarán para ejecutar la unidad
que se prueba o para revelar algo sobre el atributo de calidad que se
está midiendo.
4. Determinar cuáles deberían ser los resultados esperados de los casos
de prueba y crear el documento que los contenga.
5. Ejecutar los casos de prueba.

Evaluación de resultados
Comparar los resultados de la prueba con los resultados esperados. Cualquier
discrepancia entre ellos significa un error. Típicamente el error está en el
sistema o unidad probada, pero también puede ser generado por algún aspecto
del mismo proceso de prueba.
Caja Blanca
 Caminos Basicos

 Pruebas de caminos básicos:

Esta prueba lo que demuestra es el conjunto de pasos base del programa, lo que quiere lograr es que
cada sentencia de código se ejecute mínimo una vez.
Deacuerdo con freddy, (2008), en analisis de la prueva de caja blanca en programación, se denomina
cajas blancas a un tipo de pruebas de software que se realiza sobre las funciones internas de un módulo,
así como las pruebas de caja negra ejercitan los requisitos funcionales desde el exterior del modulo, las
de caja blanca están dirigidas a las funciones internas. Entre las técnicas usadas se encuentran la
cobertura de pruebas sobre las expresiones lógico-aritméticas, pruebas de camino de datos definición uso
de variables, comprobación de bucles se verifican los bucles para 0,1 y n iteraciones, y luego para las
iteraciones máximas, máximas menos uno y más uno.

Las pruebas de caja blanca se llevan a cabo en primer lugar, sobre un módulo concreto, para luego
realizar las de caja negra sobre varios subsistemas.

El objetivo de las pruebas de caja blanca pueden aplicarse a los métodos de la clase, pero según varias
opiniones, ese esfuerzo debería dedicarse a otro tipo de pruebas más especializadas una forma puede
ser que los métodos de una clase suelen ser menos complejos que los de una función de programación
estructurada, realizan un seguimiento del código fuente según va ejecutando los casos de prueba, de
manera que se determinan de manera concreta las instrucciones, bloques, en los que existen errores.
Cuando se pasan casos de prueba al programa que se está probando, es conveniente conocer qué
porcentaje del programa se ha ejecutado, de manera que estemos próximos a asegurar que todo él es
correcto existen varias formas de medir la cobertura lograda en el programa por los casos de prueba,
algunas de las cuales se presentan en el siguiente epígrafe.
 Estructura de Control

Pruebas de la Estructura de Control

En cuanto a esta prueba se presentaran algunas variantes de la prueba de estructura de control. Estas
variantes amplían la cobertura de la prueba y así mismo mejoran la calidad de la prueba blanca.

Caja negra

ruebas de Caja Negra

Las pruebas de caja negra, también denominada prueba de compartimiento, permiten obtener un conjunto
de condiciones de entrada que ejerciten completamente todos los requisitos funcionales de un programa.
En ellas se ignora la estructura de control, concentrándose en los requisitos funcionales del sistema y
ejercitándolos, también permiten derivar casos de pruebas que buscan encontrar los siguientes tipos de
errores: a) funciones incorrectas o faltantes, b) errores de interfaz, c) errores de estructuras de datos o en
acceso a BD externas, d) errores de compartimiento o desempeño, y e) errores de inicialización o termino

Ilustración 2 La prueba de Caja Negra se centra principalmente en los requisitos funcionales del software.
Fuente: PRESSMAN, ROGER S.
Para preparar cada uno de los casos de pruebas hacen falta un número de datos que ayuden a la
ejecución de estos casos y que permitan que el sistema se ejecute en todas sus variantes, pueden ser
datos válidos o inválidos para el programa según lo que se desea es hallar es un error o probar una
funcionalidad. Para desarrollar la prueba de caja negra existen varias técnicas, entre ellas están:
 1. Técnica de la Partición de Equivalencia: esta técnica divide el campo de entrada en clases de datos
que tienden a ejercitar determinadas funciones del software.
 2. Técnica del Análisis de Valores Límites: esta Técnica prueba la habilidad del programa para manejar
datos que se encuentran en los límites aceptables, y;
 3. Técnica de Grafos de Causa-Efecto: es una técnica que permite al encargado de la prueba validar
complejos conjuntos de acciones y condiciones.
Dentro del método de Caja Negra la técnica de la Partición de Equivalencia es una de las más efectivas
pues permite examinar los valores válidos e inválidos de las entradas existentes en el software, descubre
de forma inmediata una clase de errores que, de otro modo, requerirían la ejecución de muchos casos
antes de detectar el error genérico. La partición equivalente se dirige a la definición de casos de pruebas
que descubran clases de errores, reduciendo así en número de clases de prueba que hay que desarrollar.
A partir de un caso de uso se pueden realizar pruebas de caja negra, obteniéndose varios casos de
prueba que permiten:
 a) Verificar el resultado de la interacción entre los actores y el sistema.
 b) Comprobar que se satisfagan las precondiciones y poscondiciones del caso de uso, y;
 c) Evidenciar que se siga una secuencia de acciones especificado por el caso de uso.

Ventajas de las pruebas de Caja-Negra

 Elimina la necesidad de las pruebas exhaustivas.
 Es una guía para seleccionar el conjunto de datos de entrada para las pruebas, con alta probabilidad de
detectar defectos.
 Permite realizar una cobertura de un dominio de entradas grande con un subconjunto pequeño tomado de
clase de equivalencia.