Modelo de

prueba

Análisis de
Sistemas

1
El papel de la prueba en el ciclo
de vida del software
Propósito de las pruebas
El proceso de prueba, también llamado verificación y validación (V & V), es
el nombre que se le da a los proceso de comprobación y análisis que
aseguran que el software esté acorde con su especificación y cumpla las
necesidades de los clientes que pagaron por ese software.

La verificación y validación es un proceso de ciclo de vida completo. Inicia

con las revisiones de los requerimientos y continúa con las revisiones del
diseño y las inspecciones del código hasta la prueba del producto.

Existen actividades de V & V en cada etapa del proceso del software. Estas
actividades comprueban que los resultados de las tareas del proceso estén
acordes con lo especificado.

La verificación y la validación no son la misma cosa, aunque es muy fácil

confundirlas. Podemos expresar de manera sucinta la diferencia entre ellas
así:

Estas definiciones señalan que el papel de la verificación comprende

comprobar que el software esté de acuerdo con su especificación. Se
comprueba que el sistema cumple sus requerimientos funcionales y no
funcionales especificados.

La validación, sin embargo, es un proceso más general. Se debe asegurar que

el software cumple las expectativas del cliente. Va más allá de comprobar si

2
el sistema está acorde con su especificación para mostrar que el software
hace lo que el usuario espera a diferencia de lo que se ha especificado.

Dentro del proceso de V & V se utilizan dos técnicas de comprobación y

análisis de sistemas:

 Las inspecciones del software analizan y comprueban las

representaciones del sistema como el documento de requerimientos,
los diagramas de diseño y el código fuente del programa. Se aplican a
todas las etapas del proceso. Las inspecciones se complementan con
algún tipo de análisis automático del texto fuente de un sistema o con
documentos asociados. Las inspecciones del software y los análisis
automatizados son técnicas V & V estáticas puesto que no requieren
que el sistema se ejecute.

 Las pruebas del software comprenden llevar a cabo una

implementación del software con los datos de prueba y examinar las
salidas del software y su comportamiento operacional para comprobar
que se desempeñe conforme a lo requerido. Llevar a cabo las pruebas es
una técnica dinámica de la verificación y validación debido a que se
realizan en una representación ejecutable del sistema.

La meta fundamental del proceso de verificación y validación es generar la

confianza de que el sistema de software se “ajusta a los propósitos”.

Esto no significa que el programa deba estar libre de defectos. Más bien,
significa que el sistema debe ser suficientemente bueno para la utilización
que se pretende.

El nivel de confianza requerido depende de:

 El propósito del sistema

 Las expectativas de los usuarios del sistema
 El entorno actual de mercado para el sistema.

La Prueba en el PUD
Durante este flujo de trabajo se procederá a verificar el resultado de la
implementación probando cada construcción, tanto las intermedias como
las versiones finales del sistema.

Los objetivos de la prueba son:

3
 Planificar las pruebas necesarias en cada iteración (pruebas de
integración y de sistema).

 Diseñar e implementar las pruebas creando casos de prueba que

especifican qué probar, procedimientos de prueba que indican cómo
realizar las pruebas y de ser posible crear componentes automatizados
que realicen las pruebas.

 Realizar las pruebas y manejar los resultados de las mismas

sistemáticamente. Las construcciones en las que se detectan defectos
son probadas se nuevo y posiblemente devueltas al flujo de diseño o
implementación para que sean arregladas.

El siguiente gráfico muestra la ubicación del Flujo de Trabajo de Prueba en

el ciclo de vida del Proceso Unificado de Desarrollo.

Fuente: Libro “El Proceso Unificado de Desarrollo de Software” Ivar Jacobson y otros, 2000, pág. 11.

Durante la fase de inicio puede hacerse algo de la planificación de las

