1

ESTRATEGIAS DE PRUEBAS DE SOFTWARE

Presentado por:

DIEGO ALFONSO APONTE TOVAR

JEFFREY EDILZON GONZALEZ ORTEGON

Docente

MANUEL CABRERA

FUNDACIÓN UNIVERSITARIA UNINPAHU

FACULTAD DE INGENIERÍAS Y TECNOLOGÍAS DE LA INFORMACIÓN
PROGRAMA DE INGENIERÍA DE SOFTWARE
Bogotá – Colombia
2019
 2

TABLA DE CONTENIDO

INTRODUCCIÓN ..........................................................................................................................5
OBJETIVO GENERAL ...................................................................................................................6
PRUEBAS DE SOFTWARE ..........................................................................................................7
QUE ES EL ISTQB ........................................................................................................................8
1. Un enfoque estratégico para la prueba de software .....................................................................9
1.1. Verificación y Validación .................................................................................................9
1.2. Organización de las pruebas de Software ........................................................................10
1.3. Estrategia de la prueba del Software. Visión general ......................................................10
1.4. Criterios para completar las pruebas ...............................................................................11
2. Pruebas funcionales de software ...............................................................................................11
2.1. Pruebas de Interoperabilidad ..........................................................................................11
2.2. Pruebas de Caja Negra.....................................................................................................12
2.2.1. Técnicas de pruebas de caja negra ...........................................................................12
2.2.2. Pruebas de Caja Negra y Pruebas Funcionales ........................................................13
2.2.2.1. Pruebas de casos de uso .................................................................................14
2.2.2.2. Pruebas de historias de usuario ......................................................................14
2.3. Pruebas de Caja Blanca ...................................................................................................16
2.3.1. Técnicas de prueba de caja blanca ...........................................................................16
2.3.1.1. Camino básico ...............................................................................................16
2.3.1.2. Notación de Grafo de Flujo ...........................................................................16
2.4. Pruebas Exploratorias ......................................................................................................18
3. Pruebas no funcionales de software ..........................................................................................18
3.1. Pruebas de Desempeño ...................................................................................................19
3.2. Pruebas de Carga ............................................................................................................19
3.3. Pruebas de Estrés ............................................................................................................20
3.4. Pruebas de Usabilidad ....................................................................................................20
3.5. Pruebas de Mantenibilidad .............................................................................................21
3.6. Pruebas de Escalabilidad ................................................................................................21
3.7. Pruebas de Resistencia ...................................................................................................22
3.8. Pruebas de Recuperación ................................................................................................23
 3

3.9. Pruebas de Configuración ...............................................................................................23

4. Estrategias de prueba para Software Convencional ...................................................................24
4.1. Prueba de Unidad ............................................................................................................24
4.1.1. Consideraciones de las pruebas de Unidad ..............................................................24
4.1.2. Procedimientos de prueba de unidad .......................................................................25
4.2. Pruebas de Integración ....................................................................................................26
4.2.1. Integración descendente ...........................................................................................26
4.2.2. Integración ascendente .............................................................................................27
4.3. Prueba de regresión .........................................................................................................28
4.4. Prueba de humo ...............................................................................................................28
5. Estrategias de prueba para Software Orientado a Objeto ..........................................................30
5.1. Prueba de Unidad en el contexto OO ..............................................................................30
5.2. Prueba de Integración en el contexto OO ........................................................................31
6. Pruebas de validación ................................................................................................................31
6.1. Criterios de pruebas de validación ..................................................................................32
6.2. Revisión de la Configuración ..........................................................................................32
6.3. Pruebas Alfa y Beta .........................................................................................................32
7. Pruebas del Sistema ...................................................................................................................33
7.1. Pruebas de recuperación ..................................................................................................33
7.2. Pruebas de Seguridad ......................................................................................................34
7.3. Pruebas de Esfuerzo ........................................................................................................34
7.4. Pruebas de Rendimiento ..................................................................................................35
7.5. Pruebas de Despliegue .....................................................................................................35
7.6. Pruebas de Perfomance....................................................................................................35
7.7. Pruebas de Prueba de Documentación y Procedimientos................................................36
7.8. Pruebas de Volumen ........................................................................................................36
7.9. Pruebas de Múltiples Sitios .............................................................................................38
7.10. Pruebas de Stress ...........................................................................................................38
8. Aspectos Estratégicos de las Pruebas de Software ...................................................................39
9. Pruebas de Recuperación y Tolerancia a fallas..........................................................................40
10. Prueba de Compatibilidad y Conversión .................................................................................41
11. Pruebas de Integridad de Datos y Base de Datos .....................................................................41
 4

12. Pruebas De Validación A Sistemas A La Medida ...................................................................42

12.1. Pruebas de GUI..............................................................................................................42
13. Pruebas de Aceptación .............................................................................................................43
14. Pruebas de Campo....................................................................................................................44
LISTA DE REFERENCIAS ..........................................................................................................45
BIBLIOGRAFÍA ...........................................................................................................................46
CONCLUSIONES ........................................................................................................................47
 5

INTRODUCCIÓN

Las pruebas de Software se califican para determinar y descubrir errores que se cometen de manera

inadvertida conforme se diseña y se construye el software.

Una estrategia de software se aplica cuando se esté realizando las pruebas de software, los

ingenieros y representantes las pueden aplicar, el procedimiento final se puede clasificar como una

especificación de pruebas documentadas de forma en que el equipo desarrollador prepara dichas

pruebas.

Las pruebas de software ayudan en el desarrollo del software, ya que proporcionan los pasos para

realizar una prueba y como modelar un diseño de casos de prueba para un software, también se

pretende explicar cómo se ejecuta la prueba de software y como se recolectan y evalúan los

resultados.
 6

OBJETIVO GENERAL

El objetivo de este trabajo es conocer y analizar las pruebas de software y como se implementan

en el producto, sistema o programa desarrollado, como las estrategias de pruebas realizan una

evaluación eficaz y eficiente del software, también definimos las buenas prácticas necesarias en

cada iteración del desarrollo de software.

 7

PRUEBAS DE SOFTWARE

Un concepto necesario de conocer al incursionar en el mundo de las Pruebas de Software,

son los Tipos de Pruebas de Software.

Existen muchos términos y conceptos disponibles en la literatura, alguno de los cuales

