CALIDAD DEL

SOFTWARE

Por: Paola Madrid

.
Agenda:
General

1. Ciclo de vida software

2. Pruebas Unitarias
3. Pruebas Modulares
4. Pruebas de Integración
5. Pruebas de sistema
6. Pruebas de Aceptación
7. Pruebas funcionales
8. Pruebas no Funcionales
9. Ciclo de vida
10.Calidad del Software
CICLO DE VIDA SOFTWARE:

CICLO DE VIDA SOFTWARE: marco de referencia que define el enfoque general del desarrollo software,
indicando los procesos y actividades a realizar desde la definición del producto software hasta su
finalización de uso; así como los entregables que se van a generar y entregar al cliente (ISO 12207).
Modelo en cascada (clásico) Modelo iterativo (RUP, XP, etc.)

Modelo evolutivo Modelos ágiles (e.g. SCRUM)

Pruebas a través del ciclo de vida: Modelo-V
• El modelo-v general es el modelo de desarrollo software más utilizado.
• Desarrollo y pruebas son dos ramas iguales. Cada nivel de desarrollo tiene su correspondiente nivel de
pruebas.
• Las pruebas (rama derecha) son diseñadas en paralelo al desarrollo (rama izquierda).
• Las actividades del proceso de pruebas tiene lugar a través del ciclo de vida software completo
Pruebas a través del ciclo de vida: Modelo-V

Rama de desarrollo software

• Definición de requisitos
• Documentos de especificación
• Diseño funcional del sistema
• Diseño del flujo funcional del programa
• Diseño técnico del sistema
• Definición de arquitectura/interfaces
• Especificación de los componentes
• Estructura de los componentes
• Programación
• Creación de código ejecutable
Pruebas a través del ciclo de vida: Modelo-V

Rama de desarrollo software

• Pruebas de aceptación
• Pruebas formales de los requisitos del
cliente
• Pruebas del sistema
• Sistema integrado, especificaciones
• Pruebas de integración
• Interfaces de componentes
• Pruebas unitarias
• Funcionalidad del componente (clase,
método, módulo, etc.)
PRUEBAS DE SOFTWARE
TERMINOS:

• TESTING: es el proceso orientado a demostrar que un programa no tiene errores

• TESTING: es la tarea de demostrar que un programa realiza las funciones para las cuales fue
construido
• TESTING: es la ejecucion de programas de software con el objetivo de detectar defectos y fallas.
(proceso destructivo)

• TEST EXITOSO: aquel que detecta errores

• TEST NO EXITOSO: aquel que no los detecta

Existe un problema psicologico, requiere un cambio de actitud ya que naturalmente somos contructivos

ERROR: una equivocacion de una persona al desarrollar alguna actividad de desarrollo de software

DEFECTO: se produce cuando una persona comete un error

FALLA: es un desvio respecto del comportamiento esperado del sistema, puede producirse en cualquier
etapa
PRINCIPIOS
• Una parte necesario de un test es la definicion de los resultados esperads
• Un programador debe evitar probar su propio desarrollo
• Revise los resultados de los test en profundidad
• Los test deben incluir entradas invalidas e inesperadas asi como las validas y esperadas
• Revisar un programa para verificar que hace lo que se espera que haga es solo la miitad de la
prueba; la otra mitad consiste en comprobar que no haga lo que no se espera
• No tirar los test a la basura a menos que el pgrama sea basura
• No planear esfuerzos de pruebas asumiendo que no se encontraran errores
• La probabilidad de encontrar errores en una seccion de un programa es proporcional al numero de
errores ya encontrados en esa seccion
• El testing conituye una tarea creativa e intelectualmente desafiante
NIVELES DE PRUEBAS
PRUEBAS UNITARIS
PRUEBAS UNITARIAS: Alcance
• Sólo se prueban componentes individuales (clases, funciones, módulos, etc.)
• Cada componente se prueba de forma independiente.
• Descubre errores producidos por defectos internos
• Los casos de prueba podrá ser obtenidos a partir de:
• Código fuente, modelo de datos, Diseño software.
• Se pueden realizar pruebas de caja blanca y de caja negra para probar los módulos completamente.
• Las pruebas de caja negra (los casos de prueba) se pueden especificar antes de que programar el
modo, no así las pruebas de caja blanca.

