EFFECTIVENESS ANALYSIS OF THE SET OF TEST CASES GENERATED WITH THE REQUIREMENTS BY CONTRACTS TECHNIQUE

Abstract

This article analyzes the maturity level of knowledge and effectiveness of all test cases designed with art by Contracts Requirements for tests, applied in a case study. It is a document that is developing the second phase of the research project "Structure of a generic methodology for testing Black-Box information systems", which conducts research group SISCO, from Faculty of Engineering of the University "Luis Amigó".

Full text

EFFECTIVENESS ANALYSIS OF THE SET OF TEST CASES GENERATED WITH THE
REQUIREMENTS BY CONTRACTS TECHNIQUE
Abstract
This article analyzes the maturity level of knowledge and effectiveness of all test cases designed with art by Contracts
Requirements for tests, applied in a case study. It is a document that is developing the second phase of the research
project "Structure of a generic methodology for testing Black-Box information systems", which conducts research group
SISCO, from Faculty of Engineering of the University “Luis Amigó”.
Keywords: Test cases, body of knowledge, use cases, functional testing, functional specification.
ANÁLISIS A LA EFICIENCIA DEL CONJUNTO DE CASOS DE PRUEBA
GENERADOS CON LA TÉCNICA REQUIREMENTS BY CONTRACTS
EDGAR SERNA MONTOYA
Grupo de investigación SISCO. Fundación Universitaria Luis Amigó
TV. 51A 67B-90 Medellín - Colombia.
edgar.sernamo@amigo.edu.co
Resumen
En este artículo se analiza el nivel de madurez del
conocimiento y la eficiencia del conjunto de casos de
prueba diseñados con la técnica Requirements by
Contracts [1] para las pruebas funcionales, aplicada en
un caso práctico. Es un documento que resulta del
desarrollo de la segunda fase del proyecto de
investigación “Estructuración de una metodología
genérica para la realización de pruebas de Caja Negra
en los sistemas de información”, que realiza el grupo de
investigación SISCO de la Facultad de Ingenierías de la
Universidad Luis Amigó.
Palabras clave: Casos de prueba, cuerpo del
conocimiento, casos de uso, pruebas funcionales,
especificación funcional.
1. INTRODUCCIÓN
La prueba es la última oportunidad en el proceso de
desarrollo de software para detectar y corregir sus
posibles defectos a un costo razonable, ya que la forma
generalizada de trabajo utilizada por los profesionales
en el área es la de ejecutarla sobre el producto
“terminado” [2]; mientras que la práctica enseña que la
prueba debe ser una actividad que se desarrolle de
forma paralela a todo el proceso del ciclo de vida del
producto [3]. “Es mucho más caro corregir los defectos
que se detectan cuando el sistema se encuentra en
operación” [4], por lo que es de importancia
fundamental poder confiar en que el conocimiento
aplicado sea lo suficientemente formal como para
obtener resultados predecibles en el proceso de las
pruebas.
Las técnicas de prueba determinan diferentes criterios
para diseñar los casos de prueba que se utilizarán como
entradas para el sistema en estudio, lo que significa que
un efectivo y eficiente diseño de éstos condiciona el
éxito de las pruebas [5]. El conocimiento para
seleccionar los métodos de prueba debe provenir de
estudios que justifiquen los beneficios y condiciones de
aplicación de los mismos, sin embargo, “los estudios
formales y prácticos de este tipo no abundan, por lo que
es difícil comparar losdiferentes métodos de prueba -no
tienen una sólida base teórica-, y determinar qué
variables de los mismos son de interés en estos
estudios” [6].
En vista de la importancia de contar con un
conocimiento formal de las pruebas, en este artículo se
analiza el nivel de madurez del conocimiento en el área
y la eficiencia del conjunto de casos de prueba diseñado
con la técnica Requirements by Contracts para las
pruebas funcionales. El objetivo principal es recoger el
cuerpo de conocimiento acerca de los aspectos que esta
propuesta tiene en cuenta para diseñar los casos de
prueba y su nivel de madurez, de tal manera que esta
información pueda ser útil a los desarrolladores para
identificar las condiciones de aplicabilidad del método y
la eficiencia del conjunto de casos de prueba que
genera.
Este documento se estructura de la siguiente forma: en
la sección 2 se describe la propuesta Requirements by
Contracts; en la sección 3 se presenta el caso práctico
aplicado; en la sección 4 se presentan los resultados
obtenidos; en la 5 se hace su análisis a los resultados, y
en la 6 se presentan las conclusiones de este estudio y se
propone el trabajo futuro.
2. DESCRIPCIÓN DE LA PROPUESTA
La se estructura en dos partes: en la primera se
extienden los casos de uso utilizando contratos, en los
que se incluyen las pre y pos-condiciones y los casos de
uso con sus parámetros; en la segunda se describe cómo,
a partir de los casos de uso extendidos, generar
automáticamente los casos de prueba. En un trabajo
posterior de los mismos autores [7], se describe la
aplicación de esta propuesta a familias de productos.
Parte de un diagrama de casos de uso en notación UML,
y al final del proceso aplicado se obtiene un modelo de
casos de uso extendido con contratos, y el conjunto de
casos de prueba con los que se verifica la
implementación del modelo. Los casos de uso se
expresan mediante caminos de ejecución que recorren
las secuencias de los casos de uso para satisfacer las pre
y pos-condiciones.

