ACTIVIDAD

EVALUACION DE SOFTWARE

OSCAR ANDRES SEPULVEDA PEREZ

INGENIERA DE SISTEMAS IX SEMESTRE

UNIVERSIDAD DE CARTAGENA CREAD - LORICA

FACULTAD INGENIERA DE SISTEMAS

TUTOR:

ING: FERNANDO DAZA ILLERA

LORICA CORDOBA

2017
 ACTIVIDADES
PREGUNTAS Y RESPUESTAS

Consultar las siguientes normas:

ISO 8402, ISO 15939, ISO/IEC 9126, ISO/IEC 14598, ISO/IEC 15504, ISO/IEC 25000 SquaRE
(Software product Quality REquirements), Modelo de Madurez de Capacidad para el Software
(Capahility Maturity Model, CMM), CMMI (capability Maturity Model integration), (European
System and Software Iniciative, ESSI)

Consultar:

MTRICAS DEL SOFTWARE, Medidas Directas, Mtricas Indirectas, Mtricas orientadas al

tamao, Mtricas orientadas a la funcin

MTRICAS DE CALIDAD DEL SOFTWARE, Correccin, Facilidad de mantenimiento,

Integridad, Facilidad de Uso, Eficacia de la eliminacin de defectos

MTRICAS TCNICAS DEL SOFTWARE, Factores de calidad de McCall, Mtricas para el

esquema de puntuacin, Mtricas del modelo de Calidad FURPS, Factores de calidad ISO
9126

ESTRUCTURA PARA LAS MTRICAS TCNICAS DEL SOFTWARE, Mtricas del Modelo
de Anlisis, Mtricas basadas en la Funcin, Mtrica Bang, Mtricas del Modelo de Diseo,
Mtricas del Cdigo Fuente, Mtricas para Pruebas, Mtricas del Mantenimiento

PRUEBA DEL SOFTWARE

TCNICAS DE DISEO DE CASOS DE PRUEBA, Pruebas de caja blanca, Pruebas de caja

negra, Particiones o clases de equivalencia, Anlisis de Valores Lmite (AVL), Conjetura de
errores, Pruebas Aleatorias

ESTRATEGIAS DE APLICACIN DE PRUEBAS DEL SOFTWARE, Prueba de unidad,

Pruebas de integracin, Integracin incremental ascendente, Integracin Incremental
Descendente, Integracin no incremental, Prueba del sistema, Prueba de aceptacin, Prueba
de validacin y verificacin, Prueba del sistema, Prueba de Recuperacin, Prueba de
Seguridad, Prueba de Resistencia, Depuracin

PRUEBA DE SOFTWARE PARA OBJETOS, Mtodos de prueba de software orientado a

objetos, Pruebas de unidad, Pruebas de integracin, Pruebas de sistema

PRUEBA DE SOFTWARE BASADO EN COMPONENTES, Pruebas de unidad, Pruebas de

integracin, El volumen y la lentitud, Los mecanismos de comunicacin utilizados

DESARROLLO
ISO 8402: Es un complemento de la serie de normas ISO 9000. En ella se definen trminos
relacionados con la calidad. Clarifica y normaliza los trminos relativos a la calidad que sean
aplicables al campo de la gestin de la calidad. La necesidad de utilizar una terminologa
normalizada para evitar malentendidos o confusiones, oblig al desarrollo de una norma
auxiliar que precisara trminos y conceptos.

ISO 15939: define un proceso de medicin aplicable a sistemas e ingeniera de software y

disciplinas de gestin. El proceso se describe a travs de un modelo que define las actividades
del proceso de medicin que se requieren para especificar adecuadamente lo que la
informacin de medicin se requiere, cmo se han de aplicar las medidas y resultados de
anlisis, y cmo determinar si los resultados del anlisis son vlidos. El proceso de medicin
es flexible, tailorable, y adaptable a las necesidades de diferentes usuarios.

El estndar ISO/IEC 9126 proviene desde el modelo establecido en 1977 por McCall y sus
colegas, los cuales propusieron un modelo para especificar la calidad del software. El modelo
de calidad McCall est organizado sobre tres tipos de Caractersticas de Calidad:
Factores (especificar): Describen la visin externa del software, como es visto por los usuarios.
Criterios (construir): Describen la visin interna del software, como es visto por el desarrollador.
Mtricas (controlar): Se definen y se usan para proveer una escala y mtodo para la medida.
ISO/IEC 9126 es un estndar internacional para la evaluacin del Software. Est supervisado
por el proyecto SQuaRE, ISO 25000:2005, el cual sigue los mismos conceptos.

Norma ISO/IEC 14598: En sus diferentes etapas, establece un marco de trabajo para evaluar
la calidad de los productos de software proporcionando, adems, mtricas y requisitos para
los procesos de evaluacin de los mismos.
En particular, es utilizada para aplicar los conceptos descritos en la norma ISO / IEC 9126. Se
definen y describen las actividades necesarias para analizar los requisitos de evaluacin, para
especificar, disear y realizar acciones de evaluacin y para concluir la evaluacin de cualquier
tipo de producto de software.
El ISO/IEC 15504, tambin conocido como Software Process Improvement Capability
Determination, abreviado SPICE, en espaol, Determinacin de la Capacidad de Mejora del
Proceso de Software es un modelo para la mejora, evaluacin de los procesos de desarrollo,
mantenimiento de sistemas de informacin y productos de software.
ISO/IEC 25000 SQuaRE (Software Product Quality Requirements and Evaluation) es
organizar, enriquecer y unificar las series que cubren dos procesos principales: especificacin
de requisitos de calidad del software y evaluacin de la calidad del software, soportada por el
proceso de medicin de calidad del software.
Las caractersticas de calidad y sus mediciones asociadas pueden ser tiles no solamente
para evaluar el producto software sino tambin para definir los requerimientos de calidad.La
serie ISO/IEC 25000:2005 reemplaza a dos estndares relacionados: ISO/IEC 9126 (Software
Product Quality) e ISO/IEC 14598 (Software Product Evaluation).

El Modelo de Madurez de Capacidades o CMM (Capability Maturity Model), es un modelo de

evaluacin de los procesos de una organizacin. Fue desarrollado inicialmente para los
procesos relativos al desarrollo e implementacin de software por la Universidad Carnegie-
Mellon para el SEI (Software Engineering Institute).
El SEI es un centro de investigacin y desarrollo patrocinado por el Departamento de Defensa
de los Estados Unidos de Amrica y gestionado por la Universidad Carnegie-Mellon. "CMM"
es una marca registrada del SEI.

Integracin de modelos de madurez de capacidades o Capability Maturity Model

Integration (CMMI) es un modelo para la mejora y evaluacin de procesos para el desarrollo,
mantenimiento y operacin de sistemas de software.

CONSULTAR
MTRICAS DEL SOFTWARE En el campo de la ingeniera del software una mtrica es
cualquier medida o conjunto de medidas destinadas a conocer o estimar el tamao u otra
caracterstica de un software o un sistema de informacin, generalmente para realizar
comparativas o para la planificacin de proyectos de desarrollo. Un ejemplo ampliamente
usado es la llamada mtrica de punto funcin.

Las mtricas de software se refieren aun amplio rango de medidas para el software de
computadoras dentro del contexto de la planificacin del proyecto de software, las mtricas de
calidad pueden ser aplicadas a organizaciones, procesos y productos los cuales directamente
afectan a la estimacin de costos.

Las mediciones en el mundo fsico pueden ser catalogadas en dos campos: medidas directas
(por ej. La longitud de un tornillo), y medidas indirectas (por ej. Calidad de tornillos producidos,
medida por la cuenta de los tornillos rechazados). Las mtricas de software pueden ser
catalogadas de forma parecida.

Mtricas Orientadas al tamao, son utilizadas para obtener medidas directas del resultado y la
calidad de la ingeniera del software.

Mtricas Orientadas a la Funcin, son medidas indirectas del software y del proceso por el cual
se desarrollar; se centran en la funcionalidad o utilidad del programa (Puntos de Funcin)

