República Bolivariana de Venezuela

Ministerio del Poder Popular para la Defensa

Universidad Nacional Experimental Politécnica de la
Fuerza Armada Nacional Bolivariana
Núcleo Sucre – Extensión Carúpano
Ingeniería de Sistemas, Semestre VII

MANUAL DE ELABORACIÓN DE PRUEBAS.

Totora: Autor:

Ing. Evelyn Gil Br. Juan Molina

C.I. 26925382

Carúpano, Noviembre-2020
 ÍNDICE

Pág.

INTRODUCCIÓN………………………………………………………….. 01

OBJETIVOS………………………………………………………………… 02

CONCEPTOS BÁSICOS…………………………………………………... 03

1. Sistema 03
informático…………………………………………………...

2. Etapas de desarrollo de un sistema 03

informático……………………..

3. Pruebas del sistema…………………………………………………... 03

4. Diseño de casos de 03
pruebas…………………………………………...

5. Tipos de 04
pruebas………………………………………………………

6. Pruebas de caja 04
blanca………………………………………………..

7. Pruebas de camino básico……………………………………………. 04

8. Pruebas de estructura de 04
control……………………………………..
 9. Pruebas de caja 04
negra…………………………………………………

10. Pruebas de 04
entornos………………………………………………….

PROCEDIMIENTOS………………………………………………………. 06

1. Pruebas de caja 06
blanca………………………………………………..

2. Pruebas de camino básico……………………………………………. 06

3. Pruebas de estructura de 06
control……………………………………..

4. Pruebas de caja 07
negra…………………………………………………

5. Pruebas de 08
entorno……………………………………………………

EJEMPLOS…………………………………………………………………. 09

1. Pruebas de caja 09
negra………………………………………………....

2. Pruebas de caja 10
blanca………………………………………………..
 INTRODUCCIÓN

Con el crecimiento de la industria tecnológica, cada día más y más personas

adquieren artefactos eléctricos, por lo que la demanda de los mismos ha aumentado
significativamente. Es por eso que se hace necesario desarrollarlos y distribuirlos a
gran escala y ofreciendo productos de calidad óptima. Sin embargo, esto no solo
sucede con los electrodomésticos, sino que también con las aplicaciones informáticas,
programas que facilitan el procedimiento administrativo y operacional en el entorno
empresarial y personal.

¿Cómo lograr que un producto sea de calidad óptima? En el caso de los programas
informáticos, así como también sucede en los productos electrodomésticos, una vez
finalizada su construcción (codificación), es necesario someterlo a una serie de
pruebas para certificar su funcionamiento. Estas son muy útiles para la comprobación
de posibles errores, además, también sirven para retener errores que causen un mal
funcionamiento para componentes posteriores dentro del sistema.

En este manual el usuario puede conocer qué es una pruebas, cuáles son sus tipos,
algunos paso a paso y ejemplos de los mismos.

1
 OBJETIVOS

El objetivo de este manual es instruir al usuario sobre cómo hacer una prueba a un
sistema informático, de tal manera que pueda capacitarse en la materia. Es importante
especificar que dichas pruebas deben hacerse al sistema en cuestión con
detenimiento, ya que las pruebas certificarán el correcto funcionamiento del mismo.

Este manual está diseñado con el propósito de informar sobre conceptos y

procedimientos a las personas inexpertas, para que puedan desarrollar sus
conocimientos con respecto al diseño de las pruebas del sistema.

Se pretende ofrecer el conocimiento necesario para someter a un sistema

informático por lo menos al mínimo de pruebas requeridas para la validación del
mismo.

2
 CONCEPTOS BÁSICOS

1. Sistema informático.

Un sistema informático es una herramienta digital capaz de optimizar los procesos

administrativos y operacionales de una empresa u organización. En su mayoría
capaces de almacenar grandes cantidades de datos, procesarlos y mostrar información
cuando sea necesario.

2. Etapas de desarrollo de un sistema de información.

