Prueba y Mantenimiento.

02 Lewis
Visión General de las técnicas de prueba. 
                                                                                                                                    
                                                  
La prueba de software, como un proceso separado, ha sido testigo de un crecimiento
vertical y ha recibido la atención de aquellos líderes de proyectos y patrocinadores de
empresas en la década pasada. 

Aparte de las tradicionales técnicas de prueba, varias nuevas técnicas son exigidas por
empresas, y el desarrollo lógica de desarrollo, fue realizado para hacer una prueba de
software más significativas y útiles.

En esta parte se analizan algunas de las populares técnicas de prueba que han sido
adoptadas por la comunidad de prueba

Prueba de caja negra (Funcional)

Dentro de la caja negra o prueba funcional, las condiciones de prueba son desarrolladas en
base al programa o funcionalidad del sistema, esto es, el tester requiere de información
sobre la entrada de datos y observar las salidas, pero no se sabe como el programa o el
sistema trabaja. Así como uno no tiene que saber como un carro trabaja internamente para
manejarlo, no es necesario saber la estructura interna de un programa para ejecutarlo. El
tester se enfoca en la prueba de la funcionalidad del programa en vez de las
especificaciones. Con la prueba de la caja negra, el tester ve el programa como una caja
negra y esta completamente despreocupado con la estructura interna el programa o
sistema. Algunos ejemplos en esta categoria se incluyen en tablas de decisiones, particiones
de equivalencia, prueba de ranfo, prueba de límites de valores, prueba de integración de
base de datos, gráfica de causa-efecto, prueba de arreglos ortogonales, prueba de arreglos
y tablas, prueba de excepciones, prueba de limites pruebas al azar.

una ventaja mayor de la caja negra es que las pruebas son orientadas a lo que el sistema o
programa se supone debe hacer, lo que es natural y comprendido por todos. Esto debe ser
verificado con técnicas como lo son recorridos estructurados, inspección, y Joint Applicarion
Design (JAD) "Diseño de Aplicación Conjunta". Una limitación es la exhaustiva prueba de
entrada de datos que no se archiva, porque esto requiere que cada posible condición de
entrada de datos sea probada. En adición, pr que no hay conocimiento de la estructura
lógica interna, esto puede crear errores o una malicia deliberada por parte del programador
que no pueda ser detectada en la prueba de la caja negra. 

Prueba de la caja blanca. (Estructural)

En la caja blanca o prueba estructural, las condiciones de prueba son designadas al
examinar rutas de lógica. El tester examina la estructura interna del programa o sistema. La
pueba de datos es condicida por la examinación de la lógica del programa o sistema, sin
preocupación por el programa o los requerimientos del sistema. El tester sabe la estructura
y la lógica interna del programa, como un mecánico de carros saber sobre el funcionamiento
interno de un automóvil. Ejemplos más específicos en esta categoría incluye analisis de
rutas base, declaraciones de cobertura (statement coverage), rama de cobertura,
condiciones de cobertura y ramas/condiciones de cobertura. 

Una ventaja de la prueba de la caja blanca es que es exhaustivo y se centra en el código

producido. Por que hay conocimiento de la estructura y lógica interna, errores o errores
deliberados por parte del programador tiene una alta probabilidad de ser detectados.
Una desventaja de la prueba de la caja blanca es que no verifica que las especificaciones
entén correctas, esto es, se centra sólo en la lógica interna y eso no verifica la conformación
de la lógica de las especificaciones. Otra desvnetaja es que no hay manera de detectar rutas
perdidas y errores en los datos.

Prueba de la caja gris. (Funcional y Estructural)