Mtricas para la calidad del Software

Desarrollando y analizando una linea base de mtricas de calidad, una organizacin puede
actuar con objeto de corregir esas reas de proceso del software que son la causa de los
defectos del software. Con la creacin de estas mtricas los ingenieros del software pueden
obtener una visidn ms profunda del trabajo que realizan y del producto que elaboran.
La correccin, facilidad de mantenimiento, integridad, y facilidad de uso son medidas de
calidad que proporcionan indicadores tiles para el equipo del proyecto.
Correccin: La correccin es el grado en el que el software lleva a cabo su funcin requerida.
Facilidad de mantenimiento: Es la facilidad con la que se puede corregir un programa si se
encuentra un error, se puede adaptar si su entono cambia, o mejorar si el cliente desea un
carnio de requisitos. Esta actividad cuenta con ms esfuerzo que cualquier otra actividad de
ingeniera del software.
Integridad: Mide la capacidad de un sistema para resistir ataques (tanto accidentales como
intencionados) contra su seguridad. El ataque se puede realizar en cualquiera de los tres
componentes del software: programas, datos y documentos.
Para medir la integridad, se tienen que definir dos atributos adicionales: amenaza y seguridad.
Amenaza es la probabilidad de que un ataque de un tipo determinado ocurra en un tiempo
determinado. La seguridad es la probabilidad de que se pueda repeler el ataque de un tipo
determinado. La integridad del sistema se puede definir corno: Integridad = C [(l - amenaza) x
(1 - seguridad)] Donde se suman la amenaza y la seguridad para cada tipo de ataque.
Facilidad de uso: La facilidad de uso es un intento de cuantificar lo amigable que puede ser el
programa con el usuario. Se puede medir en funcin de cuatro caractersticas: Habilidad
intelectual y/o fisica requerida para aprender el sistema. El tiempo requerido para llegar a ser
moderadamente eficiente en el uso del sistema. Aumento neto en productividad, medida
cuando alguien utiliza el sistema moderadamente y eficientemente. Valoracin subjetiva de la
disposicin de 1os usuarios hacia el sistema, a veces obtenida mediante un cuestionario.

Eficacia de la Eliminacin de Defectos

Proporciona beneficios tanto a nivel del proyecto como del proceso, es una medida para filtrar
las actividades de la garanta de calidad y de control al aplicarse a todas las actividades del
marco de trabajo del proceso.
La Eficacia de la Eliminacin de Defectos (EED) se define de la forma siguiente: EED=E /
(E+D) Donde E es el nmero de errores encontrados antes de la entrega del software al usuario
final y D es el nmero de defectos encontrados despus de la entrega. Cuando el valor de EED
es 1 significa que no se han encontrado defectos en el software, D ser mayor que cero.
Cuando E aumenta (para un valor de D dado), el valor total de EED empieza a aproximarse a
1. De hecho, a medida que E aumenta, es probable que el valor final de D disminuya (los
errores se filtran antes de que se conviertan en defectos). Si se utilizan como una mtrica que
proporciona un indicador de la habilidad de filtrar las actividades de la garanta de la calidad y
del control, EED anima a que el equipo del proyecto de software instituya tcnicas para
encontrar todos los errores posibles antes de su entrega.
EED tambin se puede utilizar dentro del proyecto para evaluar la habilidad de un equipo en
encontrar errores antes de que pasen a la siguiente tarea de ingeniera del software. Se vuelve
a definir como:
EEDi = Ei / (Ei + Ei +1)
Donde Ei es el nmero de errores encontrado durante la actividad de ingeniera del software i
y Ei+1, es el nmero de errores encontrado durante la actividad de ingeniera del software i +
1 que se puede seguir para llegar a errores que no se detectaron en la actividad de la ingeniera
del software i.
Mtricas tcnicas
En este punto, nos damos cuenta que la medicin del software bajo las tcnicas vistas carece
de objetividad, uno que las consideramos tcnicas cualitativas y no cuantitativos. Ahora bien,
el problema es cmo definir un mtodo de medicin que nos permitan mostrar a travs de una
cantidad la complejidad del software.
Entonces, lo primero que debemos hacer es definir una serie de caractersticas que deben
cumplir las tcnicas de medicin para poder tener un criterio base, que nos permita evaluar las
tcnicas de medicin.

Mtrica para el esquema de puntuacin: Facilidad de auditora: la facilidad con la que se

puede comprobar el cumplimiento de los estndares. Exactitud : la exactitud de lo clculos y
el control. Estandarizacin de comunicaciones : el grado de empleo de estndares de
interfaces, protocolos y anchos de banda. Compleccin: el grado con que se ha logrado la
implementacin total de una funcin. Concisin : Lo compacto que es el programa en trminos
de lneas de cdigo

Mtricas del modelo de Calidad FURPS (Funcionality, Usability, Reliability, Performance,

Supportability) Hewlett Packard ha desarrollado un conjunto de factores de calidad del software
al que se le ha dado el acrnimo de FURPS: funcionalidad, facilidad de empleo, fiabilidad,
rendimiento y capacidad de soporte. Los factores de calidad son cinco y se definen de acuerdo
al siguiente conjunto de atributos: Funcionalidad. Se valora evaluando el conjunto de
caractersticas y capacidades del programa, la generalidad de las funciones entregadas y la
seguridad del sistema global. Facilidad de uso . Se valora considerando factores humanos, la
estetica, consistencia y documentacin general.

Factores de calidad de McCall:

McCall puedo poner una clasificacin de factores que se concentran en tres aspectos
importantes:
Sus caractersticas operativas
Su capacidad de cambio
Su adaptabilidad a nuevos entornos
Dentro de tres aspectos McCall analizar los siguientes factores:
Correccin
Fiabilidad
Eficiencia
Integridad
Usabilidad
La facilidad de mantenimiento
Flexibilidad
La facilidad de prueba
Portabilidad
Reusabilidad
Interoperatividad

Basndonos en todas estas caractersticas la forma de evaluar el software que es dar una
calificacin de la mtrica, multiplicado por un factor de calidad del software y finalmente realizar
una sumatoria de esto.
McCall lo puso en una escala de calificacin del cero al diez, en donde cero es baja calidad y
diez es alta calidad.
Aunque este mtodo es bastante flexible y puede adaptarse a cualquier entorno las mediciones
se basan en un criterio subjetivo.

Factores de calidad iso 9126

ISO es reconocida mundialmente como el organismo certificador de calidad por excelencia, y
das bajo el estndar 9126 que define los siguientes atributos claves de la calidad del software:
Funcionalidad
Confiabilidad
Usabilidad
Eficiencia
Facilidad de mantenimiento
Portabilidad
Al igual que en otros casos los atributos definidos por la iso 9126 son medidas indirectas y una
excelente gua para determinar la calidad del software.

Estructura para las mtricas tcnicas del software

conseguir dar valores cuantitativos a las mtricas, es necesario establecer un

modelo de medicin.
Segn Fenton: Desarrollar una mtrica nica sera semejante a la bsqueda imposible
del santo grial.
Segn Shari Pfleeger: Lo mismo que las medidas de temperatura comienzan con
un ndice de referencia y evolucionan por sofisticadas escala, herramientas y
tcnicas, las medidas del software estn evolucionando.

Mtricas del Modelo de Anlisis

En esta fase es deseable que las mtricas tcnicas proporcionen una visin interna a la calidad
del modelo de anlisis. Estas mtricas examinan el modelo de anlisis con la intencin de
predecir el "tamao" del sistema resultante; es probable que el tamao y la complejidad del
diseo estn directamente relacionadas.

MTRICAS BASADAS EN LA FUNCIN

La mtrica del punto de funcin (PF) se puede utilizar como medio para predecir el tamao de
un sistema obtenido a partir de un modelo de anlisis. Para visualizar esta mtrica se utiliza
un diagrama de flujo de datos, el cual se evaluar para determinar las siguientes medidas clave
que son necesarias para el clculo de la mtrica de punto de funcin:

