Tecnicas De Prueba

Principios de Pruebas.-

Las pruebas de software se aplican en la fase de prueba y validación del desarrollo de un sistema de información y son un conjunto de herramientas técnicas y métodos que tienen como objeto comprobar los requerimientos establecidos con los usuarios o beneficiarios del producto. Estas técnicas tienen como objeto detectar problemas y son extensamente variadas y van desde el uso del ingenio por parte del personal de pruebas hasta herramientas automáticas que ayudan a aliviar el peso y el costo de esta actividad. Las pruebas no pueden asegurar la ausencia de errores; sólo puede demostrar que existen defectos en el software.

1.1 Defectos vs Fallas.-

 Un defecto es el resultado de un fallo o deficiencia durante el proceso de creación de programas de ordenador o computadora (software).

 Dicho fallo puede presentarse en cualquiera de las etapas del ciclo de vida del software aunque los más evidentes se dan en la etapa de desarrollo y programación.

 Los errores pueden suceder en cualquier etapa de la creación de software.

 Un defecto es algo OBJETIVO, puede medirse y cuantificarse.

 El fallo del software es cualquier problema a nivel del sistema operativo o de los programas instalados en éste.

 Es la operación errónea de un software debido a un elemento no validado dentro del código.

 Es cuando un software ejecuta una acción para lo cual no fue programado.

Tipos de Defectos.-

Algunos de estos tipos son los siguientes:

• Requerimientos.

• Características y Funcionalidad.

• Defectos estructurales.

• Datos.

• Implementación y Codificación.

• Integración.

• Sistemas, Arquitectura de Software.

1.2 Clases Equivalentes.-

 Una clase de equivalencia representa un conjunto de estados válidos o no válidos para condiciones de entrada.

 Típicamente, una condición de entrada es un valor numérico específico, un rango de valores, un conjunto de valores relacionados o una condición lógica.

 Es de notar que dos tipos de clases de equivalencia están identificados:

 Las clases de equivalencia válidas representan entradas válidas al programa

 Las clases de equivalencia inválidas que representan el resto de los estados posibles de la condición (es decir, valores erróneos de la entrada).

Condición de Entrada Clases Válidas Clases Inválidas

Código de Área

# de 3 dígitos que no

empieza con 0 ni 1: 1) 200≤ código ≤ 999 2) Código < 200.

3) Código > 999.

4) No es número.

Nombre

Para identificar la operación 5) Seis caracteres. 6) Menos de 6

caracteres.

7) Más de 6 caracteres.

Orden

Una de las Siguientes 8) “Cheque”

9) “Depósito”

10) “Pago factura”

11)“Retiro de fondos” 12) Ninguna orden

válida

Ejemplo: Aplicación bancaria en la que el operador debe proporcionar un código, un nombre y una operación.

1.3 Prueba de Limite.-

Este tipo de pruebas consiste en llevar la elección de casos de prueba "en los bordes" o límites establecidos. En lugar de centrarse solamente en las condiciones de entrada, las pruebas de límites derivan casos también para el campo de salida. A continuación los aspectos a considerar en este tipo de pruebas.

 Si una condición de entrada especifica un rango delimitado por los valores a y b, se deben diseñar casos de prueba para los valores a y b y para valores justo por debajo y justo por encima de a y b.

 Si una condición de entrada especifica un número de valores, se deben desarrollar casos de prueba que ejerciten los valores máximo y mínimo. También se deben probar los valores justo por debajo del máximo y del mínimo.

 Aplicar las directrices 1 y 2 a las condiciones de salida.

 Si las estructuras de datos internas tienen límites preestablecidos hay que asegurarse de diseñar un caso de prueba que ejercite la estructura de datos en sus límites.

Tipos de Defectos.-

2.1 Prueba de Caja Blanca (Estructural) y Caja Negra (Funcional).-

Prueba Estructural: utilizan el código fuente del programa, y especialmente su estructura de control, para seleccionar casos de prueba.

Algunas de sus características:

• Por lo menos se prueban una vez todos los caminos independientes de cada módulo o unidad de software.

• Se prueban todas las decisiones lógicas en sus vertientes verdadera y falsa de cada módulo o unidad de software.

• Se prueban todos los bucles en sus límites y con sus límites operacionales de cada módulo o unidad de software.

• Se prueba todas las estructuras internas de datos para asegurar su validez para cada módulo o unidad de software

Existen varias estrategias que permiten obtener casos de prueba a partir del código fuente de un programa (Beizer, 1990). Las siguientes son algunas de las más representativas:

 Prueba del camino básico.-

Es una técnica propuesta inicialmente por Tom McCabe, que permite al diseñador de casos de prueba obtener una medida de la complejidad lógica de un diseño procedimental. Y permite usar esa medida como guía para la definición de un conjunto básico de caminos de ejecución. Los casos de prueba obtenidos del conjunto básico garantizarán que durante la prueba se ejecuta por lo menos una vez cada sentencia del programa.

Algunos elementos y conceptos utilizados alrededor de éste método son los siguientes:

 Grafo de flujo o grafo del programa: Representa el flujo de control lógico de un programa y se utiliza para trazar más fácilmente las caminos de éste. Cada nodo representa una o más sentencias procedimentales y cada arista representa el flujo de control.

 Nodos: representan cero, una o varias sentencias en secuencia. Cada nodo comprende como máximo una sentencia de decisión (bifurcación).

 Aristas: líneas que unen dos nodos.

 Regiones: áreas delimitadas por aristas y nodos. Cuando se contabilizan las regiones de un programa debe incluirse el área externa como una región más.

 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

...