Gestin y Desarrollo de Sistemas Informticos

1
Gestión y Desarrollo de Sistemas Informáticos

• Carlos R. Becerra Castro
• carlos.becerra_at_uv.cl

2
PruebaObjetivos del Área

• Diseñar casos de pruebas y planes de pruebas
  utilizando técnicas apropiadas.
• Planificar, especificar, ejecutar y evaluar
  pruebas de software.
• Utilizar herramientas para mejorar la efectividad
  de las pruebas de software.

3
PruebaNoción de Calidad de Software.

• Objetivo último de la ingeniería de Software
  producir Software de calidad.
• Calidad engloba todo el proceso de desarrollo de
  software.

4
PruebaNoción de Calidad de Software.

• Visiones de calidad.
• Visión del usuario (grado de adecuación al
  propósito, Norma ISO 9126).
• Visión del productor (conformidad con la
  especificación).
• Visión del producto (ligadas a las
  características del mismo).

5
PruebaConceptos básicos

• Definición
• Proceso de ejecutar un programa con la intención
  de encontrar defectos
• Proceso destructivo que determina el diseño de
  los casos de prueba y la asignación de
  responsabilidades

6
PruebaConceptos básicos

• Falla (failure)
• Ocurre cuando un programa no se comporta
  adecuadamente
• Representa una propiedad del sistema en ejecución
• Defecto (fault)
• Existe en el código
• Si se encuentra puede causar una falla
• Error (error,mistake)
• Acción humana que resulta en software que
  contiene un defecto
• Puede llevar a incluir un defecto en el sistema,
  haciéndolo fallar

7
PruebaConceptos básicos

• Caso de prueba
• Evento, compuesto de un conjunto de entradas
  predefinidas y salidas esperadas, ejecutado con
  el propósito de causar fallas en un(os)
  componente(s) del software con el fin de detectar
  defectos
• Cobertura
• Grado en que un conjunto de pruebas abarca todos
  los requerimientos especificados

8
PruebaConceptos básicos

• Ideas fundamentales en relación al testing
• Test exitoso es aquel que encuentra muchos
  defectos, no lo opuesto (desarrollo exitoso)
• El propósito del testing es encontrar defectos,
  debe mostrar que algo es incorrecto
• Cada vez que se corrigen defectos detectados, se
  pueden introducir nuevos defectos al sistema

9
PruebaConceptos básicos

• Testing no es
• Demostración de que no hay errores
• Demostración de que el software desempeña
  correctamente sus funciones
• Establecimiento de confianza que un programa hace
  lo que debe hacer

10
PruebaEjercicio

• Considere el siguiente programa
• Un programa lee tres valores enteros, que
  representan las longitudes de los lados de un
  triángulo, e imprime el mensaje que establece si
  es escaleno, isósceles o equilátero.
• Escriba un conjunto de casos de pruebas para este
  programa, cada caso es de la forma (x,y,z).

11
PruebaPrincipios

• Una parte necesaria de un caso de prueba es la
  definición de la salida o resultado esperado
• Un programador debería evitar probar su propio
  código
• Una unidad de programación no debería probar sus
  propios programas
• Los resultados de cada prueba deben ser
  acuciosamente inspeccionados

12
PruebaPrincipios

• Los casos de prueba deben diseñarse para
  condiciones de entrada inválidas e inesperadas,
  no sólo para aquellas válidas y esperadas
• Examinar un programa para ver si no hace lo que
  debe hacer es sólo la mitad de la tarea la otra
  mitad es ver si hace lo que no debe hacer
• Evitar casos de prueba espontáneos y que no dejan
  registro - es sólo pérdida de tiempo

13
PruebaPrincipios

• No planificar un esfuerzo de prueba bajo el
  supuesto tácito que no se encontrará defectos
• Testing es una tarea extremadamente creativa e
  intelectualmente desafiante

14
PruebaCostos asociados

• Es posible probar un programa para encontrar
  todos los defectos?
• No, ni siquiera para los programas más
  triviales..
• Es impráctico y a menudo imposible
• Habría que probar todas las combinaciones de
  entrada, correctas e incorrectas ? número
  infinito de casos de prueba
• Habría que probar todos los caminos posibles
  dentro de un programa que pueden contener loops ?
  el número de casos de prueba no es infinito, pero
  usualmente puede considerarse como tal

