PrólogoConceptos Básicos y estado del arte.

Lic. Ramiro Estigarribia

Estado del arteLa Ingeniería del Software es una nueva área de la Informática, que ofrece métodos y técnicas para desarrollar y mantener software de calidad.

El ingeniero del software comienza a ser una profesión implantada en el mundo laboral internacional, con derechos, deberes y responsabilidades que cumplir, junto a una, ya, reconocida consideración social en el mundo empresarial.

DefinicionesDejinición 1Ingeniería de Software: es el estudio de los principios y metodologías para desarrollo y mantenimiento de sistemas de software [Zelkovitz, 1981].

Definición 2Ingeniería del Software: es la aplicación práctica del conocimiento científico en el diseño y construcción de programas de computadora y la documentación asociada requerida para desarrollar, operar (funcionar) y mantenerlos. [Bohem, 1976].

Pruebas de Software

Descripción y objetivosLas pruebas son prácticas a realizar en diversos momentos de la vida del sistema para verificar:

● El correcto funcionamiento de los componentes del sistema.

● El funcionamiento del hardware y software en el entorno de operación. (Sistema Operativo)

● Que el sistema cumpla con el funcionamiento esperado, desde el punto de vista de su funcionalidad y rendimiento.

● Que los cambios sobre un componente, no introduzcan un comportamiento no deseado en otros. (efectos colaterales).

El ser humano comete erroresEl desarrollo de sistemas implica una serie de actividades de producción en las que las posibilidades de que aparezca el fallo humano son enormes.

Debido a la imposibilidad humana de trabajar y comunicarse de forma perfecta, el desarrollo debe ir acompañado de una actividad que garantice la calidad.

Importancia de las pruebasLas pruebas son un elemento crítico para la garantía de calidad y representa una revisión final de las especificaciones, del diseño y de la codificación.

La creciente percepción del software como un elemento del sistema y la importancia de los costos asociados a un fallo, están motivando la creación de pruebas minuciosas y bien planificadas.

No es raro que una organización emplee entre el 30 y el 40 por ciento del esfuerzo total de un proyecto en las pruebas.

Importancia de las pruebasEn casos extremos, las pruebas del software para actividades críticas (por ejemplo, control de tráfico aéreo,control de reactores nucleares) pueden costar de tres a cinco veces más que el resto del proyecto.

Las pruebas y el Ing.de.Soft.Las pruebas presentan una interesante anomalía para el ingeniero de software:

● Durante las fases anteriores de definición y de desarrollo, el ingeniero intenta construir el software de la mejor manera posible.

● A continuación, llegan las pruebas. El ingeniero crea una serie de casos de pruebas que intentan demoler el software construido.

● Las pruebas son uno de los pasos de la ingeniería del software que se puede ver como destructivo en lugar de constructivo.

Mito de la PerfecciónSi fuéramos realmente buenos programando, no habría errores que buscar.

Según el mito: “Existen errores porque somos malos en lo que hacemos, y si somos malos en lo que hacemos, deberíamos sentirnos culpables por ello”.

Por lo tanto, las pruebas son un reconocimiento de nuestros fallos.

¿Por no conseguir una perfección inhumana?

Objetivos de las pruebas 1. La prueba es el proceso de ejecución de un programa con la intención de descubrir un error.

2. Un buen caso de prueba es aquel que tiene una altaprobabilidad de mostrar un error no descubierto hastaentonces.

3. Una prueba tiene éxito si descubre un error no detectado hasta entonces.

Nos quita la idea de de que una prueba tiene éxito si no descubre errores.

Ventajas de las pruebas El objetivo es diseñar pruebas que sistemáticamente saquen a la luz diferentes clases de errores, con la menor cantidad de tiempo y de esfuerzo.

Si la prueba se lleva a cabo con éxito, se descubrirán fallas y vulnerabilidades.

Como ventaja secundaria, la prueba demuestra hasta qué punto el software funciona de acuerdo con las especificaciones y alcanza los requisitos de rendimiento.

