UNIDAD 2.

PRUEBAS DE SOFTWARE

Pruebas y mantenimiento de sistemas de

software

Actividad 3. Niveles de pruebas de software

Facilitador(a): Emilia Valdez Silva

Alumno: Marco Antonio Osorio Pérez

Matricula: AL10507834

Grupo: DS-DPSS-1401C-001

10º Cuatrimestre
 UNIDAD 2. PRUEBAS DE SOFTWARE

Pruebas y mantenimiento de sistemas de

software

Comprender los conceptos fundamentales de cada nivel de pruebas para su

aplicación en un caso de estudio mediante la elaboración de un reporte.
PRUEBAS DE SOFTWARE
Es un proceso de pruebas formal, suelen confundirse con mucha facilidad, los
niveles de pruebas con los tipos de prueba, y a pesar de que se encuentren
íntimamente relacionadas, tiene connotaciones diferentes en el proceso. Para
entender un poco más, vamos a partir del hecho de que las pruebas pueden
ejecutarse en cualquier punto del proceso de desarrollo de software, y es aquí
donde los niveles de prueba nos permiten entender con claridad los diferentes
puntos o etapas en donde pueden ejecutarse ciertos tipos de prueba.
Pruebas Modulares
En programación, unas pruebas unitarias o modulares son 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 es útil para 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.
 UNIDAD 2. PRUEBAS DE SOFTWARE

Pruebas y mantenimiento de sistemas de

software

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:
1. Fomentan el cambio: Las pruebas unitarias facilitan que el programador cambie
el código para mejorar su estructura (lo que se ha dado en llamar refactorización),
puesto que permiten hacer pruebas sobre los cambios y así asegurarse de que los
nuevos cambios no han introducido errores.
2. Simplifica la integración: Puesto que 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 de Regresión
Sucede con demasiada frecuencia que cuando se entrega una evolución de
un software, ya sea en una iteración en un desarrollo iterativo incremental o en
un mantenimiento correctivo o evolutivo, se realiza testing exclusivamente sobre
las funcionalidades que se han desarrollado y no se comprueban otros segmentos
 UNIDAD 2. PRUEBAS DE SOFTWARE

Pruebas y mantenimiento de sistemas de

software

del programa que se han podido ver afectados por los cambios realizados en el
código.
En muchos casos son las prisas por cumplir plazos en el proyecto, en otros por la
necesidad de solucionar una urgencia y en otros tantos porque no se piensa que
determinados cambios en el código puedan provocar efectos colaterales en la
aplicación.
Las posibilidades de que se produzcan este tipo de problemas dependerán mucho
de la calidad de la codificación y de la sección del código que se esté tocando, ya
que no es lo mismo tocar una clase con un alto acoplamiento que otra.
Para reducir el riesgo de que aparezcan efectos colaterales, es conveniente la
realización de pruebas de regresión que se basan principalmente en realizar
testing sobre funcionalidades de la aplicación que presentan riesgo de haber sido
afectadas por los cambios. El esfuerzo necesario en realizar estas pruebas
dependerá del nivel de automatización de las mismas que se tenga hasta el
momento en el rango que va desde las pruebas unitarias hasta las funcionales.
Sobre las pruebas de regresión y en general sobre el hecho de que en la
programación no hay que dar nada por sentado, podemos recordar la
siguiente cita de Doug Linder: “Un buen programador es aquel que siempre mira a
ambos lados antes de cruzar una calle que tiene un único sentido”.

Estas se producen cuando se realizan cambios a un sistema y se ejecutan para

garantizar que la nueva versión del software ha conservado las características de
la versión antigua.

Determinar que las modificaciones no han causado fallas o efectos

adversos.
Determina que se cumple con los requerimientos
Modifica menores selección de pruebas
Construir paquetes de pruebas de regresión actualizarlas.
 UNIDAD 2. PRUEBAS DE SOFTWARE

Pruebas y mantenimiento de sistemas de

software

Pruebas de Integración
Este tipo de pruebas son ejecutadas por el equipo de desarrollo y consiste en la
comprobación de que elementos del software que interactuan entre sí, funcionan
de manera correcta.
Clasificación de las pruebas de integracion
Ejecutadas para exponer fallas en interfases y en la interacción entre
componentes.
Ejecutadas por los desarrolladores.
Tecnicas
 Big bang
 UNIDAD 2. PRUEBAS DE SOFTWARE

Pruebas y mantenimiento de sistemas de

software

 Top down
 Bottom up
 Middle-out
Clasificación de las pruebas
Funcionales:
 Requerimientos
No funcionales:
 Carga
 Estrés
 Usabilidad
 Volumen
 Documentación
 Seguridad
 Almacenamiento
 Instalación
 Recuperación
Pruebas de sistemas
Este tipo de pruebas deben ser ejecutadas idealmente por un equipo de pruebas
ajeno al equipo de desarrollo, una buena practica en este punto corresponde a la
tercerizacion de esta responsabilidad. La obligación de este equipo, consiste en la
ejecución de actividades de prueba en donde se debe verificar que la
funcionalidad total de un sistema fue implementada de acuerdo a los documentos
de especificación definidos en el proyecto. Los casos de prueba a diseñar en este
nivel de pruebas, deben cubrir los aspectos funcionales y no funcionales del
sistema. Para el diseño de los casos de prueba en este nivel, el equipo debe
utilizar como bases de prueba entregables talescomo: requerimientos iniciales,
casis de uso, historias de usuario, diseños, manuales tecnicos y de usuario final,
etc. Por ultimo, es importante que los tipos de pruebas ejecuntados en este nivel
se desplieguen en un ambiente de pruebas/ambiente de pre-producción cuya
insfraestructura y arquitectura sea similar al ambiente de producción, evitando en
todos los casos utilizar el ambiente real del cliente, debido principalmente, a que
 UNIDAD 2. PRUEBAS DE SOFTWARE

Pruebas y mantenimiento de sistemas de

software

pueda ocasionar fallos en los servidores, lo que ocasionaría indisponibilidad en

otros servicios alojados en este ambiente.

Conclusiones
Nunca un producto software se ha terminado de probar. Hay que establecer un
límite dependiendo de la trascendencia, costes, etc. del proyecto.
La superación de las pruebas no implica que no existan errores, sino que no se
han detectado.
Las pruebas del software no garantizan la calidad de éste: las pruebas
demuestran la calidad pero no la garantizan.

 
Referencias electrónicas:
http://pruebasdelsoftware.wordpress.com/2013/01/21/niveles-de-prueba-del-
software/
http://www.slideshare.net/GuillermoLemus/tipos-de-pruebas-de-software
http://www.slideshare.net/aracelij/pruebas-de-software
http://isg2.pbworks.com/w/page/7624280/Pruebas%20del%20Software