pueden hasta ser sinónimos, por ejemplo: pruebas funcionales, pruebas de sistemas, pruebas no

funcionales, pruebas de caja negra, pruebas de caja blanca, entre otros.

El ISTQB ha emergido como una organización que ha ayudado a definir estándares en el

cambio de las pruebas de software.

Parte fundamental de una prueba de software es desarrollar una guía con todos los

lineamientos que describan los pasos de inicio y fin a realizarse como parte de la prueba. En general

la estrategia de pruebas debe componerse por su planificación, diseño de casos, ejecución y

recolección de la prueba y la evaluación de resultados como trazabilidad para su informe.

El software como pieza importante de su prueba de rendimiento debe ser flexible,

acomodarse con facilidad a distintas situaciones dentro de su ciclo de desarrollo con el fin de

promover su uso. Cuando el nivel es alto, debemos distinguir entre las pruebas manuales y las

automatizadas. Las pruebas manuales se realizan en persona, haciendo clic a través de la aplicación

o interactuando con el software y las API con las herramientas adecuadas. Resultan muy costosas,

ya que requieren que alguien configure un entorno y ejecute las pruebas, y pueden ser propensas a

errores humanos, ya que el encargado puede cometer erratas u omitir pasos en el script de la

prueba. Por otro lado, las pruebas automatizadas se realizan a través de una máquina que ejecuta

un script de prueba escrito con antelación. Estas pruebas pueden variar mucho en cuanto a

complejidad, desde comprobar un único método en una clase hasta garantizar que realizar una
 8

secuencia de acciones complejas en la IU genera los mismos resultados. Son mucho más potentes

y fiables que las pruebas automatizadas, pero la calidad de estas últimas depende de lo bien que se

hayan escrito los scripts de las pruebas.

¿Qué es el ISTQB?

Es una organización dedicada a la calificación y certificación de profesionales y empresas

en el área de Pruebas e Software, que ha ganado bastante prominencia en tiempos recientes, las

siglas significan "Comité Internacional de Calificación en Pruebas de Software", en inglés,

"International Software Testing Qualifications Board" (ISTQB).

La Visión del ISTQB, está la de mantener una base de conocimientos, fomentar la

comunicación de la comunidad de pruebas de software internacional y promover la investigación

en el área.

La misión del ISTQB es:

 Promover la ocupación de pruebas de software como una profesión.

 Certificar a profesionales en competencias de pruebas de software.

 Proporcionar una ruta de certificación multinivel que permite a los profesionales crecer

progresivamente en habilidades y conocimientos.

 Proporcionar un punto de referencia para evaluar la efectividad de los servicios de pruebas

de software de las organizaciones.

 Incrementar continuamente la base de conocimientos tomando las mejores prácticas de la

industria.

 Regular el contenido de los exámenes y del proceso de calificación.

 9

 Fomentar buenas relaciones con sectores académicos, gobierno, medios de comunicación,

asociaciones profesionales y otros interesados.

1. Un enfoque estratégico para la prueba de software

Su enfoque común de la estrategia de prueba es en general un conjunto de resultados de normas

y procedimientos, que se planean de forma ordenada. Durante el proceso del software, debe

realizarse un chetlist con su respectiva plantilla sobre las pruebas de software, definirse en su inicio

del desarrollo, acá se realiza el conjunto de actividades que incluye los métodos y técnicas de

diseño de pruebas específicos del Software.

Una característica genérica de una plantilla de pruebas de software referente es: La prueba

comienza en los componentes y opera “hacia afuera”, hacia la integración de todo el sistema de

cómputo. Se trata de la composición del inicio de la prueba, opera en los elementos del sistema.

1.1.Verificación y Validación

Dentro de las pruebas del software, se utilizan dos términos importantes en el proceso que son

la Verificación, que se refiere al conjunto de tareas implementas como resultado que el software

es funcional, que cumple con las especificaciones del cliente a satisfacción y la validación, que

garantiza que el producto desarrollado cumple con los requerimientos del cliente.

Sin duda las pruebas en el Software son muy importantes antes, durante y después de terminado

el proceso, pese a que no se puede tener certeza de que el margen de error sea mínimo, se trabaja

continuamente para dar un buen porcentaje de certeza en cuanto a su calidad.

 10

1.2.Organización de las pruebas de Software

El objetivo fundamental de realizar pruebas del Software, es verificar la calidad del programa,

donde se evidencie que se está libre de errores y que su funcionamiento es el adecuado, podría

indicar que es un proceso de control de calidad que permite dar veracidad de lo que se ha

desarrollado, sin necesidad de incurrir en gastos adicionales, dentro del presupuesto inicialmente

pactado. Lo que se pretende con este proceso es que quien desarrolla el software, encuentre el error

y en lo posible no sea el cliente quien lo detecte.

Dentro del proceso de calidad, se encuentra un grupo denominado “Grupo de prueba

independiente”, el cual se encarga de encontrar errores después de que el proceso de construcción

del Software haya culminado.

1.3.Estrategia de la prueba del Software. Visión general

Dentro de las estrategias de las pruebas del Software, podemos encontrar que, para desarrollar

un software, debemos avanzar en forma de espiral en forma contraria de las manecillas del reloj,

a su vez, dentro del mismo proceso, se realizan una serie de pruebas denominadas; Prueba de

unidad, prueba de integración, prueba de validación y por ultimo prueba del sistema. Todos estos,

son una serie de pasos que se unen de manera secuencial para un mismo proceso que es el detectar

en lo posible, el mayor número de errores cometidos.

Con esto lo que se pretende es optimizar al máximo el rendimiento a nivel general del Software

y dar plena seguridad del calidad del producto.

 11

1.4.Criterios para completar las pruebas

Dentro de los criterios que se tienen en cuenta sobre las pruebas realizadas en el software,

siempre surgen incógnitas o preguntas como: ¿Cuándo terminan las pruebas?, ¿Cómo se sabe si se

ha probado lo suficiente? Dentro del proceso que se maneja, nunca se puede asegurar al 100% que

el procesos el totalmente exitoso, pues como todo, siempre hay un 1% que lo desmiente. Sin

embargo lo que se intenta es justamente trabajar continuamente y bajo diversos métodos, para que

