Universidad de San Martín de Porres

Facultad de Ingeniería y Arquitectura

Diseño e Implementación de Sistemas

Disciplina de Pruebas
Sesión: 10

Ing. Géner Zambrano L.

gzambrano@usmp.edu.pe
Ing. Hector Henriquez T.
hhenriquez@usmp.edu.pe

Semestre: 2010_I
 Objetivos:

¾ Comprender de que tratan las pruebas en la aplicación

y su entorno
¾ Conocer la disciplina de Pruebas
¾ Conocer las pruebas de los componentes del sistema
para su puesta en marcha.
¾ Roles, actividades y artefactos
¾ Conocer los tipos de pruebas

2
 Visión global de desarrollo de sistemas

Puesta en productivo
y Mantenimiento
Análisis

Diseño

Conversión

Pruebas
Programación

Características:
1. Generalmente se llevan a cabo secuencialmente pero esto puede variar
de acuerdo al Enfoque de Construcción de Sistemas seleccionado.
2. Cada actividad requiere interacción con la organización.
 Visión global de desarrollo de sistemas, continua...

Análisis
Análisis Diseño
Diseño Programación
Programación Prueba
Prueba Conversión
Conversión Producción
Producción

Definición del - Si se trata de -Si se trata de un Comprobación Implantar el Monitoreo del

problema, realizar el nuevo desarrollo: del funcionam. nuevo sistema. sistema para
identificación de desarrollo: Codificación del del sistema: detectar:
la solución, Diseño lógico y sistema. - Pruebas Estrategias - Errores
análisis de Físico. unitarias posibles: - Modificaciones
factibilidad, - Prueba de - Paralela - Mejoras
estimación de - Si se trata de - Si se trata de Sistemas - Cambio Directo
esfuerzo, adquisición adquisición de - Pruebas de - Estudio Piloto
recursos y de sistema sistema Aceptación de - Por Fases
duración, existente: existente: Usuario.
identif. de identificación configuración y
riesgos y de las partes a parametrización Otras Clases de
especificación customizar y del sistema. pruebas.
de adaptaciones a
requerimientos. realizar Capacitaciones

Responde a Responde a
QUE COMO

Usuario activo Usuario activo Usuario activo Usuario activo

 Visión global de desarrollo de sistemas, continua...

Ciclo de Vida Tradicional

Definición
Definición Análisis
Análisis Diseño
Diseño Programación
Programación Instalación
Instalación Post-
Post-
Implementación
Implementación
Foco puesto en Foco puesto Foco en la Cierre del
Foco puesto Uso y evaluación
la definición del en la traducción del Sistema:
en elaboración del Sistema para
objetivo, definición de diseño a código y Pruebas de
de los determinar las
alcance, la arquitectura, en la ejecución Aceptación de
requerimientos Usuario, necesidades de
factibilidad del el diseño de pruebas
planteados en Capacitación y adaptación.
proyecto, la lógico y unitarias y de
la etapa Conversión.
estimación de físico Sistemas.
anterior, y en
esfuerzo, la planificación
recursos y
detallada de
duración,
las dos fases
restricciones y
siguientes.
riesgos.

Plan de Especif. Req. Especificación Código Fuente Manuales, Incidentes y

Proyecto Plan Pruebas de Diseño y Objeto Informe Prueba Nuevos Req.

Líder , Analista Analista Analista Programador y Usuario y Usuario y

Funcional, Funcional, Funcional y Analistas Analistas Analistas
Usuario Usuario Técnico
 Pruebas, conceptos:

‰ Prueba del Software:

Proceso en el que se ejecuta un programa con el objetivo
de detectar fallos (o errores).
‰ Un fallo es provocado por un Defecto.

‰ Depuración: proceso en el que:

9 se localiza el defecto que es la causa de un fallo,
9 se determina la forma de corregirlo,
9 se evalúa el efecto de la corrección y
9 se lleva a cabo la corrección

6
 Pruebas, objetivos:

• La prueba es un proceso de ejecución de un programa con la

intención de descubrir un error.

• Un buen caso de prueba es aquel que tiene una alta probabilidad

de mostrar un error no descubierto hasta entonces.

• Una prueba tiene éxito si descubre un error no detectado hasta

entonces.

“La prueba no puede asegurar la ausencia de defectos, sólo

puede demostrar que existen defectos en el software”.
 Pruebas, objetivos; continua...

Es la verificación dinámica del comportamiento de un programa en

un conjunto finito de casos, respecto al comportamiento esperado,

Objetivos:
9 Evaluar la calidad del producto
9 Mejorarlo identificando defectos y problemas
9 Probar que el sistema funciona
9 Probar que el sistema no funciona
9 Reducir los riesgos a un nivel conocido
9 Diseñar, documentar y mantener, teniendo en cuenta las tareas
de testing

8
 Pruebas, principio:

‰ Principio de Pareto aplicado a la Prueba:

