Fase que le permite al analista detectar errores de

codificación, estructura lógica y funcionabilidad con la

ayuda del usuario y personal técnico externo al grupo que
participa en el desarrollo.

Las pruebas se deben realizar con malicia, es decir,

buscar que el sistema falle con el propósito de que el
sistema sea implantado cumpliendo el 100% de
operatividad.
 Este autor establece que el analista debe utilizar
estrategias, tipos, métodos y clases de pruebas que le
faciliten su trabajo.

Estrategias: Existen dos estrategias que le permiten

detectar errores de codificación y funcionabilidad.

1.Estrategia Caja Negra: Con ayuda del usuario el analista

detecta errores de funcionabilidad sin importarle la
codificación del mismo.
2.Estrategia Caja de Cristal: El analista con el personal
técnico interno o externo al desarrollo detecta errores de
codificación sin importarle la funcionabilidad del sistema.
 • De arriba a hacia abajo (descendente), se prueba el
sistema comenzando con el módulo principal hasta
llegar al módulo más sencillo, es decir, que de él no
depende nadie; por ejemplo:

Sistema de ventas - x

Agregar - x
Productos - x
Agregar Código: xxx
Consultar
Modificar
Nombre:
Eliminar
Facturar
Cantidad:
Cerrar Precio:

Aplicaciones
• De abajo hacia arriba (ascendente), se prueba el sistema
comenzando por la aplicación mas sencilla hasta llegar al
módulo principal.

• Método Total: Se aplica utilizando los dos métodos

descritos anteriormente, es decir, se comienza por el
método descendente y luego el ascendente y viceversa.
• Prueba unitaria: Es aquella que le permite al analista
detectar errores de codificación y funcionabilidad de
forma independiente, es decir, módulos o cada una de
las aplicaciones que conforman el sistema sin importar la
relación que existe entre esos módulos o aplicaciones.

• Pruebas de integración: Le permite al analista detectar

errores de codificación y estructura lógica, así como
también de funcionabilidad. Con el propósito de
visualizar si los módulos se están relacionando entre si
con sus diferentes aplicaciones entre si o con otros
módulos. Por ejemplo: (El mcedula producto), cuando
agregamos un producto la relación sería la consulta.
Módulo a módulo, cuando agregamos un producto y
luego se va a reporte para generar el mismo.
• Prueba de sistema: Se detectan solamente errores de
codificación y compatibilidad entre los componentes. Por
ejemplo: Entre los componentes y el sistema (pantallas).
Control de asistencia por huellas dactilares.

• Pruebas funcionales: Le permiten al analista detectar

errores de operativilidad y seguridad. Por ejemplo:
Ingreso de claves de seguridad.

• Aceptación técnica: Le permite al analista detectar

errores de codificación, estructura lógica y funcionales
con la ayuda de personal técnico externo al grupo de
desarrollo.
• Aceptación funcional: Permite detectar errores
funcionales, con la ayuda de los usuarios finales.

• Pruebas de instalación: Permite detectar errores de

compatibilidad entre hardware y software y sobre todo
en el acontecimiento del espacio físico (puntos de redes).
1. Pruebas de programa con datos ficticios: Son las misma
clases de pruebas unitarias de Fábregas pero se utilizan
datos ficticios.

2. Prueba de enlace con datos de pruebas: Es la misma clase de

prueba de integración de Fábregas pero se utilizan datos
ficticios. A su vez se usan errores de enlace de
comunicaciones. Por ejemplo: Servidor a servidor.

3. Prueba completa de sistema con datos: Prueba también

conocida como pruebas ALFA, donde se escoge un grupo
pequeño de usuarios para que prueben el sistema con datos
ficticios.
4. Pruebas completas de sistema con datos reales: También
conocidas como pruebas BETA, se toma la totalidad de
usuarios para que utilicen el sistema bajo periodo de prueba
con datos reales con el propósito de detectar errores de
seguridad y de ejecución del sistema. Po ejemplo: La versión
de Windows en estado BETA.
I parte:

