“AÑO DEL BICENTENARIO DEL PERÚ: 200 AÑOS DE INDEPENDENCIA”

UNIVERSIDAD NACIONAL
DE TRUJILLO

Carrera de Ingeniería de Sistemas

DOCENTE: Vidal Melgarejo, Zoraida Yanet.

CURSO: Programación Orientada a objetos II.

CICLO: III.

ALUMNO:
- Castillo Rosas Charles Duck.
- Castillo Rabanal Luis Javier.
- Guevara Sanchez Ernesto David.
- Lulichac Ramos María Fernanda Guliana.
- Ramos Portilla Maykol Kenji.
- Sanchez Chiclayo Aldo Jean Marco.
- Valdiviezo Barros Edwin David.

TRUJILLO-PERÚ
2021
Contenido
DEFINICIÓN DE PRUEBAS DE SOFTWARE ............................................................................................ 3
TECNICAS DE PRUEBAS........................................................................................................................ 4
Caja Blanca ...................................................................................................................................... 4
Ventajas ....................................................................................................................................... 4
Desventajas ................................................................................................................................. 4
Caja Negra ....................................................................................................................................... 5
Ventajas ....................................................................................................................................... 5
Desventajas ................................................................................................................................. 5
TIPOS DE PRUEBAS .............................................................................................................................. 6
Pruebas de unidad........................................................................................................................... 6
Características ............................................................................................................................. 6
Ventajas ....................................................................................................................................... 6
Pruebas de integración ................................................................................................................... 7
Tipos de prueba de integración................................................................................................... 7
BIBLIOGRAFÍA ...................................................................................................................................... 8
DEFINICIÓN DE PRUEBAS DE SOFTWARE

La prueba de software es el proceso de evaluar y verificar que un producto o

aplicación de software hace lo que se supone que debe hacer. Los beneficios de las
pruebas incluyen la prevención de errores, la reducción de los costos de desarrollo y
la mejora del rendimiento.

El objetivo de las pruebas es presentar información sobre la calidad del producto a

las personas responsables de este. Las pruebas de calidad presentan los siguientes
objetivos: encontrar defectos o bugs, aumentar la confianza en el nivel de calidad,
facilitar información para la toma de decisiones, evitar la aparición de defectos.

El ambiente ideal de las pruebas es aquel que es independiente del desarrollo del
software, de esta manera se logra objetividad en las pruebas.

A pesar de lo que muchos promueven, no existen las "mejores prácticas" como

tales. Toda práctica puede ser ideal para una situación, pero completamente inútil o
incluso perjudicial en otra.

Por esto, las actividades técnicas, documentación, enfoques y demás elementos

que condicionarán las pruebas a realizar deben ser seleccionadas y utilizadas de la
manera más eficiente según contexto del proyecto.
TECNICAS DE PRUEBAS

Caja Blanca

También conocidas como pruebas de caja abierta, caja de cristal, caja clara o caja
transparente.

Son un método de evaluación de software que se utiliza para examinar la estructura interna,
el diseño, la codificación y el funcionamiento interno del software. Los desarrolladores
utilizan este método de prueba para verificar el flujo de entradas y salidas a través de la
aplicación, mejorando la usabilidad y el diseño y reforzando la seguridad.

El concepto se llama "caja blanca" porque es simbólicamente transparente, ya que el código

es visible para el probador durante el examen.

Ventajas
• Optimización del código para encontrar errores.

• Se comprueba todo el código, proporcionando un examen exhaustivo.

• Es fácilmente automatizable.

• Las pruebas pueden comenzar en una fase temprana del ciclo de vida del desarrollo

de software, incluso antes de que la interfaz gráfica de usuario esté disponible.

Desventajas

• Las pruebas de caja blanca pueden ser complejas y costosas.

• Los desarrolladores que suelen ejecutar casos de prueba de caja blanca lo detestan.

Por lo tanto, los desarrolladores no prueban la caja blanca en detalle, lo que puede
provocar errores de producción.

• Además, para la prueba de caja blanca, son necesarias herramientas profesionales y

un conocimiento profundo de la programación y la ejecución.
• La prueba de caja blanca lleva mucho tiempo, lleva tiempo probar completamente
las aplicaciones más grandes.
Caja Negra

