CONTENIDO

1 Pruebas de software ............................................................................................................ 2

1.1 PRUEBA ................................................................... Error! Bookmark not defined.

2 CLASIFICACION DE LAS PRUEBAS ............................................................................ 2

2.1 BASADA EN ESPECIFICACIÓN – CAJA NEGRA .............................................. 23

Partición de equivalencia o clases de equivalencia .......................................................... 29

Análisis de valores Límites (AVL) .................................................................................. 30

Tabla de decisiones .......................................................................................................... 31

Grafos de causa- efecto .................................................................................................... 34

Casos de uso ..................................................................................................................... 35

Basada en estructura (Caja Blanca) ...................................................................................... 23

1 PRUEBAS DE SOFTWARE

1.1 ANTECEDENTES

La primera referencia a las Pruebas de Software puede ser rastreada a 1950, pero fue
recién en 1957 que la prueba fue distinguida del debugging [Het88]. Dijkstra en 1970
presentaba una importante limitación, que “La Prueba de Software puede ser usada para mostrar
la presencia de bugs, pero nunca su ausencia” (Dijkstra, 1970)

Myers en su segunda edición del libro “The art of Software testing” del año 2004, que
fue publicado originalmente en 1979, comenta el hecho de que, en el tiempo transcurrido entre
una edición y otra, la prueba de software no se ha convertido en una ciencia exacta, y que está
lejos de eso. De hecho, parece que se sabe mucho menos sobre la prueba de software, que sobre
cualquier otro aspecto relacionado con el desarrollo de software. La prueba continúa estando
entre las “artes oscuras” del desarrollo de software (Myers, 2004)

1.2 DEFINICIÓN
Se ha ido cambiando la percepción de que las pruebas de software se realizan únicamente al
final del proceso de creación de código fuente, siendo muy útil hacerlo de todas las etapas del
desarrollo del software; esto permite corregir errores y detectar fallas de fondo, a tiempo.

Existen muchas definiciones de pruebas de software. A continuación, se hace referencia a la

definición citada por IEEE y SWEBOK.

Una prueba es una actividad en la que un sistema o un componente es ejecutado bajo

condiciones especificadas, los resultados son observados o registrados, y una evaluación es
realizada de un aspecto del sistema o componente (IEEE, 1990)

Una prueba es una actividad ejecutada para evaluar y mejorar la calidad del producto a través
de la identificación de defectos y problemas. (SWEBOK, 2014)

Las pruebas de software, en inglés “Testing” son los procesos que permiten verificar y revelar
la calidad de un producto Software. Son utilizadas para identificar posibles fallos de
implementación, Calidad, o usabilidad de un producto de un programa de ordenador o un
videojuego. (Tecnology, 2016)
1.3 IMPORTANCIA DE PRUEBAS
Hoy en día, forman parte de nuestras vidas multitud de sistemas que contienen software, como
por ejemplo los coches, smartphones, sistemas de producción de energía, programas bancarios,
etc.

La importancia de la detección oportuna

En la cadena de valor del desarrollo de un software específico, el proceso de prueba es clave a

la hora de detectar errores o fallas. Conceptos como estabilidad, escalabilidad, eficiencia y
seguridad se relacionan a la calidad de un producto bien desarrollado. Las aplicaciones de
software han crecido en complejidad y tamaño, y por consiguiente también en costos. Hoy en
día es crucial verificar y evaluar la calidad de lo construido de modo de minimizar el costo de
su reparación. Mientras antes se detecte una falla, más barata es su corrección.

El proceso de prueba es un proceso técnico especializado de investigación que requiere de

profesionales altamente capacitados en lenguajes de desarrollo, métodos y técnicas de pruebas
y herramientas especializadas. El conocimiento que debe manejar un ingeniero de prueba es
muchas veces superior al del desarrollador de software.

1.4 OBJETICO DE LAS PRUEBAS

El objetivo principal de las pruebas es aportar calidad al producto que se está desarrollando.

Calidad:

Este término es definido por muchas organizaciones e ilustres en el mundo de la calidad de

formas diferentes:

 ISO 9000 es un conjunto de normas sobre calidad y gestión de calidad, la define

como “la calidad es el grado en el que un conjunto de características inherentes cumple
con los requisitos”
 ISO 25000 es un conjunto de normas que tiene por objetivo la creación de un
marco de trabajo común para evaluar la calidad del producto software, dice: “ la calidad
es el grado en que el producto de software satisface las necesidades expresadas o
implícitas, cuando es usado bajo condiciones determinadas”.
 Philip Bayard Crosby, que contribuyó a las prácticas de la gestión de la calidad, la
define como “Conformidad con los requisitos”.
  Armand V. Feigenbaum, que diseñó el concepto del control total de la calidad, la
define como “satisfacción de las expectativas del cliente”.
 Genichi Taguchi, que desarrolló una metodología para la aplicación de estadísticas
para mejorar la calidad de los productos manufacturados, dice: “calidad es
la pérdida (monetaria) que el producto o servicio ocasiona a la sociedad desde que es
expedido”

Hay dos puntos principales que tienen casi todas las definiciones de calidad: la satisfacción del
cliente y el cumplimiento de los requisitos del producto.

Pruebas y el ciclo de vida del Software:

Las pruebas de software se integran dentro de las diferentes fases del ciclo de vida del software
dentro de la Ingeniería de software. En este sentido, se ejecuta el aplicativo a probar y mediante
técnicas experimentales se trata de descubrir qué errores tiene.

1.5 PAPEL DE LAS PRUEBAS

El Testing juega un papel importante en el logro y la evaluación de la calidad de un producto
de Software. Por un lado, mejoramos la calidad de los productos como repetimos un test–find
defects–fix (prueba para encontrar defectos y corregirlos) durante el desarrollo. Por otro lado,
evaluamos lo bueno que nuestro sistema es cuando llevamos a cabo pruebas a nivel de sistema
antes de lanzar un producto. Por lo tanto, como (SANDEEP DESAI, 2012) han descrito de
manera sucinta, las pruebas de software es un proceso de verificación para la evaluación y
mejora de la calidad del software. En términos generales, las actividades para la evaluación de
la calidad del software se pueden dividir en dos amplias categorías, a saber, el análisis estático
y análisis dinámico.

1.6 VERIFICACIÓN VALIDACIÓN

Dos conceptos similares relacionados con las pruebas de software de uso frecuente son la
verificación y validación. Ambos conceptos son abstractos en la naturaleza, y cada uno puede
ser realizado por un conjunto de actividades concretas, ejecutables. Los dos conceptos se
explican como sigue:

Verificación: Este tipo de actividad nos ayuda en la evaluación de un sistema de software

determinando si el producto de una determinada fase de desarrollo satisface los requisitos
establecidos antes del inicio de esa fase. Se puede observar que un producto puede ser un
producto intermedio, como requisito especificación, especificaciones de diseño, código, manual
de usuario, o incluso el producto final. Las actividades que comprueban la corrección de
una fase de desarrollo se denominan actividades de verificación.

Validación: Este tipo de actividades nos ayudan a confirmar que un producto cumple con su
uso previsto. Las actividades de validación tienen por objeto confirmar que un producto cumple
con las expectativas de sus clientes. En otras palabras, las actividades de validación se centran
en el producto final, que se prueba ampliamente desde el punto de vista del cliente. La
validación establece si el producto cumple con las expectativas generales de los usuarios.

Las actividades de validación son a menudo arriesgadas por lo que aumenta los costes de
desarrollo. Pueden ser ejecutadas en las primeras etapas del ciclo de desarrollo de software. Un
ejemplo de actividades de validación se puede encontrar en la metodología de desarrollo de
software XP. En la metodología XP, el cliente interactúa estrechamente con el grupo de
desarrollo de software y lleva a cabo las pruebas de aceptación durante cada iteración de
desarrollo.

