Software Testing

Ingeniería de Software II
Docente: Urbano Eliécer Gómez Prada
 Una realidad poco conocida o
comprendida, es más fácil de asimilar,
cuando es mostrada a través de un símil
con otra que si conocemos, o bien, con
otra que puede intuirse coherentemente
usando el sentido común

goo.gl/EEDMmq 2
“Vistas” de una construcción

3
Justificación

4
 Introducción a las pruebas

Objetivo:
Conocer las ideas principales sobre
las pruebas del software
 Introducción a las pruebas
Ariane 5.
Lanzado por primera vez el 4 de junio de
1996.

Ariane 5.
36.7 segundos después explotó.

Motivo:
Fallo software. La programación no se había probado lo suficiente.
 Introducción a las pruebas

Sistemas software: Pruebas:

• Mayor tamaño. • Más importancia y
• Mayor complejidad. protagonismo día a día.
• Menor tiempo de desarrollo. • Garantizan la calidad del
• Mayor calidad. software.
• Garantizan la satisfacción de
los requisitos.
Un reto a la • Ahorran tiempo y recurso en el
Ingeniería de desarrollo.
Software. • Su objetivo: localizar, para
subsanarlas, el mayor número
de deficiencias lo antes posible.
 Introducción a las pruebas

Definición de prueba:
Verificación dinámica del
comportamiento del
software a partir de un
conjunto finito de casos de
prueba.
Para probar un software
necesitamos ejecutar ese
software.
 Introducción a las pruebas

Definición de prueba:
1
Verificación dinámica del
comportamiento del software a
partir de un conjunto finito de
casos de prueba.
Validación: proceso de evaluar un
sistema o componente durante o al
final del proceso de desarrollo para
determinar si satisface los requisitos
especificados.

Dos conceptos muy Verificación: proceso de evaluar un

2
relacionados: sistema o componente para
determinar si los productos de una
determinada fase satisfacen las
condiciones impuestas al comienzo
de la fase.
 Introducción a las pruebas

Para probar un programa

tenemos que ejecutarlo.

Verificación dinámica del La prueba tiene un límite.

comportamiento del
software a partir de un
conjunto finito de casos de
prueba.
No vale ejecutar el
programa de cualquier
manera.
 Introducción a las pruebas

Acciones
Una prueba consta, al
menos, de tres Configurar partida:
elementos:  El sistema muestra un formulario con todos los
valores configurables.
 El jugador introduce modifica los valores.
 El sistema comprueba la validez de los valores y
vuelve a la pantalla principal.

Valores del prueba Resultado

Configuración:
Intentos = 5
Valores = 8
Repetidos = cierto
 Introducción a las pruebas

Ejemplo:

¿Me queda bien esta camisa?

Valores de Acciones Resultado esperado

prueba
Mi cuerpo. 1. Ponerme la camisa. Elegancia y confort.
2. Abrochármela.
3. Moverme un poco.
4. Mirarme al espejo.
Cuidado con la etiqueta o con arrugarla
por si hay que devolverla
 Introducción a las pruebas

¿Qué casos de prueba podemos escribir?.

public int suma(int a, int b)
{ Valores de Acciones Resultado
return a + b; prueba esperado
}
??? Suma(a, b) ???

Los casos de prueba son finitos

(y cuantos menos, mejor).
 Introducción a las pruebas
¿Qué casos de prueba podemos escribir?.

public int suma(int a, int b) Valores de Acciones Resultado

prueba esperado
{
return a + b;
} 0, 0 Suma(a, b) 0
0, b = no 0 Suma(a, b) b
3, 4 Suma(a, b) 7
-2, -8 Suma(a, b) -10
-3, 6 Suma(a, b) 3
Integer.MAX_V Suma(a, b) -2147483643
ALUE, 6

Y algunas permutaciones más.

 Conclusión

• Probar es ejecutar casos de prueba.

• Caso de prueba:
entrada + acciones + salida
salida obtenida == salida esperada
salida obtenida != salida esperada

• ¿Un programa que pasa todos sus casos de

prueba es un programa sin errores?.
 Conclusión

No

Las pruebas sólo pueden

encontrar los errores que buscan.
Por esto es tan importante un
buen diseño de pruebas.
 Niveles de prueba
FASES DE LA PRUEBA
• Diseño de las pruebas (¿técnicas?)
• Generación de casos de prueba (¿datos de prueba?)
• Definición del procedimiento de la prueba (¿cómo, donde?)
• Ejecución de la prueba
• Informe de la prueba (¿resultados?)

TÉCNICAS DE PRUEBA
• Pruebas estructurales o de Caja Blanca.
• Pruebas funcionales o de caja negra.

ESTRATEGIAS DE PRUEBA
• Pruebas unitarias.
• Pruebas de integración.
• Pruebas de sistema.
• Pruebas de aceptación.
• Pruebas de regresión.
 Niveles de prueba

Necesidades Verifican
de los Pruebas de
aceptación
usuarios

Verifican
Paso a Pruebas de
producción implantación

Verifican
Requisitos del Pruebas de
sistema sistema

Interacción Verifican Pruebas de

entre integración
componentes

Componentes Verifican Pruebas

aislados unitárias
 Pruebas unitarias
Cuando: Durante la Herramientas:
construcción del sistema.
Objetivo: Prueban el diseño jMock
Cactus

y el comportamiento de TestNG
CruiseControl
cada uno de los Cobertura

componentes una vez

