Unidad 2.3 Prueba De Programas

11 de abr de 2023 Sergio Sánchez Rios

Ingeniería de SoftwareUnidad II

Prueba de los Programas

Sergio Sánchez Rios.

Ingeniero en Informática – Licenciado en Informática


IntroducciónUna vez codificados los programas es el momento de probarlos.

Existen muchos tipos de pruebas: prueba unitaria, prueba de integración, prueba de función, prueba de desempeño, prueba de aceptación y prueba de instalación.

Es importante considerar, que la etapa de prueba no es la primera instancia en que se localizan defectos; también las revisiones de requerimientos y diseño contribuyen a descubrir los problemas en instancias tempranas del desarrollo.

La etapa de prueba se centra en la búsqueda de defectos.


Defectos y Fallas del software¿Qué significa decir que el software a fallado?

Por lo general se interpreta que el software no hace lo que especifican los requerimientos. La falla puede ser el resultado de alguna de varias razones:

La especificación puede ser errónea o puede haberse omitido algún requerimiento.

La especificación puede contener un requerimiento que es imposible de implementar con el software y el hardware preescrito.

El diseño del sistema puede contener un defecto. El diseño del programa puede contener un defecto. El código del programa puede estar errado.

Una falla es el resultado de uno o más defectos en algunos aspectos del sistema.


Defectos y Fallas del softwareMuchos programadores consideran que la prueba es una comprobación de que sus programas operan correctamente.

La idea de demostración de exactitud es realmente lo inverso de lo que entraña la prueba.

Se prueba un programa para demostrar la existencia de un defecto. La prueba es destructiva: dado que la meta es descubrir defectos.

Identificación de defectos: es el proceso de determinar cuál o cuales son los defectos que originan las fallas.

Corrección de defectos o remoción: es el proceso de efectuar cambios al sistema de manera que se eliminen los defectos.


Defectos y Fallas del softwareTipos de Defectos

Una de las cosas importantes al realizar las pruebas, es saber que clase de defectos se están buscando.

Defectos Algorítmicos

Se produce cuando el algoritmo o la lógica de un componente no producen la salida apropiada para una entrada dada, debido a que algo esta mal en los pasos del procesamiento.

Los tipos de defectos algorítmicos incluyen: bifurcar antes y después de tiempo, probar una condición errónea, olvidar inicializar una variable o fijar las constantes de un bucle, olvidar la prueba para una condición particular (división por cero), comparar variables de tipos de datos inapropiados, etc..



Defectos de SintaxisSe realiza mientras se buscan defectos algorítmicos. En este caso, se desea asegurar que se han utilizado apropiadamente las estructuras del lenguaje de programación.

Defectos de computación y de precisiónOcurre cuando la implementación de una fórmula es errónea o no calcula el resultado con el grado requerido de exactitud. Ej.: Mezcla de flotantes y enteros resultado inesperado.

Defectos de DocumentaciónEs cuando la documentación no corresponde con lo que el programa realmente hace. Se tiende a confiar en la documentación al pasar de una etapa a otra y al modificar.



Defectos por estrés o sobrecargaSe producen cuando las estructuras (longitud de colas, tamaño de almacenamiento temporarios (buffers), a la dimensión de tablas y así sucesivamente) se llenan hasta sobrepasar su capacidad especifica.

Defectos de capacidad o de limitesOcurre cuando el desempeño del sistema se vuelve inaceptable a medida que la actividad del sistema alcanza su limite especificado. Ej.: Sistema diseñado con 32 dispositivos, se debe probar si funciona con los 32 dispositivos trabajando.

Defecto de rendimiento o desempeñoOcurre cuando el sistema no opera a la velocidad preescrita por los requerimientos.



Defectos de sincronización o de coordinaciónAl desarrollar sistemas de tiempo real, una consideración critica es la coordinación de los varios procesos que se ejecutan simultáneamente o una secuencia rigurosa definida. El defecto se produce cuando el código que coordina dichos eventos es inadecuado.

