UNIVERSIDAD NACIONAL EXPERIMENTAL

DE LOS LLANOS OCCIDENTALES

“EZEQUIEL ZAMORA”

UNELLEZ

INTRODUC
CIÓN A LA
VERIFICAC  Profesor:  Estu
Guillermo Certad.  Yulia
IÓN Y  Carrera: Ingeniería Informática 6to semestre.  C.I:
PRUEBAS  Sub-proyecto: Principios de ingeniería del software.

DEL
SOFTWARE

Barrancas, 2022

Índice
Introducción………………………………………………………………………………………....3

Objetivo de la verificación de software, planificación y características de la verificación…………4

Pruebas del software: objetivos y principios………………………………………………………...5

Técnicas y diseño de casos de prueba: diseño de casos de pruebas de la caja blanca…………….…6

Prueba del camino básico ……………………………………………………………………….…..7

Prueba de condiciones…………………………………………………………………………….…7

Prueba de bucles……………………………………………………………………………………..7

Diseño de casos de pruebas de la caja negra………………………………………………………...8

Partición equivalente………………………………………………………………………………...8

Análisis de valores límites…………………………………………………………………………...9

Pruebas de las interfaces………………………………………………………………………….....9

Pruebas de la documentación………………………………………………………………………10

Estrategias de pruebas del software ……………………………………………………………….10

Prueba de unidad: Definición y características…………………………………………………….10

Prueba de integración: Definición y características………………………………………………..11

Prueba de validación: Definición y características…………………………………………………12

Prueba del sistema: Definición y características…………………………………………………...13

Conclusión………………………………………………………………………………………….14

Introducción
El objetivo que tiene este desarrollo, es el de saber para qué son necesarias las pruebas y la

verificación de software, se debe de tener en cuenta que las dos antes mencionadas son un proceso

de revisión que el sistema de software producido cumple con las especificaciones y logra su
contenido. En resumen, se trata de evaluar el sistema o parte de este durante o al final del

desarrollo para determinar si satisface los requisitos iniciales.

Al tener presente lo ya descrito anteriormente, en este trabajo se verá lo que son los puntos

siguientes:

 Objetivo de la verificación de software, planificación y características de la

verificación.

 Pruebas del software: objetivos y principios.

 Técnicas y diseño de casos de prueba: Diseño de casos de pruebas de la

caja blanca.

o Prueba del camino básico.

o Prueba de condiciones.

o Prueba de bucles.

 Diseño de casos de pruebas de la caja negra

o Partición equivalente.

o Análisis de valores límites.

Hay muchas más pruebas, pero estas se verán a mediada que en el que se desarrolle este

módulo IV de: Introducción a la verificación y pruebas del software.

Objetivo de la verificación de software, planificación y características

de la verificación.
Objetivos:
  Introducir la verificación y validación del software y lidiar la diferencia entre

ellos.

 Detallar el proceso de inspección del programa y su papel en la V & V.

 Explicar el análisis estático como una técnica de verificación.

 Describir el proceso de desarrollo de software de Sala Limpia.

Planificación:

La planificación de la verificación debe especificar el propósito, los métodos, las

frecuencias y las responsabilidades de las actividades de verificación.

En sus características se deben de tomar en cuenta las actividades de verificación que

estas deben confirmar lo siguiente:

 Los PPR (Programación paralela UGR) están implementados;

 La entrada a los análisis de se actualiza continuamente;

 Los PPR operacionales y los elementos dentro del plan APPCC (Análisis de

peligros y puntos de control) se han implementado y son eficaces, a su vez los niveles de

peligros están dentro de los niveles aceptables identificados.

 Otros procedimientos requeridos por la organización se han implementado y

son eficaces.

Los resultados de la planificación deben estar en un formato adecuado para los métodos de
operación de la organización. Deben proporcionarse los resultados de la verificación para permitir
el análisis de los resultados de las actividades de verificación.

Pruebas del software: objetivos y principios.

 La prueba de software es un elemento crítico para la seguridad de un correcto