construidos. muJava EasyMock

XUnit

CoView
 Pruebas unitarias

Técnicas:
– Análisis de caminos.
– Partición de categorías.
– Mutaciones.
– Algoritmos genéricos.

En general, han sido muy estudiadas.

 Pruebas de integración

Cuando: Durante la construcción Herramientas:

del sistema
Las mismas, vamos
Objetivo: Comprueban la correcta sustituyendo los mocks por
unión de los componentes entre sí las clases reales y, si es
a través de sus interfaces, y si necesario, escribiendo más
cumplen con la funcionalidad
establecida
casos de prueba.
 Pruebas de integración

Técnicas:
Arriba abajo:
El primer componente que se prueba es el primero
de la jerarquía (A). Una de las ventajas es que las
interfaces entre los distintos componentes se
prueban en una fase temprana y con frecuencia.

Abajo a arriba:
Se prueban primero los componentes de más bajo
nivel (E, F) Este tipo de enfoque permite un
desarrollo más en paralelo, pero presenta mayores
dificultades a la hora de planificar y de gestionar.
 Pruebas de sistema

Herramientas:
Cuando: Durante la construcción Herramientas:
del sistema (partes completas). Avignon

Objetivo: Prueban a fondo el JMeter

sistema, comprobando su
Marathon

The Grinch
funcionalidad e integridad GUItar

globalmente, en un entorno lo JWebTest Selenium

más parecido posible al entorno Abbot HttpUnit

final de producción.

Técnicas: probar el sistema

como lo hará el usuario final.
 Pruebas de implantación

Herramientas:
Cuando: Durante la implantación en Herramientas:
el entrono de producción.
. Las mismas. Las pruebas se vuelven
Objetivo: Comprueban el correcto a ejecutar en el entorno real de
funcionamiento del sistema dentro producción y se añaden nuevas
del entorno real de producción pruebas.
(rendimiento, copias de seguridad,
etc.). .
 Pruebas de aceptación

Herramientas:
Cuando: Después de la Herramientas:
implantación en el entorno de
producción. Las mismas. Las pruebas se vuelven
a ejecutar en el entorno real de
Objetivo: Verifican que el sistema producción y se añaden nuevas
cumple con todos los requisitos
pruebas.
indicados y permite que los
usuarios del sistema den el visto .
bueno definitivo.
 Pruebas de regresión

Cuando: Durante el mantenimiento del sistema.

Objetivo: Comprobar que los cambios sobre un
Herramientas:
componente de un sistema de información, no Las mismas.
introducen un comportamiento no deseado o
errores adicionales en otros componentes no
modificados.
 Características de una buena prueba

• Ha de tener una alta probabilidad de encontrar un fallo.

Cuanto más, mejor.
• No debe ser redundante. Si ya funciona, no lo
probamos más.
• Debe ser la “mejor de la cosecha”. Si tenemos donde
elegir, elegimos la mejor.
• No debería ser ni demasiado sencilla ni demasiado
compleja. Si es muy sencilla no aporta nada, si es
muy compleja a lo mejor no sabemos lo que ha
fallado.
 Automatización de las pruebas

Algunas palabras que hemos escuchado hablando de pruebas.

“No sirven para nada”

“Pérdida de tiempo”

“Imposibles de mantener”
“Engaño”

“Descartadas al primer cambio”

“Moda”

¿Por qué?.
 Automatización de las pruebas
Las pruebas son polémicas:

– No son parte de la solución.

– No se las entregamos a nuestros clientes.
– Incluso pueden darles a nuestros clientes una
mala impresión.
– Nuestros clientes no nos las pagan.
– Difíciles de mantener.

Sin embargo, las pruebas son imprescindibles.

La automatización nos permite reducir costes.
 Automatización de las pruebas

¿Qué significa automatizar?.

En este caso concreto: realizar de manera
automática mediante herramientas software.

¿Qué podemos automatizar?.

Diseño de las pruebas Menos habitual, pocas

Codificación de las pruebas
Ejecución de las pruebas
Evaluación de resultados
técnicas y herramientas.
El objetivo de esta
presentación
Lo más habitual, muchas
técnicas y herramientas
 Automatización de las pruebas

Ventajas de la automatización:
– Mayor rapidez de ejecución.
– Menos recursos.
– Evitamos pruebas obsoletas
 Automatización de las pruebas

Inconvenientes:
– ¡Muy pocas herramientas!.
– Necesitan una “base” a menudo inexistente.
– Un conjunto pobre de pruebas.
 Automatización de las pruebas
Cuando automatizar y cuando no automatizar.

Bien Mal.
No buscamos Gastamos más en la
automatizarlo automatización que en la
absolutamente todo. pruebas en sí.
Tenemos modelos y Construimos el sistema
documentación del sobre la marcha.
sistema.
Las herramientas de prueba
Nosotros controlamos las nos controlan a nosotros.
herramientas de prueba.
 Aparición de metodologías
La Ingeniería de Software se basa en dos puntos principales:

• La aplicación del método científico para la solución de

problemas en la gestión de proyectos de software, teniendo en
cuenta los tiempos de entrega, presupuesto, requerimientos,
productividad y calidad.
• La preferencia por el trabajo colaborativo para la solución de
estos problemas, lo que permite el apoyo en el desarrollo y la
corrección del software planeado.
 Tipos de Productos Software