Nmero de entradas del usuario

Nmero de salidas del usuario
Nmero de consultas del usuario
Nmero de archivos
Nmero de interfaces externas
La cuenta total debe ajustarse utilizando la siguiente ecuacin: PF = cuenta-total x (0,65 +
0,01 x Fi)
Donde cuenta total es la suma de todas las entradas PF obtenidas de la figura 9.2 y Fi (i=1 a
14) son los "valores de ajuste de complejidad"

Para el ejemplo descrito en la figura 9.2 se asume que la EFi es 46 (un producto
moderadamente complejo), por consiguiente:
PF = 50 x (0,65 + 0,01 x 46) = 56

Basndose en el valor previsto del PF obtenido del modelo de anlisis, el equipo del proyecto
puede estimar el tamao global de implementacin de las funciones de interaccin. Asuma
que los datos de los que se dispone indican que un PF supone 60 lneas de cdigo (se utilizar
un lenguaje orientado a objetos) y que en un esfuerzo de un mes-persona se producen 12 PF.
Estos datos histricos proporcionan al gestor del proyecto una importante informacin de
planificacin basada en el modelo de anlisis en lugar de estimaciones preliminares.

MTRICA BANG

Al igual que la mtrica de punto de funcin, la mtrica bang puede emplearse para desarrollar
una indicacin
del tamao del software a implementar como consecuencia del modelo de anlisis.

Desarrollada por DeMarco, la mtrica bang es una indicacin independiente de la

implementacin del tamao del sistema. Para calcular la mtrica bang, el desarrollador de
software debe evaluar primero un conjunto de primitivas (elementos del modelo de anlisis que
no se subdividen ms en el nivel de anlisis).

Las primitivas se determinan evaluando el modelo de anlisis y desarrollando cuentas para los
siguientes elementos:

Primitivas funcionales (PFu). Transformaciones (burbujas) que aparecen en el nivel inferior

de un diagrama de flujo de datos.

Elementos de datos (ED). Los atributos de un objeto de datos, los elementos de datos son
datos no compuestos y aparecen en el diccionario de datos.

Objetos (OB). Objetos de datos.

Relaciones (RE). Las conexiones entre objetos de datos.

Estados (ES). El nmero de estados observables por el usuario en el diagrama de transicin

de estados.

Transiciones (TR). El nmero de transiciones de estado en el diagrama de transicin de

estados.

Adems de las seis primitivas apuntadas arriba, se determinan las cuentas adicionales para:

Primitivas modificadas de funcin manual (PMFu). Funciones que caen fuera del lmite del
sistema y que deben modificarse para acomodarse al nuevo sistema.

Elementos de datos de entrada (EDE). Aquellos elementos de datos que se introducen en el

sistema.

Elementos de datos de salida (EDS). Aquellos elementos de datos que se sacan del sistema.
Elementos de datos retenidos (EDR). Aquellos elementos de datos que son retenidos
(almacenados) por el sistema.

Muestras (tokens) de datos (TCi). Las muestras de datos (elementos de datos que no se
subdividen dentro de una primitiva funcional) que existen en el lmite de la i-sima
primitiva funcional (evaluada para cada primitiva).

Conexiones de relacin (REi). Las relaciones que conectan el i-simo objeto en el modelo
de datos con otros objetos.

DeMarco sugiere que la mayora del software se puede asignar a uno de los dos dominios
siguientes, dominio de funcin o dominio de datos, dependiendo de la relacin RE/PFu. Las
aplicaciones de dominio de

funcin (encontradas comnmente en aplicaciones de ingeniera y cientficas) hacen hincapi

en la transformacin de datos y no poseen generalmente estructuras de datos complejas. Las
aplicaciones de dominio de datos (encontradas comnmente en aplicaciones de sistemas de
informacin) tienden a tener modelos de datos complejos.

RE/PFu < 0,7 implica una aplicacin de dominio de funcin

0,8 < RE/PFu < 1,4 indica una aplicacin hbrida

RE/PFu > 13 implica una aplicacin de dominio de datos

Como diferentes modelos de anlisis harn una particin del modelo con mayor o menor grado
de refinamiento. DeMarco sugiere que se emplee una cuenta media de muestra (token) por
primitiva

Teavg= DC,IPFu

para controlar la uniformidad de la particin a travs de muchos diferentes modelos dentro del
dominio de una aplicacin.

Para calcular la mtrica bang para aplicaciones de dominio de funcin, se emplea el siguiente
algoritmo:

Asignar a bang un valor inicial = 0;

Mientras queden primitivas funcionales por evaluar

Calcular cuenta-token alrededor del lmite de la primitiva i;

Calcular el incremento PFu corregido (IPFuC)

Asignar la primitiva a una clase

Evaluar la clase y anotar el peso valorado

Multiplicar IPFuC por el peso valorado

bang = bang + ponderacin IPFuC;

FinMientras

La cuenta-token se calcula determinando cuntos smbolos lxicos (tokens) diferentes son

visibles dentro de la primitiva. Es posible que el nmero de smbolos lxicos (tokens) y el
nmero de elementos de datos sea diferente, si los elementos de datos pueden moverse
desde la entrada a la salida sin ninguna transformacin interna. La IPFuC corregida se
determina de una tabla publicada por DeMarco. A continuacin, se presenta una versin muy
abreviada:

La ponderacin valorada apuntada en el algoritmo anterior se calcula de diecisis clases

diferentes de primitivas funcionales definidas por DeMarco. Se asigna una ponderacin que va
de 0,6 (encaminamiento simple de datos) a 2,5 (funciones de gestin de datos)
dependiendo de la clase de la primitiva.

Para aplicaciones de dominio de datos, se calcula la mtrica bang mediante el siguiente

algoritmo:

Asignar a bang el valor inicial = 0;

Mientras queden objetos por evaluar en el modelo de datos

Calcular la cuenta de relaciones del objeto i

Calcular el incremento de OB corregido (IOBC); bang = bang t IOBC;

FinMientras

El IOBC corregido se determina tambin de una tabla publicada por DeMarco. A continuacin
se muestra una versin abreviada:

Una vez que se ha calculado la mtrica bang, se puede emplear el historial anterior para
asociarla con el esfuerzo y el tamao. DeMarco sugiere que las organizaciones se construyan
sus propias versiones de tablas

IPFuC e IOBC para calibrar la informacin de proyectos completos de software.

Mtricas del Modelo del Diseo

Es inconcebible que el diseo de un nuevo avin, un nuevo chip de computadora o un nuevo
edificio de oficinas se realizara sin definir las medidas del diseo, sin determinar las mtricas
para varios aspectos de la calidad del diseo y usarlas para guiar la evolucin del diseo. Y
sin embargo, el diseo de sistemas complejos basados en computadora a menudo consigue
proseguir sin virtualmente ninguna medicin. La irona es que las mtricas de diseo para el
software estn disponibles, pero la gran mayora de los desarrolladores de software continan
sin saber que existen.

Las mtricas de diseo para el software, como otras mtricas del software, no son perfectas.
Contina el debate sobre la eficacia y cmo deberan aplicarse. Muchos expertos argumentan
que se necesita ms experimentacin hasta que se puedan emplear las mtricas de diseo. Y
sin embargo, el diseo sin medicin es una alternativa inaceptable.
Mtricas del Cdigo Fuente
La teora de Halstead de la ciencia del software es probablemente la mejor conocida y ms
minuciosamente estudiada ... medidas compuestas de la complejidad (software). La ciencia
del software

Propone las primeras leyes analticas para el software de computadora.

La ciencia del software asigna leyes cuantitativas al desarrollo del software de computadora,
usando un conjunto de medidas primitivas que pueden obtenerse una vez que se ha generado
o estimado el cdigo despus de completar el diseo. Estas medidas se listan a continuacin.

