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
 TABLA DE CONTENIDO

INTRODUCCIÓN ..........................................................................................................................1
ESTRATEGIAS DE PRUEBAS DE SOFTWARE .......................................................................2
1. Un enfoque estratégico para la prueba de software .....................................................................2
1.1. Verificación y Validación .................................................................................................3
1.2. Organización de las pruebas de Software ..........................................................................3
1.3. Estrategia de la prueba del Software. Visión general ........................................................3
1.4. Criterios para completar las pruebas .................................................................................4
2. Pruebas funcionales de software .................................................................................................2
2.1. Pruebas de Interoperabilidad ............................................................................................3
2.2. Pruebas de Caja Negra.......................................................................................................4
2.2.1. Técnicas de pruebas de caja negra .............................................................................4
2.2.2. Pruebas de Caja Negra y Pruebas Funcionales ..........................................................5
2.2.2.1. Pruebas de casos de uso ...................................................................................6
2.2.2.2. Pruebas de historias de usuario ........................................................................6
2.3. Pruebas de Caja Blanca .....................................................................................................7
2.3.1. Técnicas de prueba de caja blanca .............................................................................7
2.3.1.1. Camino básico .................................................................................................8
2.3.1.2. Notación de Grafo de Flujo .............................................................................9
3. Pruebas no funcionales de software ............................................................................................2
3.1. Pruebas de Desempeño .....................................................................................................3
3.2. Pruebas de Carga ..............................................................................................................3
3.3. Pruebas de Estrés ..............................................................................................................3
3.4. Pruebas de Usabilidad ......................................................................................................3
3.5. Pruebas de Mantenibilidad ...............................................................................................3
3.6. Pruebas de Escalabilidad ..................................................................................................3
3.7. Pruebas de Resistencia .....................................................................................................3
3.8. Pruebas de Recuperación ..................................................................................................3
3.9. Pruebas de Configuración .................................................................................................3
4. Estrategias de prueba para Software Convencional .....................................................................5
4.1. Prueba de Unidad ..............................................................................................................5
 4.1.1. Consideraciones de las pruebas de Unidad
4.1.2. Procedimientos de prueba de unidad
4.2. Pruebas de Integración ......................................................................................................7
4.2.1. Integración descendente .............................................................................................8
4.2.2. Integración ascendente ...............................................................................................9
4.3. Prueba de regresión ...........................................................................................................7
4.4. Prueba de humo .................................................................................................................7
5. Estrategias de prueba para Software Orientado a Objeto ..........................................................10
5.1. Prueba de Unidad en el contexto OO ..............................................................................10
5.2. Prueba de Integración en el contexto OO ........................................................................10
6. Pruebas de validación ................................................................................................................11
6.1. Criterios de pruebas de validación ..................................................................................12
6.2. Revisión de la Configuración ..........................................................................................12
6.3. Pruebas Alfa y Beta .........................................................................................................12
7. Pruebas del Sistema ...................................................................................................................13
7.1. Pruebas de recuperación ..................................................................................................13
7.2. Pruebas de Seguridad ......................................................................................................13
7.3. Pruebas de Esfuerzo ........................................................................................................14
7.4. Pruebas de Rendimiento ..................................................................................................14
7.5. Pruebas de Despliegue .....................................................................................................14
LISTA DE REFERENCIAS ..........................................................................................................15
BIBLIOGRAFÍA ...........................................................................................................................16

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.

ESTRATEGIAS DE PRUEBAS DE SOFTWARE

Parte fundamental de una estrategia de prueba 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. A la vez una estrategia de prueba de software debe hacer cumplir las normas
establecidas dentro de estos lineamientos, con el fin de planificar el seguimiento del avance del
proyecto.

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.

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.

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.

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.

2.2.1. Las Técnicas de pruebas de caja negra

 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.
 Se pueden definir particiones tanto para datos válidos como no válidos (datos que deben
ser rechazados por el sistema).
 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.
  A partir de allí se definen pruebas para cubrir todos o parte de las particiones de datos
válidos y datos inválidos.
 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

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.

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

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

Su 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
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,
NOR lógicos en una sentencia condicional), la generación del grafo de flujo se hace un poco más
complicada.
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.

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

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.

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.

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

 Los componentes en el nivel inferior se combinan en grupos, que realizan una subfunción
de software específica.
 Se escribe un controlador (un programa de control para pruebas) a fin de coordinar la
entrada y salida de casos de prueba.
 Se prueba el grupo.
 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.

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

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

7.2.Pruebas de Seguridad

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

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.

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.

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.
 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 4 de mayo 2018
 BIBLIOGRAFÍA

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