Universidad Don Bosco. Facultad de Ingeniería. Escuela de Computación. Ingeniería de Software

Transcripción

1 Universidad Don Bosco Facultad de Ingeniería Escuela de Computación Ingeniería de Software Facilitador: Ing. Milton J. Narváez Sandino Ingeniería de Software, 7a edición: Capítulo 23: Prueba del software Autor: Ian Sommerville Estudiantes: Flamenco Quijada, Víctor Manuel Gómez Hernández, Kevin Ernesto Serpas González, Josué Alejandro Ciudadela Don Bosco, 25 octubre de 2014

2 Prueba del software En el ámbito del desarrollo de software, uno de los aspectos más cruciales y determinantes es la prueba del software. Dependiendo de la complejidad del sistema, las pruebas del software van desde unidades de programas individuales hasta la integración de cada una de las unidades, generando componentes y éstos a su vez, conformando el sistema en su totalidad. Fundamentalmente, el proceso de pruebas del software se puede separar en dos actividades concretas las cuales son la prueba de componentes y las pruebas de sistema. En la práctica, cada una de estas actividades se realiza buscando demostrar al desarrollador y al cliente que el software satisface sus requerimientos, así mismo se busca descubrir defectos en el software en el que el comportamiento de éste es incorrecto, o que no cumpla completamente con su especificación. Básicamente, el demostrar que el programa cumple con los requerimientos conlleva a realizar pruebas de validación; por otra parte, encontrar los posibles defectos en software conduce a realizar tareas de pruebas de defectos, en los que los casos de prueba se utilizan para exponer defectos. Pruebas de componentes La primera fase del proceso de prueba del software comienza por las pruebas de componentes individuales, donde se busca validar cada uno de los componentes del software de acuerdo con la funcionalidad con la que haya sido especificado previamente dicho componente, así mismo se busca descubrir los posibles defectos que tenga cada uno de los componentes. Cabe mencionar también que las pruebas de componentes realizadas por los desarrolladores se basan normalmente en una suposición de cómo dichos componentes deberían de operar. Existen diferentes tipos de componentes que pueden probarse, tales como funciones o métodos dentro de un objeto, clases de objetos que tienen varios atributos y métodos, y componentes compuestos formados por diferentes objetos, conocidos como interfaces. Para probar funciones, basta con realizar llamadas utilizando diferentes parámetros de entrada. Por otro lado, al probar objetos se deben considerar pruebas aisladas de todas las operaciones asociadas con él, la asignación y consulta de todos los atributos del objeto y la simulación de todos los eventos que provoquen un cambio de estado en el objeto. Cabe mencionar que cuando se están realizando pruebas orientadas a objetos, se deben diseñar dichas pruebas da tal manera que se pueda cubrir todas las características del objeto, por tanto algunos de los pasos recomendados a seguir para realizar dichas pruebas son los siguientes:

3 1. Se debe realizar pruebas aisladas de todas las operaciones asociadas con el objeto específico. 2. Se deben asignar y consultar todos los atributos por los que está conformado el objeto. 3. Realizar pruebas de ejecución de cada uno de los estados posibles del objeto, es decir, se deben simular todos los eventos que provoquen un cambio determinado en el estado del objeto que está siendo probado. o Pruebas de interfaces A diferencia de los objetos, las funciones o rutinas, las interfaces son un conjunto de componentes formados por varios objetos que interactúan. Las pruebas de estos componentes se ocupan de probar que su interfaz se comporta de acuerdo a su especificación. Las pruebas de interfaces se utilizan en el desarrollo orientado a objetos y basado en componentes. Los objetos y componentes se definen por sus interfaces y pueden ser reutilizados combinados con otros componentes en distintos sistemas. Existen diferentes tipos de interfaces entre los componentes del programa. Pueden ser de parámetros, de memoria compartida, procedurales y de paso de mensajes. Dentro de los sistemas, complejos, una de las formas de errores más frecuente son los errores de interfaces, debido a su no comprensión, su mal uso o errores temporales. Las pruebas para encontrar defectos en las interfaces son difíciles debido a que algunos defectos de las interfaces sólo se manifiestan en extrañas condiciones. Posteriormente a la etapa de prueba de componentes, el trabajo se pasa a un equipo de integración que integra los módulos de los diferentes desarrolladores, construye el software y prueba el sistema como un todo, ésta fase se le conoce como prueba del sistema. Pruebas del sistema Las pruebas del sistema se ejecutan al integrar componentes que implementan funciones del sistema o características del mismo. Los sistemas complejos requieren de dos fases de pruebas del sistema: las pruebas de integración y las pruebas de entregas. Las pruebas de integración se realizan sobre sistemas compuestos por grupos de componentes, se encuentran sus defectos identificando qué componentes deben depurarse luego de analizar el código fuente. Por su parte, en las pruebas de entregas se prueba una versión del sistema que se pretende mostrar al cliente; en ella, se valida que el sistema satisface los requerimientos por los que se construyó, asegurando su confiabilidad. o Pruebas de integración Generalmente, para el desarrollo de sistemas se utilizan componentes nuevos desarrollados, componentes reutilizados y componentes comerciales. La integración de componentes supone una prueba de integración, que comprueba que todos ellos funcionan juntos y que se comunican de manera precisa.