15
PruebaProceso de Testing

• Planificación Guías, métodos, estimación de
  recursos requeridos.
• Especificación Descripción de las pruebas a
  nivel de propósito, y a un nivel detallado.
• Ejecución Desarrollo de las pruebas y detalle de
  los resultados (TS).
• Análisis de Defectos Identificación del defecto
  y sus causas, y las acciones correctivas.

16
PruebaTaxonomía de defectos.

• No existe una manera universal de categorizarlos
  la típicas son
• Requerimientos.
• Datos.
• Implementación y código.
• Integración.
• Arquitectura del sistema (Ejemplo
  escalabilidad).

17
PruebaDiseño de casos de prueba

• Un buen caso de prueba es aquel que tiene una
  alta probabilidad de encontrar un defecto no
  descubierto, no aquel en que el programa funciona
  correctamente
• Un caso de prueba exitoso es aquel que descubre
  un defecto no descubierto
• Para cada caso de prueba debe definirse el
  resultado esperado y debe ser repetible
• El diseño de casos de prueba es muy difícil

18
PruebaDiseño de casos de prueba

• Estrategias
• White-box testing o pruebas de caja blanca
• Examen detallado de los procedimientos internos
  (caminos lógicos, condicionales y loops).
• Black-box testing o pruebas de caja negra
• Pruebas se conducen a nivel de interfaz (análisis
  de fronteras, clases de equivalencia).

19
PruebaEjercicio.

• Un programa en C de 100 líneas, contiene 2 loop
  anidados que se ejecutan de 1 a 20 veces cada
  uno. Dentro del loop interior, se requieren 4
  constructores if-then-else.
• Calcule cuántos caminos posibles existen.
• Probar casos importantes y combinarlos con caja
  negra.

20
PruebaEjemplo.

• Testing de caja blanca
• Caminos bases.

21
PruebaEstrategias de testing

• Pasos
• Las pruebas iniciales se focalizan en cada módulo
  
• Se busca asegurar que cada componente del
  programa funciona apropiadamente como una unidad
• Principalmente se utilizan técnicas de white-box
• Luego, los módulos deben integrarse o
  ensamblarse para formar un paquete completo

22
PruebaEstrategias de testing

• Pasos
• Finalmente, corresponde una serie de pruebas de
  orden superior orientadas a
• Asegurar que el software satisfaga todas los
  requerimientos de uso, funcionales, de
  comportamiento y de desempeño
• Verificar que todos los elementos del sistema
  computacional se acoplan adecuadamente y que la
  funcionalidad y desempeño globales se alcanzan

23
PruebaEstrategias de testing
24
PruebaEstrategias de testing

• Una estrategia exitosa debe
• Especificar requerimientos del producto en forma
  cuantificable mucho antes de comenzar el testing
• Establecer explícitamente los objetivos del
  testing
• Comprender a los usuarios y desarrollar un perfil
  para cada categoría
• Desarrollar un plan que enfatice pruebas de ciclo
  rápido

25
PruebaEstrategias de testing

• Una estrategia exitosa debe
• Usar revisiones técnicas formales como un filtro
  previo al testing
• Conducir revisiones técnicas formales para
  evaluar la estrategia de testing y los casos de
  prueba
• Desarrollar un enfoque de mejoramiento continuo
  para el proceso de testing

26
Tipos de VyV

• VyV Dinámica
• Ejercitar y observar comportamiento del producto
• Normalmente pruebas del sistema
• VyV Estática
• Analizar representación estática del sistema
• Normalmente revisiones de productos de trabajo

27
Tipos de VyV
28
Tipos de VyV
29
Pruebas de Software

• Prueba
• Ejecución de programa(s)
• Para descubrir defectos
• Antes de entrega
• No asegura ausencia de defectos

30
Principios para las pruebas

• Planificación
• Seguimiento
• Progresivas
• Equipo independiente
• No exhaustivas

31
Clasificación de las pruebas.
32
Dependiendo de quién prueba

• Internas
• Por ingenieros que desarrollan SW
• Externas
• Por el cliente (junto con desarrolladores)

33
Pruebas externas

• Pruebas alfa
• Instalaciones del desarrollador
• Grupo muy reducido de clientes
• Pruebas beta
• Instalaciones del cliente, ambiente de
  laboratorio