funcionamiento del software. Entre sus objetivos están:

 Descubrir defectos en el software.

 Verificar la integración adecuada de los componentes.

 Verificar que todos los requisitos se han implementado correctamente.

 Identificar y afirmar que los defectos hallados se han corregido antes de

entregar el software al cliente.

 Diseñar casos de prueba que sistemáticamente saquen a la luz diferentes

clases de errores, haciéndolo con la menor cantidad de tiempo y esfuerzo.

Para lograr los objetivos propuestos, un ingeniero de software deberá conocer los

principios básicos que guían las pruebas del software.

Principios:

Las pruebas se rigen por una serie de principios, una buena comprensión de estos facilitará

el posterior uso de los métodos en un efectivo diseño de casos de prueba. A continuación se citan:

 La prueba puede ser utilizada para mostrar la presencia de errores, pero

nunca su ausencia.

 El principal problema del proceso de prueba, es decidir cuándo parar.

 Evitar casos de pruebas no planificados, no reutilizable y triviales a menos

que el programa sea verdaderamente sencillo.

 Una pieza necesaria de un caso de prueba es la definición del resultado

esperado.
  Los casos de pruebas tienen que ser escritos no solo para condiciones de

entrada válidas y esperadas sino también para condiciones no válidas e inesperadas.

 El número de errores sin revelar es directamente proporcional al número de

errores descubiertos.

Estas leyes que definen básicamente la aplicación de las pruebas de software ayudan a

refinar el producto de software a través de las etapas involucradas.

Técnicas y diseño de casos de prueba:

Diseño de casos de pruebas de la caja blanca

Esta prueba se centra en la estructura interna del programa. En este caso la prueba consiste

en probar todos los posibles caminos de ejecución a través de las instrucciones del código, que

puedan trazarse.

Entrada Salida

Mediante esta prueba, el ingeniero del software puede:

1. Garantizar que se recorre por lo menos una vez todos los caminos independientes de cada

módulo.

2. Recorrer todas las decisiones lógicas en sus condiciones verdadera y falsa.

3. Recorrer todos los bucles en sus límites y con sus límites operacionales.

4. Recorrer las estructuras internas de datos para asegurar su validez.

 Prueba del camino básico

Esta prueba permite obtener una medida de la complejidad de la lógica de un diseño

procedimental y usar ésa medida como guía para la definición de un conjunto básico de camino de

ejecución. Esta prueba permite que se ejecute por lo menos una vez cada sentencia del programa.

Prueba de condiciones

Pruebas de Condición-Decisión (Decision Condition Testing) Técnica de diseño de pruebas

de caja blanca en la cual los casos de prueba son diseñados para practicar resultados de condición y

resultados de decisión.

Prueba de bucles

Los bucles son la piedra angular de la inmensa mayoría de los algoritmos implementados en
software, por lo que tenemos que prestarles una atención especial a la hora de realizar la prueba del
software.

La prueba de bucles es una técnica de prueba de caja blanca que se centra en la validez de

las construcciones de los bucles.

X X

Secuencia Si x entonces… Hacer… hasta x Mientras x hacer…

(If x then… else…) (Do…Until x) (While x do…)

 Diseño de casos de pruebas de la caja negra

Radica en estudiar la especificación de las funciones, la entrada y la salida para proceder los

casos. Aquí, la prueba ideal del software consiste en probar todas las posibles entradas y salidas del

programa.

La prueba de caja negra, también encuentra errores de:  

 Funciones incorrectas o ausentes. 

 Errores de interfaz.

 Errores en estructuras de datos o en accesos a bases de datos externas.

 Errores de rendimiento.

 Errores de inicialización y de terminación.

Entrada Funciones Salida

Prueba de partición equivalente

Este método de prueba de caja negra divide el dominio de entrada de un programa en clases

de datos, a partir de las cuales deriva los casos de prueba.

Cada una de estas clases de equivalencia representa a un conjunto de estados válidos o

inválidos para las condiciones de entrada.

 Prueba de análisis de valores límites

La técnica de análisis de los valores límite se basa en el hecho heurístico de que los errores

