Universidad Nacional de Ingeniería

Facultada de Ciencias y Sistemas

Ingeniería de Sistemas

SOFTWARE II
INTEGRANTES:
• Br. Guismarck Josue Nuñez Gonzalez
• Br. Katerin Paola Flores Blandón
• Br. Isaura de los Ángeles Leiva Blandón
• Br. Jeffrey Alfonso Barrios
TIPOS Y NIVELES DE PRUEBA DE
SOFTWARE

2
 Pruebas de
componentes

Pruebas de
integración

Pruebas de sistemas

Pruebas de
mantenimiento

3
 Pruebas de componentes
Las pruebas de componentes o unitarias Son la primera fase de las pruebas
dinámicas y se realizan sobre cada módulo o componente del software que se
pueda probar de forma independiente. También se les conoce como prueba
unitaria o de módulo.

Un módulo es la unidad mínima funcional de un sistema, si el sistema es de una

calculadora de operaciones básicas como suma, resta, multiplicación y división,
cada operación está desarrollada en un módulo. Por cada nivel de pruebas se
deben definir objetivos, objetos a probar, bases de prueba, defectos comunes y
responsabilidades.
. 4
Las pruebas de componentes tienen como objetivos:

▪ Conseguir defectos y fallos en objetos de prueba.

▪ Reducir el riesgo.

▪ Construir confianza en la calidad del componente

▪ Prevenir defectos que escalen a niveles de prueba más altos.

Los objetos de prueba en este nivel son: Componentes, unidades o módulos, código o
estructura de datos clases y módulos de bases de datos.

5
Las bases de pruebas pueden ser: el diseño detallado, modelo de datos, especificaciones de
componentes o el código fuente.

Los defectos o fallas más comunes pueden ser: El funcionamiento incorrecto, entiéndase que no
es acorde a las especificaciones, los problemas de flujos de datos, códigos y lógica incorrecta
en el código.

Usualmente la prueba de componente es responsabilidad del desarrollador que escribió el

código, porque necesita acceso al código fuente.

6
 Pruebas de integración
Sirven para asegurar que la comunicación, enlaces y datos
compartidos entre módulos o con diferentes partes del sistema; como
el sistema operativo, sistema de archivos o hardware, funcionan
correctamente.

Antes de las pruebas de integración, los componentes tuvieron que

haber pasado sus pruebas unitarias, por lo que el enfoque ahora es
sobre el flujo de control entre los módulos, y sobre los datos que son
intercambiados entre ellos de manera independiente

7
Los Objetivos de las Pruebas de Integración son:

▪ Conseguir defectos y fallas entre las interfaces de módulos y sistema, así como en los
módulos en sí mismos.

▪ Reducir el riesgo.

▪ Construir confianza en la calidad de las interfaces

▪ Prevenir defectos que escalen a niveles de prueba más altos.

Las Bases de prueba a este nivel de prueba, pueden ser: Subsistemas Bases de Datos,
Infraestructura Interfaces, Interfaces de comunicación de aplicaciones.

8
Los Objetos de prueba son Diseño de software y sistemas, Diagrama de secuencias
Especificaciones de interfaz y protocolos de comunicación, Casos de uso, Arquitectura a nivel
de componentes o sistemas según corresponda, Flujos de trabajo y, Definiciones de interfaces
externas. Los Defectos o fallas más comunes serían: Datos incorrectos, faltantes o mal
codificados, Secuenciación o sincronización incorrecta a las llamadas de interfaz,
Incompatibilidad de la interfaz entre otros.

Enfoques para las pruebas de integración:

1. Prueba Big Bang

2. Prueba Incremental
• Top-Down
• Botton Up
• Prueba Incremental funcional
9
 Pruebas de sistemas

Sirven para verificar que se han integrado adecuadamente todos los

elementos del sistema y que funciona apropiadamente como un todo. Es
similar a la prueba de integración, pero con un alcance mucho más amplio.

Es común que la lleven a cabo testers especializados que forman un

equipo de prueba dedicado y a veces independiente, que informa al
gerente de desarrollo o al gerente de proyecto.

10
Las Pruebas de Sistemas tienen como Objetivos:

▪ Reducir el riesgo

▪ Verificar que los requerimientos funcionales y no funcionales del sistema corresponden a los
diseñados y a su vez con lo especificado por el usuario

▪ Validar que el sistema está completo y funciona como se esperaba

▪ Generar confianza en la calidad del sistema en su conjunto

▪ Encontrar defectos

▪ Evitar que los defectos escapen a niveles de prueba más altos, como las pruebas de
aceptación o producción.

11
En este nivel los Objetos de prueba son: Aplicaciones, sistemas de hardware o software y
sistemas operativos Las bases de prueba son comúnmente especificaciones de requisitos del
sistema y software, funcionales y no funcionales: Informes de análisis de riesgos casos de uso,

diagramas de estado Manuales de Sistema y de Usuario entre otras.