2.1 Pasos de la propuesta
Figura 1. Diagrama de actividades de la propuesta
 Paso 1. Se utiliza un intérprete –lenguaje- de
contratos para extender los casos de uso. El lenguaje
permite incluir los parámetros y las pre y pos-
condiciones, expresadas con proposiciones. El
objetivo es formular las dependencias que existen
entre los casos de uso.
 Paso 2. Se construye y ejecuta un modelo de
ejecución de casos de uso. Consiste en realizar un
diagrama que permita expresar, a partir de los casos
de uso extendidos, el comportamiento del sistema.
En este diagrama los nodos representan estados del
sistema determinados por las proposiciones, y las
transiciones instancias de caso de uso. No existen
restricciones para definir el significado semántico de
los predicados.
 Paso 3. Se selecciona el criterio de cobertura. La
propuesta propone cuatro criterios para recorrer el
modelo de ejecución, determinar el criterio de
cobertura y obtener los casos de prueba: 1) De todos
los bordes: por lo menos existe un objetivo de
prueba por transición; 2) De todos los vértices: por
lo menos existe un objetivo de prueba por vértice; 3)
De todos los casos de uso instanciados: por lo menos
existe un objetivo de prueba por caso de uso
instanciado; y 4) De todos los vértices y casos de
uso instanciados: por lo menos existe un objetivo de
prueba por vértice y caso de uso instanciado.
 Paso 4. Se aplica el criterio de cobertura
seleccionado. Al final se obtiene un conjunto de
instancias de casos de uso con sus parámetros,
conformado por secuencias de casos de uso válidas.
 Paso 5. Mediante una herramienta para generar
