UNIVERSIDAD DE CARTAGENA

CENTRO TUTORIAL CARMEN DE BOLÍVAR

PROGRAMA DE INGENIERÍA DE SISTEMAS

ASIGNATURA: INGENIERIA DE SOFTWARE

TEMA: TIPOS DE PRUEBAS DE SOFTWARE

ESTUDIANTES:

JAVIER MORENO

ANDRES BAÑOS

SANTIAGO GONZALEZ

TUTOR(A): JUAN CARLOS CUESTA

23-05-2014
 TIPOS DE PRUEBAS DE SOFTWARE

Prueba Unitaria

Objetivo de la Prueba: Se focaliza en ejecutar cada módulo (o unidad mínima

a ser probada, ej. = una clase) lo que provee un mejor modo de manejar la
integración de las unidades en componentes mayores.
Busca asegurar que el código funciona de acuerdo con las especificaciones y
que el módulo lógico es válido.
Descripción de la Prueba:
 Particional los módulos en pruebas en unidades lógicas fáciles de
probar.
 Por cada unidad hay que definir los casos de prueba (pruebas de caja
blanca).
 Para esto los casos de prueba deben diseñarse de forma tal que se
recorran todos los caminos de ejecución posibles dentro del código
bajo prueba; por lo tanto el diseñador debe construirlos con acceso al
código fuente de la unidad a probar.
 Los aspectos a considerar son los siguientes: Rutinas de excepción,
Rutinas de error, Manejo de parámetros, Validaciones, Valores válidos,
Valores límites, Rangos, Mensajes posibles.
Técnica: Comparar el resultado esperado con el resultado obtenido.
 Si existen errores, reportarlos.
Criterio de Completitud: Todas las pruebas planeadas han sido ejecutadas.
 Todos los defectos que se identificaron han sido tenidos en cuenta.
Consideraciones Especiales: Para la elaboración de pruebas unitarias

Prueba de Regresión

Identificar errores introducidos por la combinación de programas probados

unitariamente.

Determina cómo la base de datos de prueba será cargada

Utilizar la técnica Down-top.

Pruebas de Humo

 Detectar los errores en raleases tempranos y de manera fácil

 su objetivo es probar el sistema constantemente buscando que saque

“humo”

 Realizar una integración de todo el sistema cada cierto periodo (se

recomienda un día, máximo una semana)

Pruebas del Sistema

  Asegurar la apropiada navegación dentro del sistema, ingreso de datos,
procesamiento y recuperación.

 deben enfocarse en requisitos que puedan ser tomados directamente de

casos de uso y reglas y funciones de negocios

 Ejecute cada caso de uso, flujo básico o función utilizando datos válidos
e inválidos

Pruebas de Stress

 Verificar que el sistema funciona apropiadamente y sin errores

 Las pruebas de stress se proponen encontrar errores debidos a recursos

bajos o completitud de recursos

 Use los scripts utilizados en las pruebas de desempeño

Pruebas de desempeño

 Validar el tiempo de respuesta para las transacciones

 miden tiempos de respuesta, índices de procesamiento de transacciones

y otros requisitos sensibles al tiempo

 Modifique archivos de datos (para incrementar el número de

transacciones) o los scripts para incrementar el número de veces que
ocurre cada transacción

Pruebas de volumen

 Verificar el tamaño de la BD, el equipo si es suficiente etc.

 Las pruebas de volumen hacen referencia a grandes cantidades de

datos para determinar los límites en que se causa que el Sistema falle

 Deben usarse múltiples clientes, ya sea corriendo las mismas pruebas o

pruebas complementarias para producir el peor caso de volumen

Pruebas de Recuperación y Tolerancia a fallas

 Verificar que los procesos de recuperación (manual o automática)

restauran apropiadamente la Base de datos

 Estas pruebas aseguran que una aplicación o sistema se recupere de

una variedad de anomalías de hardware, software o red con pérdidas de
datos o fallas de integridad.

 Se deben utilizar las pruebas creadas para la Funcionalidad del sistema