Los Defectos o fallas más comunes pueden ser: Cálculos incorrectos. Comportamiento
incorrecto o inesperado de tareas funcionales o no funcionales del sistema, Control de datos o
flujos de datos incorrectos dentro del sistema etc.

Las pruebas generalmente son realizadas por probadores independientes.

12
 Pruebas de aceptacion

La prueba de aceptación debe responder preguntas como:

¿Se puede liberar el sistema?, ¿Cuáles, si los hay, son los riesgos de
negocio pendientes? Y, ¿Ha cumplido el desarrollo sus objetivos?

Para realizar las pruebas de aceptación el sistema será entregado a

los usuarios u otros interesados. Su fin es determinar si el sistema es
adecuado para su propósito.

13
Las pruebas de aceptación pueden ser de diversos tipos, dependiendo de cuál parte del sistema
se está validando. Cada tipo de prueba se prepara y se ejecuta por separado. Estas son:

Pruebas de aceptación de Usuario

Pruebas de aceptación operacional

Pruebas de aceptación contractual

Pruebas de aceptación reglamentaria

Pruebas de aceptación Alfa y Beta

14
Objetivos generales:

• Establecer confianza en la calidad del sistema como un todo.

• Validar que el sistema está completo y funciona como se espera.

• Verificar que los requerimientos funcionales y no funcionales del sistema cumplen con las
especificaciones.

• Satisfacer requisitos legales o regulatorios

Los objetos de prueba típicos para cualquier forma de prueba de aceptación incluyen: Procesos
operativos y de mantenimiento, Formularios, Reportes y Datos de producción existentes y
convertidos.

15
Tipos de pruebas

Funcionales

No funcionales

Estructurales

Asociada a cambios
16
 Pruebas funcionales
Se basan en las funciones, descritas en documentos o entendidas por los
probadores. Las pruebas funcionales deben realizarse en todos los niveles de
prueba, aunque el enfoque es diferente en cada nivel.

Las pruebas funcionales pueden utilizar técnicas de caja negra para derivar
condiciones de prueba, y casos de prueba para la funcionalidad del
componente o sistema. El conocimiento del negocio será de gran ayuda al
ejecutar pruebas funcionales.

17
 Pruebas no funcionales
Evalúan qué tan bien, o qué tan rápido se hace algo. Se prueba algo que
necesite medirse en una escala, por ejemplo, tiempo de respuesta del sistema.
Las pruebas no funcionales, como las pruebas funcionales, se realizan en
todos los niveles de prueba y deben ejecutarse tan pronto como sea posible.

Las pruebas no funcionales incluyen, entre otras, pruebas de rendimiento,

pruebas de carga, pruebas de estrés, pruebas de usabilidad, pruebas de
mantenimiento, pruebas de confiabilidad y pruebas de portabilidad.

18
 Pruebas de caja blanca
Se les denomina de 'caja blanca' o 'caja de vidrio' porque estamos interesados
en lo que sucede 'dentro de la caja'. La estructura interna puede incluir código,
arquitectura o flujos de datos dentro del sistema.

Las pruebas de caja blanca se utilizan con mayor frecuencia como una forma
de medir la exhaustividad de las pruebas a través de la Cobertura estructural.
La Cobertura estructural es la medida en que algún tipo de elemento
estructural ha sido probado, y se expresa como un porcentaje del tipo de
elemento que se cubre.

Pruebas de confirmación Pruebas de regresión

19
 Pruebas de mantenimiento
A medida que el tiempo pasa, el software y los sistemas deben mantenerse.
Algún tipo de cambio es casi inevitable en los sistemas en funcionamiento, ya
sea para reparar defectos descubiertos en uso operativo, para agregar alguna
funcionalidad o para eliminar o alterar las funcionalidades existentes.

Existen 3 situaciones elementales que desencadenan el mantenimiento de un

sistema, tanto para cambios planificados como no planificados, y estos son:

• Modificaciones
• Retiro del sistema
• Migración
20
Hay modificaciones en las que se pueden planificar las pruebas, y
modificaciones correctivas ad-hoc.

Se pueden identificar los siguientes tipos de modificaciones planificadas

1. Modificaciones perfectas
2. Modificaciones adaptativas
3. Modificaciones correctivas planificadas

21
El análisis de impacto evalúa los cambios que se realizaron para una versión
de mantenimiento para identificar las consecuencias tras su implementación,
así como los efectos secundarios esperados y posibles de un cambio, e
identificar las áreas del sistema que se verán afectadas directamente.
Adicionalmente el análisis de impacto puede ayudar con la identificación del
impacto de un cambio en las pruebas existentes. Recordemos que estas
pruebas serán ejecutadas sobre los posibles efectos secundarios durante las
pruebas de Regresión y sobre las áreas afectadas directamente en el sistema.

22
Pruebas estáticas y
dinámicas

23
La prueba dinámica requiere la ejecución del software que se está probando,
mientras que la prueba estática se basa en la revisión manual o mediante
herramientas automatizadas de los productos de trabajo, incluido el código
fuente sin ejecutar.

Diferencias

La prueba estática detecta defectos, la prueba dinámica identifica fallas. Sin