el margen de error sea el mínimo y se de una buna imagen en cuanto a calidad.

2. Pruebas Funcionales de Software

Se entiende como las Funcionalidades del Sistema cómo “lo que el sistema hace”, las

funcionalidades pueden estar descritas en las especificaciones de requerimientos, especificaciones

funcionales, casos de uso e inclusive no estar documentadas, los casos de prueba se definen a partir

de estas funciones o características, así como su interoperabilidad entre sistemas, Consideran el

comportamiento externo del sistema por lo que se consideran pruebas de caja negra, además de las

pruebas sobre los módulos y funciones, pueden realizarse pruebas en áreas especializadas como

Pruebas de Seguridad y Pruebas de Interoperabilidad.

2.1.Pruebas de Interoperabilidad

Es el proceso de pruebas con el objeto de determinar la interoperabilidad de un producto

software.
 12

2.2.Pruebas de 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.” (Terrera, G. 2016, Blog)

2.2.1. Las Técnicas de pruebas de caja negra

1. Consiste en clasificar las entradas de datos del sistema en grupos que presentan un

comportamiento similar, por lo cual serán procesados de la misma forma.

2. Se pueden definir particiones tanto para datos válidos como no válidos (datos que deben

ser rechazados por el sistema).

3. Las particiones también pueden definirse en función de las salidas de datos, valores

internos, valores relacionados antes o después de ciertos eventos, y también para los valores

que reciben las interfaces.

4. A partir de allí se definen pruebas para cubrir todos o parte de las particiones de datos

válidos y datos inválidos.

5. Es aplicable a entradas de datos realizadas por personas o vía interfaces con otros sistemas.

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.

Ejemplo de pruebas de Caja Negra:

Ejemplo 1: Envió de correo electrónico al registrarse una transacción

 13

Descripción del caso: El sistema enviará un correo electrónico cuando se registre alguna de las

siguientes transacciones: pedido de venta de cliente, despacho de mercancía al cliente, emisión de

factura a cliente y registro de cobro al cliente.

Técnica de pruebas de caja negra: Requerimiento funcional / Caso de uso

Caso 1.1: Datos de entrada: Registrar pedido de venta. Resultado esperado (Salida): El sistema

envía un correo electrónico al cliente como constancia que su pedido se ha recibido.

Caso 1.2: Datos de entrada: Registrar despacho de mercancía al cliente. Resultado esperado

(Salida): El sistema envía un correo electrónico al cliente como constancia que se ha realizado el

despacho.

Caso 1.3: Datos de entrada: Registrar factura de cliente. Resultado esperado (Salida): El sistema

envía un correo electrónico al departamento de facturación y al cliente.

Caso 1.4: Datos de entrada: Registrar cobro. Resultado esperado (Salida): El sistema envía un

correo electrónico al departamento de cuentas por cobrar y al agente comercial (vendedor) que

lleva la cuenta del cliente.

2.2.2. Pruebas de Caja Negra y Pruebas Funcionales

En los estándares para Software Testing definidos por ISTQB, las técnicas de pruebas de

caja negra son utilizadas para realizar pruebas funcionales, basadas en las funciones o

características del sistema y su interacción con otros sistemas o componentes.

 14

Se pueden utilizar técnicas basadas en especificación para identificar las condiciones y casos

de prueba a partir de la funcionalidad del software, como es el caso de la Derivación o Extracción

de Casos de Prueba a partir del Caso de Uso (ó Historia de Usuario).

2.2.2.1.Pruebas de casos de uso

Los casos de uso describen las interacciones entre actores (que pueden ser usuarios o

sistemas) que producen un resultado que agrega algún valor. A partir de estos se pueden derivar

casos de prueba.

Tienen precondiciones que deben cumplirse para que estos funcionen de forma exitosa.

Los casos de uso terminan con post-condiciones, que son resultados observables y estado

del sistema después de la ejecución.

Son útiles para definir las pruebas de aceptación, en las que participa el usuario o cliente.

2.2.2.2.Pruebas de historias de usuario

En metodologías ágiles como por ejemplo Scrum, los requerimientos de usuario son

preparados en la forma de historias de usuario.

La historia de usuario describe una funcionalidad (o parte de ella) que puede ser

desarrollara y probada en una sola iteración.

La historia de usuario describe la funcionalidad a implementar, requerimientos no

funcionales y los criterios de aceptación.

 15

La cobertura mínima de pruebas para una historia de usuario está compuesta por los

criterios de aceptación.

Por ende los casos de prueba se derivan de estos criterios de aceptación

2.3.Pruebas de Caja Blanca

La prueba de caja blanca se basa en el diseño de casos de prueba que usa la estructura de control

del diseño procedimental para derivarlos. Mediante la prueba de la caja blanca el ingeniero del

software puede obtener casos de prueba que:

1. Garanticen que se ejerciten por lo menos una vez todos los caminos independientes de cada

módulo, programa o método.

2. Ejerciten todas las decisiones lógicas en las vertientes verdadera y falsa.

3. Ejecuten todos los bucles en sus límites operacionales.

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

Es por ello que se considera a la prueba de Caja Blanca como uno de los tipos de pruebas más

importantes que se le aplican a los software, logrando como resultado que disminuya en un gran

porciento el número de errores existentes en los sistemas y por ende una mayor calidad y

confiabilidad.
 16

2.3.1. Técnicas de prueba de caja blanca

2.3.1.1.Camino básico

La prueba del camino básico es una técnica de prueba de la Caja Blanca propuesta por Tom

McCabe. Esta técnica 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.

La idea es derivar casos de prueba a partir de un conjunto dado de caminos independientes

por los cuales puede circular el flujo de control. Para obtener dicho conjunto de caminos

independientes se construye el Grafo de Flujo asociado y se calcula su complejidad ciclomática.

Los pasos que se siguen para aplicar esta técnica son:

1. A partir del diseño o del código fuente, se dibuja el grafo de flujo asociado.

2. Se calcula la complejidad ciclomática del grafo.

3. Se determina un conjunto básico de caminos independientes.

4. Se preparan los casos de prueba que obliguen a la ejecución de cada camino del conjunto

básico.

Los casos de prueba derivados del conjunto básico garantizan que durante la prueba se ejecuta

por lo menos una vez cada sentencia del programa.