tienden a producirse con más probabilidad en los valores extremos de los posibles valores de

entrada.

Esta técnica, que puede considerarse una expansión de la idea de partición de equivalencia,

se puede usar siempre que la entrada a analizar tenga definidos esos límites en la especificación de

los requerimientos. En realidad no es que se pueda, sino que se debe usar en tales casos. Los

valores elegidos para los casos de prueba son justo aquellos que están por encima o por debajo de

los márgenes de las clases de equivalencia.

Los valores límite no solo se exploran en los datos de entrada, sino que también pueden

estudiar las condiciones de salida.

Pruebas de las interfaces

La prueba de interfaz, también conocida como prueba de API, es una prueba para probar la

interfaz entre los componentes del sistema, que pertenece a la categoría de prueba de caja gris.

La prueba de interfaz es una prueba para probar las interfaces entre los componentes del

sistema y se utilizan principalmente para detectar los puntos de interacción entre sistemas y

sistemas externos y entre subsistemas internos. El objetivo de la prueba es comprobar el proceso de

gestión de intercambio, transferencia y control de datos, así como la dependencia lógica mutua

entre sistemas.
 Pruebas de la documentación.

La documentación para desarrolladores es aquélla que se utiliza para el propio desarrollo

del producto y, sobre todo, para su mantenimiento futuro. Se documenta para comunicar la

estructura y comportamiento del sistema o de sus partes, para visualizar y controlar la arquitectura

del sistema, para comprender mejor el mismo y para controlar el riesgo, entre otras cosas.

Obviamente, cuanto más complejo es el sistema, más importante es la documentación.

Estrategias de pruebas del software:

Prueba de unidad: Definición y características

Nombre que reciben los procedimientos de pruebas locales a un módulo del sistema. Por

definición, dichas pruebas cubren las funcionalidades propias del módulo tanto con una perspectiva

de caja blanca como de caja negra; pero prestando poca o ninguna atención a la integración con

otros módulos.

Características de una buena prueba unitaria

 Las pruebas unitarias se tienen que poder ejecutar sin necesidad de

intervención manual. Esta característica posibilita que podamos automatizar su ejecución.

 Las pruebas unitarias tienen que poder repetirse tantas veces como uno

quiera. Por este motivo, la rapidez de las pruebas tiene un factor clave.

 Las pruebas unitarias deben poder cubrir casi la totalidad del código de

nuestra aplicación. Una prueba unitaria será tan buena como su cobertura de código. La

cobertura de código marca la cantidad de código de la aplicación que está sometido a una

prueba.
  Las pruebas unitarias tienen que poder ejecutarse independientemente del

estado del entorno. Las pruebas tienen que pasar en cualquier ordenador del equipo de

desarrollo.

 La ejecución de una prueba no puede afectar la ejecución de otra. Después

de la ejecución de una prueba el entorno debería quedar igual que estaba antes de realizar la

prueba.

 Las diferentes relaciones que puedan existir entre módulos deben ser

simuladas para evitar dependencias entre módulos.

 Es importante conocer claramente cuál es el objetivo del test. Cualquier

desarrollador debería poder conocer claramente cuál es el objetivo de la prueba y su

funcionamiento.

Es importante tener en cuenta que aunque estas son las características de una buena prueba,

no siempre será posible ni necesario cumplir con todas estas reglas y será la experiencia la que nos

guiará en la realización de las mismas.

Prueba de integración: Definición y características

La prueba de integración es una metodología de prueba de software utilizada para probar

componentes de software individuales o unidades de código para verificar la interacción entre

varios componentes de software y detectar defectos en la interfaz. Los componentes se prueban

como un solo grupo o se organizan de manera iterativa. Una vez que se han realizado las pruebas

de integración en los componentes, estas estarán fácilmente disponibles para las pruebas del

sistema.
 Características:

 Esta prueba afirma que los módulos / componentes integrados funcionen

correctamente.

 Las pruebas de integración se pueden iniciar una vez que los módulos que se

van a probar estén disponibles.

 Detecta los errores relacionados con la interfaz.

Prueba de validación: Definición y características