“El 80% de los defectos descubiertos durante las pruebas surgen
al hacer un seguimiento del 20% de todos los módulos del
programa”.
Entonces:
Conviene aislar módulos sospechosos y
probarlos concienzudamente.

‰ Si las pruebas las realiza alguien ajeno a la implementación,

serán más efectivas.
‰ La prueba se puede llevar hasta el 50 o 60% del esfuerzo
dedicado al proyecto es muy importante seleccionar bien las
pruebas que se van a realizar.
9
 Pruebas - políticas:

¾ El objetivo es descubrir defectos en el software que provocan un

comportamiento incorrecto o en desacuerdo con su
especificación.
¾ Una prueba con éxito es aquella que hace que el sistema
funcione de forma incorrecta y por lo tanto ponga de manifiesto
un defecto en el sistema.
¾ Solamente las pruebas exhaustivas pueden demostrar que un
programa no tiene defectos. Sin embargo es imposible realizar
pruebas exhaustivas

10
 Pruebas - políticas, continua...

¾ Las políticas de pruebas definen la aproximación a utilizar para

seleccionar pruebas de sistemas:
‰ Deberían probarse todas las funciones accedidas desde
menús,
‰ Deberían probarse todas las funciones accedidas a través del
mismo menú,
‰ Deberían probarse todas las funciones que requieran
entradas, con datos correctos e incorrectos,
‰ Repetir las pruebas después de cada modificación,
documentar,
‰ Conservar y actualizar los programas de pruebas,
‰ Usar herramientas de ejecución automática de las pruebas. 11
 Pruebas – enfoque:

Se han propuesto varias estrategias de prueba del software; pero

todas proporcionan al desarrollador del software una plantilla para
pruebas y todas tienen las mismas caracteristicas.
 Pruebas – estrategia:

1. Para realizar pruebas efectivas un equipo de software debe efectuar

revisiones tecnicas formales y efectivas. Esto eliminara muchos
errores antes de que empiece la prueba.
2. La prueba comienza al nivel de componentes y trabaja “hacia fuera”,
hacia la integraciòn de todo el sistema de computo.
3. Diferentes tecnicas de pruebas son apropiadas en diferentes momentos.

4. La prueba la dirige el desarrollador del software y (en el caso de

proyectos grandes) un grupo independiente de pruebas.
5. La prueba y la depuración son actividades diferentes, pero la segunda
debe incluirse en cualquier estrategia de prueba.
 Estrategias de prueba del software - Niveles de prueba

Requisitos Pruebas de
del usuario Aceptación

Especificación de Pruebas de
requisitos sistema

Diseño modular Pruebas de

integración

Especificación Pruebas de
lógica del módulo unidad

Código 14
I. Pruebas de unidades
II. Pruebas de integración
III.Pruebas de validación

15
 Causas principales de la baja calidad del software

• Probar Software es muy difícil.

• Cambios en los requerimientos.

• Falta de un proceso sistemático de

pruebas.

• Mala comunicación entre miembros

del equipo.
 Verificación continua de la calidad

Es de 100 a 1000 veces más costoso encontrar y reparar

los problemas del software después del desarrollo

Š Costo de reparar el software.

Š Costo de perder oportunidades.
Costo Š Costo de perder clientes

Concepción Elaboración Construcción Transición

 Tipos de Pruebas:

Esta disciplina actúa como un proveedor de servicios a las otras disciplinas

en muchos aspectos. La disciplina Pruebas se enfoca principalmente en la
evaluación y aseguramiento de la calidad del producto.

Doc. Requisitos
Análisis
P. validación
Diseño
P. integración
Doc. Diseño
Codificación P. unidades

Cod. Módulos
Integración

Cód. Completo 18
Mantenimiento
 I. Pruebas de unidades

• La prueba de unidad centra el proceso de verificación en la

menor unidad del diseño del software: un módulo.
• Usando la descripción del diseño procedimental como guía, se
prueban los caminos de control importantes, con el fin de
descubrir errores dentro del límite del módulo.
• La prueba de unidad está orientada a caja blanca y este paso se
puede llevar a cabo en paralelo para múltiples módulos.
 I. Pruebas de unidades – caja blanca

• La prueba de caja blanca denominada a veces prueba de caja de

cristal es un método de diseño de casos de prueba que usa la
estructura de control del diseño procedimental para obtener los
casos de prueba.

• Se comprueban los caminos lógicos del software proponiendo

casos de prueba que ejerciten conjuntos específicos de
condiciones y/o bucles. Se puede examinar el estado del programa
en varios puntos para determinar si el estado real coincide con el
esperado.
 I. Pruebas de unidades – caja blanca, continua...

• Mediante los métodos de prueba de caja blanca, se puede obtener

casos de prueba que:
1. Garanticen que se ejercita por lo menos una vez todos los
caminos independientes de cada módulo.
2. Ejerciten todas las decisiones lógicas en sus vertientes
verdadera y falsa.
3. Ejecuten todos los bucles es sus límites y con sus límites
operacionales.
4. Ejerciten las estructuras internas de datos para asegurar su
validez.
 I. Pruebas de unidades – caja negra