Productos Genéricos
• Sistemas desarrollados de
manera aislada que se
venden a un mercado
abierto.
• Ejemplo. Bases de datos,
procesadores de texto, etc.
Brecha cada vez más pequeña
Productos Personalizados
(a la Medida)
• Sistemas desarrollados de
acuerdo con los requisitos de
un cliente específico.
• Sistemas de control para
instrumentos electrónicos.
35
 Atributos de un buen Software

Atributo Descripción

Mantenibilidad El software debe escribirse de tal forma que pueda evolucionar

para cumplir con las necesidades de cambio de los clientes.
Confiabilidad Fiabilidad, protección y seguridad. El software confiable no debe
causar daños físicos o económicos en el caso de una falla del
sistema.
Eficiencia El software no debe hacer que se malgasten los recursos del
sistema, por tanto debe incluir tiempos de respuesta y de
procesamiento, utilización de la memoria.
Usabilidad El software debe ser fácil de utilizar, sin esfuerzo adicional, por el
usuario para quien está diseñado. Interfaz apropiada y
documentación adecuada.

36
 Dml y lo Olv,
Exp y tal vez lo Ent
Reflexión Inv y lo Apr

Flórez, et al. 2016

 Retos Fundamentales que afronta la IS

• El reto de la heterogeneidad
• El reto de la entrega
• El reto de la confianza

"Comentar el código es como limpiar el cuarto de baño; nadie

quiere hacerlo, pero el resultado es siempre una experiencia más
agradable para uno mismo y sus invitados“ -- Ryan Campbell

38
 En resumen