La idea es escribir casos de prueba para cada función no trivial o método en el módulo, de forma que
cada caso sea independiente del resto. Luego, con las Pruebas de Integración, se podrá asegurar el
correcto funcionamiento del sistema o subsistema en cuestión.
PRUEBAS UNITARIA
Para que una prueba unitaria tenga la calidad suficiente se deben cumplir las siguientes:

CARACTERISTICAS:

• Automatizable: No debería requerirse una intervención manual. Esto es especialmente útil para
integración continua.
• Completas: Deben cubrir la mayor cantidad de código.
• Repetibles o Reutilizables: No se deben crear pruebas que sólo puedan ser ejecutadas una sola vez.
También es útil para integración continua.
• Independientes: La ejecución de una prueba no debe afectar a la ejecución de otra.
• Profesionales: Las pruebas deben ser consideradas igual que el código, con la misma
profesionalidad, documentación, etc.
PRUEBAS UNITARIA
VENTAJAS:

• Fomentan el cambio: las pruebas unitarias facilitan que el programador cambie el código para
mejorar su estructura, puesto que permiten hacer pruebas sobre los cambios y así asegurarse de
que los nuevos cambios no han introducido errores.
• Simplifica la integración: puesto que permiten llegar a la fase de integración con un grado alto de
seguridad de que el código está funcionando correctamente, de esta manera se facilitan las pruebas
de integración.
• Documenta el código: las propias pruebas son documentación del código puesto que ahí se puede
ver cómo utilizarlo.
• Separación de la interfaz y la implementación: dado que la única interacción entre los casos de
prueba y las unidades bajo prueba son las interfaces de estas últimas, se puede cambiar cualquiera
de los dos sin afectar al otro, a veces usando objetos mock (mock object) para simular el
comportamiento de objetos complejos.
• Los errores están más acotados y son más fáciles de localizar
PRUEBAS UNITARIA
HERRAMIENTAS:
• JUnit: Entorno de pruebas para Java creado por Erich Gamma y Kent Beck. Se encuentra basado
en SUnit creado originalmente para realizar pruebas unitarias para el lenguaje Smalltalk.
• TestNG: Creado para suplir algunas deficiencias en JUnit.
• JTiger: Basado en anotaciones, como TestNG.
• SimpleTest: Entorno de pruebas para aplicaciones realizadas en PHP.
• PHPUnit: Sistema para la realización pruebas unitarias en PHP.
• CPPUnit: Versión del framework para lenguajes C/C++.
• NUnit: Versión del framework para la plataforma.NET.
• FoxUnit: Entorno OpenSource de pruebas unitarias para Microsoft Visual FoxPro
• MOQ: Entorno para la creación dinámica de objetos simuladores (mocks). «MOQ».
• QUnit: Librería para pruebas unitarias en Javascript. Creada por la fundación jQuery, ha sido
reescrita para ser independiente de la librería jQuery.
• libunittest: Librería portable para pruebas unitarias en C++ que usa el nuevo estándar C++11.
• CUnit: Entorno para escribir, administar y correr test unitarios en lenguaje C.
• PyUnit: Framework para la elaboración de pruebas unitarias en python.
• QtTest: Clases para pruebas unitarias en la biblioteca Qt (C++)
PRUEBAS MODULARES
Assert.

La mayoria de las herramientas tienen assert, que son afirmaciones que son usada para
comprobar suposiciones en el programa, colocada donde el desarrollador considera
que su ennunciado es siempre verdadero.
Esto da lugar a que existan afirmaciones y por lo tanto condiciones antes
(precondiciones) y despues (postcondiciones) de la ejecución de determinadas lineas
de código, lo que da lugar a las pruebas unitarias.