Las prueba No aseguran ausencia de defectosLos resultados que se van recogiendo a medida que se lleva a cabo la prueba, proporciona una buena indicación de la fiabilidad y la calidad.

Pero, la prueba no puede asegurar la ausencia de defectos; sólo puede demostrar que existen defectos en el software.

Principios de las pruebasAntes de la aplicación de métodos para el diseño de casos de prueba efectivos, un ingeniero del software deberá entender los principios básicos que guían las pruebas del software.

Principios de DavisEl autor Davis sugiere un conjunto de principios:

1. A todas las pruebas se les debería poder hacer unseguimiento hasta los requisitos del cliente.Los defectos graves (para el cliente) son aquellos que impiden al programa cumplir sus requisitos.

2. Las pruebas deberían planificarse mucho antes deque empiecen las mismas. Se pueden planificar y diseñar todas las pruebas antes de generar ningún código.

Principios de Davis (cont..)3. El principio de Pareto, nos dice que "el 80% de los fallos de un software es generado por un 20% del código de dicho software, mientras que el otro 80% genera tan solo un 20% de los fallos".

4. Las pruebas deberían empezar por «lo pequeño» yprogresar hacia «lo grande».

5. Para ser más eficaces, las pruebas deberían ser rea-lizadas por un equipo independiente.

6. No son posibles las pruebas exhaustivas de todas las combinaciones posibles del sistema. Es posible, sin embargo, cubrir adecuadamente la lógica del programa.

Principio de ParetoEl principio de Pareto es también conocido como la regla del 80-20 y recibe este nombre en honor a Pareto, quien lo enunció por primera vez.

Así por ejemplo cuando hablamos de los costes de desarrollo podríamos decir que:

"El 20% del esfuerzo de desarrollo (en tiempo y recursos) produce el 80% del código, mientras que el 80% restante es produce tan el 20% del software".

Facilidad de pruebaLa facilidad de prueba es "la medición del nivel de sencillez" con la que se puede probar un sistema.

A veces los programadores están dispuestos ahacer cosas que faciliten el proceso de prueba y una lista de comprobación de posibles puntos de diseño, características, etc.

Puede ser útil a la hora de negociar.

Métricas paramedir la facilidad de prueba 1. Operatividad: Cuando mejor funciona, más eficientemente se puede probar.

2. Observabilidad: Lo que ves es lo que pruebas.Los estados y variables del sistema están visibles ose pueden consultar durante la ejecución. (modo debug).

3. Controlabilidad: Cuando mejor podemos controlar el software, más se puede automatizar y optimizar.El ingeniero de pruebas puede controlar directamentelos estados y las variables del hardware y del software.

Métricas paramedir la facilidad de prueba 4. Capacidad de descomposición: Si el sistema está construido con módulos independientes, podemos aislar más rápidamente los problemas y llevar a cabo mejores pruebas de regresión.

5. Simplicidad: Cuanto menos haya que probar, másrápidamente podremos probarlo.Simplicidad funcional: el conjunto de características es el mínimo necesario para cumplir los requisitos).

6. Estabilidad: Cuanto menos cambios, menos interrupciones a las pruebas.

7. Facilidad de comprensión: Cuanta más información tengamos, más inteligentes serán las pruebas.

Atributos de una 'buena' prueba:1. Una buena prueba tiene una alta probabilidad deencontrar un error. El responsable de la prueba debe entender el software e imaginarse cómo podría fallar.

2. Una buena prueba no debe ser redundante. El tiempo y los recursos para las pruebas son limitados.

3 . Una buena prueba debería ser la mejor de la cosecha. En un grupo de pruebas que tienen propósito similar, se deben seleccionar las mejores.

Diseño de casos de pruebaRecordando el objetivo de la prueba, debemos diseñar pruebas que tengan la mayor probabilidad de encontrar el mayor número de errores con la mínima cantidad de esfuerzo y tiempo.