¿Qué es Software? Programas de ordenador y la documentación asociada.
¿Qué es la Ingeniería del Es una disciplina que comprende todos los aspectos de la producción de
Software? software. Comprende las formas prácticas para desarrollar y entregar un
software útil.
¿qué es un procesos del Un conjunto de actividades cuya meta es el desarrollo o evolución del
Software? software.
¿Qué es un modelo de Una representación simplificada de un proceso del software, presentada
procesos del Software? desde una perspectiva específica.
¿Cuáles son los costos de A grandes rasgos, el 60% de los costos son de desarrollo, el 40% restantes
la Ingeniería del son de pruebas. En el caso del software personalizado, los costos de
Software? evolución a menudo exceden los de desarrollo.
¿Qué son los métodos de Enfoques estructurados para el desarrollo de software que incluyen modelos
la Ingeniería del de sistemas, notaciones, reglas, sugerencias de diseño y guías de procesos.
Software?
¿Qué es CASE Sistemas de software que intentan proporcionar ayuda automatizada a las
(Ingeniería del Software actividades del proceso del software. Los sistemas CASE a menudo se
Asistida por Computador? utilizan como apoyo al método.
¿Cuáles son los atributos El software debe tener la funcionalidad y el rendimiento requeridos por el
de un buen software? usuario, además de ser mantenible, confiable y fácil de utilizar.
¿Cuáles son los retos Enfrentarse con la creciente diversidad, las demandas para reducir los
fundamentales a los que tiempos de entrega y el desarrollo de software fiable.
se enfrenta la Ingeniería
del Software?
39
Tomado de: Sommerville, I. (2005) Ingeniería del Software. Séptima Edición. Editorial Perason. Madrid.
 Modelos de proceso especializado

Desarrollo basado en componentes

Modelo de métodos formales

Desarrollo de software orientado a aspectos

40
 Desarrollo en Componentes
Etapa 1 Etapa 4
Se investigan y evalúan productos disponibles Se integran los componentes en la
basados en componentes. arquitectura.
Etapa 2 Etapa 5
Se consideran los aspectos de integración de los Se efectúan pruebas exhaustivas para
componentes. asegurar la funcionalidad apropiada.

Etapa 3

Se diseña la arquitectura de software que

soporte los componentes.

"Programar sin una arquitectura o diseño en mente es como explorar una gruta sólo
con una linterna: no sabes dónde estás, dónde has estado ni hacia dónde vas“
Danny Thorpe

41
 Diseño en el nivel de Componentes

“Los programadores eficaces no tienen

que perder su tiempo depurando
errores… no deben introducirlos al
arrancar”
Dijkstra

"Unas buenas especificaciones incrementará la

productividad del programador mucho más de lo que
puede hacerlo cualquier herramienta o técnica"
Milt Bryce
42
 Modelo de Métodos Formales

Ventajas
• Permitan especificar, desarrollar y verificar
un sistema por medio del empleo de una
notación matemática rigurosa.
• Elimina muchos problemas difíciles de
vencer con otros paradigmas.
• Permite descubrir errores y desarrollar
software cero defectos.
Desventajas
• Consume mucho tiempo y es
costoso.
• Se requiere mucha capacitación.
• Es difícil la comunicación con los
clientes - aumenta la complejidad
técnica.

43
 Software orientado a Aspectos
• Ingeniería de componentes orientada a aspectos.

• Rebanadas horizontales a través de componentes de software descompuestos

verticalmente.
– Interfaces de usuario
– Trabajo en colaboración
– Distribución

• Aspectos comunes y sistémicos

– Persistencia
– Administración de la memoria
– Procesamiento de las transacciones
– Seguridad
– Integridad, etc.
Cálculo de Costos por Puntos de Función

45
 Contratos

• Contrato de software

• Contrato de Servicio

goo.gl/kGUrD2
Diseño de casos de prueba.
Enfoques principales

(Piattini et al) 47
 Diseño de casos de prueba

1. Prueba de caja negra :Conociendo la función específica

para la que fue diseñado el producto, se pueden llevar a
cabo pruebas que demuestren que cada función es
completamente operativa y, al mismo, tiempo buscando
errores en cada función;
2. Prueba de caja blanca : Conociendo el funcionamiento
del producto, se pueden desarrollar pruebas que
aseguren que «todas las piezas encajan», o sea, que la
operación interna se ajusta a las especificaciones y que
todos los componentes internos se han comprobado de
forma adecuada.
 Estrategias de prueba del SW

goo.gl/CqSXk9
 ISO/IEC 29119 Pruebas de
software
Estándar Internacional para pruebas
de software

Tafline Murnane and Stuart Reid

ISO/IEC JTC1/SC7 WG26 Software Testing
 Alcance
• Resumen de la ISO/IEC 29119
• Aplicaciones
• Desarrollos recientes
• Cronograma
• Trabajos futuros
 Motivación para ISO/IEC 29119

• Conflictos en definiciones y procedencia

– Gran cantidad de estándares innecesarios que serán
reemplazados uno por uno
• IEEE 829, IEEE 1008, BS 7925-1/-2, IEEE 1028
• Falta en los estándares actuales:
– Políticas y estrategías de pruebas organizacionales.
– Gestión de pruebas de proyectos.
– Sistema común y técnicas de pruebas de aceptación.
– Pruebas no funcionales
 ISO 29119 – Resumen y Estructura

Part 1 BS 7925-1
Concepts & Vocabulary

Part 4 Part 2 Part 3

Testing
Processes Documentation
Techniques

BS 7925-2
BS 7925-2 IEEE 829
IEEE 1008
 1. Conceptos y Vocabulario

• Conceptos de pruebas de software

– Introducción a las pruebas de software
– Relación entre pruebas, desarrollo y
mantenimiento.
– Implicaciones en los modelos de ciclos de vida.
– Enfoques de las pruebas
• Vocabulario de pruebas
 2. Procesos de prueba

Organisational Test Process

Test Management Processes

Static Test Dynamic Test

Processes Processes
Instancia de los procesos de prueba
 Procesos de pruebas organizacionales

Develop test [Major revision required]

specification
[No change required]

Draft
Test [No issues identified with
Specification Test Specification]

Gain consensus Monitor and

Review
on test control use of
test
specification test [Issues identified specification
specification or
Scheduled review due [Minor
Approved or revision
Test Specification Major organizational change] required]

Updated Test
Publish Specification Update
test test
Published
specification Test specification
Specification
 Procesos de gestión de pruebas

Organisational Test Process

Organisational Test Feedback on
Documentation Organisational Test
Documentation

Test Management Processes

Test Plan Updates
Test
Completion
Test Test Report
Plan Test
Test Planning Monitoring &
Completion
Control
Test Plan, Test Plan, Test Plan, Test Plan,
Control Control Test Completion Report, Control
Test Directives Test
Directives Test Measures Directives
Measures Measures

Test
Static Test Dynamic Test
Management
Processes Processes
Processes
 Procesos de planificación de pruebas
Understand Scope
Context

Organise
Test Plan
Development
Identify & Analysed Risks
Analyze
Risks
Identify Treatment
Risk Approaches
Treatment
Approaches
Design Test
Strategy
Schedule, Staffing
Profile Determine
Staffing and
Test Strategy
Draft Scheduling
Test Plan Document
Test Plan
Approved
Test Plan
Gain
Consensus
Test Plan on Test Plan
Publish
Test Plan
 Monitoreo de pruebas y control de procesos

Test Status Report

Test Test
Progress Control
Information Information
Report
[Testing Incomplete]

Test Test [Testing

Plan Measures Test Progress Complete]
Info
Set-Up Monitor Control

Control
Measures Directives

...Test Processes...
Dynamic/Static/Management
 Procesos de pruebas dinámicos
(Phase) Test Management Process
(Phase) Control
Test Plan Directives Test
Measures

Dynamic Test Processes

Test Test [No Issues

Test Design & Specification Results Noticed]
Test Execution
Implementation
[Issue Noticed or
Retest Result]

Test Environment
Requirements
Test
Test Incident
Environment
Test Reporting Incident
Set-up Environment Report
Readiness
Report
 Procesos de pruebas estáticas

(Phase) Test Management Process

(Phase) Control Test
Test Plan Directives Measures

Static Test Processes

Preparation Review Follow-Up

 Diseño de casos de prueba.
Comparación de los Enfoques principales

a) Enfoque estructural o de caja blanca (transparente):

– se centra en la estructura interna del programa para elegir
los casos de prueba
– la prueba exhaustiva consistiría en probar todos los
posibles caminos de ejecución
– nº caminos lógicos  ( buscar los más importantes)
b) Enfoque funcional o de caja negra:
– para derivar los casos, se estudia la especificación de las
funciones, la entrada y la salida.
• No son excluyentes.

63
 Prueba de caja Negra
• Las pruebas de caja negra, también denominada prueba de
comportamiento, se centran en los requisitos funcionales del
software. O sea, la prueba de caja negra permite al ingeniero
del software obtener conjuntos de condiciones de entrada
que ejerciten completamente todos los requisitos funcionales
de un programa.
• La prueba de caja negra intenta encontrar errores de las
siguientes categorías: (1) funciones incorrectas o ausentes,
(2) errores de interfaz, (3) errores en estructuras de datos o
en accesos a bases de datos externas, (4) errores de
rendimiento y (5) errores de inicialización y de terminación.