Ejemplo
int b= 3;
b= b+8;
System.out.println(“b tiene valor: “, b);
(b==11) //assert
b= b*2;
PRUEBAS MODULARES
Assert Junit (java)
METODO assertxxx() de JUnit lo que comprueba
assertTrue(expresion) comprueba que expresion evalue a
true
assertFalse(expresion) comprueba que expresion evalue a
false
assertEquals(esperando,real) comprueba que esperando sea igual
a real
assertNull(objeto) comprueba que el objeto sea null
assertNotNull(objeto) comprueba que el objeto no sea null
assertSame(Objeto_esperado, comprueba que el Objeto_esperado y
Objeto_real) el Objeto_real sean el mismo objeto
AssertNotSame(Objeto_esperado, comprueba que el Objeto_esperado y
Objeto_real) el Objeto_real no sean el mismo
objeto
fail() hace que el test termine con fallo
PRUEBAS DE INTEGRACION
PRUEBASDE INTEGRACIÓN: Alcance
• Las pruebas de integración comprueban la interacción mutua entre componentes (subsistemas)
software entre sí. Se asumen que los componentes ya han sido aprobados.
• Tendencia a intentar una integración no incremental:
• Combinar todos los módulos y probar el sistema en su conjunto.
• Resultado previsible: CAOS !!!
• Recomendación: aplicar integración incremental:
• El software se prueba en pequeñas porciones.
• En la detección y resolución de errores es más: Fácil, controlable y gestionable.
• Los casos de prueba podrá ser obtenidos a partir de:
• Especificación de interfaces, diseño de la arquitectura y modelo datos
PRUEBAS DE INTEGRACION
Falla de Intercomponentes
• Falla de interoperatividad

TIPOS DE PROBLEMAS QUE PUEDEN SURGIR:

• Relacionados con la programacion
• Relacionados con la operacion

TIPO 1: los componentes individuales probados, la secuencia de invocacion en un componente puede

fallar, el estado y los abrazos mortales

TIPO 2: problemas de interoperatibilidad, relacionados con:

• Los sistemas: componentes desarrollados en diferentes ingraestructuras, posiblemente no 100%
compatibles
• Lenguajes de programacion:
• Especificaciones:
PRUEBAS DE INTEGRACION
TIPO 2: problemas de interoperatibilidad, relacionados con:
• Los sistemas: componentes desarrollados en diferentes ingraestructuras, posiblemente no 100%
compatibles
• Lenguajes de programacion: componentes desarrollados en diferentes lenguajes de programacion,
manejo en la conversion de tipos y los resultados de operaciones aritmeticas
• Especificaciones: especificaciones mal interpretadas por los desarrolladores, fallas en el nivel de
detalle de la arquitectura

TIPO 3: otras fallas

• Entradas especiales:
• Condiciones particulares de ejecucion:
PRUEBAS DE INTEGRACION
METODOLOGIAS DE PRUEBAS:

• En que orden integrar componentes

• Como probar incrementealmente el sistema
• Como probar un nuevo componente

TIPO 1: Descomposicion funcional

PRUEBAS DE INTEGRACION
Caracteristicas de Descomposicion Funcional
• Big Bang: se prueba todo junto, produciendo una explosion; nadie sabe que fallo o por que, es
donde unas fallas enmascaran a otras y por lo general se utilizan en empresas sin cuidado en la
calidad
• Top Down: stubs De la raiz hacia las hojas
PRUEBAS DE INTEGRACION
Bottom Up: Drivers
De las hojas hacia la raiz, cuando cada modulo termina, se supone probado como unidad; se usa
manejador para uno o mas de ellos
No se especifica si primero todo un nivel o subiendo por el arbol
se adapta a subarboles
PRUEBAS DE INTEGRACION
Sandwich (in the middle) cuando no hay orden estricto de terminacion de modulos, pueden irse
probando pares conforme esten listos.
Se completa con manejadores
Generan muchas pruebas
PRUEBAS DE INTEGRACION
TIPO 2: Grafo de llamadas
PRUEBAS DE SISTEMA
PRUEBAS DE SISTEMA: Alcance
• Consiste en probar (lo más exhaustivamente posible) el software completo para verificar que:
• Se cumplen los requisitos funcionales establecidos
• Se cumplen aspectos no funcionales de calidad: usabilidad, eficiencia, portabilidad, seguridad,
etc.
• La calidad software es observada desde el punto de vista del usuario y en un entorno de pruebas
coincidente (en lo posible) con entorno real.
• Los casos de prueba podrá ser obtenidos a partir de:
• Especificaciones funcionales, casos uso, procesos negocio
• Para la generación de casos de prueba se utilizan técnicas de caja negra
PRUEBAS DE ACEPTACION
Pruebas de Aceptación:
• Son pruebas para aceptar formalmente el software. Son las pruebas de sistema del cliente/usuario.
• Es conveniente haber definido los criterios de aceptación verificables de manera previa y
consensuada.
• Están enfocadas a demostrar que no se cumplen los requisitos, criterios de aceptación o el contrato.
• El usuario selecciona casos de prueba concretos para sus pruebas de aceptación, según las
prioridades de su negocio.
• Las pruebas se realizarán en el entorno del cliente (real) y se utiliza técnicas de caja negra.
PRUEBAS FUNCIONALES
Pruebas Funcionales:
Una prueba funcional es una prueba basada en la ejecución, revisión y retroalimentación de las
funcionalidades previamente diseñadas para el software. Las pruebas funcionales se hacen mediante el
diseño de modelos de prueba que buscan evaluar cada una de las opciones con las que cuenta el
paquete informático. Dicho de otro modo son pruebas específicas, concretas y exhaustivas para probar y
validar que el software hace lo que debe y sobre todo, lo que se ha especificado.

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