Halstead usa las medidas primitivas para desarrollar expresiones para la longitud global del
programa; volumen mnimo potencial para un algoritmo; el volumen real (nmero de bits
requeridos para especificar un programa); el nivel del programa (una medida de la complejidad
del software); nivel del lenguaje (una constante para un lenguaje dado); y otras
caractersticas tales como esfuerzo de desarrollo, tiempo de desarrollo e incluso el nmero
esperado de fallos en el software.

Halstead expone que la longitud N se puede estimar como:

y el volumen de programa se puede definir como:

Se debera tener en cuenta que V variar con el lenguaje de programacin y representa el

volumen de informacin (en bits) necesarios para especificar un programa.
Tericamente, debe existir un volumen mnimo para un algoritmo. Halstead define una relacin
de volumen L como la relacin de volumen de la forma ms compacta de un programa con
respecto al volumen real del programa. Por tanto, L debe ser siempre menor de uno. En
trminos de medidas primitivas, la relacin de volumen se puede expresar como:

Mtricas para Pruebas

Aunque se ha escrito mucho sobre las mtricas del software para pruebas, la mayora de las
mtricas propuestas se concentran en el proceso de prueba, no en las caractersticas tcnicas
de las pruebas mismas. En general, los responsables de las pruebas deben fiarse de las
mtricas de anlisis, diseo y cdigo para que les guen en el diseo y ejecucin de los casos
de prueba.

Las mtricas basadas en la funcin pueden emplearse para predecir el esfuerzo global de las
pruebas. Se pueden juntar y correlacionar varias caractersticas a nivel de proyecto (por
ejemplo, esfuerzo y tiempo para las pruebas, errores descubiertos, nmero de casos de
prueba producidos) de proyectos anteriores con el nmero de PF producidos por un equipo del
proyecto. El equipo puede despus predecir los valores esperados de estas caractersticas
del proyecto actual.

La mtrica bang puede proporcionar una indicacin del nmero de casos de prueba necesarios
para examinar las medidas primitivas. El nmero de primitivas funcionales (PFu),
elementos de datos (DE), objetos (OB), relaciones (RE), estados (ES) y transiciones (TR)
pueden emplearse para predecir el nmero y tipos de prueba del software de caja negra y de
caja blanca. Por ejemplo, el nmero de pruebas asociadas con la interfaz hombre-mquina se
puede estimar examinando: (1) el nmero de transiciones (TR) contenidas en la
representacin estado-transicin del IHM y evaluando las pruebas requeridas para
ejecutar cada transicin, (2) el nmero de objetos de datos (OB) que se mueven a travs de la
interfaz y (3) el nmero de elementos de datos que se introducen o salen.
Las mtricas del diseo arquitectnico proporcionan informacin sobre la facilidad o dificultad
asociada con

la prueba de integracin y la necesidad de software especializado de prueba (por ejemplo,

matrices y controladores). La complejidad ciclomtica (una mtrica de diseo de
componentes) se encuentra en el ncleo de las pruebas de caminos bsicos. Adems, la
complejidad ciclomtica puede usarse para elegir mdulos como candidatos para pruebas ms
profundas. Los mdulos con gran complejidad ciclomtica tienen ms probabilidad de
tendencia a errores que los mdulos con menor complejidad ciclomtica.

Por esta razn, el analista debera invertir un esfuerzo extra para descubrir errores en el
mdulo antes de integrarlo en un sistema. Es esfuerzo de las pruebas tambin se puede
estimar usando mtricas obtenidas de medidas de Halstead. Usando la definicin del
volumen de un programa, V, y nivel de programa, NP, el esfuerzo de la ciencia del software,
e, puede calcularse como:

El porcentaje del esfuerzo global de pruebas a asignar a un mdulo k se puede estimar usando
la siguiente relacin:

donde e(k) se calcula para el mdulo k usando la primera ecuaciones y la suma en el

denominador de la segunda ecuacin es la suma del esfuerzo de la ciencia del software a lo
largo de todos los mdulos del sistema.

A medida que se van haciendo las pruebas, tres medidas diferentes proporcionan una
indicacin de la complecin de las pruebas. Una medida de la amplitud de las pruebas
proporciona una indicacin de cuantos requisitos (del nmero total de ellos) se han probado.
Esto proporciona una indicacin de la complecin del plan de pruebas. La profundidad de las
pruebas es una medida del porcentaje de los caminos bsicos independientes probados en
relacin al nmero total de estos caminos en el programa. Se puede calcular una
estimacin razonablemente exacta del nmero de caminos bsicos sumando la complejidad
ciclomtica de todos los mdulos del programa. Finalmente, a medida que se van haciendo las
pruebas y se recogen los datos de los errores, se pueden emplear los perfiles de fallos para
dar prioridad y categorizar los errores descubiertos. La prioridad indica la severidad del
problema. Las categoras de los fallos proporcionan una descripcin de un error, de manera
que se puedan llevar a cabo anlisis estadsticos de errores.

Mtricas del Mantenimiento

Todas las mtricas del software pueden usarse para el desarrollo de nuevo software y para el
mantenimiento del existente. Sin embargo, se han propuesto mtricas diseadas
explcitamente para actividades de mantenimiento.

El estndar EEE 982.1-1988 sugiere un ndice de madurez del software (IMS) que proporciona
una indicacin de la estabilidad de un producto software (basada en los cambios que ocurren
con cada versin del producto). Se determina la siguiente informacin:

El ndice de madurez del software se calcula de la siguiente manera:

A medida que el IMS se aproxima a 1 ,O el producto se empieza a estabilizar. EL IMS puede

emplearse tambin como mtrica para la planificacin de las actividades de mantenimiento del
software. El tiempo medio para producir una versin de un producto software
puede correlacionarse con el IMS desarrollndose modelos empricos para el mantenimiento.
PRUEBA DEL SOFTWARE

Los casos de prueba quedarn determinados por los valores a asignar a las entradas en su
ejecucin El objetivo es disear casos de prueba que, sistemticamente, saquen a la luz
diferentes clases de errores, hacindolo con la menor cantidad de tiempo y de
esfuerzo.

La prueba no puede asegurar la ausencia de errores; slo puede demostrar

que existen defectos en el software. Pruebas de caja negra: Realizar pruebas de forma que se
compruebe que cada funcin es operativa.

Pruebas de caja blanca: Desarrollar pruebas de forma que se asegure que la operacin interna
se ajusta a las especificaciones, y que todos los componentes internos se han probado de
forma adecuada. El criterio de seleccin de casos de prueba buscar cierta cobertura caminos
independientes valores de las condiciones bucles dentro y fuera de sus lmites operacionales
estructuras de datos
los errores se esconden en los rincones y se acumulan en las fronteras Permiten detectar:
funcionamiento incorrecto o incompleto errores interface errores accesos estructuras de datos
externas problemas de rendimiento errores de inicio y terminacin
La prueba es un proceso de ejecucin de un programa con la intencin de descubrir un error.

Un buen caso de prueba es aquel que tiene una alta probabilidad de mostrar un error no
descubierto hasta entonces.

Una prueba tiene xito si descubre un error no detectado hasta entonces

Cobertura valores representativos de conjuntos de datos fronteras, valores o combinaciones

de valores conflictivos capacidad de proceso Tcnicas de caja negra Gracias por su atencin.

Las pruebas de caja blanca (tambin conocidas como pruebas de caja de cristal o pruebas
estructurales) se centran en los detalles procedimentales del software, por lo que su diseo
est fuertemente ligado al cdigo fuente. El testeador escoge distintos valores de entrada para
examinar cada uno de los posibles flujos de ejecucin del programa y cerciorarse de que se
devuelven los valores de salida adecuados.

En teora de sistemas y fsica, se denomina Caja Negra a aquel elemento que es estudiado
desde el punto de vista de las entradas que recibe y las salidas o respuestas que produce, sin
tener en cuenta su funcionamiento interno. En otras palabras, de una caja negra nos interesar
su forma de interactuar con el medio que le rodea (en ocasiones, otros elementos que tambin
podran ser cajas negras) entendiendo qu es lo que hace, pero sin dar importancia a cmo
lo hace. Por tanto, de una caja negra deben estar muy bien definidas sus entradas y salidas,
es decir, su interfaz; en cambio, no se precisa definir ni conocer los detalles internos de su
funcionamiento.