2.3.1.2.Notación de Grafo de Flujo

Para aplicar la técnica del camino básico se debe introducir una sencilla notación para la

representación del flujo de control, el cual puede representarse por un Grafo de Flujo. Cada nodo

del grafo corresponde a una o más sentencias de código fuente. Todo segmento de código de
 17

cualquier programa se puede traducir a un Grafo de Flujo. Para construir el grafo se debe tener en

cuenta la notación para las instrucciones. Un Grafo de Flujo está formado por 3 componentes

fundamentales que ayudan a su elaboración, comprensión y nos brinda información para confirmar

que el trabajo se está haciendo adecuadamente. Los componentes son:

Nodo

Cada círculo representado se denomina nodo del Grafo de Flujo, el cual representa una o

más secuencias procedimentales. Un solo nodo puede corresponder a una secuencia de procesos o

a una sentencia de decisión. Puede ser también que hallan nodos que no se asocien, se utilizan

principalmente al inicio y final del grafo

Aristas

Las flechas del grafo se denominan aristas y representan el flujo de control, son análogas a

las representadas en un diagrama de flujo. Una arista debe terminar en un nodo, incluso aunque el

nodo no represente ninguna sentencia procedimental.

Regiones

Las regiones son las áreas delimitadas por las aristas y nodos. También se incluye el área

exterior del grafo, contando como una región más. Las regiones se enumeran. La cantidad de

regiones es equivalente a la cantidad de caminos independientes del conjunto básico de un

programa.

Cualquier representación del diseño procedimental se puede traducir a un grafo de flujo.

Cuando en un diseño se encuentran condiciones compuestas (uno o más operadores AND, NAND,
 18

NOR lógicos en una sentencia condicional), la generación del grafo de flujo se hace un poco más

complicada.

2.4.Pruebas exploratorias

Cuantas más funciones y mejoras se apliquen en tu código, más deberás someterlo a pruebas

para garantizar que todo el sistema funciona correctamente. Entonces, para cada error que

soluciones, lo mejor es comprobar que no se vuelvan a producir en nuevas versiones. La

automatización es clave para hacer esto posible, y escribir pruebas antes o después pasará a formar

parte de tu workflow de desarrollo.

De este modo, la pregunta es si aún merece la pena realizar pruebas manuales. Se podría decir

que sí, y que deben centrarse en lo que se conoce como pruebas exploratorias, cuyo objetivo reside

en detectar errores que no son obvios.

3. Pruebas no funcionales de software

Su objetivo es probar los requerimientos no funcionales, incluyendo (sin limitarse a) pruebas

de: Desempeño, Carga, Estrés, Usabilidad, Mantenibilidad, Confiabilidad y Portabilidad, los

requerimientos no funcionales representan “cómo funciona el sistema” (en contraposición con las

funcionalidades que definen “lo que el sistema hace”). Las características no funcionales del

software, se pueden medir de diversas maneras, por ejemplo por medio de tiempos de respuesta en

el caso de pruebas de desempeño.

 19

Pueden hacer referencias a modelos de calidad, como por ejemplo ISO 9126, consideran el

“comportamiento externo” del sistema, en la mayoría de los casos son pruebas de caja negra

3.1.Pruebas Desempeño:

Son un tipo de pruebas que permiten analizar y evaluar las características del software

relacionadas con el desempeño, por ejemplo:

Tiempos de Respuesta: Es el intervalo de tiempo que transcurre entre la solicitud de un usuario

al sistema y la respuesta de este mismo

Throughput: Es la tasa a la cual el sistema puede atender las peticiones.

Capacidad: Máxima cantidad de trabajo útil que se puede realizar por unidad de tiempo.

El Objetivo de esta prueba de desempeño es verificar y validar los requisitos de desempeño

que se han especificado

3.2.Pruebas de Carga:

Prueba de rendimiento utilizado para evaluar cómo actúa el sistema con una carga variable de

usuarios pero dentro de los niveles esperados de la aplicación. Esta prueba da una idea al

propietario de la aplicación como actuará su sistema bajo una carga “normal” cuando este esté en

producción.
 20

Cuando usar una prueba de carga: Comprobar escenarios “reales” para saber si todas las

respuestas están dentro de los estándares aceptados. Ex: Comprobar que todas las transacciones

Ventana a ventana (screen to screen ) tardan menos de 2 secs.

3.3.Pruebas de Estrés:

Una prueba de estrés evalúa el sistema sometiéndolo a una carga creciente hasta que este falle.

Esta prueba permitirá identificar cuellos de botella “bottleneck” y conocer que carga es la máxima

admitida por la aplicación hasta que esta empieza a tener problemas de rendimiento.

Cuando usar una prueba de estrés: Esta prueba es realizada antes de eventos en los cuales la

aplicación va a recibir una carga fuera de lo normal (Ex: Black Friday)

3.4.Pruebas de Usabilidad:

En las pruebas de usabilidad, los testers de software se enfocan en validar que tan fácil de usar

es una determinada aplicación.

Las características evaluadas en la usabilidad incluyen:

Facilidad de aprendizaje: Que tan fácil es para los usuarios realizar funciones básicas la primera

vez que utilizan la aplicación.

Eficiencia: Que tan rápido los usuarios experimentados pueden realizar sus tareas.
 21

Memorización: Que tan fácil de memorizar es el uso de la aplicación, esto es, cuando un usuario

pasa mucho tiempo sin usar la aplicación, puede recordar lo suficiente para usarla con efectividad

la próxima vez, o tiene que empezar a aprender de nuevo.

Errores: Cuantos errores atribuibles al diseño comete el usuario, que tan severos son y que tan

fácil es recuperarse de los mismos.

Satisfacción: Que tanto le gusta (o desagrada) al usuario utilizar el sistema.

3.5.Pruebas de Mantenibilidad:

Básicamente consisten en evaluar que tan fácil es realizar el mantenimiento de un sistema o

aplicación. Esto significa que tan fácil es analizar, cambiar y probar estos cambios. Para realizar

esta prueba deben evaluarse la forma en que está implementada la aplicación, siguiendo buenas

prácticas de ingeniería de software. Es decir, que se estén siguiendo los patrones recomendados de

ingeniería de software y que no se estén introduciendo inadvertidamente anti patrones, esto es, que