pruebas, se generan los casos de prueba a partir del
conjunto de instancias del paso anterior.
Tabla 1. Resumen de los pasos de la propuesta
Paso Detalle Objetivo
1 Se extiende el modelo de
casos de uso utilizando un
lenguaje de contratos
Obtener casos de uso
con parámetros, y pre y
pos-condiciones
2 Se construye el modelo
de ejecución de casos de
uso
Diseñar el modelo de
ejecución de casos de
uso
3 Se selecciona el criterio
de cobertura
Describir el criterio de
cobertura para recorrer
el modelo construido
4
Se aplica el criterio de
cobertura seleccionado
Obtener secuencias de
casos de uso válidas
5 Se generan los casos de
prueba
Diseñar las pruebas
ejecutables para el
sistema
3. CASO APLICATIVO
A continuación se describe el proceso utilizado para
aplicar experimentalmente esta propuesta.
3.1 Los casos de uso. Es de anotar que el sistema sobre
el que se experimenta la propuesta es un caso netamente
académico. Para una situación industrial y con exigencia
más compleja, la aplicación tiene un nivel de trabajo y
complejidad un poco mayor. El sistema utilizado para
experimentar la propuesta se basa en la circulación de
material en una biblioteca; en la tabla 2 se detallan los
casos de uso utilizados.
Tabla 2. Casos de uso seleccionados del sistema de
circulación de material
Referencia Descripción
CU
-
001
Validar Usuario
CU-002 Prestar material
CU-003 Devolver material
Figura 2. Diagrama de casos de uso del sistema
En las tablas 3, 4 y 5 se describen la documentación de
los casos de uso mediante la aplicación de la plantilla
sugerida en [8]; para que la documentación no se
extienda innecesariamente se suprimen algunos
elementos del modelo de la plantilla que no son
necesarios en este caso aplicativo.
Tabla 3. Caso de uso “Validar Usuario”
Caso de uso CU-001 Validad Usuario
Actores Usuario, BD usuarios
Tipo Inclusión
Propósito
Permitir la validación de usuarios en
el sistema
Resumen El usuario carga la página inicial del

sistema y digita nombre de usuario y
contraseña
Pre-condiciones Ninguna
Flujo Principal 1. El usuario carga la página de
acceso al sistema
2. El sistema despliega la página de
verificación de datos de ingreso y
solicita usuario y contraseña
3. El usuario digita los datos y
selecciona la opción “Ingresar”
4. El sistema valida usuario y
contraseña, y despliega la página
inicial del proceso
Excepciones E1: El sistema no carga la página de
acceso si el servidor no está activo o
existen problemas de navegación,
entonces se termina el caso de uso y
muestra un mensaje de error
E2: Si los datos de usuario y
contraseña no se digitan, el sistema
los solicita nuevamente y despliega
un mensaje de error
E3: Si el nombre de usuario no se
encuentra en la base de datos de
usuarios, el sistema lo solicita
nuevamente y despliega un mensaje
de error
E4: Si la contraseña no es válida, el
sistema la solicita nuevamente y
despliega un mensaje de error
Tabla 4. Caso de uso “Prestar Material”
Caso de uso
CU-002 Prestar Material
Actores Usuario, BD Material, BD Clientes
Tipo Principal
Propósito Registrar el préstamo del material de
la biblioteca
Resumen El usuario atiende las solicitudes de
los clientes y las registra o rechaza de
acuerdo con el escenario
Pre-condiciones
El usuario debe estar validado en el
sistema
Flujo Principal 1. El sistema presenta el cuadro de
diálogo de préstamo de material
2. El usuario digita el código del
material que el cliente desea
prestar
3. El sistema valida la disponibilidad
del material y el estado del cliente,
y despliega un mensaje de
confirmación
Excepciones
E1: Si no
se digita el código de
material el sistema lo solicita
nuevamente y despliega un mensaje
de error
E2: Si el código no existe despliega
un mensaje de error y termina el caso
de uso
E3: Si el código no está disponible se
despliega un mensaje de error y
termina el caso de uso
E4: Si el cliente está deshabilitado se
despliega un mensaje de error y
termina el caso de uso
Tabla 5. Caso de uso “Devolver material”
Caso de uso CU-003 Devolver Material
Actores Usuario, BD Material, BD Clientes
Tipo
Principal
Propósito Registrar la devolución de material a
la biblioteca por los clientes
Resumen El usuario atiende las devoluciones de
material por los clientes
Pre-condiciones
El usuario debe estar validado en el
sistema
Flujo Principal
1. El sistema presenta el cuadro de
diálogo de devolución de material
2. El sistema despliega la
información del material que el
cliente tiene en préstamo
3. El usuario selecciona el código a
devolver
4. El sistema actualiza las BD de
Clientes y Material
5. El sistema despliega mensaje de
confirmación de devolución
Excepciones E1: Si el cliente no tiene material en
préstamo el sistema muestra el
mensaje y termina el caso de uso
3.2 Generar el conjunto de casos de prueba
En el diagrama de casos de uso se aprecia que existe
dependencia de los casos de uso “Prestar material” y
“Devolver material” con el de “Validar usuario”, de tal
manera que no pueden ejecutarse antes de éste; de igual
manera existe una dependencia temporal entre los dos
primeros, ya que prestar debe haberse ejecutado antes
que devolver. A continuación, se aplica la propuesta a
estos casos de uso para obtener el conjunto de casos de
prueba del sistema.
Paso 1. Ampliar el diagrama de casos de uso mediante
contratos:
Tabla 6. Contratos para los casos de uso del sistema
CU Función Pre-condición Pos-condición
001 Validar(u1) Ninguna
UsuarioValidado
(uv)
002 Prestar (usuario
uv) UsuarioValidado
(usuario uv) MaterialPrestado
(mp)
003 Devolver (usuario
uv, mp)
UsuarioValidado
(usuario uv) y
MaterialPrestado
(mp)
MaterialDevuelto
(md)
Paso 2. Modelo de ejecución de los casos de uso
Tabla 7. Descripción de la semántica de los predicados
para ejecución de los casos de uso
Predicado
Detalle
Validar(u1)
Determina que el usuario u1 debe
quedar validado (uv) luego de
ejecutar el caso de uso “Validar
Usuario”
MaterialPrestado(mp) Determina que el material mp se
encuentra en estado préstamo
MaterialDevuelto(md) Determina que el material md se
encuentra en estado devuelto y
puede prestarse nuevamente
De los parámetros, y las pre y pos-condiciones
expresadas en los contratos de la tabla 6, se observa el
orden de ejecución de los casos de uso. El modelo de
ejecución detalla el progreso de los diferentes
parámetros de los casos de uso; los estados detallan el