1. Niveles de seguridad: Le permite al analista validar, verificar

y certificar todas las aplicaciones y módulos del sistema con
la ayuda del usuario y grupo de desarrollo.
2. Verificación: Este tipo de prueba se detectan errores de
estructura lógicas y aritméticas. Por ejemplo: El ingreso de
la clave, solicitud de cantidades, ingreso de códigos de
productos, entre otros.
3. Validación: Valida las entradas y salidas de los datos del
sistema. Por ejemplo: Bloqueo de la tarjeta luego de 3
intentos.
4. Certificación: Es realizado por el usuario quien establece si
cumple o no con sus necesidades.
II parte:

1. Estrategias de pruebas: Se dividen en dos tipos:

• De codificación: Es la misma estrategia de la caja de cristal.
• De especificación: Es la misma estrategia de la caja negra.

III Parte: Niveles de pruebas

1. Pruebas parciales: Son los métodos ascendentes y

descendentes.
2. Pruebas de sistema: Este tipo de prueba se realiza con la ayuda
de simuladores, ya que el sistema se prueba de la siguiente
manera y a través de las siguientes pruebas al sistema:
a. Pruebas de carga máxima: Consiste en que el sistema funcione
al 100%, es decir, se ejecuten diferentes procesos al mismo
tiempo con el fin de determinar si el sistema es capaz de
soportar situaciones extremas. Por ejemplo: De varios
terminales al mismo tiempo.
b. Pruebas de ejecución: Permiten detectar los tiempos de cada
una de las ejecuciones con el propósito de establecer si el
sistema es eficaz.
c. Pruebas de almacenamiento: Con ayuda de un simulador se
determina si la capacidad de almacenamiento fue la
establecida.
d. Prueba de factores humanos: Con este tipo de pruebas se
detecta los posibles errores que pueden cometer los usuarios al
momento de ingresar o ejecutar alguna aplicación.
e. Pruebas de documentación: Con este tipo de pruebas se
determina si el nivel de ayuda ofrecida por los manuales de
usuario y el módulo de ayuda ubicado en la pagina principal
satisface o no a los usuarios.
f. Pruebas de recuperación: Estos tipos de pruebas permiten
determinar si el sistema es capaz de recuperar información por
fallos eléctricos o fallas humanas.
 Pruebas de entorno especializados, arquitectura y aplicación.

• Interfaz gráfica: Este tipo de pruebas detecta errores

relacionado con el diseño de pantallas que utiliza el usuario
para interactuar con el sistema, razón por la cual dentro del
grupo de desarrollo se encuentra el diseñador grafico quien se
encarga de esta tarea.
• Cliente-Servidor: Detecta errores de conexión entre cliente y
diferentes servidores con el propósito de establecer si la
conexión es correcta.
• Prueba de documentación y ayuda: Se utiliza para detectar
errores con la ayuda de los usuarios quienes sin los manuales y
el módulo de ayuda cumplen con las necesidades y sobre todo
orientan al manejo del sistema.
• Prueba de sistema de tiempo real: Se utiliza para detectar
errores de ejecución y sobre todo del tiempo de respuesta de
cada una de las actividades o aplicaciones ejecutada en el
mismo. Se divide en:

 Tarea: También conocida como prueba de aplicación la cual se

realiza para detectar errores en cada una de las tarea que
efectuara el usuario. Por ejemplo: Módulo producto  agregar,
consultar, eliminar, entre otros.
 Prueba de comportamiento: Aquella que permite determinar si
la aplicación o módulo se ejecuta según la analizada y diseñada.
Por ejemplo: Generar reportes diarios o semanales.
 Pruebas de intertarea: Se utiliza para detectar errores dentro
de aplicaciones, como por ejemplo: Consultas- se puede
realizar por código o por nombre.