no se estén cometiendo errores comunes de programación.

3.6.Pruebas de Escalabilidad

Las pruebas de escalabilidad consisten en verificar la capacidad de una aplicación de escalar

cualquiera de sus características no funcionales, como por ejemplo la carga que soporta, número

de transacciones, volúmenes de datos, entre otros.

 22

Al diseñar casos de prueba de escalabilidad, es recomendable considerarlos en bloques

incrementales, dada la dificultad de predecir la carga real que tendrá una aplicación luego de

implementada en producción.

Probar en bloques incrementales significa por ejemplo primero probar con niveles de demanda

bajos, luego incrementar a niveles de demanda medios y finalmente probar con altos niveles de

carga. De esta manera se puede determinar que también escala la aplicación y los problemas que

comienzan a surgir en distintos niveles.

Para que los resultados sean confiables, los ambientes de prueba y su configuración deben

mantenerse constantes.

3.7.Pruebas de Resistencia

Las pruebas de resistencia implican someter a un Sistema o aplicación a una carga determinada

durante un período de tiempo, para determinar cómo se comporta luego de un uso prolongado.

Un sistema informático puede comportarse de forma normal durante las primeras horas, sin

embargo, luego de cierto tiempo, problemas como fugas de memoria suelen ocasionar fallas.

Estos defectos en el desarrollo de software no pueden identificarse bajo pruebas funcionales

normales, por lo que es conveniente involucrar pruebas de resistencia entre los tipos de pruebas de

software.
 23

3.8.Pruebas de Recuperación

Las pruebas de recuperación se realizan para verificar que tan rápido y que tan bien se recupera

una aplicación luego de experimentar un falló de hardware o software.

Por lo tanto, para realizar pruebas de recuperación se requiere forzar la falla y luego verificar si

la recuperación ocurre adecuadamente.

Por ejemplo, cuando una aplicación esté funcionando desconectar el cable de red, o en una

aplicación móvil interrumpir la conexión con la red Wi-Fi o con la operadora, para luego

restablecer la conexión.

3.9.Pruebas de Configuración

En lugar de probar el desempeño de una aplicación desde la perspectiva de la carga, las pruebas

de configuración se usan para validar que efectos en el desempeño tienen ciertos cambios en la

configuración.

Un ejemplo típico de esta situación es experimentar con diferentes métodos de balanceo de

cargas y ver la respuesta de la aplicación a niveles similares de sobrecarga.

Otro ejemplo es verificar si el sistema es capaz de funcionar adecuadamente en diferentes

versiones o configuraciones de entornos de hardware y software, como pueden ser diversos

navegadores de internet, versiones de navegadores, entre otros.

 24

4. Estrategias de prueba para Software Convencional

Según lo que se indica en el artículo, existe variedad de estrategias para realizar pruebas de

Software. Sin embargo no todas son tan funcionales y efectivas para el fin que fueron creadas y

menos si estas se implementan después de que el software ya se encuentra estructurado.

Una de las estrategias, es realizar pruebas permanentes cada que se construya una parte del

software, con el fin de ir solucionado en el camino y no cuando todo esté terminado. Sin embargo

para quienes intervienen en este proceso dicha estrategia no es tan llamativa y prefieren no usarla.

4.1.Prueba de Unidad

Esta prueba se concentra en la verificación más notable de la unidad del diseño del software a

la que llamamos componente de Software, enfoca sus esfuerzos a que se verifique este componente

dándole un plus de calidad, detectando los pequeños errores dentro del módulo. Las pruebas y los

errores están en total relación de complejidad y es establecida para la prueba de Unidad por su

restricción limitada que es descubierta en sus procesos.

“Las pruebas de unidad se enfocan en la lógica de procedimiento interno y de las estructuras de

datos dentro de las fronteras de un componente”.

4.1.1. Consideraciones de las pruebas de Unidad.

Estas pruebas se ajustan a una síntesis práctica y facilidad de uso y lectura. Se acopla una

interfaz de módulo que facilita que la información fluya relativamente desde la unidad de software
 25

hacia y desde la unidad. Se aseguran los datos almacenados desde la estructura de datos locales a

ser examinados asegurando su integridad en todos los pasos en la ejecución de un algoritmo.

Imagen Prueba de Unidad Esquemática.

Un buen diseño de prueba establece un margen mínimo de errores y genera rutas de manejo

que termina estos rezagos de procesos limpiamente.

4.1.2. Procedimientos de prueba de unidad:

Se identifican por componentes, estos proporcionan guías para establecer los casos de

pruebas e identificar, una vez realizadas estas guías para establecer casos de pruebas para

identificar errores en las categorías analizadas de la revisión de la información. Cada caso de

prueba debe agruparse en conjunto de resultados esperados.

 26

En esta figura se puede establecer los entornos de prueba de unidad, donde el representante

del proyecto analiza los módulos a probarse, donde el controlador es el diseño que tiene sus guías

de ruta de datos y que suministra los resultados esperados de los casos de pruebas.

Los representantes y controladores crean una “sobrecarga” a las pruebas, estos dos son

software, si estos se mantienen simples habrá una leve sobrecarga. En términos no alentadores

muchos componentes no pueden tener prueba de unidad adecuada con un software de sobrecarga

simple. En circunstancias, la prueba completa puede posponerse hasta el paso de prueba de

integración.

4.2.Pruebas de Integración

Estas pruebas tienen un interrogante, porque va a fallar estas pruebas si son juntados todos los

módulos, el problemas es juntar todos los módulos, conectarlos. Los datos en su migración pueden

perderse. Las pruebas de Integración son técnicas que clasifican un método para construir una

estructura. Ocasionalmente se dificulta construir un enfoque no incremental que permita crear el

programa. La integración incremental realiza o se crea el programa y se prueba en pequeños

incrementos, donde los errores son más sencillos de consolidar, y puede aplicarse un enfoque de

pruebas sistemático.

4.2.1. Integración descendente.

Incrementa su enfoque funcional e incremental a la construcción de arquitectura de software.

El proceso de integración se realiza en una serie de cinco pasos.

 27

1. El módulo de control principal se usa como un controlador de prueba y los representantes (stubs)

se sustituyen con todos los componentes directamente subordinados al módulo de control

principal.