4 La integración de componentes se puede dar de dos formas: integración ascendente o integración descendente. La integración ascendente inicia su proceso añadiendo componentes fundamentales que proporcionan servicios comunes a los demás componentes, formando así la estructura completa del sistema. La integración descendente es el proceso inverso: se desarrolla la estructura del sistema total y a ésta se le añaden componentes funcionales. La localización de los errores es la principal dificultad que surge durante las pruebas. Para minimizar la dificultad, Sommerville sugiere utilizar una aproximación incremental para la integración y pruebas. Se debe comenzar integrando una configuración mínima y funcional del sistema y ejecutar las respectivas pruebas, y luego, añadir otros componentes a la configuración mínima construida y ejecutar nuevas pruebas luego de cada incremento. o Pruebas de entregas Tal como se mencionó anteriormente, las pruebas de entregas consisten en validar una entrega que será distribuida a los clientes. Generalmente, se utiliza un proceso de pruebas de caja negra (ver figura 1), analizando las entradas que se proporcionan al sistema y las salidas que éste genera, sin fijarse en el comportamiento interno de las funciones que se ejecutan. Figura 1. Modelo de pruebas de caja negra. Al realizar pruebas del sistema, se debe intentar detectar los defectos del software eligiendo casos de prueba que provoquen comportamientos inesperados, es decir, seleccionando entradas que tienen alta probabilidad de generar fallos de ejecución del sistema. Whittaker recomienda cinco guías que incrementan la probabilidad de encontrar defectos en el sistema: 1. Elegir entradas que fuerzan a que el sistema genere todos los mensajes de error. 2. Diseñar entradas que hacen que los búferes de entrada se desborden. 3. Repetir la misma entrada varias veces. 4. Forzar a que se generen salidas inválidas. 5. Forzar los resultados de cálculos para que sean demasiado grandes o pequeños. Cabe mencionar que una manera óptima de validar los requerimientos del sistema es mediante la realización de pruebas basadas en escenarios, de los cuales se parte para generar casos de prueba y que la información que se va a utilizar y generar tengan un sentido lógico dependiendo de la naturaleza del software.