El proceso de verificación establece la correspondencia de una fase de ejecución del proceso de

desarrollo de software con su especificación, mientras que la validación se establece la
correspondencia entre un sistema y expectativas de los usuarios. Uno puede comparar la
verificación y la validación de la siguiente manera:
Las actividades de verificación apuntan a confirmar que se está construyendo el producto
correctamente, mientras que las actividades de validación tienen por objeto confirmar que se
está construyendo el producto correcto

1.7 ERROR, DEFECTO O FALLA

Se utilizan distintos términos en la bibliografía para distinguir entre la causa de un mal
funcionamiento en el sistema, que es percibida por los desarrolladores y la observación de ese
mal funcionamiento, que es percibida por quien usa el sistema.

En este trabajo se usará la definición de cuando se hace referencia a los términos error, falta o

defecto y falla:

Con estas definiciones, un defecto es una visión interna del sistema, desde la óptica de los
desarrolladores, una falla es una visión externa del sistema, o sea un problema que ve el usuario.
No todos los defectos corresponden a una falla. Por ejemplo: si un trozo de código defectuoso
nunca se ejecuta, el defecto nunca provocará la falla del código.

La Prueba puede revelar fallas, pero son las faltas las que pueden y deben ser removidas.

Para terminar de entender las pruebas debemos diferenciar los términos error, fallo y defecto.
Estos conceptos están relacionados entre sí, pero tienen significados diferentes. Para
comprender estas palabras y por ende las pruebas, vamos a ver como las define el ISTQB (El
Comité internacional de calificación de pruebas de software) (International Software Testing
Qualifications Board) realiza un glosario de términos de prueba de software estándar

“Una persona puede cometer un error que a su vez puede producir un defecto en el código de
programa o en un documento. Si se ejecuta un defecto en el código, el sistema puede no hacer
lo que debiera (o hacer algo que no debiera), lo que provocaría un fallo. Algunos defectos de
software pueden dar lugar a fallos, pero no todos los defectos lo hacen.”

Así pues, tenemos:

Error: está provocado por la acción humana, por ejemplo, el error lo provocará el
desarrollador que realizará una incorrecta interpretación de un método del programa que
producirá un resultado no esperado.
 Defecto: Provocado por un error de implementación, por ejemplo, el defecto lo
provocará el haber utilizado el operador “x + y > z” en vez de “x + y => z”

Fallo: al ejecutar el programa con un defecto obtendremos resultados no

deseados, por ejemplo, cuando el resultado de la suma de los dos componentes fuese
igual, no obtendríamos los mismos resultados al compararlos con las
sentencias indicadas anteriormente. En sistemas muy complejos, como pueden ser
una lanzadera espacial o una central eléctrica, pueden llegar a producir efectos
catastróficos.

2 NIVELES DE PRUEBA DE SOFTWARE

3 TIPOS PRUEBAS DE SOFTWARE

3.1 Prueba Unitaria

3.1.1 Prueba Unitaria

Tiene como objetivo realizar la prueba a cada unidad mínima a ser probada lo que permite un
mejor modo de manejar la integración de las unidades en los componentes mayores, así mismo
busca asegurar que el código funcione de acuerdo a las especificaciones y que el modulo lógico
sea válido.
Se caracteriza por lo siguiente:

 Particionar los módulos en unidades lógicas fáciles de probar.

 Por cada unidad de prueba es necesario definir los casos (pruebas de caja blanca)

 Las pruebas se diseña de tal forma que recorran la ejecución de todos los caminos
posibles dentro del código, por lo que es necesario que diseñador tenga acceso al
código fuente.

 Se consideran los siguientes aspectos Rutinas de excepción, Rutinas de error,

Manejo de parámetros, Validaciones, Valores válidos, Valores límites, Rangos,
Mensajes posible

 Permite compara el resultado esperado con el resultado obtenido y si existen errores

reportarlos.

3.2 Pruebas de Integración

3.2.1 Prueba de Integración

Identificar errores introducidos por la combinación de programas probados unitariamente, asi

mismo determina cómo la base de datos de prueba será cargada.

Verificar que las interfaces entre las entidades externas (usuarios) y las aplicaciones funcionan
correctamente y que las especificaciones de diseño sean alcanzadas.

Se caracteriza por lo siguiente:

 Describe cómo verificar que las interfaces entre las componentes de software funcionan
correctamente.
 Determina cómo la base de datos de prueba será cargada.
 Determina el enfoque para avanzar desde un nivel de integración de las componentes al
siguiente.
 Decide qué acciones tomar cuando se descubren problemas.
3.2.2 Prueba de Regresión

Determinar si los cambios recientes en una parte de la aplicación tienen efecto adverso
en otras partes.

En esta prueba se vuelve a probar el sistema a la luz de los cambios realizados durante
el debugging, mantenimiento o desarrollo de la nueva versión del sistema buscando
efectos adversos en otras partes.

Se caracteriza por lo siguiente:

 La prueba de regresión es una nueva corrida de casos de prueba previos.

 Se requiere de políticas para ser creada la prueba de regresión y decidir qué casos
de prueba incluir, para probar eficientemente.
 La prueba de regresión es un buen candidato para automatización. Desde que estas
pruebas se repiten una y otra vez, las herramientas para minimizar el esfuerzo del
trabajo son útiles.
 La prueba de viejas funcionalidades es más importante que la de nuevas
funcionalidades.
 Aquellos casos de uso (y los casos de prueba asociados) que descubren defectos
tempranamente deben ser incluidos en la prueba de regresión.

3.2.3 Pruebas de Humo (Smoke Testing o Ad Hoc)

Permite detectar errores en versiones tempranas y de manera fácil y constante probar el

sistema garantizando poco esfuerzo en la integración final del sistema.

Asegura los resultados de las prueba unitarias reduciendo el riesgo y a abaja calidad.

Recibe este nombre debido a que tiene como objetivo probar el sistema constantemente
buscando que saque humo o falle , en algunos proyectos va junto con las pruebas
funcionales. Permite detectar problemas que por lo regular no son detectadas en las
pruebas normales, Si ocurren tarde en el ciclo de desarrollo serán un forma de garantizar
un buen desarrollo.

Estas pruebas no son exhaustivas, pero van de extremo a extremo de la aplicación y

permite realizar una integración de todo el sistema cada cierto periodo (se recomienda
un día, máximo una semana).
 Realizar los casos de prueba asignados a los casos de uso finalizados ese día más los
realizados en días anteriores lo cual permite buscar eficientemente errores

3.3 Pruebas del Sistema

3.3.1 Prueba de Sistema

Asegurar la apropiada navegación dentro del sistema, ingreso de datos, procesamiento

y recuperación.

Las pruebas del sistema deben enfocarse en requisitos que puedan ser tomados
directamente de casos de uso y reglas y funciones de negocios. El objetivo de estas
pruebas es verificar el ingreso, procesamiento y recuperación apropiado de datos, y la
implementación apropiada de las reglas de negocios. Este tipo de pruebas se basan en
técnicas de caja negra, ésto es, verificar el sistema (y sus procesos internos), la
interacción con las aplicaciones que lo usan via GUI y analizar las salidas o resultados.

En esta prueba se determina qué pruebas de Sistema (usabilidad, volumen, desempeño,

etc.) asegurarán que la aplicación alcanzará sus objetivos de negocio.

La prueba de Sistema incluye:

 Prueba funcionalidad
 Prueba de Usabilidad
 Prueba de Performance
 Prueba de Documentación y Procedimientos
 Prueba de Seguridad y Controles
 Prueba de Volumen
 Prueba de Esfuerzo (Stress)
 Prueba de recuperación
 Prueba de múltiples sitios

Para sistemas web se recomienda especialmente realizar mínimo el siguiente grupo de