64
 Preguntas
1. ¿Cómo se prueba la validez funcional?
2. ¿Cómo se prueba el rendimiento y el comportamiento del
software?
3. ¿Qué clases de entrada compondrán unos buenos casos de
prueba?
4. ¿Es el sistema particularmente sensible a ciertos valores de
entrada?
5. ¿De qué forma están aislados los límites de una clase de datos?
6. ¿Qué volúmenes y niveles de datos tolerará el sistema?
7. ¿Qué efectos sobre la operación del sistema tendrán
combinaciones específicas de datos?
 Partición equivalente
La partición equivalente es un método de prueba de caja negra que divide el campo de
entrada de un programa en clases de datos de los que se pueden derivar casos de prueba.

Las clases de equivalencia se pueden definir de acuerdo con las

siguientes directrices:
1. Si una condición de entrada especifica un rango, se define una
clase de equivalencia válida y dos no válidas.
2. Si una condición de entrada requiere un valor específico, se
define una clase de equivalencia válida y dos no válidas.
3. Si una condición de entrada especifica un miembro de un
conjunto, se define una clase de equivalencia válida y una no
válida.
4. Si una condición de entrada es lógica, se define una clase de
equivalencia válida y una no válida.
 Análisis de valores límite

• Por razones que no están del todo claras, los

errores tienden a darse más en los límites del
campo de entrada que en el «centro». Por
ello, se ha desarrollado el análisis de valores
límites (AVL) como técnica de prueba. El
análisis de valores límite nos lleva a una
elección de casos de prueba que ejerciten los
valores límite.
 Las directrices de AVL
1. Si una condición de entrada especifica un rango delimitado por los
valores a y b, se deben diseñar casos de prueba para los valores a y b, y
para los valores justo por debajo y justo por encima de a y b,
respectivamente.
2. Si una condición de entrada especifica un número de valores, se deben
desarrollar casos de prueba que ejerciten los valores máximo y mínimo.
También se deben probar los valores justo por encima y justo por debajo
del máximo y del mínimo.
3. Aplicar las directrices 1 y 2 a las condiciones de salida. Por ejemplo,
supongamos que se requiere una tabla de «temperatura / presión»
como salida de un programa de análisis de ingeniería. Se deben diseñar
casos de prueba que creen un informe de salida que produzca el máximo
(y el mínimo) número permitido de entradas en la tabla.
4. Si las estructuras de datos internas tienen límites preestablecidos (por
ejemplo, una matriz que tenga un límite definido de 100 entradas), hay
que asegurarse de diseñar un caso de prueba que ejercite la estructura
de datos en sus límites.
 Prueba de comparación

• Hay situaciones (por ejemplo, aviónica de aeronaves, control de planta

nuclear) en las que la fiabilidad del software es algo absolutamente
crítico. En ese tipo de aplicaciones, a menudo se utiliza hardware y
software redundante para minimizar la posibilidad de error.

• Cuando se desarrolla software redundante, varios equipos de ingeniería

del software separados desarrollan versiones independientes de una
aplicación, usando las mismas especificaciones.

• En esas situaciones, se deben probar todas las versiones con los mismos
datos de prueba, para asegurar que todas proporcionan una salida
idéntica. Luego, se ejecutan todas las versiones en paralelo y se hace una
comparación en tiempo real de los resultados, para garantizar la
consistencia.
 Pruebas de entornos
especializados, arquitecturas y
aplicaciones
• Prueba de interfaces gráficas de usuario
• Prueba de arquitectura
• Prueba de sistemas de tiempo-real
• Prueba de la documentación: se puede enfocar en dos fases. -1- La revisión e
inspección (examina el documento para comprobar la claridad editorial). -2- La
prueba en vivo utiliza la documentación junto al uso del programa real

goo.gl/DNLG9B
 El arte de la depuración.

La depuración ocurre como consecuencia de una prueba efectiva. Es

decir, cuando un caso de prueba descubre un error, la depuración es
el proceso que provoca la eliminación del error.

Aunque la depuración puede y debe ser un proceso ordenado, sigue

teniendo mucho de arte.

Un ingeniero del software, al evaluar los resultados de una prueba,

se encuentra frecuentemente con una indicación «sintomática» de
un problema en el software:
• La manifestación externa de un error y la causa interna del error pueden no estar
relacionadas de una forma obvia.
• El proceso mental, apenas comprendido, que conecta un síntoma con una causa es la
depuración.
 El arte de la depuración II

La depuración no es una prueba, pero siempre ocurre como consecuencia

de la prueba. El proceso de depuración siempre tiene uno de los dos
resultados siguientes:

1. Se encuentra la causa, se corrige y se elimina;

2. O no se encuentra la causa.

En este último caso, la persona que realiza la depuración debe

sospechar la causa, diseñar un caso de prueba que ayude a confirmar
sus sospechas y el trabajo vuelve hacia atrás a la corrección del error
de una forma iterativa.

Durante la depuración hay errores que van desde lo ligeramente

inesperado (por ejemplo, un formato de salida incorrecto) hasta lo
catastrófico (por ejemplo, el sistema falla, produciéndose serios daños
económicos o físicos).
El proceso de la Depuración (III)
 Verificación y Validación (v&v)

• La verificación se refiere al conjunto de actividades que

asegura que el software implementa adecuadamente una
función específica.
• La validación se refiere a un conjunto diferente de actividades
que aseguran que el software construido se ajusta a lo
requerimientos del cliente.

