Como ya se ha descrito el proceso de prueba de software es una actividad que implica varias consideraciones, por lo que una decisión crítica y primordial es la de establecer la manera en que se realizarán las pruebas. Algunas preguntas que ayudarán a establecer una estrategia adecuada son: 17
¿Qué componentes deben probarse? ¿De qué manera se deben probar? ¿Qué se espera de la prueba?
Estas preguntas implican la consideración del tiempo a invertir en las pruebas, el cual aumenta proporcionalmente de acuerdo al número de componentes a probar, el personal involucrado y la cantidad de cambios en el software y la complejidad del producto.
Respecto de las pruebas que se pueden realizar en un producto de software, de manera general se pueden clasificar de la siguiente manera:
• Pruebas estáticas • Pruebas dinámicas 17
CAPITULO 2 MARCO TEÓRICO 25 • Pruebas de integración
Las pruebas estáticas en general se utilizan para las pruebas unitarias, que revisan principalmente la estructura del código fuente, ayuda a encontrar errores de lógica en el programa y permite revisar las prácticas de programación. Algunas de las limitaciones en las pruebas estáticas son: su difícil aplicación en programas muy grandes y no permite la detección de errores en tiempo real.
Las pruebas dinámicas se enfocan en la ejecución del programa y la comparación de resultados respecto de las especificaciones, dentro de este rubro se puede dividir dos tipos de pruebas dinámicas:
• Funcionales • Lógicas
Las pruebas funcionales verifican que el programa se ejecute adecuadamente bajo condiciones operacionales típicas, de manera que el proceso realizado de acuerdo a una entrada y la salida generada correspondan a las especificaciones del programa (desde el punto de vista de caja negra).
La prueba lógica evalúa como se ejecuta el programa desde el punto de vista interno (caja blanca), en general se trata de probar las diversas condiciones y posibles valores para éstas, sin embargo esto es difícil de conseguir por la magnitud de posibilidades. Este tipo de prueba también verifica: los datos y el control interno entre las diferentes unidades que componen el programa, el tiempo de ejecución y de respuesta de los procesos, tiempo de uso del procesador, accesos a red, envío y recepción de información de forma remota.
Respecto de las pruebas de integración evalúan y verifican los diversos módulos que componen al sistema, este tipo de pruebas permite detectar errores en las interfaces,
CAPITULO 2 MARCO TEÓRICO 26
interconexiones, en los tiempos de respuesta totales en el desempeño final del sistema y los estándares de calidad. Dentro de este rubro se tiene otro tipo de prueba que es la prueba de aceptación o certificación que consiste en examinar al sistema en condiciones reales, en un ambiente diferente al de desarrollo y probar desde la instalación, la configuración y la ejecución del producto de software bajo condiciones acordes a las especificaciones en un entorno similar al del uso destinado.
La cantidad, complejidad y diversidad de pruebas a realizar, van muy de la mano con el costo a invertir en esta actividad, el personal disponible y el tiempo en el que se pretenda realizar esta etapa, por lo general es una de las etapas más costosas dentro del ciclo de vida del software. Por lo que es importante considerar una estrategia adecuada en la forma de realizar las pruebas. Algunas propuestas de estrategia son las siguientes:
• Planeación, diseño, ejecución y mantenimiento.18
• Decisión para automatizar pruebas, herramienta de prueba, introducción al proceso de pruebas automatizadas, planeación, diseño y desarrollo de pruebas, Ejecución y manejo de pruebas y revisión/valoración.19
• Pruebas unitarias, pruebas de Integración, validación de pruebas.20
• Planeación de la prueba, prueba de requisitos, pruebas del diseño, pruebas en el desarrollo y, pruebas en la implementación21
Estas estrategias de diferentes autores se pueden englobar en tres procesos, la planeación, el diseño y la ejecución. La diferencia notable dentro de estos elementos, es que se aplican en
18
Goglia, Patricia. 1993. Testing client/server applications. USA: QED Publishing group.
19
Dustin, Elfriede. Jeff Rashka. John Paul. 1999. Automated software testing: introduction, management and performance. Boston: Addison-Wesley.
20
Pressman, Roger S. 2005. Software Engineering.
21
CAPITULO 2 MARCO TEÓRICO 27
diferentes momentos en el ciclo de vida del desarrollo de software. Por lo que se puede observar la diversidad en los procesos a seguir, e inclusive algunos autores tratan a la etapa de prueba, como un ciclo de vida por si mismo.
2.6.1 Estrategias para prueba de integración
Existen dos tipos de estrategias para realizar pruebas que verifiquen la integración de módulos o unidades de software en un sistema22. Una es la estrategia llamada “big bang” o no incremental,
la otra es denominada incremental que a su vez se divide en dos: “bottom up” (descendente) y “top down” (ascendente). En la estrategia ”big bang” se prueban todos los módulos, lo cual implica una revisión exhaustiva, que como se mencionó previamente se descarta esta posibilidad, lo que nos deja dos posibles estrategias que en seguida se mencionan brevemente:
Estrategia “bottom up” consiste en revisar los módulos de más bajo nivel de la estructura de software hasta llegar al de mayor nivel o nivel principal. La ventaja a destacar de esta estrategia es su relativa facilidad de ejecución, su desventaja consiste en la tardanza de poder observar al sistema como un todo.
Estrategia “top-down” consiste en iniciar la revisión con el módulo principal y subsecuentemente los módulos de más bajo nivel. La principal ventaja de esta estrategia es la posibilidad de mostrar las funciones del programa en un corto periodo (una vez que se ha revisado el módulo principal), en muchas ocasiones esta característica permite una temprana identificación de errores en el análisis y diseño relativo a los algoritmos y requerimientos funcionales. La principal desventaja es la relativa dificultad en el análisis de resultados.
22
Piattini Velthuis, Mario G. [et al]. Analisis Y Diseño Detallado De Aplicaciones Informáticas De Gestión. México:
CAPITULO 2 MARCO TEÓRICO 28
Para este trabajo se utilizará la estrategia “top down” ya que permite visualizar un proyecto como un todo funcional, para realizar las pruebas de software, esta característica es el elemento relevante y en común con el modelo de prototipo, que en sus etapas tempranas están construidos solamente aquellos módulos que son esenciales para mostrar las características mas importantes del proyecto.
2.6.2 Enfoques de prueba
El enfoque de prueba, hace énfasis en ciertos aspectos de la prueba con relación directa a los requerimientos de calidad de forma estructural o funcional, existen tres enfoques caja blanca, caja negra y caja gris como se mencionó en el Subtema 2.6, en seguida se muestra los casos en que es factible utilizar cada enfoque23.
Enfoque de caja blanca
Cuando se requiere tener un alto grado de certeza en la aplicación de estándares, mejores prácticas, aplicaciones de alta seguridad y críticas en cuanto su funcionamiento, optimización de código e inclusive en la remoción de comentarios (ya sea informativos o líneas de código comentariadas) innecesarios, el enfoque de caja blanca o también llamado estructural es una buena opción. En etapas muy tempranas de desarrollo cuando prácticamente se tienen solo unidades funcionales de software, este enfoque es muy adecuado.
Enfoque de caja negra
Este enfoque se utiliza principalmente, para pruebas de exactitud de datos de salida. Cuando en el proyecto no se pondrá énfasis en la estructura interna sino en la funcionalidad y
23
CAPITULO 2 MARCO TEÓRICO 29
comportamiento del sistema, este enfoque es adecuado. A pesar de la desventaja de requerir una gran cantidad de casos de prueba, para poder verificar de forma aceptable la funcionalidad, salida e intercambio de datos en un sistema, existen alternativas que proporcionan un grado adecuado de confiabilidad y reducen en gran medida los casos de uso necesarios, teniéndose como consecuencias, reducción en los costos y optimización en el proceso de prueba.
Enfoque de caja gris
Es una combinación de caja blanca y negra que consiste en una revisión estructural pero limitado a una porción de código que puede ser importante analizar y además, probar el comportamiento de la unidad de software que se este revisando con la finalidad de observar los elementos de diseño y los resultados esperados. En general, este enfoque se utiliza sólo para ciertas unidades cuyo detalle de prueba sea mayor, tanto para la estructura interna como el entorno.
Algunas ventajas y desventajas de cada enfoque que pueden ayudar para tomar una decisión de cual utilizar se muestran en la tabla 2.1 y2.2:
Enfoque de caja blanca
Ventajas Desventajas • Se revisa directamente cada línea de código (en
función de las rutas a probar) y a su vez los algoritmos utilizados.
• Se puede identificar las líneas de código que no se ejecutan en los casos de pruebas y ejecutar los casos de prueba pertinentes si es necesario. • Permite determinar la calidad de la codificación
y el apego a los estándares de codificación
• Se requiere una gran cantidad de recursos para ejecutar este enfoque
• No se puede probar el desempeño en términos de disponibilidad (tiempo de respuesta), confiabilidad y otras pruebas relativas a la operación, revisión y factores de transición.
CAPITULO 2 MARCO TEÓRICO 30
Enfoque de caja negra
Ventajas Desventajas • Permiten realizar la mayoría de
los tipos de pruebas (sin necesidad de usar otro enfoque). • Algunas pruebas, también se
pueden realizar con caja blanca, sin embargo requieren menos recursos.
• Es posible que la agregación de errores coincida con una respuesta correcta para un caso de prueba en particular e impida la detección de errores.
• Ausencia del control en el alcance, cuando el encargado de realizar la prueba intenta mejorar la línea de alcance, no existen los mecanismos para especificar los parámetros en los casos de prueba para dicha mejora. Por lo anterior, puede no ejecutarse proporciones substanciales de líneas de código.
Imposibilita la prueba de calidad de la programación y su apego a estándares.
Tabla 2.2 Ventajas y desventajas del enfoque de caja negra