Particin Equivalente
La particin equivalente es un mtodo 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.. Un caso
de prueba ideal descubre de forma inmediata una clase de errores, que de otro modo
requeriran la ejecucin de muchos casos antes de detectar el error genrico.

La particin equivalente se dirige a la definicin de casos de prueba que descubran clases de

errores, reduciendo as el nmero de casos de pruebaque hay que desarrollar.

El diseo de casos de preba para la particin equivalente se basa en una evaluacin de las
clases de equivalencia para una condicin de entrada. Una clase de equivalencia representa
un conjunto de estados vlidos o invlidos para condiciones de de entrada.

1. Si una condicin de entrada especifica un rango, se define una clase de equivalencia vlida
y dos invlidas
2. Si una condicin de entrada requiere un valor especfico, se define una clase de equivalencia
vlida y dos invlidas.
3. Si una condicin de entrada especifica un miembro de un conjunto, se define una clase de
equivalencia vlida y una invlida.
4. Si una condicin de entrada es lgica, se define una clase vlida y una invlida.

Como ejemplo, consideremos los datos contenidos en una aplicacin de automatizacin

bancaria. Este software acepta datos en la siguiente forma:
Cdigo de rea: En blanco un nmero de 3 dgitos
Prefijo: Nmero de 3 dgitos que no comience por 0 1
Sufijo: Nmero de 4 dgitos
Contrasea: Vvalor alfanumrico de 6 dgitos
Ordenes: "Comprobar", "Depositar","Pagar factura", etc.

Las condiciones de entrada relacionadas con cada elemento de la aplicacin bancaria se

pueden especificar como:
Cdigo de rea: Condicin de entrada lgica - el cdigo de rea puede estar o no presente
Condicin de entrada rango - valores definidos entre 200 y 999
Prefijo: Condicin de entrada rango - valor especificado > 200
Sufijo: Condicin de entrada valor- longitud de 4 dgitos
Contrasea: Condicin de entrada lgica - la palabra clave puede estar o no presente
Condicin de entrada valor - cadena de seis caracteres
Orden: Condicin de entrada conjunto, contenida en las rdenes listadas anteriormente.

Los casos de prueba se seleccionan de manera que se ejercite el mayor nmero de atributos
de cada clase de equivalencia a la vez.

Anlisis de valores lmite (AVL)

Esta tcnica complementa a la de particin equivalente. En lugar de seleccionar cualquier

elemento de una clase de equivalencia, el AVL lleva a la eleccin de casos de prueba "en los
bordes" de la clase. En lugar de centrarse solamente en las condiciones de entrada, el AVL
deriva casos de prueba tambin para el campo de salida.
1. Si una condicin de entrada especifica un rango delimitado por los valores a y b, se deben
disear casos de prueba para los valores a y b y para valores justo por debajo y justo por
encima de a y b, respectivamente.

2. Si una condicin de entrada especifica un nmero de valores, se deben desarrollar casos

de prueba que ejerciten los valores mximo y mnimo. Tambin se deben probar los valores
justo por debajo del mximo y del mnimo.

3. Aplicar las directrices 1 y 2 a las condiciones de salida. Por ej. supongamos que se requiere
una tabla como salida deun programa, entonces se deben disear casos de prueba que creen
un informe de salida que produzca el mximo ( y el mnimo) nmero permitido de entradas en
la tabla.
4. Si las estructuras de datos internas tienen lmites preestablecidos ( p. Ej. Un arreglo de 100
entradas) hay que asegurarse de disear un caso de prueba que ejercite la estructura de datos
en sus lmites.

ESTRATEGIAS DE APLICACIN DE PRUEBAS DEL SOFTWARE

Una estrategia de prueba del software integra las tcnicas de diseo de casos de prueba en
una serie de pasos bien planificados que dan como resultado una correcta construccin del
software. Y lo que es ms importante, una estrategia de prueba del software proporciona un
mapa a seguir para el responsable del desarrollo del software, a la organizacin de control de
calidad y al cliente: un mapa que describe los pasos que hay que llevar a cabo como parte de
la prueba, cundo se deben planificar y realizar esos pasos, y cunto esfuerzo, tiempo y
recursos se van a requerir. Por tanto, cualquier estrategia de prueba debe incorporar la
planificacin de la prueba, el diseo de casos de prueba, la ejecucin de las pruebas y la
agrupacin y evaluacin de los datos resultantes.

Una estrategia de prueba del software debe ser suficientemente flexible para promover la
creatividad y la adaptabilidad necesarias para adecuar la prueba a todos los grandes sistemas
basados en software. Al mismo tiempo, la estrategia debe ser suficientemente rgida para
promover un seguimiento razonable de la planificacin y la gestin a medida que progresa el
proyecto. Shooman trata estos puntos:

En muchos aspectos, la prueba es un proceso individualista y el nmero de tipos diferentes de

pruebas vara tanto como los diferentes enfoques de desarrollo. Durante muchos aos, nuestra
nica defensa contra los errores de programacin era un cuidadoso diseo y la propia
inteligencia del programador. Ahora nos encontramos en una era en la que las tcnicas
modernas de diseo (y las revisiones tcnicas formales) nos ayudan a reducir el nmero de
errores iniciales que se encuentran en el cdigo de forma inherente. De forma similar, los
diferentes mtodos de prueba estn empezando a agruparse en varias filosofas y enfoques
diferentes.

PRUEBA DE UNIDAD

La prueba de unidad centra el proceso de verificacin en la menor unidad del diseo del
software: el mdulo. Usando la descripcin del diseo procedimental como gua, se prueban
los caminos de control importantes, con el fin de descubrir errores dentro del lmite del mdulo.
La complejidad relativa de las pruebas y de los errores descubiertos est limitada por el alcance
estricto establecido por la prueba de unidad.

Consideraciones sobre la prueba de unidad

Las pruebas que se dan como parte de la prueba de unidad estn esquemticamente
ilustradas en la Figura 10.4. Se prueba la interfaz del mdulo para asegurar que la informacin
fluye de forma adecuada hacia y desde la unidad de programa que est siendo probada. Se
examinan las estructuras de datos locales para asegurar que los datos que se mantienen
temporalmente conservan su integridad durante todos los pasos de ejecucin del algoritmo.
Se prueban las condiciones lmite para asegurar que el mdulo funciona correctamente en los
lmites establecidos como restricciones de procesamiento. Se ejercitan todos los caminos
independientes (caminos bsicos) de la estructura de control con el fin de asegurar que todas
las sentencias del mdulo se ejecutan por lo menos una vez. Y, finalmente, se prueban todos
los caminos de manejo de errores.

Antes de iniciar cualquier otra prueba es preciso probar el flujo de datos de la interfaz del
mdulo. Si los datos no entran correctamente, todas las dems pruebas no tienen sentido.
Myers, en su libro sobre prueba del software, propone una lista de comprobaciones para la
prueba de interfaces:

1. Es igual el nmero de parmetros de entrada al nmero de argumentos?

2. Coinciden los atributos de los parmetros y los argumentos?
3. Coinciden los sistemas de unidades de los parmetros y de los argumentos?
4. Es igual el nmero de argumentos transmitidos a los mdulos de llamada que
el nmero de parmetros?
5. Son iguales los atributos de los argumentos transmitidos a los mdulos de
llamada y los atributos de los parmetros?
6. Son iguales los sistemas de unidades de los argumentos transmitidos a los
mdulos de llamada y de los parmetros?
7. Son correctos el nmero de los atributos y el orden de los argumentos de las
funciones incorporadas?
8. Existen referencias a parmetros que no estn asociados con el punto de
entrada actual?
9. Entran slo argumentos alterados?
10. Son consistentes las definiciones de variables globales entre los mdulos?
11. Se pasan las restricciones como argumentos?