Bohem, lo define de otra forma:

• Verificación “¿Estamos construyendo el producto
correctamente?”
• Validación “¿Estamos construyendo el producto correcto?”
 Una Estrategia de Prueba del SW

• La prueba en el contexto de espiral

goo.gl/DNLG9B
 Una estrategia de prueba del SW

• Desde el punto de vista procedimental

Requisitos Pruebas de
alto nivel
Diseño Prueba de
Integración

Codificación
Prueba de
unidad
Dirección del
la prueba
Etapas de prueba del SW
 Criterios para Completar la Prueba

Cada vez que se tratan de las pruebas del SW surgen unas preguntas:
¿Cuándo hemos terminado la prueba?
¿Cómo sabemos que hemos probado lo suficiente?

‘¿Cuando debemos probar?’

Una respuesta a la “La prueba nunca termina ya que
el responsable carga o pasa el problema al cliente ”
Otra respuesta algo cínica es “Se termina la prueba
cuando se agota el tiempo o el dinero disponible para
cada efecto”
 Aspectos Estratégicos

Ton Gilb, plantea que se deban abordar los siguientes puntos si se desea
implementar con éxito una estrategia de prueba del SW:
• Especificar los requisitos del producto de manera cuantificable mucho
antes que comiencen las pruebas.
• Establecer los objetivos de la prueba de manera explicita.
• Comprender que usuarios van a manejar el SW y desarrollar un perfil
para cada categoría de usuario.

goo.gl/DNLG9B
 Pruebas de Unidad

La prueba de unidad centra el proceso de verificación en la

menor unidad del diseño del software(Módulo).
Probar los caminos de control importantes, con el fin de
descubrir errores dentro del ámbito de un módulo.

Errores:
1. Procedencia aritmética incorrecta mal aplicada
2. Operaciones de modo mezcladas.
3. Inicializaciones incorrectas.
4. Falta de precisión.
5. Representación incorrecta de una expresión.
 Pruebas de Integración

“Si todos funcionan bien, ¿Por qué dudar de que no funcionen

todos juntos?”
La prueba de Integración es una técnica sistemática y sistémica
para construir la estructura del programa mientras que al mismo
tiempo, se llevan a cabo pruebas para detectar errores
asociados con la interacción.

Tipos de Integración
1. No incremental “big bang”. Se combinan todos los módulos por
anticipado, se prueba todo el producto.
2. Integración incremental en donde se desarrollan módulos pequeños y
funcionales que hacen que los errores sean más fácil de aislar y corregir.
 La Prueba de Regresión
 Cada vez que se añade un nuevo modulo como parte de una prueba de
integración el software cambia.
 La prueba de regresión es volver a ejecutar un subconjunto de
pruebas que se han llevado a cabo anteriormente para asegurarse de
que los cambios no han propagado efectos colaterales no deseados.

goo.gl/CqSXk9
 Comentarios de la Prueba

 La desventaja de la integración descendente es la necesidad

de resguardos. La principal desventaja de la integración
ascendente es que el “el programa como entidad no
existe hasta que se haya añadido el ultimo módulo”.
 La selección de una estrategia de integración depende
de las características del software y, a veces de la
planificación del proyecto, en algunos de los casos se
puede usar un enfoque combinado(denominado
pruebas Sándwich).
 Pruebas de Validación

La validación se consigue cuando el software funciona de

acuerdo con las expectativas razonables del cliente.
 Criterios de la prueba de Validación

La prueba alfa:
• Se lleva a cabo por un cliente en el lugar de desarrollo.
• Se usa el software de forma natural con el desarrollador
como observador del usuario.
• Se registran los errores y problemas de uso.
• Se llevan a cabo en un entorno controlado.

La prueba beta:
• Se lleva a cabo por los usuarios finales del software en los
lugares de trabajo de los clientes.
• El desarrollador no está presente normalmente.
• Es una aplicación «en vivo» del software en un entorno que
no puede ser controlado por el desarrollador.
 Prueba de Recuperación.

Fuerza el fallo del software de muchas formas.

Verifica que la recuperación se lleva a cabo apropiadamente.

Si la recuperación es automática hay que evaluar la corrección

de la inicialización, de los mecanismos de recuperación del
estado del sistema, de datos y del proceso de re-arranque.

Si la recuperación requiere la intervención humana, hay que

evaluar los tiempos medios de reparación (TMR) para
determinar si están dentro de unos límites aceptables.
 Prueba de Seguridad.

Piratas informáticos
• “deporte”
• emplea­dos disgustados  venganza
• Individuos deshonestos  ganancias personales ilícitas.

La prueba de seguridad intenta verificar que los

mecanismos de protección incorporados en el sistema lo
protegerán, de hecho, de accesos impropios.
 PRUEBA DE RESISTENCIA (STRESS)

La prueba de resistencia ejecuta un sistema de forma que demande

recursos en cantidad, frecuencia o volúmenes anormales. Por
ejemplo:
1. incrementar las frecuencias de datos de entrada en un orden de
magnitud con el fin de comprobar cómo responden las funciones de
entrada;
2. diseñar pruebas especiales que generen diez, interrupciones por
segundo, cuando las normales son una o dos;
3. ejecutar casos de prueba que requieran el máximo de memoria o de
otros recursos;
4. diseñar casos de prueba que puedan dar problemas en un sistema
operativo virtual
 PRUEBA DE RENDIMIENTO.