y Procesos de Negocios para crear una serie de transacciones
Prueba de Múltiples Sitios

 Detectar fallas en configuraciones y comunicaciones de datos entre

múltiples sitios

 El propósito de esta prueba es evaluar el correcto funcionamiento del

sistema o subsistema en múltiples instalaciones.

 Consistencia, empaquetamiento, sincronización

Prueba de Compatibilidad y Conversión

 Buscar problemas de compatibilidad y conversión en los sistemas

 El propósito es demostrar que los objetivos de compatibilidad no han

sido logrados y que los procedimientos de conversión no funcionan.

 Compatibilidad entre programas y Conversión de datos

Pruebas de Integridad de Datos y Base de Datos

 Asegurar que los métodos de acceso y procesos funcionan

adecuadamente y sin ocasionar corrupción de datos.

 La Base de datos y los procesos de Base de datos deben ser probados

como sistemas separados del proyecto

 Invoque cada método de acceso y proceso de la Base de datos,

utilizando en cada uno datos válidos e inválidos. Analizar la BD

Pruebas de Seguridad y Control de Acceso

 Nivel de seguridad de la aplicación: Verifica que un actor solo pueda

acceder a las funciones y datos que su usuario tiene permitido

 Seguridad del sistema, incluyendo acceso a datos o Funciones de

negocios e incluyendo accesos remotos

 Funciones / Seguridad de Datos: Identificar cada tipo de usuario y las

funciones y datos a los que se debe autorizar.

Pruebas del Ciclo del Negocio

 Asegurar que el sistema funciona de acuerdo con el modelo de negocios

emulando todos los eventos en el tiempo y en función del tiempo.

 deberían emular las actividades ejecutadas en el a través del tiempo.

Debería identificarse un periodo, como por ejemplo un año, y las
transacciones y actividades que podrían ocurrir durante un periodo
  Ejecute cada caso de uso, flujo básico o función utilizando datos válidos
e inválidos…

Pruebas de GUI

 La navegación , Los objetos de la ventana y características, tales como

menús, medidas, posiciones, estados y focos

 La prueba de interfaz de usuario verifica la interacción del usuario con el

software

 Pruebas de crear / modificar cada ventana para verificar la adecuada

navegación y estado de los objetos.

Pruebas de Configuración

 Validar y verificar que el cliente del sistema funciona apropiadamente en

las estaciones de trabajo recomendadas.

 Estas pruebas verifican la operación del sistema en diferentes

configuraciones de hardware y software

 Incluya la apertura o cierre de varias aplicaciones Microsoft, como Excel

y Word (o algun tipo de software similar a la que se esta probando )

Prueba de Estilo

 Comprobar que la aplicación sigue los estándares de estilo propios del

cliente.

 Se entienden como tales el formato de las ventanas, colores

corporativos, tipos de letra etc.

 Se realiza una navegación por la aplicación verificando si se cumplen

con los estándares de GUI del cliente.

Prueba de Aceptación

 Determinación por parte del cliente de la aceptación o rechazo del

sistema desarrollado.

 La prueba de aceptación es ejecutada antes de que la aplicación sea

instalada dentro de un ambiente de producción

 Realización de los documentos de planes de prueba de aceptación y

especificación de los mismos, basados en los criterios de aceptación del
cliente.

Prueba de Instalación
  Verificar y validar que el sistema se instala apropiadamente en cada
cliente, bajo las siguientes condiciones: Instalaciones nuevas y
actualizaciones

 El primero es asegurar que el sistema puede ser instalado en todas las

configuraciones posibles .El segundo propósito verificar que, una vez
instalado, el sistema opera correctamente.

 Diseñar scripts para validar las condiciones de la máquina a instalar.

Prueba de Documentación Y Procedimiento

 Evaluar la documentación del usuario

 Evaluar la exactitud y claridad de la documentación del usuario y para