Cuando un mdulo lleve a cabo E/S externa, se deben llevar a cabo pruebas de interfaz
adicionales. Nuevamente, de Myers:
1. Son correctos los atributos de los archivos?
2. Son correctas las sentencias ABRIR/CERRAR?
3. Coinciden las especificaciones de formato con las sentencias de E/S?
4. Coincide el tamao del buffer con el tamao del registro?
5. Se abren los archivos antes de usarlos?
6. Se tienen en cuenta las condiciones de fin-de-archivo?
 7. Se manejan los errores de E/S?
8. Hay algn error textual en la informacin de salida?
Las estructuras de datos locales de cada mdulo son una fuente potencial de errores. Se deben
disear casos de prueba para descubrir errores de las siguientes categoras:
1. Tipificacin impropia o inconsistente.
2. Inicializacin o valores implcitos errneos.
3. Nombres de variables incorrectos (mal escritos o truncados).
4. Tipos de datos inconsistentes.
5. Excepciones de desbordamiento por arriba o por abajo, o de
direccionamiento.

Adems de las estructuras de datos locales, durante la prueba de unidad se debe comprobar
(en la medida de lo posible) el impacto de los datos globales sobre el mdulo.

Durante la prueba de unidad, la comprobacin selectiva de los caminos de ejecucin es una

tarea esencial. Se deben disear casos de prueba para detectar errores debidos a clculos
incorrectos, comparaciones incorrectas o flujos de control inapropiados. Las pruebas del
camino bsico y de bucles son tcnicas muy efectivas para descubrir una gran cantidad de
errores en los caminos.

Entre los errores ms comunes en los clculos estn: (1) precedencia aritmtica incorrecta o
mal interpretada; (2) operaciones de modo mezcladas; (3) inicializaciones incorrectas; (4) falta
de precisin; (5) incorrecta representacin simblica de una expresin. Las comparaciones y
el flujo de control estn fuertemente emparejadas (p. ej.: el flujo de control cambia
frecuentemente tras una comparacin).

Los casos de prueba deben descubrir errores como: (1) comparaciones ente tipos de datos
distintos; (2) operadores lgicos o de precedencia incorrectos; (3) igualdad esperada cuando
los errores de precisin la hacen poco probable; (4) variables o comparaciones incorrectas; (5)
terminacin de bucles inapropiada o inexistente; (6) fallo de salida cuando se encuentra una
iteracin divergente y (7) bucles que manejan variables modificadas de forma inapropiada.

Un buen diseo exige que las condiciones de error sean previstas de antemano y que se
dispongan unos caminos de manejo de errores que redirijan o terminen de una forma limpia el
proceso cuando se d un error. Yourdon llama a este
enfoque antipurgado. Desgraciadamente, existe una tendencia a incorporar la manipulacin
de errores en el software y as no probarlo nunca. Como ejemplo, sirve una historia real:

Mediante un contrato se desarroll un importante sistema de diseo interactivo. En un mdulo

de proceso de transacciones un bromista puso el siguiente mensaje de manipulacin de error
que apareca tras una serie de pruebas condicionales que invocaban varias ramificaciones del
flujo de control: ERROR! NO HAY FORMA DE QUE UD. LLEGUE HASTA AQU. Este
mensaje de error fue descubierto por un cliente durante la fase de puesta a punto!

Entre los errores potenciales que se deben comprobar cuando se evala la manipulacin de
errores estn:
1. Descripcin ininteligible del error.
2. El error sealado no se corresponde con el error encontrado
3. La condicin de error hace que intervenga el sistema antes que el mecanismo
 de manejo de errores
4. El proceso de la condicin excepcional es incorrecto
5. La descripcin del error no proporciona suficiente informacin para ayudar en
la localizacin de la causa del error.

La prueba de lmites es la ltima (y probablemente, la ms importante) tarea del paso de la

prueba de unidad. El software falla frecuentemente en sus condiciones lmite. Es decir, con
frecuencia aparece un error cuando se procesa el elemento n-simo de un array n-dimensional,
cuando se hace la i-sima repeticin de un bucle de i pasos o cuando se encuentran los valores
mximo o mnimo permitidos. Los casos de prueba que ejerciten las estructuras de datos, el
flujo de control y los valores de los datos por debajo, en y por encima de los mximos y los
mnimos son muy apropiados para descubrir estos errores.

PRUEBA DE INTEGRACIN

Un nefito del mundo del software podra, una vez que se les ha hecho la prueba de unidad a
todos los mdulos, cuestionar de forma aparentemente legtima lo siguiente: Si todos
funcionan bien por separado, por qu dudar de que funcionen todos juntos?. Por supuesto,
el problema es ponerlos juntos (interaccin). Los datos se pueden perder en una interfaz;
un mdulo puede tener un efecto adverso e inadvertido sobre otro; las subfunciones, cuando
se combinan, pueden no producir la funcin principal deseada; la imprecisin aceptada
individualmente puede crecer hasta niveles inaceptables; y las estructuras de datos globales
pueden presentar problemas; desgraciadamente, la lista sigue y sigue.

La prueba de integracin es una tcnica sistemtica para construir la estructura del programa
mientras que, al mismo tiempo, se llevan a cabo pruebas para detectar errores asociados con
la interaccin. El objetivo es coger los mdulos probados en unidad y construir una estructura
de programa que est de acuerdo con lo que dicta el diseo.

A menudo hay una tendencia a intentar una integracin no incremental; es decir, a construir el
programa mediante un enfoque de big bang. Se combinan todos los mdulos por anticipado.
Se prueba todo el programa en conjunto. Normalmente se llega al caos! Se encuentra un gran
conjunto de errores. La correccin se hace difcil, puesto que es complicado aislar las causas
al tener delante el programa entero en toda su extensin. Una vez que se corrigen esos errores
aparecen otros nuevos y el proceso contina en lo que parece ser un ciclo sin fin.

La integracin incremental es la anttesis del enfoque del big bang. El programa se

construye y se prueba en pequeos segmentos en los que los errores son ms fciles de aislar
y de corregir, es ms probable que se puedan probar completamente las interfaces y se puede
aplicar un enfoque de prueba sistemtica. A continuacin se tratan varias estrategias de
integracin incremental diferentes.

Integracin ascendente

La prueba de la integracin ascendente, como su nombre indica, empieza la construccin y la

prueba con los mdulos atmicos (es decir, mdulos de los niveles ms bajos de la estructura
del programa). Dado que los mdulos se integran de abajo hacia arriba, el proceso requerido
de los mdulos subordinados a un nivel dado siempre estn disponibles y se elimina la
necesidad de resguardos.

Se puede implementar una estrategia de integracin ascendente mediante los siguientes

pasos:

1. Se combinan los mdulos de bajo nivel en grupos (a veces

denominados construcciones) que realicen una subfuncin especfica del
software.

2. Se escribe un controlador (un programa de control de la prueba) para coordinar

la entrada y la salida de los casos de prueba.

3. Se prueba el grupo.

4. Se eliminan los controladores y se combinan los grupos movindose hacia

arriba por la estructura del programa.

La integracin sigue el esquema ilustrado en la Figura 8. Se combinan los mdulos para formar
los grupos 1, 2 y 3. Cada uno de los grupos se somete a prueba mediante un controlador
(mostrado como un bloque punteado). Los mdulos de los grupos 1 y 2 son subordinados de
Ma. Los controladores D1 y D2 se eliminan y los grupos interaccionan directamente con Ma. De
forma similar, se elimina el controlador D3 del grupo 3 antes de la integracin con el mdulo
Mb Tanto Ma como Mb se integrarn finalmente con el mdulo Mc y as sucesivamente. En la
Figura 9 se muestran diferentes categoras de controladores.

A medida que la integracin progresa hacia arriba, disminuye la necesidad de controladores

de prueba diferentes. De hecho, si los dos niveles superiores de la estructura del programa se
integran de forma descendente, se puede reducir sustancialmente el nmero de controladores
y se simplifica enormemente la integracin de grupos.

Integracin descendente

La integracin descendente es un planteamiento incremental a la construccin de la estructura