• Grupo más amplio de clientes
• Pruebas piloto
• Instalaciones del cliente, ambiente de producción
• Conjunto reducido de departamentos del cliente

34
Dependiendo de qué se prueba.

• Pruebas Unitarias
• Cada programa individualmente
• Pruebas de Integración
• Módulos o subsistemas ya integrados
• Pruebas del Sistema
• Características técnicas del sistema completo
• Pruebas de Validación o Aceptación
• Funcionalidad del sistema completo

35
Dependiendo de cómo se diseñan

• Pruebas de caja negra (Black-box)
• Se toma en cuenta funcionalidad
• Pruebas de caja blanca (White-box)
• Se toma en cuenta como está desarrollado
• Estadísticas
• Se diseñan para lo más probable

36
Clasificación de las pruebas.
37
Plan vs. Diseño de Pruebas

• Plan de pruebas
• Qué se va a probar del sistema
• Incluye tipos de pruebas a realizar
• Dónde se va a probar
• Cuándo se va a probar
• Quién va a probar
• Riesgos y contingencias
• Diseño de pruebas
• Detalle de cómo se va a realizar CADA prueba, o
  sea conjunto de casos de prueba

38
Pruebas en el proceso de desarrollo
39
Pruebas de caja negra

• Prueba requerimientos funcionales del software
• Requisitos funcionales -gt casos de pruebas
• Intenta corregir
• Funcionalidad incorrecta o faltante
• Errores de interfase
• Errores en las Bases de Datos
• Errores en el comportamiento

40
Métodos de caja negra

• Partición equivalente
• Análisis de valores límite
• Basados en grafos
• ... Muchos otros

41
Partición equivalente

• Divide (particiona) cada entrada en conjuntos
  equivalentes
• Directriz diseñar al menos 2 casos de prueba por
  cada partición
• Uno válido y otro inválido, o
• Uno dentro y otro fuera de la partición
• Ejemplos de posibles particiones
• Si la entrada es alfanumérica
• Nulo, letras, números, especiales, etc.

42
Partición equivalente

• Ejemplos de posibles particiones
• Numérico
• Negativos, cero, positivos, reales
• Rango
• Dentro del rango, fuera del rango
• Tabla de rangos
• Dentro de cada rango, fuera del menor de los
  rangos, fuera del mayor de los rangos

43
Valores límite

• Prueba los valores límite de los datos
• Directrices
• Rango entre a y b
• Diseñar 4 casos de prueba a-1, a, b y b1
• De M a N datos
• Diseñar 4 casos de prueba M-1, M, N y N1 datos
• De 0 (cero) a N datos
• Diseñar 4 casos de prueba 0, 1, N y N1 datos
• NOTAS
• Cumple con partición equivalente
• Hacer lo mismo con los resultados

44
Ejercicio 1

• En una escuela reciben pagos de colegiaturas cada
  mes.
• Si la persona paga entre el día 1 y 10 no tiene
  ningún recargo
• Si paga entre el 11 y 20 tiene un recargo del 2
• Si paga el día 21 o después el recargo es del 4.
• Se ha realizado un programa que sólo solicita el
  día del mes en que se paga (en este ejercicio el
  mes no importa) y despliega el de recargo a
  cobrar.
• Diseñen los casos de prueba y entréguenlos

45
Respuesta.

• Paso 1 Analizar posibles entradas de datos
• Clases de datos (partición equivalente)
• Letras
• Nulo
• Negativo
• Positivo
• Cero
• Flotante
• Con coma
• Un valor entre 1-10
• Un valor entre 11-20
• Un valor entre 21-31
• Valores límite
• Rango 1-10 0, 1, 10,11
• Rango 11-20 10, 11, 20, 21
• Rango 21-31 20, 21, 31, 32

46

• Paso 2 Eliminar repetidos
• Clases de datos (partición equivalente)
• Letras
• Nulo
• Negativo
• Positivo
• Cero
• Flotante
• Con coma
• Un valor entre 1-10
• Un valor entre 11-20
• Un valor entre 21-31
• Valores límite
• Rango 1-10 0, 1, 10, 11
• Rango 11-20 10, 11, 20, 21
• Rango 21-31 20, 21, 31, 32

47

• Paso 3 diseñar casos de prueba con los datos
  resultantes