pruebas de sistema:

 Humo.
 Usabilidad
 Performance
 Funcionalidad
 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.

3.3.2 Pruebas de Desempeño

Validar el tiempo de respuesta para las transacciones o funciones de negocios bajo las
siguientes dos condiciones:

 Volumen normal anticipado

 Volumen máximo anticipado.

Las pruebas de desempeño miden tiempos de respuesta, índices de procesamiento de

transacciones y otros requisitos sensibles al tiempo. El objetivo de las pruebas de
desempeño es verificar y validar los requisitos de desempeño que se han especificado
(en este caso, el desempeño ofrecido por el proponente).

Las pruebas de desempeño usualmente se ejecutan varias veces, utilizando en cada una,
carga diferente en el sistema. La prueba inicial debe ser ejecutada con una carga similar
a la esperada en el sistema. Una segunda prueba debe hacerse utilizando una carga
máxima.

Adicionalmente, las pruebas de desempeño pueden ser utilizadas para perfilar y refinar
el desempeño del sistema como una función de condiciones tales como carga o
configuraciones de hardware

Las principales actividades son:

 Comparar el desempeño del sistema actual con los requisitos,

 Poner a punto el sistema para mejorar las métricas de desempeño y proyectar la
capacidad futura de carga del sistema.

Los objetivos de nivel de servicio definidos deben guiar la prueba de performance.

Algunas características que afectan el desempeño son:

 Errores lógicos
 Procesamiento ineficiente
 Diseño pobre: muchas interfases, instrucciones y entradas/salidas.
 Cuellos de botella en discos, CPU ó canales de entrada/salida
 Salidas del sistema
 Tiempos de respuesta
 Capacidad de almacenamiento
 Tasa de entrada/salida de datos
 Número de transacciones que pueden ser manejadas simultáneamente.

Las pruebas de desempeño utilizan las técnicas de caja blanca y caja negra.
3.3.3 Pruebas de Carga

Verificar el tiempo de respuesta del sistema para transacciones o casos de uso de negocios,
bajo diferentes condiciones de carga.

Las pruebas de carga miden la capacidad del sistema para continuar funcionando
apropiadamente bajo diferentes condiciones de carga.

La meta de las pruebas de carga es determinar y asegurar que el sistema funciona

apropiadamente aún más allá de la carga de trabajo máxima esperada. Adicionalmente, las
pruebas de carga evalúan las características de desempeño (tiempos de respuesta, tasas de
transacciones y otros aspectos sensibles al tiempo).

En esta prueba se usa el scrip de los desarrolladores para las pruebas de negocios las
cuales se modifica para incrementa el número de transacciones las cuales debe ser
utilizadas por múltiples de usuarios.

Estas pruebas debe ser ejecutadas en máquinas dedicadas o en un tiempo dedicado, asi
mismo la base de datos de prueba debe ser de igual tamaño o mayor que la diseñada.

3.3.4 Pruebas de Strees

Verifica que el sistema funcione apropiadamente bajos las siguientes condiciones

 Memoria baja o no disponible en el servidor

 Máximo número de clientes conectados o simulados

 Múltiples usuarios realizan la misma transacción y con los mismos datos

 El Peor caso de volumen de transacción (Pruebas de desempeño)

Esta prueba ayuda a identificar y documentar bajo que condiciones FALLA el sistema.

Las pruebas de stress se proponen encontrar errores debidos a recursos bajos o

completitud de recursos. Poca memoria o espacio en disco puede revelar defectos en el
sistema que no son aparentes bajo condiciones normales. Otros defectos pueden resultar
de incluir recursos compartidos, como bloqueos de base de datos o ancho de banda de
la red. Las pruebas de stress identifican la carga máxima que el sistema puede manejar.

El objetivo de esta prueba es investigar el comportamiento del sistema bajo condiciones

que sobrecargan sus recursos. No debe confundirse con las pruebas de volumen: un
 esfuerzo grande es un pico de volumen de datos que se presenta en un corto período de
tiempo.

Puesto que la prueba de esfuerzo involucra un elemento de tiempo, no resulta aplicable

a muchos programas, por ejemplo a un compilador o a una rutina de pagos.

Es aplicable, sin embargo, a programas que trabajan bajo cargas variables, interactivos,
de tiempo real y de control de proceso.

Aunque muchas pruebas de esfuerzo representan condiciones que el programa

encontrará realmente durante su utilización, muchas otras serán en verdad situaciones
que nunca ocurrirán en la realidad. Esto no implica, sin embargo, que estas pruebas no
sean útiles.

Si se detectan errores durante estas condiciones “imposibles”, la prueba es valiosa

porque es de esperar que los mismos errores puedan presentarse en situaciones reales,
algo menos exigentes.

Se caracteriza por lo siguiente:

 Usa los scripts utilizados en las pruebas de desempeño.

 Para probar recursos limitados, las pruebas se deben correr en un servidor con
configuración reducida (o limitada).
 Para las pruebas de stress restantes, deben utilizarse múltiples clientes, ya sea
corriendo los mismos scripts o scripts complementarios para producir el peor caso
de volumen de transacciones.

Al realizar estas pruebas se debe considera que producir stress en la red puede requerir
herramientas de red para sobrecargarla de tráfico y el espacio en disco utilizado para el
sistema debe ser reducido temporalmente para limitar el espacio disponible para el
crecimiento de la Base de datos y requiere sincronización de varios clientes accediendo
simultáneamente los mismos registros.

3.3.5 Pruebas de Volumen

Permite verificar que la aplicación funciona adecuadamente bajo los siguientes

escenarios de volumen:

 Máximo (actual o físicamente posible) número de clientes conectados (o simulados),

todos ejecutando la misma función (peor caso de desempeño) por un período
extendido.
 Máximo tamaño de base de datos (actual o escalado) y múltiples consultas
ejecutadas simultáneamente

Las pruebas de volumen hacen referencia a grandes cantidades de datos para determinar
los límites en que se causa que el Sistema falle. También identifican la carga máxima o
volumen que el sistema puede manejar en un período dado. Por ejemplo, si el sistema
está procesando un conjunto de registros de Base de datos para generar un reporte, una
 prueba de volumen podría usar una Base de datos de prueba grande y verificar que el
sistema se comporta normalmente y produce el reporte correctamente.

El objetivo de esta prueba es someter al sistema a grandes volúmenes de datos para

determinar si el mismo puede manejar el volumen de datos especificado en sus
requisitos.

Algunos ejemplos de escenarios de prueba de volúmenes:

 Un compilador puede ser alimentado por un programa para compilar que sea
absurdamente grande.
 Un editor de nexos puede recibir un programa que contenga miles de módulos.
 Un simulador de circuito electrónico puede recibir un circuito diseñado con miles
de componentes.

Puesto que obviamente, la prueba de volumen es una prueba costosa, tanto en tiempo
de máquina como en personal, se debe tratar de no exceder los límites. Sin embargo,
todo programa debería ser expuesto, al menos, a algunas pruebas de volumen.

Se caracteriza por lo siguiente

 Utiliza los scripts diseñados para las pruebas de desempeño.

 Deben usarse múltiples clientes, ya sea corriendo las mismas pruebas o pruebas
complementarias para producir el peor caso de volumen (ver pruebas de stress)
por un período extendido.
 Se utiliza un tamaño máximo de Base de datos. (actual, escalado o con datos
representativos) y múltiples clientes para correr consultas simultáneamente para
períodos extendidos.

Qué período de tiempo debería considerarse como aceptable para condiciones de

volumen alto?

3.3.6 Pruebas de Recuperación y tolerancia a fallas

Verificar que los procesos de recuperación (manual o automática) restauran