El desarrollo de un sistema consta de varias etapas, el análisis, el diseño y la

implantación, de esa manera, una vez está construido, el sistema debe someterse a
una serie de pruebas, que forman parte del proceso de implantación, para poder
asegurar que no existan errores y el sistema esté optimizado.

3. Pruebas del sistema.

Las pruebas del sistema sirven para “ejercitarlo”, de tal manera que haga visible
sus vulnerabilidades y fallas, desde su creación hasta su puesta en producción. Lo
interesante de las pruebas es que se puedan ejecutar de manera automática, para
determinar en cualquier momento si tenemos una aplicación estable o si, por el
contrario, un cambio en una parte ha afectado a otras partes sin que nos demos
cuenta.

4. Diseño de casos de pruebas.

De esa manera el diseño de los casos de pruebas son el conjunto de entradas,

condiciones de ejecución y resultados esperados para satisfacer un objetivo concreto,
el cual es tener la mayor probabilidad de encontrar el mayor número de errores con la

3
mínima cantidad de esfuerzo y tiempo posible. Los casos de pruebas se basan en la
explotación de los distintos escenarios de ejecución de los casos de uso; en un
diagrama de actividad.

5. Tipos de pruebas.

Entre los distintos tipos de pruebas, están:

5.1. Caja blanca: se realiza sobre las funciones internas de un módulo, se

centran en los detalles procedimentales del software, por lo que su diseño
está fuertemente ligado al código fuente. Más prácticamente, son pruebas
en las que se certifica que el código fuente se ejecute todo, y que en el
mismo no halla errores.
5.2. Camino básico: permite obtener una medida de la complejidad lógica de
un diseño y usar esta medida como guía para la definición de un conjunto
básico. Básicamente, se prepara un grafo de control en base al código
fuente o el diseño del sistema, se calcula la complejidad del mismo, se
determina el conjunto básico de caminos, y se ejecutan los mismos.
5.3. Estructura de control: permiten modificar el flujo de ejecución de las
instrucciones de un programa. Puede ejecutar el código del mismo de
acuerdo a su función, al valor de sus variables, o mientras se cumpla una
condición, o hasta que se cumpla una condición o un número determinado
de veces.
5.4. Caja negra: se estudia desde el punto de vista de las entradas que recibe y
las salidas que produce, sin tener en cuenta su funcionamiento interno, es
decir, se estudia el entorno que le rodea. Se refiere a un sistema cuyo
interior no puede ser descubierto, cuyos elementos internos son
desconocidos y que sólo puede conocerse “por fuera”, a través de
manipulaciones externas o de observación externa.

4
5.5. Entornos: Es principalmente el conjunto de variables que definen o
controlan determinados aspectos de la ejecución del proceso. Sus
elementos son el inicio, los módulos y los íconos, nos permiten interactuar
con el usuario. Es decir, es el interfaz de usuario.

5
 PROCEDIMIENTOS

1. Pruebas de caja blanca.

Para someter al sistema a una prueba de caja blanca se deben seguir los siguientes
pasos:

a. Se debe establecer un escenario, es decir, seleccionar un caso de uso del

sistema, para ejecutarlo.
b. Una vez seleccionado el escenario, se debe seguir e inspeccionar la
ejecución a nivel de código fuente del sistema.
c. Con el seguimiento, determinar si se cumple el caso de uso establecido, y si
las líneas de código son ejecutadas correctamente.
d. Con los resultados, el equipo desarrollador puede cerciorarse de la
funcionalidad de todas las líneas de código, pudiendo descartar las que no
sean necesarias.

Usualmente, este tipo de prueba debe hacerse con todos y cada uno de los casos de
uso del sistema. De tal manera que pueda inspeccionarse todo el código fuente del
mismo.

2. Pruebas de camino básico.

Para someter al sistema a una prueba de camino básico se deben seguir los
siguientes pasos:

