Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

5. Métodos de Prueba de Software

8,324 views

Published on

Siguiendo con los apuntes de Ingeniería de Software para la Ingeniería en Computación, de la Universidad Tecnologica de la Mixteca en Huajuapan de León, Oaxaca México.

Published in: Education
  • You can hardly find a student who enjoys writing a college papers. Among all the other tasks they get assigned in college, writing essays is one of the most difficult assignments. Fortunately for students, there are many offers nowadays which help to make this process easier. The best service which can help you is ⇒ www.HelpWriting.net ⇐
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Hello! I can recommend a site that has helped me. It's called ⇒ www.HelpWriting.net ⇐ So make sure to check it out!
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

5. Métodos de Prueba de Software

  1. 1. 5 . M É T O D O S D E P R U E B A D E S O F T WA R E I N G E N I E R Í A D E S O F T WA R E U T M 2 0 1 7 M A Y O 2 0 1 5
  2. 2. ¿ P O R Q U É P R O B A R E L S O F T WA R E ? 2
  3. 3. ¿ Q U É E S P R O B A R S O F T WA R E ? ¿Qué hacen los ingenieros de pruebas? ¿Demostrar que el software funciona correctamente? ¿Buscar fallas? ¿Mejorar la calidad del software? Los expertos ofrecen diferentes definiciones para las pruebas del software pero hay algo en lo que todos parecen estar de acuerdo: probar software no consiste en demostrar que éste funciona correctamente. 3
  4. 4. 4
  5. 5. 5
  6. 6. E D S G E R D D I J K S T R A “Probar software es el proceso de ejecutar un programa con el objetivo de encontrar errores” 6
  7. 7. G L E N F O R D J M Y E R S “Las pruebas de software pueden ser usadas para mostrar la presencia de errores, pero nunca para demostrar la ausencia de errores!” 7
  8. 8. C E M K A N E R “Las pruebas de software es la investigación empírica como técnica que se desarrolla para ofrecerle a los stakeholders con información sobre la calidad del producto o servicio evaluado.” 8
  9. 9. 5 . 1 E L P R O C E S O D E P R U E B A S Las pruebas son básicamente un conjunto de actividades dentro del desarrollo de software. Dependiendo del tipo de pruebas, estas actividades podrán ser implementadas en cualquier momento de dicho proceso de desarrollo. Como existen distintos modelos de desarrollo de software, así también existen modelos para pruebas. A cada uno corresponde un nivel distinto de involucramiento en las actividades de desarrollo. 9
  10. 10. 10
  11. 11. 5 E L E M E N T O S E S E N C I A L E S 1. Una estrategia de pruebas que nos indique qué tipos de pruebas y la cantidad de ellas que consideremos serán suficientes para encontrar defectos en el software 2. Un plan de pruebas que nos diga cómo deberemos de llevar a cabo la estrategia 3. Casos de prueba que preparemos con anterioridad en la forma de ejemplos detallados que usaremos para comprobar si el software cumple sus requerimientos 4. Datos de prueba, que consiste en los datos de entrada y las bases de datos de prueba que se utilizarán para ejecutar los casos de prueba y 5. Un ambiente de pruebas que nos permitan llevar a cabo dichas pruebas 11
  12. 12. ¿ C Ó M O S E H A C E N L A S P R U E B A S E N E L M U N D O R E A L ? 1. Reunión inicial - ¿Quién es el cliente? ¿Duración del proyecto y fecha de entrega? ¿Stakeholders? 2. Plan de pruebas - desarrollado en base al SRS: se divide el diseño en módulos 3. Casos de Prueba y Escenarios - se crean pruebas siguiendo una filosofía bottom-top (pruebas de módulos y luego su integración) 4. Testing y debugging 12
  13. 13. P R U E B A S E N M E T O D O L O G Í A S Á G I L E S 13
  14. 14. 5 . 3 M É T O D O S D E P R U E B A • Diferentes técnicas de pruebas son apropiadas para diferentes momentos en el desarrollo de software • El primero en probar su código es el mismo desarrollador que puede ser asistido por grupos de pruebas independientes para proyectos grandes • El papel del tester independiente es eliminar el conflicto de interés inherente cuando el desarrollador prueba su propio producto 14
  15. 15. Validación ¿Estamos construyendo el producto correcto? Verificación ¿Estamos construyendo el proyecto correctamente? 15
  16. 16. E TA PA S D E P R U E B A S • Pruebas de Módulo o unitarias • Pruebas de Integración • Pruebas del Sistema • Pruebas de Rendimiento • Pruebas de Aceptación • Pruebas de Instalación 16
  17. 17. 17
  18. 18. 18
  19. 19. ¿ C A J A N E G R A O C A J A B L A N C A ? E L D I L E M A D E S I E M P R E … • El número de caminos lógicos determina si es caja blanca • La naturaleza de los datos de entrada • La cantidad de procesamiento necesario • La complejidad de los algoritmos 19
  20. 20. P R U E B A S U N I TA R I A S • Se deben de probar los límites de los rangos de datos • Los paths (rutas) básicas deben ser probadas • Todos las rutas que generen errores deben ser probadas • Drivers y/o stubs deben ser desarrollados para probar software incompleto 20
  21. 21. D AT O S D E P R U E B A • Idealmente se deben alternar datos válidos e inválidos • Particiones equivalentes (eg. fechas, edades, etc) • Pruebas de Regresión 21
  22. 22. P R U E B A S D E I N T E G R A C I Ó N • Proceso Bottom-Up (con Drivers) • Proces Top-Down (con Stubs) • Sandwich testing 22
  23. 23. P R U E B A S D E L S I S T E M A Pruebas de Recuperación • Checar las habilidades del sistema de recuperarse de fallas Pruebas de seguridad • Verifica los mecanismos de protección del sistema que prevenga accesos no autorizados o la alteración de datos Pruebas de Estrés • El sistema es probado para ver cómo se comporta con demandas de trabajo no planeadas Pruebas de Rendimiento • Prueba el desempeño del sistema por un largo periodo de tiempo 23
  24. 24. P R U E B A S D E R E N D I M I E N T O • Pruebas de Estrés • Pruebas de Volumen • Pruebas de Configuración (hardware & software). • Pruebas de Compatibilidad • Pruebas de Regresión • Pruebas de Seguridad 24
  25. 25. P R U E B A S D E R E N D I M I E N T O • Pruebas de Tiempo • Pruebas Ambientales • Pruebas de Calidad • Pruebas de Recuperación • Pruebas de Mantenimiento • Pruebas de Documentación • Evaluación de Factores Humanos (Usabilidad) 25
  26. 26. P R U E B A S D E A C E P TA C I Ó N 26
  27. 27. P R U E B A S D E A C E P TA C I Ó N Asegurarnos de que el software trabaja correctamente para los stakeholders en su ambiente normal de trabajo Pruebas Alfa • El sistema completo es probado por el cliente, con la presencia del equipo de desarrollo, en el sitio de desarrollo Pruebas Beta • El sistema completo es probado por el cliente, sin la presencia del equipo de desarrollo, en el sitio del cliente 27
  28. 28. E S T R AT E G I A S PA R A P R U E B A S D E A C E P TA C I Ó N • Pruebas de Benchmark • Pruebas Piloto • Pruebas en Paralelo 28
  29. 29. H E R R A M I E N TA S D E P R U E B A • Simuladores • Programas monitores • Analizadores de resultados • Generadores de datos de prueba 29
  30. 30. E Q U I P O D E P R U E B A S • Testers profesionales • Analistas • Diseñadores de sistema • Especialistas de configuración • Usuarios 30
  31. 31. 5 . 3 D I S E Ñ O D E P R U E B A S El objetivo del proceso de diseño de casos de prueba es crear un conjunto de casos de prueba que sean efectivos descubriendo defectos en los programas y muestren que el sistema satisface sus requerimientos. 31
  32. 32. P R O C E S O D E D I S E Ñ O • Para diseñar un caso de prueba, se selecciona una característica del sistema o componente que se está probando. • A continuación, se selecciona un conjunto de entradas que ejecutan dicha característica, documenta las salidas esperadas o rangos de salida y, donde sea posible, se diseña una prueba automatizada que prueba que las salidas reales y esperadas son las mismas. 32
  33. 33. T I P O S D E A P R O X I M A C I O N E S • Pruebas basadas en requerimientos • Pruebas de particiones • Pruebas estructurales • Pruebas de caminos 33
  34. 34. P R U E B A S B A S A D A S E N R E Q U E R I M I E N T O S • Los casos de prueba se diseñan para probar los requerimientos del sistema • Se usa generalmente en las pruebas del sistema • Se identifican casos de prueba que puedan demostrar que el sistema satisface ese requerimiento 34
  35. 35. P R U E B A S D E PA R T I C I O N E S • Se identifican particiones de entrada y salida y se diseñan pruebas para que el sistema ejecute entradas de todas las particiones y genere salidas para todas las particiones • Las particiones son grupos de datos que tienen características comunes 35
  36. 36. P R U E B A S E S T R U C T U R A L E S • Se utiliza el conocimiento de la estructura del programa para diseñar pruebas que ejecuten todas las partes del sistema • Cuando se prueba un sistema debería ejecutar cada instrucción al menos una vez. Las pruebas estructurales deben ayudar a hacer eso 36
  37. 37. P R U E B A S D E C A M I N O S • Es una estrategia de pruebas estructurales cuyo objetivo es probar cada camino de ejecución independiente en un componente o programa • Se pruebas cada instrucción al menos una vez. Las condiciones se prueban en verdadero y falso 37
  38. 38. 5 . 4 C A S O S D E E S T U D I O D E P R U E B A S D E S O F T WA R E 38
  39. 39. C A S O 1 : G O O G L E Y S U S P R U E B A S D E 1 0 M I N U T O S “Cada 10 minutos cambiaba de aplicación. Y a medida que los minutos pasaban mi equipo iba entendiendo el mensaje: descartaron la idea de describir el problema, la aplicación o cualquier cosa innecesaria. Cambiaron prosa por listas de viñetas. Caso omiso a cualquier información no relevante para el testing. Si no era importante, lo ignoraban. No había tiempo.” Así creamos el método ACC (atributos, componentes y capacidades) • Atributos (valor del producto para el usuario) • Componentes (enumerar, de memoria, los componentes del software) • Capacidades (las acciones que realiza el sistema) Caso de estudio: Cómo hace Google sus planes de pruebas (y los hace en menos de 10 minutos) http:// www.javiergarzas.com/2012/12/google-pruebas.html 39
  40. 40. C A S O 2 : P O K E R O N L I N E A P P Real Poker Online es una app cliente servidor desarrollada en Java que permite a jugadores de todo el mundo jugar poker Se busca validar los requerimientos, además de la escalabilidad del proyecto (Eclipse IDE, Ant, JUnit, XDoclet, Hibernate JDO, Tapestry Web Application Framework, Hessian RPC, Sun ONE J2EE 1.3 certified application server, Firebird RDBMS y Tomcat) La estimación inicial para las pruebas hecha por el cliente era de 8000 horas- hombre Bughuntress propuso pruebas automatizadas en vez de un proceso manual: caja negra, simulación, funcionalidad, estrés, usabilidad y pruebas de apuestas lógicas. Las pruebas finalmente requirieron 2500 horas-hombre CASE STUDIES: ONLINE GAME: http://www.bughuntress.com/portfolio/case-studies/poker-online 40
  41. 41. C A S O 3 : U S O D E H E R R A M I E N TA S D E S O F T WA R E L I B R E Reto: Las empresas deben entender los riesgos y mitigar los problemas que su desarrollo web enfrenta durante la etapa de desarrollo y cuando la aplicación se encuentra en producción Solución: PushToTest Turnkey Testing Services identifica y resuelve las causas de problemas de rendimiento y seguridad en ambientes de múltiples proveedores Resultados: • Desarrollo de scripts de pruebas y ejecución de pruebas funcionales y en pruebas de rendimiento y volumen • Costo: comparado con herramientas propietarias, las soluciones de PushToTest ahora el 895% en la creación de pruebas y el 33% en las pruebas reales • Certificación: PushToHelp ayuda a mitigar los riesgos en pruebas funcionales, de seguridad y rendimiento PushToTest Case Studies: http://www.pushtotest.com/software-testing-case-studies.html 41
  42. 42. C A S O 4 : T E S T I N G Á G I L D E S O F T WA R E C O N H E R R A M I E N TA S L I B R E S Y A B I E R TA S El paper describe las pruebas de software mediante el uso de una metodología ágil (SCRUM) y herramientas de software libre y abierto aplicadas a un proyecto en particular: SWEST (Software para Empresas deServicios Temporales) • Necesidad urgente del cliente por tener en producción la aplicación, en concreto el módulo de nómina • Antecedentes de fallos e incidencias en la primera versión del módulo de nómina • Necesidad de mostrar resultados en el menor tiempo posible. Tres herramientas utilizadas y probadas: TestLink, Mantis y PangoScrum Paper en: http://www.academia.edu/2332917/Testing_ %C3%81gil_de_Software_con_Herramientas_Libres_y_Abiertas 42
  43. 43. C A S O 5 : P R U E B A S D E C O M PAT I B I L I D A D D E G U I El cliente: proveedor líder de fotografía y contenidos para empresas en el ramo de hoteles y viajes El reto: asegurar la compatibilidad de su UI en varias plataformas sin ningún problema La solución: • Análisis de requerimientos utilizando la arquitectura y escenarios de alto nivel • Pruebas de las interfaces con escenarios y prototipos • Casos de prueba para diferentes medios ambientes y resoluciones • Reportes diarios • GUI COMPATIBILITY TESTING CASE STUDY: http://www.optimusinfo.com/case- study/gui-compatibility-testing/ 43

×