estado del sistema de acuerdo con los predicados
definidos en los contratos, y cada transición representa
la ejecución de un caso de uso.
Figura 3. Modelo de ejecución de los casos de uso
Paso 3. Selección del criterio de cobertura. En este caso
aplicativo se selecciona el criterio de cobertura de todos
los estados y transiciones, por lo que todos los del
modelo de la figura 3 deben considerarse en por lo
menos una prueba.
Paso 4. Generar el conjunto de casos de pruebas. Para
ejecutar este paso se utiliza la herramienta de libre
distribución disponible en [9]. Para utilizar esta
herramienta es necesario describir el modelo de
ejecución de la figura 3:
# Entidades del sistema
{ u1 : usuario
md1, md2 : MaterialDisponible
}
# Descripción del estado inicial
{ MaterialDisponible (md1)
MateriaDisponible(md2)
}
# Descripción de los casos de uso
# Caso de uso ValidarUsuario
CU Validar(u1: usuario)
pre
post UsuarioValidado(uv)
# Caso de uso PrestarMaterial
CU Prestar(uv: UsuarioValidado; md : MaterialDisponible)
pre UsuarioValidado(uv) y MaterialDisponible(md)
post prestamo(L) and not disponible(L)
# Caso de uso DevolverMaterial
CU Devolver(uv : UsuarioValidado; mp : MaterialPrestado)
pre usuarioValidado(uv) y MaterialPrestado(mp)
post MaterialDevuelto(md) y MaterialDisponible(md)
Figura 4. Descripción del Modelo de ejecución
4. RESULTADOS
En las siguientes figuras se representan las secuencias
que surgen al aplicar la herramienta descrita, al modelo
de ejecución, con todos los criterios de cobertura.
[ValidarUsuario(u1), ValidarUsuario(u1)]
[ValidarUsuario(u1), Prestar(uv, md1), ValidarUsuario(u1)]
[ValidarUsuario(u1), Prestar(uv,md1), Devolver(uv,mp1)]
[Validadusuario(u1), Prestar(uv, md2), ValidarUsuario(u1)]
[ValidarUsuario(u1), Prestar(uv, md2), Prestar(uv, md1)]
[ValidarUsuario(u1), Prestar(uv, md2), Devolver(uv, mp2)]
[ValidarUsuario(u1), Prestar(uv, md1), Prestar(uv, md2),
ValidarUsuario(u1)]
[ValidarUsuario(u1), Prestar(uv, md1), Prestar(uv, md2),
Devolver(uv, mp1)]
[ValidarUsuario(u1), Prestar(uv, md1), Prestar(uv, md2),
Devolver(uv, mp2)]
Figura 5. Criterio de todos los bordes
[ValidarUsuario(u1), Prestar(uv, md2)]
[ValidarUsuario(u1), Prestar(uv, md1), Prestar(uv, md2)]
Figura 6. Criterio de todos los vértices
[ValidarUsuario(u1), ValidarUsuario(u1)]
[ValidarUsuario(u1), Prestar(uv, md1), ValidarUsuario(u1)]
[ValidarUsuario(u1), Prestar(uv, md1), Devolver(uv,mp1)]
[ValidarUsuario(u1), Prestar(u1, md2), ValidarUsuario(u1)]
[Validarusuario(u1), Prestar(uv, md2), Devolver(uv, mp2)]
Lo que se debe cubrir:
[ValidarUsuario(u1), Prestar(uv, md1), Prestar(uv, md2),
Devolver(uv,mp1), Devolver(uv, mp2)]
Figura 7. Criterio de todos los casos de uso instanciados
[ValidarUsuario(u1), Validarusuario(u1)]
[ValidarUsuario(u1), Prestar(uv, md1), ValidarUsuario(u1)]
[ValidarUsuario(u1), Prestar(uv, md1), Devolver(uv, mp1)]
[ValidarUsuario(u1), Prestar(uv, md2), ValidarUsuario(u1)]
[ValidarUsuario(u1), Prestar(uv, md2), Devolver(uv, mp2)]
[ValidarUsuario(u1), Prestar(uv, mp2)]
[Validarusuario(u1), Prestar(uv, md1), Prestar(uv, md2)]
Lo que se debe cubrir:
[ValidarUsuario(u1), Prestar(uv, md1), Prestar(uv, md2),
Devolver(uv,md1), Devolver(uv, mp2)] : 5
Figura 8. Criterio de todos los vértices y casos de uso
instanciados
Nota: La herramienta no permite la ejecución del
proceso en el criterio de casos de uso instanciados, ni en
el de vértices y casos de uso instanciados, presenta un
error de bloqueo interno y se detiene el proceso de
generación de los casos de prueba.
4.1 Factores de análisis. Para lograr una visión más
amplia de la oferta que hace esta propuesta, se establece
una serie de características elegidas como las que mejor
describen la mayoría de sus cualidades y facilitan su
validación y comparación en pro de analizar la
eficiencia del conjunto de casos de prueba, de tal forma
que al leerlas es posible conocer lo más importante de la
propuesta y los diferentes tratamientos dados a cada
una de ellas. Los factores que en este estudio se tienen
en cuenta para evaluar la eficiencia de la propuesta
fueron promulgados en 1995 [10] y ampliados en 2003.
1. Origen: requisitos para aplicación. Tipo:
Set{Necesidades, lenguaje natural, casos de uso,
varios}
2. Notación: si introduce nuevas notaciones gráficas.
Tipo: Boolean.
3. Aplicación: si referencia proyectos reales de
aplicación. Tipo: Boolean.

