IMPORTANCIALa detección oportuna
Análisis de                       Diseño de                          *UI                                        Prueba de ...
Análisis de                                      DETECCIÓN DE                                        ERRORES              ...
ESTABILIDAD ESCALABILIDADEFICIENCIA   SEGURIDAD
$
FUENTE DEL PROBLEMA:
FUENTE DEL PROBLEMA:SOFTWARE
Tipos de Prueba                        Caja NegraPruebas Unitarias                        Pruebas dePruebas Funcionales   ...
Tipos de PruebaPruebas de RecorridoPruebas de MutaciónPruebas concurrentes
Pruebas UnitariasPrueban el correctofuncionamiento de unmódulo de código.Sirven para asegurarque cada uno de losmódulos fu...
Pruebas FuncionalesBasadas en la           evaluar cada una deejecución, revisión y   las opciones con lasretroalimentació...
Pruebas de IntegraciónSe realizan una vezque se han aprobadolas pruebas unitarias.Únicamente serefieren a la prueba oprueb...
Pruebas de ValidaciónSon el proceso derevisión que elsistema de softwareproducido cumple conlas especificaciones yque cump...
Caja BlancaSe centra en losdetallesprocedimentales delsoftware, por lo quesu diseño estáfuertemente ligado alcódigo fuente.
Caja NegraEl proceso esestudiado desde elpunto de vista de lasentradas que recibe ylas salidas orespuestas queproduce, sin...
Pruebas de SistemaSe prueba un sistemacompletamenteintegrado paraverificar que cumplacon sus requisitos
Pruebas de AceptaciónPuede significar 2 cosas:  Una “prueba de            La prueba es ejecutada  humo” es utilizada      ...
Pruebas de RegresiónIntentan descubrir lascausas de nuevos errores(bugs), carencias defuncionalidad, odivergencias funcion...
Pruebas de CargaSon el proceso deponer una cantidad dedemanda en unsistema o dispositivoy medir su respuesta.
Pruebas de Prestaciones (óPerformance, ó Desempeño)Se ejecutan paradeterminar qué tanrápido un sistema osub-sistema trabaj...
Pruebas de RecorridoEs una forma de reseñaentre colegas en la que undiseñador ó programadorguía a los miembros delequipo d...
Pruebas de MutaciónMétodos queinvolucran lamodificación delcódigo fuente de unprograma de maneramínima.
Pruebas de MutaciónMétodos queinvolucran lamodificación delcódigo fuente de unprograma de maneramínima.
Pruebas ConcurrentesSe desarrollan bajo lapremisa de que,mientras se desarrollael código, éste estásiendo sometido apruebas.
Manejo de Pruebas Técnicas de Software: pt. 2
Manejo de Pruebas Técnicas de Software: pt. 2
Manejo de Pruebas Técnicas de Software: pt. 2
Manejo de Pruebas Técnicas de Software: pt. 2
Manejo de Pruebas Técnicas de Software: pt. 2
Manejo de Pruebas Técnicas de Software: pt. 2
Manejo de Pruebas Técnicas de Software: pt. 2
Manejo de Pruebas Técnicas de Software: pt. 2
Manejo de Pruebas Técnicas de Software: pt. 2
Manejo de Pruebas Técnicas de Software: pt. 2
Manejo de Pruebas Técnicas de Software: pt. 2
Manejo de Pruebas Técnicas de Software: pt. 2
Manejo de Pruebas Técnicas de Software: pt. 2
Manejo de Pruebas Técnicas de Software: pt. 2
Upcoming SlideShare
Loading in …5
×

Manejo de Pruebas Técnicas de Software: pt. 2

2,089 views

Published on

Segunda parte de la unidad: "Pruebas de Software".