La prueba de la caja gris es una combinación de la prueba de la caja blanca y negra. El
tester estudia las especificaciones de requerimientos y se comunica con el desarrollador
para comprender la estructura interna del sistema. La motivación es despejar
especificaciones ambiguas y "leer entre lineas" para diseñar una prueba amplia. Un ejemplo
del uso de la prueba de la caja gris es cuando aparece al tester una cierta funcionalidad
parece ser reutilizada en una aplicación. Si el tester se comunica con el desarrollador y
comprende el diseño y arquitectura interna, algunas pruebas pueden ser eliminadas, por
que puede ser posible probar la funcionalidad sólo una vez. 

Manual contra puebas automatizadas

La base de la categorización de la prueba manual es que no es tipicamente llevada por
personas y no es implementada en una computadora. Ejemplos incluyen recorridos
estructurados, inspecciones, JADs, y prueba de escritorio. La base de la categorización de la
prueba automatizada es que es implementada en una computadora. Ejemplos incluyen la
prueba de limites de valores, prueba de rama de covertura, prototipos y prueba de sintaxis.
La prueba de sintaxis es realizada con un lenguaje de compilador, y el compilador es un
programa que se ejecuta en una computadora.

Prueba estática contra prueba dinámica.

Los enfoques de la prueba estática, son independientes al tiempo y son clasificados de esta
manera porque no necesariamente involucran ninguna ejecución manual o automatizada del
producto que se está probando. Ejemplos incluyen la prueba de sintáxis, recorridos
estructurados e inspecciones. Una inspección de una programa ocurre en  una lista de
codigo fuente en donde cada lina de codigo es leída linea por linea y se discute. Un ejemplo
de  pruebas estaticas usando la computadora es la herramienta de analisis de flujo estatico,
donde se investiga otro programa para errores sin ejecutar el programa. Eso analiza el otro
control de programa y flujo de datos para descubrir problemas como referencia a una
variable que no ha sido inicializada, y código inalcanzable.

Las técnicas de pruebas dinámicas son dependientes del tiempo e involucran ejecutar una
secuencia especifica de instrucciones en papel o en la computadora. Ejemplos incluyen
recorridos estructurados, en cada logica de programa es simulada por caminos atraves del
codigo y descrito verbalmente. La prueba de limites es una tecnica de prueba dinámica que
requiere la ejecución de casos de prueba en la computadora centrandose en especificaciones
en los límites de valores asociados con las entradas y salidas de datos del programa.

Taxonomia del software y técnicas de prueba

Una técnica de prueba es un conjunto de procedimientos interrelacionados, que juntos
producen una prueba de entrega.

Numeración Nombre de la prueba. Explicación.

01 prueba de aceptación prueba final basada en las
especificaciones del
usuario-final/cliente, sobre
un periodo definido de
tiempo.
02 prueba ad hoc Similar a la prueba de
exploración, tomando un
significado para el tester para
entender el software antes
de probarlo.
03 prueba de la caja negra Casos de prueba generados
en base a la funcionalidad del
sistema.
04 prueba bottom-up Ingración de modulos o
programacinas iniciando
desde el fondo.
05 prueba de comparacion Comparando las debilidades
y fortalezas del software con
otros productos.
06 CRUD Crear una matriz CRUD y
probar todos los objetos
(Create, Read, Update y
Delete)
07 prueba de base de datos Probar la integridad de los
valores de los campos de la
base de datos.
08 Prueba de escritorio Desarrolladores revisan
código con exactitud.
09 Patición de equivalencia Cada condición de entrada es
particionada en dos o más
grupos. Son representados
por casos válidos e inválidos.
10 JADs Técnica que brinda a los
usuarios y desarrolladores en
conjunto para diseñar un
sistema en facilidad de
sesiones.
11 Prototipos enfoque general de datos
desde usuario creando y
demostrandose alguna parte
de alguna aplicacion
potencial.
12 Prueba sandwich Módulos de integración o
programas desde el arriba
hasta el fondo
simultáneamente.
13 Recorridos estructurados conduce a cuales
participantes del proyecto
deben examinar un producto
para encontrar errores.
14 Prueba de la caja blanca Casos de prueba son
definidos examinando la
lógica de las rutas del
sistema.