apropiadamente la Base de datos, aplicaciones y sistemas, y los llevan a un estado
conocido o deseado. Los siguientes tipos de condiciones deben incluirse en la prueba:

 Interrupción de electricidad en el cliente.

 Interrupción de electricidad en el servidor
 Interrupción en la comunicación hacia el servidor (caídas de red)
 Interrupción en la comunicación con los controladores de disco.
 Ciclos incompletos (procesos de consultas interrumpidos, procesos de
sincronización de datos interrumpidos)
  Llaves o apuntadores de base de datos inválidos
 Elementos corruptos o inválidos en la base de datos.

Estas pruebas aseguran que una aplicación o sistema se recupere de una variedad de
anomalías de hardware, software o red con pérdidas de datos o fallas de integridad.

Las pruebas de tolerancia a fallas aseguran que, para aquellos sistemas que deben
mantenerse corriendo, cuando una condición de falla ocurre, los sistemas alternos o de
respaldo pueden tomar control del sistema sin pérdida de datos o transacciones.

Las pruebas de recuperación son contrarias a las pruebas en que la aplicación o sistema
es expuesto a condiciones extremas (o condiciones simuladas), tales como fallas en
dispositivos en entrada/salida o llaves o apuntadores inválidos de base de datos. Los
procesos de recuperación se invocan y la aplicación es monitoreada y/o inspeccionada
para verificar que éstos mecanismos se han ejecutado en forma apropiada.

El objetivo de esta prueba es determinar la habilidad del sistema para recuperarse de una
falla de hardware o software. Esta prueba evalúa las características de contingencia
construidas en el sistema para procesar interrupciones y para volver a puntos específicos
en el ciclo de procesamiento del sistema. La recuperación debe ser considerada en el
proceso de diseño. Errores de programación o de datos pueden ser incorporados ex
profeso en un sistema para determinar si se puede recuperar de ellos. Las fallas de equipo
(por ejemplo errores de paridad en memoria, errores en dispositivos de entrada/salida)
pueden ser simuladas.

3.3.7 Pruebas de Múltiples Sitios

Esta prueba permite detectar fallas de configuración y comunicaciones de datos entre

múltiples sitios , evaluado de esta manera el correcto funcionamiento del sistema o
subsistemas en múltiples instalaciones.

En esta prueba se debe verificar lo siguiente :

 Consistencia de las opciones de configuración para el sistema a través de los sitios

 Empaquetamiento del sistema para múltiples instalaciones
 Sincronización de datos entre sitios
 Comunicación de datos entre sistemas en diferentes sitios
 Rompimiento de funciones de sistema a través de los sitios.
 Consistencia de controles y seguridad a través de los sitios

3.3.8 Pruebas de Compatibilidad y Conversión

 Busca problemas de compatibilidad y conversión de los sistemas, todo sistema no son
completamente nuevos frecuentemente son reemplazo de partes deficiente de sistema
de procesamiento de datos o sistema manuales por tal motivo es necesario evaluar su
compatibilidad y procedimientos con los sistema existentes

3.3.9 Prueba de Integridad de Datos y Base de Datos

Asegurar que los métodos de acceso y procesos funcionan adecuadamente y sin

ocasionar corrupción de datos.

La Base de datos y los procesos de Base de datos deben ser probados como sistemas
separados del proyecto. Estos sistemas deberían ser probados sin usar interfaces de
usuario (como las interfaces de datos). Se necesita realizar investigación adicional en el
DBMS para identificar las herramientas y técnicas que podrían existir para soportar las
pruebas identificadas más adelante.

En esta prueba se invoca cada método de acceso y proceso de la Base de datos,

utilizando en cada uno datos válidos e inválidos y se analiza la Base de datos, para
asegurar que los datos han sido grabados apropiadamente, que todos los eventos de Base
de datos se ejecutaron en forma correcta y revise los datos retornados en diferentes
consultas.

3.3.10 Pruebas de Seguridad y Control de Acceso

Las pruebas de seguridad y control de acceso se centran en dos áreas claves de

seguridad:

 Seguridad del sistema, incluyendo acceso a datos o Funciones de negocios y

 Seguridad del sistema, incluyendo ingresos y accesos remotos al sistema.

Las pruebas de seguridad de la aplicación garantizan que, con base en la seguridad

deseada, los usuarios están restringidos a funciones específicas o su acceso está limitado
únicamente a los datos que está autorizado a acceder.

El objetivo de esta prueba es evaluar el funcionamiento correcto de los controles de

seguridad del sistema para asegurar la integridad y confidencialidad de los datos. El
foco principal es probar la vulnerabilidad del sistema frente a accesos o manipulaciones
no autorizadas. Una manera de encontrar esos casos de prueba es estudiar problemas
 conocidos de seguridad en sistemas similares y tratar de mostrar la existencia de
problemas parecidos en el sistema que se examina.

Algunas consideraciones de prueba son:

 Controles de acceso físico

 Acceso a estructuras de datos específicas a través de los programas de aplicación.
 Seguridad en sitios remotos
 Existencia de datos confidenciales en reportes y pantallas
 Controles manuales, incluyendo aquellos para autorización y aprobación,
formularios, documentación numerada, transmisión de datos, balances y conversión
de datos.
 Controles automáticos, incluyendo aquellos para edición de datos, chequeo de
máquinas, errores del operador, acceso a datos elementales y archivos, acceso a
funciones, auditoría, entre otros.

3.4 Pruebas de Validación de Sistemas a Medida

3.4.1 Pruebas del Ciclo de Negocio

Asegurar que el sistema funciona de acuerdo con el modelo de negocios emulando todos
los eventos en el tiempo y en función del tiempo.

Las pruebas del ciclo de negocio deberían emular las actividades ejecutadas en el a
través del tiempo. Debería identificarse un periodo, como por ejemplo un año, y las
transacciones y actividades que podrían ocurrir durante un periodo de un año deberían
ejecutarse. Incluyendo todos los ciclos y eventos diarios, semanales y mensuales que
sean datos sensitivos, como las agendas.

3.4.2 Pruebas de GUI

Verifica lo siguiente:

 La navegación a través de los objetos de la prueba reflejan las funcionalidades del

negocio y requisitos, se realiza una navegación ventana por ventana, usando los
modos de acceso (tabuladores, movimientos del mouse, teclas rápidas, etc)
 Los objetos de la ventana y características, tales como menús, medidas, posiciones,
estados y focos se verifican conforme a los estándares.

La prueba de interfaz de usuario verifica la interacción del usuario con el software. El

objetivo es asegurar que la interfaz tiene apropiada navegación a través de las diferentes
 funcionalidades. Adicionalmente, las pruebas de interfaz aseguran que los objetos de la
interfaz a ser probada se encuentran dentro de los estándares de la industria

Pruebas de crear / modificar cada ventana para verificar la adecuada navegación y

estado de los objetos.

Cada ventana elegida será totalmente verificada y comparada con similares en el

mercado logrando una buena aceptación dentro del estándar.

3.4.3 Pruebas de Configuración

Validar y verificar que el cliente del sistema funciona apropiadamente en las estaciones
de trabajo recomendadas.

Estas pruebas verifican la operación del sistema en diferentes configuraciones de

hardware y software. En la mayoría de los ambientes de producción, las especificaciones
para las estaciones de trabajo, equipos de red y servidores pueden variar. Las estaciones
pueden tener diferentes versiones de software instaladas (Sistemas Operativos, Drivers,
etc) y en cualquier momento, pueden llegar a utilizarse diferentes combinaciones.

Con frecuencia, el número de configuraciones posibles es demasiado grande para

intentar una prueba de cada una de ellas, pero el programa debe probarse al menos con
cada tipo de dispositivo y con las configuraciones mínima y máxima posibles.

3.4.4 Pruebas de Estilo

Comprobar que la aplicación sigue los estándares de estilo propios del cliente.

Se entienden como tales el formato de las ventanas, colores corporativos, tipos de letra
etc. En esta prueba se realiza una navegación por la aplicación verificando si se cumplen
con los estándares de GUI del cliente validado objetos gráficos contra el manual de
estilos del cliente.

