Pruebas de software

FAVA - Formación en Ambientes Virtuales de Aprendizaje - SENA - Servicio Nacional de Aprendizaje

Tabla de contenido 4.3.1. Prueba del ciclo del negocio

1.Introducción 4.3.2. Prueba de GUI o Interfaz

2. Mapa conceptual 4.3.3. Prueba de configuración

3. Pruebas de software 4.3.4. Prueba de estilo

3.1. Propósitos 4.3.5. Prueba de aceptación

3.2. Metodología 4.3.6. Prueba de instalación

3.2.1. Etapa de planeación de pruebas 4.3.7. Prueba funcional

3.2.2. Etapa de diseño de pruebas 4.3.8. Prueba de documentación y

procedimiento
3.2.3. Etapa de implementación de pruebas
4.3.9. Prueba de usabilidad
3.2.4. Etapa de evaluación de criterios de salida
4.3.10. Prueba de campo
3.2.5. Etapa de cierre del proceso
4.4. Pruebas de validación a
3.3. Pruebas de acuerdo con el modelo de software aplicaciones genéricas

4. Estrategias de prueba para software convencional 4.4.1. Prueba Alfa

(para desarrolladores)
4.1. Pruebas de unidad
4.4.2. Prueba Beta (para usuarios)
4.1.1. Prueba de unidad
4.5. Pruebas de sistema
4.2. Pruebas de integración
4.5.1. Pruebas de recuperación
4.2.1. Prueba de integración descendente
4.5.2. Pruebas de seguridad
4.2.2. Prueba de integración ascendente
4.5.3. Pruebas de esfuerzo
4.2.3. Prueba de regresión
4.5.4. Pruebas de rendimiento
4.2.4. Prueba de humo
5. Estrategias de prueba para software
4.3. Pruebas de validación a sistemas a la medida orientado a objetos

FAVA - Formación en Ambientes Virtuales de Aprendizaje - SENA - Servicio Nacional de Aprendizaje

 5.1. Prueba de unidad en el contexto OO

5.2. Prueba de integración en el contexto OO

6. Prueba de aplicaciones convencional

6.1. Pruebas de caja blanca

6.1.1. Prueba de cubrimiento

6.1.2. Prueba de condición

6.1.3. Prueba de bucle

6.2. Pruebas de caja negra

7. Glosario

8. Referencias bibliográficas

Control del documento

Control de cambios

Créditos

Creative Commons

FAVA - Formación en Ambientes Virtuales de Aprendizaje - SENA - Servicio Nacional de Aprendizaje

1. Introducción

En la presente actividad de aprendizaje se abordarán los conceptos, propósitos, metodología,

estrategias y pruebas a realizar en el proceso y construcción del software. Las pruebas (Software
Testing), hacen referencia al conjunto de procesos que se realizan para identificar posibles fallos de
funcionamiento, configuración o usabilidad de una aplicación.

En tal sentido, se revisarán las estrategias de prueba de software, las pruebas a aplicar en aplicaciones
convencionales, para software orientado a objetos y software orientado a sistemas web.

2. Mapa conceptual

Fuente: SENA

FAVA - Formación en Ambientes Virtuales de Aprendizaje - SENA - Servicio Nacional de Aprendizaje

3. Pruebas de software

Las aplicaciones (o software en general), son propensas a tener fallos, pues sus procesos son
diseñados e implementados por el ser humano y la presencia de estos errores puede contribuir al
fracaso de cualquier proyecto e impactar de forma negativa a la empresa.

En tal sentido, al interior del proceso de control de la calidad, se hace necesario aplicar pruebas de
software, que garanticen la satisfacción del cliente. Y estas deben ser consideradas como un conjunto
de actividades insertas dentro del mismo desarrollo y construcción del software.

La prueba de software corresponde a un tema más amplio, que usualmente se conoce como verificación
y validación (V&V). La verificación, comprende el conjunto de tareas que garantizan que el software
implemente correctamente una función específica.

Según Pressman (2010) “La validación, es un conjunto diferente de tareas que aseguran que el software
en construcción, siga los requerimientos del cliente” (p. 380). De acuerdo al modelo utilizado en la
construcción del software, se aplican determinados tipos de pruebas, las cuales se pueden aplicar en
cualquier momento del proceso de análisis, diseño, desarrollo e implementación.