• Se centran en los requisitos funcionales del software. Permite

obtener conjuntos de condiciones de entrada que ejerciten
completamente todos los requisitos funcionales de un programa,
es decir consideran la función para la cual fue creado el producto
(lo que hace).

• Se llevan a cabo sobre la interfaz del sistema reduciendo el

número de casos de prueba mediante la elección de entradas y
salidas válidas y no válidas que ejercitan toda la funcionalidad del
sistema.

• No es una alternativa a las técnicas de prueba de caja blanca, se

trata de un enfoque complementario que intenta descubrir
diferentes tipos de errores que los métodos de caja blanca no
contempla.
 I. Pruebas de unidades – caja negra, continua...

• La prueba de caja negra intenta encontrar errores de las

siguientes categorías:

9 Funciones incorrectas o ausentes.

9 Errores de interfaz.
9 Errores en estructuras de datos o en accesos a bases de datos
externas.
9 Errores de rendimiento.
9 Errores de inicialización y de terminación.
 I. Pruebas de unidades – caja negra, continua...

• Otras pruebas que se realizan son:

9 Pruebas de GUI (Interfaces Gráficas de Usuario).

9 Pruebas de Arquitectura Cliente/Servidor.

9 Pruebas de Documentación y Ayudas

 I. Pruebas de unidades, Walkthrough:

Walkthrough o visita guiada:

En este tipo de revisión se demuestra la funcionalidad del artefacto
revisado mediante la simulación de su funcionamiento con casos de
prueba y ejemplos. Se introducen al artefacto los casos de prueba y
se van registrando los resultados intermedios.

9 La realiza un grupo en el que al menos está el programador del

código fuente a revisar
9 Una persona ajena al código fuente prepara un conjunto de casos
de prueba.
9 Se ejecuta “mentalmente” en grupo el código para los casos de
prueba. Ejecución guiada por el programador del código.
9 Se plantean preguntas al programador del código.
25
 Desarrollo del testeo:

Comportamiento
esperado del
programa ok

Input ¿?

Comportamiento
obtenido del falla
programa
• Se puede ejecutar el programa
• Se conoce el resultado esperado
• Es posible comparar los resultados obtenidos con los esperados
• Además: ¿Cómo elegimos el input?
26
 Desarrollo del testeo:, continua...

• No se analiza la estructura interna del programa sino que la

selección de casos de prueba se concentra en:
– los datos de entrada y salida
– la especificación
• La especificación informal dificulta la correcta selección de
casos de prueba.
• Los casos de prueba que exploran las condiciones límite son
más efectivos, y son los que se hallan “arriba” y “debajo” de
los márgenes de las condiciones de entrada o de salida.
Lograr:
– Registrar todas las pruebas
– Registrar todas las fallas
– Relacionarlas con los casos que las provocan
27
 Desarrollo del testeo:, continua...

• Diremos que un caso de uso de prueba es un elemento del

dominio de inputs
• Un programa tiene infinitos posibles inputs
• Diremos que un conjunto de prueba es un conjunto finito de casos
de prueba
• Un criterio de selección es un predicado sobre el conjunto de
inputs. Por ejemplo: que define una clase de equivalencia
• Requerimientos de prueba:
– El propósito de la prueba, ¿qué quiero testear?
• Especificaciones de Test:
– Supuestos y definiciones que sirven para generar los casos de
prueba para los requerimientos de prueba

28
 II. Pruebas de Integración

Refiere a la construcción del sistema a partir de sus componentes y

probarlos para detectar problemas con la interacción entre los
componentes.
Integración Top-down
Desarrolla el esqueleto del sistema y se van añadiendo
componentes
Integración Bottom-up
Integra los componentes de infraestructura y añade
componentes funcionales
En esta etapa, ya suele estar disponible el manual de usuario, que
también se utiliza para realizar pruebas hasta lograr una cobertura
aceptable.
 II. Pruebas de Integración

El objetivo es tomar los módulos probados en

una unidad y construir una estructura de
programa que esté de acuerdo con lo que
establece el diseño.
Se comprueba la compatibilidad y funcionalidad
de los interfaces entre las distintas ‘partes’ que
componen un sistema, estas ‘partes’ pueden ser
módulos, aplicaciones individuales, aplicaciones
cliente/servidor, etc.
Comprenden verificaciones asociadas a grupos
de componentes. Tienen por objetivo verificar el
correcto ensamblaje entre los distintos
componentes.
 III. Pruebas de Validación

Verificación y validación, continua...

Verificación:
Implica probar el programa implementado para ver si funciona
conforme a las Especificaciones. Se trata de responder a la
pregunta:
¿Estamos construyendo el programa CORRECTAMENTE?

Validación:
Implica probar el programa implementado para ver si satisface las
necesidades del cliente. Se trata de responder a la pregunta:
¿Estamos construyendo el programa CORRECTO?

31
 III. Pruebas de Validación , continua...

