Pruebas%20del%20Software

1
Pruebas del Software

• Dinámica
• En cada uno de los objetos que se te presentan,
  indique como lo probarían ?
• Sus pruebas realizadas
• Sus conclusiones

2
(No Transcript)
3
(No Transcript)
4
Para todos.
5
Pruebas del software

• Existen dos fases de pruebas claramente
  diferenciables
• Pruebas del componente, realizadas por el
  desarrollador del software.
• (pruebas de funcionamiento de los componentes
  claramente identificables)
• Pruebas de integración, realizadas por un equipo
  de pruebas independiente.
• (integración de componentes en subsistemas o
  sistemas completos

6
Fases de prueba
Pruebas de integración
Pruebas del componente
Desarrollador de software
Equipo de pruebas independiente
7
Pruebas del software

• Desde una perspectiva de pruebas los sistemas OO
  difieren de los orientados a funciones porque
• En los orientados a funciones existe una
  distinción entre las unidades básicas del
  programa (funciones) y las colecciones de éstas
  (módulos). En los sistemas OO no existe esta
  distinción.
• A menudo no existe una jerarquía clara de objetos.

8
Pruebas de defectos

• El objetivo de estas pruebas es encontrar
  defectos en el software
• Una prueba de defectos exitosa es aquella que
  logra que el software se comporte de una manera
  incorrecta
• Las pruebas muestran la presencia no la ausencia
  de defectos

9
Datos de prueba y casos de prueba

• Los datos de prueba son entradas que permiten
  probar el sistema
• Los casos de prueba son entradas para probar el
  sistema y la predicción de las salidas que
  deberían ocurrir si el funcionamiento del sistema
  está de acuerdo a las especificaciones.

10
El proceso de pruebas de defectos
Informe prueba
Resultados prueba
Datos prueba
Casos de prueba
Comparar resul- tados con casos
Diseñar casos de prueba
Preparar datos de prueba
Ejecutar programas
11
(No Transcript)
12
Ejemplo

• Se deben probar todas las funciones del sistema
  que se acceden a través de menús
• Se deben probar las combinaciones de funciones
  (formato a un texto)
• Cuando el usuario introduce la entrada, todas las
  funciones deben probarse tanto con las entradas
  correctas como las incorrectas.

13
(No Transcript)
14
(No Transcript)
15
(No Transcript)
16
(No Transcript)
17
(No Transcript)
18
Prueba de caja negra

• Se analizan las entradas y las salidas del
  sistemas sin analizar qué ocurre dentro de él
• Los casos de prueba están basados en la
  especificación del sistema
• La planificación de la prueba se puede empezar al
  inicio del proceso de desarrollo de software

19
Prueba de caja negra
Entradas que causan salidas anormales
Salidas que revelan la presencia de defectos
20
Ejemplo
21
Particionamiento de equivalencia

• Los datos de entrada y los resultados de salida a
  menudo caen en diferentes clases. Por ejemplo
  números positivos, números negativos, cadenas con
  caracteres en blanco, etc.
• El sistema tiende a comportarse en forma
  equivalente para cada una de estas clases. Por
  este motivo resulta útil identificar dichas
  clases al momento de probar.
• Estas clases se denominan particiones de
  equivalencia.

22
Particiones de equivalencia
23
Particiones de equivalencia

• Las entradas al sistema se dividen en sets de
  equivalencia
• Ejemplo Si una entrada es un entero 5-digit
  entre 10.000 and 99.999, las particiones de
  equivalencia son lt 10.000, 10.000 - 99.999 y
  gt 100.000
• Por lo tanto se deben escoger los conjuntos de
  prueba entre estos límites
• 00000, 09999, 10.000, 99.999, 100.001

24
Particiones de equivalencia
Número de valores de entrada
Valores de entrada
25
Pruebas estructurales

• Algunas veces llamadas pruebas de caja blanca o
  de caja transparente
• Se definen a partir del conocimiento que se tiene
  de la estructura interna del sistema
• El objetivo es que se ejecuten todas las
  instrucciones del programa

26
Prueba de Caja Blanca
Datos de prueba
Pruebas
Deriva en
Salidas de prueba
Código del componente
27
Ejemplo
28
Prueba de trayectorias (ruteo)

• El objetivo de las pruebas de trayectoria es
  asegurarse que las diferentes instrucciones se
  ejecutan correctamente
• El punto de partida es un flujo gráfico del
  programa que muestre los nodos representativos de
  las decisiones que va tomando el programa. Los
  arcos representan el flujo de control
• Las instrucciones con condiciones se escriben
  junto a los nodos en el gráfico

29
Diagrama de flujo para una rutina de búsqueda
binaria
30
Las trayectorias independientes (sin vuelta
atrás) son

• 1, 2, 3, 8, 9
• 1, 2, 3, 4, 6, 7, 2
• 1, 2, 3, 4, 5, 7, 2
• 1, 2, 3, 4, 6, 7, 2, 8, 9
• Los casos de prueba deberían asegurarse que se
  ejecutan todas las trayectorias
• Un analizador dinámico podría utilizarse para
  saber las trayectorias efectivamente ejecutadas

31
Pruebas de integración

• Una vez que se han probado los componentes
  individuales del programa, deben integrarse para
  formar un sistema parcial o completo.
• Este proceso de integración comprende la
  construcción del sistema y probar el sistema
  resultante con respecto a los problemas que
  surjan de las interacciones de los componentes.
• Estas pruebas se desarrollan a partir de la
  especificación del sistema.

32
Pruebas de integración

• La principal dificultad es detectar el origen del
  problema cuando la prueba ha entregado una salida
  anómala.
• Dónde está el error ? El el subprograma A ?
  En el B ? En ambos ? En el traspaso de
  parámetros ?
• Si no existe un diseño claro es muy difícil
  encontrarlo. Además los programadores se echan
  la culpa entre sí.

33
Pruebas de integración Integración incremental

• No se arma el sistema completo sino parte por
  parte, las que se van probando.
• Al ser un sistema más simple, es más fácil de
  encontrar el origen de los errores.
• En el ejemplo las pruebas T1, T2 y T3 se aplican
  al sistema compuesto por los módulos A y B. Si
  hay errores, se corrigen.
• Se integra el módulo C y se repite T1, T2 y T3.

34
Pruebas de integración Integración incremental
35
Pruebas de integración Pruebas ascendentes y
descendentes.

• Pruebas descendentes
• Empiezan con el sistema de alto nivel y se va
  llegando a los niveles inferiores (más detalle)
• Pruebas ascendentes
• Integran componentes individuales en niveles
  hasta que es completado el sistema
• En la práctica se suele combinar ambos tipos de
  prueba

36
Top-down testing
37
Bottom-up testing
38
Pruebas de interfaces entre componentes

• Se realizan cuando se han integrado todos los
  componentes del sistema
• Cada módulo o subsistema tiene una interfaz
  definida que es llamada por otros componentes del
  programa
• El objetivo es detectar los errores producidos al
  integrar estas interfaces

39
Pruebas de interfaces entre componentes
40
Pruebas de interfaces entre componentes

• Las flechas en los límites de los cuadros
  significan que los casos de prueba no se aplican
  a los componentes individuales sino al subsistema
  creado mediante la integración de estos
  componentes.
• Esta forma es muy importante en el desarrollo OO
  cuando se reutilizan objetos y clases

41
Tipos de interfaces

• Interfaces de parámetros
• Datos pasados de un procedimiento a otro
• Interfaces de memoria compartida
• Bloques de memoria que son compartidos entre
  componentes
• Interfaces de procedimientos
• Los subsistemas encapsulan un conjunto de
  procedimientos que son llamados por otros
  subsistemas
• Interfaces de paso de mensajes
• Los subsistemas solicitan servicios a otros
  subsistemas

42
Pruebas de stress (presión)

• Sistemas bien diseñados y construidos fallan en
  situaciones límite (muchos usuarios, muchos datos
  en las tablas, etc.).
• Estas fallas suelen ser catastróficas porque
  ocurren cuando hay mucho usuarios y procesos
  ejecutándose
• El objetivo de estas pruebas es determinar hasta
  que límite el sistema puede funcionar sin colapsar

43
(No Transcript)
44
Bancos de pruebas

• Son herramientas desarrolladas especialmente para
  hacer pruebas
• Muchos bancos de prueba están abiertos para
  configurarlos debido a que normalmente hay que
  configurarlos a situaciones específicas
• A veces existen dificultades para integrarlas
  debido a que el sistema a probar no está bien
  diseñado para interactuar con estas herramientas

45
Bancos de prueba
46

• Linux.com ha publicado una interesante nota
  acerca de catorce útiles consejos que harán la
  vida más fácil a quienes desean probar programas
  y aplicaciones libres. Lee a continuación para
  conocer los detalles.
• Utiliza la más reciente versión del equipamiento
  lógico que estás probando.
• Verifica si hay actualizaciones antes de reportar
  un error.
• Incluye suficiente información en tu reporte de
  modo que el problema pueda ser reproducido con
  facilidad.
• Evita disculparte por tu idioma.
• Utiliza los sistemas de reporte de errores si
  están disponibles (Bugzilla).
• Si es posible, escribe pruebas automatizadas.
• Si es posible, utiliza el código que estás
  probando bajo condiciones de vida real.
• Utiliza las herramientas de reporte de fallas
  (ejemplo Bugbuddy).
• Conviene familiarizarse con las herramientas que
  serán utilizadas para compilar, ligar y probar el
  código.
• si es posible, es conveniente mantener un entorno
  separado para pruebas.
• Conserva revisiones anteriores del código para
  rastrear los errores cuando aparezcan.
• Describe tan completo como sea posible las
  condiciones que llevan a la falla.
• Tus impresiones como usuario novicio son
  críticas, reporta todo lo que veas.
• Se paciente con los desarrolladores.
• Fuente Linux.com.

47
Temas clave

• Es más importante probar las partes del sistema
  que se utilizan más frecuentemente que las partes
  que raramente se utilizan.
• Las particiones de equivalencia son una forma de
  generar casos de prueba. Dependen de encontrar
  particiones en los conjuntos de datos de entrada
  y salida y ejecutar el programa con valores de
  estas particiones. A menudo el valor más útil es
  uno límite.

48
Temas clave

• Las pruebas estructurales analizan un programa
  para determinar las trayectorias y utilizan este
  análisis para escoger los datos de prueba que
  sean más útiles.
• Las pruebas de caja negra están basadas en la
  especificación del sistema (lo que debería hacer)
• La finalidad de los datos de prueba es encontrar
  errores de funcionamiento.