3.1. Propósitos

Pressman (2010) comenta que “La aplicación de pruebas de software se realiza para descubrir errores
que se cometieron de manera inadvertida en el proceso de diseño y construcción” (p.381). Según la
enciclopedia web EcuRed (2012), los objetivos de las pruebas de software son:

“Detectar defectos en el software; verificar la integración adecuada de los componentes; verificar que todos
los requisitos se han implementado correctamente; identificar y asegurar que los defectos encontrados se han
corregido antes de entregar el software al cliente y diseñar casos de prueba que sistemáticamente saquen a
la luz diferentes clases de errores, haciéndolo con la menor cantidad de tiempo y esfuerzo”.

3.2. Metodología

La prueba de software debe comenzar de lo pequeño hacia lo grande. Para Pressman (2010),

Las primeras etapas de prueba se enfocan sobre un solo componente, o un pequeño grupo de componentes
relacionados y se aplican para descubrir errores en los datos y en la lógica de procesamiento por componente.

Después estos deben integrarse hasta que se construya el sistema completo. La prueba de software es un
conjunto de actividades que pueden planearse por adelantado y realizarse de manera sistemática. Por esta
razón, durante el proceso de desarrollo debe definirse una plantilla de prueba, que integre en un conjunto de
pasos con métodos y técnicas específicos (p. 383).

La aplicación de pruebas se realiza teniendo en cuenta una serie de etapas; a continuación, se

presentan cinco etapas típicas dentro de un proceso formal, según clasificación presentada por Zapata
(2013):

FAVA - Formación en Ambientes Virtuales de Aprendizaje - SENA - Servicio Nacional de Aprendizaje

3.2.1. Etapa de planeación de pruebas

Es la etapa en la que se ejecutan las primeras actividades correspondientes al proceso de pruebas y

tiene como resultado un entregable denominado Plan de Pruebas, el cual debe tratar los siguientes
aspectos:

• Alcance de la prueba: determina el listado de funcionalidades del producto y/o software que serán
probados durante el transcurso de la prueba.

• Tipos de prueba: orientado a determinar qué tipos de pruebas requiere el producto.

• Estrategia de pruebas: determinar a través de un análisis de riesgos qué pruebas se deben tener
en cuenta para ser aplicadas.

• Criterios de salida: entre los integrantes del grupo, se definen las condiciones a considerar después
de que la actividad de pruebas fue finalizada.

• Otros aspectos: tener en cuenta estimación de tiempos, los roles y/o recursos que harán parte del
proceso, la preparación del entorno de pruebas, cronograma base, entre otros.

3.2.2. Etapa de diseño de pruebas

Luego de que se elabore y realice la aprobación del Plan de Pruebas, los integrantes del equipo de
trabajo deberán dar inicio al análisis de toda la documentación existente con respecto al sistema,
como por ejemplo casos de uso, arquitectura del sistema, diseños, manuales de usuario, historias de
usuario, manuales técnicos, entre otros.

3.2.3. Etapa de implementación de pruebas

Esta se deberá dar con la creación de los datos de prueba que sean necesarios para poder ejecutar
los casos diseñados.

3.2.4. Etapa de evaluación de criterios de salida

Esta etapa es necesaria para poder determinar la factibilidad de dar por finalizado un ciclo de pruebas.
Para poder lograr esto, es conveniente comparar los resultados frente a las métricas definidas. Si
estas pruebas no son superadas, no es posible continuar con la siguiente etapa.

3.2.5. Etapa de cierre del proceso

En esta etapa se deberán cerrar las incidencias reportadas. Se verificará si los entregables planeados
han sido aprobados; se terminan y aprueban los documentos de soporte de la prueba y se analizan las
lecciones aprendidas para aplicar a futuros proyectos.

FAVA - Formación en Ambientes Virtuales de Aprendizaje - SENA - Servicio Nacional de Aprendizaje

3.3. Pruebas de acuerdo con el modelo de software

El proceso de pruebas de software, en el ciclo de vida del software, busca generar mayor confianza
en el cumplimiento de los requerimientos funcionales y no funcionales. Para Mayorga y Arce (2013),
se hace necesaria la implementación de mecanismos que permitan garantizar la calidad del software,
estos se denominan modelos de pruebas de software. Existen varios tipos de esquemas.
Tabla 1.
Modelos de pruebas de software