Published in: Education
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,089
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
28
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • \n
  • \n
  • \n
  • Tenemos frente a nosotros lo que es el flujo de la información en el ciclo de Ingeniería de Software. Si recuerdan lo expuesto en clases anteriores y han revisado la Bibliografía revelada en el temario, se darán cuenta de que cuando existen modificaciones que realizar en la etapa de mantenimiento, la información generada en esta etapa se devuelve al Análisis de Requisitos. Esto, con el fin de tomar la información generada en la etapa de Mantenimiento y evaluarla de acuerdo a los lineamientos emanados de los principales requisitos.\n\nEl proceso de prueba es clave al momento de detectar errores en nuestro proyecto.\n\n
  • Tenemos frente a nosotros lo que es el flujo de la información en el ciclo de Ingeniería de Software. Si recuerdan lo expuesto en clases anteriores y han revisado la Bibliografía revelada en el temario, se darán cuenta de que cuando existen modificaciones que realizar en la etapa de mantenimiento, la información generada en esta etapa se devuelve al Análisis de Requisitos. Esto, con el fin de tomar la información generada en la etapa de Mantenimiento y evaluarla de acuerdo a los lineamientos emanados de los principales requisitos.\n\nEl proceso de prueba es clave al momento de detectar errores en nuestro proyecto.\n\n
  • Conceptos como estabilidad, escalabilidad, eficiencia y seguridad son llevados a un entorno de laboratorio de procesos, regido por el método científico de “prueba y error” hasta alcanzar los objetivos.\n\n¿Alguien conoce estos conceptos o tiene una aproximación a ellos?\n\n
  • Conceptos como estabilidad, escalabilidad, eficiencia y seguridad son llevados a un entorno de laboratorio de procesos, regido por el método científico de “prueba y error” hasta alcanzar los objetivos.\n\n¿Alguien conoce estos conceptos o tiene una aproximación a ellos?\n\n
  • Conceptos como estabilidad, escalabilidad, eficiencia y seguridad son llevados a un entorno de laboratorio de procesos, regido por el método científico de “prueba y error” hasta alcanzar los objetivos.\n\n¿Alguien conoce estos conceptos o tiene una aproximación a ellos?\n\n
  • Conceptos como estabilidad, escalabilidad, eficiencia y seguridad son llevados a un entorno de laboratorio de procesos, regido por el método científico de “prueba y error” hasta alcanzar los objetivos.\n\n¿Alguien conoce estos conceptos o tiene una aproximación a ellos?\n\n
  • Además, estos conceptos se relacionan a la calidad de un producto bien desarrollado.\n
  • Las aplicaciones de software han crecido en complejidad y tamaño, por lo tanto, también en costos.\n\nMientras más antes se detecte una falla, más barata es su corrección. \n
  • Las aplicaciones de software han crecido en complejidad y tamaño, por lo tanto, también en costos.\n\nMientras más antes se detecte una falla, más barata es su corrección. \n
  • Si quieren ver un ejemplo MUY actual al respecto vean los recientes reportes de la batería del iPhone 4S. ( http://gizmodo.com/5854510/whats-going-on-with-the-iphone-4s-battery )\n
  • Algunos apuntan como soluciones que descargues la batería hasta que se apague el dispositivo, que denota una falta de calibración entre el software que detecta la carga de la batería y el hardware en sí (muy presente en otras marcas). Otros señalan un bug (fallo) en los servicios de geolocalización que provoca que estos servicios se ejecuten aunque no los esté utilizando ninguna aplicación.Ninguno de estos problemas son graves, ni dejan al aparato inutilizable. Pero son un pequeño raspón en la experiencia de usuario que Apple tanto tiempo ha perfeccionado, y que afortunadamente para sus clientes la misma compañía nunca cambia su disposición de resolver problemas de sus clientes al menor costo posible.\n
  • Pero, ¿Cuál sigue siendo la fuente del problema?\n\nEstos problemas pudieron haber sido evitados, si en las pruebas se hubieran previsto tales situaciones. Pero el hubiera no existe, y ahora tienen algo de trabajo por delante en la compañía de la manzana.\n
  • Pero, ¿Cuál sigue siendo la fuente del problema?\n\nEstos problemas pudieron haber sido evitados, si en las pruebas se hubieran previsto tales situaciones. Pero el hubiera no existe, y ahora tienen algo de trabajo por delante en la compañía de la manzana.\n
  • El proceso de prueba de software es un proceso técnico especializado de investigación que requiere de profesionales altamente capacitados en lenguajes de desarrollo, métodos y técnicas de pruebas y herramientas especializadas. Y, con frecuencia, el conocimiento que debe manejar un ingeniero de prueba es “n” veces superior al del desarrollador de software, esto es relativo al grado de preparación y educación continua que lleva el desarrollador consigo mismo.\n
  • El proceso de prueba de software es un proceso técnico especializado de investigación que requiere de profesionales altamente capacitados en lenguajes de desarrollo, métodos y técnicas de pruebas y herramientas especializadas. Y, con frecuencia, el conocimiento que debe manejar un ingeniero de prueba es “n” veces superior al del desarrollador de software, esto es relativo al grado de preparación y educación continua que lleva el desarrollador consigo mismo.\n
  • El proceso de prueba de software es un proceso técnico especializado de investigación que requiere de profesionales altamente capacitados en lenguajes de desarrollo, métodos y técnicas de pruebas y herramientas especializadas. Y, con frecuencia, el conocimiento que debe manejar un ingeniero de prueba es “n” veces superior al del desarrollador de software, esto es relativo al grado de preparación y educación continua que lleva el desarrollador consigo mismo.\n
  • El proceso de prueba de software es un proceso técnico especializado de investigación que requiere de profesionales altamente capacitados en lenguajes de desarrollo, métodos y técnicas de pruebas y herramientas especializadas. Y, con frecuencia, el conocimiento que debe manejar un ingeniero de prueba es “n” veces superior al del desarrollador de software, esto es relativo al grado de preparación y educación continua que lleva el desarrollador consigo mismo.\n
  • \n
  • \n
  • Para que una prueba unitaria sea buena se deben cumplir los siguientes requisitos:\nAutomatizable: no debería requerirse una intervención manual. Esto es especialmente útil para integración continua.\nCompletas: deben cubrir la mayor cantidad de código.\nRepetibles o Reutilizables: no se deben crear pruebas que sólo puedan ser ejecutadas una sola vez. También es útil para integración continua.\nIndependientes: la ejecución de una prueba no debe afectar a la ejecución de otra.\nProfesionales: las pruebas deben ser consideradas igual que el código, con la misma profesionalidad, documentación, etc.\nAunque estos requisitos no tienen que ser cumplidos al pie de la letra, se recomienda seguirlos o de lo contrario las pruebas pierden parte de su función.\n
  • \n
  • Consiste en realizar pruebas para verificar que un gran conjunto de partes de software funcionan juntos.\n
  • Es normalmente una parte del proceso de pruebas de software de un proyecto, que también utiliza técnicas tales como evaluaciones, inspecciones, y tutoriales. La validación es el proceso de comprobar lo que se ha especificado es lo que el usuario realmente quería.\nSe trata de evaluar el sistema o parte de este durante o al final del desarrollo para determinar si satisface los requisitos iniciales. La pregunta a realizarse es: ¿Es esto lo que el cliente quiere?.\n\nEnfoques a la verificación\nDinámica de verificación, también conocido como ensayos o experimentación.\nEstática de verificación, también conocido como análisis.\n\nTipos\nPruebas de aceptación: desarrolladas por el cliente.\nPruebas alfa realizadas por el usuario con el desarrollador como observador en un entorno controlado (simulación de un entorno de producción).\nPruebas beta: realizadas por el usuario en su entorno de trabajo y sin observadores.\n\nCaracterísticas\nComprobar que se satisfacen los requisitos:\nSe usan la mismas técnicas, pero con otro objetivo.\nNo hay programas de prueba, sino sólo el código final de la aplicación.\nSe prueba el programa completo.\nUno o varios casos de prueba por cada requisito o caso de uso especificado.\nSe prueba también rendimiento, capacidad, etc. (y no sólo resultados correctos).\nPruebas alfa (desarrolladores) y beta (usuarios).\n
  • El encargado de pruebas escoge distintos valores de entrada para examinar cada uno de los posibles flujos de ejecución del programa y cerciorarse de que se devuelven los valores de salida adecuados.\n\nEs aplicable a varios niveles: unidad, integración y sistema.\n\nLas principales técnicas de diseño de pruebas de caja blanca son:\nPruebas de flujo de control\nPruebas de flujo de datos\nPruebas de bifurcación (branch testing)\nPruebas de caminos básicos\n\n
  • de una caja negra nos interesará su forma de interactuar con el medio que le rodea (en ocasiones, otros elementos que también podrían ser cajas negras) entendiendo qué es lo que hace, pero sin dar importancia a cómo lo hace. Por tanto, de una caja negra deben estar muy bien definidas sus entradas y salidas, es decir, su interfaz; en cambio, no se precisa definir ni conocer los detalles internos de su funcionamiento.\n\nSu justificación reside en que un sistema formado por módulos que cumplan las características de caja negra será más fácil de entender ya que permitirá dar una visión más clara del conjunto. El sistema también será más robusto y fácil de mantener, en caso de ocurrir un fallo, éste podrá ser aislado y abordado más ágilmente.\n
  • Tiene similitudes con la prueba de “Caja Negra”, en el sentido que no requiere conocimiento del diseño interno del código o su lógica.\nEsta prueba a su vez encierra una lista de pruebas muy grande que se enlista a continuación:\nPruebas de interfaz gráfica de usuario\nPruebas de usabilidad\nPrueba de Desempeño\nPrueba de Compatibilidad\nPrueba de Manejo de Errores\nPrueba de cargas\nPrueba de volumen\nPrueba de Estrés\nPrueba de Seguridad\nPrueba de Escalabilidad\nPrueba de Sanidad\nPrueba de Humo\nPrueba exploratoria\nPrueba ad hoc\nPrueba de regresión\nPrueba de confifanza\nPrueba de instalación\nPrueba de mantenimiento\nPrueba de Recuperación\nPrueba de accesibilidad, cumpliendo con los lineamientos de:\n Americans with Disabilities Act of 1990\n Section 508 Amendment to the Rehabilitation Act of 1973\n Web Accessibility Initiative (WAI) of the World Wide Web Consortium (W3C)\n
  • Una prueba de humo se refiere a pruebas físicas hechas a sistemas cerrados de tubería para encontrar “fugas”. El término es utilizado para las primeras pruebas hechas despues de un ensamblaje (en este caso de código), de una manera metafórica.\nEl término es ampliamente utilizado en los campos de la electrónica, desarrollo de software, plomería, control de plagas, entre otros.\n
  • Normalmente, éstos bugs ó errores son consecuencias inesperadas de la adición de nuevas características a nuestros sistemas cuando los módulos recién implementados colisionan con código pre-existente.\n
  • Hay poco acuerdo en cuanto a los objetivos de este tipo de prueba. El término a veces se utiliza como sinónimo de prueba de desempeño de software, prueba de confiabilidad, y prueba de volumen. Las pruebas de carga son un tipo de prueba no funcional.\n\nHerramientas para este tipo de pruebas:\nAppLoader , NRG Globar\nblitz.io , de Mu Dynamics\nIBM Rational Performance Tester\nIXIA IxLoad , de Ixia\nJMeter , de Apache\nLoad Test (included with Soatest) , de Parasoft\nLoadRunner , de HP\nOpenSTA , Software Libre GPL\nSilkPerformer , de Micro Focus\nSLAMD , Open Source\nVisual Studio Load Test ,de Microsoft \n\n
  • ...como la escalabilidad, la confiabilidad y el uso de recursos.\n
  • Hoy en día muchas aplicaciones móviles y módulos de instalación están basados en este tipo de prueba, que es menos técnica pero muy precisa al momento de medir la usabilidad de un sistema.\n
  • Estas modificaciones intentan obtener los mismos resultados modulares a través de diferentes procesos lógicos.\n\nEstas pruebas surgen a partir de la proliferación de los lenguajes de programación orientados a objetos y los frameworks de pruebas unitarias, debido a las necesidades de probar porciones individuales de una aplicación y no la estructura completa.\n\nÉstas pruebas como consecuencia nos pueden arrojar más y mejores métodos para la implementación de procesos dentro de nuestro código.\n\nEs decir “Para el mismo fin, existen varios caminos”.\n\n
  • Mientras el equipo de desarrollo completa los requerimientos del código para una aplicación o sistema, este código requerido se hace “testeable”. Mientras, otros miembros del equipo pueden ejecutar casos de prueba contra el código completado.\nEstas pruebas han generado ciclos de retroalimentación más cortos bajo entornos de trabajo SCRUM, XP, Crystal, entre otros, por lo tanto, el costo de las fallas ha sido reducido gracias a estas pruebas.\n
  • Manejo de Pruebas Técnicas de Software: pt. 2

    1. 1. IMPORTANCIALa detección oportuna
    2. 2. Análisis de Diseño de *UI Prueba de Software Mantenimient o*UI = User Interface = Interfaz de Usuario
    3. 3. Análisis de DETECCIÓN DE ERRORES Diseño de *UI Prueba de Software Mantenimient o*UI = User Interface = Interfaz de Usuario
    4. 4. ESTABILIDAD ESCALABILIDADEFICIENCIA SEGURIDAD
    5. 5. $
    6. 6. FUENTE DEL PROBLEMA:
    7. 7. FUENTE DEL PROBLEMA:SOFTWARE
    8. 8. Tipos de Prueba Caja NegraPruebas Unitarias Pruebas dePruebas Funcionales AceptaciónPruebas de Pruebas de RegresiónIntegración Pruebas de CargaPruebas de Validación Pruebas dePruebas de Sistema Prestaciones
    9. 9. Tipos de PruebaPruebas de RecorridoPruebas de MutaciónPruebas concurrentes
    10. 10. Pruebas UnitariasPrueban el correctofuncionamiento de unmódulo de código.Sirven para asegurarque cada uno de losmódulos funcionecorrectamente porseparado.
    11. 11. Pruebas FuncionalesBasadas en la evaluar cada una deejecución, revisión y las opciones con lasretroalimentación de que cuenta el paquetelas funcionalidades informático.previamentediseñadas para elsoftware. La pruebasfuncionales se hacenmediante el diseño demodelos de prueba
    12. 12. Pruebas de IntegraciónSe realizan una vezque se han aprobadolas pruebas unitarias.Únicamente serefieren a la prueba opruebas de todos loselementos unitariosque componen unproceso, hecha enconjunto, de una sola
    13. 13. Pruebas de ValidaciónSon el proceso derevisión que elsistema de softwareproducido cumple conlas especificaciones yque cumple sucometido.
    14. 14. Caja BlancaSe centra en losdetallesprocedimentales delsoftware, por lo quesu diseño estáfuertemente ligado alcódigo fuente.
    15. 15. Caja NegraEl proceso esestudiado desde elpunto de vista de lasentradas que recibe ylas salidas orespuestas queproduce, sin tener encuenta sufuncionamientointerno.
    16. 16. Pruebas de SistemaSe prueba un sistemacompletamenteintegrado paraverificar que cumplacon sus requisitos
    17. 17. Pruebas de AceptaciónPuede significar 2 cosas: Una “prueba de La prueba es ejecutada humo” es utilizada por el usuario final en su después de introducir propio centro de una nueva cómputo con su propio compilación al hardware. Puede ser proceso principal de utilizada como enlace prueba. Ej: Antes de entre diferentes etapas una integración o una del proceso de regresión Ingeniería.
    18. 18. Pruebas de RegresiónIntentan descubrir lascausas de nuevos errores(bugs), carencias defuncionalidad, odivergencias funcionalescon respecto alcomportamiento esperadodel software, inducidos porcambios recientementerealizados en partes de laaplicación queanteriormente al citadocambio no eran propensas a
    19. 19. Pruebas de CargaSon el proceso deponer una cantidad dedemanda en unsistema o dispositivoy medir su respuesta.
    20. 20. Pruebas de Prestaciones (óPerformance, ó Desempeño)Se ejecutan paradeterminar qué tanrápido un sistema osub-sistema trabajabajo una cargaparticular de trabajo.Puede servir paravalidar y verificar otrosatributos relacionadoscon la calidad delsistema...
    21. 21. Pruebas de RecorridoEs una forma de reseñaentre colegas en la que undiseñador ó programadorguía a los miembros delequipo de desarrollo yterceros interesados através de un producto desoftware, y los participanteshacen preguntas ycomentarios sobre erroresposibles, violación deestándares de desarrollo yotros problemas.
    22. 22. Pruebas de MutaciónMétodos queinvolucran lamodificación delcódigo fuente de unprograma de maneramínima.
    23. 23. Pruebas de MutaciónMétodos queinvolucran lamodificación delcódigo fuente de unprograma de maneramínima.
    24. 24. Pruebas ConcurrentesSe desarrollan bajo lapremisa de que,mientras se desarrollael código, éste estásiendo sometido apruebas.

    ×