Defectos de recuperaciónPueden ocurrir cuando se encuentra una falla y el sistema no se comporta como los diseñadores desean que lo haga, o como el lo quiere el cliente.

Defecto de Hardware y Software de sistemas.Cuando el hardware suministrado y el software de sistemas no trabajan realmente de acuerdo con las condiciones operativas y procedimientos documentados.



Defectos de estándares y procedimientosEl código será revisado para ver si se han seguido los estándares y procedimientos. Estos no siempre afectan la ejecución de los programas. Al no usar los estándares o procedimientos requeridos un programador puede hacer que para otros resulte muy difícil comprender la lógica del código.


Aspectos de la PruebaSon muchos los tipos de prueba que se hacen antes de poder entregarle el sistema al cliente con la seguridad de que operara correctamente.

Cada componente del programa se verifica en si mismo, aislado de los demás componentes del sistema.

Cada componente del programa se verifica en si mismo, aislado de los demás componentes del sistema.

La prueba funcional, evalúa el sistema para determinar si las funciones descritas por la especificación son realmente ejecutadas por el sistema integrado.

La prueba funcional, evalúa el sistema para determinar si las funciones descritas por la especificación son realmente ejecutadas por el sistema integrado.

La prueba de integración, verifica que los componentes del sistema trabajan juntos conforme a lo descrito en la especificación del diseño del programa.

La prueba de integración, verifica que los componentes del sistema trabajan juntos conforme a lo descrito en la especificación del diseño del programa.

Se realiza una prueba de rendimiento con el resto de requerimientos de software y hardware. Cuando la prueba se lleva acabo exitosamente, se produce un sistema valido.

Se realiza una prueba de rendimiento con el resto de requerimientos de software y hardware. Cuando la prueba se lleva acabo exitosamente, se produce un sistema valido.

La prueba de aceptación se realiza en conjunto con el cliente; ya que el sistema se comprueba contra la especificación de requerimientos.

La prueba de aceptación se realiza en conjunto con el cliente; ya que el sistema se comprueba contra la especificación de requerimientos.

La prueba de instalación se realiza para garantizar que todo funciona como corresponde.

La prueba de instalación se realiza para garantizar que todo funciona como corresponde.


Aspectos de la Prueba¿Quién realiza las pruebas?

Muchas veces se manifiestan dificultades para separar los sentimientos personales del proceso de prueba. Por lo tanto, a menudo se utiliza un equipo de prueba independiente.

Justificación de un equipo independiente de prueba:

Es claro que nadie entrega su código para la prueba sino piensa que el código a sido realizado de acuerdo con la especificación, pero se puede estar demasiado apegado al código como para ser realmente objetivos y reconocer algunos de los defectos más sutiles.

Las pruebas pueden llevarse concurrentemente con la codificación; el equipo de prueba verifica los componentes a medida que son completados y comienza a consolidarlos mientras el plantel de programación continua codificando los demás.


Aspectos de la PruebaLa visión de los objetos de prueba

Al probar un componente, un grupo de componentes, un subsistema o un sistema, la propia visión del objeto de prueba puede afectar la forma que se lleva acabo la prueba.

Si el objeto de prueba se ve desde afuera, como una “caja negra” o “caja cerrada” , cuyo contenido se desconoce, las pruebas consisten en alimentar la caja negra con entradas y anotar cuales son las salidas que se producen.

En este caso la meta de la prueba es asegurarse que se ha ingresado toda clase de entradas y que la salida observada en cada caso corresponde a una salida esperada.

La ventaja de este tipo de prueba, es que esta libre de las restricciones impuestas por la estructura interna o lógica.



La desventaja de utilizar la prueba de caja negra en un componente, es que no se pueden seleccionar los casos de prueba más significativos porque no se tiene un conocimiento acabado del procesamiento.

Para superar este problema el objeto de prueba puede verse como una “caja abierta”, “caja de cristal”, “caja blanca” o “caja transparente”, luego; se puede utilizar la estructura interna del objeto de prueba, para probar las diferentes maneras.