determinar si el manual de procedimientos trabajará correctamente
como una parte integral del sistema.

 Revisar la documentación del proyecto contra las funcionalidades del

sistema y su configuración física.

Pruebas Funcionales

 Se asegura la trabajo apropiado de los requisitos funcionales, incluyendo

la navegación, entrada de datos, procesamiento y obtención de
resultados

 Las pruebas Funcionales deben enfocarse en los requisitos funcionales

Diseñar scripts para validar las condiciones de la máquina a instalar

 Que los resultados esperados ocurran cuando se usen datos válidos.

Prueba de Usabilidad

 Determinar la usabilidad del sistema.

 Determina cuán bien el usuario podrá usar y entender la aplicación.

Identifica las áreas de diseño que hacen al sistema de difícil uso para el
usuario.

 Verificar que la aplicación no presenta los siguientes problemas de

usabilidad típicos: sistema es demasiado complejo, recuperación de
errores es pobre, procedimientos no son simples ni obvios.

Prueba de Campo

 Correr el sistema en el ambiente real para encontrar errores y validar el

producto contra sus especificaciones originales.

 Realizar un subconjunto válido de pruebas de sistema.

  Determinar que pruebas de sistema serán corridas para validar el
sistema en producción.

Pruebas Alfa

 Prueba de aceptación para detectar errores en el sistema bajo un

ambiente controlado.

 La verificación involucra la ejecución de partes o todo del sistema en

ambientes simulados, con el fin de encontrar errores.

 Realizar las pruebas de sistema bajo las siguientes características:

Se llevan a cabo en el lugar en donde fue desarrollado el sistema.

Pruebas Beta

 Realizar la validación del sistema por parte del usuario.

 Prueba de aceptación donde La validación (o pruebas beta) involucra el

uso del software en un ambiente real.

 Se selecciona un grupo de usuarios que ponen a trabajar el sistema en

un ambiente real. Usan el sistema en sus actividades cotidianas,
procesan transacciones y producen salidas normales del sistema.

MÉTODOS DE PRUEBA DE CAJA NEGRA

Las pruebas de caja negra, muchas veces son llamadas pruebas funcionales,
tratan el sistema bajo prueba como una caja negra. Las pruebas son
desarrolladas sin ningún tipo de suposición acerca de la estructura interna del
sistema bajo prueba. Ellos evalúan el comportamiento puro de entrada y salida
del sistema bajo prueba. Típicamente, un conjunto de casos de prueba es
definido para cada función del sistema bajo prueba, enfocándose sobre las
diferentes salidas que la función debe producir.
Los métodos más conocidos para el desarrollo sistemático de pruebas de caja
negra son la particiones de clases de equivalencia y el análisis de valores
límite.
Para las particiones de clases de equivalencia, el dominio de cada parámetro
de entrada de una función es estructurada en clases de equivalencia. Para los
valores en una clase de equivalencia, es asumido que la función los trata de la
misma manera, y por lo tanto, solo un representante de cada clase de
equivalencia necesita ser probado.
El análisis de valores de frontera es muchas veces usado en combinación con
la partición de clases de equivalencia. En este método, los casos de prueba
desarrollados por las particiones de clases de equivalencia son
complementadas por los casos de prueba que prueban la frontera de las clases
de equivalencia, porque los errores de programación típico, como por ejemplo,
la terminación equivocada de bucles, están muchas veces relacionados a estas
fronteras.

En otras palabras, los casos de uso y los métodos identifican los conjuntos de
casos de pruebas que deben ser desarrollados para lograr la cobertura
funcional del sistema. Para ayudar a la identificación de las clases de
equivalencia, pueden ser usadas las especificaciones de los casos de uso y los
métodos de, por ejemplo, los diagramas de secuencia o diagrama de
actividades. El flujo especificado de control estas muchas veces relacionado a
las clases de equivalencia.

Variantes de pruebas de caja negra.

• a) Métodos de prueba basados en grafos.

• b) Partición Equivalente.
• c) Análisis de valores límite.
• d) Prueba de Comparación.
• e) Conjetura de Errores.