Sin embargo, muchos ingenieros de software, a menudo tratan las pruebas como algo sin importancia, desarrollando casos de prueba que «parecen adecuados», pero que tienen poca garantía de ser completos.

Diseño de casos de pruebaCualquier producto de ingeniería puede probarse de una de estas dos formas: 1. Conociendo la función para la que fue diseñado el producto, se pueden llevar a cabo pruebas que demuestran que cada función es completamente operativa.2. Conociendo el funcionamiento del producto, se pueden desarrollar pruebas que aseguren que «todas las piezas encajan», o sea, que la operación interna se ajusta alas especificaciones y que todos los componentes internos se han comprobado de forma adecuada.

El primer enfoque de prueba se denomina prueba de caja negra y el segundo, prueba de caja blanca.

Pruebas de Caja NegraCuando se considera el software de computadora, laprueba de caja negra se refiere a las pruebas que se llevan a cabo sobre la interfaz del software.

En otras palabras, los casos de prueba pretenden demostrar que las funciones del software son operativas, que la entrada se acepta de forma adecuada y que se produce un resultado correcto.

Una prueba de caja negra examina algunos aspectos del modelo fundamental del sistema sin tener mucho en cuenta la estructura lógica interna del software.

Pruebas de Caja BlancaLa pruebas de caja blanca del software se basan en elminucioso examen de los detalles procedimentales. (con acceso al código fuente, base de datos, etc)

Se comprueban los caminos lógicos del software proponiendo casos de prueba que ejerciten conjuntos específicos de condiciones y/o bucles.

Se puede examinar el “estado del programa” en varios puntos para determinar si el estado real coincide con el esperado o mencionado.

Pruebas de caja blanca (cont...)A primera vista parecería que una prueba de caja blanca muy profunda nos llevaría a tener “programas cien porcien correctos”.

Todo lo que tenemos que hacer es definir todos los caminos lógicos, desarrollar casos de prueba que los ejerciten y evaluar los resultados.

Lastimosamente, incluso para pequeños programas, el número de caminos lógicos posibles puede ser enorme.

Caja Negra vs Caja Blanca¿Por qué no gastamos, todas nuestras energías solamente en las pruebas de caja negra?

La respuesta se encuentra en la naturaleza misma de los defectos del software.

Los errores de escritura son en su mayoría descubiertos por los mecanismos de comprobación de sintaxis, pero otros permanecerán indetectados hasta que comience la prueba, siendo igual de probable que exista un error tipográfico en un oscuro camino lógico que en un camino principal.

Prueba del camino básicoEl método del camino básico, propuesto por Tom McCabe, permite al diseñador de casos de prueba obtener una medida de la complejidad lógica y usar esa medida como guía para la definición de un conjunto básico de caminos de ejecución.

Garantizan que durante la prueba se ejecuta por lo menos una vez cada sentencia de programa.

Cualquier representación del diseño procedimental se puede traducir a un grafo de flujo.

Prueba del camino básico

La complejidad de este grafo depende del número de caminos independientes del conjunto básico de un programa y nos da un límite superior para el número de pruebas que se deben realizar para asegurar que se ejecuta cada sentencia al menos una vez.

Prueba del camino básico

El grafo permite observar los tres caminos básicos de ejecución:Camino 1: 1-2-5-8-9Camino 2: 1-3-4-5-8-9Camino 3: 1-3-6-7-8-9Camino 4: 1-3-6-9

Complejidad ciclomáticaEs una métrica del software que proporciona una medición cuantitativa de la complejidad lógica de un programa.

El valor calculado como complejidad ciclomática define el número de caminos independientes del conjunto básico de un programa y nos da un límite superior para el número de pruebas que se deben realizar para asegurar que se ejecuta cada sentencia al menos una vez.

Complejidad ciclomáticaEl resultado obtenido en el cálculo de la complejidad ciclomática define el número de caminos independientes dentro de un fragmento de código.

Además determina el número de pruebas que se deben realizar para asegurar que se ejecuta cada sentencia al menos una vez, (if, else, for, while, etc)

