1. Introducción a las Pruebas
de Software
- Fundamentos de las Pruebas de Software
- Metodologías de desarrollo y las Pruebas
- Tipos de Pruebas de Software
Material académico preparado por:
Ph.D Marta Silvia Tabares B.
Fecha última actualización 26-Sep-2011
3. Fundamentos de las Pruebas de
Software
El software como producto puede tener
defectos o fallos, desde el momento de
concebirlo y modelarlo, durante su
desarrollo y después de la puesta en
producción de la aplicación software
Las pruebas del software corresponde
a la necesidad de garantizar un
producto de calidad
3
Material académico preparado por Marta Silvia Tabares B. UdeM
4. Fundamentos de las Pruebas de
Software
• Glosario
– Prueba: proceso de evaluar un producto particular
para determinar si un producto tiene defectos.
– Pruebas de Software: es un proceso de evaluar
un sistema ya sea manual o automático y verificar
que este satisface los requisitos o identifica
diferencias entre lo esperados y los resultados
actuales.
4
Material académico preparado por Marta Silvia Tabares B. UdeM
5. Fundamentos de las Pruebas de
Software
• Por qué es importante hacer pruebas de
software:
– Sistema libre de errores
– Eficiencia de la aplicación
– Aseguramiento de la calidad del software (p.ej.: la
norma 9126)
– Evaluación de la flexibilidad del software
construido
5
Material académico preparado por Marta Silvia Tabares B. UdeM
6. Fundamentos de las Pruebas de
Software
• Por qué es importante hacer pruebas de
software:
• Misiones fallidas
• Impacto inesperado en la
ejecución operacional
• Falta de confiabilidad en
casos de que no se
ejecute acertadamente
6
Material académico preparado por Marta Silvia Tabares B. UdeM
7. Fundamentos de las Pruebas de
Software
Objetivos de las pruebas:
1. La prueba es el proceso de ejecución de un programa con la intención
de descubrir un error.
2. Un buen caso de prueba es aquel que tiene una alta probabilidad de
descubrir un error no encontrado hasta entonces.
3. Una prueba tiene éxito si descubre un error no detectado hasta
entonces.
• No sólo se prueba el código, también la documentación , los manuales, las
ayudas, las interfaces de todo tipo
7
Material académico preparado por Marta Silvia Tabares B. UdeM
8. Fundamentos de las Pruebas de
Software
• Índice de la fiabilidad del software:
se comporta de acuerdo a las especificaciones y requisitos de
rendimiento.
“La prueba no puede asegurar la ausencia de defectos: sólo puede demostrar que
existen defectos en el software”.
• No es una actividad secundaria:
– 30-40% del esfuerzo de desarrollo
– En aplicaciones críticas (p.ej. control de vuelo, reactores nucleares),
¡de 3 a 5 veces más que el resto de pasos juntos de la ingeniería del
software!
– El costo aproximado de los errores del software (bugs) para la economía
americana es el equivalente al 0,6% de su PIB, unos 60.000 millones de
dólares
⇒ ¡Evitar bugs puede ser un gran negocio!
8
Material académico preparado por Marta Silvia Tabares B. UdeM
9. Fundamentos de las Pruebas de
Software
Un software fácil de probar tiene las siguientes
características:
Operatividad
Observatividad
Controlabilidad
Capacidad de descomposición
Simplicidad
Estabilidad
Facilidad de comprensión.
9
Material académico preparado por Marta Silvia Tabares B. UdeM
10. Fundamentos de las Pruebas de
Software
• A todas las pruebas se les debería poder hacer un seguimiento hasta los requisitos
de los clientes (trazabilidad).
• Las pruebas deberían planificarse antes de que empiecen.
• El principio de Pareto es aplicable a la prueba del software (“donde hay un defecto,
hay otros”).
• Las pruebas deberían empezar por “lo pequeño” y progresar hacia “lo grande”.
• No son posibles las pruebas exhaustivas.
• Para ser más efectivas, las pruebas deberían ser conducidas por un equipo
independiente.
• Se deben evitar los casos de prueba no documentados ni diseñados con cuidado.
• No deben realizarse planes de prueba suponiendo que prácticamente no hay
defectos en los programas y, por tanto, dedicando pocos recursos a las pruebas.
10
Material académico preparado por Marta Silvia Tabares B. UdeM
11. Fundamentos de las Pruebas de
Software
Verificación y validación
• Verificación
“¿Estamos construyendo el producto
corréctamente?”.
• El software debería ajustarse a su especificación
• Validación
“¿estamos construyendo el producto correcto?”.
• El software debería hacer lo que el cliente realmente
reclama.
11
Material académico preparado por Marta Silvia Tabares B. UdeM
12. Fundamentos de las Pruebas de
Software
Verificación y validación
• La V & V debe aplicarse en cada etapa del
software.
• Tiene dos objetivos principales
– El descubrimiento de defectos en el sistema;
– La evaluacíón de si el sistema es útil y utilizable en
una situación operacional o no.
12
Material académico preparado por Marta Silvia Tabares B. UdeM
13. Fundamentos de las Pruebas de
Software
Normas de Calidad asociadas a las pruebas de software
• Desarrollo del software - Validación y Verificación del
software
– Norma ISO/IEC 12207
– Norma ISO/IEC 17025
(http://www.lysconsultores.com/Descargar/NT006.pdf)
• Mantenimiento del software
– Norma ISO 14764
• Software Testing
– Norma ISO/IEC 29119
(http://softwaretestingstandard.org/)
13
Material académico preparado por Marta Silvia Tabares B. UdeM
14. Fundamentos de las Pruebas de
Software
Norma estándar para las pruebas de software
29119 – Proceso de Pruebas
Fuente: http://softwaretestingstandard.org/
14
Material académico preparado por Marta Silvia Tabares B. UdeM
15. Fundamentos de las Pruebas de
Software
Norma estándar para las pruebas de software
29119 – Proceso de Pruebas
Fuente: http://softwaretestingstandard.org/
15
Material académico preparado por Marta Silvia Tabares B. UdeM
16. Fundamentos de las Pruebas de
Software
Norma estándar para las pruebas de software 29119 – Proceso de Pruebas
Fuente: http://softwaretestingstandard.org/
16
Material académico preparado por Marta Silvia Tabares B. UdeM
17. Fundamentos de las Pruebas de
Software
Norma estándar para las pruebas de software 29119 – Proceso de Pruebas
Fuente: http://softwaretestingstandard.org/
17
Material académico preparado por Marta Silvia Tabares B. UdeM
18. Fundamentos de las Pruebas de
Software
Norma estándar para las pruebas de software 29119 – Proceso de Pruebas
Fuente: http://softwaretestingstandard.org/
18
Material académico preparado por Marta Silvia Tabares B. UdeM
19. LA TRAZABILIDAD DE REQUISITOS –
PRÁCTICA VITAL PARA LAS PRUEBAS DE
SOFTWARE
Material académico preparado por Marta Silvia Tabares B. UdeM
20. La Trazabilidad del Software
• Es la habilidad de dejar huella de
los movimientos y procesos por
los que pasa un determinado pr
oducto principalmente destinado
al consumo humano.
• Procedimientos preestablecidos y
autosuficientes que permiten
conocer el histórico, la ubicación y
la trayectoria de un producto o lote
de productos a lo largo de la cadena
de suministros en un momento
dado, a través de unas herramientas
determinadas
20
Material académico preparado por Marta Silvia Tabares B. UdeM
21. Naturaleza de la Trazabilidad del
Software
El producto esta siendo caracterizado de manera iterativa
e incremental lo cual hace más complejo seguir su traza
21
Material académico preparado por Marta Silvia Tabares B. UdeM
22. Naturaleza de la Trazabilidad del
Software
Trazabilidad (Rastreabilidad)
Es el grado en el cual una relación puede ser establecida entre dos o
más productos del proceso de desarrollo, especialmente productos que
tienen relaciones de predecesor-sucesor o maestro-subordinado entre
uno y otro” [IEEE-STD-610]
22
Material académico preparado por Marta Silvia Tabares B. UdeM
23. Naturaleza de la Trazabilidad del
Software
El esfuerzo invertido en mantener las relaciones de traza, obtiene su retorno cuando se
van a realizar modificaciones en el software
Modelos de
Trazabilidad
Alteración del
software y pruebas
sobre todos los
elementos
impactados
23
Material académico preparado por Marta Silvia Tabares B. UdeM
24. Naturaleza de la Trazabilidad del
Software
Contexto del negocio
Modelos del
Product producto V1
o
Instalad Todo es
o Producto en Operación
consistente y
Artefactos
ejecutables
trazado
Escenario del producto V1
1
Cambios en Solicitud Ingeniero de Desarrollo
Contexto del negocio de del Software
condiciones Solicitud
cambio
de negocio de
Solicitud
cambio
de Intervención en
Producto en Operación cambio ambiente de
Escenario 2
desarrollo
Artefactos
Artefactos
ejecutables
ejecutables
Artefactos del producto V4
Modelos del del producto V3
ejecutables
producto V1 del producto V2
Posible pérdida de
consistencia de los modelos
y productos
24
Material académico preparado por Marta Silvia Tabares B. UdeM
25. Naturaleza de la Trazabilidad del
Software
2, 9 Definir /
Modificar
Repositorio de
Modelos y Modelos
1. Definir Traza Y Matriz de
Requisitos Chec trazabilidad
7.
k-out (Ej: Enterprise
4,
Analiz Architect)
Ingenier ar 11Chec
o k-in
Desarro Impac Check-
Cliente del Report
llador 3, 10 to in++
producto ar
Construir/
6. Colocar seguim
Modificar 5,
solicitud iento Servidor de
12Chec Configuracio
de cambio Entorno de k-in nes
Desarrollo Check- (Ej: CVS,
6.
(Ej: Eclipse, Subversión)
Reportar in++
8. Establecer NetBeans)
No Acuerdo
Conformi
dades Manejador Área
Comercial /
Área de tickets Gerente
SQA (Ej: Mantis) Proyecto
25
Material académico preparado por Marta Silvia Tabares B. UdeM
27. Metodologías de desarrollo y las
Pruebas
• Prueba para modelos en espiral
27
Material académico preparado por Marta Silvia Tabares B. UdeM
28. Metodologías de desarrollo y las
Pruebas
28
Material académico preparado por Marta Silvia Tabares B. UdeM
29. Metodologías de desarrollo y las
Pruebas
• Pruebas para modelos procedimentales
Requisitos Pruebas de
alto nivel
Diseño Prueba de
Integración
Codificación
Prueba de
unidad
Dirección del la
prueba
Etapas de prueba del SW
29
Material académico preparado por Marta Silvia Tabares B. UdeM
30. Metodologías de desarrollo y las
Pruebas
• Pruebas desde el Modelo V
Especificación Especificación Diseño
Diseño del sistema
De requisitos Del sistema detallado
Plan de pruebas Plan de pruebas de Código y
Plan de pruebas
de integración del integración prueba de los
De aceptación
sistema De los subsistemas módulos y
unidades
Prueba de Prueba de integración
Prueba de
Servicio integración del De los subsistemas
aceptación
sistema
30
Material académico preparado por Marta Silvia Tabares B. UdeM
31. TIPOS DE PRUEBAS DEL SOFTWARE
Material académico preparado por Marta Silvia Tabares B. UdeM
32. Tipos de Pruebas
Pruebas de Software
Estáticas Dinámicas
Pruebas Caja Blanca Pruebas Caja Negra
Pruebas en etapas tempranas del (pruebas estructurales) (pruebas funcionales)
desarrollo del Software. Pruebas en tiempo de
Pruebas en tiempo de ejecución. Se hacen
Buscan defectos sin ejecutar código, ejecución. Estas pruebas pruebas que demuestren
es decir se pueden hacer desde los aseguran que todas las que cada función
requisitos y sobre los modelos de piezas encajan y que el la identificada es operativa
análisis y diseño estructuración del código que de acuerdo a los
ejecuta una función interno resultados esperados.
También se pueden hacer una vez corresponde a la operación
se escriba el código, pero se hacen interna especificada. P. ej.: Pruebas sobre la
fuera de ejecución interfaz del software
32
Material académico preparado por Marta Silvia Tabares B. UdeM
33. Tipos de Pruebas
33
Material académico preparado por Marta Silvia Tabares B. UdeM
34. Tipos de Pruebas
PRUEBA DEL SISTEMA
Cuando se hacen pruebas en grupo o un grupo de analistas entrega un conjunto de
artefactos de software a los testers, un problema típico es la «delegación de
culpabilidad»,.
Esto ocurre cuando se descubre un error y cada uno de los creadores de cada
elemento del sistema echa la culpa del problema a los otros. Se debe anticipar a los
posibles problemas y:
1. diseñar caminos de manejo de errores que prueben toda la información
procedente de los elementos del sistema;
2. llevar a cabo una serie de pruebas que simulen la presencia de datos en mal
estado o de otros posibles errores en la interfaz del software;
3. registrar los resultados de las pruebas como «evidencia» en el caso de que se le
señale con el dedo;
4. participar en la planificación y el diseño de pruebas del sistema para
asegurarse de que el software se prueba de forma adecuada.
34
Material académico preparado por Marta Silvia Tabares B. UdeM
35. Tipos de Pruebas
• Pruebas de defectos
– Pruebas diseñadas para descubrir defectos en el sistema.
– Una prueba de defectos exitosa es aquella que revela la presencia de
defectos en un sistema.
• Pruebas de validación
– Previsto para mostrar que el software cumple sus requerimientos.
– Una prueba con éxito es aquella que muestra que un requerimiento se
ha implementado correctamente.
Vínculos sugeridos para estudio complementario a este capítulo:
- http://www.sistedes.es/TJISBD/Vol-1/No-4/articles/pris-07-raja-ctps.pdf
35
Material académico preparado por Marta Silvia Tabares B. UdeM
36. Tipos de Pruebas
CRITERIOS DE LA PRUEBA DE
VALIDACIÓN
PRUEBA DE
VALIDACIÓN La prueba alfa se lleva a cabo, por un cliente, en el
lugar de desarrollo. Se usa el software de forma
natural con el desarrollador como observador del
Un software está validado usuario y registrando los errores y los problemas de
cuando se consigue que uso. Las pruebas alfa se llevan a cabo en un entorno
controlado.
este funcione de acuerdo
con las expectativas La prueba beta se lleva a cabo por los usuarios finales
del software en los lugares de trabajo de los clientes. A
razonables del cliente. diferencia de la prueba alfa, el desarrollador no está
presente normalmente. Así, la prueba beta es una
aplicación «en vivo» del software en un entorno que
no puede ser controlado por el desarrollador.
36
Material académico preparado por Marta Silvia Tabares B. UdeM
37. Tipos de Pruebas
PRUEBA DE ACEPTACIÓN
El objetivo de las pruebas de aceptación es validar que un sistema cumple
con el funcionamiento esperado y permitir al usuario de dicho sistema que
determine su aceptación, desde el punto de vista de su funcionalidad y
rendimiento.
Las pruebas de aceptación son definidas por el usuario del sistema y
preparadas por el equipo de desarrollo, aunque la ejecución y aprobación
final corresponden al usuario.
La validación del sistema se consigue mediante la realización de pruebas de
caja negra que demuestran la conformidad con los requisitos y que se
recogen en el plan de pruebas, el cual define las verificaciones a realizar y
los casos de prueba asociados.
37
Material académico preparado por Marta Silvia Tabares B. UdeM
38. Tipos de Pruebas
PRUEBA DE UNIDAD
La prueba de unidad centra el proceso de verificación en la
menor unidad del diseño del software(Módulo). Aquí se
prueban los caminos de control importantes, con el fin de
descubrir errores dentro del ámbito de un módulo.
Estas pruebas se pueden hacer desde etapas tempranas de
desarrollo como pruebas estáticas.
38
Material académico preparado por Marta Silvia Tabares B. UdeM
39. Tipos de Pruebas
ERRORES SON LOS MÁS COMUNES DURANTE
LA PRUEBA DE UNIDAD
1. Procedencia aritmética incorrecta mal aplicada
2. Operaciones de modo mezcladas.
3. Inicializaciones incorrectas.
4. Falta de precisión.
5. Representación incorrecta de una expresión.
39
Material académico preparado por Marta Silvia Tabares B. UdeM
40. Tipos de Pruebas
• Pruebas de Unidad
• Ver video en:
http://channel9.msdn.com/blogs/channel9spain
/pruebas-unitarias-unit-testing-con-visual-studio
40
Material académico preparado por Marta Silvia Tabares B. UdeM
41. Tipos de Pruebas
PRUEBA DE INTEGRACIÓN
“Si todos funcionan bien
¿Por qué dudar de que no funcionen todos juntos?”
«Es una técnica sistemática para construir la estructura del
programa mientras que al mismo tiempo, se llevan a cabo
pruebas para detectar errores asociados con la interacción».
Un poco de métodos ágiles con integración: http://www.youtube.com/watch?v=UT_s1aZCfAw
41
Material académico preparado por Marta Silvia Tabares B. UdeM
42. Tipos de Pruebas
TIPOS DE PRUEBAS INTEGRACIÓN
No incremental: Al inicio se combinan todos los módulos
por anticipado, se prueba todo el producto.
Incremental: En la segunda prueba se hace de forma
incremental, es decirse desarrollan módulos pequeños y
funcionales que hacen que los errores sean más fácil de aislar
y corregir.
42
Material académico preparado por Marta Silvia Tabares B. UdeM
43. Tipos de Pruebas
Formas de hacer la Integración
1. Descendente
«Es una estrategia de integración incremental a la construcción de
la estructura de programas, en cual se integran los módulos
moviéndose en dirección hacia abajo por la jerarquía de control
comenzando con el módulo principal».
«Los módulos subordinados al módulo de control principal se
incorpora en la estructura, de forma primero-en-profundidad, ó
primero-en-anchura».
43
Material académico preparado por Marta Silvia Tabares B. UdeM
44. Tipos de Pruebas
Ilustración: Integración descendente
M1
M2 M3 M4
M5 M6 M7
M8
44
Material académico preparado por Marta Silvia Tabares B. UdeM
45. Tipos de Pruebas
La desventaja de la integración descendente es la
necesidad de resguardos. La principal desventaja de la
integración ascendente es que el “el programa
como entidad no existe hasta que se haya añadido el
ultimo módulo”.
La selección de una estrategia de integración
depende de las características del software y, a veces
de la planificación del proyecto, en algunos de los
casos se puede usar un enfoque
combinado(denominado pruebas Sándwich).
45
Material académico preparado por Marta Silvia Tabares B. UdeM
46. Tipos de Pruebas
Formas de hacer la Integración
2. Ascendente
«Es un modelo de integración no incremental, en donde la
construcción del diseño empieza de los módulos atómicos (es
decir, módulos de los niveles mas bajos de la estructura del
programa). Dado que los módulos se integran de abajo hacia
arriba, el proceso requerido de los módulos subordinados
siempre está disponible y elimina la necesidad de
resguardos».
46
Material académico preparado por Marta Silvia Tabares B. UdeM
47. Tipos de Pruebas
PRUEBA DE REGRESIÓN
Cada vez que se añade un nuevo modulo como parte de una
prueba de integración el software cambia.
La prueba de regresión es volver a ejecutar un
subconjunto de pruebas que se han llevado a cabo
anteriormente para asegurarse de que los cambios no han
propagado efectos colaterales no deseados.
47
Material académico preparado por Marta Silvia Tabares B. UdeM
48. Tipos de Pruebas
PRUEBA DE HUMO
La prueba de humo es un método de prueba de integración que
es comúnmente utilizada cuando se ha desarrollado un
software “empaquetado”. Es diseñado como una mecanismo
para proyectos críticos por tiempos, permitiendo que el
equipo de software valore su proyecto sobre una base sólida.
48
Material académico preparado por Marta Silvia Tabares B. UdeM
49. Tipos de Pruebas
PRUEBA DE RECUPERACIÓN
La prueba de recuperación es una prueba del sistema que la hacen expertos
en infraestructura. Esta fuerza el fallo del software de muchas formas y
verifica que la recuperación se lleva a cabo apropiadamente.
Cuando la recuperación es automática hay que evaluar la corrección de la
inicialización, de los mecanismos de recuperación del estado del sistema, de
la recuperación de datos y del proceso de re-arranque.
Cuando la recuperación es manual hay que evaluar los tiempos medios de
reparación (TMR) para determinar si están dentro de unos límites
aceptables.
49
Material académico preparado por Marta Silvia Tabares B. UdeM
50. Casos de Prueba
• Qué es un CASO DE PRUEBA DE SOFTWARE?
– Conjunto de condiciones o variables bajo las
cuáles el analista determinará si el requisito de
una aplicación es parcial o completamente
satisfactorio (wikipedia).
– Plantilla Recomendada:
http://readyset.tigris.org/nonav/es/templates/test-
case-format.html
50
Material académico preparado por Marta Silvia Tabares B. UdeM
52. Estrategias de Pruebas
• Ton Gilb, plantea que se deban abordar los siguientes
puntos si se desea implementar con éxito una
estrategia de prueba del SW:
– Especificar los requisitos del producto de manera
cuantificable mucho antes que comiencen las pruebas.
– Establecer los objetivos de la prueba de manera explicita.
– Comprender que usuarios van a manejar el SW y
desarrollar un perfil para cada categoría de usuario.
Vínculos complementario para el estudio de este tema:
- http://www.willydev.net/descargas/oguzman-diseno_pruebas.pdf
52
Material académico preparado por Marta Silvia Tabares B. UdeM
53. Estrategias de Pruebas
– Desarrollar un plan de prueba que haga hincapié en la
prueba de ciclo rápido.
– Construir un SW robusto diseñado para probarse así
mismo.
– Usar revisiones técnicas formales y efectivas como
filtro antes de la prueba.
– Llevar acabo revisiones técnicas formales para evaluar
la estrategia de prueba y los propios casos de prueba.
– Desarrollar un enfoque de manera continua al proceso
de prueba. Debería medirse la estrategia de prueba.
Vínculo complementarios para estudio de este tema:
- http://msdn.microsoft.com/es-es/library/dd286594.aspx
53
Material académico preparado por Marta Silvia Tabares B. UdeM
54. Estructura de un Plan de Pruebas
• Proceso de pruebas
• Trazabilidad de requerimientos.
• Elementos probados.
• Calendario de pruebas.
• Procedimientos de registro de las pruebas.
• Requerimientos hardware y software.
• Restricciones.
Vínculo complementarios para estudio de este tema:
- http://catarina.udlap.mx/u_dl_a/tales/documentos/lis/urcid_p_p/capitulo5.pdf
54
Material académico preparado por Marta Silvia Tabares B. UdeM
55. Estructura de un Plan de Pruebas
Un plan de pruebas debe estar diseñado para
asegurar que se satisfacen todos los requisitos
funcionales especificados por el usuario
teniendo en cuenta también los requisitos no
funcionales relacionados con el rendimiento,
seguridad de acceso al sistema, a los datos y
procesos, así como a los distintos recursos del
sistema.
55
Material académico preparado por Marta Silvia Tabares B. UdeM
56. Algunas Herramientas Open Source
para Pruebas del Software
• JCRAWLER: http://www.youtube.com/watch?v=W-NkHNOxPRM
• WebInject: www.goldb.org
• LoadUI: http://www.loadui.org/About-loadUI/what-is-loadui.html
• http://www.opensourcetesting.org/
57. Sitios de consulta recomendados
• Además de los definidos en la bibliografía y en el transcurso
de la presentación, sugiero:
– http://www.softwareqatest.com/
– http://www.nickjenkins.net/prose/testingPrimer.pdf
– http://www.sparxsystems.com.ar/resources/testing.html
– http://sunnyday.mit.edu/16.355/oct20.pdf
– http://www.cs.helsinki.fi/u/paakki/software-testing-s05.html
– Pruebas de usabilidad:
http://www.eici.ucm.cl/Academicos/R_Villarroel/descargas/com
_h_m/EvaluacionInterfacesUsuario.pdf
– Listas de chequeo:
• http://www.usereffect.com/topic/25-point-website-usability-checklist
• http://www.testinggeek.com/performance-security-testing-checklist