Las pruebas de caja negra, es una técnica de pruebas de software en la cual la funcionalidad
se verifica sin tomar en cuenta la estructura interna de código, detalles de implementación
o escenarios de ejecución internos en el software.

En las pruebas de caja negra, nos enfocamos solamente en las entradas y salidas del sistema,
sin preocuparnos en tener conocimiento de la estructura interna del programa de software.
Para obtener el detalle de cuáles deben ser esas entradas y salidas, nos basamos únicamente
en los requerimientos de software y especificaciones funcionales.

Ventajas

• La prueba es imparcial porque el diseñador y el evaluador son independientes entre

sí.

• El evaluador no necesita conocimientos de ningún lenguaje de programación

específico.

• La prueba se realiza desde el punto de vista del usuario, no del diseñador.

• Los casos de prueba se pueden diseñar tan pronto como se completen las

especificaciones.

Desventajas

• La prueba puede ser redundante si el diseñador de software ya ha ejecutado un caso

de prueba.

• Los casos de prueba son difíciles de diseñar.

• Probar cada flujo de entrada posible no es realista porque llevaría una cantidad de

tiempo excesiva; por lo tanto, muchas rutas de programas no se probarán.

TIPOS DE PRUEBAS

Pruebas de unidad

Valida que cada unidad de software funcione según lo esperado. Una unidad es el
componente de prueba más pequeño de una aplicación. Esto sirve para asegurar que cada
unidad funcione correcta y eficientemente por separado.

Características

• Automatizable: No debería requerirse una intervención manual. Esto es

especialmente útil para integración continua.

• Completas: Deben cubrir la mayor cantidad de código.

• Rápidas: Deben poder ejecutarse en fracciones de segundo, caso contrario serán

obviadas.

• 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.

Ventajas

• Facilitan que el programador cambie el código para mejorar su estructura.

• Permiten llegar a la fase de integración con un grado alto de seguridad de que el

código está funcionando correctamente.

• Las propias pruebas son documentación del código, puesto que ahí se puede ver
cómo utilizarlo.
• Los errores están más acotados y son más fáciles de localizar.
Pruebas de integración

Se realizan en el ámbito del desarrollo de software una vez que se han aprobado las pruebas
unitarias y lo que prueban es que todos los elementos unitarios que componen el software,
funcionan juntos correctamente probándolos en grupo. Se centra principalmente en probar
la comunicación entre los componentes y sus comunicaciones ya sea hardware o software.

Existen muchos tipos o enfoques diferentes para las pruebas de integración. La elección del
enfoque depende de varios factores como el costo, la complejidad, la criticidad de la
aplicación, etc.

Tipos de prueba de integración

Prueba de Integración Big Bang

En las pruebas de integración de Big Bang, todos los componentes o módulos se

integran simultáneamente, después de lo cual todo se prueba como un todo.

Prueba de Integración Descendente

Las pruebas se llevan a cabo de arriba a abajo, siguiendo el flujo de control o la

estructura arquitectónica (por ejemplo, comenzando desde la GUI o el menú
principal).

Prueba de Integración Ascendente

Las pruebas se llevan a cabo desde la parte inferior del flujo de control hacia
arriba. Los componentes o sistemas se sustituyen por controladores.

Prueba de Integración Incremental

Otro enfoque es que todos los programadores se integran uno por uno y se
realiza una prueba después de cada paso.

El enfoque de prueba de integración incremental tiene la ventaja de que los

defectos se encuentran temprano en un ensamblaje más pequeño cuando es
relativamente fácil detectar la causa.
BIBLIOGRAFÍA

https://trans-ti.com/2020/12/14/que-son-las-pruebas-de-integracion-en-el-sofware-testing/

https://www.ibm.com/docs/es/rtw/9.0.1?topic=phases-integration-testing

https://manuel.cillero.es/doc/metodologia/metrica-3/tecnicas/pruebas/integracion/

https://es.wikipedia.org/wiki/Prueba_unitaria#Ventajas

https://es.itpedia.nl/2018/02/05/white-box-testing-onder-de-loep/

http://www.pmoinformatica.com/2017/02/pruebas-de-caja-negra-ejemplos

https://trans-ti.com/2020/12/30/en-el-sofware-testing-que-son-las-pruebas-de-caja-negra

http://www.pmoinformatica.com/2014/06/plantilla-de-casos-de-prueba.html

https://historiadelaempresa.com/que-es-el-white-box-testing