En este trabajo se presenta una propuesta de estructura de almacenamiento y los mecanismos de recuperación utilizados para aplicar el razonamiento basado en casos (RBC) en la generación de procedimientos de prueba funcionales en proyectos de software. Esta propuesta parte de los requisitos funcionales del proyecto de software y en ella se enuncian los algoritmos propuestos para considerar la semejanza entre cada par de proyectos, así como los que permiten adaptar la solución encontrada en la base de casos a las características de los nuevos proyectos.
Introducción
El tema de la calidad del software es de gran actualidad. Sin embargo, aunque las empresas dedican grandes recursos a la adopción o definición de estándares de calidad los resultados alcanzados no cubren las expectativas, ya que la productividad es baja, la cantidad de recursos a consumir es casi impredecible y el resultado casi nunca tiene la calidad y profesionalidad requerida. Desde las primeras etapas en el ciclo de vida de un software se pueden comenzar a planificar las pruebas a realizar (Everett, 2007; Pressman, 2005) incluso antes de llegar a la etapa de codificación, con esto se evita insertar errores en la aplicación que pueden volverse muy difíciles de encontrar en fases posteriores.
A pesar de constituir una buena práctica, muy pocos se acogen a esta idea y comienzan a pensar en las pruebas sólo después de tener el código. La mayoría de los equipos de desarrollo de software cuentan con tiempo limitado para la creación de pruebas minuciosas y bien planificadas, lo cual trae consigo que se ejecuten fundamentalmente pruebas funcionales y sin una planificación previa. Bajo estas condiciones puede pensarse en trabajar sobre la acumulación, en la computadora, de la experiencia que se obtiene en cada una de las pruebas, de forma tal que se disponga de un banco de casos para apoyar la fase de pruebas en nuevos proyectos, y en particular la generación de casos y procedimientos de prueba partiendo de otros que se han utilizado antes y que han permitido detectar defectos en proyectos previos.
Diferentes metodologías en desarrollo de software incluyen las pruebas, y algunas hacen más énfasis en ellas, como es el caso del desarrollo guiado por pruebas —en inglés Test-Driven Development— (Augustine, 2005) y otras lo ven como una fase del desarrollo que debe garantizar la calidad del producto final (Jacobson, 2004), pero todas las propuestas coinciden en que es un tema de suma importancia y debe planificarse desde las etapas tempranas de desarrollo del software. Varios trabajos refieren la importancia de estimar el esfuerzo asociado a las pruebas para decidir su automatización o ejecución en cada caso (Singh y Misra, 2008), así como la automatización de pruebas en entornos específicos (Xie y Memon, 2007; Masood, Bhatti, Ghafoor y Mathur, 2009; (KO y Myers, 2010). Existe un conjunto de propuestas que abordan directamente el tema de la reducción de casos de prueba (Heimdahl, 2004; Mogyorodi, 2008; Polo, 2005; Black, 2004; éstas utilizan algoritmos donde es vital disponer del tiempo necesario para la etapa de pruebas, siendo esto a veces imposible.
Esta es una versión de prueba de citación de documentos de la Biblioteca Virtual Pro. Puede contener errores. Lo invitamos a consultar los manuales de citación de las respectivas fuentes.
Artículo:
Detección de cambios en edificios antiguos a partir de escaneado láser terrestre e imágenes hiperespectrales
Artículo:
Uso indirecto del método de medición de distancia y error por cámaras ópticas individuales
Artículo:
Miniaturización de una antena de parche microstrip con un contorno fractal de Koch utilizando un algoritmo de araña social para optimizar la posición del poste de cortocircuito y la alimentación de la inserción
Artículo:
Evaluación y predicción del rendimiento de los receptores superheterodinos basada en la distancia de Mahalanobis y el análisis de la secuencia temporal
Artículo:
Espectroscopia de impedancia de microondas y efectos de temperatura en las propiedades eléctricas de interfaces Au/BN/C