4. Estándares: si utiliza diagramas y notaciones
estándar o comúnmente aceptados. Tipo: Boolean.
5. Herramientas: si existen herramientas que la
soporten. Tipo: Boolean.
6. Prácticos: si incluye casos prácticos y ejemplos de
aplicación. Tipo: Boolean.
7. Cobertura: si para generar los casos de prueba
describe criterios de cobertura. Tipo:
Set{Enum{Análisis de caminos, partición de
categorías, varios, no}}.
8. Valores para prueba: si detalla cómo seleccionar
los valores para el conjunto de casos de prueba
generados. Tipo: Boolean.
9. Optimización: si describe cómo seleccionar
subconjuntos de casos de prueba sin perder
cobertura de requisitos. Tipo: Boolean.
10. Dependencia: si genera casos de prueba que
dependan de varios casos de uso o de casos de uso
aislados. Tipo: Boolean.
11. Orden de ejecución: si describe el orden de
ejecución de los casos de prueba que genera. Tipo:
Boolean.
12. Construcción modelo: si incluye la descripción de
cómo construir un modelo de comportamiento del
sistema o si genera los casos de pruebas desde los
datos de los casos de uso. Tipo: Boolean.
13. Priorización: si genera pruebas más detalladas para
los requisitos o casos de uso primarios y menos
detalladas los secundarios. Tipo: Boolean.
14. Continuidad: si el o los autores continúan
trabajando en la propuesta, si están desarrollando
herramientas de soporte, si han ofrecido nuevas
versiones o si han recibido el apoyo de otros grupos
de trabajo. Tipo: Enum{Sí, no, ?}.
15. Indicador de inicio: si indica el momento para
iniciar la generación de casos de prueba. Tipo:
Enum{Elicitación de requisitos, Análisis del
sistema}.
16. Resultados: cómo se presentan los resultados de
aplicación. Tipo: Set{Enum{Pruebas en lenguaje no
formal, scripts de prueba. Modelo de prueba,
secuencia de transiciones}}.
17. Documentación: cuál es el grado dificultad para
aplicarla de acuerdo a la calidad de la
documentación ofrecida. Tipo: Set{Alta, media,
baja}. Alta, si la documentación es suficiente; media
si existen lagunas o vacíos que la documentación no
resuelve; baja, si es difícil o no logra implementar
con la documentación.
18. Pasos: cantidad de pasos propuestos. Tipo: Entero.
19. Año publicación: para seguimiento más detallado.
Tipo: Entero.
Tabla 8. Resultado de las características
Característica
Indicador
1. Origen Casos de uso
2. Notación Diagramas de transición de
casos de uso
3. Aplicación No
4.
Estándares
Sí
5. Herramientas Sí
6. Prácticos Sí
7. Cobertura Varios
8. Valores para prueba No
9. Optimización Sí
10. Dependencia Sí
11. Orden de ejecución Sí
12. Construcción
modelo Sí
13.
Priorización
No
14. Continuidad Sí
15. Indicador de inicio Elicitación de requisitos
16. Resultados Secuencias de transiciones
entre los casos de uso
17. Documentación Media
18. Pasos 4
19. Año publicación 2003/2004
4.2 Limitaciones del estudio. Debido a que el estudio
de caso es académico, es posible que los resultados no
sean tan representativos como los que podrían hallarse
en un caso industrial. Otra limitante lo constituye la
herramienta para automatizar la propuesta ya que su
error no se pudo subsanar, por lo que es posible que los
casos de prueba obtenidos no sean los más adecuados
para analizar su eficiencia. Por último, el experimento
puede estar limitado al momento de seleccionar los
factores de análisis, porque si el estudio de caso es de
corte industrial, es posible que sean otros los que hay
que tener en cuenta.
5. ANÁLISIS DE LOS RESULTADOS
 No es suficiente para ponerla en práctica la forma