de programas. Se integran los mdulos movindose hacia abajo por la jerarqua de control,
comenzando por el mdulo de control principal (programa principal). Los mdulos
subordinados (de cualquier modo subordinados) al mdulo de control principal se van
incorporando en la estructura, bien de forma primero-en-profundidad o bien de forma primero-
en-anchura.

Como se muestra en la Figura 10.6, la integracin primero-en-profundidad integra todos los

mdulos de un camino de control principal de la estructura. La seleccin del camino principal
es, de alguna manera, arbitraria y depender de las caractersticas especficas de la aplicacin.
Por ejemplo, si se elige el camino a mano izquierda, se integrarn primero los mdulos M1,
M2 y M5.
A continuacin se integrar M8 o M6 (si es necesario para un funcionamiento adecuado
de M2). Acto seguido se construyen los caminos de control central y derecho. La
integracin primero-en-anchura incorpora todos los mdulos directamente subordinados a
cada nivel, movindose por la estructura de forma horizontal. Segn la figura, los primeros
mdulos que se integran son M2, M3 yM4. A continuacin sigue el siguiente nivel de control, M5,
M6, etc.

El proceso de integracin se realiza en una serie de cinco pasos:

1. Se usa el mdulo de control principal como controlador de la prueba,

disponiendo de resguardos para todos los mdulos directamente subordinados
al mdulo de control principal.

2. Dependiendo del enfoque de integracin elegido (es decir, primero-en-

profundidad o primero-en-anchura) se van sustituyendo los resguardos
subordinados uno a uno por los mdulos reales.

3. Se llevan a cabo pruebas cada vez que se integra un nuevo mdulo.

4. Tras terminar cada conjunto de pruebas, se reemplaza otro resguardo con el

mdulo real.

5. Se hace la prueba de regresin para asegurarse de que no se han introducido

errores nuevos.

El proceso contina desde el paso 2 hasta que se haya construido la estructura del programa
entero.

La estrategia de integracin descendente verifica los puntos de decisin o de control

principales al principio del proceso de prueba. En una estructura de programa bien fabricada,
la toma de decisiones se da en los niveles superiores de la jerarqua y, por tanto, se encuentran
antes. Si existen problemas generales de control, es esencial reconocerlos cuanto antes. Si se
selecciona la integracin primero-en-profundidad, se puede ir implementando y demostrando
las funciones completas del software. Por ejemplo, considere una estructura de transaccin
clsica en la que se requiere una compleja serie de entradas interactivas, obtenidas y validadas
por medio de un camino de entrada. Ese camino de entrada puede ser integrado en forma
descendente. As, se puede demostrar todo el proceso de entradas (para posteriores
operaciones de transaccin) antes de que se integren otros elementos de la estructura. La
demostracin anticipada de las posibilidades funcionales es un generador de confianza tanto
para el desarrollador como para el cliente.

La estrategia descendente parece relativamente fcil, pero en la prctica, pueden surgir

algunos problemas logsticos. El ms comn de estos problemas se da cuando se requiere un
proceso de los niveles ms bajos de la jerarqua para poder probar adecuadamente los niveles
superiores. Al principio de la prueba descendente, los mdulos de bajo nivel se reemplazan
por resguardos; por tanto, no pueden fluir datos significativos hacia arriba por la estructura del
programa. El responsable de la prueba tiene tres opciones: (1) retrasar muchas de las pruebas
hasta que los resguardos sean reemplazados por los mdulos reales; (2) desarrollar
resguardos que realicen funciones limitadas que simulen los mdulos reales; o (3) integrar el
software desde el fondo de la jerarqua hacia arriba. La Figura 10.7 ilustra varias clases de
resguardos tpicas, desde la ms simple (resguardo A) hasta la ms compleja (resguardo D).

El primer enfoque (retrasar pruebas hasta reemplazar los resguardos por los mdulos reales)
hace que perdamos cierto control sobre la correspondencia de ciertas pruebas especficas con
la incorporacin de determinados mdulos. Esto puede dificultar la determinacin de las
causas del error y tiende a violar la naturaleza altamente restrictiva del enfoque descendente.
El segundo enfoque es factible pero puede llevar a un significativo incremento del esfuerzo a
medida que los resguardos se hagan ms complejos. El tercer enfoque, denominado prueba
ascendente, se estudia a continuacin.

PRUEBA DE VALIDACIN

Tras la culminacin de la prueba de integracin, el software est completamente ensamblado

como un paquete; se han encontrado y corregido los errores de interfaz y puede comenzar una
serie final de pruebas del software: la prueba de validacin. La validacin puede definirse de
muchas formas, pero una simple (aunque vulgar) definicin es que la validacin se consigue
cuando el software funciona de acuerdo con las expectativas razonables del cliente. En este
punto, un desarrollador de software estricto podra protestar: Qu o quin es el rbitro de
las expectativas razonables?.

Las expectativas razonables estn definidas en la especificacin de requisitos del software

un documento que describe todos los atributos del software visibles para el usuario. La
especificacin contiene una seccin denominada Criterios de validacin. La informacin
contenida en esa seccin forma la base del enfoque a la prueba de validacin.

PRUEBA DEL SISTEMA

Al principio, pusimos nfasis en el hecho de que el software es slo un elemento de un sistema

mayor basado en computadora. Finalmente, el software es incorporado a otros elementos del
sistema (p. ej.: nuevo hardware, informacin) y realizan una serie de pruebas de integracin
del sistema y de validacin. Estas pruebas caen fuera del mbito del proceso de ingeniera del
software y no las realiza nicamente el desarrollador del software. Sin embargo, los pasos
dados durante el diseo del software y durante la prueba pueden mejorar enormemente la
probabilidad de xito en la integracin del software en el sistema.

Un problema tpico de la prueba del sistema es la delegacin de culpabilidad. Esto ocurre

cuando se descubre un error y cada uno de los creadores de cada elemento del sistema echa
la culpa del problema a los otros. En vez de verse envuelto en esta absurda situacin, el
ingeniero del software debe anticiparse a los posibles problemas de interaccin y: (1) disear
caminos de manejo de errores que prueben toda la informacin procedente de otros elementos
del sistema; (2) llevar a cabo una serie de pruebas que simulen la presencia de datos en mal
estado o de otros posibles errores en la interfaz del software; (3) registrar los resultados de las
pruebas como evidencia en el caso de que se le seale con el dedo; (4) participar en la
planificacin y el diseo de pruebas del sistema para asegurarse de que el software se prueba
de forma adecuada.
La prueba del sistema, realmente, est constituida por una serie de pruebas diferentes cuyo
propsito primordial es ejercitar profundamente el sistema basado en computadora. Aunque
cada prueba tiene un propsito diferente, todas trabajan para verificar que se han integrado
adecuadamente todos los elementos del sistema y que realizan las funciones apropiadas.

Prueba de recuperacin

Muchos sistemas basados en computadora deben recuperarse de los fallos y continuar el

proceso en un tiempo previamente especificado. En algunos casos, un sistema debe ser
tolerante con los fallos; es decir, los fallos del proceso no deben hacer que cese el
funcionamiento de todo el sistema.

En otros casos, se debe corregir un fallo del sistema en un determinado periodo de tiempo
para que no se produzca un serio dao econmico.

La prueba de recuperacin es una prueba del sistema que fuerza el fallo del software de
muchas formas y verifica que la recuperacin se lleva a cabo apropiadamente. Si la
recuperacin es automtica (llevada a cabo por el propio sistema) hay que evaluar la
correccin de la inicializacin, de los mecanismos de recuperacin del estado del sistema, de
la recuperacin de datos y del proceso rearranque. Si la recuperacin requiere la intervencin
humana, hay que evaluar los tiempos medios de reparacin para determinar si estn dentro
de unos lmites aceptables.

Prueba de seguridad