3.4.5 Pruebas de Aceptación

Determinación por parte del cliente de la aceptación o rechazo del sistema desarrollado.
 La prueba de aceptación es ejecutada antes de que la aplicación sea instalada dentro de
un ambiente de producción. La prueba de aceptación es generalmente desarrollada y
ejecutada por el cliente o un especialista de la aplicación y es conducida a determinar
como el sistema satisface sus criterios de aceptación validando los requisitos que han
sido levantados para el desarrollo, incluyendo a documentación y procesos de negocio.

Basado en esta prueba el cliente determina si acepta o rechaza el sistema

Estas pruebas están destinadas a probar que el producto está listo para el uso operativo.
Suelen ser un subconjunto de las Pruebas de Sistema.

Sirve para que el usuario pueda validar si el producto final se ajusta a los requisitos
fijados, es decir, si el producto está listo para ser implantado para el uso operativo en el
entorno del usuario.

Esta prueba es complementada por la prueba de estilo.

Realización de los documentos de planes de prueba de aceptación y especificación de

los mismos, basados en los criterios de aceptación del cliente.

Los casos prueba de aceptación han de ser planificados, organizados y formalizados de

manera que se determine el cumplimiento de los requisitos del sistema. Para la
realización de estas pruebas se necesita disponer de los siguientes documentos:

 Especificación de requisitos del sistema.

 Manual de usuario.
 Manual de administrador.
 Realizar Pruebas de estilo

3.4.6 Prueba de Instalación

Verificar y validar que el sistema se instala apropiadamente en cada cliente, bajo las siguientes
condiciones:

 Instalaciones nuevas, nuevas máquinas a las que nunca se les ha instalado el sistema.
 Actualizar máquinas previamente instaladas con el sistema.
 Instalar versiones viejas en máquinas previamente instaladas con el sistema.

Las pruebas de instalación tienen dos propósitos. El primero es asegurar que el sistema
puede ser instalado en todas las configuraciones posibles, tales como nuevas
instalaciones, actualizaciones, instalaciones completas o personalizadas, y bajo
condiciones normales o anormales; estas últimas incluyen insuficiente espacio en disco,
falta de privilegios para algunas tareas, etc.

El segundo propósito es verificar que, una vez instalado, el sistema opera correctamente.
Esto usualmente implica correr un número significativo de pruebas de Funcionalidad.
3.4.7 Pruebas Funcionales

Se asegura el trabajo apropiado de los requisitos funcionales, incluyendo la navegación,

entrada de datos, procesamiento y obtención de resultados

Las pruebas Funcionales deben enfocarse en los requisitos funcionales, las pruebas
pueden estar basadas directamente en los Casos de Uso (o funciones de negocio), y las
reglas del negocio. Las metas de estas pruebas son:

 Verificar la apropiada aceptación de datos,

 Verificar el procesamiento y recuperación y la implementación adecuada de las
reglas del negocio.

Este tipo de pruebas están basadas en técnicas de caja negra, que es, verificar la
aplicación (y sus procesos internos) mediante la interacción con la aplicación vía GUI
y analizar la salida (resultados). Lo que se identifica a continuación es un diseño
preliminar de las pruebas recomendadas para cada aplicación.

3.4.8 Pruebas de Documentación y Procediemiento

Evaluar la exactitud y claridad de la documentación del usuario y para determinar si el

manual de procedimientos trabajará correctamente como una parte integral del sistema.

Muchos defectos son identificados cuando un probador competente chequea totalmente

los manuales y documentación del usuario.

Muchos programas son parte de sistemas mayores, no completamente automatizados,

que contienen procedimientos realizados por operadores. Cualquier procedimiento
humano, tal como los que llevan a cabo el operador, el administrador de la base de datos,
o el usuario de terminal, debe ser probado durante la prueba de sistemas.

3.4.9 Prueba de Usabilidad

Determina cuán bien el usuario podrá usar y entender la aplicación. Identifica las áreas
de diseño que hacen al sistema de difícil uso para el usuario.

La prueba de usabilidad detecta problemas relacionados con la conveniencia y

practicidad del sistema desde el punto de vista del usuario.

Verificar que la aplicación no presenta los siguientes problemas de usabilidad típicos:

  El sistema es demasiado complejo y difícil de usar.
 Es difícil instalar y entender el sistema
 La recuperación de errores es pobre y los mensajes de error no tienen significado
 La sintaxis de los comandos es difícil de aprender y recordar
 El sistema obliga al usuario a recordar formatos y secuencias fijas
 Los procedimientos no son simples ni obvios
 El sistema no tiene instrucciones de ayuda por computadora y tiene manuales
pobres.
 Los diagramas, pantallas, reportes y gráficos son de calidad y apariencia pobre
 El sistema carece de herramientas de construcción adecuadas y requiere múltiples
comandos
 La lógica y conveniencia de los botones, switches, displays y mensajes de ayuda