datos, procesamiento y obtención de resultados
• Las pruebas Funcionales deben enfocarse en los requisitos funcionales Diseñar scripts para validar
las condiciones de la máquina a instalar
• Que los resultados esperados ocurran cuando se usen datos válidos.

Las pruebas funcionales pueden ser, según el nivel y el tipo de pruebas:

• Pruebas exploratoriasPruebas de regresión
• Pruebas de regresión
• Pruebas de compatibilidad
• Pruebas de integración
• Pruebas de aceptación
PRUEBAS NO FUNCIONALES
Pruebas no Funcionales: Las pruebas no funcionales se enfocan en validar un sistema o aplicación por
medio de sus requerimientos no funcionales, es decir, la forma en que el sistema funciona y no por
medio de comportamientos específicos.

Las características no funcionales de un sistema o aplicación con frecuencia se cuantifican en escalas

variables, como por ejemplo los tiempos de respuesta en pruebas de desempeño.
PRUEBAS NO FUNCIONALES
10 tipos de pruebas no funcionales
A continuación te presentamos una lista no limitativa de 10 tipos de pruebas no funcionales que puedes
incluir en tu plan de pruebas de software.

1. - Pruebas de carga
Las pruebas de carga consisten en simular demanda sobre una aplicación de software y medir el
resultado. Estas pruebas se realizan bajo demanda esperada y también en condiciones de sobrecarga
(picos en la demanda).
Para ejecutar estas pruebas, se requiere del uso de herramientas que simulen la carga, como por
ejemplo SoapUI.
Las pruebas de carga ayudan a identificar la máxima capacidad operativa de una aplicación, así como
en el identificar cuellos de botella y las causas de posible degradación del desempeño.
Cuando la carga de prueba se eleva por encima de los parámetros esperados, a estas pruebas se les
conoce como pruebas de estrés.
PRUEBAS NO FUNCIONALES
2. - Pruebas de estrés
Son pruebas de carga que se realizan con demandas mayores a la capacidad operativa, con frecuencia
hasta llegar al punto de ruptura.

Este tipo de prueba de software se utiliza para determinar la estabilidad de un sistema o aplicación, con
especial atención en la disponibilidad y manejo de errores cuando se enfrenta a la sobrecarga.
PRUEBAS NO FUNCIONALES
3. - Pruebas de volumen

Las pruebas de volumen consisten en validar el funcionamiento de la aplicación con ciertos volúmenes
de datos.

Por ejemplo, si se quiere ver el comportamiento de una aplicación con un tamaño de base de datos
específico, se expande el tamaño de base de datos a dichos parámetros y luego e realizan consultas,
procesos o funcionalidades de la aplicación, midiendo su desempeño.

El sujeto de pruebas no está limitado a bases de datos, también se puede usar por ejemplo para medir
el desempeño de una interfaz cuando el archivo de interfaz (un archivo de texto, xml, etc.) supera cierto
tamaño.

El objetivo es ver si dado ciertos volúmenes de datos la aplicación funciona con normalidad, cuales son
los límites máximos de volúmenes de datos para la operación e identificar condiciones de falla.
PRUEBAS NO FUNCIONALES
3. - Pruebas de volumen

Las pruebas de volumen consisten en validar el funcionamiento de la aplicación con ciertos volúmenes
de datos.

Por ejemplo, si se quiere ver el comportamiento de una aplicación con un tamaño de base de datos
específico, se expande el tamaño de base de datos a dichos parámetros y luego e realizan consultas,
procesos o funcionalidades de la aplicación, midiendo su desempeño.

El sujeto de pruebas no está limitado a bases de datos, también se puede usar por ejemplo para medir
el desempeño de una interfaz cuando el archivo de interfaz (un archivo de texto, xml, etc.) supera cierto
tamaño.