Modelo Características

Fuente: SENA

Para cumplir con un procedimiento de pruebas de software, se deberán definir estándares y establecer
procedimientos mediante los cuales, se pueda comparar lo alcanzado durante cada una de las fases.

4. Estrategias de prueba para software convencional

Durante muchos años, se confió en el análisis, diseño e inteligencia del programador cuando se trataba
de construir un software. Actualmente existen modernas técnicas de diseño que ayudan a reducir
el número de errores iniciales que son inherentes al código. De igual modo, diferentes métodos de
prueba comienzan a agruparse en estrategias.

Existen dos maneras de probar el software. La primera consiste en esperar hasta que el sistema esté
completamente construido y aplicar pruebas sobre el sistema total, con la esperanza de encontrar
errores. Este tipo de estrategia, no es la más adecuada.

FAVA - Formación en Ambientes Virtuales de Aprendizaje - SENA - Servicio Nacional de Aprendizaje

La segunda forma está orientada a realizar pruebas al final de la construcción de alguna parte del
sistema. Para Pressman (2010) este enfoque, “aunque menos atractivo para muchos, puede ser muy
efectivo” (p.368).

Desde una mirada procedimental, las pruebas de software en la Ingeniería del Software, son
generalmente un conjunto de cuatro pasos, que se articulan de forma secuencial.

Figura 1. Estrategia de pruebas

Fuente: Pressman (2010)

Para Pressman (2010), “Las pruebas se focalizan inicialmente en cada componente de manera
individual, lo que garantiza que funcionen adecuadamente como unidad. De ahí el nombre de prueba
de unidad”. A continuación, en la prueba de integración, los componentes deben ensamblarse o
integrarse para formar el sistema del software completo. Se abordan los conflictos asociados con los
problemas duales de verificación y construcción de programas.

Durante la integración, se usan más las técnicas de diseño de casos de prueba que se enfocan en
entradas y salidas, aunque también pueden usarse técnicas que ejercitan rutas de programa específicas
para asegurar la cobertura de las principales rutas de control.

Figura 2. Pasos de la prueba de Software

Fuente: Pressman (2010)

FAVA - Formación en Ambientes Virtuales de Aprendizaje - SENA - Servicio Nacional de Aprendizaje

Posteriormente, se realizan una serie de pruebas de orden superior. En la prueba de validación,
deben evaluarse criterios de validación (establecidos durante el análisis de requerimientos). La prueba
de validación proporciona la garantía final de que el software cumple con todos los requerimientos
informativos, funcionales, de comportamiento y de rendimiento.

Finalmente, se aplica la prueba del sistema, la cual verifica que todos los elementos se mezclan de
manera adecuada, lográndose el funcionamiento y rendimiento global del sistema.

4.1. Pruebas de unidad

En las pruebas de unidad o unitarias, se evalúa el funcionamiento individual de cada módulo, escribiendo
casos de prueba para cada funcionalidad o método en el módulo, de forma que se determine la
integridad del mismo (Mayorga & Arce, 2013, p.32).

Se focaliza en ejecutar cada módulo o unidad mínima a ser probada, (Ejemplo: Una clase). Esta
situación provee un mejor modo de manejar la integración de las unidades en componentes mayores.
Busca asegurar que el código funciona de acuerdo con las especificaciones y que el módulo lógico es
válido.

4.1.1. Prueba de unidad

Según Mayorga y Arce (2013), esta prueba permite la verificación de las unidades de un software,
sean estas un componente o un módulo. La ventaja de esta prueba consiste en verificar la lógica del
procesamiento interno que sea aplicable a varios componentes de un programa al tiempo.

Figura 3. Prueba de Unidad

Fuente: Jorge Bustillos 2014

FAVA - Formación en Ambientes Virtuales de Aprendizaje - SENA - Servicio Nacional de Aprendizaje

4.2. Pruebas de integración

Las pruebas de integración pretenden verificar que el conjunto de los módulos de un sistema funciona
adecuadamente (Mayorga y Arce, 2013).

Están orientadas a: 1. Identificar errores introducidos por la combinación de programas probados

unitariamente; 2. Verificar que las interfaces entre las entidades externas (usuarios) y las aplicaciones
funcionan correctamente; 3. Probar que las especificaciones de diseño sean alcanzadas y 4.
Determinar el enfoque para avanzar desde un nivel de integración de los componentes siguientes
(Abad, 2005).