deben ser testeados. (La prueba de usabilidad puede ser conducida por un grupo
separado si es posible.

Se deben crear casos de prueba para comprobar que se puede operar en el sistema de
forma adecuada.

3.4.10 Prueba de Campo

Correr el sistema en el ambiente real para encontrar errores y validar el producto contra
sus especificaciones originales.

Realizar un subconjunto válido de pruebas de sistema para determinar que pruebas de

sistema serán corridas para validar el sistema en producción.

3.5 Pruebas de Validación a Aplicaciones Genéricas

3.5.1 Pruebas Alfa

Prueba de aceptación para detectar errores en el sistema bajo un ambiente controlado.

La verificación involucra la ejecución de partes o todo del sistema en ambientes

simulados, con el fin de encontrar errores.

La retroalimentación de esta fase produce cambios en el software para resolver los

errores y fallas que se descubren.

3.5.2 Pruebas Beta

Realizar la validación del sistema por parte del usuario.

Prueba de aceptación donde La validación (o pruebas beta) involucra el uso del software
en un ambiente real.
 Se selecciona un grupo de usuarios que ponen a trabajar el sistema en un ambiente real.
Usan el sistema en sus actividades cotidianas, procesan transacciones y producen salidas
normales del sistema.

Las transacciones y personas que usan el sistema son reales y trabajan en su área de
trabajo real.

El desarrollador no está presente.

Los usuarios están advertidos de que están usando un sistema que puede fallar y puede
realizar realizar pruebas a su antojo realizando uso de la aplicación.

4 ENFOQUE DE DISEÑO DE PRUEBAS

Existe en la bibliografía distintas formas de clasificar los tipos de prueba existentes.

Whittaker en (Whittaker, 2002), propone clasificar la prueba según qué tipo de prueba que se
esté haciendo (funcional o estructural) y según cómo se realiza la prueba (unitaria, de
integración o del sistema). Se hace énfasis en la prueba funcional, debido a que el proceso
definido utiliza ese tipo para probar un producto de software.

El tercer grupo de técnicas de pruebas está basado en la experiencia de la persona que

realiza las pruebas. En la Ilustración 1, se presenta la clasificación de los tres grupos de
técnicas.
 Basada en Basada en
Basadas en
especificación estructura (Caja
experiencia
(Caja negra) Blanca)

Partición de Pruebas de Predicción

equivalencia sentencia de error

Análisis de Pruebas de Pruebas

valores limites decisión Exploratorias

Tabla de Pruebas de
decisión caminos

Grafos de
causa- efecto

Transición de
estados

Casos de uso

Ilustración 1 de Clasificación de Pruebas de Software

4.1 BASADA EN ESTRUCTURA – CAJA BLANCA

1. Basada en estructura (Caja Blanca)

Las técnicas de pruebas basadas en la estructura, como su nombre lo indica, necesitan conocer
la estructura interna de los componentes del sistema, su implementación y la lógica de las
funciones que lleva a cabo, para cubrir los caminos del programa. Por lo tanto el contenido
interno de la aplicación es conocido.

5 Calculadora

+ 1
5

Ilustración 2 Caja Blanca

Los casos de prueba se basan en la implementación del sistema, permitiendo que:

 Se valide que se recorre al menos una vez los caminos independientes de cada módulo
 Se valide todas las decisiones lógicas tanto verdaderas como falsas.
 Se valide todos los bucles del sistema dentro y sobre sus límites operacionales.
 Se validen las estructuras internas de datos, para asegurar su integridad.

Las pruebas de caja blanca son útiles cuando se realizan pruebas en los siguientes niveles:
 • Pruebas de Componentes: Permite validar la estructura de “las sentencias, las
decisiones, las ramas o caminos que se presentan en el componente”.
• Pruebas de integración: Permite validar la estructura por ejemplo de “árbol de
llamadas (un diagrama en el que los módulos llaman a otros módulos)”
• Pruebas de sistema: Permite validar la estructura de los “menús, procesos de negocio
o una estructura de una página web”.

A continuación, en la siguiente Tabla, se presentas las técnicas de caja blanca: Pruebas de

sentencia, pruebas de decisión y pruebas de caminos. La idoneidad de las pruebas se mide a
partir del porcentaje de cobertura, cuando se realizan pruebas bajo todas las condiciones al
menos una vez, se dice que cumple 100% la cobertura.
Técnica de prueba Objetivo Casos de prueba Descripción de Cobertura

• La cobertura de la sentencia permite evaluar el

porcentaje de sentencias ejecutadas del sistema en
los casos de pruebas.

𝐶𝑜𝑏𝑒𝑟𝑡𝑢𝑟𝑎 𝑑𝑒 𝑠𝑒𝑛𝑡𝑒𝑛𝑐𝑖𝑎 =
𝑁ú𝑚𝑒𝑟𝑜 𝑑𝑒 𝑠𝑒𝑛𝑡𝑒𝑛𝑐𝑖𝑎𝑠 𝑒𝑗𝑒𝑐𝑢𝑡𝑎𝑑𝑎𝑠
• Los casos de prueba deben diseñarse 𝑁ú𝑚𝑒𝑟𝑜 𝑡𝑜𝑡𝑎𝑙 𝑑𝑒 𝑠𝑒𝑛𝑡𝑒𝑛𝑡𝑖𝑎𝑠 𝑒𝑗𝑒𝑐𝑢𝑡𝑎𝑏𝑙𝑒𝑠
× 100%
para ejecutar las sentencias del sistema,
Validar las • Aunque el porcentaje de la cobertura de las
por lo tanto, deben dirigirse a sentencias
sentencias del sentencias es igual al 100%, no asegura que el
Pruebas de sentencia específicas, para aumentar la cobertura
código en el sistema este correcto, debido que no es posible
del sistema.
sistema. asegurar que cada decisión del sistema ha sido
• Una sentencia del sistema se ejecuta en ejecutada, por ejemplo, si el sistema cuenta con
su totalidad o no en absoluto. sentencias de condición, únicamente se prueba un
camino.

• Si el porcentaje de la cobertura es menor que el

100% significa que existe código que no ha sido
ejecutado.

Validar y asegurar • Los casos de prueba buscan ejecutar los • La cobertura de decisión, permite evaluar el
Pruebas de decisión las decisiones del resultados de las decisiones. porcentaje de los resultados de decisión, que han

sistema (if, do- sido ejecutados.

 while, repeat-until, • Para definir los casos de prueba se debe: 𝐶𝑜𝑏𝑒𝑟𝑡𝑢𝑟𝑎 𝑑𝑒 𝑑𝑒𝑐𝑖𝑠𝑖ó𝑛 =
case) 𝑁ú𝑚𝑒𝑟𝑜 𝑡𝑜𝑡𝑎𝑙 𝑑𝑒 𝑟𝑒𝑠𝑢𝑙𝑡𝑎𝑑𝑜𝑠 𝑑𝑒 𝑑𝑒𝑐𝑖𝑠𝑖ó𝑛 𝑐𝑢𝑏𝑖𝑒𝑟𝑡𝑜𝑠
o Dividir el código del sistema en × 100%
𝑁ú𝑚𝑒𝑟𝑜 𝑡𝑜𝑡𝑎𝑙 𝑑𝑒 𝑝𝑜𝑠𝑖𝑏𝑙𝑒𝑠 𝑟𝑒𝑠𝑢𝑙𝑡𝑎𝑑𝑜𝑠 𝑑𝑒 𝑑𝑒𝑐𝑖𝑠𝑖ó𝑛

bloques básicos.
• El 100% de cobertura de decisión, garantiza el
o Identificar las decisiones que se 100% de cobertura de sentencia, pero no viceversa.
presentan en cada bloque, las
ramas y sus resultados.

o Diseñar casos de pruebas que

cubran los resultados de las
decisiones, tanto falsas como
verdaderas.

Esta técnica definida por McCabe, se basa Calculo de la complejidad ciclomática:

Validar los caminos
en “derivar una medida de complejidad
de ejecución de (1). 𝑉(𝐺) = 𝐸 − 𝑁 + 2
lógica a partir de un diseño procedimental,
manera
Pruebas de camino o y usar esta medida como guía para definir Donde E: Número de aristas y N el número de nodos.
independiente en el
ruta básica un conjunto base de rutas de ejecución”. O,
grafo del
componente de (2). 𝑉(𝐺) = 𝑃 + 1
prueba.
Donde P: Número de nodos predicados1 del grafo.

1
El nodo predicado: corresponde a un nodo que presenta una condición del sistema, donde aparecen uno o más operadores lógicos, creando nodos descendientes por cada
condición. [18],
Para la generación de casos de pruebas es Grafica de flujo de acuerdo a instrucciones
necesario:
Secuencia Condicional
1. Convertir el código del sistema en una
gráfica de flujo.
2. Calcular la complejidad ciclomática
𝑉(𝐺) del grafo generado.
Mientras Hasta
El valor de 𝑉(𝐺) define:

 El número de rutas que son

independientes del programa.

 El límite superior del número de

Según sea
pruebas a diseñar.

 Cuando el valor es mayor a 10, la

probabilidad de presentarse
defectos es mayor

3. Determinar el conjunto básico de

caminos linealmente independientes.
4. Diseñar los casos de pruebas del
conjunto de caminos.
4.2 BASADA EN ESPECIFICACIÓN – CAJA NEGRA

Las técnicas basadas en especificación o pruebas de caja negra, no necesitan conocer la lógica
interna del sistema a probar para el desarrollo de los casos de prueba. Se basan en las posibles
entradas, las salidas del sistema como resultado y la validación del resultado, las pruebas son
exitosas si el resultado cumple los criterios de aceptación, en caso contrario la prueba revela un
defecto (salida errónea). Quien ejecuta las pruebas se basa en que hace el software y no en el
cómo, tiene en cuenta las respuestas del sistema y no la trayectoria interna de cálculos y
procesamiento realizado. (ISTQB, 2011)

La IEEE define esta técnica como “un enfoque que trata a un sistema o componente cuyas
entradas, salidas y funciones en general son conocidos, pero cuyo contenido o implementación
son desconocidos o irrelevantes” (ISO/IEC, 2010)

Las pruebas de caja negra se llevan a cabo sobre la interfaz del software, obviando el
comportamiento interno y la estructura del programa.

Los casos de prueba de la caja negra pretenden demostrar que:

• Las funciones del software son operativas

• La entrada se acepta de forma correcta
• Se produce una salida correcta
• La integridad de la información externa se mantiene

Las pruebas de caja negra pretenden encontrar estos tipos de errores:

• Funciones incorrectas o ausentes

• Errores en la 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

En la Ilustración 2, se presenta un ejemplo sobre pruebas sobre una calculadora, que como
entrada recibe los números y las operaciones que se requieren ejecutar sobre ellos y devuelve
una salida con el resultado de la operación.
Ilustración 3 Técnica de caja negra

En las siguientes subsecciones se presentan las técnicas de pruebas de acuerdo a este enfoque.

Los tipos de prueba de cana negra que vamos a estudiar son:

• Prueba de partición equivalente

• Prueba de análisis de valores límites
• Tablas de decisión
• Grafos causa efecto.
• Transición de estados
• Casos de Uso

Partición de equivalencia o clases de equivalencia

Como su nombre lo indica, esta técnica busca dividir las entradas o salidas del sistema en grupos
de acuerdo a un común comportamiento o por características comunes, por lo tanto, se espera
que sean procesados de la misma manera el resultado de la prueba para una entrada de una clase
es representativo para todas las entradas de la misma clase.

• Dividir las entradas o salidas, en grupos equivalentes.

• Supuesto: Si un valor da resultado esperado, el resto del grupo harán lo mismo o, por el
contrario, si un valor de una partición no funciona, entonces se asume que el resto de la
partición no funcionará.
• La partición de equivalencia puede aplicarse en todos los niveles de pruebas.

Por ejemplo 0<=X<=10

Se identifican tres particiones para realizar los casos de prueba:

• Todos los valores numéricos de entrada que se encuentren dentro de los rangos X<=0 y
X>=10 son valores de entrada inválidos.
 • Todos los valores numéricos de entrada que se encuentren dentro del rango 0<= X <=10
son valores de entrada válidos.

Pressman define cuatro directrices para la definición de particiones equivalentes (Pressman,

2002).

1. Si una condición de entrada especifica un rango, se define una clase de

equivalencia válida y dos inválidas

2. Si una condición de entrada requiere un valor específico, se define una clase de

equivalencia válida y dos inválidas.

3. Si una condición de entrada especifica un miembro de un conjunto, se define una

clase de equivalencia válida y una inválida.
4. Si una condición de entrada es lógica, se define una clase válida y una inválida.

Análisis de valores Límites (AVL)

Esta técnica complementa a la de partición equivalente (toma como base a la anterior). En lugar
de seleccionar cualquier elemento de una clase de equivalencia, el AVL lleva a la elección de
casos de prueba "en los bordes" o “análisis de valores límite” de la clase. En lugar de centrarse
solamente en las condiciones de entrada, el AVL deriva casos de prueba también para el campo
de salida.

 Los valores máximos y mínimos de una partición corresponden a los valores límites.
 Los limites o fronteras son un buen lugar para encontrar defectos, debido que los
defectos tienden a encontrarse alrededor de ellos. Es probable que se presente un error
en los valores justo fuera del rango por ser aceptados o los valores justo en el límite del
rango por ser rechazados.
 Los limites válidos constituye al valor límite de las particiones válidas y limites no
válidos corresponde a valor límite de las particiones no válidas. Por lo tanto, un valor
límite es el valor en un límite de una partición de equivalencia.
  Las pruebas deben considerar los valores válidos, valores inválidos, valores límite
válidos y valores límite inválidos. Cuando se selecciona un valor límite, se debe
seleccionar el valor límite, al menos un valor dentro del límite y otro valor fuera del
límite, por lo tanto, por cada límite se seleccionan tres valores. Es importante tener
cuidado con el valor fuera del límite de la partición, debido que esta puede ser el valor
de la frontera de otra clase, lo que puede estar reduciendo los valores de selección a dos:
el valor límite y un valor dentro del límite.
 El análisis de valores límite puede aplicarse en todos los niveles de pruebas.
 Con frecuencia se presentan inconvenientes en el momento de definir los valores límites
de una partición, por lo que es necesario basarse en la especificación de los
requerimientos, y como segunda instancia buscar los límites de manera indirecta u
ocultos.

En el siguiente ejemplo anterior para el rango 0 < X < 10, se tienen las mismas particiones
con las fronteras: 0 y 10.

Se tiene los siguientes valores de pruebas:

• Valores identificados para las tres particiones: -1, 0, 1, 5, 9, 10, 11

• 0, 1, 9, 10 representan valores de prueba para el rango 0 < X < 10, donde las fronteras
son excluidas en el rango.
• -1, 0, 10, 11 representan valores de prueba para el rango 0 < X < 10, donde las fronteras
no son excluidas en el rango.

Tabla de decisiones

Las tablas de decisión, comprende un conjunto de condiciones (entradas) y un conjunto de

acciones (salidas). Para cada conjunto de condiciones, se relaciona la entrada con las opciones
“Si”, “No”, o “No aplica” como respuesta y una lista de resultados esperados de acuerdo a las
reglas seleccionadas.

 Las tablas de decisión permiten registrar todas las condiciones de entrada posibles junto
con todas las acciones resultantes del sistema.
  Facilita la definición de las decisiones lógicas del sistema, debido que las tablas
representan relaciones lógicas entre las condiciones.
 Las tablas de decisión, son muy útiles cuando se tienen reglas de negocio complejas y
se cuenta con varias condiciones de entradas que producen varias salidas.
 Las tablas de decisión permiten determinar si los requerimientos están completos, los
casos de prueba se crean a partir de cualquier texto o documento y a menudo permiten
evidenciar ambigüedades o falencias en los requerimientos.
 Las combinaciones posibles de la tabla de decisión se derivan de los requerimientos, se
debe analizar la especificación para identificar las condiciones y acciones del sistema.
 Las filas de la tabla de decisión especifican las condiciones de entrada o acciones que
son realizadas en el sistema.
 Las columnas de la tabla de decisión, representan los casos de prueba, especifican las
acciones que pueden ocurrir. Representa un conjunto único de combinaciones de
entrada.

Entrada / Acciones Prueba 1 Prueba 2 Prueba N

Entrada 1 Si No Si

Entrada 2 Si N/A No

Entrada N Si N/A Si

Salidas/Respuestas

Salida 1 Si No Si

Salida 2 Si No No

Salida N No Si N/A

Tabla 1 Tabla se decisión

En la siguiente Tabla se presenta un ejemplo sobre la técnica de tablas de decisión. Las entradas
corresponden a los estados de las personas que ingresan a un sistema y las salidas corresponden
a las salidas de acuerdo a las entradas.

Entrada Prueba 1 Prueba 2 Prueba 3 Prueba 4 Prueba 5

/Acciones

¿Mayor de edad? Si Si Si Si No

¿Empleado? Si No No Si N/A

¿Esta No N/A
Si Si No
pensionada?

¿Estudia en
No No No No Si
colegio?

Salidas/Respuestas

Cotiza pensión. No No No Si N/A

Recibe ingresos
Si Si N/A N/A N/A
por pensión.

Recibe sueldo por

Si No N/A Si N/A
trabajo.

Depende
económicamente N/A N/A N/A N/A Si
de los padres.

Tabla 2 Ejemplo de tabla de decisión

Así por ejemplo se tienen las siguientes entradas para definir los casos de pruebas y las salidas
o respuestas esperadas:

• El primer caso de prueba, las entradas definen a una persona que es mayor de edad, esta
empleada, es jubilada y no estudia en colegio. Por lo tanto, no cotiza pensión, recibe
ingresos por pensión y recibe sueldo por trabajo.
• El segundo caso de prueba, las entradas definen a una persona que es mayor de edad,
no está empleada, esta pensionada y no estudia en un colegio. Por lo tanto, no cotiza
pensión, recibe ingresos por pensión y no recibe sueldo por trabajo.
 • El quinto caso de prueba, las entradas definen a un menor de edad y que estudia en el
colegio. Por lo tanto, depende económicamente de sus padres.

Grafos de causa- efecto

Técnica de prueba que busca representar de manera gráfica las “entradas o estímulos (causas)
del sistema con las salidas asociadas (efectos) del sistema.”

Proporcionan una concisa representación de las condiciones lógicas y sus correspondientes

acciones. Sigue cuatro pasos:

1. Se listan para un módulo las causas (condiciones de entrada) y los efectos (acciones),
asignando un identificador a cada uno de ellos.
2. Se desarrolla un grafo de causa-efecto.
3. Se convierte el grafo en una tabla de decisión.
4. Las reglas de la tabla de decisión se convierten a casos de prueba.

Para la creación de casos de pruebas es necesario

2. Cuando un requerimiento no es atómico es difícil de manejar, por lo que se

recomienda Dividir el requerimiento en varios segmentos viables, que puedan ser
representados como causa – efecto.
3. Identificar las causas y los efectos del requerimiento. A cada una de las causas y
efecto se le debe asignar un identificador único.
4. Para cada efecto generar una expresión booleana que exprese las causas.
5. Generar el grafo, en las conexiones se incluye el tipo de combinación entre las
causas y efectos.
a) Si se presenta el operador booleano ^ (y), significa que todas las causas
deben ser verdaderas para que el efecto sea verdadero.
b) Si se presenta el operador booleano ˅ (o), significa que al menos una causa
debe ser verdadera para que el efecto sea verdadero.
c) Si se presenta un ~, representa la negación, lo verdadero debe entenderse
d) como falso, y viceversa.
e) Si se presenta un arco ∡, significa que todas las causas se deben combinar
con el operador.
 6. Cuando se presenten consideraciones que no son posibles incluir en el grafo