pruebas. Sin embargo las pruebas se llevan a cabo cuando una construcción
es sometida a las pruebas de integración y de sistema. Esto quiere decir que
las actividades de pruebas se centran en las fases de elaboración cuando se
prueba la línea base ejecutable del sistema, y en la fase de construcción
cuando el grueso del sistema está implementado.

4
Durante la fase de transición el centro de atención se desplaza hacia la
corrección de defectos durante los primeros usos del sistema y a las pruebas
de regresión.

Flujo de trabajo de prueba

Para describir el flujo de trabajo de prueba se enumeran los artefactos
creados en este flujo de trabajo, los trabajadores participantes y las
actividades a realizar:

 Artefactos: Los artefactos que se producen en la Prueba son:

o Modelo de pruebas.
o Caso de prueba.
o Procedimiento de prueba.
o Componente de prueba.
o Plan de prueba.
o Defecto.
o Evaluación de prueba.

 Trabajadores: Los trabajadores responsables por los artefactos que se

producen en el modelo de prueba son:

o Diseñador de pruebas
o Ingeniero de componentes.
o Ingeniero de pruebas de integración.
o Ingeniero de pruebas de sistema

 Actividades: Las actividades a realizar por los trabajadores para producir

los distintos artefactos son:

o Planificar la prueba.
o Diseñar prueba.
o Implementar prueba.
o Realizar pruebas de integración.
o Realizar prueba de sistema.
o Evaluar prueba.

El siguiente gráfico muestra la relación entre los artefactos de la Prueba y los

trabajadores responsables de cada uno:

5
Fuente: Libro “El Proceso Unificado de Desarrollo de Software” Ivar Jacobson y otros, 2000, pág.
282.

A continuación se muestra un gráfico que indica el flujo de trabajo para la

actividad de Prueba, que relaciona los trabajadores participantes con sus
actividades, poniendo de manifiesto la secuencia de éstas:

Fuente: Libro “El Proceso Unificado de Desarrollo de Software” Ivar Jacobson y otros, 2000, pág.
290.

6
Modelo de prueba
El Modelo de Prueba es un modelo que describe principalmente cómo se
prueban los componentes ejecutables (construcciones) en el modelo de
implementación con pruebas de integración y de sistema. También puede
especificar cómo se probarán ciertos aspectos específicos como la interfaz
de usuario y la ayuda en línea.

El modelo de pruebas está compuesto por un conjunto de casos de prueba,

procedimientos de prueba y componentes de prueba.

Plan de prueba
Este plan describe las estrategias, recursos y planificación de la prueba. La
estrategia incluye la definición del tipo de pruebas a realizar para cada
iteración y sus objetivos, el nivel de cobertura de prueba y el porcentaje de
pruebas que deberían ejecutarse con un resultado específico.
Defecto
Un defecto es una anomalía del sistema. Un defecto puede ser utilizado para
localizar cualquier cosa que los desarrolladores deben registrar como un
síntoma de problema en el software, que ellos necesitan controlar y
resolver.

Evaluación de prueba
Esto es un análisis y valoración del resultado de la prueba, tales como
cobertura del caso de prueba, cobertura de código y el estado de los
defectos. Más adelante, veremos cómo determinar el porcentaje de
cobertura de la prueba en función de la cantidad de escenarios posibles de
un caso de uso.

Procedimiento de prueba
En este punto veremos los conceptos de procedimiento de prueba (indica
cómo probar), caso de prueba (indica qué probar) y componente de prueba
(automatiza el procedimiento de prueba cuando sea posible).

7
Procedimiento de prueba
Un procedimiento de prueba especifica cómo realizar uno o más casos de
prueba. Esto implica las instrucciones para que un individuo lleve a cabo las
pruebas o las instrucciones para interactuar con una herramienta de
automatización de pruebas.

El cómo llevar a cabo un caso de prueba puede ser especificado por un

procedimiento de prueba, pero a menudo es útil reutilizar un procedimiento
de prueba para varios casos y reutilizar varios procedimientos de prueba
para un caso de uso

