Ángel Antonio Carvajal C.Jesús Antonio Hoyos Perdomo

FASE DE PRUEBAS DEL SOFTWARE

PRUEBAS DE MODULOPRUEBAS DE MODULOY Y

PRUEBAS DE PRUEBAS DE INTEGRACIONINTEGRACION

FASES DE PRUEBASF

AS

ES

DE

PR

UE

BA

S

PRUEBAS DE MODULO (Sueltos

Sistemáticas)

PRUEBAS DE INTEGRACION

(Varios Módulos)

PRUEBAS DE ACEPTACION

(Clientes)

Caja Blanca (Código escrito)

Caja Negra (Funcionali

dad)

Cobertura de Segmento (Secuencia de sentencias sin punto de decisión)Cobertura de Ramas (Recorre toda las posibles salidas.Cobertura de Condición/Decisión (Expresión Booleana correcta)Cobertura de Bucles (While, DoWhile, For “ciclos”).

Cobertura de Requisitos:Prueba de caja OpacaPruebas funcionales (código)Prueba de E/SPrueba incluida por los datos

Involucran Módulos.Estructurales(Personaliza llamada de Módulos)Funcionales (Como la caja negra, funcionabilidades conjuntasPruebas Finales (Consideran todo el Sistema)Técnicas de Diseño: - Diseño Descendente (Módulos Generales) - Diseño Ascendente (Módulos Base). - Codificación Incremental (se codifica solo parte de cada modulo y se van añadiendo funcionalidades.

- Las realiza el cliente antes de pasar en producción- Errores que solo el cliente Detecta.- Técnicas: - Entorno Controlado (Alfa) - Entorno sin controles se queda en el producto (Beta)

DISEÑO:ANGEL

FASE DE PRUEBASFASE DE PRUEBAS

Una vez que el programa está Una vez que el programa está introducido en la memoria del introducido en la memoria del ordenador, es necesario depurar ordenador, es necesario depurar posibles errores. La experiencia posibles errores. La experiencia demuestra que hasta el programa demuestra que hasta el programa más sencillo contiene errores y, por lo más sencillo contiene errores y, por lo tanto, este es un paso de vital tanto, este es un paso de vital importancia.importancia.

Los errores más frecuentes son los sintácticos o de escritura, por habernos equivocado durante la codificación. Para corregirlos, basta con localizar el error (que generalmente nos marcará el propio ordenador) y subsanarlo.

Más peliagudos son los errores de análisis o diseño. Un error en fases tan tempranas dará lugar a un programa que, aunque corre en la máquina, no hace lo que se esperaba de él y, por lo tanto, no funciona.

Estos errores obligan a revisar el análisis y el diseño y, en consecuencia, a rehacer todo el trabajo de especificación, codificación y pruebas. La mejor forma de evitarlos es realizar un análisis y un diseño concienzudos antes de lanzarnos a teclear código como un loco.

Existen varias técnicas, relacionadas con los controles de calidad, para generar software libre de errores y diseñar baterías de prueba que revisen los programas hasta el límite de lo posible, pero que quede claro: ningún programa complejo está libre de errores al 100% por más esfuerzos que se hayan invertido en ello.

La importancia de la detección oportuna

En la cadena de valor del desarrollo de un software específico, el proceso de prueba es clave a la hora de detectar errores o fallas. Conceptos como estabilidad, escalabilidad, eficiencia y seguridad se relacionan a la calidad de un producto bien desarrollado.

Las aplicaciones de software han crecido en complejidad y tamaño, y por consiguiente también en costos. Hoy en día es crucial verificar y evaluar la calidad de lo construido de modo de minimizar el costo de su reparación. Mientras antes se detecte una falla, más barato es su corrección.

El proceso de prueba es un proceso técnico especializado de investigación que requiere de profesionales altamente capacitados en lenguajes de desarrollo, métodos y técnicas de testeo y herramientas especializadas. El conocimiento que debe manejar un ingeniero de prueba es muchas veces superior al del desarrollador de software.

TIPOS DE PRUEBAS

Pruebas unitarias Pruebas funcionales Pruebas de Integración Pruebas de validación Pruebas de sistema Caja blanca (sistemas) Caja negra (sistemas)

CONTINUACION

Pruebas de aceptación Pruebas de regresión Pruebas de carga Pruebas de prestaciones Pruebas de recorrido Pruebas de mutación

PRUEBAS DE MODULO

En programación, una prueba unitaria es una forma de probar el correcto funcionamiento de un módulo de código. Esto sirve para asegurar que cada uno de los módulos funcione correctamente por separado. Luego, con las Pruebas de Integración, se podrá asegurar el correcto funcionamiento del sistema o subsistema en cuestión.

RESULTADOS

Conductor

Modulo que se va a probar

Resguardo Resguardo

Interfaz

Estructuras de datos locales

Condiciones límite

Caminos Independientes

Caminos de manejo de errores

Casos de prueba

Casos de prueba

Casos de prueba

Casos de pruebaCasos de prueba

Entorno para la prueba de unidad

Características

Para que una prueba unitaria o de modulo sea Para que una prueba unitaria o de modulo sea buenabuena se deben cumplir los siguientes requisitos: se deben cumplir los siguientes requisitos:

Automatizable: No debería requerirse una intervención manual. Esto es especialmente útil para integración continúa. Completas: Deben cubrir la mayor cantidad de código. Repetibles o Reutilizables: No se deben crear pruebas que sólo puedan ser ejecutadas una sola vez. También es útil para integración continua. Independientes: La ejecución de una prueba no debe afectar a la ejecución de otra. Profesionales: Las pruebas deben ser consideradas igual que el código, con la misma profesionalidad, documentación, etc.

PRUEBAS DE INTEGRACIONPRUEBAS DE INTEGRACION

Las pruebas de integración son aquellas que se realizan en el ámbito del desarrollo de software una vez que se han aprobado las pruebas unitarias.

Únicamente se refieren a la prueba o pruebas de todos los elementos unitarios que componen un proceso, hecho en conjunto, de una sola vez.

ContinuaciónContinuación

Consiste en realizar pruebas para verificar que un gran conjunto de partes de software funcionan juntos.

Las pruebas de integración (algunas veces llamadas Integración y Testeo (&t) es la fase del testeo de software en la cual módulos individuales de software son combinados y testeados como un grupo. Son las pruebas posteriores a las pruebas unitarias y preceden el testeo de sistema.

El objetivo es coger los módulos probados individualmente y construir una estructura de programa que este de acuerdo con lo que dicta el diseño.

Un novato del mundo del software podría, una vez que ha hecho la prueba individual a cada modulo, cuestionar de forma aparentemente legitima lo siguiente: si todos los módulos funcionan bien por separado, ¿Por qué dudar de que funcionen bien todos juntos?Por supuesto, el problema es ponerlos todos juntos (interacción).Puede suceder lo siguiente:

Los datos se pueden perder en una interfaz.

Un modulo puede tener un efecto adverso e inadvertido sobre otro.

Las subfunciones, cuando se combinan, pueden no producir la función principal deseada.

La imprecisión aceptada individualmente puede crecer hasta niveles inaceptables

Las estructuras de datos globales pueden presentar problemas, etc.

A menudo hay una tendencia a intentar una integración no incremental; es decir, a construir el programa mediante un enfoque de <big bang>. Se combinan todos lo módulos por anticipado. Se prueba todo el programa en conjunto. !Normalmente se llega al caos!. Se encuentra un gran conjunto de errores. La corrección se hace difícil, puesto que es complicado aislar las causas al tener delante el programa entero en toda su extensión.Una vez que se corrigen esos errores aparecen otros y el proceso continua en lo que parece un ciclo sin fin.

La integración incremental es la antítesis del enfoque del <big bang>. El programa se construye y se prueba en pequeños segmentos en los que los errores son mas fáciles de aislar y de corregir, es mas probable que se puedan probar completamente las interfaces y se puede aplicar un enfoque de prueba sistemática.

Las pruebas de integración pueden ser: Prueba de integración descendente. Pruebas de integración ascendente.

Integración DescendenteIntegración Descendente

La integración descendente es un planteamiento incremental a la construcción de la estructura de programas. Se integran los módulos moviéndose hacia abajo por la jerarquía de control, comenzando por el modulo de c0ntrol principal (programa principal). Los módulos subordinados al modulo de control principal se van incorporando a la estructura, bien de forma primero-en-profundidad, o bien de forma primero-en-anchura.

M1

M3M2

M6M5 M7

M8

M4

INTEGRACION DESCENDENTEINTEGRACION DESCENDENTE

La integración primero-en-profundidad integra todos los módulos de un camino de control principal de la estructura.

La selección del camino principal es arbitraria y depende de las características especificas de la aplicación. Por ejemplo, si se elige el camino del lado izquierdo, se integraran primero los módulos M1, M2 y M5.

A continuación se integrara M8, o M6, para un funcionamiento adecuado de M2

Después se construyen los caminos de control central y derecho. La integración primero-en-anchura incorpora todos los módulos directamente subordinados a cada nivel, moviéndose por la estructura de forma horizontal. Según la figura anterior los primeros módulos que se integran son M2, M3 y M4.

Luego el siguiente nivel de control M5, M6 y M7.

PRUEBAS DE INTEGRACION ASCENDENTE

Empieza la construcción y la prueba con los módulos atómicos (es decir, módulos de los niveles mas bajos de la estructura del programa). Dado que los módulos se integran de abajo hacia arriba, el proceso requerido de los módulos subordinados a un nivel dado siempre están disponibles

Se puede implementar una estrategia de integración ascendente mediante los siguiente pasos:1.Se combinan los módulos de bajo nivel en grupos ( a veces llamados construcciones) que realicen una subfuncion especifica del software.2.Se escribe un controlador para coordinar la entrada y salida de los casos de prueba.3.Se prueba el grupo.4.Se eliminan los controladores y se combinan los grupos moviéndose hacia arriba por la estructura del programa.

Mc

MbMa

D3D1 D2

GRUPO 1

GRUPO 2

GRUPO 3

En la integración, según el esquema anterior, se combinan los módulos para formar los grupos 1, 2 y 3.

Cada uno de los grupos se somete a prueba mediante un controlador (mostrado como un bloque punteado). Los módulos de los grupos 1 y 2 son subordinados de Ma.

Los controladores D1 y D2 se eliminan y los grupos interaccionan directamente con Ma.

De forma similar, se elimina el controlador D3 del grupo 3 antes de la integración con el modulo Mb.

Tanto Ma como Mb se integraran finalmente con el modulo Mc y así sucesivamente.

A medida que la integración progresa hacia arriba, disminuye la necesidad de controladores de prueba diferentes