Es una técnica sistemática de integración incremental, para construir la arquitectura del software,
mientras se aplican las pruebas para descubrir errores asociados con la interfaz. Su objetivo es
tomar componentes a los que se aplicó una prueba de unidad y construir una estructura de programa
que determine el diseño.

No obstante, en algunos casos la prueba de integración “se utiliza para intentar una integración
que no sea incremental; enfoque llamado big bang, el cual, combina todos los componentes por
anticipado y se prueba todo el programa como un todo” (Mayorga & Arce, 2013, p. 32).

El programa se prueba como un todo y se descubren errores en conjunto. La corrección se dificulta,

pues el aislamiento de las causas se complica por la vasta extensión de todo el programa. “Una vez
corregidos estos errores, otros nuevos aparecen y el proceso continúa en un bucle aparentemente
interminable” (Pressman, 2010, p. 392).

Las pruebas de integración incremental son lo contrario al enfoque Big Bang. El programa se
construye y prueba en pequeños incrementos, donde los errores son más fáciles de aislar y corregir;
las interfaces tienen más posibilidades de probarse por completo; y puede aplicarse un enfoque de
prueba sistemático.

4.2.1. Prueba de integración descendente

La principal dificultad de esta prueba es localizar los errores. Se aplica de tal manera que los módulos
se integran jerárquicamente hacia abajo, comenzando con el módulo de control principal (M1) según
la figura 4. Los módulos subordinados al módulo de control principal se incorporan en la estructura,
primero en profundidad o primero en anchura.

10

FAVA - Formación en Ambientes Virtuales de Aprendizaje - SENA - Servicio Nacional de Aprendizaje

 Figura 4. Prueba de Integración descendente
Fuente: SENA

4.2.2. Prueba de integración ascendente

Para lograr esta integración, es necesario añadir componentes desde una configuración mínima y
probar después de añadir uno a uno el cambio generado en el funcionamiento del sistema cada vez
que ocurre un incremento (Mayorga y Arce, 2013).

Mc

Ma Mb

D1 D2 D3
Grupo 3

Grupo 2
Grupo 1

Figura 5. Prueba de integración ascendente

Fuente: SENA

11

FAVA - Formación en Ambientes Virtuales de Aprendizaje - SENA - Servicio Nacional de Aprendizaje

4.2.3. Prueba de regresión

El proceso de ejecutar un conjunto existente de pruebas, se denomina pruebas de regresión. Cuando

se integra un nuevo incremento, hay que volver a ejecutar las pruebas para incrementos previos,
así como las nuevas pruebas requeridas para verificar la nueva funcionalidad del sistema. Si las
pruebas de regresión muestran problemas, entonces hay que verificar si estos son problemas en el
incremento previo o si son debidos al incremento añadido de funcionalidad (Mayorga y Arce, 2013).

4.2.4. Prueba de humo

Su propósito se focaliza en probar el sistema constantemente buscando que saque “humo” o falle.
En algunos proyectos, este tipo de prueba va junto con las pruebas funcionales. Permite detectar
problemas que por lo regular no son detectados en las pruebas normales. Algunas veces, si las
pruebas ocurren en etapas tardías, esta será una forma de garantizar el buen desarrollo. Las pruebas
de humo no son exhaustivas, pero van de extremo a extremo de la aplicación (Abad, 2005).

4.3. Pruebas de validación a sistemas a la medida

Abad (2005), comenta que deberá presentarse un listado de pruebas de validación a aplicaciones a
sistemas a la medida, las cuales están orientadas a la validación del funcionamiento de software a
la medida del modelo de negocio.

4.3.1. Prueba del ciclo del negocio

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

4.3.2. Prueba de GUI o interfaz

Por medio de esta prueba se verifica la interacción del usuario con el software. El objetivo será
asegurar que la interfaz presente una adecuada navegación por medio de diferentes funcionalidades.
Además, permite asegurar que los objetos de la interfaz que se van a adoptar, se encuentren dentro
de estándares de la industria.

4.3.3. Prueba de configuración

Con este tipo de pruebas se puede verificar la operación del sistema en diferentes configuraciones de
hardware y software. Las especificaciones para las estaciones de trabajo, equipos de red y servidores,
pueden presentar variaciones en la mayoría de los ambientes de producción.