2. Dependiendo del enfoque de integración seleccionado (es decir, primero en profundidad o

anchura), los representantes subordinados se sustituyen uno a la vez con componentes reales.

3. Las pruebas se llevan a cabo conforme se integra cada componente.

4. Al completar cada conjunto de pruebas, otro representante se sustituye con el componente real.

5. Las pruebas de regresión (que se analizan más adelante en esta sección) pueden realizarse para

asegurar que no se introdujeron nuevos errores.

El control del proceso continúa desde el paso 2 hasta que se crea toda la estructura del

programa. La principal estrategia de integración descendente es garantizar los principales puntos

de control al principio en el proceso de prueba.

4.2.2. Integración ascendente.

La prueba de integración ascendente, comienza la construcción y los componentes en los

niveles inferiores dentro de la estructura del programa de métodos de la construcción de prueba.

Una estrategia de integración ascendente puede implementarse con los siguientes pasos:

1. Los componentes en el nivel inferior se combinan en grupos, que realizan una subfunción

de software específica.

2. Se escribe un controlador (un programa de control para pruebas) a fin de coordinar la

entrada y salida de casos de prueba.

 28

3. Se prueba el grupo.

4. Los controladores se remueven y los grupos se combinan moviéndolos hacia arriba en la

estructura del programa.

4.3.Prueba de regresión

Se realizan nuevas rutas de flujo de datos, el software cambia cuando se agrega nuevo módulo

de software. Las pruebas de regresión es un subconjunto cuando se realiza una nueva ejecución de

prueba que asegura que los cambios no propagan efectos colaterales no deseados.

Las pruebas exitosas en un concepto más amplio de las pruebas de regresión dan como

resultado el objetivo de descubrir errores que lo contextualice a un óptimo rendimiento, estos a su

vez deben corregirse, cambia el aspecto del software cada vez que se corrige el software.

Estas pruebas de regresión, al volver a ejecutar un subconjunto puede realizar manualmente,

usando herramientas de captura, esto permite al desarrollador capturar casos de pruebas y

resultados que le faciliten una nueva comparación.

4.4.Prueba de Humo (Smoke Testing o Ad Hoc).

Valida rápidamente y funcionalmente el software a probar, sin una prueba antes diseñada, este

término se describe de la historia donde las computadores eran gigantes y eran conectadas para

determinar si salía humo, al no salir este estaba correcto, si salía era desconectada. Esta prueba de

humo es un enfoque de prueba de integración, es diseñada como un mecanismo de ritmo para

proyectos o productos complicados. Esta prueba abarca la siguiente actividad de la más usada: Se

diseña una serie de pruebas para exponer los errores que evitarán a la construcción realizar
 29

adecuadamente su función. La intención debe ser descubrir errores “paralizantes” que tengan la

mayor probabilidad de retrasar el proyecto.

La prueba de humo debe exponer los problemas iniciales, se debe contemplar todo el sistema

de extremo a extremo, esta debe ser profunda para darle continuidad si la construcción pasa, pueda

suponer que es estable para probarse con mayor profundidad.

Opciones estratégicas: Las ventajas de una estrategia sirve para descubrir errores, las pruebas no

van a mejorar la calidad de software, es un mecanismo para validar que el software sea de calidad,

la estrategia de pruebas define una serie de pasos en los cuales debe existir una planificación, un

diseño y debemos de recolectar información para validar con los resultados obtenidos en la

validación de las pruebas y las características del software.

Productos de trabajo de las pruebas de integración: Estos productos son necesarios que las

pruebas específicas sean documentadas en una especificación de pruebas, es decir se debe

recolectar los resultados, validarlos y ejecutarlos en la validación de las pruebas. Este producto de

marco incorpora un plan de prueba y un procedimiento, y se acopla de la configuración del

software, podemos identificarlo como un paradigma imperativo.

Metodología: “Con las pruebas de humo se pueden verificar los flujos más significativos de una

aplicación o de una versión entregada al momento del despliegue a pruebas, de manera que las

funciones básicas del software operen de forma correcta mediante pruebas rápidas y sencillas.”

(Noren, A 2016)

Los pasos a seguir para la ejecución de las pruebas de humo son:

 Integrar el sistema para iniciar las pruebas

 Ejecutar los casos de prueba definidos

 30

 Encontrar errores

Pruebas de humo ubicadas en el ciclo de pruebas

5. Estrategias de prueba para Software Orientado a Objeto

Estrategias simples para ejecutar pruebas con el objetivo de probar y encontrar el mayor

número posible de errores con una facilidad de ejecutar una cantidad manejable de recursos que

determine un lapso realista, la naturaleza de este software cambia tanto las tácticas de la prueba

como la estrategia para el software orientado a software.

5.1.Prueba de Unidad en el contexto OO

El concepto de unidad cambia cuando definimos Unidad orientada a objetos, esta determina la

definición de clase y objeto, esto quiere decir que cada clase y cada instancia de una clase

empaqueta los atributos en la capa de datos, estas clases se definen métodos que dentro de las

clases son unidades comprobables más diminutas. Una clase de jerarquía define una superclase y
 31

la heredan algunas subclases. La prueba de clase para software OO es el equivalente de la prueba

de unidad para software convencional. A diferencia de la prueba de unidad del software

convencional, que tiende a enfocarse sobre el detalle algorítmico de un módulo y en los datos que

fluyen a través de la interfaz de módulo, la prueba de clase para software OO la dirigen las

operaciones encapsuladas por la clase y el comportamiento de estado de ésta.

5.2.Prueba de Integración en el contexto OO

Dentro de la prueba de integración de contexto, existen dos estrategias que permiten realizar

la prueba de integración de los sistemas OO y son, la prueba basada en Hebra y la prueba basada

en uso. La prueba basada en Hebra, básicamente se encarga de integrar diversos elementos entro

de la prueba, con el fin de que no existan daños colaterales. La prueba basada en uso se encarga

de probar diferentes clases servidor, después de ser probadas des diversas clases (clases

independientes y clases dependientes), se puede dar por terminada la construcción del software.

Dentro de estas mismas pruebas se utiliza el uso de controladores, los cuales prueban las

diversas operaciones de los niveles inferiores.

6. Pruebas de validación

Los requerimientos establecidos como parte de su modelado se valida enfrentándose con el