Por ejemplo se pueden ejecutar casos de prueba que ejecuten todas las instrucciones y caminos de control que existen dentro del componente, para asegurase que el objeto de prueba está bien.



Ejemplo:

Si n y m valen cada uno 100.000, un caso de prueba debe iterar mil millones de veces para ejecutar todos los caminos lógicos.

Si n y m valen cada uno 100.000, un caso de prueba debe iterar mil millones de veces para ejecutar todos los caminos lógicos.

Para acotar estos casos de prueba según la composición interna, se pueden asignar valores I que sean menor que n, igual que n, y mayor que n. De igual forma se pueden asignar valores de J con relación a m.

Para acotar estos casos de prueba según la composición interna, se pueden asignar valores I que sean menor que n, igual que n, y mayor que n. De igual forma se pueden asignar valores de J con relación a m.



Cuando se decide como probar, no es necesario seleccionar exclusivamente pruebas de caja abierta y cerrada. Se puede considerar que las pruebas de caja cerrada es uno de los extremos y la prueba de caja abierta el otro. Este proceso se llama caja estructurada (desde caja cerrada a abierta).


Prueba Unitaria¿Cómo comenzar cuando la meta es encontrar defectos?.

El proceso es similar al que se utiliza, cuando se prueba un programa asignado como tarea en la universidad:

1. Se examina el código, leyendo minuciosamente, tratando de localizar defectos en los algoritmos, los datos y la sintaxis.2. Comparar el código con las especificaciones y con el diseño hasta tener la certeza de considerar todos los casos relevantes.3. Finalmente se desarrollan los casos de prueba para demostrar que las entradas se convierten realmente en las salidas esperadas.


Prueba UnitariaEl examen del código

El proceso de revisión del código es similar al de la revisión de requerimientos y diseño. Se conforma un equipo, integrado por el mismo programador y tres o cuatro expertos técnicos.

Este equipo se encarga de estudiar el programa de manera organizada para localizar defectos. En estas pruebas no se incluyen clientes (examen de código).

Existen dos tipos de revisiones de códigos: las recorridas y las inspecciones.


Prueba UnitariaEl examen del código – Recorridos de código

Se presenta el código y la documentación correspondiente al equipo de revisión y el equipo comenta sobre su exactitud.

Durante la recorrida es el programador quien lidera y controla la discusión.

La atmósfera es informal y el foco de atención está en el código no en el programador.


Prueba UnitariaEl examen del código – Inspección de código

Este método fue presentado por Fagan (1976) en IBM. Es similar a una recorrida pero más formal. El equipo revisa el código y la documentación contra una lista de puntos de interés preparados.

La inspección involucra varios pasos:

1. El equipo debe reunirse para hacer una revisión general del código y hacer una descripción de las metas de la inspección.2. Los miembros del equipo se preparan individualmente para una segunda reunión de grupo. Cada inspector estudia el código y sus documentos relacionados y resalta los defectos encontrados.


Prueba UnitariaEl examen del código – Inspección de código

3. Finalmente, los miembros del equipo informan lo que han encontrado y registran los defectos que se descubren durante el proceso de discusión de los defectos descubiertos por los individuos.

Los miembros del equipo de inspección se seleccionan sobre la base de las metas de la inspección. Ej.: Si se quieren inspeccionar las interfaces, alguno de los miembros del equipo a lo menos debe ser diseñador de interfaces.


Prueba UnitariaÉxito de las revisiones de código

Puede sentirse incomodidad al tener a un grupo revisando el código propio.

Sin embargo, las revisiones han demostrado ser extraordinariamente exitosas en la detección de defectos, y por lo general están incluidas en la lista de prácticas obligatorias o de las mejores prácticas de una organización.

Por esta razón Gild (1988) y Gild y Graham (1993) sugieren inspeccionar no sólo el código, sino los artefactos tempranos del desarrollo tales como la especificación de requerimientos y el diseño.