12

FAVA - Formación en Ambientes Virtuales de Aprendizaje - SENA - Servicio Nacional de Aprendizaje

De igual manera las estaciones pueden tener diferentes versiones de software instaladas (drivers,
sistemas operativos, entre otros) y en cualquier momento se pueden utilizar diferentes combinaciones.
Con frecuencia el número de configuraciones posibles es demasiado grande, para intentar una
prueba de cada una de ellas, pero el programa debe probarse al menos con cada tipo de dispositivo
y con las configuraciones mínima y máxima posibles.

4.3.4. Prueba de estilo

Comprueba que la aplicación sigue los estándares de estilo propios del cliente, tales como el formato
de las ventanas, colores corporativos, tipos de letra, entre otros.

4.3.5. Prueba de aceptación

Esta prueba está destinada a confirmar que el producto está listo para el uso operativo. Suele ser
un subconjunto de las pruebas de sistema y se ejecuta antes de que la aplicación se instale dentro
de un ambiente de producción. Su ejecución se realiza por parte del cliente, o por un especialista de
la aplicación.

Está orientada a determinar si el sistema satisface los criterios de aceptación, validando los requisitos
que han sido levantados para el desarrollo, incluyendo la documentación y los procesos de negocio.
Basado en esta prueba, el cliente determina si acepta o rechaza el sistema.

4.3.6. Prueba de instalación

Está orientada a verificar y validar que el sistema se instale apropiadamente en cada computador de
cliente, bajo estas condiciones:

● Instalaciones nuevas, nuevas máquinas a las que nunca se les ha instalado el sistema.

● Actualizar máquinas previamente instaladas con el sistema.

● Instalar versiones viejas en máquinas previamente instaladas con el sistema.

4.3.7. Prueba funcional

Prueba orientada a garantizar el análisis apropiado de los requisitos funcionales, incluyendo la

navegación, entrada de datos, procesamiento y obtención de resultados. En tal sentido, este tipo de
pruebas se focalizan en los requisitos funcionales, pueden estar basadas directamente en los casos
de uso, funciones y reglas del negocio.

13

FAVA - Formación en Ambientes Virtuales de Aprendizaje - SENA - Servicio Nacional de Aprendizaje

4.3.8. Prueba de documentación y procedimiento

Se focaliza en evaluar la exactitud y claridad de la documentación del usuario y determina si el manual

de procedimientos trabajará correctamente como parte integral del sistema.

4.3.9. Prueba de usabilidad

Su objeto está orientado a determinar la usabilidad del sistema. En tal sentido, busca medir qué tan
fácil el usuario podrá usar y entender la aplicación, tratando de identificar las áreas de diseño que
dificultan el uso del sistema por parte del usuario.

4.3.10. Prueba de campo

Esta prueba está orientada a ejecutar el sistema en un ambiente real para encontrar errores y validar
el producto contra sus especificaciones originales. En tal sentido, determina las pruebas de sistema
que serán corridas para validar el sistema en producción.

4.4. Pruebas de validación a aplicaciones genéricas

Las pruebas de validación a aplicaciones genéricas están orientadas a la validación del funcionamiento
del software genérico de acuerdo con los requerimientos funcionales del cliente.

4.4.1. Prueba Alfa (para desarrolladores)

La verificación en la prueba Alfa, involucra la ejecución por partes o de todo del sistema en ambientes
simulados, con el fin de encontrar errores. La retroalimentación produce cambios en el software para
resolver los errores y fallas que se descubren.

4.4.2. Prueba Beta (para usuarios)

Está orientada para que un grupo de usuarios finales, por un tiempo determinado, utilice y realice la
validación del software en un ambiente real.

4.5. Pruebas de sistema

Según Zapata (2013), “Este tipo de prueba debe ser ejecutada idealmente por un equipo de pruebas
ajeno al equipo de desarrollo” (p.43). La obligación de este equipo, consiste en la ejecución de
actividades de prueba, con las que debe verificar que la funcionalidad total de un sistema fue
implementada, de acuerdo a los documentos de especificación definidos en el proyecto.

Los casos de prueba a diseñar en este nivel, cubren aspectos funcionales y no funcionales del
sistema. Para su diseño, el equipo debe utilizar bases de prueba entregables como: requerimientos
iniciales, casos de uso, historias de usuario, diseños, manuales técnicos y de usuario final, entre
otros.