La prueba de rendimiento está diseñada para probar el

rendimiento del software en tiempo de ejecución dentro del
contexto de un sistema integrado.
 Enfoque estratégico para Pruebas del SW
• Las pruebas comienzan a nivel de modulo y trabajan hacia fuera.
• Según el momento son apropiadas diferentes técnicas de prueba.
• La prueba la lleva acabo el responsable del desarrollo del SW.
• La prueba y la depuración son actividades diferentes, pero la
depuración se debe incluir en cualquier estrategia de prueba.

goo.gl/DNLG9B
 Tipos

Tipo de
pruebas
 Alfa
Unidad
Beta

Recuperación
Integración
Seguridad

Resistencia
Tipos
Validación Rendimiento

Recuperación

Seguridad
Sistema
Resistencia

Rendimiento
 Tipos

Tipo de Objetivos
pruebas
 Descubrir errores

Notificar acerca de los

riesgos

Identificar fallos
funcionales de la
aplicación
Objetivos

Evaluar la calidad del

producto

Evaluar la calidad
técnica del producto

Cumplir con los

requerimientos
específicos del cliente.
 Tipos

Tipo de Objetivos
pruebas

Otro tipo
de
pruebas
 Recorrido

Aleatoria

Solidez

Aguante
Otro tipo de
pruebas
Prestaciones

Conformidad
homologación

Regresión

Mutación
 Tipos

En Tipo de Objetivos
función pruebas

Otro tipo
de
pruebas
 De caja negra
En función de
qué conocemos
De caja blanca

Pruebas
En función al manuales
grado de
automatización Pruebas
automáticas
En función

Pruebas unitarias

Pruebas
integración

En función de Pruebas de
que se prueba aceptación

Pruebas
funcionales

Pruebas de
rendimiento
 Tipos

En Tipo de Objetivos
función pruebas

Otro tipo
de
pruebas
 Integridad de
los datos y la
BD
Fallas y
Funcionalidad
recuperación

Seguridad y
Ciclo del
control de
negocio
acceso

Criterios
para la
realización
Interfaz de de pruebas
Esfuerzo
usuario

Performance Volumen

Carga Configuración
 Sentencias

De tablas Decisiones

De llamadas Condiciones

Cobertura
de
pruebas

Condiciones Condiciones
/decisiones múltiples

Operadores
De caminos
relacionales
De
funciones
 Propósito

Enfoque del
Aprovechamiento
cliente

Pruebas y
aceptación
del cliente

Visión del cliente Escenario

 Concepto

Control
estadístico
vs
métricas
 Concepto

Clasificación

Control
estadístico
vs
métricas
 Métricas de Medidas de estructuración de un
producto programa.

Métricas de
Métricas de complejidad.
proceso
Métricas de cobertura
de pruebas.

Métricas basadas en Métricas de calidad del

Clasificación
atributos internos del diseño.
producto

Métricas de
defectos.

Métricas de
portabilidad.
Métricas basadas en
Métricas de
atributos externos del
usabilidad.
producto
Métricas de
mantenibilidad.

Métricas de
fiabilidad.
 Concepto

Clasificación

Control
estadístico
vs
métricas
Para sistemas
orientados a
objetos
 Acoplamiento

Para sistemas
orientados a Herencia
objetos

Cohesión
 Concepto

Clasificación

Control
estadístico
vs
métricas
Para sistemas
orientados a
objetos

Basadas en
estructuras
de diseño
 Relacionadas
con el control
Basadas en intramodular
estructuras de
diseño Relacionada con
el acoplamiento
entre clases
 Concepto

Clasificación

Control
estadístico
vs
métricas
Para sistemas
Herramientas
orientados a
estadísticas
objetos

Basadas en
estructuras
de diseño
 Histogramas.

Tablas de
varianza y
Herramientas covarianza.
estadísticas Matriz de
correlación
lineal.
 Concepto

Basadas en
código Clasificación
fuente

Control
estadístico
vs
métricas
Herramientas Para sistemas
estadísticas orientados a
objetos

Basadas en
estructuras
de diseño
 No. de líneas de
código.

No. de líneas de
comentarios.
Basadas en
código fuente
No. de
instrucciones

Densidad de
documentación.
 Concepto

Basadas en
código Clasificación
fuente

Control
estadístico
vs
métricas
Para sistemas
Herramientas
orientados a
estadísticas
objetos

Basadas en
estructuras
de diseño
 Riesgos

1.¿Quién debe participar?

2.¿Cuándo debe hacerse?
3.¿La identificación se hace solamente en la fase de planificación?
4.¿Cómo influyen la creatividad y el pensamiento innovador?
5.¿Cuáles son las herramientas y técnicas a usar?
Espina de pescado, Diagramas de flujo de proceso, Entrevistas, DOFA, Árbol de decisiones, Simulación
http://www.pmoinformatica.com/2012/10/todo-proyecto-siempre-poseen-niveles-de.html
 Riesgos II

• Posibles dificultades en la disponibilidad de entornos.

• Pruebas que dependen de factores externos al proyecto
y la organización.
• Disponibilidad de personal con conocimientos
especializados en alguna herramienta, o en la
funcionalidad especifica que se está desarrollando.
• Dependencias con otros proyectos.
• Posibilidad que alguna premisa no se cumpla.

¿Y qué opina usted?, ¿Qué aspectos agregaría a esta lista para la identificación
efectiva de los riesgos de proyecto?, ¿Cuál ha sido su experiencia?
Complejidad