El objetivo es ver si dado ciertos volúmenes de datos la aplicación funciona con normalidad, cuales son
los límites máximos de volúmenes de datos para la operación e identificar condiciones de falla.
PRUEBAS NO FUNCIONALES
4. - 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.
PRUEBAS NO FUNCIONALES
5. - 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.
PRUEBAS NO FUNCIONALES
6. - Pruebas de seguridad

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.
PRUEBAS NO FUNCIONALES
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.
PRUEBAS NO FUNCIONALES
8. - 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.
PRUEBAS NO FUNCIONALES
9. - 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.
PRUEBAS NO FUNCIONALES
9. - 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.
PRUEBAS NO FUNCIONALES
10. - 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.
TECNICAS PRUEBAS ASEGURAMIENTO DE LA CALIDAD
TECNICAS ESTATICAS
REVISIONES:
OBJETIVO: mejorar la calidad del producto y reducir propagación de errores entre fases (modelo-v)
• La detección temprana de errores ahorra costes a posteriori.
• Defectos potencialmente detectables en:
• Documentos de especificación y arquitectura
• Especificaciones de interfaces
• Desviaciones respecto a estándares acordados (e.g. Guías de programación)
• Tarea eminentemente manual.

ANALISIS ESTATICO:
OBJETIVO: Buscar errores en la especificación de objetos de prueba (e.g. Código fuente, script, etc.) sin
ejecutar el objeto de prueba.
• Aspectos a detectar:
• Reglas y estándares de programación
• Diseño de un programa (análisis del flujo de control)
• Uso de datos (análisis flujo de datos)
• Complejidad de la estructura de un programa (métricas)
• Existen herramientas compiladores, analizadores
• Detectar lógica errónea (bucles potencialmente infinitos)
• Detectar estructuras lógicas complejas, inconsistencias entre interfaces, etc.
• Supone menor esfuerzo que una inspección
TECNICAS DINAMICAS
CAJA NEGRA:
• El tester observar el objeto de prueba como una caja negra.
• La estructura interna del objeto de prueba es irrelevante o desconocida.

• Los casos de prueba se obtienen a partir del análisis de la especificación (funcional o no funcional) de
un componente o sistema
• Prueba de comportamiento entrada/salida

• La utilidad es el foco de atención

• La técnica de caja negra también se denomina prueba funcional o prueba orientada a la
especificación
TECNICAS DINAMICAS
Métodos de caja negra:
• Partición de equivalencias o clases de equivalencia.
• Análisis de valores límite.
• Pruebas de casos de uso.
• Tablas de decisión, de transición de estado,

• Método: Clases de equivalencia (CE)

• Consiste en dividir los valores de entrada en clases de datos para derivar casos de prueba.
• Se asume que el resultado de una prueba con un valor representativo de cada CE equivale a
realizar la misma prueba con cualquier otro valor de la CE.

Ejemplo: un programa requiere un número entero [0…100]. Posibles clases de equivalencia:

1.Identificar clases de equivalencia. Definir clases de datos válidos y no válidos.
• CE válida: 0 <= X <= 100
• 1ra CE no válida: X > 100
• 2da CE no válida: X < 0
• 3ra CE no válida: X = decimal
• 4ta CE no válida: X = alfanumérico
TECNICAS DINAMICAS
Método: Análisis de Valores Límite.
Ejemplo
• Construcción de una batería de pruebas para detectar posibles errores en la construcción de los
identificadores de un hipotético lenguaje de programación. La regla que determina su construcción
sintáctica es: No debe tener mas de 15 ni menos de 5 caracteres
TECNICAS DINAMICAS
Método:
Pruebas de Casos de Uso
• Los casos de prueba son obtenidos desde los casos
de uso.
• Cada caso de uso puede ser utilizado como
fuente para un caso de prueba, pero cada
paso alternativo del caso de uso, se traduce
en una prueba distinta.
• Cada caso de uso describe una cierta interacción
usuario-sistema. Elementos: precondiciones, pasos
del comportamiento del sistema, post condiciones.
• Beneficios
• Pruebas apropiadas para pruebas de
aceptación y de sistema.
• Útil para diseñar pruebas con el cliente/usuario
• Puede ser combinadas con otras técnicas
basadas en la especificación
• Desventajas
• No es posible obtener casos de prueba más
allá de la información de los casos de uso.
TECNICAS DINAMICAS
Método: Pruebas de Casos de Uso.
Ejemplo del cajero automático

