Facultad de Ingeniería y Arquitectura
Práctica de Especialidad II
Metodologías de Pruebas de Software
Grupo 03
Gema System
Catedrático: Lic. Mauricio Quevedo
Presentado Por:
Fátima Haydeé Hernández Brito Tanya Angélica Nóchez Pérdomo
Mónica Beatriz Palacios Torres Donnina Beatriz Paz Rivera
1
Introducción
La prueba de software es un conjunto de herramientas, técnicas y métodos que determinan la calidad de un programa, así como también la mejor publicidad que una empresa dedicada a la producción de software pueda tener. Las técnicas para encontrar problemas en un programa son extensamente variadas y van desde el uso del ingenio por parte del personal de prueba hasta herramientas automatizadas que ayudan a aliviar el peso y el costo de tiempo de esta actividad. Pero de nada serviría conocer todas las técnicas de prueba de software, si un programa carece de documentación, el código es confuso o no se han seguido pasos para la planificación y desarrollo del software, ya que sería como buscar una aguja en un pajar.
2
Pruebas de Software
Las pruebas de software, en inglés testing son los procesos que permiten verificar y revelar un
funcionamiento de calidad en las aplicaciones informáticas. Son utilizadas para identificar posibles fallos de implementación, calidad o usabilidad de un programa de ordenador o videojuego. Básicamente es una fase en el desarrollo de software consiste en probar las aplicaciones construidas.
Las pruebas de software se integran en las diferentes fases del ciclo del software dentro de la Ingeniería de software. Así se ejecuta un programa y mediante técnicas experimentales se trata de descubrir que errores tiene.
Para determinar el nivel de calidad se deben efectuar unas medidas o pruebas que permitan comprobar el grado de cumplimiento respecto a las especificaciones iniciales del sistema. Hay muchos planteamientos a la hora de abordar el proceso de pruebas de software, pero para verificar productos complejos de forma efectiva se requiere de un proceso de investigación más que seguir un procedimiento al pie de la letra.
¿Qué es el control de calidad del software?
Conceptos como estabilidad, escalabilidad, eficiencia y seguridad se relacionan a la calidad de un producto bien desarrollado. El control de calidad del software incluye desde el monitoreo de desarrollo de procesos haciendo respetar los estándares y procedimientos concordados, asegurándose un buen seguimiento de programa y la detección y corrección de errores. El control de calidad del software está orientado a la prevención.
En general, los informáticos distinguen entre errores de programación o bugs y defectos de forma. En un defecto de forma, el programa no realiza lo que el usuario espera. Por el contrario, un error de programación puede describirse como un fallo en la semántica de un programa de ordenador. Éste podría presentarse, o no, como un defecto de forma si se llegan a dar ciertas condiciones de cálculo.
Una práctica común es que el proceso de pruebas de un programa sea realizado por un grupo independiente de testers antes de sacarlo al mercado y al finalizar su desarrollo. Una práctica que viene siendo muy popular es distribuir de forma gratuita una versión no final del producto para que sean los propios consumidores los que la prueben, acción realizada sobre todo en la industria de juegos. En ambos casos, a la versión del producto de pruebas y que es anterior a la versión final o master se denomina beta y a dicha fase de pruebas, beta testing.
Puede además existir una versión anterior en el proceso de desarrollo llamada alpha, en la que el programa, aunque incompleto, dispone de funcionalidad básica y puede ser testeado. Finalmente y antes de salir al mercado, es cada vez más habitual que se realice una fase de
Release To Market testing (RTM), dónde se comprueba cada funcionalidad del programa
3
Otra práctica que se sigue, consiste en realizar pruebas desde el mismo momento en que empieza el desarrollo y se continúa hasta que finaliza.
El proceso de prueba 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. El conocimiento que debe manejar un ingeniero de prueba es muchas veces superior al del desarrollador de software.
Tipos de pruebas
Pruebas unitarias
En programación, una prueba unitaria es una forma de probar el correcto funcionamiento de un módulo de código. Esto sirve para asegurar que cada uno de los módulos funcione correctamente por separado. Luego, con las pruebas de integración, se podrá asegurar el correcto funcionamiento del sistema o subsistema en cuestión.
La idea es escribir casos de prueba para cada función no trivial o método en el módulo de forma que cada caso sea independiente del resto.
Características
Para que una prueba unitaria sea buena se deben cumplir los siguientes requisitos:
Automatizable: no debería requerirse una intervención manual. Esto es especialmente útil para integración continúa.
Completas: deben cubrir la mayor cantidad de código.
Repetibles o Reutilizables: no se deben crear pruebas que sólo puedan ser ejecutadas una sola vez. También debe ser útil para la fase de integración continua.
Independientes: la ejecución de una prueba no debe afectar a la ejecución de otra. Profesionales: las pruebas deben ser consideradas igual que el código, con la misma
profesionalidad, documentación, etc.
Aunque 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.
Ventajas
El objetivo de las pruebas unitarias es aislar cada parte del programa y mostrar que las partes individuales son correctas. Proporcionan un contrato escrito que el trozo de código debe satisfacer. Estas pruebas aisladas proporcionan cinco ventajas básicas:
4
sobre los cambios y así asegurarse de que los nuevos cambios no han introducido errores.
2. Simplifica la integración: permiten llegar a la fase de integración con un grado alto de seguridad de que el código está funcionando correctamente. De esta manera se facilitan las pruebas de integración.
3. Documenta el código: las propias pruebas son documentación del código puesto que ahí se puede ver cómo utilizarlo.
4. Separación de la interfaz y la implementación: dado que la única interacción entre los casos de prueba y las unidades bajo prueba son las interfaces de estas últimas, se puede cambiar cualquiera de los dos sin afectar al otro, a veces usando objetos mock (mock object) para simular el comportamiento de objetos complejos.
5. Los errores están más acotados y son más fáciles de localizar: dado que tenemos pruebas unitarias que pueden desenmascararlos.
Limitaciones
Es importante darse cuenta de que las pruebas unitarias no descubrirán todos los errores del código. Por definición, sólo prueban las unidades por sí solas. Por lo tanto, no descubrirán errores de integración, problemas de rendimiento y otros problemas que afectan a todo el sistema en su conjunto. Además, puede no ser trivial anticipar todos los casos especiales de entradas que puede recibir en realidad la unidad de programa bajo estudio. Las pruebas unitarias sólo son efectivas si se usan en conjunto con otras pruebas de software.
Pruebas funcionales
Una prueba funcional es una prueba basada en la ejecución, revisión y retroalimentación de
las funcionalidades previamente diseñadas para el software. Las pruebas funcionales se hacen mediante el diseño de modelos de prueba que buscan evaluar cada una de las opciones con las que cuenta el paquete informático.
Pruebas de integración
Pruebas integrales o pruebas de integración son aquellas que se realizan en el ámbito del
desarrollo de software 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 hecho en conjunto, de una sola vez. Es decir, consiste en realizar pruebas para verificar que un gran conjunto de partes de software funcionan juntos.
5
Pruebas de validación
Las pruebas de validación en la ingeniería de software son el proceso de revisión que el
sistema de software producido cumple con las especificaciones y que cumple su cometido. 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. Se 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?
Enfoques a la verificación
Dinámica, también conocida como ensayos o experimentación. Estática, también conocida como análisis.
Tipos
Pruebas de aceptación: desarrolladas por el cliente.
Pruebas alfa: realizadas por el usuario con el desarrollador como observador en un entorno controlado (simulación de un entorno de producción).
Pruebas beta: realizadas por el usuario en su entorno de trabajo y sin observadores.
Características
Comprobar que se satisfacen los requisitos:
Se usan la mismas técnicas, pero con otro objetivo.
No hay programas de prueba, sino sólo el código final de la aplicación.
Se prueba el programa completo.
Uno o varios casos de prueba por cada requisito o caso de uso especificado. Se prueba también rendimiento, capacidad, etc. (y no sólo resultados correctos). Pruebas alfa (desarrolladores) y beta (usuarios).
Caja blanca (sistemas)
En programación, se denomina cajas blancas a un tipo de pruebas de software que se realiza sobre las funciones internas de un módulo. Así como las pruebas de caja negra ejercitan los requisitos funcionales desde el exterior del módulo, las de caja blanca están dirigidas a las funciones internas. Entre las técnicas usadas se encuentran; la cobertura de caminos (pruebas que hacen que se recorran todos los posibles caminos de ejecución), pruebas sobre las
6
comprobación de bucles (se verifican los bucles para 0, 1 y n iteraciones, y luego para las
iteraciones máximas, máximas menos uno y más uno).
Las pruebas de caja blanca se llevan a cabo en primer lugar, sobre un módulo concreto, para luego realizar las de caja negra sobre varios subsistemas (integración).
En los sistemas orientados a objetos, las pruebas de caja blanca pueden aplicarse a los métodos de la clase, pero según varias opiniones, ese esfuerzo debería dedicarse a otro tipo de pruebas más especializadas (un argumento podría ser que los métodos de una clase suelen ser menos complejos que los de una función de programación estructurada).
Este concepto también es utilizado de manera análoga en la teoría general de sistemas.
Prueba de sistema
Es una prueba de caja negra incluyendo todos los componentes del sistema desde el hardware a la documentación.
Prueba de fin a fin
Es similar a la prueba de sistema pero esta involucra la interacción con otros hardwares, bases de datos y redes.
Caja negra (sistemas)
En teoría de sistemas y física, se denomina caja negra a aquel elemento que 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. En otras palabras, de una caja negra nos interesará su forma de interactuar con el medio que le rodea, 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.
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.
Caja negra y Programación modular
7
cada miembro va a encargarse de implementar una parte (un módulo) del programa global; el implementador de un módulo concreto deberá conocer como es la comunicación con los otros módulos (la interfaz), pero no necesitará conocer cómo trabajan esos otros módulos internamente; en otras palabras, para el desarrollador de un módulo, idealmente, el resto de módulos serán cajas negras.
Pruebas de Software
En pruebas de software, conociendo una función específica para la que fue diseñado el producto, se pueden diseñar pruebas que demuestren que dicha función está bien realizada. Dichas pruebas son llevadas a cabo sobre la interfaz del software, es decir, de la función, actuando sobre ella como una caja negra, proporcionando unas entradas y estudiando las salidas para ver si son o no las esperadas.
Pruebas de regresión
Se denominan pruebas de regresión a cualquier tipo de pruebas de software que 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 requerido cambio no eran propensas a este tipo de error. Esto implica que el error tratado se reproduce como consecuencia inesperada del citado cambio en el programa.
Este tipo de cambio puede ser debido a prácticas no adecuadas de control de versiones, falta de consideración acerca del ámbito o contexto de producción final y extensibilidad del error que fue corregido (fragilidad de la corrección), o simplemente una consecuencia del rediseño de la aplicación.
Por lo tanto, en la mayoría de las situaciones del desarrollo de software se considera una buena práctica que cuando se localiza y corrige un bug, se grabe una prueba que exponga el bug y se vuelvan a probar regularmente después de los cambios subsiguientes que experimente el programa.
Existen herramientas de software que permiten detectar este tipo de errores de manera parcial o totalmente automatizada, la práctica habitual en programación extrema es que este tipo de pruebas se ejecuten en cada uno de los pasos del ciclo de vida del desarrollo del software.
Tipos de regresión
Clasificación de ámbito
Local: los cambios introducen nuevos errores.
8
Remota: los cambios vinculan algunas partes del programa (módulo) e introducen errores en ella.
Clasificación temporal
Nueva característica: los cambios realizados con respecto a nuevas funcionalidades en la versión introducen errores en otras novedades en la misma versión del software.
Característica preexistente: los cambios realizados con respecto a nuevas funcionalidades introducen errores en funcionalidad existente de previas versiones.
¿Cómo mitigar los riesgos?
Repetición completa y habitual de la batería de pruebas, manual o mediante automatización.
Repetición parcial basada en trazabilidad y análisis de riesgos. Pruebas de cliente o usuario:
Beta: distribución a clientes potenciales y actuales de versiones beta. Pilot: distribución a un subconjunto bien definido y localizado.
Paralela: simultaneando uso de ambos sistemas. Usar releases mayores. Probar nuevas funciones a menudo cubre las funciones existentes. Cuantas más nuevas características haya en un release, habrá mayor nivel de pruebas de regresión "accidental".
Parches de emergencia: estos parches se publican inmediatamente y serán incluidos en releases de mantenimiento futuras.
Usos
Las Pruebas de Regresión pueden usarse no solo para probar la corrección de un programa, sino a menudo usarse para rastrear la calidad de su salida. Por ejemplo en el diseño de un compilador, las pruebas de regresión deben rastrear el tamaño del código, tiempo de simulación, y el tiempo de compilación de las suites de prueba. Cuando quiera que aparezca un nuevo build, el proceso de regresión aparece.
Pruebas de sanidad
9
Pruebas de aceptación
Es la prueba final basada en las especificaciones del usuario o basada en el uso del programa por el usuario final luego de un periodo de tiempo.
Pruebas de carga
Está basada en las aplicaciones bajo cargas pesadas, generalmente usadas en sitios web y en servidores con gran cantidad de datos donde se determina en cuales puntos existen degradaciones del sistema.
Prueba de estrés
Es una prueba de carga y perfomance basada en la funcionalidad del sistema bajo cargas pesadas, un gran número de repeticiones, manejo de grandes datos y demasiadas preguntas a bases de datos grandes.
Prueba de perfomance
Es una de las pruebas finales y sirve para definir los requerimientos y la calidad del software, en base a las pruebas de carga y estrés. Incluye entrevistas con el usuario y programador.
Prueba de seguridad