goo.gl/DNLG9B
Complejidad

goo.gl/DNLG9B
 Software Testing –Test Link
• Definir proyectos de pruebas (Test Project).
• Definir los usuarios que accederán al proyecto.
• Crear casos de prueba y su información (Test Case).
• Organizar los casos de pruebas en “conjuntos de pruebas” (Test Suite).
• Asignar palabras claves (keywords) a los casos de pruebas.
• Crear planes de pruebas (Test Plan) y enlazarles casos de pruebas (Test Case).
• Ejecutar los casos de prueba y registrar resultados.
• Visualizar los resultados de las pruebas (Test Results).
• http://www.testlink.org/
• http://www.qaustral.com.ar/descargas/MTestLink.pdf
• https://softwaremantenible.com/2016/05/23/como-crear-un-proyecto-de-prueba-unitarias-unit-test
-project/
 Hewlett Packard Quality Center (HP QC)
•
Es un software de gestión de calidad.
• Ofrece diversas capacidades para el aseguramiento de calidad, gestión de
requerimientos, gestión de software testing, entre otros.
Pasos:
• Definir proyectos, ciclos y planes de prueba.
• Definir los casos de prueba.
• Registrar la ejecución de casos de prueba incluyendo el resultado y la evidencia anexa.
• Registrar defectos y asociarlos a los casos de prueba.
• Reportes operativos de Testing (porcentajes de avance, estado de incidencias, progreso de
la Ejecución).
 Zephyr / Jira

• Creación y planificación:
– Crear Tests como Issues de Jira estándares.
– Construir planes de prueba.
– Definir ciclos de pruebas.
– Hacer seguimiento al avance de las pruebas dentro de Jira.
– Tiene disponibles planes predeterminados para amplia variedad de proyectos.
• Ejecución de las pruebas:
– Ingreso de información en las pruebas (estatus, comentarios, adjuntos).
– Asociaciones de defectos a los casos de pruebas.
• Tableros e indicadores para ver la situación y progreso de las pruebas.

http://www.getzephyr.com/
https://es.atlassian.com/software/jira
.

Referencias bibliográficas
1. UPIICSA, «Ingeniería de Software,» [En línea]. Available: goo.gl/QkbWqG.
2. Lawrence Pfleeger, SHARI Atlee, JOANNE M, Software Engineering: Theory and Practice.
4a. Edición. Pearson Education, 2010.
3. Sommerville, I. (2005) Ingeniería del Software. Séptima Edición. Editorial Pearson. Madrid.
4. Pressman, Roger. (2010) Ingeniería del Software un enfoque práctico. Séptima edición. McGrwHill.
5. R. A. Gacitúa Bustos, «Métodos de desarrollo de software: el desafío pendiente de la
estandarización,» Theoria, vol. 12, pp. 23-42, 2003.
6. E. Mnkandla, «About Software Engineering Frameworks and Methodologies,» IEEE Africon 2009,
2009.
7. S. Lawrence Pfleeger y J. M. Atlee, Software Engineering. Theory and Practice.,Tercera ed., Pearson
Education, Inc., 2006.
8. E. M. Rogers, Diffusion of Innovations, Quinta ed., Free Press, 2003.
9. S. T. Redwine y W. E. Riddle, «"Software technology maturation", Proceedings of the Eighth
International Conference on Software Engineering,» IEEE Computer Society Press, pp. 189-
200, 1985.
10. R. McGrath, «The Pace of Technology Adoption is Speeding Up,» Harvard Business Review, 25
Noviembre 2013. [En línea]. Available: goo.gl/P1J5Lh.
11. B. H. Hall y B. Khan, «Adoption of New Technology,» New Economy Handbook, 2003.
12. B. Boehm, «A view of 20th and 21st century software engineering,» ICSE '06 Proceedings of the 28th
international conference on Software engineering, pp. 12-29, 28 Mayo 2006.
 Referencias bibliográficas (II)

1. A. Finkelstein y J. Kramer, «Software Engineering: A Roadmap,» Proceedings of the

Conference on The Future of Software Engineering, 2000.
2. A. Orlic, «El futuro de la ingeniería de software,» Informática. Tecnología y Gestión., 2001.
3. S. Lawrence Pfleeger, «Understanding and Improving Technology Transfer in Software
Engineering,» Journal of Systems and Software, Febrero 1999.
4. Z. B. Rosanigo, Maximizando reuso en software para Ingeniería Estructural.
Modelos y Patrones., La Plata: Universidad Nacional de La Plata, 2000.
5. ABACO. Modelos de calidad de software. (2010). Consultado en 2013-02-22 de
http://www.gestionabaco.com/newsite/tecnologia/modelos-de-calidad-de-software
6. Bonilla Sánchez, Beatriz. CMMI – Modelos de madurez 2 y 3. 2006.
http://www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=cmmi2y3
7. Functional Prototype of a Web Information System to Assist Planning Software Projects,
Based on CMMI. 2014. goo.gl/7TxakJ
8. COMEX (Grupo IBERICA)INTEGRACIÓN | METODOLOGÍA ( CMMI ) .
9. Grupo consultoría. Conceptos y componentes del Modelo CMMi, 2011.
http://www.grupoconsultoria.com.co/compocmmi.htm
10. SLPROG. Empresas CMMI. 2013. http://slprog.wikispaces.com/EmpresasCMMI