Redes

1. Prólogo
Conceptos Básicos y estado del arte.
Lic. Ramiro Estigarribia

2. Estado del arte
La 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.

4. Definiciones
Dejinición 1
Ingeniería de Software: es el estudio de los principios y
metodologías para desarrollo y mantenimiento de sistemas
de software [Zelkovitz, 1981].
Definición 2
Ingenierí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].

5. Pruebas de Software

6. Descripción y objetivos
Las 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).

7. El ser humano comete errores
El 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.

8. Importancia de las pruebas
Las 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.

9. Importancia de las pruebas
En 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.

11. 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.

12. Mito de la Perfección
Si 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?

13. 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 alta
probabilidad de mostrar un error no descubierto hasta
entonces.
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.

14. 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.

15. Las prueba No aseguran
ausencia de defectos
Los 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.

16. Principios de las pruebas
Antes 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.

17. Principios de Davis
El autor Davis sugiere un conjunto de principios:
1. A todas las pruebas se les debería poder hacer un
seguimiento 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 de
que empiecen las mismas.
Se pueden planificar y diseñar todas las pruebas antes de
generar ningún código.

18. 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» y
progresar 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.

19. Principio de Pareto
El 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".

20. Facilidad de prueba
La 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 a
hacer 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.

21. Métricas para
medir 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 o
se 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 directamente
los estados y las variables del hardware y del software.

22. Métricas para
medir 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ás
rá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.

23. Atributos de una 'buena'
prueba:
1. Una buena prueba tiene una alta probabilidad de
encontrar 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.

24. Diseño de casos de prueba
Recordando 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.

25. Diseño de casos de prueba
Cualquier 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 a
las 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.

27. Pruebas de Caja Negra
Cuando se considera el software de computadora, la
prueba 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.

28. Pruebas de Caja Blanca
La pruebas de caja blanca del software se basan en el
minucioso 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.

29. 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 por
cien 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.

30. 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.

31. Prueba del camino básico
El 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.

32. 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.

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

34. Complejidad ciclomática
Es 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.

35. Complejidad ciclomática
El 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)

36. Complejidad ciclomática
Si 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.

37. Complejidad ciclomática
El grafo permite observar los cuatro caminos básicos
posibles:
Camino 1: 1-2-5-8-9
Camino 2: 1-3-4-5-8-9
Camino 3: 1-3-6-7-8-9
Camino 4: 1-3-6-9
En este ejemplo,
la complejidad
ciclomática = 4.

39. Pruebas de la Caja Negra
Las 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 un
enfoque complementario que intenta descubrir diferentes
tipos de errores que los métodos de caja blanca.

40. Pruebas de la Caja Negra
A 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.

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

42. Ejemplo, Caja Negra
Como 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ígitos
Prefijo: Número de 3 dígitos que no comience por 0 ó 1
Sufijo: Número de 4 dígitos
Contraseñ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.

43. Prueba de comparación
Hay situaciones (por ejemplo, aviónica de aeronaves,
control de planta nuclear) en las que la fiabilidad del
software 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.

44. Prueba de comparación
(cont...)
En esas situaciones, se deben probar
todas las versiones con los mismos datos de prueba, para
asegurar que todas proporcionan una salida idéntica.
Luego, se ejecutan todas las versiones en paralelo y se
hace 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.

45. Prueba de la Tabla Ortogonal
Cuando 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.

46. Prueba de la Tabla Ortogonal
Para ilustrar la prueba de la tabla ortogonal, considerar un
sistema 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.

47. Pruebas en entornos
especializados
A medida que el software de computadora se ha hecho
má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.

48. Prueba de interfaces
gráficas de usuario
Las interfaces gráficas de usuario (IGUs) presentan
interesantes desafíos para los ingenieros del software.
Debido a los componentes reutilizables provistos
como parte de los entornos de desarrollo de las GUI,
la creación de la interfaz de usuario se ha convertido
en 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.

49. Prueba de interfaces
gráficas de usuario
Considerando el gran número de permutaciones asociadas
con las operaciones IGU, sería necesario para
probar utilizar herramientas automáticas.

50. Prueba de arquitectura
cliente/servidor
La 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 para
hacer las pruebas de la arquitectura C/S y el software
residente en ellas, considerablemente más difíciles que
la prueba de aplicaciones individuales.

51. Prueba de la documentación y
facilidades de ayuda
Los 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.

52. Prueba de sistemas de
tiempo-real
La naturaleza asíncrona y dependiente del tiempo de
muchas aplicaciones de tiempo real, añade un nuevo y
potencialmente 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.

53. 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.

54. Lectura recomendada.
GOOGLE Y LAS PRUEBAS
Principio:
“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.html
http://www.javiergarzas.com/2011/04/pruebas-
software-en-google.html

55. Preguntas
1. ¿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 Blanca
5. ¿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?