Ingeniería de Software

Clase 10:
Estrategias de Pruebas

Hugo R. Cordero S.
Clase 1
 Objetivos
2

 Conocer los diferentes conceptos relacionadas a las

pruebas de software
 Entender como se complementan las estrategias y
planes de pruebas para el software
 Temas
3

 Introducción
 Pruebas de Software
 Niveles de pruebas
 Tipos de pruebas
 Estrategias y plan de pruebas
 Introducción
4

Contexto de las pruebas

La economía mundial es cada vez más Las aplicaciones crecen en tamaño,

dependiente del software. complejidad y distribución.

Los negocios demandan mayor productividad Las pruebas y las revisiones mejoran la
y CALIDAD en menos tiempo. CALIDAD del software
 Introducción
5

¿Qué son los errores y defectos?

 ¿Qué es un Error?

 Una acción humana que produce un

resultado incorrecto

 ¿Qué es un Defecto?
 Una manifestación de un error en software
 También conocido como un defecto o “bug”

 De ser ejecutado, un defecto puede causar

un fallo
 Introducción
6

¿Qué es un fallo?
 Una desviación del software de su entrega esperada o

servicio
 Es un defecto encontrado

 El fallo es un acontecimiento, el defecto es un estado del

software, causado por un error

 Introducción
7

Los defectos y los fallos provienen

 Errores en especificación, diseño e implementación del

software
 Errores en el uso del sistema

 Condiciones ambientales

 Daño intencional

 Consecuencia de errores tempranos, defectos y fallas

 Introducción
8

El costo de los defectos

COSTO

TIEMPO
Requerimientos Diseño Construcción Pruebas Tiempo de Uso
 Introducción
9

El enfoque a las pruebas…

 El software se prueba para descubrir errores cometidos sin

darse cuenta al realizar su diseño y construcción

 Un proceso de prueba eficaz es aquel que descubre los

errores
 La prueba es un conjunto de actividades que se planean con

anticipación y se realizan de manera sistemática.

 Introducción
10

Las pruebas del software

 Verificación y Validación (V&V)
11

Verificación
 Es el proceso de evaluación de un sistema o de uno de sus
componentes para determinar si los productos de una fase
dada satisfacen las condiciones impuestas al comienzo de dicha
fase.
 ¿Estamos construyendo el producto correctamente?
Validación
 El proceso de evaluación de un sistema o de uno de sus
componentes durante o al final del proceso de desarrollo para
determinar si satisface los requisitos marcados por el usuario
 ¿Estamos construyendo el producto correcto?
 Verificación y Validación
12

Verificación Estática
 Se analizan las diferentes representaciones del sistema
(diagramas, requerimientos, código fuente) en busca de defectos
 No requiere que el código se ejecute
 Se logra con inspecciones del software
Verificación Dinámica
 Se contrasta dinámicamente la respuesta de prototipos
ejecutables del sistema con el comportamiento operacional
esperado
 El sistema se tiene que ejecutar
 Se logra mediante pruebas del software
 Pruebas de Software
13

 Pruebas (test):
 Una actividad en la cual un sistema o uno de sus componentes se
ejecuta en circunstancias previamente especificadas, los
resultados se observan y registran y se realiza una evaluación
de algún aspecto
 Caso de prueba (test case):
 Un conjunto de entradas, condiciones de ejecución y resultados
esperados desarrollados para un objetivo particular
 Pruebas de Software
14

