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 nodo predicado.

 Prueba de la estructura de control.-

 Prueba de Condición.-

Prueba los tipos de errores que pueden aparecer en una condición:

 Existe un error en un operador lógico.

 Existe un error en un paréntesis lógico.

 Existe un error en un operador relacional.

 Existe un error en una expresión aritmética.

 Prueba del Flujo de Datos.-

 Enumerar cada sentencia del programa.

 Asegurar que el programa no modifique variables globales.

 Asegurar que los subprogramas no modifiquen los parámetros dados por los programas que los llaman.

 Considerar una variable “x”.

 Localizar el número de sentencia “m” donde se inicializa la variable.

 Localizar los números de sentencia “n1, n2, …,nX” donde se usa la variable “x”.

 Definir el conjunto de declaraciones entre los números de declaración “m” y “ni” como cadenas de definición-uso.

 El método de prueba de flujo de datos indica que cada cadena de definición-uso debe ser cubierta por cada caso de prueba al menos una vez.

 Prueba de Bucles.-

Pruebas para Bucles simples (Ver figura #1)

(n es el número máximo de iteraciones permitidos por el bucle). En este método sus objetivos son los siguientes:

• Pasar por alto totalmente el bucle

• Pasar una sola vez por el bucle

• Pasar dos veces por el bucle

• Hacer m pasos por el bucle con m < n

• Hacer n-1, n y n + 1 pasos por el bucle Figura #1

Para las pruebas de Bucles Anidados (Ver figura #2), sus objetivos son los siguientes:

• Comenzar en el bucle más interior estableciendo los demás bucles en sus valores mínimos

• Realizar las pruebas de bucle simple para el más interior manteniendo los demás en sus valores mínimos

• Avanzar hacia fuera confeccionando pruebas para el siguiente bucle manteniendo todos los externos en los valores mínimos y los demás bucles anidados en sus valores típicos

• Continuar el proceso hasta haber comprobado todos los bucles

Figura #2

Pruebas para Bucles concatenados (Ver Figura #3)

Siempre que los bucles concatenados sean independientes se puede aplicar lo relativo a bucles simples/anidados. En caso de ser dependientes se evaluarán como bucles anidados

Figura #3

Pruebas para Bucles no estructurados (Ver Figura #4)

Siempre que se usen los mecanismos que aporta la programación estructurada, este tipo de bucles no estarán presentes

Figura #4

Prueba Funcional:

...