Prueba 1. Insertar tarjeta (no válida); fin

Prueba 2. Insertar tarjeta (válida); introduce código (no
válido); fin
Prueba 3. Insertar tarjeta (válida); introduce código
(válido);…; fin
Prueba 4. Insertar tarjeta (válida); introduce código (no
válido); introduce código (no válido); fin
TECNICAS DINAMICAS
CAJA BLANCA:
• El tester conoce la estructura interna del código, i.e., la jerarquía de componentes, flujo de control y
datos, etc.
• Los casos de prueba son seleccionados en base a la estructura del código.
• La estructura del trabajo es el foco de atención
• La técnica de caja blanca también es conocida como prueba basada en la estructura o prueba basada
en el flujo de control.
TECNICAS DINAMICAS
CAJA BLANCA:
• Los métodos de caja blanca requieren el apoyo de herramientas, lo que asegura la calidad de las
pruebas e incrementa su eficiencia.
• Dada la complejidad de las mediciones necesarias para las pruebas de caja blanca, la ejecución manual
implica: consumo de tiempo y recursos, dificultad en la implementación y propensión a errores.
• Métodos de caja blanca (basados en la cobertura)
• Cobertura de sentencias.
• Cobertura de decisión.
• Cobertura de condición (simple y múltiple).
• Cobertura de caminos.

Método: Cobertura de Sentencias

• Técnica basada en el análisis del gráfico del flujo de control (sentencias = nodos; flujo de control =
aristas). El foco de atención es la sentencia del código !
• Objetivo: lograr la cobertura de un porcentaje específico (C0) de todas las sentencias. Cada sentencia
se debe ejecutar, al menos, una vez.
C0 = 100% * (nº sentencias ejecutadas / nº total sentencias)
TECNICAS DINAMICAS
CAJA BLANCA:
Método: Cobertura de Sentencias. Ejemplo
Todas las sentencias pueden ser alcanzadas haciendo uso de un único camino, 100% de cobertura de
sentencia. Un único caso prueba.
TECNICAS DINAMICAS
CAJA BLANCA:
Método: Cobertura de Decisión
• Se centra en el flujo de control (aristas del diagrama de flujo)
• Objetivo: Todas las aristas del diagrama de flujo tiene que ser cubiertas al menos una vez. Lograr un
porcentaje de cobertura de todas las decisiones (C1)
C1 = 100% * (nº decisiones ejecutadas / nº total decisiones)
Ejemplo:
• ¿Cuántos caminos consigue una cobertura de precisión del 100%?
• Una cobertura de decisión del 100% requiere, al menos, los mismos casos de prueba que una cobertura
sentencia.
TECNICAS DINAMICAS
CAJA BLANCA:
Método: Cobertura de Condición
Objetivo: detectar defectos en la implantación de condiciones.
• En este criterio es necesario presentar un número suficiente de casos de prueba de modo que cada
condición en una decisión tenga, al menos una vez, todos los resultados posibles.
• Tipos:
• Cobertura de condición simple.
• Cobertura de condición múltiple.

Método: Cobertura de Condición SIMPLE

• Cada subcondición atómica de una sentencia condicional tiene que tomar, al menos una vez, los
valores verdadero ("true") y falso ("false").
Ejemplo: considerar la condición A>2 OR B<6. En los casos de prueba para la cobertura de condición
simple podrían ser (por ejemplo):
• Con sólo dos casos de prueba se puede lograr una cobertura de condición simple.
• Cada subcondición ha tomado los valores verdadero y falso.
• Sin embargo, el resultado combinado es verdadero en ambos casos.

A = 6 (true) B = 9 (false) A>2 OR B<6 (true) A = 1 (false) B = 2 (true) A>2 OR B<6 (true)
TECNICAS DINAMICAS
CAJA BLANCA:
Método: Cobertura de Condición MÚLTIPLE
• Todas las combinaciones que pueden ser creadas utilizando permutaciones de las subcondiciones
atómicas deben formar parte de las pruebas.

Ejemplo: considerar la condición A>2 OR B<6. En los casos de prueba para la cobertura de condición
múltiple podrían ser (por ejemplo):
• Con sólo 4 casos de prueba se puede lograr una cobertura de condición múltiple.
• Se han creado todas las combinaciones verdadero/falso.
• Se han logrado todos los posibles resultados de la condición.