14

FAVA - Formación en Ambientes Virtuales de Aprendizaje - SENA - Servicio Nacional de Aprendizaje

4.5.1. Pruebas de recuperación

Es una prueba del sistema que fuerza al software a fallar en varias formas y que verifica que la
recuperación se realice de manera adecuada. Si la recuperación es automática (realizada por el
sistema en sí), se evalúa el reinicio, los mecanismos de puntos de verificación, la recuperación
de datos y la reanudación para correcciones. Si la recuperación requiere intervención humana, se
evalúa el tiempo medio de reparación (TMR) para determinar si está dentro de límites aceptables
(Pressman, 2010).

4.5.2. Pruebas de seguridad

La interrupción abarca un amplio rango de actividades hacker. La prueba de seguridad comprueba

que los mecanismos de protección integrados en el sistema realmente lo protejan de irrupciones
inapropiadas. Quien aplica este tipo de prueba, desempeña el papel del individuo que desea entrar en
el sistema (Mayorga & Arce, 2013).

4.5.3. Pruebas de esfuerzo

También llamadas pruebas de resistencia (stress). Se diseñan para enfrentar los programas a
situaciones anormales, para evaluar el tiempo transcurrido antes de que falle o los recursos que utiliza
antes de bloquearse.

4.5.4. Pruebas de rendimiento

Evalúa el rendimiento del sistema bajo condiciones normales, cuando los componentes del software
se encuentran totalmente integrados, teniendo en cuenta todos los elementos del sistema y así poder
juzgar su verdadero desempeño ante diversas situaciones, condiciones y contextos (Mayorga & Arce,
2013).

5. Estrategias de prueba para software orientado a objetos

El objetivo de esta estrategia de prueba es encontrar el mayor número posible de errores con una
cantidad manejable de esfuerzo aplicado durante un lapso realista.

5.1. Prueba de unidad en el contexto OO

Cuando se considera software orientado a objeto, el concepto de unidad cambia. La encapsulación

determina la definición de clases y objetos. Esto significa que cada clase y cada instancia de una clase
empaquetan los atributos (datos) y las operaciones que manipulan estos datos. Por lo general, una
clase encapsulada es el foco de la prueba de unidad.

No obstante, las operaciones (métodos) dentro de la clase son las unidades comprobables más
pequeñas.

15

FAVA - Formación en Ambientes Virtuales de Aprendizaje - SENA - Servicio Nacional de Aprendizaje

“Puesto que una clase puede contener algunas operaciones diferentes, y una operación particular
puede existir como parte de algunas clases diferentes, las tácticas aplicadas a la prueba de unidad
deben cambiar”(Pressman, 2010).

5.2. Prueba de integración en el contexto OO

Existen dos estrategias diferentes para la prueba de integración de los sistemas OO. La primera, la
prueba basada en Hebra o Hilo, integra el conjunto de clases requeridas para responder a una entrada
o evento para el sistema. Cada hilo se integra y prueba de manera individual.

El segundo enfoque de integración, la prueba basada en uso, comienza la construcción del sistema
al probar dichas clases (llamadas clases independientes) que usan muy pocas clases servidor (si
es que usan alguna). Después de probar las clases independientes, se prueba la siguiente capa de
clases, llamadas dependientes, que usan las clases independientes. Esta secuencia de probar capas
de clases dependientes continúa hasta que se construye todo el sistema (Pressman, 2010).

6. Prueba de aplicaciones convencional

Existen otras estrategias que se aplican a la realización de pruebas para aplicaciones convencionales,
que a continuación se analizarán al detalle.

6.1. Pruebas de caja blanca

La prueba de caja blanca del software se basa en el examen cercano de los detalles de procedimiento.
Las rutas lógicas a través del software y las colaboraciones entre componentes se ponen a prueba al
revisar conjuntos específicos de condiciones y/o bucles. Existe tres tipos de pruebas de caja blanca:

- Pruebas de condición

- Pruebas de cubrimiento

- Pruebas de bucle

6.1.1. Prueba de cubrimiento

Permiten ejecutar al menos una vez cada sentencia, para la cual se necesitan varios casos de prueba
que permitan:

● Determinar posibles “caminos” independientes.

