SOF-112

PRUEBA DE SOFTWARE

UNIDAD II

2.0
Contexto de la prueba de software

Versión 1.1. REPÚBLICA DOMINICANA. 2019.

Direcció.n Virtual
virtual.itsc.edu.do
 1. Contexto de la prueba de
software.

El ciclo de vida básico de un software Figura No.1

consta de los siguientes procedimientos:

Definición de objetivos: define la finalidad

del proyecto y su papel en la estrategia
global.

Análisis de los requisitos y su viabilidad:

recopila, examina y formula los requisitos
del cliente y examina cualquier restricción
que se pueda aplicar.

Diseño general: requisitos generales de la

arquitectura de la aplicación.

Diseño en detalle: definición precisa de

cada subconjunto de la aplicación.

Programación (programación e
implementación): implementación de un
lenguaje de programación para crear las
funciones definidas durante la etapa de
diseño.

Prueba de unidad: prueba individual de

cada subconjunto de la aplicación para
garantizar que se implementaron de
acuerdo con las especificaciones.

Integración: garantiza que los diferentes

módulos se integren con la aplicación. Este
es el propósito de la prueba de integración
que está cuidadosamente documentada.

2
Prueba beta (o validación): garantiza que el software cumple con las
especificaciones originales.

Documentación: sirve para documentar información necesaria para los usuarios

del software y para desarrollos futuros.

Implementación

Mantenimiento: comprende todos los procedimientos correctivos (mantenimiento

correctivo) y las actualizaciones secundarias del software (mantenimiento
continuo).

El orden y la presencia de cada uno de estos procedimientos en el ciclo de vida

de una aplicación dependen del tipo de modelo de ciclo de vida acordado entre el
cliente y el equipo de desarrolladores.

(http://www.lsi.us.es/docencia/get.php?id=361)

Veamos ahora cuáles son las fases para

probar un software:

1. Diseño de las pruebas. Esto es,

identificación de la técnica o técnicas de pruebas
que se utilizarán para probar el software. Distintas
técnicas de prueba ejercitan diferentes criterios
como guía para realizar las pruebas.

2. Generación de los casos de prueba. Los casos de prueba representan los datos que
se utilizarán como entrada para ejecutar el software a probar. Más concretamente los
casos de prueba determinan un conjunto de entradas, condiciones de ejecución y
resultados esperados para un objetivo particular. Como veremos posteriormente, cada
técnica de pruebas proporciona unos criterios distintos para generar estos casos o
3
 datos de prueba. Por lo tanto, durante la tarea de generación de casos de prueba, se
han de confeccionar los distintos casos de prueba según la técnica o técnicas
identificadas previamente. La generación de cada caso de prueba debe ir acompañada
del resultado que ha de producir el software al ejecutar dicho caso (como se verá más
adelante, esto es necesario para detectar un posible fallo en el programa).

3. Definición de los procedimientos de la prueba. Esto es, especificación de cómo se va a

llevar a cabo el proceso, quién lo va a realizar, cuándo, …

4. Ejecución de la prueba, aplicando los casos de prueba generados previamente e

identificando los posibles fallos producidos al comparar los resultados esperados con
los resultados obtenidos.

5. Realización de un informe de la prueba, con el resultado de la ejecución de las

pruebas, qué casos de prueba pasaron satisfactoriamente, cuáles no, y qué fallos se
detectaron. Tras estas tareas es necesario realizar un proceso de depuración de las
faltas asociadas a los fallos identificados. Nosotros nos centraremos en el segundo
paso, explicando cómo distintas técnicas de pruebas pueden proporcionar criterios
para generar distintos datos de prueba.

En este sentido, todas las fases de un desarrollo deben documentarse:

requerimientos, análisis, diseño, programación, pruebas, etc... Una herramienta
muy útil en este sentido es una notación estándar de modelado, de modo que
mediante ciertos diagramas se puedan comunicar ideas entre grupos de trabajo.
Hay decenas de notaciones, tanto estructuradas como orientadas a objetos. Un
caso particular es el de UML, que analizamos en otra obra. De todas maneras,
los diagramas son muy útiles, pero siempre y cuando se mantengan
actualizados, por lo que más vale calidad que cantidad. La documentación para
desarrolladores a menudo es llamada modelo, pues es una simplificación de la
realidad para comprender mejor el sistema como un todo.

Otro aspecto para tener en cuenta cuando se documenta o modela, es el del

nivel de detalle. Así como cuando construimos planos de un edificio podemos
hacer planos generales, de arquitectura, de instalaciones y demás, también al
documentar el software debemos cuidar el nivel de detalle y hacer diagramas
diferentes en función del usuario de la documentación, concentrándonos en un
aspecto a la vez.

(https://pruebasdelsoftware.wordpress.com/201
3/01/07/principios-fundamentales-del-proceso-
de-pruebas/)
4
5