embargo, la prueba estática detecta defectos en los productos de trabajo
directamente, en lugar de identificar los fallos causados por defectos cuando
se ejecuta el software.

24
La prueba estática detecta defectos difíciles de alcanzar cuando se ejecuta
el software Un defecto puede residir en un producto de trabajo durante
mucho tiempo sin provocar un fallo. La combinación de pasos a ejecutar
para llegar a donde se encuentra el defecto se puede dar con poca
frecuencia o puede ser muy complicado de lograr, por lo que no será fácil
construir y ejecutar una prueba dinámica que lo detecte.

La prueba estática puede ser capaz de encontrar el defecto con un esfuerzo

mucho menor. La prueba estática se enfoca en la calidad interna de los
productos de trabajo, la dinámica en el comportamiento del software.

25
Otra diferencia es que la prueba estática se puede utilizar para mejorar la
consistencia y la calidad interna de los productos de trabajo, mientras que la
prueba dinámica se concentra, normalmente, en los comportamientos
visibles desde el exterior,

Los defectos encontrados en las pruebas estáticas son más fáciles de

conseguir y reparar.

26
Proceso de revisión
de pruebas

27
Las revisiones consisten en examinar cuidadosamente un producto de trabajo, a menudo
representan hitos del proyecto y pueden ser realizadas por una o más personas con el principal
objetivo de encontrar y remover defectos.

El tipo y la cantidad de defectos encontrados durante las revisiones también pueden ayudar a
los evaluadores a enfocar sus pruebas y seleccionar clases efectivas de pruebas. En algunos
casos, los clientes o los usuarios asisten a la reunión de revisión y brindan comentarios al
equipo de desarrollo, por lo que las revisiones también son un medio de comunicación entre el
cliente y el usuario. Las revisiones pueden ser informales o formales.

Si están interesados en información más detallada del proceso de revisión de productos de

trabajo, incluyendo roles y técnicas de revisión, pueden consultar el estándar ISO/IEC 20246.

28
El proceso de revisión comprende las siguientes actividades principales:

1. Planificación
2. Iniciar la Revisión
3. Revisión Individual
4. Analizar y Comunicar posibles defectos
5. Corregir e Informar

Generalmente es tarea del autor de dicho producto de trabajo realizar las

correcciones, comunicar defectos a la persona o equipo adecuado

29
De acuerdo al tipo de revisión, una persona puede asumir más de un rol, y las
acciones asociadas a cada rol también pueden variar según el tipo de revisión.
Además, con la introducción de ciertas herramientas para apoyar el proceso de
revisión, especialmente el registro de defectos, puntos pendientes y decisiones, a
menudo no hay necesidad de un Escriba.
ISO/IEC 20246.

Los cuatro tipos de revisiones más comunes son:

1. La Revisión Informal 3. La Revisión Técnica

2. La Revisión Guiada 4. La Inspección

30
Las técnicas de revisión que pueden aplicarse durante la actividad de revisión
individual o preparación individual para detectar defectos son:

• Ad hoc
• Basada en Listas de Comprobación o Checklist.
• Escenarios y Ensayos
• Basada en Roles
• Basada en Perspectiva

31
El éxito de las revisiones depende de factores técnicos y humanos.

Factores técnicos:

Cada revisión debe tener objetivos claros, definidos durante la planificación

de la revisión y utilizados como criterios de salida medibles.
Los tipos y técnicas de revisión se deben aplicar según el contexto.
Los documentos de gran tamaño deberán redactarse y revisarse en
pequeños fragmentos.
Entrenar a los participantes en la técnica de revisión, en especial para las
revisiones más formales.
Los participantes deberán disponer de tiempo suficiente para prepararse.

32
Factores de éxito relativos a las personas:

Dependiendo de los objetivos que se quieran alcanzar debemos involucrar a

las personas adecuadas.
Los probadores deben verse como elementos valiosos que contribuyen a la
revisión y aprenden sobre el producto de trabajo.
Los participantes deben dedicar tiempo y atención adecuados a los detalles.
Las revisiones se llevan a cabo en pequeños fragmentos, para que los
revisores no pierdan la concentración durante la revisión individual o la
reunión de revisión, en los casos cuando se lleva a cabo.

33
Los defectos detectados deben ser reconocidos, valorados y tratados
objetivamente.
La reunión deberá ser efectiva de manera que los participantes no la
consideren una pérdida de tiempo.
Es importante que los participantes cuiden su lenguaje corporal, evitando
conductas que podrían indicar aburrimiento, exasperación u hostilidad hacia
otros participantes.
Debe promoverse una cultura de aprendizaje y mejora de los procesos

34
Anexos - Pruebas realizadas
Herramientas utilizadas

35
Prueba de componentes

36
37
38
39
40
41
42
43
44
45
46
47
Prueba de integración

48
49
50
51
52
53
54
55
56
Prueba de Sistema

57
58
59
60
61
62
63
64
Prueba de Aceptación

65
66
67
68
69
70
71
72
THANK YOU !

Made with by