como describe el proceso para la generación del
diagrama de comportamiento del sistema.
 La notación que ofrece para el diagrama de
transición de casos de uso es incompleta en relación
con los diagramas de estados de UML. Por ejemplo,
no detalla qué hacer cuando no se tiene un estado,
como el caso del estado inicial.
 La utilidad del diagrama de comportamiento no es
clara, ya que el modelo de comportamiento de la
herramienta de soporte se puede generar desde el
diagrama de casos de uso extendido con los
contratos.
 La herramienta de soporte no está bien
documentada, tal es el caso del formato de los
archivos que utiliza, por lo que debe recurrirse a la
información en la Internet para utilizarlos.
 No describe como pasar del modelo de
comportamiento a la descripción de la herramienta,
por lo que es necesario intuirlo desde los ejemplos y
casos prácticos disponibles.
 La herramienta de soporte, como los autores lo
especifican, está en un estado incipiente de
desarrollo.
 La cantidad de casos de prueba varía mucho de
acuerdo con el criterio de cobertura.
 Se encontraron errores no documentados en algunos
criterios y no se pudo determinar su origen.
 Es bueno que la especificación que toma como
punto de partida sea el UML, dado su nivel de
unificación en el campo de conocimiento.
 Trata de forma tangencial el concepto de diseño por