software que se construyó, el cliente manifiesta los requisitos para implementar el software y que

debemos cumplir con los requerimientos solicitados. Una validación resulta exitosa, cuando el

nivel de satisfacción del cliente sea el adecuado, de acuerdo con el funcionamiento del Software.
 32

Sin duda el mayor reto que se tiene para dar por aprobado el proceso de calidad de un sistema,

es el ojo evaluador y el grado de satisfacción de quien lo compra.

6.1.Criterios de pruebas de validación

Como ya lo hemos visto en los anteriores títulos de este trabajo, se puede validar un sistema

y/o software, después de haber sido sometido a diversas pruebas que nos indicaran pero no del

todo, la totalidad de errores que puede llevar consigo el software

En lo posible se trata de cumplir con las expectativas del cliente en cuanto a calidad. Sin

embargo, siempre se debe mediar con el cliente cuando se presenta algún error en el sistema.

6.2.Revisión de la Configuración

La revisión de la configuración, hace parte uno de la tantos procesos que se realizan para

garantizar de una u otra manera que la configuración del sistema es el adecuado. Se dice que es

una especie de auditoria que refuerza los procesos ya realizados para dar garantía de la calidad del

producto.

6.3.Pruebas Alfa y Beta

Las pruebas Alfa y Beta, son pruebas que se realizan con el fin de descubrir aquellos errores

que a simple vista no se detectan, pero que al parecer el usuario final termina por encontrarlos.
 33

Durante este proceso, los mismos clientes pueden realizar diversas pruebas que les permiten

detectar errores en el sistema y así saber si acepta o no el software. Dicho proceso puede tardar

varios días e inclusos semanas para detectar las inconsistencias.

7. Pruebas del Sistema

Dentro de las pruebas del sistema, se presenta normalmente una situación, que se llama el

“dedo acusador”, esto ocurre cuando se descubren una serie de errores en la estructuración del

sistemas, y los ingenieros y/o desarrolladores del sistema inician a tirarse la bola unos con otros.

El objetivo fundamental de las pruebas del sistema, es realizar diversidad de pruebas con el fin

de lograr que todos los elementos del software se hayan integrado correctamente y que la prueba

se haya aplicado de manera adecuada.

7.1.Pruebas de recuperación

En las pruebas de recuperación, se espera que todo sistema se recupere de aquellos errores que

se puedan presentar, sin que esto afecte el funcionamiento del sistema a nivel general y tampoco

genere gastos adicionales innecesarios.

La recuperación se puede realizar de manera automática o con intervención humana, lo que

significa que en la primera se realizan pruebas a través del mismo sistema para detectar las fallas

y en la otra interviene el factor humano, donde se evalúa el Tiempo Medio de Recuperación

(TMR).
 34

7.2.Pruebas de Seguridad y Controles

Las pruebas de seguridad, realizan un control eficaz, sobre aquellas personas inescrupulosas

que intentan penetrar el sistema y causar estragos en el software, dichas personas son también

llamados (hackers). El objetivo es realizar pruebas, donde se simula ser un hacker, para de esta

manera detectar las posibles falencias que otro pudiese encontrar.

Se requiere de tiempo y recursos para poder realizar las pruebas necesarias y asegurar de

manera precisa el sistema para que sea casi imposible penetrarlo.

Las pruebas Consiste en probar los atributos o características de seguridad del sistema, si es un

sistema seguro o no, si puede ser vulnerado, si existe control de acceso por medio de cuentas de

usuario, si pueden ser vulnerados estos accesos.

Las pruebas de seguridad también sirven para validar si el equipo de desarrollo de software ha

seguido prácticas de seguridad recomendadas en su programación.

Entre las características de seguridad de un sistema, están la confidencialidad, integridad,

autenticación, autorización y la disponibilidad.

7.3.Pruebas de Esfuerzo (stress)

El objetivo de las pruebas de esfuerzo, es enfrentar al sistema a situaciones de dificultad.

Dentro de las mismas pruebas de esfuerzo, existe una que se llama prueba de sensibilidad, la cual

se encarga de descubrir datos de entrada que pueden causar inestabilidad o un proceso no apto para

el sistema.
 35

7.4.Pruebas de Rendimiento

La prueba de rendimiento está diseñada para medir como su nombre lo indica, el rendimiento

del sistema y la frecuencia con la que se miden los recursos. Este proceso se lleva a cabo en el

transcurso de todos los pasos del proceso de pruebas. Sin embargo, solo hasta que el sistema está

totalmente integrado, se puede verificar el rendimiento verdadero del sistema.

Con este sistema, quien realiza el proceso de prueba, puede determinar si existen fallas que

afecten el correcto funcionando del sistema.

7.5.Pruebas de Despliegue

El objetivo de la prueba de despliegue consiste en moldear el software con el fin de que

funcione en cada uno de los sistemas operativos existentes donde debe operar de manera adecuada.

Adicionalmente se examina dentro de este proceso, todos los procedimientos que se requieren

y se deben seguir para la instalación del programa y documentos legales que se utilizan para la

legalidad de proceso de instalación.

7.6.Pruebas de Perfomance

Las pruebas de performance permiten conocer y mitigar los riesgos relacionados con el mal

desempeño de las aplicaciones en los entornos de producción y realizar las correcciones necesarias

antes de salir al mercado.

Se cuantifica la capacidad de la infraestructura, se validan los requerimientos de performance,

la escalabilidad de las plataformas y del sistema a probar.

 36

De esta manera, la empresa puede conocer qué cantidad de clientes simultáneos soporta su

producto, con tiempos y datos razonables sobre la infraestructura y las plataformas propuestas.

Asimismo, puede saber si es suficiente el hardware para soportar el nivel propuesto de

transacciones y qué expectativa de crecimiento soporta.

7.7.Prueba de Documentación y Procedimientos

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. Su Técnica es revisar la documentación del

proyecto contra las funcionalidades del sistema y su configuración física

7.8.Prueba de Volumen

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
 37

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.

Técnica:

 Utilice 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.
 38

7.9.Pruebas Múltiples Sitios

El propósito de esta prueba es evaluar el correcto funcionamiento del sistema o subsistema en

múltiples instalaciones.

Técnica: Realizar casos de prueba que verifiquen mínimo 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

