Modelo de prueba
El papel de la prueba en el ciclo de vida del software
Modelo de prueba
Procedimiento de prueba
Referencias
Descarga en PDF
Lección 1 de 5
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í:
Figura 1. Diferencia entre la verificación y la validación
Fuente: elaboración propia con base en Sommerville, 2005, p. 472.
Tal como indica Sommerville (2005), estas definiciones señalan que el papel
de la verificación comprende comprobar que el software esté de acuerdo con
su especificación. 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 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 (Sommerville, 2005).
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 implican ejecutar 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. (Sommerville, 2005, p. 473).
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 (Sommerville, 2005):
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:
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 de 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.
Figura 2. Ubicación del flujo de trabajo de prueba
Fuente: Jacobson, Booch y Rumbaugh, 2000, p. 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.
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. ([Link]/nQS59).
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:
Modelo de pruebas.
Caso de prueba.
Procedimiento de prueba.
Componente de prueba.
Plan de prueba.
Defecto.
Evaluación de prueba.
Trabajadores
–
Los trabajadores responsables por los artefactos que se producen en el modelo de prueba son:
Diseñador de pruebas.
Ingeniero de componentes.
Ingeniero de pruebas de integración.
Ingeniero de pruebas de sistema.
Actividades
–
Las actividades a realizar por los trabajadores para producir los distintos artefactos son:
Planificar la prueba.
Diseñar prueba.
Implementar prueba.
Realizar pruebas de integración.
Realizar prueba de sistema.
Evaluar la prueba.
El siguiente gráfico muestra la relación entre los artefactos de la prueba y los
trabajadores responsables de cada uno.
Figura 3. Relación entre los artefactos de la prueba y los trabajadores
responsables
Fuente: Jacobson, Booch y Rumbaugh, 2000, p. 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 estas.
Figura 4. Flujo de trabajo para la actividad de prueba
Fuente: Jacobson, Booch y Rumbaugh, 2000, p. 290.
C O NT I NU A R
Lección 2 de 5
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 prueba 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.
C O NT I NU A R
Lección 3 de 5
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).
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”.
Figura 1. Ejemplo de procedimiento de prueba
Fuente: elaboración propia.
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:
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
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 externamente 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”,
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.
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.
Para ampliar los conocimientos sobre la temática, te recomendamos leer el
siguiente artículo:
M4 L3 MODELOS DE PRUEBAS PARA PRUEBAS DEL [Link]
124.4 KB
Fuente: Gutiérrez, J. J.; Escalona, M. J.; Mejías, M. y Reina, A. M. (2006). MODELOS DE PRUEBAS PARA PRUEBAS
DEL SISTEMA. Departamento de Lenguajes y Sistemas Informáticos Universidad de Sevilla. Recuperado de:
[Link]
C O NT I NU A R
Lección 4 de 5
Referencias
Jacobson, I.; Booch, G. y Rumbaugh, J. (2000). El Proceso Unificado de
Desarrollo de Software. ES: Editorial Addison Wesley.
Sommerville, I. (2002). Ingeniería de Software. MX: Ed. Pearson Educación.
C O NT I NU A R
Lección 5 de 5
Descarga en PDF
Mòdulo 4 - Lectura [Link]
454.5 KB
