22. Tipos de Prueba
Caja Negra
Pruebas Unitarias
Pruebas de
Pruebas Funcionales
Aceptación
Pruebas de
Pruebas de Regresión
Integración
Pruebas de Carga
Pruebas de Validación
Pruebas de
Pruebas de Sistema
Prestaciones
24. Pruebas Unitarias
Prueban el correcto
funcionamiento de un
módulo de código.
Sirven para asegurar
que cada uno de los
módulos funcione
correctamente por
separado.
25. Pruebas Funcionales
Basadas en la evaluar cada una de
ejecución, revisión y las opciones con las
retroalimentación de que cuenta el paquete
las funcionalidades informático.
previamente
diseñadas para el
software. La pruebas
funcionales se hacen
mediante el diseño de
modelos de prueba
26. Pruebas de Integración
Se realizan una vez
que se han aprobado
las pruebas unitarias.
Únicamente se
refieren a la prueba o
pruebas de todos los
elementos unitarios
que componen un
proceso, hecha en
conjunto, de una sola
27. Pruebas de Validación
Son el proceso de
revisión que el
sistema de software
producido cumple con
las especificaciones y
que cumple su
cometido.
28. Caja Blanca
Se centra en los
detalles
procedimentales del
software, por lo que
su diseño está
fuertemente ligado al
código fuente.
29. Caja Negra
El proceso es
estudiado desde el
punto de vista de las
entradas que recibe y
las salidas o
respuestas que
produce, sin tener en
cuenta su
funcionamiento
interno.
30. Pruebas de Sistema
Se prueba un sistema
completamente
integrado para
verificar que cumpla
con sus requisitos
31. Pruebas de Aceptación
Puede 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.
32. Pruebas de Regresión
Intentan descubrir las
causas de nuevos errores
(bugs), carencias de
funcionalidad, o
divergencias funcionales
con respecto al
comportamiento esperado
del software, inducidos por
cambios recientemente
realizados en partes de la
aplicación que
anteriormente al citado
cambio no eran propensas a
33. Pruebas de Carga
Son el proceso de
poner una cantidad de
demanda en un
sistema o dispositivo
y medir su respuesta.
34. Pruebas de Prestaciones (ó
Performance, ó Desempeño)
Se ejecutan para
determinar qué tan
rápido un sistema o
sub-sistema trabaja
bajo una carga
particular de trabajo.
Puede servir para
validar y verificar otros
atributos relacionados
con la calidad del
sistema...
35. Pruebas de Recorrido
Es una forma de reseña
entre colegas en la que un
diseñador ó programador
guía a los miembros del
equipo de desarrollo y
terceros interesados a
través de un producto de
software, y los participantes
hacen preguntas y
comentarios sobre errores
posibles, violación de
estándares de desarrollo y
otros problemas.
36. Pruebas de Mutación
Métodos que
involucran la
modificación del
código fuente de un
programa de manera
mínima.
37. Pruebas de Mutación
Métodos que
involucran la
modificación del
código fuente de un
programa de manera
mínima.
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