nº casos de prueba exponencial: 2n, donde n = nº condiciones atómicas

A = 6 (true) B = 9 (false) A>2 OR B<6 (true)

A = 6 (true) B = 2 (true) A>2 OR B<6 (true)
A = 1 (false) B = 2 (true) A>2 OR B<6 (true)
A = 1 (false) B = 9 (false) A>2 OR B<6 (false)
TECNICAS DINAMICAS
CAJA BLANCA:
Método:
Cobertura de Camino: Consiste en ejecutar todos los posibles cambios a través de un programa. Esto
puede conducir a un nº muy alto de casos de prueba.
• Camino: secuencia de instrucciones en el flujo de control (nodos y aristas en el diagrama de
control).
• Cada camino va desde el nodo inicial al final del diagrama de flujo de control.
Para una cobertura de decisión, un solo camino a través de un bucle es suficiente. Sin embargo, en la
cobertura por caminos hay más casos de prueba:
• Un caso prueba no entrante en el bucle
• Un caso prueba adicional para cada ejecución del bucle

Objetivo: alcanzar un porcentaje definido de cobertura de camino (CC):

• CC = 100% * (nº caminos cubiertos / nº total caminos)
TECNICAS DINAMICAS
CAJA BLANCA:
Ejemplo:
• ¿Cuántos casos de prueba para una cobertura de
camino del 100%? 5 casos de prueba
• ¿Cuántos casos de prueba para una cobertura de
sentencia del 100%? 2 casos de prueba
• ¿Cuántos casos de prueba para una cobertura de
decisión del 100%? 3 casos de prueba

Aspectos a tener en cuenta:

• El 100% de cobertura de caminos sólo en programas
muy simples.
• La cobertura de camino es más exhaustiva que la
cobertura de sentencia y de decisión.
• El 100% de cobertura de camino incluye el 100% de
cobertura de decisión que a su vez incluye el 100%
de cobertura de sentencia.
TECNICAS DINAMICAS
CAJA BLANCA:
Método: Cobertura de Condición
Objetivo: detectar defectos en la implantación de
condiciones.
• En este criterio es necesario presentar un número
suficiente de casos de prueba de modo que cada
condición en una decisión tenga, al menos una vez,
todos los resultados posibles.
• Tipos:
• Cobertura de condición simple.
• Cobertura de condición múltiple.
Herramientas de gestión de pruebas Herramientas para pruebas funcionales
–Bugzilla Testopia –Selenium-
–FitNesse –Soapui
–qaManager –Watir (Pruebas de aplicaciones web en Ruby)
–qaBook –WatiN (Pruebas de aplicaciones web en .Net)
–RTH (open source) –Capedit
–Salome-tmf –Canoo WebTest
–Squash TM –Solex
–Test Environment Toolkit –Imprimatur
–TestLink –SAMIE
–Testitool –ITP
–XQual Studio –WET
–Radi-testdir –WebInject
–Data Generator
Herramientas para pruebas de carga y Herramientas de calidad del Producto Software
rendimiento –PMD
–FunkLoad –Check Style
–FWPTT load testing –SONAR-
–loadUI –.Simian
–jmeter
Herramientas de gestión de pruebas Herramientas para pruebas funcionales
–HP Quality Center/ALM –QuickTest Pro
–QA Complete –Rational Robot
–qaBook –Sahi
–T-Plan Professional –SoapTest
–SMARTS –Test Complete
–QAS.Test Case Studio –QA Wizard
–PractiTest –Squish
–SpiraTest –vTest
–TestLog –Internet Macros
–ApTest Manager
–Zephyr
Herramientas para pruebas de carga y rendimiento Herramientas de calidad del Producto Software
–HP LoadRunner –ChecKing QA
–LoadStorm –Kiuwan
–NeoLoad –Google CodePro Analytix
–WebLOAD Professional –.Simian
–Forecast
–ANTS – Advanced .NET Testing System
–Webserver Stress Tool
–Load Impact
BIBLIOGRAFIA
• Barrientos, Pablo Andrés (04 de 2014). Enfoque para pruebas de unidad basado en la generación
aleatoria de objetos. p. 101. Consultado el 28 de abril de 2014.
• Testing and Quality Assurance for Component-Based Software (Artech House Computer Library),
Jerry Zeyu Gao, H.-S. Jacob Tsao, Ye Wu
THANK YOU!