Las pruebas de validación en la ingeniería de software son el proceso de revisión que

verifica que el sistema de software producido cumple con las especificaciones y logra su cometido.

Es normalmente una parte del proceso de pruebas de software de un proyecto, que también utiliza

técnicas tales como evaluaciones, inspecciones y tutoriales. La validación es el proceso de

comprobar que lo que se ha especificado es lo que el usuario realmente quería.

Se trata de evaluar el sistema o parte de este durante o al final del desarrollo para

determinar si satisface los requisitos iniciales.

Características:

Comprobar que se satisfacen los requisitos:

 Se utilizan las mismas técnicas, pero con otro objetivo.

 No hay programas de prueba, sino sólo del código final de la aplicación.

 Se prueba el programa completo.

 Uno o varios caso de prueba de cada requisito o caso de uso especificado.

 Se prueba también rendimiento, capacidad, etc. (y no sólo resultados correctos).

  Pruebas alfa (desarrolladores) y beta (usuarios).

Prueba del sistema: Definición y características

Las pruebas del sistema tienen como objetivo instruir profundamente el sistema

comprobando la integración del sistema de información globalmente, verificando el

funcionamiento correcto de las interfaces entre los distintos subsistemas que lo componen y con el

resto de sistemas de información con los que se comunica.

Son pruebas de integración del sistema de información completo, y permiten probar el

sistema en su conjunto y con otros sistemas con los que se relaciona para verificar que las

especificaciones funcionales y técnicas se cumplen. Dan una visión muy similar a su

comportamiento en el entorno de producción.

Características:

La prueba de sistema es compleja porque intenta validar un número de características al

mismo tiempo, a diferencia de otras pruebas que sólo se centran en uno o dos aspectos del sistema

al mismo tiempo.

Ejecute cada caso de uso, flujo básico o función utilizando datos válidos e inválidos, para
verificar que:

 Los resultados esperados ocurren cuando se utiliza un dato válido.

 Los mensajes de error o de advertencia aparecen en el momento adecuado,

cuando se utiliza un dato inválido.

 Cada regla de negocios es aplicada adecuadamente.

Conclusión
 En lo ya descrito en este trabajo, se pudo observar lo fundamental que es hacer una
verificación al software y que está sujeta a una serie de pruebas que hay que tomar a consideración,
todo ese proceso se lleva acabo ¿Con que tipo de finalidad? Simple, para poder cumplir con los
requisitos necesarios que tiene el cliente respecto al proyecto a realizarse.

A través de este desarrollo, pude detallar que una prueba de la caja blanca es una prueba
que se centra en la estructura interna del programa, en este caso, la prueba consiste en probar todos
los posibles caminos de ejecución a través de las instrucciones del código, que puedan trazarse.
Ella está compuesta por otras pruebas que son: Prueba del camino básico, prueba de bucles y
pruebas de condiciones.

Ahora, enfoquémonos en la prueba de la casa negra ¿En qué consiste? Consiste en estudiar
la especificación de las funciones, la entrada y la salida para proceder los casos y justo, como la
caja blanca, esta tiene también otros tipos de pruebas que son: Prueba de partición equivalente y
prueba de análisis de valores límites.

También están las pruebas de estrategias para el software, en él se consigue: La prueba de

unidad que por definición, dichas pruebas cubren las funcionalidades propias del módulo tanto con

una perspectiva de caja blanca como de caja negra; pero prestando poca o ninguna atención a la

integración con otros módulos. En la prueba de integración es una metodología de prueba de

software utilizada para probar componentes de software individuales o unidades de código. Las

pruebas de validación en la ingeniería de software son el proceso de revisión que verifica que el

sistema de software producido cumple con las especificaciones y logra su cometido. Las pruebas

del sistema tienen como objetivo instruir profundamente el sistema comprobando la integración del

sistema de información globalmente, verificando el funcionamiento correcto de las interfaces entre

los distintos subsistemas que lo componen.

Como pudo observar, es importante hacer pruebas para poder validar el sistema y llevar a

cabo el cumplimiento de requisitos para el cliente.