Verificación y validación
¾ Objetivos de la verificación y validación (V&V):
9 Descubrir defectos en el sistema
9 Evaluar si el sistema funciona según las expectativas del
cliente
¾ La Verificación y validación forman parte del proceso de prueba
del software
¾ El proceso de prueba puede demostrar únicamente la presencia
de errores.
¾ El proceso de prueba no puede demostrar la ausencia de errores
en el software.

32
 III. Pruebas de Validación, continua...

Comprobar que se satisfacen los requisitos:

9 Se prueba el programa completo
9 Uno o varios casos de prueba por cada requisito o caso de uso
especificado
9 Se prueba también rendimiento, capacidad, etc. (y no sólo
resultados correctos)
Demostrar que tanto para el desarrollador como para el cliente
el software satisface sus requerimientos

33
 III. Pruebas de Validación, continua...

• Tras la culminación de la prueba de integración, el software está

completamente ensamblado como un paquete; se han encontrado
y corregido los errores de interfaz y puede comenzar una serie
final de pruebas del software: la prueba de validación.

• La validación se consigue cuando el software funciona de

acuerdo con las expectativas razonables del cliente.

• La validación del software se consigue mediante una serie de

pruebas de caja negra que demuestran la conformidad con los
requisitos.
 III. Pruebas de Validación, continua...

• Una vez que se procede con cada caso de prueba de validación,

puede darse una de las siguientes condiciones:

1. Las características de funcionamiento o de rendimiento están

de acuerdo con las especificaciones y son aceptables; o

2. Se descubre una desviación de las especificaciones se crea

una lista de deficiencias.
 III. Pruebas de Validación, continua...

• Cuando se construye software a medida para un cliente, se lleva a

cabo una serie de pruebas de aceptación para permitir que el
cliente valide todos los requisitos.

• Las realiza el usuario final en lugar del responsable del desarrollo

del sistema. La mayoría de los constructores de productos
software llevan a cabo un proceso denominado prueba alfa y beta
para descubrir errores que parezca que sólo el usuario final puede
descubrir.

• La prueba alfa se lleva a cabo en el lugar de desarrollo pero por

un cliente. Se usa el software de forma natural con el
desarrollador como observador del usuario y registrando los
errores y los problemas de uso. Las pruebas alfa se llevan a cabo
en un entorno controlado.
 III. Pruebas de Validación, continua...

• La prueba beta se lleva a cabo por los usuarios finales del

software en los lugares de trabajo de los clientes.

• A diferencia de la prueba alfa, normalmente el desarrollador no

está presente. Así, la prueba beta es una aplicación en vivo del
software en un entorno que no puede ser controlado por el
desarrollador. El cliente registra todos los problemas (reales o
imaginarios) que encuentra durante la prueba beta e informa a
intervalos regulares al desarrollador.

• Como resultado de los problemas informados durante la prueba, el

desarrollador del software lleva a cabo modificaciones y así
prepara una versión del producto de software para toda la clase de
clientes.
 Cada actividad incluye su verificación

Todo aquello que hagas, no lo habrás terminado, hasta que hayas

verificado que hiciste lo que debías de hacer.

Ejecución
Actividad

Acción Verificación
 Plan de actividades de aseguramiento de la calidad

Conjunto de actividades que serán ejecutadas para generar

confianza en que el producto cumplirá con los requerimientos y el
proceso es efectivo

Cliente Validaciones

Necesidades
Verificaciones

Requisitos Producto

Revisiones
 Establecer criterios y procedimientos de Verificación