(ejemplo. Una restricción ambiental), se debe incluir la anotación en el diagrama.
7. Es posible transformar el grafo a una tabla de decisión, ver sección 6.1.3, donde las
columnas de la tabla representan un caso de prueba.

Ilustración 4 diagrama causa efecto

Casos de uso

Técnica de pruebas que se basa en los casos de uso del sistema, debido a que brindan
información importante y completa del sistema, específica las funcionalidades del negocio, los
escenarios, los flujos de procesos entre el sistema y el actor describen los usos particulares del
sistema para cada usuario u otro sistema, presenta el sistema de principio a fin. “Un sistema se
describe por la suma de sus casos de uso”. Las ventajas de los casos de uso son:

• Los casos de uso manejan lenguaje natural con términos del negocio y no un lenguaje
técnico. Describe las interacciones de los usuarios con el sistema de manera secuencial.
• Los casos de uso tienen precondiciones que el sistema debe cumplir antes de la
ejecución y post condiciones que indican los resultados finales del que el sistema luego
de su ejecución
• Los casos de uso describen un flujo del sistema principal basado en el uso más probable
y otros flujos asociados que describen las posibles excepciones que se pueden presentar.
• Cada escenario de un caso de uso representa un caso de prueba.
• Permite asegurar el cumplimento de los requerimientos del sistema y las expectativas
del usuario. Por lo tanto, son una base para las pruebas de aceptación.
 • Dentro de los casos de pruebas se deben incluir los flujos normales de los actores