Este tipo de prueba es una derivación de las pruebas de caja blanca, ya que se
enfoca en la revisión del código, solo que en este caso se debe seguir un orden lógico
en la ejecución de las sentencias del programa, de acuerdo a los casos de usos del
mismo

6
 a. Construir un grafo de flujo asociado, con el cual se obtendrán todos los
posibles caminos del programa.
b. Calcular la complejidad ciclomática del grafo, con la cual se sabrá la
complejidad de del programa y cuán severa debe ser la revisión.
c. Una vez se tiene el grafo y la complejidad ciclomática, se debe determinar el
conjunto básico de caminos independientes.
d. Entonces se puede saber cuáles son los casos de prueba que hacen ejecutar a
cada camino del grafo.
e. Analizar los datos obtenidos, para certificar que todos los caminos sean
ejecutados.
3. Pruebas de estructura de control.

Las pruebas de estructura de control se dividen en 3 partes, y para someter al

sistema a una prueba de estructura de control se deben seguir los siguientes pasos:

a. Prueba de condición: en esta parte es debe estudiar cada una de las

condiciones del programa y su propósito es detectar los errores en las
condiciones del mismo y los errores globales que estos generan.
b. Prueba de flujo de datos: se deben seleccionar los caminos de prueba de un
programa de acuerdo a la ubicación de las definiciones y los usos de las
variables del programa.
c. Pruebas de bucles: se deben analizar las construcciones de bucles, como los
bucles simples, los anidados y los concatenados para certificar que funcionen
adecuadamente.
4. Pruebas de caja negra.

Para someter al sistema a una prueba de caja negra se deben seguir los siguientes
pasos:

7
 a. Se debe establecer un escenario en el cual se presente un caso de uso del
sistema, definiendo cuáles son los datos de entrada y los posibles casos de
familia.
b. Ingresar al sistema los datos de entrada establecidos.
c. Analizar los datos de salido producidos por el sistema, sin importar su
funcionamiento interno.
d. Determinar si los datos de salida corresponden con la funcionalidad del
sistema
5. Pruebas de entorno.

Para realizar esta prueba simplemente debe usarse el entorno gráfico de software,
con la intención de observar las incongruencias y errores gráficos que pueda presentar
el programa

8
 EJEMPLOS

1. Caja negra.
a. Descripción del caso: los pedidos de compra que excedan el monto
establecido en el flujo de liberaciones de pedidos configurados, deberán
pasar por las aprobaciones establecidas en dicho flujo de aprobación.
b. Técnica de pruebas de caja negra: requerimiento funcional / caso de uso.
c. Caso 2.1:
 Datos de entrada: pedido de compra con un monto inferior al primer
límite de aprobación configurado.
 Resultado esperado (Salida): el sistema registra el pedido con estatus
“aprobado”.
d. Caso 2.2:
 Datos de entrada: pedido de compra con un monto superior al primer
límite de aprobación configurado.
 Resultado esperado (Salida): el sistema coloca el pedido con estado
“pendiente de aprobación” y lo clasifica en la bandeja de entrada del
aprobador. El aprobador puede configurarse en el sistema (usando el
nombre de usuario).
e. Caso 2.3:
 Datos de entrada: modificar el límite de aprobación y registrar un
pedido de compra con un monto inferior al nuevo límite.
 Resultado esperado (Salida): el sistema registra el pedido con estatus
“aprobado”.
f. Caso 2.4:

9
  Datos de entrada: modificar el límite de aprobación y registrar un
pedido de compra con un monto superior al nuevo límite.
 Resultado esperado (Salida): el sistema coloca el pedido con estado
“pendiente de aprobación” y lo clasifica en la bandeja de entrada del
aprobador. El aprobador puede configurarse en el sistema (usando el
nombre de usuario).
2. Camino básico.
a. Descripción del caso: se tiene un software simple de conteo de palabras, al
cual se le debe aplicar una prueba de camino básico:

El camino básico para este caso está en la siguiente página.

10
11