Pruebas

8.226 visualizaciones

Publicado el

Nociones básicas de pruebas.

0 comentarios
6 recomendaciones
Estadísticas
Notas
  • Sé el primero en comentar

Sin descargas
Visualizaciones
Visualizaciones totales
8.226
En SlideShare
0
De insertados
0
Número de insertados
28
Acciones
Compartido
0
Descargas
0
Comentarios
0
Recomendaciones
6
Insertados 0
No insertados

No hay notas en la diapositiva.

Pruebas

  1. 1. Diseño de casos de prueba<br />* ERP (“Enterprise Resource Planning”) <br />
  2. 2. 1<br />2<br />Conceptosgenerales de pruebas<br />Diseño de casos de prueba<br />Agenda<br />
  3. 3. 2<br />Diseño de casos de prueba<br />Agenda<br />1<br />Conceptosgenerales de pruebas<br />
  4. 4. Importancia de las pruebas<br />Los sistemas de software son una parte creciente en nuestra vida, desde aplicaciones de negocio (bancos) hasta productos de consumo (autos)<br />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.<br />Toyota anunció que llamará a revisión <br />133,000 vehículos del modelo Prius 2010<br />y 14,500 Lexus HS 250h 2010 "para <br />actualizar el software en el sistema de<br />antibloqueo de frenos (ABS) de los vehículos".<br />
  5. 5. Causas de los defectos de software<br />Un humano puede cometer un error que a su vez produce un defecto en el código, software, sistema o documento.<br />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.<br />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.<br />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<br />
  6. 6. Defectos causados por condiciones ambientales…<br />
  7. 7. Niveles de Pruebas<br />Para cada uno de los niveles de pruebas, puede identificarse lo siguiente:<br />Objetivos genéricos<br />Los productos que será referenciado de la derivación de los casos de prueba<br />El objetivo de la prueba (lo que será probado)<br />Defectos típicos y fallas a ser encontradas<br />Herramientas a utilizar<br />
  8. 8. Pruebas de componentes<br />Busca defectos<br />Verifica la funcionalidad<br />Módulos, programas, objetos, clases<br />Puede ser realizado aislado del resto del sistema según el contexto del desarrollo del ciclo de vida<br />Puede probar requerimientos funcionales o no funcionales<br />Los casos de prueba derivan de <br />Especificación de componentes<br />Arquitectura<br />Modelo de datos<br />
  9. 9. Pruebas de componentes<br />Se realiza accediendo al código a ser probado en el ambiente de desarrollo<br />Compilador<br />Involucrando al programador<br />Los defectos se corrigen tan pronto como son encontrados<br />No es necesario el registro formal de incidentes<br />Preparar y automatizar casos de prueba antes de la codificación<br />
  10. 10. Pruebas de integración<br />Prueba la interfase entre componentes<br />Interacciones con diferentes partes del sistema<br />S.O.<br />Sistema de archivo<br />Hardware<br />Interfases entre sistemas<br />En cada escenario de la integración, los probadores se concentran en al integración misma.<br />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.<br />
  11. 11. Pruebas de Sistema<br />Son concernientes al comportamiento del sistema/producto entero definido por el ámbito del proyecto de desarrollo o programa.<br />El ambiente del sistema debe corresponder al objetivo final de producción<br />Minimiza el riesgo de fallas de ambiente<br />Incluye pruebas basadas en:<br />El riesgo o especificación de requerimientos<br />Procesos de negocio<br />Comportamiento del sistema<br />Interacciones con el sistema operativo<br />Recursos del sistema<br />Debe probar los requerimientos funcionales y no funcionales<br />
  12. 12. Pruebas<br />Enfoques de las pruebas<br />Pruebas de desarrollo: causar tantas fallas como sea posible para que los defectos de software puedan ser detectados y corregidos<br />Pruebas de aceptación: confirmar que el sistema funciona en base a lo esperado, para asegurarse que cumple los requisitos.<br />Pruebas de mantenimiento: probar que no han sido introducidos nuevos defectos al código durante el desarrollo de cambios.<br />Pruebas operacionales: asegurar las características del sistema como disponibilidad y confiabilidad.<br />
  13. 13. Pruebas de aceptación<br />Comúnmente es responsabilidad de los usuario del sistema<br />Establece la confiabilidad del sistema<br />Encontrar defectos no es el principal enfoque<br />Debe asegurarse de que el sistema esta preparado para la implementación y uso<br />Pruebas de aceptación del usuario<br />Verifica comúnmente las condiciones de uso del sistema por los usuarios del negocio<br />
  14. 14. Pruebas de aceptación<br />Pruebas de aceptación operacional<br />Pruebas de restauración/respaldo<br />Recuperación de fallas<br />Administración de usuarios<br />Tareas de mantenimiento<br />Pruebas de aceptación contractual<br />Prueba el desempeño de cualquier regulación que dba ser incluida: legal, gobierno, seguridad<br />
  15. 15. 7 principios de las pruebas<br />Principio 1: Las pruebas muestran la presencia de defectos.<br />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.<br />
  16. 16. 7 principios de las pruebas<br />Principio 2: las pruebas exhaustivas son imposibles.<br />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.<br />
  17. 17. 7 principios de las pruebas<br />Principio 3: Pruebas tempranas.<br />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.<br />Principio 4: Agrupación de defectos.<br />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.<br />
  18. 18. 7 principios de las pruebas<br />Principio 5: Paradoja del pesticida.<br />Si las mismas pruebas son repetidas una y otra vez, ese conjunto de casos de prueba no encontrará más defectos.<br />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.<br />
  19. 19. 7 principios de las pruebas<br />Principio 6: Las pruebas son dependientes del contexto.<br />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.<br />Principio 7: La falacia de la ausencia de errores.<br />Encontrar y reparar defectos no ayuda si la construcción del sistema es inoperable y no satisface las necesidades y expectativas del cliente.<br />
  20. 20. Psicología de las pruebas<br />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.<br />
  21. 21. Psicología de las pruebas<br />Un cierto grado de independencia es más efectivo al encontrar defectos y fallas:<br />Pruebas diseñadas por la persona que escribió el código bajo prueba (bajo nivel de independencia)<br />Pruebas diseñadas por otras personas<br />Pruebas diseñadas por personas ajenas a la organización<br />Pruebas diseñadas por personas de diferente compañía u organización.<br />
  22. 22. Psicología de las pruebas<br />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.<br />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.<br />
  23. 23. 1<br />Conceptosgenerales de pruebas<br />Agenda<br />2<br />Diseño de casos de prueba<br />
  24. 24. ¿Qué es un caso de Prueba?<br />El estándar IEEE 610 (1990) define un caso de prueba como:<br />Un conjunto de entradas de prueba, condiciones de ejecución y resultados esperados desarrollados para un objetivo particular.<br />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<br />Un caso de prueba es un conjunto de pasos específicos que tiene resultados junto con varias piezas de información adicionales<br />1 de 1<br />
  25. 25. ¿Qué es un caso de Prueba?<br />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<br />Un caso de prueba debe contener algunos datos: <br />Identificador<br /> Nombre del caso de prueba<br />Objetivo<br />Precondiciones<br />Datos de entrada del requerimiento<br />Pasos a seguir<br />Resultados esperados <br />1 de 1<br />
  26. 26. ¿Qué es un caso de Prueba?<br />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<br />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<br />1 de 1<br />
  27. 27. ¿Qué es un caso de prueba?<br />Los casos de prueba pueden ser de dos tipos:<br />Casos de prueba positivos<br />Casos de prueba negativos<br />
  28. 28. Objetivos del diseño de Casos de Prueba<br />Detectar la mayor cantidad de defectos posible<br />Buena cobertura (no quede algo sin probar)<br />Minimizar los costos del desarrollo de pruebas<br />Minimizar los costos de la ejecución de pruebas<br />Minimizar los costos del mantenimiento de pruebas<br />
  29. 29. Desarrollo de pruebas<br />Una buena prueba debe tener una alta probabilidad de encontrar un defecto<br />El responsable de la prueba debe entender el software e intentar desarrollar una imagen mental de cómo podría fallar<br />Una buena prueba se centra en:<br />Probar si el software no hace lo que debe hacer<br />Probar si el software hace lo que no debe hacer<br />
  30. 30. Desarrollo de pruebas<br />Una buen prueba debe ser la mejor de todas<br />Se debería emplear la prueba que tenga la más alta probabilidad de descubrir una clase entera de errores.<br />Una buena prueba no debe ser ni muy sencilla ni muy compleja<br />Combinar varias pruebas a la vez puede enmascarar errores. Cada prueba debe hacerse por separado.<br />
  31. 31. Orígenes<br />
  32. 32. Casos de prueba de requerimientos<br />Pasos para seleccionar casos de prueba<br />Identificar los casos básicos que indiquen la funcionalidad del programa<br />Crear un conjunto básico de pruebas que cubran las entradas y salidas<br />Separar los casos complejos en casos más simples<br />Remover casos duplicados o innecesarios<br />Revisar sistemática y profundamente<br />
  33. 33. Casos de prueba en los extremos<br />Buscan condiciones excepcionales, límites, fronteras y anormalidades<br />Se necesita:<br />Experiencia<br />Creatividad del ingeniero de pruebas<br />
  34. 34. Casos de prueba aleatorios y extraídos<br />Los casos de prueba extraídos involucran ejemplos extraídos de datos reales para el proceso de pruebas<br />Los casos de prueba aleatorios involucran el uso de herramientas para generar datos potenciales para el proceso de pruebas<br />
  35. 35. Métodos para el diseño de casos de prueba<br />Partición de equivalencia<br />Análisis de valores límite<br />Adivinación de errores<br />Diagrama de causa-efecto<br />
  36. 36. Partición de equivalencia<br />Dominio de la entrada<br />Una clase de equivalencia es un subconjunto de datos que es representativo de una clase más grande<br />Se divide el dominio de la entrada dentro clases de equivalencia<br />Se intenta cubrir clases de errores<br />Un caso de prueba por cada clase de equivalencia para reducir el número total de casos de prueba necesarios<br />
  37. 37. Ejemplo <br />Un programa que autoriza créditos limita en base a u rango dado:<br />$10,000 a $15,000<br />Existen tres clases de equivalencia:<br />Menor a $10,000 (Inválido)<br />Entre $10,000 y $15,000 (Válido)<br />Mayor a $15,000 (Inválido)<br />
  38. 38. Partición de equivalencia<br />$9,800<br />$18,000<br />$12,500<br />
  39. 39. Ejercicio<br />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<br />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.<br />
  40. 40. Análisis de valores límite<br />Esta técnica consiste en desarrollar casos de prueba y datos enfocados en las entradas y salidas límite de una función dada<br />Complementan la partición de equivalencia seleccionando los casos de prueba en el filo de las clases de equivalencia<br />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<br />Se divide el dominio de entrada dentro de clases de equivalencia<br />
  41. 41. Análisis de valores límite<br />Valores válidos<br />Valores válidos<br />
  42. 42. Ejemplo<br />En el mismo ejemplo del límite de crédito el análisis de límites sería:<br />Límite inferior más ó menos 1<br />$9,999 y 10,001<br />En el límite<br />$10,000 y $15,000<br />Por encima del límite más ó menos 1<br />$14,999 y %15,001<br />
  43. 43. Rango de valores límite<br />Un valor inmediatamente por debajo del rango<br />Primer valor del rango<br />Segundo valor del rango<br />Valor inmediatamente por debajo del último valor del rango<br />Último valor del rango<br />Valor inmediatamente por encima del rango<br />
  44. 44. Adivinación de errores<br />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<br />
  45. 45. Ejemplo.<br />En un sistema donde en una de sus funciones debe ingresar una fecha:<br />El ingeniero de prueba puede introducir<br />29/02/2000<br />09/09/9999<br />
  46. 46. Diagrama de causa efecto<br />Ofrece una descripción de condiciones lógicas y acciones asociadas<br />4 etapas<br />Las causas (condiciones de entrada) y efectos (acciones) son listadas para un módulo y un identificador es asociado a cada una<br />Se crea una gráfica de causa-efecto<br />La gráfica se convierte en una tabla de decisión<br />La tabla de decisión se convierte en casos de prueba<br />
  47. 47. Diagrama de causa efecto<br />Ofrece una descripción de condiciones lógicas y acciones asociadas<br />4 etapas<br />Las causas (condiciones de entrada) y efectos (acciones) son listadas para un módulo y un identificador es asociado a cada una<br />Se crea una gráfica de causa-efecto<br />La gráfica se convierte en una tabla de decisión<br />La tabla de decisión se convierte en casos de prueba<br />
  48. 48. Ejemplo<br />Se tiene un requerimiento donde se prueba la condición siguiente:<br />If A or B then C<br />Las siguientes reglas cumplen este requerimiento:<br />Si A esverdadero y B esverdadero , entonces C esverdadero .<br />If A esverdadero y B esfalso, entonces C esverdadero .<br />If A esfalso y B esverdadero , entonces C esverdadero .<br />If A esfalso y B esfalso, entonces C esfalso.<br />
  49. 49. Ejemplo<br />A,B y C son llamados nodos<br />A y B son las causas y C el efecto. Las líneas son llamadas vectores<br />Todos los requerimientos se trasladan a nodos y relaciones<br />Solo hay 4 posibles relaciones<br />A ----- C<br />A ____VC<br />A ____ ^C<br />A_____~C<br />
  50. 50. Ejemplo<br />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<br />Cada columna representa un caso de prueba y cada caso de prueba corresponde a una única posible combinación<br />
  51. 51. Ejemplo<br />Solo hay 3 casos de prueba, sin embargo cubren el 100% de la funcionalidad.<br />Colocar A y B T redundaría.<br />
  52. 52. Buenas prácticas del diseño de casos de prueba<br />Desarrollar al menos dos casos de prueba por cada requerimiento a probar.<br />Un caso de prueba para demostrar que un requerimiento ha sido implementado, se conoce como Caso de Prueba Positivo<br />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<br />
  53. 53. Formato del caso de Prueba<br />
  54. 54. Formato del caso de Prueba<br />(casos aprobados *100)/CP a evaluar<br />
  55. 55. Perfeccionando las pruebas - Conceptos<br />Testability<br />Fácil de probar<br />Escribir en modo activo:<br />Hacer esto, hacer lo otro<br />El sistema muestra esto, hace esto otro<br />Usar lenguaje simple y conversacional<br />Exactitud, nombres de campos consistentes y no genéricos<br />No explicar las funciones básicas de Windows<br />Ir al menú inicio…<br />Ir al menú archivo/Seleccionar…<br />Abrir en con el botón inicio/todos los programas/Internet explorer<br />De 10 a 15 pasos o menos para describir casos de prueba<br />Siempre actualizar los casos de uso<br />

×