Prueba UnitariaÉxito de las revisiones de código

Jones (1991), realiza una investigación que denota la importancia de la inspección como una técnica de localización de defectos.

Defectos encontrados durante las actividades de descubrimiento

Actividad de Descubrimiento Defectos encontrados por cada mil líneas de código

Revisión de los requerimientos 2,5

Revisión del diseño 5,0

Inspección del código 10,0

Prueba de integración 3,0

Prueba de aceptación 2,0


Prueba UnitariaCasos de Prueba

Un buen test case es aquel que tiene una alta probabilidad de encontrar un defecto no descubierto, no aquel en que el programa funciona correctamente.

Un buen test case no es redundante, ni muy simple, ni muy complejo .... idealmente, el mejor de su clase.

Un exitoso test case es aquel que descubre un defecto no descubierto. El diseño de test cases es muy difícil.

El Testing no puede mostrar la ausencia de defectos, sólo puede mostrar que los defectos están presentes.



Existen dos estrategias para definir los casos de prueba:

Caja Negra – Black Box Testing Métodos más Usados

Particionamiento de Equivalencias. Análisis de Valores Fronteras. Adivinanza de Defectos.

Métodos menos Usados Diagrama causa - efecto. Pruebas Sintácticas. Pruebas de Transición de Estados. Matriz de Grafos



Existen dos estrategias para definir los casos de prueba:

Caja Blanca – White Box Testing Métodos más Usados

Pruebas de Cobertura (Instrucción, Decisión, Condición, Decisión/Condición, Múltiples Condiciones, De Caminos).

Métodos menos Usados Pruebas de caminos básicos. Pruebas de Estructuras de Control. Pruebas de Condición. Pruebas de Flujo de Datos. Pruebas de Loop.


Prueba de Integración

Cuando se llega a un convencimiento de los componentes individuales están trabajando correctamente y se satisfacen los objetivos, se los combina en un sistema activo.

Esta integración se planea y coordina para que al producirse una falla, se pueda tener alguna idea de lo que le ha dado origen.


Prueba de IntegraciónIntegración Ascendente (bottom – up)

Este enfoque permite realizar pruebas desde los componentes elementales a los más generales.

Cuando se usa este método, se prueba primero en forma individual cada componente al nivel más bajo de la jerarquía del sistema. Luego los próximos componentes que se prueban son lo que llaman a los ya probados.

Este método es útil cuando muchos de los componentes de bajo nivel son rutinas utilitarias de uso general que son invocados a menudo por otros componentes.



Considerando está jerarquía se comienza probando los módulos E, F, G. Como no existe ningún programa preparado para llamar a estos programas del más bajo nivel, se escribe un código especial para llamar a la integración.

Este código se llama, controlador de componentes (Driver), es una rutina que llama a un componente particular y le pasa un caso de prueba.

A

B C D

E F G



Considerando la jerarquía planteada anteriormente estos son los pasos de la prueba.

ProbarE

ProbarF

ProbarG

DriverE

DriverF

DriverG

Casos de prueba

ProbarE, F, B

ProbarC

ProbarG, D

Se prueban nuevamente los componentes E, F, B, C, G, D

Se prueban nuevamente los componentes E, F, B, C, G, D

ProbarA, B, C, D,E, F y G

Se prueban todos los componentes juntos.Se prueban todos los componentes juntos.

Si los componentes probados no están OK no se pasa al otro nivel.

Si los componentes probados no están OK no se pasa al otro nivel.



En un enfoque funcional, la queja radica en que al ser los módulos superiores los más importantes son los últimos en ser probados.

Por otra parte, este enfoque es a menudo el más razonable para los programas orientados a objeto. Los objetos se combinan de uno por vez con objetos o colecciones de objetos que se han probado previamente.


Prueba de IntegraciónIntegración Descendente (Top – down)

Es lo contrario del bottom – up.

El componente principal se prueba aisladamente, después todos los componentes llamados por el componente se combinan y se prueban como una unidad mayor. Este enfoque se vuelve a aplicar hasta que todos los componentes estén incorporados.