● Que cada condición se cumpla en un caso y en otro no. En general, se necesitan tantos casos como
condiciones, más uno (número ciclomático).

16

FAVA - Formación en Ambientes Virtuales de Aprendizaje - SENA - Servicio Nacional de Aprendizaje

● Determinar la imposibilidad de cubrir el 100 %.

● Descubrir el código que nunca se ejecuta: condiciones imposibles.

Ejemplo de estas pruebas, son la detección y notificación de errores internos en un código sin errores.

6.1.2. Prueba de condición

Permite cumplir o no, partes de una condición, para ello se necesitan varios casos de prueba que
permitan:

● Determinar expresiones simples en las condiciones.

● Una por cada operando lógico o comparación.

● Cada expresión simple deberá cumplirse en un caso y en otro no, siendo decisiva en el resultado.

● Determinar la imposibilidad de cubrir el 100 %.

● Validar y probar expresiones simples no independientes.

6.1.3. Prueba de bucle

Se utilizan para conseguir números de repeticiones especiales a través de bucles simples que permitan:

● Repetir cero, una y dos veces.

● Repetir un número medio (típico) de veces.

● Repetir el máximo-1, máximo y ¡máximo +1!

Bucles anidados

● Repetir un número medio (típico) los bucles internos, el mínimo los externos, y variar las repeticiones
del bucle intermedio ensayado.

● Ensayarlo con cada nivel de anidamiento.

6.2. Pruebas de caja negra

Se refiere a las pruebas que se llevan a cabo en la interfaz del software. Una prueba de caja negra
examina algunos aspectos fundamentales de un sistema con poca preocupación por la estructura
lógica interna del software (Mayorga y Arce, 2013).

17

FAVA - Formación en Ambientes Virtuales de Aprendizaje - SENA - Servicio Nacional de Aprendizaje

Mediante la aplicación de estas pruebas se busca:

● Probar el desempeño del sistema en su entorno.

● Enfocarse en las entradas y salidas, independiente de su funcionamiento interno.

● Enfocarse en asegurar que la comunicación entre módulos o componentes del sistema sea acorde
a lo especificado.

● Pruebas en que se conoce solo la interfaz.

● Se procura ejercitar cada elemento de la interfaz.

7. Glosario

OO: sigla que indica orientación a objetos.

Pruebas de aceptación: es una estrategia que integra pruebas como: Prueba de integración
descendente, Prueba de integración ascendente, Prueba de regresión, y Prueba de humo. Está
orientada a verificar que el conjunto de los módulos de un sistema funcione adecuadamente al
mismo tiempo.

Pruebas de caja blanca: tipo de prueba orientada a evaluar los procedimientos, condiciones y
bucles propios del desarrollo de software.

Pruebas de caja negra: tipo de prueba orientada a evaluar las interfaces del software.

Pruebas de integración: es una estrategia que integra pruebas como: Prueba de integración
descendente, Prueba de integración ascendente, Prueba de regresión, y Prueba de humo. Está
orientada a verificar que el conjunto de los módulos de un sistema funcione adecuadamente en
conjunto.

Pruebas de unidad: es una estrategia que integra una prueba con el mismo nombre. Está orientada
a evaluar el funcionamiento individual de cada módulo.

Pruebas de validación a aplicaciones genéricas: es una estrategia que integra pruebas como:
Prueba alfa (para desarrolladores), y Prueba beta (para usuarios). Está orientada a la validación del
funcionamiento del software genérico de acuerdo con los requerimientos funcionales del cliente.

Pruebas de validación a sistemas a la medida: es una estrategia que integra pruebas como: Prueba
del ciclo del negocio, Prueba de GUI o interfaz, Prueba de configuración, Prueba de estilo, Prueba
de aceptación, Prueba de instalación, Prueba funcional, Prueba de documentación y procedimiento,
Prueba de usabilidad, y Prueba de campo. Está orientada a la validación del funcionamiento de
software a la medida del modelo de negocio.

18

FAVA - Formación en Ambientes Virtuales de Aprendizaje - SENA - Servicio Nacional de Aprendizaje

Pruebas del sistema: es una estrategia que integra pruebas como: Pruebas de recuperación,
Pruebas de seguridad, Pruebas de esfuerzo, y Pruebas de rendimiento. Está orientada a ejecución
de actividades de prueba en donde se debe verificar que la funcionalidad total de un sistema fue
implementada de acuerdo a los documentos de especificación definidos en el proyecto.

