Fundamentos de Ingeniería de Software
Educación a distancia
Ingeniería en Sistemas Computacionales Fundamentos de Ingeniería de Software
Semana 15 Unidad 5. Modelo de Implementación. 5.3.
Modelos de pruebas
Antología realizada por: M.C. Gricelda Rodríguez Robledo
Semana 15
Educación a distancia
Fundamentos de Ingeniería de Software
CONTENIDO 5.3 Pruebas del Software ...................................................................................................................... 4 5.3.1 ¿Qué son las pruebas de software?........................................................................................ 4 5.3.2 ¿Por qué probar el software a desarrollar? ............................................................................ 5 5.3.3. ¿Qué ventajas tiene la creación de pruebas para el desarrollo de software? ....................... 5 5.3.4 ¿Quién debe realizar las pruebas?.......................................................................................... 6 5.3.5 Principios de las pruebas ........................................................................................................ 7 5.3.6 Objetivos De Una Prueba ....................................................................................................... 7 5.3.7 Planeación de las pruebas. .................................................................................................... 8 5.3.8 Proceso. .................................................................................................................................. 8 5.3.9. Clasificación de las pruebas .................................................................................................... 9 Pruebas del camino básico. .......................................................................................................... 9 Pruebas de Unidad........................................................................................................................ 9 Análisis de valores límite (AVL). .................................................................................................. 10 Caja Blanca. ................................................................................................................................. 10 Pruebas de cubrimiento. ............................................................................................................ 10 Pruebas de Integración. .............................................................................................................. 11 Prueba de recuperación: ............................................................................................................ 13 Prueba de seguridad: .................................................................................................................. 13 Referencias ......................................................................................................................................... 13
Semana 15
Educación a distancia
Fundamentos de Ingeniería de Software
Competencia específica a desarrollar
Actividades de Aprendizaje
Identificar procesos implementación.
de
la
fase
de
• Aplicar al menos una herramienta CASE para generar código en algún lenguaje de programación a partir del diseño previo. • Investigar sobre las técnicas de pruebas y su clasificación. • Discutir sobre los métodos de implementación de las empresas de desarrollo de software de su entorno.
Semana 15
Educación a distancia
Fundamentos de Ingeniería de Software
5.3 PRUEBAS DEL SOFTWARE 5.3.1 ¿QUÉ SON LAS PRUEBAS DE SOFTWARE? Las pruebas, vistas desde el marco de un proceso de desarrollo de software, son los diferentes procesos que se deben realizar durante un desarrollo, con el objetivo de asegurar que este completo, correcto, tenga calidad, entre otros factores de gran importancia. Consisten en llevar a cabo la verificación dinámica de un componente, programa o sistema, mediante el uso de métodos, técnicas y herramientas especializadas, las cuales permiten detectar y corregir errores, problemas e inconsistencias durante el proceso de desarrollo. Estas, al contrario de lo que muchas personas creen, no se deben dejar para el final de la etapa de construcción del software. Las pruebas se deben empezar a realizar desde la misma etapa de análisis de los requerimientos, ya que desde un principio se puede caer en malas interpretaciones de las "reglas del negocio", lo que finalmente tendrá como consecuencia incongruencia entre lo que el cliente quiere y lo que se ha desarrollado.
Semana 15
Educación a distancia
Fundamentos de Ingeniería de Software
5.3.2 ¿POR QUÉ PROBAR EL SOFTWARE A DESARROLLAR ? Debido a que los procesos serios de desarrollo de software, en la mayoría de los casos tienden a ser caóticos, es necesario involucrar procesos de aseguramiento de la calidad, para que se puedan cumplir de manera correcta los requerimientos que el cliente necesita. Por otro lado, el costo que implica reparar un defecto que es descubierto en etapas avanzadas del desarrollo de software, tal como la implementación, es muy alto, hablando en términos del presupuesto del proyecto, como también en el cronograma. Por tal razón, se implementan las pruebas de software desde los comienzos del desarrollo.
5.3.3. ¿QUÉ VENTAJAS TIENE LA CREACIÓN DE PRUEBAS PARA EL DESARROLLO DE SOFTWARE? Principalmente, las ventajas que trae la realización de pruebas, en un desarrollo de software son las siguientes: •
Reducen la posibilidad de agregar defectos al software. Si hay que realizar una adición de características requeridas por el cliente y se ve que ya no funcionan bien algunas de las cosas que anteriormente servían, se puede inferir la nueva funcionalidad es la que contiene defectos, por lo que no hay necesidad realizar modificaciones a los componentes realizados anteriormente.
•
Reducen la posibilidad de encontrar defectos en funcionalidades ya implementadas.
•
Las pruebas son buena documentación. Es preferible ver unas pequeñas líneas de "Código de prueba", que son concisas y realmente son fáciles de entender, a revisar línea por línea de código para poder entender que hace determinado componente de software.
•
Reducen el costo del cambio. Ya que evitan que se descubran los defectos hasta el final del desarrollo de software.
•
Permiten realizar reimplementación. Se puede llegar a necesitar reimplementar determinada funcionalidad en un sistema, debido a fallos de seguridad, rendimiento, o
Semana 15
Fundamentos de Ingeniería de Software
Educación a distancia
•
•
simplemente por que no reunía lo que el cliente esperaba de éste, entonces dada tal situación, las pruebas que a realizar a dicha funcionalidad van a permitir que se vuelva a desarrollar de manera segura, ya que la prueba encierra el criterio de aceptación sobre la funcionalidad, permitiendo de esta forma que se vuelva a desarrollar algo acorde con la especificación. Restringe las características a implementar. Muchas veces los programadores pierden tiempo en detalles que la especificación no pedía. Con las pruebas el programador sabe que tiene que programar dicha funcionalidad y también probarla, por lo que se restringe a lo que los diseñadores de las pruebas hayan realizado. Hacen que el desarrollo sea más rápido. Ya que a medida que se agregan características al software, las funcionalidades anteriores pueden fallar, pero si se han hecho las pruebas pertinentes a las funcionalidades anteriores, se puede descartar inmediatamente que existan defectos en éstas, por lo que se puede concentrar tranquilamente en la funcionalidad nueva.
5.3.4 ¿QUIÉN DEBE REALIZAR LAS PRUEBAS? Las pruebas deben ser diseñadas y ejecutadas por personal diferente al que realizó el análisis de las reglas del negocio, también de las personas que realizaron los diseños y principalmente, deben ser diferentes a las que realizaron la labor de programación.
En la labor de desarrollo de software existen varios roles que cumplen los integrantes del proyecto, entre esos los siguientes: Analistas, Diseñadores y Programadores: Este grupo de personas poseen un punto de vista creativo, ya que ellos son los que a partir de una necesidad del cliente, diseñan, analizan y codifican una solución informática. Debido a esa situación ellos no alcanzan a divisar los posibles defectos que tiene el software que ellos realizaron.
Semana 15
Educación a distancia
Fundamentos de Ingeniería de Software
Analista de Calidad: Ellos se enfocan en entender las reglas del negocio, requerimientos, casos de uso y todas aquellas cosas que ayuden a comprender el negocio. Este grupo de personas poseen por decirlo de alguna manera un punto de vista destructivo, ya que ellos saben que determinada parte del programa tiene que llevar a cabo ciertas funciones, y ellos en su quehacer tratan de encontrar defectos a la funcionalidad realizada por otra persona.
5.3.5 PRINCIPIOS DE LAS PRUEBAS 1. A todas las pruebas se les debería poder hacer un seguimiento hasta los requerimientos del cliente/usuario. 2. Las pruebas deberían planificarse antes de que empiecen. La planificación de las pruebas puede empezar cuando estén completos los requerimientos. 3. Las pruebas deberían empezar de lo individual a lo general. A) Módulos individuales B) Grupos de módulos integrados C) Sistema total. 4. Para ser más efectiva las pruebas deberían ser conducidas por un equipo independiente.
5.3.6 OBJETIVOS DE UNA PRUEBA •
Cuáles son las alternativas para verificar y validar software
•
Qué son las pruebas de software
•
Conocer la utilidad de las pruebas unitarias
•
Conocimientos básicos de cómo hacer pruebas unitarias
•
Idea básica sobre desarrollo guiado por pruebas
Semana 15
Educación a distancia
Fundamentos de Ingeniería de Software
5.3.7 PLANEACIÓN DE LAS PRUEBAS. En este punto se deben de cubrir ciertos puntos para realizar las pruebas: • • • • • • • • • •
Conocer el propósito de la prueba. Definir el lugar, fecha y duración de la misma. Determinar el hardware y software necesarios para llevarse a cabo. Definir el estado del sistema al iniciar la prueba. Integrar facilitadores y nivel de participación. Definir a los usuarios participantes. Especificar las tareas a desarrollar por los usuarios. Establecer criterios de terminación de tareas. Crear materiales de apoyo para usuarios. Especificar métodos de recolección y análisis de datos resultantes.
5.3.8 PROCESO. Las pruebas de software son una tarea técnica, y como tal son un proceso que, en primer lugar, necesita del dominio del lenguaje de programación en el que el producto que se va a checar fue creado, también del conocimiento indispensable para comprender la arquitectura del sistema implementado además de las implicaciones de tipo lógico que el diseño pueda suponer. Adicionalmente, la persona que lo pruebe deberá conocer los lenguajes y herramientas que se han de usar para llevar a cabo este proceso de pruebas. Las pruebas de software son elementos básicos para determinar la calidad del software. La relevancia de los costos asociados a los errores conllevan a la definición y aplicación de un proceso de pruebas minuciosas y bien planificadas. Las pruebas permiten validar (proceso que determina si el software satisface los requisitos previamente establecidos) y verificar (proceso para determinar si los productos de un fase satisfacen las condiciones de ésta) el software.
Semana 15
Educación a distancia
Fundamentos de Ingeniería de Software
5.3.9. CLASIFICACIÓN DE LAS PRUEBAS PRUEBAS DEL CAMINO BÁSICO. Propuesta por Tom McCabe, permite al diseñador de casos de prueba que pueda obtener una medida de la complejidad lógica en un diseño procedimental y usar ésta como guía para llegar a definir un conjunto elemental de caminos de ejecución. Los casos de prueba derivados de éste último garantizan que durante la prueba se ejecuta por lo menos una vez cada sentencia de programa. Un camino independiente es cualquier camino del programa que introduce por lo menos un nuevo conjunto de sentencias de procesamiento o una nueva condición.
PRUEBAS DE UNIDAD. Las pruebas unitarias tienen como objetivo verificar la funcionalidad y estructura de cada componente individualmente una vez que ha sido codificado.
CAJA NEGRA. Son pruebas que se llevan a cabo directamente en la interfaz del software. Se comprueba el correcto funcionamiento de los componentes del sistema de información, analizando las entradas y salidas y verificando que el resultado es el esperado. Se consideran exclusivamente las entradas y salidas del sistema sin preocuparse por la estructura interna del mismo. Errores que se pretenden detectar: funciones incorrectas o ausentes, errores de interfaz, errores en las estructuras de datos, errores de rendimiento, errores de inicialización y terminación. Algunos tipos son:
PARTICIÓN EQUIVALENTE . Es un método que divide el campo de entrada de un programa en clases de datos de los que se pueden derivar casos de prueba. Un caso de prueba correcto descubre de manera inmediata una clase de errores. Se dirige a la definición de casos de prueba que descubran clases de errores, reduciendo así el número de casos de prueba que hay que desarrollar. El diseño de estos casos se basa en una evaluación de las clases de equivalencia para una condición de entrada. Una clase de equivalencia representa un conjunto de estados válidos o inválidos para condiciones de entrada.
Semana 15
Educación a distancia
Fundamentos de Ingeniería de Software
ANÁLISIS DE VALORES LÍMITE (AVL). Esta técnica es un complemento para la anterior. En lugar de seleccionar cualquier elemento de una clase de equivalencia, se lleva a la elección de casos de prueba a los extremos de la clase. En lugar de centrarse únicamente en las condiciones de entrada, también se derivan casos de prueba para el campo de salida.
CAJA BLANCA. Se prueban procedimientos del software. Se verifica la estructura interna del componente con independencia de la funcionalidad establecida para el mismo. Por tanto, no se comprueba la corrección de los resultados, sólo si éstos se producen. Algunas clases de pruebas:
PRUEBAS DE CUBRIMIENTO.
P RUEBAS DE CONDICIONES . Es un método de diseño de casos de prueba que ejercita las condiciones lógicas contenidas en un módulo de un programa. Se basa en el criterio de que si un conjunto de pruebas de un programa es efectivo para detectar errores en las condiciones que se encuentran en el programa, es probable que el conjunto de pruebas sea también efectivo para detectar otros errores en el programa. P RUEBAS DE BUCLES . Los bucles son la parte más importante de la mayoría de los algoritmos implementados en software. Es una técnica que se centra principalmente en la validez de las construcciones de bucles y existen estos tipos de ellos:
Bucles simples Bucles anidados Bucles concatenados Bucles no estructurados
Semana 15
Educación a distancia
Fundamentos de Ingeniería de Software
PRUEBAS DE INTEGRACIÓN. El objetivo de las pruebas de integración es verificar el correcto ensamblaje entre los distintos componentes una vez que han sido probados unitariamente con el fin de comprobar que interactúan correctamente a través de sus interfaces, tanto internas como externas, cubren la funcionalidad establecida y se ajustan a los requisitos no funcionales. En las pruebas de integración se examinan las interfaces entre grupos de componentes o subsistemas para asegurar que son llamados cuando es necesario y que los datos que se transmiten son los requeridos. A SCENDENTE . Es la estrategia tradicional empleada para integrar los componentes de un sistema de software en un todo funcionando. Consiste en pruebas de unidad, seguidas por pruebas de subsistemas y luego por pruebas del sistema completo. Las primeras tienen el objetivo de descubrir errores en los módulos individuales del sistema. Las pruebas de unidad deben ser tan exhaustivas como sea posible para garantizar que se ha probado cada caso representativo manejado por cada módulo. dichas pruebas se facilitan por una estructura que se componga de módulos pequeños y débilmente acoplados. D ESCENDENTE . Empieza con la rutina principal y una o dos rutinas inmediatamente subordinadas en la estructura del sistema. después de que el esqueleto de alto nivel ha sido probado con detenimiento, se convierte en el arreo de prueba para sus subrutinas inmediatamente subordinadas. La integración de alto nivel requiere el uso de troncos de programa para simular el efecto de rutinas de más bajo nivel que son llamadas rutinas en prueba. R EGRESIÓN . Son una estrategia de prueba en la cual las pruebas que se han ejecutado anteriormente se vuelven a realizar en la nueva versión modificada, para asegurar la calidad después de añadir la nueva funcionalidad. El propósito de estas pruebas es asegurar que: Los defectos identificados en la ejecución anterior de la prueba se ha corregido.
Semana 15
Educación a distancia
Fundamentos de Ingeniería de Software
Los cambios realizados no han introducido nuevos defectos o reintroducido defectos anteriores. La prueba de regresión puede implicar la re-ejecución de cualquier tipo de prueba. Normalmente, las pruebas de regresión se llevan a cabo durante cada iteración, ejecutando otra vez las pruebas de la iteración anterior.
PRUEBAS DE VALIDACIÓN. La validación se logra cuando se logran cumplir las expectativas que tiene el cliente al cual se esta desarrollando el producto y se lleva a cabo mediante algunas pruebas como: A LFA . Es una prueba que es llevada a cabo por un cliente en el mismo lugar en el que se desarrollo el producto. Se usa el software de manera normal pero con algún encargado del desarrollo checando el uso que le da el usuario y registrando errores y problemas con su uso. Este tipo de pruebas se llevan a cabo en un entrono controlado. B ETA . Esta prueba se lleva a cabo, en uno o más lugares, por los que serán los usuarios finales del software. A diferencia de la anterior prueba, el encargado del desarrollo, regularmente, no se encuentra presente. La prueba es una aplicación del software en un entorno que no puede ser controlado por el equipo de desarrollo, para poder darle más realismo al funcionamiento del software o sistema. El cliente registra todos los fallos y/o problemas (reales o imaginarios) que llegue a encontrar y los informa regularmente. Con base en éstos, el equipo de desarrollo lleva a cabo modificaciones y así prepara una versión mejorada del producto. P RUEBAS DEL S ISTEMA . Las pruebas del sistema implican dos clases de actividades: pruebas de integración y pruebas de aceptación. Las estrategias para integrar los componentes del software en un producto que funcione incluyen las estrategias ascendente, descendente y de emparedado. Se requiere de una cuidadosa planeación y programación a tiempo para asegurar que los módulos estarán disponibles para su integración dentro del producto de software en desarrollo, cuando se necesiten. La estrategia de integración dicta el orden en que los módulos deben estar disponibles, por lo que ejerce gran influencia en el orden en que se escriben, depuran y hacen las pruebas de unidad de los módulos. Las pruebas de aceptación implican la planeación y ejecución de pruebas funcionales, de desempeño y de tensión para verificar que el sistema realizado satisfaga sus requisitos. Las pruebas de aceptación suelen realizarlas las organizaciones de control de calidad, los clientes o ambos.
Semana 15
Educación a distancia
Fundamentos de Ingeniería de Software
Dependiendo de las circunstancias, locales, el grupo de desarrollo puede o no estar relacionado con las pruebas de aceptación. Algunas son:
PRUEBA
DE VALIDACIÓN : Proporciona una
seguridad final de que el software satisface todos los requerimientos funcionales y de rendimiento. Además, valida los requerimientos establecidos comparándolos con el sistema que ha sido construido. Durante la validación se usan exclusivamente técnicas de prueba de caja negra.
PRUEBA DE RECUPERACIÓN: Fuerza un fallo del software y verifica que la recuperación se lleva a cabo apropiadamente.
PRUEBA
DE SEGURIDAD : Verificar los mecanismos de protección y es una herramienta técnica al
análisis de riesgos que proporciona una clara visión referente al nivel de vulnerabilidad y exposición de la plataforma tecnológica. P RUEBA DE RESISTENCIA : Enfrenta a los programas a situaciones anormales. P RUEBA DE RENDIMIENTO : Prueba el rendimiento del software en tiempo de ejecución. P RUEBA DE INSTALACIÓN : Se centra en asegurar que el sistema software desarrollado se puede instalar en diferentes configuraciones hardware y software y bajo condiciones excepciones, por ejemplo con espacio de disco insuficiente o continuas interrupciones.
REFERENCIAS Sommerville, Ian. "Ingeniería del Software", Capítulo 23. 7ª Edición, Pearson-Addison Wesley, 2005. Pressman, R.S."Ingeniería del Software: un enfoque práctico", Capítulos 13 y 14.6ª Edición, McGraw-Hill. Massol, Vicent. "JUnit in Action”, Manning.
Semana 15