Ideas paradójicas de las pruebas

 La prueba exhaustiva del software es impracticable (no se

pueden probar todas las posibilidades de su

funcionamiento ni siquiera en programas sencillos
 El objetivo de las pruebas es la detección de defectos en el

software (descubrir un error es el éxito de una prueba)

 Mito

 “Un defecto implica que somos malos profesionales y que

debemos sentirnos culpables todo el mundo comete errores”
 Pruebas de Software
15

Objetivos de las pruebas

 Determinar que el producto software satisface los
requerimientos especificados.
 Confirma que los productos trabajados apropiadamente
reflejan los requerimientos especificados. En otras palabras, la
verificación asegura que “se construye el producto
correctamente”.
 Confirmación, a través de la provisión de objetivos
evidenciables, que los requerimientos especificados han sido
cumplidos a cabalidad.
 Pruebas de Software
16

Objetivos de las pruebas

 Determinar que el producto de software cumple su

propósito.
 Confirma que el producto, como condición rutinaria, cumplirá a
cabalidad con su uso propuesto. En otras palabras, la
validación asegura que “se construye el producto correcto”.
 Detectar Defectos.
 Para descubrir fallas o defectos en el software donde su
comportamiento no está en conformidad con su especificación.
 Niveles de prueba
17

Pruebas de Bajo Nivel

 De Unidad, Unitarias o de Componentes

 De Integración

Pruebas de Alto Nivel

 De Sistema

 De Aceptación
 Niveles de prueba
18

Pruebas Unitarias
 Verifica el funcionamiento y busca defectos de los
componentes de software que pueden ser analizados
individualmente. (Ej: módulos, programas, objetos y clases).
 Niveles de prueba
19

Pruebas Unitarias
 Como se analizan individualmente, se utilizan “stubs” y

“drivers” para reemplazar el software faltante y simular las

interfaces entre los componentes del software. El “driver”
reemplaza a un componente que «llama» al componente a ser
probado; mientras que el “stubs” reemplaza a un componente
que es llamado por el componente bajo prueba.
 Niveles de prueba
20

Pruebas Unitarias
 Generalmente ejecutados por desarrolladores.

 Se utilizan herramientas del entorno de desarrollo,

depuradores, etc. que permiten el acceso al código.
 Usualmente los errores se arreglan al momento (sin necesidad

de documentarlos)
 Utilizados en XP para preparar y automatizar casos de

prueba antes de codificar. Esto se llama una prueba de primer

enfoque o desarrollo basado en pruebas.
 Niveles de prueba
21

Pruebas Unitarias
 Herramientas:

 JUnit
 TestNG (versión mejorada de JUnit)
 PHPUnit
 CPPUnit
 NUnit (.Net)
 MOQ (creación dinámica de objetos simuladores, mocks)
 Pruebas unitarias automáticas
22

22
 Pruebas unitarias automáticas
23

23
 Niveles de prueba
24

Pruebas de Integración
 Prueba interfaces entre distintos componentes o
interacciones ente distintas partes de un sistema. Se pueden
dividir en:
 Pruebas de integración de componentes

 Prueba las interacciones entre los componentes de un sistema. Se

realiza después de las pruebas Unitarias (o de componentes)
 Pruebas de integración de sistemas
 Prueba las interacciones entre los sistemas. Generalmente se realiza
después de las pruebas de sistema.
 Niveles de prueba
25

Pruebas de Integración - Estrategias

 Pruebas de integración ‟Big-Bang‟

 Se realiza cuando todos los componentes o sistemas están

completamente integrados
 Se prueba el integrado como un todo.
 Ventaja: No se tienen que simular partes.
 Desventaja: Ocupa tiempo y dificultad para rastrear fallas.
 Niveles de prueba
26

Pruebas de Integración - Estrategias

 Pruebas de integración ‟paso por paso‟

 Los componentes se integran uno por uno y en cada integración se

realizan las pruebas.
 Testeo incremental.
 Ventaja: Fácil de rastrear las fallas
 Se deben simular partes, por lo que demanda más tiempo.
 Niveles de prueba
27

Pruebas de Integración - Estrategias

 Top-Down: Las pruebas se realizan desde el principio hasta el

final, siguiendo el flujo de control.

 Niveles de prueba
28

Pruebas de Integración - Estrategias

 Bottom-Up: Las pruebas se realizan desde el final del flujo de

control hasta el principio.

 Según funcionalidades: Las pruebas se llevan a cabo en base

a las funcionalidades según lo documentado en la

especificación funcional.
 Niveles de prueba
29

Pruebas de Sistema
 Se concentra en el comportamiento de todo el sistema. Se

incluyen pruebas basadas en requerimientos, riesgos, casos de

uso, procesos de negocio, etc. Se realizan tanto pruebas
funcionales como no funcionales.
 Relacionado con el comportamiento de todo el sistema en su

totalidad, según haya sido redefinido en el alcance del

proyecto.
 Comprueba que el sistema construido cumpla con todas sus

especificaciones.
 Niveles de prueba
30

Pruebas de Aceptación
 Se presenta el software al cliente para su aceptación.

 Es el cliente el que debe decidir si el producto ya está listo.

 Se realiza en un entorno de pruebas, simulando ser el entorno

donde será implementado el software.

 También se puede dividir en niveles. Ejemplos:

 Las pruebas de aceptación de usabilidad de componentes se deben

realizar durante las pruebas de componentes
 Las pruebas de aceptación para una nueva mejora de
funcionalidad se deben realizar antes de las pruebas de sistema.
 Niveles de prueba
31

Pruebas de Aceptación
 Otros tipos de pruebas de aceptación:

 Pruebas de aceptación del usuario

 Pruebas de aceptación operacional
 Pruebas del contrato de aceptación
 Pruebas de regulación de aceptación
 Pruebas Alfa
 Pruebas Beta
 Niveles de prueba
32

Pruebas de Aceptación: Pruebas Alfa

 Pruebas internas, generalmente por el mismo equipo

 Puede ser usuarios externos también, pero…

 Se realiza en el entorno del desarrollador

Pruebas de Aceptación: Pruebas Beta

 También llamado ‟pruebas de campo‟

 Siempre son usuarios externos usan el producto

 Ambientes de trabajo reales

 Los usuarios informan de los errores o incidentes encontrados

mientras usaban el producto
 Tipos de prueba
33

 Los tipos de prueba son un medio para clarificar el objetivo

de ciertos niveles de prueba en un programa o proyecto.
 Enfocar las Pruebas en un específico objetivo de prueba y
seleccionar el apropiado tipo de prueba hace más fácil
comunicar y tomar decisiones.
 Tipos de prueba
34

 Un tipo de prueba está enfocado en un particular objetivo de

prueba, el cual podría ser la prueba de una función a ser
realizada por un componente o sistema; una característica no
funcional, tal como la confiabilidad o la usabilidad; o pruebas
relativas a los cambios, como pruebas de confirmación o de
regresión.
 Los tipos son:
 Prueba Funcional
 Prueba No Funcional
 Prueba Estructural
 Prueba relacionadas a los cambios
 Tipos de prueba
35

Prueba funcional
 La prueba funcional considera el comportamiento especificado

y se denomina también: Prueba de Caja Negra.

 El funcionamiento de un sistema o componente, está
especificado en:
 Especificación de Requerimientos
 Especificación Funcional
 Especificación de Componentes
 Casos de Uso
 Historias de Usuario, etc.
 Tipos de prueba
36

Prueba funcional
 Pueden existir funciones no documentadas que serán

también parte de los

requerimientos de un sistema.
 Puedes ser realizada desde dos perspectivas:

 Basada en los requerimientos

 Basada en los procesos de negocio
 Tipos de prueba
37

Prueba No funcional
 Un segundo objetivo de las pruebas es la prueba de las

características de calidad o atributos no funcionales del

sistema.
 Probamos algo que necesitamos medir en alguna escala de

medida.
 La prueba no funcional, así como la prueba funcional es

realizada en todos los niveles de prueba.

 Tipos de prueba
38

Prueba No funcional
 Incluye las pruebas de:

 Carga
 Estrés
 Usabilidad
 Mantenibilidad
 Confiabilidad
 Portabilidad
 Tipos de prueba
39

Prueba No funcional: De Estrés

 O también conocidas como pruebas de performance o

rendimiento
 Es el proceso de poner demanda en un sistema o dispositivo
y medir su respuesta
 Permite:

 Identificar cuellos de botella

 Reducir el riesgo de caídas del sistema
 Aprovechar los recursos de TI más eficientemente
 Conocer los límites que soporta el sistema
 Tipos de prueba
40

Prueba No funcional: De Estrés

 Algunas herramientas para medir performance:

 JMeter
 Grinder
 LoadSim
 Apache benchmark
 Paessler
 WAPT
 Tipos de prueba
41

Prueba Estructural
 Un tercer objetivo es la estructura del sistema o componente.

Es frecuentemente llamado Prueba de caja blanca, debido a

que el interés está en lo que ocurre dentro de la caja.
 Es frecuentemente usado como un modo para medir la

rigurosidad de las pruebas a través de la cobertura de un

conjunto de elementos estructurales.
 Es comúnmente aplicado a nivel de prueba de componentes y

pruebas de integración.
 Tipos de prueba
42

Prueba relativas a los cambios

 El último objetivo de las pruebas es la prueba de los cambios.

 Prueba de confirmación: Ejecutar de nuevo la prueba para

confirmar que el defecto haya sido reparado.
 Pruebas de regresión: Las pruebas se realizan con la

intención de comprobar que el sistema no ha retrocedido (es

decir, que no tienen ahora más defectos en ella como
consecuencia de algún cambio) . Es decir se prueba lo que ya
se había probado anteriormente y pasó correcto.
 Automatización de las pruebas
43

Elementos
 Gestor de pruebas

 Gestiona la ejecución de las pruebas del programa. Mantiene un

registro de los datos de las pruebas, resultados esperados y
facilidades probadas del programa.
 Generador de datos de prueba
 Genera datos de prueba para el programa a probar. Se logra
seleccionando datos de una base de datos o utilizando patrones
para generar datos aleatorios.
 Oráculo
 Predice resultados esperados de las pruebas. Pueden ser versiones
previas del programa o sistemas de prototipos.
 Automatización de las pruebas
44

Elementos
 Las pruebas back-to-back implican ejecutar el oráculo y el
programa a probar, en paralelo.
 Las diferencias entre sus salidas son resaltadas.
 Comparador de ficheros.
 Compara los resultados de las pruebas del programa con los
resultados de pruebas previas e informa de las diferencias entre
ellos. Se utilizan en pruebas de regresión, donde se comparan los
resultados de ejecutar diferentes versiones.
 Generador de informes
 Proporciona informes y facilidades de generación para los
resultados de las pruebas.
 Automatización de las pruebas
45

Elementos
 Analizador dinámico.

 Añade código a un programa para contar el número de veces que

se ha ejecutado cada sentencia. Después de las pruebas, se
genera un perfil de ejecución que muestra cuántas veces se ha
ejecutado cada sentencia del programa.
 Simulador.
 Hay varios tipos de simuladores. Los simuladores de la máquina
objetivo simulan la máquina sobre la que se ejecuta el programa.
 Estrategias de pruebas
46

 Describe la técnica, patrón y/o herramientas a utilizarse en

el diseño de los casos de prueba. Por ejemplo en el caso de
pruebas unitarias de un procedimiento, esta sección podría
indicar “Se aplicará la estrategia caja de negra de
fronteras de la precondición”.
 En lo posible en la estrategia se debe precisar el número
mínimo de casos de prueba a diseñar
 La estrategia también explica el grado de automatización
que se exigirá, tanto para la generación de casos de
prueba como para su ejecución.
 Estrategias de pruebas
47

 La estrategia define:
 Técnicas de pruebas (manual o automática) y herramientas a ser
usadas.
 Qué criterios de éxito y culminación de la prueba serán usados.
 Consideraciones especiales afectadas por requerimientos de
recursos o que tengan implicaciones en la planificación.
 En resumen, son todos los métodos que facilitan probar los
niveles y tipos de pruebas definidos mediante casos de
prueba
 Plan de pruebas
48

Objetivo
 Señalar el enfoque, los recursos y el esquema de

actividades de prueba, así como los elementos a probar, las

características, las actividades de prueba, el personal
responsable y los riesgos asociados
 Puede haber un plan global que explique el énfasis en

realizar sobre los distintos tipos de prueba (verificación,

integración, aceptación)
 Plan de pruebas
49

Documentos
 Según el estándar IEEE 829,

se definen varios
documentos relacionados con
el diseño de las pruebas
 Plan de pruebas
50

Relación con las estrategias de pruebas

 El plan de pruebas es la suma de la estrategias de pruebas

y la logística para realizar las pruebas

 Una estrategia de prueba es lo que quieres probar.
Logística de las pruebas son los recursos que se necesita
para poner en marcha lo que se quiere probar, con la
forma en que deseas probar. Y la unión de esta pareja es
el Plan de pruebas: factores como el donde, el cuando y el
con que, las pruebas se llevará a cabo.
 Plan de pruebas
51

¿Cuál viene primero?

 No se debe forzar un primero; ya que cada uno de ellos

evoluciona a medida que avanza el proyecto. Pero si lo que

realmente interesa es la documentación de estos elementos,
entonces la estrategia de prueba vendría antes del plan de
pruebas.
 Plan de pruebas
52

Ejemplo de caso de prueba

 ID Caso de prueba
 Descripción de la prueba
 Resultados esperados
 Resultados actuales
 Indicador si pasó o falló
 Anotaciones
 Plan de pruebas
53

Ejemplo de caso de prueba (2)

 Se puede especificar en detalle los datos y la secuencia de
pasos para la prueba
 Plan de pruebas
54

Ejemplo de caso de prueba (3)

 Pueden ser cuadros más resumidos
 Plan de pruebas
55

Documento de Pruebas
 Objetivo
 Alcance
 Esquema de Pruebas
 Pruebas de Interface
 Pruebas de Funcionalidad
 Pruebas de Integración
 Condiciones de Excepción
 Pruebas de Mensajes de Error
 Pruebas de Integridad
 Plan de pruebas
56

 Pruebas de Seguridad
 Pruebas de Performance
 Requerimientos para pruebas
 De datos
 De simuladores
 De hardware
 De software
 Recursos humanos
 Cronograma de pruebas
 Herramientas para pruebas
57

 TestLink
 Qmetry
 TestRail
 qTest
 PractiTest
 Zephyr
 TestLodge
 Selenium
 Resumen
58

 Un defecto es una manifestación de un error en software. El

fallo es un defecto encontrado.
 Verificación responde a la pegunta: ¿Estamos construyendo
el producto correctamente? , mientras que validación
responde a ¿Estamos construyendo el producto correcto?
 Las pruebas son una actividad en la cual un sistema o uno
de sus componentes se ejecuta en circunstancias
previamente especificadas, los resultados se observan y
registran y se realiza una evaluación de algún aspecto
 Los cuatro niveles de pruebas son: unitarias, de integración,
de aceptación y de sistema
 Los tipos de prueba son funcional, no funcional, estructural y
relacionada a cambios.
 ¿Preguntas?
59

 ¿Cuáles son los principales niveles y tipos de

pruebas?
 Referencias
60

 Eric Braude, Ingeniería de Software. Una perspectiva

orientada a objetos (1ra. Edición)
 Capítulo 9, Integración, verificación y validación del sistema
 Ingeniería de Software. Un enfoque desde la guía SWEBOK
(1ra. edic.), Salvador Sánchez, Miguel Ángel Sicilia, Daniel
Rodríguez
 Capítulo 7: Pruebas
 Guillermo Pantaleo, Ludmila Rinaudo, Ingeniería de
Software (1ra. Edición)
 Capítulo 16, Pruebas de software
 Capítulo 17, Proceso de pruebas de software
 Roger S. Pressman, Ingeniería de Software: Un enfoque
práctico (7ma edición)
 Capítulo 17: Estrategias de pruebas de software