descritos en los casos de uso, los flujos de las excepciones o variantes que se describan,
la información adicional suministrara información sobre el propósito de la prueba, las
precondiciones.

Caso de uso Acceso a la cuenta de un cliente a través de su tarjeta

Objetivo Describir el flujo de acceso a la cuenta a través de la tarjeta de un cliente

Actor Cliente tarjeta

Usuario con tarjeta activa

Precondiciones
Cuenta sin bloqueo

Descripción

No No
Actor Sistema
paso paso

1 Inserta la 2 Valida tarjeta y solicita clave

Flujo normal tarjeta

3 Ingresa la 4 Valida clave

clave

5 Permite el acceso a la cuenta

2a Tarjeta no valida: el sistema presenta mensaje y rechaza la tarjeta

Clave no valida: el sistema presenta mensaje y permite realizar

4a
Excepciones reintento de clave

Clave invalida 3 veces: el sistema bloquea la tarjeta y no permite

4b
el acceso.

Post
Actor accede a su cuenta
condiciones

Tabla 3 Descripción del caso de uso de acceso a la cuenta

Basadas en experiencia

Esta técnica de pruebas, se basa en la habilidad, intuición, conocimiento, imaginación y

experiencia de la persona que ejecuta las pruebas y representan un factor decisivo en el éxito y
la calidad de los casos de pruebas derivados.

Aportan un valor agregado en la creación de casos de pruebas, debido que permiten identificar
casos especiales que comúnmente no son previstos mediante otros métodos, por lo tanto, estas
técnicas deben ser complemento a las técnicas formales, a continuación, se presentan las
técnicas: Predicción de error y pruebas exploratorias.

Predicción de error

Como su nombre lo indica, esta técnica busca identificar de manera anticipada los errores que
se pueden presentar en el sistema, se basan en la experiencia, en el conocimiento del sistema,
en su funcionamiento y en el conocimiento de ejecución de pruebas por parte del probador, para
identificar debilidades y los posibles defectos del sistema. Así como también en el historial de
problemas presentados en versiones anteriores o sistemas similares. Es importante tener en
cuenta los siguientes puntos:

 No existen reglas que especifiquen como adivinar errores

 Los casos de pruebas se creen a partir de las situaciones identificadas como
debilidades o posibles fallas.
 Es importante incluir en los casos de pruebas, eventos que fueron definidos como
“Eso nunca sucede”, debido que son suposiciones que pueden generar errores.
 Una buena práctica, es crear una base de conocimientos de problemas presentados
en el sistema y diseñar casos que lo validen.
 Este enfoque no solamente se puede usar para la validación dinámica del sistema,
sino también en etapas anteriores como son los requerimientos, el diseño, el
desarrollo y posteriores como operación y mantenimiento.
 “Estudios realizados por la IBM Corporation, indican que los mismos tipos de
defectos de software se producen con la misma frecuencia de proyecto a proyecto,..,
los expertos en pruebas de software puede predecir los tipos de defectos que se
producirán en el software.”

Pruebas Exploratorias
En esta técnica de pruebas, se busca realizar pruebas del sistema sin que los casos de pruebas
se encuentren definidos de manera formal, pero se cuenta con el conocimiento del alcance de
la prueba, el enfoque de las pruebas y problemas esperados en una “carta de pruebas” que
presenta dicha información.

 Útil cuando se cuenta con poca documentación, mala calidad de las especificaciones de
los requerimientos, “y existe una importante presión temporal”

 Los casos de prueba y su ejecución se realizan de manera inmediata.

 Las pruebas exploratorias se realizan de manera simultánea: el aprendizaje, el diseño de

la prueba y la ejecución de pruebas por lo tanto a medida que se ejecutan pruebas, se va
generando la documentación de las pruebas, se realiza el reporte de defectos y en caso
de identificar nuevos eventos, estos son incluidos.

 Un aspecto importante sobre esta técnica es el aprendizaje del software por parte del
ejecutor de pruebas: su uso, sus fortalezas y sus debilidades.

 Permite complementar otras técnicas de pruebas.

 Si el probador tiene experiencia podrá analizar, razonar y tomar decisiones sobre la

marcha.

En la Error! Reference source not found., se presenta la información sobre lo que permiten
conocer las pruebas exploratorias.

Explorar
Encontrar Identificar en el sistema
•Información del sistema •Que funciona.
(para incluir y mejorar •Que no funciona.
pruebas) •El uso.
•Defectos del sistema. •Fortalezas.
•Debilidades.

Ilustración 5 pruebas exploratorias

5. PROCESOS DE PRUEBA DE SOFTWARE

6. CONCLUSIONES Y RECOMENDACIONES

6.1. Conclusiones


6.2. Recomendaciones

6.3.