Complejidad ciclomáticaSi tenemos en cuenta el siguiente ranking:

1-10 Programa Simple, sin mucho riesgo.11-20 Más complejo, riesgo moderado.21-50 Complejo, Programa de alto riesgo.50 Programa no testeable, Muy alto riesgo.

Complejidad ciclomáticaEl grafo permite observar los cuatro caminos básicos posibles:Camino 1: 1-2-5-8-9Camino 2: 1-3-4-5-8-9Camino 3: 1-3-6-7-8-9Camino 4: 1-3-6-9

En este ejemplo,la complejidad ciclomática = 4.

Pruebas de la Caja NegraLas pruebas de caja negra, también denominada prueba de comportamiento, se centran en los requisitos funcionales del software.

O sea, la prueba de caja negra permite al ingeniero de software obtener conjuntos de condiciones de entrada que ejerciten completamente todos los requisitos funcionales de un programa.

La prueba de caja negra no es una alternativa a las técnicas de prueba de caja blanca. Más bien se trata de unenfoque complementario que intenta descubrir diferentes tipos de errores que los métodos de caja blanca.

Pruebas de la Caja NegraA diferencia de la prueba de caja blanca, que se lleva a cabo previamente en el proceso de prueba, la prueba de caja negra tiende a aplicarse durante fases posteriores.

Ya que la prueba de caja negra centra su atención en el campo de la información.

Las pruebas de Caja Negra responden a preguntas:¿Cómo se prueba la validez funcional?¿Cómo se prueba el rendimiento y el comportamientodel sistema?¿Qué clases de entrada compondrán unos buenoscasos de prueba?¿Es el sistema particularmente sensible a ciertos valo-res de entrada?¿De qué forma están aislados los límites de una clasede datos?¿Qué volúmenes y niveles de datos tolerará el sis-tema?¿Qué efectos sobre la operación del sistema tendráncombinaciones específicas de datos?

Ejemplo, Caja NegraComo ejemplo, consideremos los datos contenidos en una aplicación de automatización bancaria. Este software acepta datos en la siguiente forma:

Código de área: En blanco ó un número de 3 dígitosPrefijo: Número de 3 dígitos que no comience por 0 ó 1Sufijo: Número de 4 dígitosContraseña: Valor alfanumérico de 12 dígitosÓrdenes: "Comprobar", "Depositar","Pagar factura", etc.

Los casos de prueba se seleccionan de manera que se ejercite el mayor número de atributos de cada clase de equivalencia a la vez.

Prueba de comparaciónHay situaciones (por ejemplo, aviónica de aeronaves,control de planta nuclear) en las que la fiabilidad delsoftware es algo absolutamente crítico.

En ese tipo de aplicaciones, a menudo se utiliza hardware y software redundante para minimizar la posibilidad de error.

Cuando se desarrolla software redundante, varios equipos de ingeniería del software separados desarrollan versiones independientes de una aplicación, usando las mismas especificaciones.

Prueba de comparación (cont...)En esas situaciones, se deben probartodas las versiones con los mismos datos de prueba, paraasegurar que todas proporcionan una salida idéntica.

Luego, se ejecutan todas las versiones en paralelo y sehace una comparación en tiempo real de los resultados,para garantizar la consistencia.

Con las lecciones aprendidas de los sistemas redundantes, se sugiere que, para las aplicaciones críticas, se deben desarrollar versiones de software independientes, incluso aunque sólo se vaya a distribuir una de las versiones en el sistema final basado en computadora.

Prueba de la Tabla OrtogonalCuando el número de parámetros de entrada es pequeño y los valores de cada uno de los parámetros está claramente delimitado, es factible realizar esta prueba

En cambio, cuando el número de valores de entrada crece y el número de valores diferentes para cada elemento de dato se incrementa, la prueba exhaustiva se hace impracticable o imposible.

