Pruebas

1
Pruebas

• Pontificia Universidad Católica de Chile
• Departamento de Ciencia de la Computación
• IIC3552 Sistemas Embebidos de Tiempo Real
• Gerardo León Pablo Straub

2
Objetivo

• Concer los distintos tipos de pruebas a los que
  debe someterse un sistema computacional
• En esta clase veremos
• Pruebas unitarias
• Pruebas de integración
• Pruebas de sistemas
• Certificación (qualification)
• Pruebas de regresión

3
Por qué probamos el software?

• Asegurar que el sistema es consistente con los
  requisitos y las necesidades de los usuarios y
  clientes
• Como vimos al comienzo del curso, hay varios
  tipos de pruebas
• Como profesional hazlas todas
• En este curso bastan pruebas unitarias y de
  integración

4
Tipos de pruebas

• Pruebas unitarias o de módulos (unit testing)
• Pruebas de integración (integration testing)
• Pruebas de sistema (system testing)
• Certificación (qualification)
• Para sistemas a medida son pruebas de aceptación
• Pruebas de regresión (regression testing)

5
Modelo de ciclo de vida en V
Necesidades
Certificación
Requisitos
Pruebas de sistema
Arquitectura
Pruebas de integración
Diseño detallado
Pruebas unitarias
Codificación
6
Pruebas unitarias

• Propósito Encontrar defectos en el módulo o
  función.
• Normalmente las pruebas unitarias son hechas por
  el programador del módulo.
• Para probar una función debes
• Llamarla
• Tener subfunciones para llamar

7
Diseño de pruebas unitarias

• Las pruebas de cada función se especifican junto
  a la especificación de cada función
• Debemos asegurarnos de incluir pruebas para
• Casos habituales y casos extremos de los
  parámetros
• Todas las excepciones
• Todos los tipos de efectos laterales
• Un mismo caso de prueba puede mostrar una
  excepción y un efecto lateral

8
Especificación de un caso de prueba

• Parámetro Valor
• Parámetro1 Valor del parámetro 1
• Parámetro2 Valor del parámetro 2
• Parámetro3 Valor del parámetro 3
• Retorno Valor retornado o bien -.
• Estado Condiciones del estado inicial del sistema
  o bien -.
• Excepción Excepción que se devuelve en este caso
  o bien -.
• Efecto Efectos laterales para este caso o bien
  -.
• Observación ___________________________________
  ___________________________________

9
Cuántos casos de prueba hacer?

• Probemos con todas las entradas posibles
• Supongamos 4 argumentos y 2 variables globales
  consultadas (todos de 16 bits)
• En principio hay entonces (216)6 posibles casos
• Esto es 216x6 296 7,9 x 1028
• Si ejecutamos mil millones de pruebas por segundo
  necesitamos 7,9 x 1019 seg
• Esto es más de 2,5 millones de millones de años
• Más de 160 veces el tiempo desde el big bang!
• Una medida de calidad es la cobertura, o sea la
  fracción de las líneas ejecutadas por las pruebas

10
Funciones de un módulo

• Lo anterior se refiere más bien a probar cada
  función por separado
• Si las funciones de un módulo interactúan,
  debemos probar las interacciones
• (Si no interactúan el módulo tiene cero cohesión)
• La estrategia de prueba de un módulo va junto a
  su especificación funcional
• El límite entre la prueba de un módulo complejo y
  la prueba de integración es muy fino un módulo
  complejo es un subsistema que debe integrarse

11
Herramientas

• Hay herramientas que generan casos de prueba en
  forma inteligente, de alguna manera eligiendo
  un número relativamente limitado de casos de
  prueba
• Las herramientas pueden probar los casos (generan
  código para el test driver)
• Las herramientas computan cobertura de código e
  incluso cobertura de caminos
• Para sistemas embebidos de comunicaciones (como
  radios de dos vías), las herramientas se
  comunican con un modelo ejecutable de otros
  sistemas con los que se interactúa

12
Pruebas de integración

• Propósito Asegurar que no hay errores de
  interfaces encontrar defectos en el sistema
• Debemos planificar las pruebas de integración
• En el Documento de Arquitectura, o bien en el
  Plan de Pruebas de Sistema
• En nuestro caso podríamos agregarlas al final de
  la sección 1 del documento de diseño
• Típicamente se necesita andamiaje e incluso
  simuladores al comienzo de la integración
• Integrar sistemas embebidos es difícil debido a
  concurrencia, tiempo real, hardware inestable

13
Pruebas de sistema

• Propósito Asegurar que se cumplen los requisitos
• Este es un proceso muy formal
• Planificado en el Plan de Pruebas de Sistema
• Casos de prueba en la Especificación de Pruebas
  de Sistema
• Resultados en el Acta de Pruebas de Sistema

14
Certificación (qualification)

• Propósito Certificar que los requisitos del
  cliente se han cumplido satisfactoriamente y por
  lo tanto se puede iniciar la producción
• Esta etapa también llamada pruebas de
  aceptación debe hacerse por un equipo
  independiente del desarrollo
• Puede ser otra organización en la empresa
• Puede ser el cliente, si hay uno específico
• Hay empresas que ofrecen este servicio en general
  o en relación a estándares funcionales como los
  protocolos de comunicaciones

15
Pruebas de regresión

• Propósito Asegurar que cambios en el software no
  introducen nuevos defectos
• Se ejecutan luego de modificar el sistema
• Consisten en repetir las pruebas que ya se han
  hecho al sistema en una versión anterior y
  comparar el resultado actual con el anterior
• Aquí hay un beneficio enrome al tener un ambiente
  automatizado de pruebas