WEBAPPS: término que se utiliza para hacer referencia a una página web, condicionada a cualquier
dispositivo móvil. Su condicionamiento se debe a la versión de HTML5 y CSS3.

8. Referencias bibliográficas

Abad Londoño, J. (2005, Julio 1). Tipos de prueba de software. [Web log post] Recuperado de
http://ing-sw.blogspot.com.co/2005/04/tipos-de-pruebas-de-software.html

Bustillos, Jorge (2014). Enfoque estratégico para la prueba de software. Recuperado de

https://es.slideshare.net/JorgeCarlos3/enfoque-estrategico-para-la-prueba-de-software

Calderón Hernández, M. (2014). Modelo para pruebas de software y auditoría en entorno Microsoft.Net.
Recuperado de http://www.monografias.com/trabajos20/pruebas-de-software/pruebas-de-software2.
shtml

EcuRed - Conocimiento con todos y para todos. (s.f.). Pruebas de software. Recuperado de
https://www.ecured.cu/Pruebas_de_software

Fiestas, J. (2014, marzo 3). QA: Pruebas para asegurar la calidad del producto software. [Web log
post]. Recuperado de http://blog.elevenpaths.com/2014/09/qa-pruebas-para-asegurar-la-calidad-del.
html

Guru, S. (Productor) (2015). Testing para dummies. [Archivo de video] Recuperado de

https://www.youtube.com/watch?v=jk4wKUHUZAU

Gutiérrez, J., Escalona, M., Mejias, M., & Reina, A. (2006). Modelos de pruebas para pruebas del
sistema. Recuperado de http://ceur-ws.org/Vol-227/paper07.pdf

Guzmán Cortéz, O. (s.f.). Aplicación práctica del diseño de pruebas de software a nivel de programación.
Recuperado de https://www.icesi.edu.co/revistas/index.php/sistemas_telematica/article/view/935

It-Mentor - ITM. (s.f.). Pruebas de Software. Recuperado de

http://materias.fi.uba.ar/7548/Pruebas-Intro.pdf

Martínez España, R. (Dirección). (2015). Ingeniería del software - pruebas de software [Archivo de
video] Recuperado de https://www.youtube.com/watch?v=CSgdhH5gp_U

19

FAVA - Formación en Ambientes Virtuales de Aprendizaje - SENA - Servicio Nacional de Aprendizaje

Mayorga Pabón, J., & Arce Arias, Y. (2013). Material de formación actividad de aprendizaje 3: Pruebas
de Software. Armenia - Quindío: Centro de Comercio y turismo - Regional Quindío SENA.

Mifsu, E. ( 2012). Monográfico: Introducción a la seguridad informática. Recuperado de

http://recursostic.educacion.es/observatorio/web/es/software/software-general/1040-introduccion-a-
la-seguridad-informatica?showall=1

PMO Infomática.com. (2015). Pruebas de software. Recuperado de

http://www.pmoinformatica.com/p/pruebas-de-software.html

Pressman, R. (2010). Calidad de Software. En R. S. Pressman, ingeniería del software un enfoque

práctico. Ciudad de México: Mac Graw Hill.

SENATV (2013, Abril 1). Pruebas de Software. [Archivo de video]. Recuperado de

https://www.youtube.com/watch?v=bWNRTDAO_7M

Universidad Nacional de México - UNAM. (s.f.). Metodologías y procesos de análisis de software. Capítulo
2. Recuperado de http://www.ptolomeo.unam.mx:8080/xmlui/bitstream/handle/132.248.52.100/175/
A5%20Cap%C3%ADtulo%202.pdf?sequence=5

Zapata, J. (2013). Niveles de prueba del software. Recuperado de

https://pruebasdelsoftware.wordpress.com/

Control del documento

Control de cambios

20

FAVA - Formación en Ambientes Virtuales de Aprendizaje - SENA - Servicio Nacional de Aprendizaje

 Atribución - No Comercial - Sin Derivar.
(BY-NC-ND)
No se permite un uso comercial de la obra original ni la
generación de obras derivadas.

21

FAVA - Formación en Ambientes Virtuales de Aprendizaje - SENA - Servicio Nacional de Aprendizaje