contratos, una idea del desarrollo que es posible
aplicar a las pruebas para buscar en algún momento
que sea posible formalizarlas.

5.1 Puntos fuertes y débiles de la propuesta. Sus
puntos fuertes los constituyen: contar con diferentes
criterios de cobertura para recorrer el modelo de
ejecución; contar con una herramienta preliminar que la
soporte, el UCTSystem [9]; permite generar pruebas en
las que se involucran las secuencias de casos de uso.
Entre sus puntos débiles se encuentra el no permitir que
se desarrollen pruebas para verificar aisladamente el
comportamiento de cada caso de uso.
Tabla 9. Resumen de puntos fuertes y débiles
Puntos Fuertes Puntos Débiles
Contar con una
herramienta de libre
distribución en la que
se implementan los
criterios que propone
Extender los casos de uso de
forma no estandarizada por UML
Generar pruebas que
se basan en las
secuencias de los
casos de uso
No permitir que se desarrollen
pruebas para verificar
aisladamente el comportamiento
de cada caso de uso
Utilizar contratos para
expresar
dependencias de los
casos de uso entre sí
No detalla con qué criterio se
selecciona el número de
parámetros para un caso de uso
No hay forma de relacionar los
parámetros simbólicos con los
valores reales
Muchos de los conceptos que
utiliza no tienen una definición o
descripción suficiente
No tiene una descripción
detallada de cómo implementar
las pruebas
No detalla estudios de caso reales
o industriales en los que se haya
aplicado con éxito
6. CONCLUSIONES
 A partir del análisis del estado del arte es posible
concluir que esta propuesta aún no está completa, y
que partiendo de la especificación funcional, no es
posible generar un conjunto de casos de prueba
suficiente para ejecutar sobre el sistema en prueba.
 De la descripción de esta propuesta y del análisis
presentado en la tabla 9, aunque presenta algunos
puntos fuertes, sus carencias hacen que sea difícil
ponerla en práctica.
 El estudio que realiza al problema por resolver es
incompleto, ya que no tiene en cuenta elementos que
pueden considerarse fundamentales como generar
valores concretos de prueba o evaluar la cobertura
de los requisitos.
 La documentación que acompaña la propuesta es de
calidad media, lo que significa en su aplicación
aparecieron escenarios o dudas que no fue posible
resolver; lo que le resta eficiencia ya que esas
situaciones se deben resolver desde la experiencia, la
intuición o el conocimiento de quien que la aplique.
 Le hace falta consistencia, ya que en su presentación