El procedimiento de prueba es similar a la descripción del flujo de eventos

de un caso de uso pero incluye información adicional, como los valores de
entrada del caso de uso a utilizar, la forma en la que estos valores han de ser
introducidos en la interfaz de usuario y lo que hay que verificar.

A continuación se muestra un ejemplo de Procedimiento de Prueba para el

caso de uso “Registrar Disco”.

Caso de prueba
Un caso de prueba especifica una forma de probar el sistema, incluyendo la
entrada o resultado con la que se ha de probar y las condiciones bajo las que
ha de probarse.

Típicamente un caso de prueba (en el Flujo de Trabajo de Prueba del PUD)

puede especificar:

8
 Cómo probar un caso de uso o un escenario específico de un caso de
uso. Este tipo de caso de prueba incluye la verificación del resultado de
la interacción entre los actores y el sistema, que se satisfacen las
precondiciones y las postcondiciones. Un caso de prueba de este tipo es
una prueba de “caja negra”, es decir, una prueba del comportamiento
exteriormente observable.

 Cómo probar una realización de caso de uso-diseño, que incluye la

verificación de la interacción de los componentes que implementan
dicho caso de uso. Este tipo de prueba es una prueba de “caja blanca”,
es decir una prueba de la interacción interna de los componentes.

Para las pruebas de sistema, en el Flujo de Trabajo de Prueba se plantean

las siguientes:

 Pruebas de instalación: Verifican que el sistema pueda ser instalado en

la plataforma del cliente y que funcionará correctamente.

 Pruebas de configuración: Verifican que el sistema funciona

correctamente en diferentes configuraciones, como por ejemplo
distintas configuraciones de red.

 Pruebas negativas: Intentan provocar que el sistema falle para revelar

sus debilidades. Consisten en casos de prueba en los que se utilizará el
sistema deliberadamente “mal” o realizando cosas que no son las
esperadas, o sobrecargándolo.

 Pruebas de tensión o de estrés: Identifican problemas con el sistema

cuando hay recursos insuficientes o cuando hay competencia por los
recursos.

 Pruebas de aceptación: Se realizan en el ambiente de operación,

también se las conoce como testing del cliente. En la confección del plan
de pruebas de aceptación debería participar el cliente.

Componente de prueba
Un componente de prueba automatiza uno o varios procedimientos de
prueba o partes de ellos. Pueden ser desarrollados utilizando un lenguaje de
programación común o desarrollada con una herramienta de
automatización de pruebas.

9
Si son complejos de desarrollar, se puede confeccionar un modelo de diseño
de pruebas (similar al modelo de diseño del sistema), para modelar los
componentes de prueba.

10
Referencias
Booch Grady, Rumbaugh James, Jacobson Ivar (1999) “El lenguaje de
Modelado Unificado”, España, Addison Wesley Iberoamericana. Capítulos: 25,26,
29 y 30

Braude Eric (2003) “Ingeniería de Software, una perspectiva orientada a objetos”,

Alfaomega Grupo Editor SA. Capítulo: 8 y 9

Jacobson Ivar, Booch Grady, Rumbaugh James (2000) “El Proceso

Unificado de Desarrollo de Software”, España, Addison Wesley. Capítulos: 10 y 11
Larman Craig (2003) “UML y Patrones. Una introducción al análisis y diseño
orientado a objetos y al proceso unificado”, 2da. Edición, España, Prentice Hall.
Capítulo: 20

Pressman Roger (2006) “Ingeniería de Software. Un enfoque práctico”

6ta. edición, McGraw Hill. Capítulos 10

Rubble David (1998) "Análisis y Diseño práctico de Sistemas Cliente/Servidor con

GUI". Prentice Hall. Capítulo: 8

Sommerville Ian (2002) “Ingeniería de Sofware”, Ed. Pearson Educación, México.

Capítulo: 10

11