5 o Pruebas de rendimiento En las pruebas de rendimiento se busca que el sistema sea capaz de soportar la carga a la que estará sometido en un entorno real. Generalmente, se planifican pruebas en las que se incrementa la carga hasta que el sistema no pueda soportarla. Se utiliza un perfil operacional para comprobar si los requerimientos de rendimiento se alcanzaron. Un perfil operacional es un conjunto de pruebas que reflejan el trabajo que debería manejar el sistema. Se debe diseñar este perfil de manera tal que las pruebas se enfoquen en las actividades que más frecuentemente se llevan a cabo en el programa, con el fin de obtener un resultado preciso del rendimiento operacional del sistema. Una forma efectiva de descubrir los defectos es diseñar pruebas alrededor de los límites del sistema. Estas pruebas implican estresar el sistema realizando peticiones fuera de los límites de su diseño. Las pruebas de estrés van realizando pruebas acercándose a la máxima carga del diseño del sistema hasta que falle. Este tipo de pruebas tienen dos funciones: probar el comportamiento de fallo de ejecución del sistema y sobrecargar el sistema para provocar manifestaciones de defectos que normalmente no serían descubiertos. Diseño de casos de prueba Los casos de prueba se diseñan de tal forma que sean efectivos descubriendo defectos en los sistemas y que muestren que el sistema satisface sus requerimientos. El proceso consiste en seleccionar una característica del sistema o componente y se elige un conjunto de entradas que ejecutan dicho componente, se documentan las salidas esperadas o rangos de salida y se diseña una prueba automatizada para verificar si las salidas reales y las esperadas coinciden. Para poder seguir dichas pruebas, puede basarse en requerimientos, en particiones y estructuras. o Pruebas basadas en requerimientos Las pruebas basadas en requerimientos son pruebas de validación y una aproximación sistemática al diseño de casos de prueba en donde el usuario analiza cada requerimiento y se realizan un conjunto de pruebas para cada uno de ellos. Las pruebas de un requerimiento no implican escribir una única prueba. Usualmente se diseñan distintas pruebas para asegurar que el requerimiento es cubierto. o Pruebas de particiones Se basan en identificar todas las particiones para un sistema o componente. Los casos de prueba se diseñan para que las entradas o salidas pertenezcan a esas particiones; pueden realizarse para diseñar casos de prueba para sistemas y componentes. Una partición es un conjunto de clases que se comporta de manera similar.

6 Luego de identificar las particiones, se eligen casos de prueba para cada una de ellas. Sommerville recomienda elegir casos de prueba en los límites de las particiones y casos de prueba cercanos al punto medio de la partición, pues los diseñadores y programadores tienden a considerar valores típicos de entradas. Sin embargo, los límites son valores atípicos y los programas generan fallos regularmente cuando se procesan dichos valores. En ocasiones, cuando se prueba problemas con secuencias, vectores o listas, se deben probar secuencias que sólo tienen un valor, secuencias de diferentes tamaños y se deben generar pruebas para acceder a elementos clave de la lista, como el primero, el último y el central. o Pruebas estructurales Las pruebas estructurales se derivan a partir del conocimiento de la estructura e implementación del software. Estas pruebas se conocen usualmente como pruebas de caja blanca, en donde la identificación de particiones adicionales y casos de prueba se fundamenta en la comprensión del algoritmo utilizado en una componente. Un esquema básico sobre el modelo de pruebas de caja blanca se puede observar en la figura 2. A diferencia de las pruebas de caja negra, en las pruebas de caja blanca si es importante el análisis del funcionamiento interno de la rutina, clase o interfaz. Figura 2. Modelo de pruebas de caja blanca o Pruebas de caminos Las pruebas de caminos son una estrategia de pruebas estructurales que se ejecutan generalmente durante las pruebas de componentes, y tienen como objetivo probar cada camino de ejecución independiente en un componente o programa. Lo que se busca con este tipo de prueba es que todas las sentencias presentes en un componente se ejecuten al menos una vez durante la operación del programa. Es imposible probar todas las posibles combinaciones de todos los caminos en un programa, pues el número de estas combinaciones es infinito, e incluso cuando todas las sentencias del programa se han ejecutado al menos una vez, los defectos pueden aparecer cuando se combinan determinados caminos. Para ejecutar una prueba de caminos, se parte de un grafo de flujo del programa. Éste es un modelo del esqueleto de todos los caminos del programa. Este grafo consiste en nodos que representan decisiones y aristas que representan el flujo de control.

7 La prueba de caminos se asegura de que cada camino independiente en el programa se ejecuta al menos una vez. Se entiende por camino independiente aquel que recorre al menos una nueva arista en el grafo de flujo. Es decir, es aquel que ejecuta decisiones no ejecutadas anteriormente. Automatización de las pruebas Es importante resaltar que la fase de pruebas es costosa y puede ser laboriosa, en especial si el programa es complejo. Sin embargo, existen herramientas que facilitan las pruebas y su uso reduce los costes de las pruebas, y además, puede configurarse y adaptarse para el sistema específico que se está probando. Dichas herramientas cuentan con un banco de pruebas, es decir, un conjunto de herramientas que soportan el proceso de pruebas, entre las cuales se tienen: 1. Gestor de pruebas 2. Generador de datos de prueba 3. Oráculo 4. Comparador de ficheros 5. Generador de informes 6. Analizador dinámico 7. Simulador De las herramientas mencionadas, cabe destacar que la utilización de un analizador dinámico es sumamente útil para realizar las pruebas de caminos, puesto a que éste permite trabajar conjuntamente con compiladores de tal manera que al momento de compilar un componente determinado del sistema para realizar pruebas, se le añaden instrucciones que permiten realizar un conteo del número de veces que una sentencia o función ha sido llamada, permitiendo imprimir perfiles de ejecución, posterior a la realización de casos de prueba particulares de tal manera que sean reveladas secciones del programa que no han sido probadas en dicho caso de prueba.