Cualquier sistema basado en computadora que maneje informacin sensible o lleve a cabo
acciones que puedan perjudicar (o beneficiar) impropiamente a las personas es un posible
objetivo para entradas al sistema impropias o ilegales. Este acceso al sistema incluye un
amplio rango de actividades: piratas informticos que intentan entrar en los sistemas por
deporte, empleados disgustados que intentan penetrar por venganza e individuos deshonestos
que intentan penetrar para obtener ganancias personales ilcitas.

La prueba de seguridad intenta verificar que los mecanismos de proteccin incorporados en el

sistema lo protegern, de hecho, de accesos impropios.

Durante la prueba de seguridad, el responsable de la prueba desempea el papel de un

individuo que desea entrar en el sistema. Todo vale! Debe intentar conseguir las claves de
acceso por cualquier medio, puede atacar al sistema con software a medida, diseado para
romper cualquier defensa que se haya construido, debe bloquear el sistema, negando as el
servicio a otras personas, debe producir a propsito errores del sistema, intentando acceder
durante la recuperacin o debe curiosear en los datos sin proteccin, intentando encontrar la
clave de acceso al sistema, etc.

Con tiempo y recursos suficientes, una buena prueba de seguridad terminar por acceder en
el sistema. El papel del diseador del sistema es hacer que el coste de la entrada ilegal sea
mayor que el valor de la informacin obtenida.
Prueba de resistencia

Las pruebas de resistencia estn diseadas para enfrentar a los programas con situaciones
anormales. En esencia, el sujeto que realiza la prueba de resistencia se pregunta: A qu
potencia puedo ponerlo a funcionar antes de que falle?

La prueba de resistencia ejecuta un sistema de forma que demande recursos en cantidad,

frecuencia o volmenes anormales. Por ejemplo: (1) disear pruebas especiales que generen
diez interrupciones por segundo, cuando las normales son una o dos; (2) incrementar las
frecuencias de datos de entrada en un orden de magnitud con el fin de comprobar cmo
responden las funciones de entrada; (3) ejecutar casos de prueba que requieran el mximo de
memoria o de otros recursos; (4) disear casos de prueba que puedan dar problemas en un
sistema operativo virtual o (5) disear casos de prueba que produzcan excesivas bsquedas
de datos residentes en disco. Esencialmente, el responsable de la prueba intenta romper el
programa.

Una variante de la prueba de resistencia es una tcnica denominada prueba

de sensibilidad. En algunas situaciones (la ms comn se da con algoritmos matemticos), un
rango de datos muy pequeo dentro de los lmites de una entrada vlida para un programa
puede producir un proceso exagerado e incluso errneo o una profunda degradacin del
rendimiento. Esta situacin es anloga a una singularidad en una funcin matemtica. La
prueba de sensibilidad intenta descubrir combinaciones de datos dentro de una clase de
entrada vlida que pueda producir inestabilidad o un proceso incorrecto.

Prueba de rendimiento

Para sistemas de tiempo real y sistemas empotrados, es inaceptable el software que

proporciona las funciones requeridas pero no se ajusta a los requisitos de rendimiento.
La prueba de rendimiento est diseada para probar el rendimiento del software en tiempo de
ejecucin dentro del contexto de un sistema integrado. La prueba de rendimiento se da durante
todos los pasos del proceso de la prueba. Incluso al nivel de unidad, se debe asegurar el
rendimiento de los mdulos individuales a medida que se llevan a cabo las pruebas de caja
blanca. Sin embargo, hasta que no estn completamente integrados todos los elementos del
sistema no se puede asegurar realmente el rendimiento del sistema.

Las pruebas de rendimiento, a menudo, van emparejadas con las pruebas de resistencia y,
frecuentemente, requieren instrumentacin tanto de software como de hardware. Es decir,
muchas veces es necesario medir la utilizacin de recursos (p. ej.: ciclos de procesador), de
un modo exacto. La instrumentacin externa puede monitorizar los intervalos de ejecucin, los
sucesos ocurridos (p. ej.: interrupciones) y muestras de los estados de la mquina en un
funcionamiento normal. Instrumentando un sistema, el encargado de la prueba puede
descubrir situaciones que lleven a degradaciones y posibles fallos del sistema.

EL ARTE DE LA DEPURACIN
La prueba del software es un proceso que puede planificarse y especificarse sistemticamente.
Se puede llevar a cabo el diseo de casos de prueba, se puede definir una estrategia y se
pueden evaluar los resultados en comparacin con las expectativas prescritas.

La depuracin ocurre como consecuencia de una prueba efectiva. Es decir, cuando un caso
de prueba descubre un error, la depuracin es el proceso que provoca la eliminacin del error.
Aunque la depuracin 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 indicacin sintomtica de un problema en el software. Es decir, la
manifestacin externa de un error, y la causa interna del error pueden no estar relacionados
de una forma obvia. El proceso mental, apenas comprendido, que conecta un sntoma con una
causa es la depuracin.

El proceso de depuracin

La depuracin no es una prueba, pero siempre ocurre como consecuencia de la prueba. Como
se muestra en la Figura 10.9, el proceso de depuracin comienza con la ejecucin de un caso
de prueba. Se evalan los resultados y aparece una falta de correspondencia entre los
esperados y los encontrados realmente. En muchos casos, los datos que no concuerdan son
un sntoma de una causa subyacente que todava permanece oculta. El proceso de depuracin
intenta hacer corresponder el sntoma con una causa, llevando as a la correccin del error.

El proceso de depuracin siempre tiene uno de los dos resultados siguientes: (1) se encuentra
la causa, se corrige y se elimina; o (2) no se encuentra la causa. En este ltimo caso, la persona
que realiza la depuracin debe sospechar la causa, disear un caso de prueba que ayude a
confirmar sus sospechas y el trabajo vuelve hacia atrs a la correccin del error de una forma
iterativa.

Por qu es tan difcil la depuracin? Todo parece indicar que la respuesta tiene ms que ver
con la psicologa humana que con la tecnologa del software. Sin embargo, varias
caractersticas de los errores nos dan algunas pistas:

1. El sntoma y la causa pueden ser geogrficamente remotos entre s. Es decir, el sntoma

puede aparecer en una parte del programa, mientras que la causa est localizada en
otra parte muy alejada. Las estructuras de programa fuertemente acopladas resaltan
esta situacin.
2. El sntoma puede desaparecer (temporalmente) al corregir otro error.
3. El sntoma puede realmente estar producido por algo que no es un error (p.ej.:
inexactitud en los redondeos).
4. El sntoma puede estar causado por un error humano que no sea fcilmente detectado.
5. El sntoma puede ser el resultado de problemas de temporizacin en vez de problemas
de proceso.
6. Puede ser difcil reproducir exactamente las condiciones de entrada (p.ej.: una
aplicacin de tiempo real en la que el orden de la entrada no est determinado).
7. El sntoma puede aparecer de forma intermitente. Esto es particularmente corriente en
sistemas empotrados que acoplan el hardware y el software de manera confusa.
8. El sntoma puede ser debido a causas que se distribuyen por una serie de tareas
ejecutndose en diferentes procesadores.
Durante la depuracin encontramos errores que van desde lo ligeramente inesperado (p. ej.:
un formato de salida incorrecto) hasta lo catastrfico (p.ej.: el sistema falla, producindose
serios daos econmicos o fsicos). A medida que las consecuencias de un error aumentan,
crece la presin por encontrar su causa. A menudo la presin fuerza a un ingeniero de software
a corregir un error introduciendo dos ms.

Las pruebas de software (en ingls software testing) son las investigaciones empricas y
tcnicas cuyo objetivo es proporcionar informacin objetiva e independiente sobre la calidad
del producto a la parte interesada o stakeholder. Es una actividad ms en el proceso de control
de calidad.

Las pruebas son bsicamente un conjunto de actividades dentro del desarrollo de software.
Dependiendo del tipo de pruebas, estas actividades podrn ser implementadas en cualquier
momento de dicho proceso de desarrollo. Existen distintos modelos de desarrollo de software,
as como modelos de pruebas. A cada uno corresponde un nivel distinto de involucramiento
en las actividades de desarrollo.