Introducción de pruebas de software

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

Bibliografía
Los conceptos utilizados en esta presentación fueron estudiados y tomados en su mayoría
de las siguientes referencias bibliográficas.
1. Camacho, E.; Cardeso, F.; Nuñez, G. ARQUITECTURAS DE SOFTWARE - GUÍA DE ESTUDIO. (Abril, 2004).
2. Glenford J. Myers.; Corey Sandler; Tom Badgett. The Art of Software Testing. Third Edition. Jonh Wiley & Sons.
2012.
3. Arlow, J., and Neustad, I. UML 2 and the Unified Process: Practical Object-Oriented Analysis and Design (2nd
Edition). Addison-Wesley Object Technology Series. 2005.
4. OMG-UML. Unified Modeling Language: Superstructure. Version 2.0, formal/05-07-04. 2005.
5. Jacobson, I., Booch, G., Rumbaugh, J. El Proceso Unificado de Desarrollo de Software. Addison Wesley. 2000.
6. Alan Dennis, Barbara Haley Wixom and David Tegarden. Systems Analysis and Design with UML Version 2.0 - An
Object Oriented Approach, Second Edition. John Wiley & Sons © 2005.
7. Simon Bennett, Stee McRobb, y Ray Farmer. Análisis y Diseño Orientado a Objetos del Sistema, Usando UML.
McGraw-Hill, 2006.
8. Bass, L., Clements, P., Kazman, R. Software Architecture in Practice Second Edition.
9. Pressman, R. Ingeniería del Software un Enfoque Práctico.
10. www.sei.cmu.edu.co
11. http://www.iso.org/iso/home.html
12. http://iso25000.com/index.php/iso-iec-9126.html
13. http://softwaretestingstandard.org/

2
Material académico preparado por Marta Silvia Tabares B. UdeM

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

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

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

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

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

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

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

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

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

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

Software
Normas de Calidad asociadas a las pruebas de software
• Desarrollo del software - Validación y Verificación del
software
– Norma ISO/IEC 12207
(http://www.lysconsultores.com/Descargar/NT006.pdf)

• Mantenimiento del software
– Norma ISO 14764

• Software Testing
(http://softwaretestingstandard.org/)

13

Software
Norma estándar para las pruebas de software
29119 – Proceso de Pruebas
Fuente: http://softwaretestingstandard.org/

14

Software
Norma estándar para las pruebas de software
29119 – Proceso de Pruebas

15

Software
Norma estándar para las pruebas de software 29119 – Proceso de Pruebas

16

Software

17

Software

18

LA TRAZABILIDAD DE REQUISITOS –
PRÁCTICA VITAL PARA LAS PRUEBAS DE
SOFTWARE

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

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

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

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

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

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

METODOLOGÍAS DE DESARROLLO Y
LAS PRUEBAS

Metodologías de desarrollo y las
Pruebas
• Prueba para modelos en espiral

27

Pruebas

28

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

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

TIPOS DE PRUEBAS DEL SOFTWARE


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

Tipos de Pruebas

33

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

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

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

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

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

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

Tipos de Pruebas
• Pruebas de Unidad

• Ver video en:
http://channel9.msdn.com/blogs/channel9spain
/pruebas-unitarias-unit-testing-con-visual-studio

40

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

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

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

Tipos de Pruebas

Ilustración: Integración descendente

M1

M2 M3 M4

M5 M6 M7

M8
44

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

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

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

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

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

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

http://msdn.microsoft.com/es-es/library/dd286594.aspx
ESTRATEGIAS DE PRUEBAS


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

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

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

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

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/

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

Introducción de pruebas de software

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à Introducción de pruebas de software

Similaire à Introducción de pruebas de software (20)

Plus de Marta Silvia Tabares

Plus de Marta Silvia Tabares (20)

Introducción de pruebas de software