Prueba de la Tabla OrtogonalPara ilustrar la prueba de la tabla ortogonal, considerar unsistema que tiene tres elementos de entrada, X, Y y Z.

Cada uno de estos elementos de entrada tiene tres valores diferentes. Hay 3 x 3 x 3 = 27 posibles casos de prueba.

Pruebas en entornos especializadosA medida que el software de computadora se ha hechomás complejo, ha crecido también la necesidad de enfoques de pruebas especializados.

Los métodos de prueba de caja blanca y de caja negra tratados son aplicables a todos los entornos, pero a veces se necesitan unas directrices y enfoques especiales para las pruebas.

Prueba de interfaces gráficas de usuarioLas interfaces gráficas de usuario (IGUs) presentaninteresantes desafíos para los ingenieros del software.

Debido a los componentes reutilizables provistoscomo parte de los entornos de desarrollo de las GUI,la creación de la interfaz de usuario se ha convertidoen menos costosa en tiempo y más exacta.

Al mismo tiempo, la complejidad de las IGUs ha aumentado, originando más dificultad en el diseño y ejecución de los casos de prueba.

Prueba de interfaces gráficas de usuarioConsiderando el gran número de permutaciones asociadas con las operaciones IGU, sería necesario paraprobar utilizar herramientas automáticas.

Prueba de arquitectura cliente/servidorLa arquitectura cliente/servidor (C/S) representa un desafío significativo para los responsables de la pruebas del software.

La naturaleza distribuida de los entornos clien/servidor, los aspectos de rendimiento asociados con el proceso de transacciones, las complejidades de las redes, y la necesidad de servir a múltiples clientes desde una base de datos centralizada se combinan todos parahacer las pruebas de la arquitectura C/S y el softwareresidente en ellas, considerablemente más difíciles quela prueba de aplicaciones individuales.

Prueba de la documentación y facilidades de ayudaLos errores en la documentación pueden ser tan destructivos para la aceptación del programa, como los errores en los datos o en el código fuente.

Nada es más frustrante que seguir fielmente el manual de usuario y obtener resultados o comportamientos que no coinciden con los anticipados por el documento.

Por esta razón, la prueba de la documentación debería ser una parte importante de cualquier plan de pruebas del software.

Prueba de sistemas de tiempo-realLa naturaleza asíncrona y dependiente del tiempo demuchas aplicaciones de tiempo real, añade un nuevo ypotencialmente difícil elemento a la complejidad de las

El responsable del diseño de casos pruebas o sólo tiene que considerar los casos de prueba de caja blanca y de caja negra, sino también el tratamiento de sucesos (por ejemplo, procesamiento de interrupciones), la temporización de los datos y el paralelismo de las tareas (procesos) que manejan los datos.

Conclusiones● El principal objetivo del diseño de casos de prueba es

obtener un conjunto de pruebas que tengan la mayor probabilidad de descubrir los defectos del software.

● A menudo, los desarrolladores de software expen-mentados dicen que «la prueba nunca termina, simple-mente se transfiere de usted (el ingeniero del software)al cliente: Cada vez que el cliente usa el programa, lle-va a cabo una prueba.

Lectura recomendada.GOOGLE Y LAS PRUEBASPrincipio: “No existe software perfecto en el mundo”.Finalidad:“Pruebas constantes en diversos momentos de la vida del SW”.http://googletesting.blogspot.com/2011/01/how-google-tests-software.htmlhttp://www.javiergarzas.com/2011/04/pruebas-software-en-google.html

Preguntas1. ¿Qué son las Pruebas de Software? 2. Si fuéramos realmente buenos programando, no habría

errores que buscar. ¿Estás de acuerdo con esa frase? 3. ¿Cuándo se dice que una prueba es buena o exitosa? 4. Explique la diferencia entre:

Prueba de Caja Negra y Blanca5. ¿Qué es la Complejidad Ciclomática?6. Calcule la Complejidad Ciclomática.7. ¿En que se basa la Prueba de la

documentación y facilidades de ayuda?