Métodos de prueba basados en grafos

Pasos a seguir para una prueba de caja Negra:

1. Entender los objetos que se van a modelar y las relaciones que

conectan a estos.
2. Definir una serie de pruebas que verifique que “todos los objetos
tienen entre ellos la relaciones esperadas”

Partición equivalente
Pasos para identificar clases de equivalencia.
1. Identificación de las condiciones de entrada del programa.
2. Identificar las clases de equivalencia:
a) Datos válidos.
b) Datos no válidos.

Partición equivalente
Pasos para identificar casos de prueba.
1. Asignar un número único para cada clase de equivalencia.
2. Escribir casos de pruebas para todas las clases válidas.
3. Escribir casos de pruebas para todas las clases no válidas.

Ejemplo de clases de equivalencia

Aplicación bancaria en la que el operador debe proporcionar un código, un
nombre y una operación.
Condición de Entrada Clases Válidas Clases Inválidas

Código de Área 1) 200≤ código ≤ 999 2) Código < 200.

# de 3 dígitos que no 3) Código > 999.
empieza con 0 ni 1: 4) No es número.

Nombre 5) Seis caracteres. 6) Menos de 6

Para identificar la caracteres.
operación 7) Más de 6 caracteres.

Orden 8) “Cheque” 12) Ninguna orden

Una de las Siguientes 9) “Depósito” válida
10) “Pago factura”
11)“Retiro de fondos”

Análisis de valores limite

Las reglas para identificar las clases son:
1. Si una condición de entrada especifica un rango que deben
generar casos para los extremos.
2. Si la condición de entrada especifica un número finito y
consecutivo de valores, escribir casos para los números máximo,
mínimo, uno más del máximo y uno menos del mínimo de valores
3. Usar la regla 1 para la condición de salida.
4. Usar la regla 2 para cada condición de salida.

Prueba de Comparación
 Se desarrollan versiones independientes de una aplicación con las
mismas especificaciones.
 Probar todas las versiones con los mismos datos de prueba.
 Luego se ejecutan las versiones en paralelo y se hace una comparación
en tiempo real de los resultados.

Conjetura de Errores
 Enumerar una lista de equivocaciones que pueden cometer los
desarrolladores.
 Generar casos de prueba en base a dicha lista.
 La generación de casos se obtiene en base a la intuición o la
experiencia.

MÉTODOS DE PRUEBA DE CAJA BLANCA

Las pruebas de caja blanca hacen uso de la estructura interna del sistema bajo
prueba, es decir, tratan el sistema bajo prueba como una caja de cristal.
Los casos de prueba son desarrollados usando criterios de cobertura para el
código del programa.
Los criterios típicos de cobertura son sentencias, ramas, y rutas de cobertura.
Los demás criterios de cobertura se relacionan al uso de las variables en el
flujo del programa y las condiciones que determina las ramas y la terminación
de bucles.
Los criterios de cobertura también son usados para derivar los casos de prueba
a partir de modelos UML. Por ejemplo, los criterios de cobertura de estado y
transición, pueden ser usados para definir un conjunto satisfactorio de casos de
pruebas para las maquinas de estados, describiendo el comportamiento de una
clase. Los criterios de cobertura pueden también ser usados para definir los
casos de prueba para diagramas de secuencia, diagramas de actividad, y
diagramas de interacción.
Hasta este punto hemos abordado cómo son tratadas las pruebas de software
convencional. De aquí en adelante nos centraremos en las aplicaciones
Web, donde la navegabilidad es su característica por naturaleza. Si bien es
cierto, el desarrollo de aplicaciones Web tiene varias propuestas metodológicas
que tienen una robustez reconocida, la Ingeniera Web ha puesto atención en el
desarrollo de aplicaciones Web basada en modelos. En el siguiente apartado,
presentaremos sus características principales, finalizando con el tratamiento de
las pruebas de software aplicando este nuevo paradigma.