8 Funcionres individuales o métodos Clases de objetos con varios atributos y métodos Pruebas aisladas de operaciones asociadas Asignación y consulta de todos los atributos asociados Prueba de componentes Tipos de componentes a ser evaluados Simular los posibles estados mediante la provocación de eventos Examinar el código y listar explícitamente cada llamada a un componente externo Comprobar punteros nulos Componentes compuestos con interfaz definida Diseñar prueba que hagan que componente falle Utilizar pruebas de estres Pruebas del software Pruebas de integración Integración ascendente Integración descendente Variar orden de activación de los componentes Errores comunes Mal uso de la interfaz No compresión del la interfaz Datos de entrada Errores temporales Procesamiento Pruebas de caja negra Resultados reales Resultados obtenidos Pruebas del sistema Comparación Resultados esperados Informe de la prueba Elegir entradas que fuerzen todos los mensajes de error Entradas que desborden búferes Actividades Repetición de entradas Pruebas de entregas Forzar salidas no válidas Forzar resultados demasiado grandes o pequeños Pruebas de rendimiento Capacidad de carga Perfil operacional Errores sobre los límites del sistema Basadas en requerimientos Actividades frecuentes Rendimiento esperado Límites de valores de entrada Diseño de casos de prueba Pruebas de particiones Pruebas de caminos Punto medio de partición Secuencia de datos Pruebas estructurales Caja blanca

9 Conclusiones El proceso de prueba del software no solamente es crucial desde el punto de vista del producto final que sea entregado, sino que también debe ser planificado con especial cuidado puesto que es un proceso muy trabajoso y que dependiendo de la complejidad del sistema, los costos totales de las pruebas pueden llegar hasta el 50% del total de los costos de desarrollo del software, así como utilizar una gran cantidad del tiempo de desarrollo solo dedicado al proceso de prueba del mismo, lo cual se traduce finalmente en otros factores muy importantes al momento de la planificación del proyecto de desarrollo. Es por esto que si se puede invertir en herramientas CASE de alta calidad para soportar las pruebas, se estaría logrando retirar parte de la carga que la fase de pruebas del sistema coloca sobre el proyecto. Cabe mencionar que el proceso de prueba del software es determinante para lograr cumplir muchos de los objetivos de la ingeniería de software, como lo es el crear software de calidad, es decir, que el sistema además de ser completamente funcional, genere un sentido de confianza en la información que éste genera, debido a que los procedimientos que realiza han sido previamente probados y validados mediante diversas fases. Es importante mencionar que las pruebas de software no pueden demostrar que el software está libre de defectos o que se comportará en todo momento como está especificado, siempre es posible que exista una prueba que se haya pasado por alto y que se pueda descubrir problemas adicionales con el sistema. Las pruebas software son un proceso que intenta proporcionar confianza en el software, de tal manera que el cliente pueda percibir que el software es lo suficientemente bueno para su uso operacional, por tanto las pruebas de aceptación son fundamentales. Es importante comprender que el hecho de que cada componente del sistema funcione de manera correcta y esté validado, no significa que al integrar todo los componentes, estos se vayan a comportar de la misma manera, puesto a que existen muchos procedimientos o aspectos involucrados en la conexión entre los diversos componentes, en éste sentido las fases de prueba de sistema buscan garantizar que el software completo, como producto final, haya pasado por una serie de pruebas funcionales y no funcionales, y que por tanto se pueda aseverar que puede ser utilizado de manera óptima.

10 Fuentes consultadas IAN SOMMERVILLE. Ingeniería de software. Séptima edición, Enero ISBN: Prentice Hall.