CU_01_Login <<extend>>
usuario
(from <Use Case Name>) CU_1
(from

CU_17_Generar seguridad
CU_02_Apertura de Obra
(from <Use Case Name>)
(from <Use Case Name>)
CU_19_Registrar cliente
(from <Use Case Name>)

Requerimiento Personal
CU_03_Registrar Perso
(from <Use Case Name>)

Administrativo
09_Emitir orden de compra (f rom Actors)
(from <Use Case Name>)

Plantillas CU
CU_04_Registrar Per
CU_07_Registrar zona
(from <Use Case N
(from <Use Case Name>)

CU_14_Registar orden de compra

Ingeniero Residente
(from <Use Case Name>) CU_06
(f rom Actors) CU_10_Registrar subcontratista

Diagrama de análisis
(from <Use Case Name>) (from

Diagrama de caso de
uso

Codificación Diseño –
Componentes Diagrama de
secuencia
 Revisión de Pares
¿Qué es una Revisión?
Una revisión es una verificación grupal mediante la cual se
evalúan los entregables e indirectamente la salud del proyecto a
un nivel técnico y de estándares

ƒ ¿Refleja el entregable de forma precisa los entregables de las

fases previas?
ƒ ¿Se han aplicado todos los estándares apropiados?
ƒ ¿Se han cumplido los procedimientos y procesos estándar?
ƒ ¿Es el contenido técnicamente correcto?
 Revisión de Pares

ƒ Las revisiones de productos están diseñadas para detectar

defectos. ¿Qué es un defecto?

ƒ Cualquier error que pudiera causar un problema en la vida del

sistema

ƒ Una desviación de los resultados esperados

ƒ Un defecto mayor causará un malfuncionamiento del sistema

o resultados incorrectos

ƒ Un defecto menor no causará una mal función del sistema o

resultados incorrectos, pero podría causar otros problemas
 Revisión de Pares

El proceso de Revisión para todos los tipos tiene tres

sub-procesos con criterios definidos de entrada y
salida

Re-revisión
Criterios de Entrada

Criteria de Salida
Actividades Actividades
Pre- Actividad Post-
Revisión Revisión Revisión
Revisión de Pares

El criteria de entrada asegura que estamos listos para

la revisión

 Prerequisitos cumplidos,
retrabajo completo
 Autor siente que producto está
completo y correcto
 Alto nivel de documentación
disponible

Re- r eview

Pre- Revi ew Post -

Revi ew Act i vi t y Revi ew

Acti vi t y Act i vi t y
Ent ry Cri t eri a

Exi t Cri teri a

Revisión de Pares

El criteria de salida indica el criterio de término

 Todos los defectos identificados,

y problemas
registrados
 Se ha inspeccionado
entregable por
completo
 Re-trabajo se ha
completado
 Se ha tomado una decisión
de re-revisión
Re-r eview

Pre- Revi ew Post -

Revi ew Act i vi ty Revi ew

Act i vi t y Act i vi ty

Exi t Cri teri a

Entry Cri t eri a
Disciplina: Pruebas

46
Flujo de trabajo: Pruebas

47
 Disciplina: Pruebas, própositos:

Encontrar
Encontrar fallas
fallas de
de calidad
calidad en
en el
el
software
software yy documentarlas.
documentarlas.
Recomendar
Recomendar sobre
sobre la
la calidad
calidad percibida
percibida
en
en el
el software.
software.
Validar
Validar yy probar
probar las
las suposiciones
suposiciones
hechas
hechas durante
durante elel diseño
diseño yy lala
especificación
especificación dede requerimientos
requerimientos dede
forma
forma concreta.
concreta.
Validar
Validar que
que el
el software
software trabaja
trabaja como
como
fue
fue diseñado.
diseñado.
Validar
Validar que
que los
los requerimientos
requerimientos son
son
implementados
implementados apropiadamente.
apropiadamente. 48
 Flujo de trabajo: Definir la misión de la evaluación

El propósito de este flujo es identificar el foco apropiado del esfuerzo de

la prueba para la iteración, y obtener el acuerdo con los stakeholders sobre
las metas que dirigirán las prueba.

El valor principal en la ejecución

de este flujo es pensar a través de
las varias preocupaciones y
ediciones que afectarán la prueba
sobre el curso de la iteración, y
considerar las acciones
apropiadas que se deben tomar.
Como regla general, no pase
mucho tiempo en la presentación
de la documentación para estos
aspectos del esfuerzo de la 49
prueba.
 Flujo de trabajo: Verificar la aproximación de la Prueba

El propósito de este flujo es

verificar por demostración que
el acercamiento al trabajo,
produce resultados exactos y
es apropiado para los recursos
disponibles.
El objetivo es obtener una
comprensión de los apremios y
limitaciones que tiene cada
técnica como será aplicada en
el contexto dado por el
proyecto, y se encuentre una
solución apropiada para la
puesta en práctica de cada
técnica o técnicas alternativas
para el hallazgo de la solución 50
que pueden ser utilizadas.
 Flujo de trabajo: Validar la estabilidad de la estructura
(build)

El propósito de este flujo es

validar que la estructura sea
bastante estable para que el
esfuerzo a desplegar para las
pruebas y la evaluación se inicie.

Este flujo ayuda a proveer los

recursos de la prueba que son
perdidos en el esfuerzo de una
prueba infructuosa.

51
 Flujo de trabajo: Probar y evaluar
El propósito de este flujo es
alcanzar holgura y profundidad
apropiada en el esfuerzo de la
prueba para permitir una
suficiente evaluación de los
artículos que son indicados por
la prueba, donde la evaluación
sea gobernada por los
motivadores de la prueba.
Implica realizar el trabajo táctico
de la prueba y de la evaluación a
poner en práctica, ejecución y
evaluación de las pruebas
específicas y la divulgación de
los incidentes se encontrados
52
 Flujo de trabajo: Alcance de una misión aceptable

El propósito de este flujo es entregar un resultado útil de la evaluación

a los stakeholders de las prueba, este resultado producto de la
evaluación se determina en los términos de la misión de la evaluación.

53
 Flujo de trabajo: Mejorar el resultado de la Prueba

El propósito de este flujo es

mantener y mejorar los activos
de la prueba. Esto es importante
especialmente si se intenta
reutilizar los activos
desarrollados en el ciclo actual
de la prueba en los ciclos
subsecuentes de la prueba.
En algunos casos puede ser útil
asignar la creación y el
mantenimiento de los activos de
la automatización a un equipo secundario separado, permitiendo que se
especialicen en preocupaciones de la automatización. Esto permite que los
otros miembros del equipo se centren en la mejora de los activos de la
prueba de la no automatización. 54
Actividades por Roles:

55
Descripción de los Artefactos de las Pruebas

56
 Rol:Test Manager

El Rol del Administrador de Prueba, tiene como responsabilidad el

éxito total de la prueba.
El Rol involucra calidad y aprobación de la prueba, recurso de
planeación, dirección, y solución a de los problemas que impiden el
57
éxito de la prueba
 Rol: Test Manager. Artefactos:

El Plan de Pruebas, contiene la definición de

las metas y objetivos a probar dentro del
alcance de cada iteración del proyecto.
Proporciona el marco de trabajo en el que el
equipo llevará a cabo la prueba dentro de el
Artifact: Test Plan horario coordinado.

El Resumen de la Evaluación de la Prueba,

organiza y presenta un análisis resumen de los
resultados de las pruebas y las medidas clave
para revisar y definir estas, típicamente por los
Stakeholders claves.
Además,puede contener una declaración
Artifact: Test general de calidad relativa, puede mantener
Evaluation Summary las recomendaciones de las pruebas que se
realizaran a futuro.
58
 Rol: Test Manager. Artefactos:

La Lista de los Problemas, proporciona una

manera de registrar para la Administrador del
Proyecto los: problemas, excepciones,
anomalías, u otras tareas incompletas que
requieren atención que relaciona a la dirección
del proyecto.
Artifact: Issues List
Se proponen cambios a los artefactos de
desarrollo a través de Cambio de requerimiento
(CR), se usan los Cambio de Requerimiento
para documentar los problemas, las mejoras
solicitadas y cualquier otro tipo de solicitud para
un cambio en el producto. El beneficio de CR es
que proporcionan un registro de decisiones,
Artifact: Change debido a su proceso de valoración, asegura los
Request impactos del cambio que puedan darse en el
59
proyecto.
Rol: Test Analyst

El Análista de las Pruebas es el

responsable de identificar y definir las
pruebas requeridas, mientras supervisa
el progreso de la comprobación
detallada y resultado por cada ciclo de
realización de las pruebas.

Este rol lleva la responsabilidad típica

de representar las necesidades de los
stakeholders que no tienen la
representación directa o regular en el
proyecto.
60
 Rol: Test Analyst. Artefactos:

La Lista de Ideas de Prueba, es una lista enumerada de

ideas, a menudo parcialmente formada, que identifican
pruebas potencialmente útiles a conducir.
Test-Ideas List

Su propósito del Caso de Prueba, es especificar y

comunicar las condiciones específicas que necesitan ser
validadas para permitir una definición de algunos
aspectos particulares de los ítems de prueba objetivo.
Test Case

El Modelo de Análisis de la carga de Trabajo, trata de

definir acertadamente las condiciones de carga bajo los
cuales, los ítems de prueba objetivo deben operar en su
entorno de configuración del sistema.
61
Workload Analysis Model
 Rol: Test Analyst. Artefactos:

La Data de Prueba, es la definición (usualmente

formal) de una colección de valores de entrada de
prueba que son consumidos durante la ejecución de
una prueba
Test Data

La Data de Resultado, es una colección de

información sumaria determinada del análisis de
unas o más peticiones de los registros y del cambio
de la prueba,

Referido a veces como un depósito más grande de

muchos resultados de la prueba.
Test Results

62
 Rol: Test Designer

El Rol del Test Designer es responsable de definir el acercamiento de

la prueba y de asegurar su puesta en práctica acertadamente. El papel
implica el identificar las técnicas, herramientas y pautas apropiadas para
poner en ejecución las pruebas requeridas, y dotar de los recursos
63
necesarios para conducir los requisitos de la prueba.
 Rol: Test Designer. Artefactos:

El Plan de Estrategia, define el plan estratégico de como

el esfuerzo de la prueba será conducido contra uno o más
aspectos del sistema.
Una estrategia de prueba necesita poder convencer a la
Test Strategy
gestión y a otros Stakeholders que el acercamiento es
alcanzable.

La arquitectura de automatización, es útil cuando la

ejecución automatizada de las pruebas del software se
debe mantener y ampliar durante ciclos múltiples de
Test
prueba.
Automation
Architecture Proporciona una descripción arquitectónica comprensible
del sistema de automatización de las pruebas, usando un
número de diversas visiones arquitectónicas para
representar diversos aspectos del sistema. 64
 Rol: Test Designer. Artefactos:

La especificación de interfaz de la prueba, especifica

la disposición de un sistema en términos de
comportamientos (operaciones), por clasificador (una
clase, un subsistema o un componente) para los
propósitos del acceso de las pruebas (testeabilidad).
Test Interface
Specification Proporciona medios para documentar los requisitos
especiales del esfuerzo de las pruebas que pondrán
apremios o requisitos adicionales en el diseño de
software.

La configuración del entorno de la prueba, es la

especificación para un arreglo de hardware, software, y
ajustes asociados al entorno que se requieran para
Test permitir las pruebas exactas a ser conducidas que
Environment evaluarán uno o más ítems de la prueba objetivo.
Configuration
65
 Rol: Test Designer. Artefactos:

La Suite de Pruebas, es un tipo de paquete que agrupa

las colecciones de pruebas, para ordenar la ejecución de
esas pruebas y para proporcionar un sistema útil y
Test Suite relacionado de información del registro de prueba del
cual los resultados de prueba pueden ser determinados.

66
Rol: Tester
El Rol Tester es ser
responsable de todas las
actividades de las pruebas.

Las implicancias:
• Identificar dentro de la
implementación la más
apropiada para mostrarla
en las pruebas.
• Implementación individual
de los tests
• Verificación y ejecución
de test.
• Analizar y recoger las
ejecuciones de errores.
67
 Rol: Tester. Artefactos:

El registro de las pruebas, es una colección de salidas

capturadas durante la ejecución de una o más pruebas,
usualmente representa la salida resultante de la ejecución
Test Log de un conjunto de pruebas para un ciclo de pruebas.

Las notas de prueba, instrucciones paso a paso de

cómo realizar una prueba, permitiendo su ejecución de
una manera efectiva y eficiente.
Test Script

68
Tipos de pruebas:
1. Usabilidad
2. Unitarias
3. Funcionales
4. De Seguridad
5. De Volumen
6. Confiabilidad
7. Desempeño
8. Soportabilidad

69
 1. Pruebas de Usabilidad

Se centran en:

9 Factores humanos,
9 Estética,
9 Consistencia con la interfaz de usuario,
9 Ayudas en línea y “context sensitive”,
9 Wizards y agentes,
9 Documentación para el usuario
9 Materiales de entrenamiento.

70
 2. Pruebas Unitarias

Pruebas unitarias. Se enfocan en un programa o un componente

que desempeña una función especifica que puede ser probada y
que se asegura que funcione tal y como lo define la
especificación del programa.

Los programadores siempre prueban el código durante el

desarrollo, por lo que las pruebas unitarias son realizadas
solamente después de que el programador considera que el
componente está libre de errores.

71
 3. Pruebas Funcionales

Objetivo:
Asegurar el trabajo apropiado de los requisitos funcionales;
incluyendo la navegación, entrada de datos, procesamiento y
obtención de resultados.

Metas:
9Verificar el procesamiento, recuperación e implementación
adecuada de las reglas del negocio.
9Verificar la apropiada aceptación de datos.

Enfoque:
Los requisitos funcionales (Casos de Uso) y las reglas del
negocio
72
 3. Pruebas Funcionales,
continua...

Técnica: Caja Negra.

‰No se analiza la estructura interna del programa sino que la
selección de casos se concentra en: los datos de entrada y salida, y
la especificación
‰Se ejecuta cada caso de uso, flujo de caso de uso, o función,
usando datos válidos e inválidos, para verificar lo siguiente:
9Que se aplique apropiadamente cada regla de negocio.
9Que los resultados esperados ocurran cuando se usen datos
válidos.
9Que sean desplegados los mensajes apropiados de error y
precaución cuando se usen datos inválidos.
‰La especificación informal dificulta la correcta selección de casos
73
 3. Pruebas Funcionales,
continua...

Para realizar las Pruebas Funcionales se debe de tener en

cuenta:
9 Identificación del Caso de Uso
9 Plantilla de identificación del Caso de Uso.
9 Prototipo.
9 Plantilla de caso de uso de Prueba
9 Set de prueba del caso de uso de prueba

Caja Negra

Entrada Funciones Salida

74
 4. Pruebas de Seguridad

Objetivo:
Nivel de Seguridad de la Aplicación: Verificar que un actor solo
pueda acceder a las funciones y datos que su usuario tiene
permitido.
Nivel de Seguridad del Sistema: Verificar que solo los actores con
acceso al sistema y a la aplicación están habilitados para accederla.
Áreas:
Seguridad de la aplicación, incluye los accesos a datos o funciones
de negocios.
Seguridad del sistema, incluye los ingresos y accesos remotos al
sistema.
75
 4. Pruebas de Seguridad,
continua...

Garantiza:
Que los usuarios estén restringidos a funciones específicas o su
acceso este limitado únicamente a los datos para los cuales están
autorizados a acceder.
Que solo aquellos usuarios autorizados a acceder al sistema son
capaces de ejecutar las funciones del sistema.
Cumplir con los objetivos específicos de seguridad de cada
sistema.

Técnicas:
Identificar cada tipo de usuario y las funciones y datos a los que se
debe autorizar.
76
 4. Pruebas de Seguridad,
continua...

Técnicas:
9 Crear pruebas para cada tipo de usuario y verificar cada
permiso, creando transacciones específicas para cada tipo de
usuario.
9 Modificar tipos de usuarios y volver a ejecutar las pruebas.

Criterio de Completitud.
9 Para cada tipo de usuario conocido, las funciones y datos
apropiados y todas las transacciones funcionen como se
esperaba.

77
 5. Pruebas de Volumen

Objetivo:
Verificar que la aplicación funcione adecuadamente bajo los
siguientes escenarios de volumen:
Máximo (actual o físicamente posible) número de clientes
conectados (o simulados), todos ejecutando la misma función por
un período extendido.
Máximo tamaño de base de datos (actual o escalado) y múltiples
consultas ejecutadas simultáneamente.
Descripción:
Verificar que la aplicación funcione adecuadamente bajo los
siguientes escenarios de volumen:
9Determinan la cantidad de datos con la cual el sistema falla.
9Carga máxima que el sistema soporta en un período dado. 78
 5. Pruebas de Volumen,
continua...

Técnica.
Usar múltiples clientes, corriendo las mismas pruebas o pruebas
complementarias para producir el peor caso de volumen por un
período extendido.
Utilizar un tamaño máximo de Base de datos (actual o con datos
representativos) y múltiples clientes para correr consultas
simultáneamente para períodos extendidos.
Criterio de Completitud.
Todas las pruebas planeadas han sido ejecutadas y los límites
especificados en el sistema se han conseguido o excedido sin que el
sistema falle.

79
 6. Pruebas de Confiabilidad

• Pruebas de Integridad:
Se enfocan en probar la robustez (resistencia a fallas) y el uso
adecuado del lenguaje, sintaxis y uso de recursos. Este tipo de
prueba puede aplicarse tanto a unidades como a integración de
unidades.

• Pruebas de Estructura:
Estas pruebas se enfocan en hallar problemas de adherencia del
elemento objetivo a su diseño y formación. Típicamente, estas
pruebas se realizan sobre aplicaciones Web, asegurando que todos
los enlaces están conectados, los controles adecuados se muestran,
y no hay contenido inaccesible.

80
 6. Pruebas de Confiabilidad,
continua...

• Pruebas de Stress:
Este tipo de prueba se enfoca a evaluar el comportamiento del
sistema bajo condiciones anormales. Stress del sistema se refiere a
extrema carga, memoria insuficiente, no disponibilidad de servicios
y hardware o recursos compartidos limitados. Este tipo de prueba
permite comprender mejor cómo y qué áreas del sistema
colapsarán, de este modo es posible planificar contingencias y
actualizar el mantenimiento y planear y asignar recursos de
antemano.

81
 7. Pruebas de Desempeño:

• Pruebas de Benchmark:
Compara el desempeño del elemento objetivo de la prueba con un
sistema conocido y una carga de trabajo definida.

• Pruebas de Carga:
Validar y evaluar aceptabilidad de un elemento de un sistema
sobre diferentes cargas de trabajo mientras el sistema permanece
constante. Generalmente se incluye simulación de cargas de
trabajo promedio y pico que puedan ocurrir dentro de la tolerancia
operacional normal.

82
 7. Pruebas de Desempeño,
continua...

• Pruebas de Contención:
Validar que el elemento que se prueba maneja adecuadamente
cuando muchos actores solicitan el mismo recurso.

• Pruebas de Perfil de Desempeño:

Monitorea el perfil en el tiempo incluyendo flujo de ejecución,
acceso a data, llamadas a funciones para identificar cuellos de
botella y procesos ineficientes.

83
 8. Pruebas de Soportabilidad:

• Pruebas de Configuración:
Se enfocan en evaluar aquellos elementos configurados para
diferentes hardware y/o configuraciones de software.
Pueden implementarse como pruebas de rendimiento del sistema.

• Pruebas de Instalación:
Se enfoca en evaluar que el elemento a probar se instala como se
indica, en diferentes hardware y /o configuraciones de sistemas de
software y bajo diferentes condiciones (tales como espacio
insuficiente en disco, interrupción de electricidad).
Este tipo de prueba se aplica y ejecuta sobre aplicaciones y
sistemas.

84
 Recomendaciones:

1. Escribir un plan de prueba para cada paquete.

2. Integrar paquetes siguiendo una estrategia bottom-up.
3. Probar el programa para los valores límite, y para valores de
entrada inválidos.
4. Realizar revisiones en grupo del código fuente.
5. Permitir a alguien ajeno al proyecto que “juegue” con vuestro
programa.

85
 Fuentes de consulta:

1. Materia: Tecnología de la Información. Curso: Profesora Ariana Rosenthal.

UBA_FCE.

2. Rational Unified Process, help

Universidad de San Martín de Porres
Facultad de Ingeniería y Arquitectura

Diseño e Implementación de Sistemas

Disciplina de Pruebas
Fin de la sesión: 10

Mg. Géner Zambrano L.

gzambrano@usmp.edu.pe
Ing. Hector Henriquez T.
hhenriquez@usmp.edu.pe

Semestre: 2010_I