• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Pruebas
 

Pruebas

on

  • 7,366 views

Nociones básicas de pruebas.

Nociones básicas de pruebas.

Statistics

Views

Total Views
7,366
Views on SlideShare
7,366
Embed Views
0

Actions

Likes
4
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Pruebas Pruebas Presentation Transcript

    • Diseño de casos de prueba
      * ERP (“Enterprise Resource Planning”)
    • 1
      2
      Conceptosgenerales de pruebas
      Diseño de casos de prueba
      Agenda
    • 2
      Diseño de casos de prueba
      Agenda
      1
      Conceptosgenerales de pruebas
    • Importancia de las pruebas
      Los sistemas de software son una parte creciente en nuestra vida, desde aplicaciones de negocio (bancos) hasta productos de consumo (autos)
      Muchas personas han tenido experiencias con software que no trabaja como es esperado. El software que no hace su trabajo correctamente puede acarrear muchos problemas, desde pérdida de dinero, tiempo o una mala reputación, y pueden incluso causar lesiones o muerte.
      Toyota anunció que llamará a revisión
      133,000 vehículos del modelo Prius 2010
      y 14,500 Lexus HS 250h 2010 "para
      actualizar el software en el sistema de
      antibloqueo de frenos (ABS) de los vehículos".
    • Causas de los defectos de software
      Un humano puede cometer un error que a su vez produce un defecto en el código, software, sistema o documento.
      Si un defecto en el código es ejecutado, el sistema fallará en hacer lo que tenía que hacer (o hará algo que no debía), causando una falla. Los defectos en el software, sistemas o documentos pueden resultar en fallas, pero no todos.
      Los defectos ocurren porque los principios humanos son falibles y por la existencia de presión, código complejo, infraestructura compleja, cambio en las tecnologías y/o muchas interacciones del sistema.
      Los defectos pueden ser causados por condiciones ambientales como: radiación, magnetismo, campos electrónicos y contaminación y pueden causar fallas en el firmware o influir en la ejecución de software al cambiar las condiciones del hardware
    • Defectos causados por condiciones ambientales…
    • Niveles de Pruebas
      Para cada uno de los niveles de pruebas, puede identificarse lo siguiente:
      Objetivos genéricos
      Los productos que será referenciado de la derivación de los casos de prueba
      El objetivo de la prueba (lo que será probado)
      Defectos típicos y fallas a ser encontradas
      Herramientas a utilizar
    • Pruebas de componentes
      Busca defectos
      Verifica la funcionalidad
      Módulos, programas, objetos, clases
      Puede ser realizado aislado del resto del sistema según el contexto del desarrollo del ciclo de vida
      Puede probar requerimientos funcionales o no funcionales
      Los casos de prueba derivan de
      Especificación de componentes
      Arquitectura
      Modelo de datos
    • Pruebas de componentes
      Se realiza accediendo al código a ser probado en el ambiente de desarrollo
      Compilador
      Involucrando al programador
      Los defectos se corrigen tan pronto como son encontrados
      No es necesario el registro formal de incidentes
      Preparar y automatizar casos de prueba antes de la codificación
    • Pruebas de integración
      Prueba la interfase entre componentes
      Interacciones con diferentes partes del sistema
      S.O.
      Sistema de archivo
      Hardware
      Interfases entre sistemas
      En cada escenario de la integración, los probadores se concentran en al integración misma.
      Si se prueba el módulo A contra el módulo B, están interesados en probar la comunicación entre los módulos, no la funcionalidad de cada uno de ellos.
    • Pruebas de Sistema
      Son concernientes al comportamiento del sistema/producto entero definido por el ámbito del proyecto de desarrollo o programa.
      El ambiente del sistema debe corresponder al objetivo final de producción
      Minimiza el riesgo de fallas de ambiente
      Incluye pruebas basadas en:
      El riesgo o especificación de requerimientos
      Procesos de negocio
      Comportamiento del sistema
      Interacciones con el sistema operativo
      Recursos del sistema
      Debe probar los requerimientos funcionales y no funcionales
    • Pruebas
      Enfoques de las pruebas
      Pruebas de desarrollo: causar tantas fallas como sea posible para que los defectos de software puedan ser detectados y corregidos
      Pruebas de aceptación: confirmar que el sistema funciona en base a lo esperado, para asegurarse que cumple los requisitos.
      Pruebas de mantenimiento: probar que no han sido introducidos nuevos defectos al código durante el desarrollo de cambios.
      Pruebas operacionales: asegurar las características del sistema como disponibilidad y confiabilidad.
    • Pruebas de aceptación
      Comúnmente es responsabilidad de los usuario del sistema
      Establece la confiabilidad del sistema
      Encontrar defectos no es el principal enfoque
      Debe asegurarse de que el sistema esta preparado para la implementación y uso
      Pruebas de aceptación del usuario
      Verifica comúnmente las condiciones de uso del sistema por los usuarios del negocio
    • Pruebas de aceptación
      Pruebas de aceptación operacional
      Pruebas de restauración/respaldo
      Recuperación de fallas
      Administración de usuarios
      Tareas de mantenimiento
      Pruebas de aceptación contractual
      Prueba el desempeño de cualquier regulación que dba ser incluida: legal, gobierno, seguridad
    • 7 principios de las pruebas
      Principio 1: Las pruebas muestran la presencia de defectos.
      Las pruebas pueden mostrar que los defectos están presentes, pero no pueden probar que no son defectos. Las pruebas reducen la probabilidad de mantener defectos ocultos en el software pero, si no se encuentran defectos, no es una prueba de que este correcto.
    • 7 principios de las pruebas
      Principio 2: las pruebas exhaustivas son imposibles.
      Probar todo (todas las combinaciones de entradas y precondiciones) no es viable excepto para casos excepcionales. En lugar de pruebas exhaustivas, el análisis de riesgo y prioridades debería ser usado para enfocar las pruebas.
    • 7 principios de las pruebas
      Principio 3: Pruebas tempranas.
      Las actividades relacionadas a las pruebas, deben iniciar tan temprano como sea posible en el ciclo de vida de desarrollo de software, y debe enfocarse en objetivos definidos.
      Principio 4: Agrupación de defectos.
      Un pequeño número de módulos contienen la mayor parte de los defectos encontrados durante la preliberación de pruebas, o es responsable de la mayor parte de las fallas operacionales.
    • 7 principios de las pruebas
      Principio 5: Paradoja del pesticida.
      Si las mismas pruebas son repetidas una y otra vez, ese conjunto de casos de prueba no encontrará más defectos.
      Para evitar la paradoja del pesticida, los casos de prueba necesitan ser revisados regularmente, deben escribirse nuevos casos de prueba para probar diferentes partes del software o sistema para potenciar el hallazgo de nuevos errores.
    • 7 principios de las pruebas
      Principio 6: Las pruebas son dependientes del contexto.
      Las pruebas son diferentes en diferentes conceptos. Po ejemplo, el software crítico para un banco es probado diferente a un sitio de comercio electrónico.
      Principio 7: La falacia de la ausencia de errores.
      Encontrar y reparar defectos no ayuda si la construcción del sistema es inoperable y no satisface las necesidades y expectativas del cliente.
    • Psicología de las pruebas
      Con el modo de pensar correcto los desarrolladores son capaces de probar su propio código, pero la separación de esta tarea a un probador enfoca el esfuerzo y provee beneficios adicionales.
    • Psicología de las pruebas
      Un cierto grado de independencia es más efectivo al encontrar defectos y fallas:
      Pruebas diseñadas por la persona que escribió el código bajo prueba (bajo nivel de independencia)
      Pruebas diseñadas por otras personas
      Pruebas diseñadas por personas ajenas a la organización
      Pruebas diseñadas por personas de diferente compañía u organización.
    • Psicología de las pruebas
      La búsqueda de fallas en un sistema requiere curiosidad, pesimismo profesional, ojo crítico, atención a los detalles, buena comunicación con los desarrolladores.
      Si los errores, defectos o fallas son comunicados de una manera constructiva, los malos entendidos entre probadores y analistas, diseñadores y desarrolladores pueden ser reducidos.
    • 1
      Conceptosgenerales de pruebas
      Agenda
      2
      Diseño de casos de prueba
    • ¿Qué es un caso de Prueba?
      El estándar IEEE 610 (1990) define un caso de prueba como:
      Un conjunto de entradas de prueba, condiciones de ejecución y resultados esperados desarrollados para un objetivo particular.
      El (IEEE Std 829-1983) especifica que es Documento que especifica entradas, resultados previstos y un conjunto de condiciones de ejecución para un elemento de prueba
      Un caso de prueba es un conjunto de pasos específicos que tiene resultados junto con varias piezas de información adicionales
      1 de 1
    • ¿Qué es un caso de Prueba?
      Un caso de prueba es un documento que describe una entrada, acción o evento y tiene una respuesta esperada para determinar si una característica de una aplicación funciona correctamente
      Un caso de prueba debe contener algunos datos:
      Identificador
      Nombre del caso de prueba
      Objetivo
      Precondiciones
      Datos de entrada del requerimiento
      Pasos a seguir
      Resultados esperados
      1 de 1
    • ¿Qué es un caso de Prueba?
      Hay que notar que el proceso de desarrollo de casos de prueba puede ayudar a encontrar problemas en los requerimientos o diseño de una aplicación ya que requiere por completo el pensar a través de la operación de la aplicación
      Por esta razón es muy útil preparar los casos de prueba lo más temprano posible en el ciclo de vida del software en caso de ser posible
      1 de 1
    • ¿Qué es un caso de prueba?
      Los casos de prueba pueden ser de dos tipos:
      Casos de prueba positivos
      Casos de prueba negativos
    • Objetivos del diseño de Casos de Prueba
      Detectar la mayor cantidad de defectos posible
      Buena cobertura (no quede algo sin probar)
      Minimizar los costos del desarrollo de pruebas
      Minimizar los costos de la ejecución de pruebas
      Minimizar los costos del mantenimiento de pruebas
    • Desarrollo de pruebas
      Una buena prueba debe tener una alta probabilidad de encontrar un defecto
      El responsable de la prueba debe entender el software e intentar desarrollar una imagen mental de cómo podría fallar
      Una buena prueba se centra en:
      Probar si el software no hace lo que debe hacer
      Probar si el software hace lo que no debe hacer
    • Desarrollo de pruebas
      Una buen prueba debe ser la mejor de todas
      Se debería emplear la prueba que tenga la más alta probabilidad de descubrir una clase entera de errores.
      Una buena prueba no debe ser ni muy sencilla ni muy compleja
      Combinar varias pruebas a la vez puede enmascarar errores. Cada prueba debe hacerse por separado.
    • Orígenes
    • Casos de prueba de requerimientos
      Pasos para seleccionar casos de prueba
      Identificar los casos básicos que indiquen la funcionalidad del programa
      Crear un conjunto básico de pruebas que cubran las entradas y salidas
      Separar los casos complejos en casos más simples
      Remover casos duplicados o innecesarios
      Revisar sistemática y profundamente
    • Casos de prueba en los extremos
      Buscan condiciones excepcionales, límites, fronteras y anormalidades
      Se necesita:
      Experiencia
      Creatividad del ingeniero de pruebas
    • Casos de prueba aleatorios y extraídos
      Los casos de prueba extraídos involucran ejemplos extraídos de datos reales para el proceso de pruebas
      Los casos de prueba aleatorios involucran el uso de herramientas para generar datos potenciales para el proceso de pruebas
    • Métodos para el diseño de casos de prueba
      Partición de equivalencia
      Análisis de valores límite
      Adivinación de errores
      Diagrama de causa-efecto
    • Partición de equivalencia
      Dominio de la entrada
      Una clase de equivalencia es un subconjunto de datos que es representativo de una clase más grande
      Se divide el dominio de la entrada dentro clases de equivalencia
      Se intenta cubrir clases de errores
      Un caso de prueba por cada clase de equivalencia para reducir el número total de casos de prueba necesarios
    • Ejemplo
      Un programa que autoriza créditos limita en base a u rango dado:
      $10,000 a $15,000
      Existen tres clases de equivalencia:
      Menor a $10,000 (Inválido)
      Entre $10,000 y $15,000 (Válido)
      Mayor a $15,000 (Inválido)
    • Partición de equivalencia
      $9,800
      $18,000
      $12,500
    • Ejercicio
      El módulo de captura de contrarecibo tiene establecido que para subir un archivo adjunto, el tamaño de dicho archivo no debe ser mayor a 4Mb. Encuentre la partición de equivalencia para esta función
      El módulo de Factura Electrónica obtiene el R.F.C. de un cliente. Para personas físicas es de 13 posiciones mientras que para una persona moral es de 12. realice la partición de equivalencia para ambos casos.
    • Análisis de valores límite
      Esta técnica consiste en desarrollar casos de prueba y datos enfocados en las entradas y salidas límite de una función dada
      Complementan la partición de equivalencia seleccionando los casos de prueba en el filo de las clases de equivalencia
      En la práctica, la mayor parte de los errores se encuentran en los límites de las clases de equivalencia que en la misma clase
      Se divide el dominio de entrada dentro de clases de equivalencia
    • Análisis de valores límite
      Valores válidos
      Valores válidos
    • Ejemplo
      En el mismo ejemplo del límite de crédito el análisis de límites sería:
      Límite inferior más ó menos 1
      $9,999 y 10,001
      En el límite
      $10,000 y $15,000
      Por encima del límite más ó menos 1
      $14,999 y %15,001
    • Rango de valores límite
      Un valor inmediatamente por debajo del rango
      Primer valor del rango
      Segundo valor del rango
      Valor inmediatamente por debajo del último valor del rango
      Último valor del rango
      Valor inmediatamente por encima del rango
    • Adivinación de errores
      En base a la teoría de que los casos de prueba pueden ser desarrollados basados en la intuición y experiencia del ingeniero de pruebas
    • Ejemplo.
      En un sistema donde en una de sus funciones debe ingresar una fecha:
      El ingeniero de prueba puede introducir
      29/02/2000
      09/09/9999
    • Diagrama de causa efecto
      Ofrece una descripción de condiciones lógicas y acciones asociadas
      4 etapas
      Las causas (condiciones de entrada) y efectos (acciones) son listadas para un módulo y un identificador es asociado a cada una
      Se crea una gráfica de causa-efecto
      La gráfica se convierte en una tabla de decisión
      La tabla de decisión se convierte en casos de prueba
    • Diagrama de causa efecto
      Ofrece una descripción de condiciones lógicas y acciones asociadas
      4 etapas
      Las causas (condiciones de entrada) y efectos (acciones) son listadas para un módulo y un identificador es asociado a cada una
      Se crea una gráfica de causa-efecto
      La gráfica se convierte en una tabla de decisión
      La tabla de decisión se convierte en casos de prueba
    • Ejemplo
      Se tiene un requerimiento donde se prueba la condición siguiente:
      If A or B then C
      Las siguientes reglas cumplen este requerimiento:
      Si A esverdadero y B esverdadero , entonces C esverdadero .
      If A esverdadero y B esfalso, entonces C esverdadero .
      If A esfalso y B esverdadero , entonces C esverdadero .
      If A esfalso y B esfalso, entonces C esfalso.
    • Ejemplo
      A,B y C son llamados nodos
      A y B son las causas y C el efecto. Las líneas son llamadas vectores
      Todos los requerimientos se trasladan a nodos y relaciones
      Solo hay 4 posibles relaciones
      A ----- C
      A ____VC
      A ____ ^C
      A_____~C
    • Ejemplo
      La gráfica de causa y efecto se convierte en una tabla de verdad que representa cada relación lógica entre las causas y lso efectos
      Cada columna representa un caso de prueba y cada caso de prueba corresponde a una única posible combinación
    • Ejemplo
      Solo hay 3 casos de prueba, sin embargo cubren el 100% de la funcionalidad.
      Colocar A y B T redundaría.
    • Buenas prácticas del diseño de casos de prueba
      Desarrollar al menos dos casos de prueba por cada requerimiento a probar.
      Un caso de prueba para demostrar que un requerimiento ha sido implementado, se conoce como Caso de Prueba Positivo
      Otro caso que refleje una anormalidad, condición o datos faltantes para demostrar que el requerimiento se cumple solo bajo las condiciones deseadas, se llama Caso de Prueba Negativo
    • Formato del caso de Prueba
    • Formato del caso de Prueba
      (casos aprobados *100)/CP a evaluar
    • Perfeccionando las pruebas - Conceptos
      Testability
      Fácil de probar
      Escribir en modo activo:
      Hacer esto, hacer lo otro
      El sistema muestra esto, hace esto otro
      Usar lenguaje simple y conversacional
      Exactitud, nombres de campos consistentes y no genéricos
      No explicar las funciones básicas de Windows
      Ir al menú inicio…
      Ir al menú archivo/Seleccionar…
      Abrir en con el botón inicio/todos los programas/Internet explorer
      De 10 a 15 pasos o menos para describir casos de prueba
      Siempre actualizar los casos de uso