describe que es posible obtener directamente el
conjunto de casos de prueba: valores de prueba,
interacciones con el sistema y resultados esperados;
pero en la práctica no fue posible obtener pruebas
directamente ejecutables ni generar los resultados
esperados; a cambio se obtuvo un conjunto de tablas
en formato propio.
 No incluye cómo evaluar la calidad del conjunto de
casos de prueba generados. Parte del concepto de
que es suficiente con seguir adecuadamente sus
pasos para obtener un conjunto de casos de prueba
de calidad y máxima cobertura.
 La automatización del proceso de generación del
conjunto de casos de prueba no es completamente
posible con esta herramienta, ya que los requisitos se
describen en lenguaje natural.
 Aunque sigue los estándares UML, su aplicación no
permite un seguimiento al 100% de los mismos.
 No detalla cómo resolver los ciclos infinitos que
aparecen en el código del programa en prueba. Para
el caso del sistema detallado en este documento,
cuando un usuario en el caso de uso “Validar
Usuario” digita el nombre o la contraseña
equivocada y el sistema los vuelve a solicitar, la
propuesta no restringe el número de intentos y lo
deja a criterio de los desarrolladores, lo que dificulta
su automatización.
7. TRABAJO FUTURO
 Es necesario que la propuesta se pueda conectar a
una herramienta CASE UML, utilizando una
herramienta para generar el conjunto de casos de
prueba más específica y adecuada -menos ad hoc.
 Validar la propuesta en otros estudios de caso. El
aquí presentado y el que los autores utilizan para
documentar la propuesta, tienen un corte muy
académico, por lo que es conveniente aplicarla a
procesos industriales más exigentes.
 Deben estudiarse las variantes funcionales para
productos de software en línea y también la
flexibilidad del enfoque para tratar con el hecho de
que los requisitos frecuente se modifican en un ciclo
de vida OO.
 Se requiere un campo de conocimiento más
estandarizado para determinar los criterios utilizados
para calificar la eficiencia de las técnicas de prueba
recientemente propuestas. Los que se encuentran no
contemplan algunas características que dichas
técnicas utilizan en sus procesos para obtener los
casos de prueba.
REFERENCIAS
[1] Nebut, C., Fleurey F., Le Y. T. and Jézéquel J-M.
(2003). Proceedings of the 14th International
Symposium on Software Reliability Engineering,
ISSRE’03, Denver, Colorado. Pp. 85-98.
[2] Kamde, P. M., Nandavadekar V. D. and Pawar R.
G. (2006). Value of test cases in software testing.
Management of Innovation and Technology. Vol. 2.
Pp. 668-672.
[3] Leon, D., Masri W. and Podgurski A. (2007). An
empirical evaluation of test case filtering techniques
based on exercising complex information flows.
IEEE Transactions on Software Engineering. Vol.
33, No. 7. Pp. 454-477.

[4] Lewis, W. E. (2000). Software testing and
continuous quality improvement. Florida: CRC
Press. 657 p.
[5] Sinha, P. P. and Suri N. (1999). Identification of test
cases using a formal approach. Proceedings of the
Twenty-Ninth Annual International Symposium on
Fault-Tolerant Computing. Madison, WI, USA. Pp.
314-321.
[6] Pressman, R. (2005). Software engineering: a
practitioner’s approach. New York: McGraw Hill.
958 p.
[7] Nebut, C., Fleurey F., Le Traon Y. and Jezequel J.-
M. (2004). A Requirement-Based Approach to Test
Product Families. Lecture Notes in Computer
Science. No. 3014. Pp. 198-210.
[8] Weitzenfeld, A. (2005). Ingeniería de Software
Orientada a Objetos con UML, Java e Internet.
México: Thompson Paraninfo. 678 p.
[9] RBCTool. UCTSystem. http://www.irisa.fr/triskell/
results/ISSRE03/UCTSystem/UCTSystem.html.
August 2009.
[10] Bach, J. (1995). The Challenge of Good Enough
Software. American Programmer. New York:
Yourdon Press. 545 p.