Un componente que se esta probando puede llamar a otro todavía no probado, de modo que se escribe un programa de propósito especial que simule la actividad del componente omitido, denominado “talón” (stuk).



Ejemplo basado en la jerarquía anterior:

ProbarA

ProbarA, B, C, D

ProbarB, C, D, E

F, G

Talones para B, C, DTalones para B, C, D Talones para E, F, GTalones para E, F, G

En la prueba descendente no se necesitan programas controladores. Por otro lado la escritura de los talones puede ser difícil, porque estos deben permitir probar todas las posibles condiciones.

Otra problemática es que si el diseño se cambia los talones también.



Una desventaja de esta técnica es la posibilidad de requerir números muy grandes de talones. Está situación se produce cuando el nivel más bajo tiene muchas rutinas.

Una manera de evitar este problema es alterar ligeramente la estrategia. En lugar de incorporar un nivel completo por vez, un enfoque descendente modificado prueba los componentes de cada nivel individualmente antes de llevar a cabo la fusión.

ProbarA

ProbarB

ProbarC

ProbarD

ProbarA, B, C,

D

ProbarE

ProbarF

ProbarG

ProbarA, B, C,

D, E, F, G



La prueba por separado de los componentes de cada nivel trae aparejado otra dificultad, se necesitan talones y controladores para cada componente, lo que lleva a que aunque aumenten considerablemente las tareas de codificación.


Prueba de IntegraciónIntegración Big - Bang

Cuando todos los componentes se prueban por separado, existe la tentación de mezclarlos juntos como un sistema final y ver si funciona la primera vez.

Myers (1979) ha llamado prueba big – bang ha este particular enfoque de prueba.

Muchos programadores usan este enfoque para sistemas pequeños, pero no es práctico para los grandes.


Prueba de IntegraciónIntegración Big - Bang

ProbarA

ProbarB

ProbarC

ProbarD

ProbarE

ProbarF

ProbarG

ProbarA, B, C, D

E, F, G

Desventajas, exige talones y controladores que prueben los componentes independientes.

Otra es que todos los componentes se fusionan (combinan a la vez), por esto es difícil encontrar la causa de fallas.


Prueba de IntegraciónIntegración Intercalada

Meyer (1979) combina las estrategias bottom – up y top –down para formar un enfoque de prueba intercalada.

El sistema de se como tres capas, al igual que un sandwich: en el medio la capa objetivo, los niveles por encima del objetivo y los niveles por debajo del objetivo.

En la capa superior se utiliza top – down y en la capa inferior bottom – up. La prueba converge a la capa objetivo, elegida en base a las características del sistema y a la estructura de la jerarquía del componente.

Este enfoque permite utilizar el enfoque bottom - up para verificar lo correcto de los utilitarios al principio de la prueba. Por lo tanto no se necesita escribir talones para los utilitarios porque están disponibles.



Basados en el ejemplo anterior, el nivel objetivo es el nivel medio, compuesto por los componentes B, C y D.

ProbarE

ProbarF

ProbarG

ProbarE, F, B

ProbarG, D


ProbarC

ProbarA



Este enfoque mezcla las ventajas de los dos métodos. Sin embargo, no permite probar los componentes antes de la integración.

La prueba intercalada modificada, permite probar los componentes antes de unirlos con otros.

ProbarE

ProbarF

ProbarG

ProbarE, F, B

ProbarG, D


ProbarC

ProbarA

ProbarD

ProbarB


Bibliografía

Guía del Tópico:

Software Engineering 6a. ed.– Ian Sommerville – Pearson Education – 2000.Ingeniería de Software Teoría y Práctica – Shari Lawrence Pfleeger – Pearson Education – 2002.

Solo referencial:

Ingeniería de Software: Un enfoque práctico - Roger S. Pressman - Mc Graw Hill – 2002.

Unidad 2.3 Prueba De Programas

Documents

Transcript of Unidad 2.3 Prueba De Programas