7.10. Pruebas de Stress

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.

 39

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.

Verificar que el sistema funciona apropiadamente y sin errores, bajo estas condiciones de

stress:

 Memoria baja o no disponible en el servidor.

 Máximo número de clientes conectados o simulados (actuales o físicamente posibles)

 Múltiples usuarios desempeñando la misma transacción con los mismos datos.

 El peor caso de volumen de transacciones (ver pruebas de desempeño).

8. Aspectos Estratégicos de las Pruebas de Software

Todo proceso que se desee realizar, requiere de estrategias específicas y a su vez exitosas, que

den pauta al cómo proceder y que den confiabilidad de que lo que se desea hacer, sea en lo posible

de manera adecuada y con el mínimo de error.

Según Tom Gil, dice que “incluso la mejor estrategia fracasará, si no se aborda una serie de

aspectos decisivos.” (Pressman, 2010, p. 388) y que solo dicha estrategia triunfará, si quienes

prueban el software tienen en cuenta los siguientes aspectos que vale la pena resaltar:

Especifican los requerimientos del producto en forma cuantificable mucho antes de comenzar

con las pruebas.

 Establecen de manera explícita los objetivos de las pruebas.

 Entienden a los usuarios del software y desarrollan un perfil para cada categoría de usuario.

 Desarrollan un plan de prueba que enfatice “pruebas de ciclo rápido”.

 40

 Construyen software “robusto” que esté diseñado para probarse a sí mismo.

 Usan revisiones técnicas efectivas como filtro previo a las pruebas.

 Realizan revisiones técnicas para valorar la estrategia de prueba y los casos de prueba.

 Desarrollan un enfoque de mejora continuo para el proceso de prueba.

Dado que el proceso de seguridad del sistema es un tema fundamental para garantizar la calidad

del producto, las pruebas de despliegue se realizan a su vez con la pruebas de seguridad.

9. Pruebas de Recuperación y Tolerancia a fallas

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.

Su Técnica se centra en: Se deben utilizar las pruebas creadas para la Funcionalidad del sistema

y Procesos de Negocios para crear una serie de transacciones. Una vez se alcanza el punto inicial

de las pruebas de recuperación, se deben realizar o simular las siguientes acciones:

 Interrupción de electricidad en el cliente.

 Interrupción de electricidad en el servidor: simular o iniciar procedimientos de pérdida

de energía para el servidor.

 Interrupción de la comunicación en la red. (desconectar físicamente los cables o apagar

los hubs o routers)

 41

 Interrupción de la comunicación con los controladores de disco: simular o eliminar

físicamente la comunicación con uno o más controladores o dispositivos.

10. Prueba de Compatibilidad y Conversión

El propósito es demostrar que los objetivos de compatibilidad no han sido logrados y que los

procedimientos de conversión no funcionan.

La mayoría de los programas que se desarrollan no son completamente nuevos; con frecuencia

son reemplazos de partes deficientes, ya sea de sistemas de procesamiento de datos, o sistemas

manuales.

Como tales, los programas tienen a menudo objetivos específicos con respecto a su

compatibilidad y a sus procedimientos de conversión con el sistema existente.

Técnica: Desarrollar casos de prueba que permitan detectar deficiencias con:

 Compatibilidad entre programas

 Conversión de datos

11. Pruebas de Integridad de Datos y Base 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.

Técnica:
 42

 Invoque cada método de acceso y proceso de la Base de datos, utilizando en cada uno datos

válidos e inválidos.

 Analice 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.

12. Pruebas De Validación A Sistemas A La Medida

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.

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

verificar que:

 Incremente el número de veces en que una función es ejecutada para simular diferentes

usuarios sobre un periodo especificado

 Todas las fechas o funciones que involucren tiempos serán probadas con datos válidos e

inválidos de fechas o periodos de tiempo.

 Todas las funciones ocurren en un periodo de tiempo serán ejecutadas en el tiempo

apropiado.

12.1. Pruebas de GUI

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

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

Técnica: Pruebas de crear / modificar cada ventana para verificar la adecuada navegación y estado

de los objetos.

13. Pruebas de Aceptación

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

Técnica: 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:

 44

 Especificación de requisitos del sistema.

 Manual de usuario.

 Manual de administrador.

 Realizar Pruebas de estilo

14. Pruebas de Campo

Su objetivo es Correr el sistema en el ambiente real para encontrar errores y validar el producto

contra sus especificaciones originales. Esta realiza un subconjunto válido de pruebas de sistema.

Técnica: Determinar que pruebas de sistema serán corridas para validar el sistema en producción.
 45

LISTAS DE REFERENCIAS

Pressman, R. (2010). Ingeniería del Software Un enfoque práctico. Séptima edición. Editorial Mc

Graw Hill. Recuperado de https://www.freelibros.org/ingenieria/ingenieria-del-software-un-

enfoque-practico-7ma-edicion-roger-s-pressman.html 17 de mayo 2019

Terrera G. (2016). TestingBaires. Pruebas de Caja Negra y un enfoque Práctico. Recuperado de

https://testingbaires.com/2017/02/26/pruebas-caja-negra-enfoque-practico/ 18 de mayo 2019.

Norén, A. (2016). Pruebas de humo, su aplicación al flujo de un producto de software financiero.

Recuperado de https://www.testingcolombia.com/pruebas-de-humo-su-aplicacion-al-flujo-de-un-

producto-financiero/ 18 de mayo de 2019

 46

BIBLIOGRAFÍA

 Ingeniería del Software Un enfoque práctico. Séptima edición. Editorial Mc Graw Hill

 La oficina de proyectos de informática. La web sobre gerencia de proyectos de informática,

software y tecnología. http://www.pmoinformatica.com

 Testing Colombia. Comunidad para compartir conocimientos acerca de pruebas de

software. https://www.testingcolombia.com/
 47

CONCLUSIONES

Las estrategias de prueba de software son una parte fundamental de la validación y verificación

del software y reúne todas las técnicas de diseño de casos de prueba en una serie de pasos bien

definidos y bien ejecutados que llevan a la construcción correcta del software.

Cada estrategia de prueba se desarrolla de acuerdo al nivel de desarrollo en el que este el software

y se prueba tanto cada módulo individual en cada fase como también cuando ya está desarrollado

el software como un todo.