AIS Tema3 PruebasSoftware Materialapoyo

Ampliacin de Ingeniera del Software
Grado en Ingeniera Informtica

Material de Apoyo Terico

Pgina N
Una de las caractersticas tpicas del desarrollo de software basado en el ciclo de vida es
la realizacin de controles peridicos, normalmente coincidiendo con los hitos del
proyecto o la terminacin de documentos.
Estos controles pretenden una evaluacin de la calidad de los productos generados
(especificacin de requisitos, documentos de diseo, etc.) para poder detectar posibles
defectos cuanto antes.
Sin embargo, todo sistema o aplicacin, independientemente de estas revisiones, debe
ser probado mediante su ejecucin controlada antes de ser entregado al cliente.
Estas ejecuciones o ensayos de funcionamiento, posteriores a la terminacin del cdigo
del software, se denominan habitualmente pruebas.

Pgina N

Pgina N

Pgina N
La prueba del software es un elemento de un tema ms amplio que, a menudo, es conocido como
verificacin y validacin (V&V). V&V es un conjunto de procedimientos, actividades, tcnicas y
herramientas que se utilizan, paralelamente al desarrollo de software, para asegurar que un
producto software resuelve el problema inicialmente planteado.
Principio: Actuar sobre los productos intermedios que se generan durante el desarrollo para
detectar y corregir cuanto antes sus defectos y las desviaciones respecto al objetivo fijado
La verificacin se refiere al conjunto de actividades que aseguran que el software implementa
correctamente una funcin especfica. Tcnica ms utilizada: Revisiones SW
La validacin se refiere a un conjunto diferente de actividades que aseguran que el software
construido se ajusta a los requisitos del cliente. Tcnica ms utilizada: Pruebas SW
La definicin de V&V comprende muchas de las actividades a las que se refiere la garanta de
calidad del software (SQA o Software Quality Assurance). En particular, la verificacin y la
validacin abarcan una amplia lista de actividades SQA que incluyen: revisiones tcnicas formales,
auditoras de calidad y de configuracin, monitorizacin de rendimientos, simulacin, estudios de
factibilidad, revisin de la documentacin, revisin de la base de datos, anlisis algortmico,
pruebas de desarrollo pruebas de validacin y pruebas de instalacin.
Las pruebas son una familia de tcnicas de V&V, que incluye otras muchas actividades.

Pgina N
Los objetivos concretos de la V&V son:
Detectar y corregir los defectos tan pronto como sea posible en el ciclo de vida del software.
Disminuir los riesgos, las desviaciones sobre los presupuestos y sobre el calendario o programa
de tiempos del proyecto.
Mejorar la calidad y fiabilidad del software.
Mejorar la visibilidad de la gestin del proceso de desarrollo.
Valorar rpidamente los cambios propuestos y sus consecuencias.
La visin del desarrollo de software como un conjunto de fases con posibles realimentaciones
facilita la V&V. De hecho, al inicio del proyecto es necesario hacer un Plan de V&V del SW (IEEE
1012), cuyas actividades se realizan de forma iterativa durante el desarrollo.
La figura muestra un ejemplo del plan de V&V de acuerdo al estndar correspondiente de la IEEE,
el IEEE 1012-2004 (IEEE Standard for Software Verification and Validation).

Pgina N
En general, las Pruebas (Testing) se realizan para evaluar la calidad de un producto, y/o mejorarlo, mediante la
identificacin de defectos y problemas. Conviene que nos detengamos un momento en algunos de los
conceptos recogidos en la anterior definicin de qu son las pruebas de software:
Comprobacin Dinmica
Las pruebas siempre implican la ejecucin del programa con unas ciertas entradas.
Los valores de entrada no siempre son suficientes para determinar una prueba porque un sistema
complejo podra reaccionar de distinta manera ante una misma entrada dependiendo del estado del
sistema (sistema no determinista).
Las tcnicas de verificacin esttica (sin ejecucin) se consideran tcnicas de aseguramiento de calidad y
no pruebas. Por ejemplo, las revisiones formales o informales del cdigo.
Conjunto Finito de Casos de prueba
Incluso en los programas sencillos, son posibles tericamente tantos casos de prueba que su realizacin
de forma exhaustiva podra llevar meses o aos.
En la prctica se considera que el conjunto completo de posibles casos de prueba es infinito.
Hacer pruebas implica un equilibrio entre recursos y tiempo limitados y unos requisitos de prueba
virtualmente ilimitados.
Seleccionados entre los infinitos
Es necesario seleccionar un subconjunto finito de casos de prueba.
La gran cantidad de tcnicas de prueba propuestas difieren fundamentalmente en la manera de
seleccionar el conjunto de casos de prueba.
Diferentes criterios de seleccin pueden implicar grados muy distintos de efectividad.
Identificar el criterio de seleccin ms adecuado para cada situacin es muy complejo. En la prctica se
aplican:
Anlisis de Riesgos
Experiencia del ingeniero de pruebas
Comportamiento Esperado
Para que el esfuerzo de hacer pruebas sea til debe ser posible, aunque no siempre fcil, decidir si los
resultados observados al ejecutar el programa son aceptables o no.
El comportamiento esperado puede ser comparado con
Las expectativas de los usuarios (pruebas de aceptacin)
Una especificacin (pruebas de verificacin)
Comportamiento anticipado desde requisitos implcitos.

Pgina N
Prueba (test): Una actividad en la cual un sistema o uno de sus componentes se ejecuta en
circunstancias previamente especificadas, los resultados se observan y registran y se realiza una
evaluacin de algn aspecto.
Para Myers, probar (o la prueba) es el proceso de ejecutar un programa con el fin de
encontrar errores.
El nombre prueba, adems de la actividad de probar, se puede usar para designar un
conjunto de casos y procedimientos de prueba.

Pgina N
Caso de prueba (test case): Un conjunto de entradas, condiciones de ejecucin, y resultados
esperados desarrollados para un objetivo particular como, por ejemplo, ejercitar un camino
concreto de un programa o verificar el cumplimiento de un determinado requisito.
Tambin se puede referir a la documentacin donde se describen las entradas, condiciones y
salidas de un caso de prueba.


Pgina N
Es habitual ver como algunas personas utilizan de manera indistinta los trminos Defecto, Fallo y
Error. Sin embargo, cada uno de ellos tiene un significado diferente:
Defecto: un defecto se encuentra en un artefacto y puede definirse como una diferencia entre
la versin correcta del artefacto y una versin incorrecta. Coincide con la definicin de
diccionario, "imperfeccin.
Fallo: en terminologa IEEE, un fallo es la discrepancia visible que se produce al ejecutar un
programa con un defecto, el cual es incapaz de funcionar correctamente (no sigue su curso
normal). Podramos referirnos a un fallo como el sntoma o efecto del defecto.
Error: es una equivocacin cometida por el desarrollador, por tanto es humano. Algunos
ejemplos de errores son un error tipogrfico o la malinterpretacin de un requisito. El
estndar 829 de la IEEE se refiere a un error como "una idea falsa o equivocada". Por lo tanto
un programa no puede tener o estar en un error, ya que los programas no tienen ideas; las
ideas las tienen las personas. Si recurrimos a la literatura encontraremos otras acepciones:
La diferencia entre un valor calculado, observado o medido y el valor verdadero,
especificado o tericamente correcto. Por ejemplo, una diferencia de dos centmetros
entre el valor calculado y el real.
Un defecto. Por ejemplo, una instruccin incorrecta en un programa.
Un resultado incorrecto. Por ejemplo, un programa ofrece como resultado de la raz
cuadrada de 36 el valor 7 en vez de 6.
Una accin humana que conduce a un resultado incorrecto (una metedura de pata:
mistake). Por ejemplo, que el operador o el programador pulse una tecla equivocada.
Nosotros desecharemos las acepciones 2 y 3, ya que coinciden con las definiciones de defecto
y fallo, para evitar equvocos. De forma coloquial podramos decir que un error es algo
abstracto (en tanto en cuanto es una idea), un defecto es la concretizacin de esa idea y un
fallo es el resultado de esa concretizacin. Es decir, una idea equivocada se implementa en un
defecto que provoca un fallo.


Pgina N
Esta figura ilustra mejor la idea: un error del programador introduce un defecto y este defecto
produce un fallo.

Pgina N

Pgina N
Las pruebas del software son un elemento crtico para la garanta de calidad del software y
representa una revisin final de las especificaciones, del diseo y de la codificacin.
La creciente percepcin del software como un elemento del sistema y la importancia de los
costes asociados a un fallo del propio sistema, estn motivando la creacin de pruebas
minuciosas y bien planificadas.
No es raro que una organizacin de desarrollo de software emplee entre el 30 y el 40 por ciento
del esfuerzo total de un proyecto en las pruebas.
En casos extremos, las pruebas del software para actividades crticas (por ejemplo, control de
trfico areo, control de reactores nucleares) pueden costar de tres a cinco veces ms que el
resto de actividades juntas.

Pgina N
Las pruebas presentan una interesante anomala para el ingeniero del software. Durante las fases
anteriores de definicin y de desarrollo, el ingeniero intenta construir el software partiendo de un
concepto abstracto y llegando a una implementacin tangible.
A continuacin, llegan las pruebas donde el ingeniero crea una serie de casos de prueba que
intentan demoler el software construido. De hecho, las pruebas son una de las actividades de la
ingeniera del software que se puede ver (por lo menos, psicolgicamente) como eminentemente
destructiva en lugar de constructiva.
As, dado que los ingenieros del software son, por naturaleza, personas constructivas, las pruebas
requieren que se descarten ideas preconcebidas sobre la correccin del software que se acaba
de desarrollar y se supere cualquier conflicto de intereses que aparezcan a medida que se
descubran errores.

Pgina N
Existe un mito que dice que [BEIZER, 1990]:
Si furamos realmente buenos programando, no habra errores que buscar. Si tan solo furamos realmente
capaces de concentrarnos, si todo el mundo empleara tcnicas de codificacin estructuradas, el diseo
descendente, si los programas se escribieran en un lenguaje apropiado, si tuviramos siempre la solucin
ms adecuada, entonces no habra errores. Segn el mito, existen errores porque somos malos en lo que
hacemos, y si somos malos en lo que hacemos, deberamos sentirnos culpables por ello. Por tanto, las
pruebas son un reconocimiento de nuestros errores, lo que implica una buena dosis de culpabilidad. An
ms, lo tediosas que son las pruebas son un justo castigo a nuestros errores. Castigados por qu? Por ser
humanos? Culpables por qu? Por no conseguir una perfeccin inhumana? Por no poder distinguir entre
lo que otro programador piensa y lo que dice? Por no tener telepata? Por no poder resolver los
problemas de comunicacin humana que han estado presentes, durante cuarenta siglos?
Hay que recordar, ante todo, que el objetivo de las pruebas es la deteccin de defectos en el software y que
descubrir un defecto debera considerarse el xito de una prueba. Se trata de una actividad a posteriori, de
deteccin, y no de prevencin, de problemas en el software. El problema es que, tradicionalmente, existe el
mito de la ausencia de errores en el buen profesional: si furamos realmente capaces y empleramos las
tcnicas ms sofisticadas, no existiran los defectos en el software. Por lo tanto, un defecto implica que
somos malos profesionales y que debemos sentirnos culpables. Si una prueba revela uno de estos
problemas, implica la constatacin de un fracaso del desarrollador.
Sin embargo, la realidad es muy distinta. Todo el mundo comete errores (errare humanum est) y es de
sabios rectificar. Las pruebas permiten la rectificacin en el software. La mayora de los estudios revelan que
los mejores programadores incluyen una cierta media de defectos por cada 1.000 lneas de cdigo. Los
defectos no son siempre el resultado de la negligencia, sino que en su aparicin influyen mltiples factores
(por ejemplo, la mala comunicacin entre los miembros del equipo que da lugar a malentendidos en los
requisitos). Por todo ello, el descubrimiento de un defecto significa un xito para la mejora de la calidad al
igual que, a pesar de lo incmodo que resulte, la deteccin de un problema de salud en un anlisis mdico
se considera un xito para lograr la curacin del paciente.
Resumiendo: Deben infundir culpabilidad la pruebas? Son realmente destructivas? La respuesta a estas
preguntas es: no!
Sin embargo, los objetivos de las pruebas son algo diferentes de lo que podramos esperar


Pgina N
Existen prejuicios (como, por ejemplo, la creencia de que todo defecto es consecuencia de una
negligencia en el trabajo desarrollado) que pueden perjudicar a las pruebas. Todos estos factores
obligan a estudiar cul es la mejor actitud o filosofa a seguir a la hora de abordar el desarrollo de
pruebas.
(VER DIAPOSITIVA)
Los objetivos anteriores suponen un cambio dramtico de punto de vista. Nos quitan la idea que
normalmente tenemos de que una prueba tiene xito si no descubre errores.
Nuestro objetivo es disear pruebas que sistemticamente saquen a la luz diferentes clases de
errores, hacindolo con la menor cantidad de tiempo y de esfuerzo. Si la prueba se lleva a cabo
con xito (de acuerdo con el objetivo anteriormente establecido), descubrir errores en el
software. Por tanto, debemos disear pruebas que tengan la mayor probabilidad de encontrar el
mayor nmero de errores.
Como ventaja adicional, la prueba demuestra hasta qu punto el software parece funcionar de
acuerdo a los requisitos funcionales y no funcionales. Adems, los datos que se van recogiendo a
medida que se lleva a cabo la prueba proporcionan una buena indicacin de fiabilidad y, de
alguna manera, un indicador de la calidad del software como un todo.
Pero no debemos olvidar que la prueba no puede asegurar la ausencia de defectos; slo puede
demostrar que existen defectos en el software.

Pgina N
Las especiales caractersticas del software (ausencia de existencia fsica, ausencia de leyes que
rijan su comportamiento, gran complejidad, etc.) hacen an ms difcil la tarea de probarlo en
relacin a otros productos industriales. Adems, no debemos olvidar los prejuicios que hemos
comentado respecto a las pruebas. Por todo ello, antes de la aplicacin de mtodos para el diseo
de casos de prueba efectivos, un ingeniero software deber entender los principios bsicos que
guan las pruebas del software.
Davis [DAV95] y Myers [Myers, 1979] sugieren los siguientes:
A todas las pruebas se les debera poder hacer un seguimiento hasta los requisitos del cliente.
Como hemos visto, el objetivo de las pruebas del software es descubrir errores. Se entiende
que los defectos ms graves (desde el punto de vista del cliente) son aquellos que impiden al
programa cumplir sus requisitos.
Las pruebas deberan planificarse mucho antes de que empiecen. La planificacin de las
pruebas pueden empezar tan pronto como est completo el modelo de requisitos. La
definicin detallada de los casos de prueba puede empezar tan pronto como el modelo de
diseo se ha consolidado. Por tanto, se pueden planificar y disear todas las pruebas antes de
abordar las tareas de construccin.
El principio de Pareto es aplicable a la prueba del software. Dicho de manera sencilla, el
principio de Pareto implica que el 80% de todos los errores descubiertos durante las pruebas
se localizan en un 20% de todos los mdulos/componentes del sistema. El problema, por
supuesto, es aislar estos mdulos sospechosos y probarlos concienzudamente.


Pgina N
No son posibles las pruebas exhaustivas. El nmero de permutaciones de caminos para incluso un programa de tamao
moderado es excepcionalmente grande. Por este motivo, es imposible ejecutar todas las combinaciones de caminos
durante las pruebas. Es posible, sin embargo, cubrir adecuadamente la lgica del programa y asegurarse de que se han
aplicado todas las condiciones en el diseo a nivel de componente.
Las pruebas deberan empezar por lo pequeo y progresar hacia lo grande. Las primeras pruebas planeadas y
ejecutadas se centran generalmente en mdulos individuales del programa. A medida que avanzan las pruebas, desplazan
su punto de mira en un intento de encontrar errores en grupos integrados de mdulos y finalmente en el sistema entero.
Para ser ms eficaces, las pruebas deberan ser realizadas por un equipo independiente. Por mas eficaces queremos
referirnos a pruebas con la ms alta probabilidad de encontrar errores (el objetivo principal de las pruebas). Por las
razones que se expusieron anteriormente, el ingeniero del software que cre el sistema no es el ms adecuado para llevar
a cabo las pruebas para el software. El programador debe evitar probar sus propios programas porque desea (consciente
o inconscientemente) demostrar que funcionan sin problemas. Esta actitud inadecuada lleva a realizar pruebas menos
rigurosas de lo deseable. Adems, es normal que las situaciones que ha olvidado considerar al crear el programa (por
ejemplo, no pensar en cmo tratar un fichero de entrada vaco) queden, de nuevo, olvidadas al escribir casos de prueba.
Lo ideal sera que probara el software el peor enemigo de quien lo ha construido, ya que as se asegurara una bsqueda
implacable de cualquier error cometido.
Para definir buenos casos de prueba:
Se deben evitar los casos desechables, es decir, los no documentados ni diseados con cuidado (por ejemplo, los que
se teclean sobre la marcha), ya que suele ser necesario probar una y otra vez el software hasta que queda libre de
defectos. No documentar o guardar los casos significa repetir constantemente el diseo de casos de prueba.
Cada caso de prueba debe definir el resultado de salida esperado. Este resultado esperado es el que se compara con
el realmente obtenido de la ejecucin en la prueba. Las discrepancias entre ambos (errores) se consideran sntomas
de un posible defecto en el software.
Al generar casos de prueba, se deben incluir tanto datos de entrada vlidos y esperados como no vlidos e
inesperados. Es frecuente observar una tendencia a centrarse en lo esperado y lo vlido.
Debemos evitar ser redundantes. El tiempo y los recursos para las pruebas son limitados. No hay motivo para realizar
una prueba que tiene el mismo propsito que otra. Todas las pruebas deberan tener un propsito diferente (incluso
si es sutilmente diferente). Una buena prueba debera ser la mejor de la cosecha. En un momento dado, varios
miembros de un equipo de pruebas pueden proponer varios casos de prueba que tengan un propsito similar, pero
las limitaciones de tiempo y recursos que pueden abogar por la ejecucin de solo un subconjunto de estas pruebas.
En tales casos, se debera emplear la prueba que tenga la ms alta probabilidad de descubrir una clase entera de
errores.
Una buena prueba o debera ser ni demasiado sencilla ni demasiado compleja. Aunque es posible, a veces, combinar
una serie de pruebas en un caso de pruebas, los posibles efectos secundarios de este enfoque pueden enmascarar
errores, en general, cada prueba debera realizarse separadamente.


Pgina N
En circunstancias ideales, un ingeniero disea un programa, un sistema o un producto con la facilidad de la prueba en mente. Esto
permite a los encargados de las pruebas disear casos de pruebas ms fcilmente. Pero, Qu es la facilidad de la prueba?
La facilidad de la prueba del software es simplemente la facilidad con la que se puede probar un programa. Ya que la prueba es
esencialmente difcil, merece la pena saber qu se puede hacer para hacerla ms sencillo. A veces los programadores estn dispuestos a
hacer cosas que faciliten el proceso de prueba y una lista de comprobacin de posibles puntos de diseo, caractersticas y dems, puede
ser til a la hora de negociar con ellos. Existen, de hecho, mtricas que podran usarse para medir ciertos aspectos de la facilidad de
prueba. La siguiente lista de comprobacin proporciona un conjunto de caractersticas que llevan a un software fcil de probar.
Operatividad. Cuanto mejor funcione ms eficientemente se puede probar.
El sistema tiene pocos errores (los errores aaden sobre carga de anlisis y de generacin de informe al proceso de prueba).
Ningn error bloquea la ejecucin de las pruebas.
Observabilidad. Lo que ves es lo que pruebas.
Se genera una salida distinta para cada entrada.
Los estados y variables del sistema estn visibles o se pueden consultar durante la ejecucin.
Los estados y variables anteriores al sistema estn visibles o se pueden consular (por ejemplo, registro de transaccin).
Todos los factores que afectan a los resultados estn visibles.
Un resultado incorrecto se identifica fcilmente.
Los errores internos se detectan automticamente a travs de un mecanismo de autocomprobacin.
Se informa automticamente de los errores internos.
El cdigo fuente es accesible.
Controlabilidad. Cuanto mejor podamos controlar el software ms se puede automatizar y optimizar la prueba.
Todos los resultados posibles se pueden generar a travs de alguna combinacin de entrada.
Todo el cdigo es ejecutable a travs de alguna combinacin de entrada.
El ingeniero de pruebas puede controlar directamente los estados y las variables del hardware y del software
Los formatos de las entradas y los resultados son consistentes y estructurados.
Las pruebas pueden especificarse, automatizarse y reproducirse convenientemente.
Capacidad de descomposicin. Controlando el mbito de las pruebas, podemos aislar ms rpidamente los problemas y llevar a cabo
mejores pruebas de regresin.
El sistema software est construido con mdulos independientes. Los mdulos del software se pueden probar independientemente.
(COHESIN Y ACOPLAMIENTO)
Simplicidad. Cuanto menos haya que probar, ms rpidamente podremos probarlo.
Simplicidad funcional (por ejemplo, el conjunto de caractersticas es el mnimo necesario para cumplir los requisitos).
Simplicidad estructural (por ejemplo, la arquitectura es modularizada para limitar la propagacin de fallos).
Simplicidad del cdigo (por ejemplo, se adopta un estndar de cdigo para facilitar la inspeccin y el mantenimiento).
Estabilidad. Cuanto menos cambios, menos interrupciones a las pruebas.
Los cambios del software son infrecuentes
Los cambios del software estn controlados
Los cambios del software no invalidan las pruebas existentes.
El software se recupera bien de los fallos.
Facilidad de comprensin. Cuanta ms informacin tengamos, ms inteligentes sern las pruebas
El diseo se ha entendido perfectamente
Las dependencias entre los componentes internos, externos y compartidos se han entendido perfectamente.
Se han comunicado los cambios del diseo
La documentacin tcnica es instantneamente accesible, est bien organizada, es especfica, detallada y exacta

Pgina N
En la figura se puede ver una representacin del proceso de pruebas basada en parte en el
estndar IEEE std. 1008.
El proceso de prueba comienza con la generacin de un plan de pruebas en base a la
documentacin sobre el proyecto y la documentacin sobre el software a probar.
A partir de dicho plan, se entra en detalle diseando pruebas especficas basndose en la
documentacin del software a probar.
Una vez detalladas las pruebas (especificaciones de casos y de procedimientos) se toma la
configuracin del software (revisada, para confirmar que se trata de la versin apropiada del
programa) que se va a probar para ejecutar sobre ella los casos. En algunas situaciones, se puede
tratar de re-ejecuciones de pruebas, por lo que es conveniente tener constancia de los defectos
ya detectados aunque an no corregidos.
A partir de los resultados de salida, se pasa a su evaluacin mediante comparacin con la salida
esperada. A partir de sta, se pueden realizar dos actividades:
La depuracin (localizacin y correccin de defectos).
El anlisis de la estadstica de errores.
La depuracin puede corregir o no los defectos. Si no consigue localizarlos, puede ser necesario
realizar pruebas adicionales para obtener ms informacin. Si se corrige un defecto, se debe
volver a probar el software para comprobar que el problema est resuelto.
Por su parte, el anlisis de errores puede servir para realizar predicciones de la fiabilidad del
software y para detectar las causas ms habituales de error y mejorar los procesos de desarrollo.

Pgina N
Una vez introducidos los principales conceptos relacionados con las pruebas de software, veamos
las diferentes formas de disear pruebas de software.

Pgina N
El diseo de casos de prueba est totalmente mediatizado por la imposibilidad de probar
exhaustivamente el software. Pensemos en un programa muy sencillo que slo suma dos
nmeros enteros de dos cifras (del 0 al 99). Si quisiramos probar, simplemente, todos los valores
vlidos que se pueden sumar deberamos probar 10.000 combinaciones distintas de cien posibles
nmeros del primer sumando y cien del segundo. Pensemos que an quedara por probar todas
las posibilidades de error al introducir los datos (por ejemplo, teclear una letra en vez de un
nmero). Si para un programa tan elemental debemos realizar tantas pruebas, podemos imaginar
lo que supondra un programa medio.
En consecuencia, las tcnicas de diseo de casos de prueba tienen como objetivo conseguir una
confianza aceptable en que se detectarn los defectos existentes (ya que la seguridad total slo
puede obtenerse de la prueba exhaustiva, que no es practicable) sin que se necesite consumir
una cantidad excesiva de recursos (por ejemplo, tiempo para probar o tiempo de ejecucin). Toda
la disciplina de pruebas debe moverse, por lo tanto, en un equilibrio entre la disponibilidad de
recursos y la confianza que aportan los casos para descubrir los defectos existentes. Este
equilibrio no es sencillo, lo que convierte a las pruebas en una disciplina difcil y lejos de parecerse
a la imagen de actividad rutinaria que suele sugerir.
Ya que no se pueden probar todas las posibilidades de funcionamiento del software, la idea
fundamental para el diseo de casos de prueba consiste en elegir algunas de ellas que, por sus
caractersticas, se consideren representativas del resto. As, se asume que, si no se detectan
defectos en el software al ejecutar dichos casos, podemos tener un cierto nivel de confianza (que
depende de la eleccin de los casos) en que el programa no tiene defectos. La dificultad de esta
idea es saber elegir los casos que se deben ejecutar. De hecho, una eleccin puramente aleatoria
no proporciona demasiada confianza en que se puedan detectar todos los defectos existentes.
Por ejemplo, en el caso del programa de suma de dos nmeros, elegir cuatro pares de sumandos
al azar no aporta mucha seguridad a la prueba (una probabilidad de 4/10.000 de cobertura de
posibilidades). Por eso es necesario recurrir a ciertos criterios de eleccin que veremos a
continuacin.

Pgina N
Cualquier producto de ingeniera (y de muchos otros campos) puede probarse de una de estas dos formas:
(1) Conociendo la funcin especfica para la que fue diseado el producto, se pueden llevar a cabo
pruebas que demuestren que cada funcin es completamente operativa y, al mismo, tiempo buscando
errores en cada funcin;
(2) Conociendo el funcionamiento del producto, se pueden desarrollar pruebas que aseguren que todas
las piezas encajan, o sea, que la operacin interna se ajusta a las especificaciones y que todos los
componentes internos se han comprobado de forma adecuada.
El enfoque estructural o de caja blanca consiste en centrarse en la estructura interna (implementacin) del
programa para elegir los casos de prueba. En este caso, la prueba ideal (exhaustiva) del software consistira
en probar todos los posibles caminos de ejecucin, a travs de las instrucciones del cdigo, que puedan
trazarse. se basa en el minucioso examen de los detalles procedimentales. Se comprueban los caminos
lgicos del software proponiendo casos de prueba que ejerciten conjuntos especficos de condiciones y/o
bucles. Se puede examinar el estado del programa en varios puntos para determinar si el estado real
coincide con el esperado o mencionado.
El enfoque funcional o de caja negra consiste en estudiar la especificacin de las funciones, la entrada y la
salida para derivar los casos. Aqu, la prueba ideal del software consistira en probar todas las posibles
entradas y salidas del programa. Son por tanto pruebas que se llevan a cabo sobre la interfaz del software.
Pretenden demostrar que el software hace lo que se esperaba de l: que la entrada se acepta de forma
adecuada y que se produce un resultado correcto, mientras se mantiene la integridad de la informacin
externa (por ejemplo, archivos de datos). Una prueba de caja negra no contempla la estructura lgica
interna del software.
Estos enfoques no son excluyentes entre s, ya que se pueden combinar para conseguir una deteccin de
defectos ms eficaz.
Finalmente, en el enfoque aleatorio se simula la entrada habitual del programa creando datos para
introducir en l que sigan la secuencia y la frecuencia con las que podran aparecer en la prctica diaria, de
forma continua, sin descanso. Esto implica usar herramientas denominadas generadores de pruebas a las
que se alimenta con una descripcin de datos y secuencias de entradas posibles as como una estimacin de
probabilidad de ocurrir cada una de ellas en el uso real. Este enfoque es muy comn en la prueba de
compiladores en la que se generan aleatoriamente programas codificados en un lenguaje concreto que
sirven de pruebas para comprobar si son correctamente compilados.
Si el proceso de generacin de pruebas se ha realizado correctamente, a la larga se crearn todas las
posibles entradas del programa en todas las combinaciones posibles, aunque no sea necesario hacer
esto para una prueba adecuada. Tambin se puede conseguir, indicando la distribucin estadstica que
siguen, que la frecuencia de entradas sea la apropiada para orientar correctamente nuestras pruebas
hacia aquello que es ms probable que suceda en la prctica real. No obstante, esta forma de disear

Pgina N
casos de prueba es menos utilizada que las tcnicas de caja negra y de caja blanca.


Pgina N

Pgina N
La prueba del camino bsico es una tcnica de prueba de caja blanca propuesta inicialmente por
Tom McCabe [McCabe, 1976].
La utilizacin de la mtrica de McCabe ha sido muy popular en el diseo de pruebas desde su
presentacin. Esta mtrica es un indicador del nmero de caminos independientes que existen en
un grafo. El propio McCabe defini como un buen criterio de prueba la consecucin de la
ejecucin de un conjunto de caminos independientes, lo que implica probar un nmero de
caminos igual al de la mtrica.
El mtodo del camino bsico permite al diseador de casos de prueba obtener una medida de la
complejidad lgica de un diseo procedimental y usar esa medida como gua para la definicin de
un conjunto bsico de caminos de ejecucin. Los casos de prueba obtenidos del conjunto bsico
garantizan que durante la prueba se ejecuta por lo menos una vez cada sentencia del programa.

Pgina N

Pgina N

Pgina N

Pgina N
Un concepto importante en el contexto de los diagramas de flujo son las regiones. Para ilustrarlos
partimos de la representacin grfica de un determinado programa que nos proporciona el
Diagrama de Flujo mostrado en la parte superior de la diapositiva.
Dicho diagrama de flujo da lugar al grafo de flujo mostrado en la parte inferior. Pues bien, las
reas delimitadas por aristas y nodos se denominan regiones y cuando contabilizamos las
regiones, debemos contabilizar el rea exterior del grafo como otra regin ms.

Pgina N
La complejidad ciclomtica es una mtrica del software que proporciona una medida cuantitativa
de la complejidad lgica de un programa. De hecho, la experimentacin con la mtrica de McCabe
ha dado como resultado las siguientes conclusiones:
V (G) marca un lmite mnimo de nmero de casos de prueba para un programa, contando
siempre cada condicin de decisin como un nodo individual. Por lo tanto, en el contexto del
mtodo de prueba del camino bsico, el valor de la complejidad ciclomtica define el nmero
de caminos independientes de dicho programa, y por lo tanto, el nmero de casos de prueba a
realizar.
Parece que, cuando V(G) es mayor que diez, la probabilidad de defectos en el mdulo o en el
programa crece bastante si dicho valor alto no se debe a sentencias Case-of o similares. En
estos casos, es recomendable replantearse el diseo modular obtenido.
Posteriormente veremos cmo se identifican esos caminos, pero primero veamos cmo se puede
calcular la complejidad ciclomtica a partir de un grafo de flujo, para obtener el nmero de
caminos a identificar.


Pgina N
Existen varias formas de calcular la complejidad ciclomtica de un programa a partir de un grafo
de flujo:
El nmero de regiones del grafo coincide con la complejidad ciclomtica, V(G).
La complejidad ciclomtica, V(G), de un grafo de flujo G se define como
V(G) = Aristas Nodos + 2
La complejidad ciclomtica, V(G), de un grafo de flujo G se define como
V(G) = Nodos Predicado + 1

Pgina N
La Figura representa, por ejemplo, las cuatro regiones del grafo de flujo, obtenindose as la
complejidad ciclomtica de 4.
Anlogamente se puede calcular el nmero de aristas y nodos predicados para confirmar la
complejidad ciclomtica. As:
V(G) = Nmero de regiones = 4
V(G) = Aristas Nodos + 2 = 11-9 + 2 = 4
V(G) = Nodos Predicado + 1 = 3 +1 = 4
Esta complejidad ciclomtica determina el nmero de casos de prueba que deben ejecutarse para
garantizar que todas las sentencias de un programa se han ejecutado al menos una vez, y que
cada condicin se habr ejecutado en sus vertientes verdadera y falsa. Veamos ahora, cmo se
identifican estos caminos.

Pgina N
Un camino independiente es cualquier camino del programa que introduce, por lo menos, un
nuevo conjunto de sentencias de proceso o una condicin, respecto a los caminos existentes. En
trminos del diagrama de flujo, un camino independiente est constituido por lo menos por una
arista que no haya sido recorrida anteriormente a la definicin del camino.
En la identificacin de los distintos caminos de un programa para probar se debe tener en cuenta
que cada nuevo camino debe tener el mnimo nmero de sentencias nuevas o condiciones nuevas
respecto a los que ya existen. De esta manera se intenta que el proceso de depuracin sea ms
sencillo.
El conjunto de caminos independientes de un grafo no es nico. No obstante, a continuacin, se
definen algunas heursticas para identificar dichos caminos:
(a) Elegir un camino principal que represente una funcin vlida que no sea un tratamiento de
error. Debe intentar elegirse el camino que atraviese el mximo nmero de decisiones en el
grafo.
(b) Identificar el segundo camino mediante la localizacin de la ltima decisin en el camino
de la lnea bsica alternando su resultado mientras se mantiene el mximo nmero de
decisiones originales del camino inicial.
(c) Identificar un tercer camino, colocando la ltima decisin en su valor original a la vez que
se altera la penltima decisin del camino bsico, mientras se intenta mantener el resto de
decisiones originales.
(d) Continuar el proceso hasta haber conseguido tratar todas las decisiones, intentando
mantener como en su origen el resto de ellas.
Conviene aclarar que algunos de los caminos puede que no se puedan ejecutar solos y requieran
una concatenacin con algn otro. A partir de estos caminos, el diseador de las pruebas debe
analizar el cdigo para saber los datos de entrada necesarios para forzar la ejecucin por cada
uno de ellos. Una vez determinada la entrada deber consultar la especificacin para averiguar
cul es la salida tericamente correcta para cada caso.
Puede ocurrir tambin que las condiciones necesarias para que la ejecucin pase por un
determinado camino no se puedan satisfacer de ninguna manera. Nos encontraramos entonces
ante un camino imposible. En ese caso, debemos sustituir dicho camino por otro que permita
satisfacer igualmente el criterio de prueba de McCabe.


Pgina N

Pgina N
La figura muestra un procedimiento en pseudocdigo para calcular la media de 100 o menos
nmeros que se encuentran entre un mnimo y un mximo que se proporcionan como entrada al
procedimiento. Tambin calcula el total de entradas y el total de nmeros vlidos.
Se han numerado las sentencias con objeto de crear el correspondiente grafo de flujo

Pgina N
El valor de V(G) nos da el nmero de caminos linealmente independientes de la estructura de
control del programa. En el caso del procedimiento media, hay que especificar seis caminos.
Estos caminos pueden ser los que se muestran en la diapositiva.
En este caso hemos optado por construir primero el camino independiente ms corto y luego ir
complicndolo, modificando la decisin en cada nodo predicado.
Ntese que en cada camino hemos sealado en negrita el nodo predicado cuya decisin cambia
con respecto al siguiente camino.
Igualmente, memos subrayado la o las aristas nuevas con respecto a los caminos anteriores.
Si hubiramos construido los caminos siguiendo el algoritmo descrito en la diapositiva anterior, el
conjunto bsico sera (en negrita el nodo predicado cuya decisin cambia en el camino siguiente):
Camino 1: 1, 2, 3, 4, 5, 6, 7, 8, 9, 2 ,10, 11, 13
Camino 2: 1, 2, 3, 4, 5, 6, 7, 8, 9, 2 ,10, 12, 13
Camino 3: 1, 2, 3, 4, 5, 6, 7, 8, 9, 2, 3, 10, 12, 13
Camino 4: 1, 2, 3, 4, 5, 6, 8, 9, 2, 10, 12, 13
Camino 5: 1, 2, 3, 4, 5, 8, 9, 2, 10, 12, 13
Camino 6: 1, 2, 10, 12, 13

Pgina N
Veamos los posibles casos de prueba que se pueden generar para forzar la ejecucin de cada uno
de estos caminos.
Debemos escoger los datos de forma que las condiciones de los nodos predicado estn
adecuadamente establecidas, con el fin de comprobar cada camino.

Pgina N
Por ejemplo, fijemonos en el camino 4: 1-2-3-4-5-8-9-2-...
En esencia, dicho camino implica probar el algoritmo proporcionando como entrada un conjunto
de valores que incluya alguno que no cumpla con la condicin de estar entre los lmites
porporcionados (mnimo y mximo)
Un posible caso sera:
Valor: array de dos posiciones: [19, -999] Ntese que, por el nodo predicado 2, el segundo
nmero no contribuye al clculo de la media.
Mnimo: 20
Mximo: n (cualquier nmero entero)
El resultado esperado sera entonces:
Total.entrada = 1 el valor 19 pasa el primer IF haciendo que se incremente el contador
Total.valido = 0 pero no est en el rango de valores vlidos, con lo que no se incrementa
el contador de valores vlidos.
Por lo tanto, el ltimo IF (nodo 12) hace que el valor de la variable de salida media sea -999

Pgina N

Pgina N
Tambin conocidas como Pruebas de Comportamiento, estas pruebas se basan en la
especificacin del programa o componente a ser probado para elaborar los casos de prueba. El
componente se ve como una Caja Negra cuyo comportamiento slo puede ser determinado
estudiando sus entradas y las salidas obtenidas a partir de ellas.
Es decir, se centra en los requisitos funcionales. O sea, la prueba de caja negra permite al
ingeniero obtener conjuntos de condiciones de entrada que ejerciten completamente todos los
requisitos funcionales de un programa.

Pgina N
Lamentablemente, la prueba exhaustiva de caja negra tambin es generalmente impracticable:
pensemos en el ejemplo de la suma ya mencionado: un programa que debe sumar dos nmeros
del 1 al 100, admite 10.000 entradas
De nuevo, ya que no podemos ejecutar todas las posibilidades de funcionamiento, es decir, todas
las combinaciones de entradas y salidas, debemos buscar criterios que permitan elegir un
subconjunto de casos cuya ejecucin aporte una cierta confianza en detectar los posibles
defectos del software.
Para fijar estas pautas de diseo de pruebas, nos apoyaremos en las siguientes dos definiciones
de Myers que definen qu es un caso de prueba bien elegido:
El que reduce el nmero de otros casos necesarios para que la prueba sea razonable. Esto
implica que el caso ejecute el mximo nmero de posibilidades de entrada diferentes para as
reducir el total de casos.
El que cubre un conjunto extenso de otros casos posibles, es decir, nos indica algo acerca de la
ausencia o la presencia de defectos en el conjunto especfico de entradas que prueba pero
tambin de otros conjuntos similares.

Pgina N
Existen distintas tcnicas de diseo de casos de caja negra.
Conjetura de errores
Se enumera una lista de posibles equivocaciones tpicas que pueden cometer los desarrolladores y de
situaciones propensas a ciertos errores.
El valor cero es una situacin propensa a error tanto en la salida como en la entrada
En situaciones en las que se introduce un nmero variable de valores, conviene centrarse en el caso de
no introducir ningn valor y en el de un solo valor. Tambin puede ser interesante un lista que tiene
todos los valores iguales
Es recomendable imaginar que el programador pudiera haber interpretado algo mal en la especificacin
Tambin interesa imaginar lo que el usuario puede introducir como entrada a un programa
Mtodos de prueba basados en grafos
El primer paso en esta prueba de caja negra es entender los objetos que se modelan en el software y las
relaciones que conectan a estos objetos. Una vez que se ha llevado a cabo esto, el siguiente paso es definir
una serie de pruebas que verifiquen que todos los objetos tienen entre ellos las relaciones esperadas.
Dicho de otra manera, esta prueba empieza creando un grafo de objetos importantes y sus relaciones, y
despus diseando una serie de pruebas que cubran el grafo de manera que se ejerciten todos los objetos y
sus relaciones.
Prueba de comparacin
Hay situaciones (por ejemplo, controlador areo, gestin de planta nuclear) en las que la fiabilidad del
software es algo absolutamente crtico. En ese tipo de aplicaciones, a menudo se utiliza hardware y software
redundante para minimizar la posibilidad de error. Cuando se desarrolla software redundante, varios
equipos separados desarrollan versiones independientes de una aplicacin, usando las mismas
especificaciones. En esas situaciones, se deben probar todas las versiones con los mismos datos de prueba
para asegurar que todas proporcionan una salida idntica. Luego se ejecutan todas las versiones en paralelo
y se hace una comparacin en tiempo real de los resultados, para garantizar la consistencia.
Prueba de la tabla ortogonal
Hay muchas aplicaciones en que el dominio de entrada es relativamente limitado. Es decir, el nmero de
parmetros de entrada es pequeo y los valores de cada uno de los parmetros est claramente
delimitados. Cuando estos nmeros son muy pequeos (por ejemplo, 3 parmetros de entrada tomando 3
valores diferentes), es posible considerar cada permutacin de entrada y comprobar exhaustivamente el
dominio de entrada. En cualquier caso, cuando el nmero de valores de entrada crece y el nmero de
valores diferentes para cada dato se incrementa, la prueba exhaustiva se hace impracticable o imposible.
A continuacin nos centraremos en las tcnicas de diseo de pruebas de caja negra ms relevantes: la

Pgina N
particin equivalente y el anlisis de valores lmite.

Pgina N
La particin en clases de equivalencia 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. Su
objetivo es la definicin de casos de prueba que descubran clases de errores, reduciendo as el
nmero total de casos de prueba que hay que desarrollar.
En otras palabras, este mtodo intenta dividir el dominio de entrada de un programa en un
nmero finito de clases de equivalencia, de tal modo que se pueda asumir razonablemente que
una prueba realizada con un valor representativo de cada clase es equivalente a una prueba
realizada con cualquier otro valor de dicha clase. Esto quiere decir que si el caso de prueba
correspondiente a una clase de equivalencia detecta un error, el resto de los casos de prueba de
dicha clase de equivalencia deben detectar el mismo error. Y viceversa, si un caso de prueba no
ha detectado ningn error, es de esperar que ninguno de los casos de prueba correspondientes a
la misma clase de equivalencia encuentre ningn error.
Por lo tanto, puede descubrir de forma inmediata una clase de errores (por ejemplo,
procesamiento incorrecto de los datos de tipo cadena de caracteres) que, de otro modo,
requeriran la ejecucin de muchos casos de prueba antes de detectar el error genrico.


Pgina N
Una clase de equivalencia representa un conjunto de estados vlidos y no vlidos para las
condiciones de entrada de un programa.
Las clases de equivalencia se identifican examinando cada condicin de entrada (normalmente
una frase en la especificacin) y dividindola en dos o ms grupos.
Se definen dos tipos de clases de equivalencia: las clases de equivalencia vlidas, que representan
entradas vlidas al programa, y las clases de equivalencia no vlidas, que representan valores de
entrada errneos.


Pgina N
En funcin de cul sea la condicin de entrada se pueden seguir las siguientes pautas para
identificar las clases de equivalencia:
Si una condicin de entrada especifica un rango de valores, identificar una clase de
equivalencia vlida y dos clases no vlidas. Por ejemplo, si un contador puede ir de 1 a 999, la
clase vlida sera 1 <= contador <= 999. Mientras que las clases no vlidas seran contador <
1 y contador > 999
Si una condicin de entrada especifica un valor o nmero de valores, identificar una clase
vlida y dos clases no vlidas. Por ejemplo, si tenemos que puede haber desde uno hasta seis
propietarios en la vida de un coche, habr una clase vlida y dos no vlidas: menos de un
propietario (0) y ms de 6 propietarios.
Si una condicin de entrada especifica un conjunto de valores de entrada, identificar una clase
de equivalencia vlida y una no vlida. Sin embargo, si hay razones para creer que cada uno de
los miembros del conjunto ser tratado de distinto modo por el programa, identificar una
clase vlida por cada miembro y una clase no vlida. Por ejemplo, el tipo de un vehculo puede
ser: autobs, camin, taxi, coche o moto. Habr una clase vlida por cada tipo de vehculo
admitido, y la clase no vlida estar formada por otro tipo de vehculo.
Si una condicin de entrada especifica una situacin que debe ocurrir, esto es, es lgica,
identificar una clase vlida y una no vlida. Por ejemplo, el primer carcter del identificador
debe ser una letra. La clase vlida sera identificador que comienza con letra, y la clase
invlida sera identificador que no comienza con letra.
En general, si hay alguna razn para creer que los elementos de una clase de equivalencia no se
tratan de igual modo por el programa, dividir la clase de equivalencia entre clases de equivalencia
ms pequeas para cada tipo de elementos. Por ejemplo:
Si se sospecha que ciertos elementos de una clase no se tratan igual deben dividirse en clases
menores
Si se especifica un conjunto de valores y el programa los trata de diferente manera, se
identifica una clase vlida y otra no vlida para cada valor


Pgina N
En esta diapositiva se muestran algunos ejemplos sencillos de aplicacin de las reglas que
acabamos de presentar

Pgina N
El ltimo paso del mtodo es el uso de las clases de equivalencia para identificar los casos de
prueba correspondientes.
El objetivo es minimizar el nmero de casos de prueba, por tanto cada caso de prueba debe
considerar tantas condiciones de entrada como sea posible.
No obstante, es necesario disear con cuidado los casos de prueba de manera que no se
enmascaren fallos. As, para crear los casos de prueba a partir de las clases de equivalencia se han
de seguir los siguientes pasos:
1. Asignar a cada clase de equivalencia un nmero nico.
2. Hasta que todas las clases de equivalencia hayan sido cubiertas por los casos de prueba, se
tratar de escribir un caso que cubra tantas clases vlidas no incorporadas como sea posible.
3. Hasta que todas las clases de equivalencia no vlidas hayan sido cubiertas por casos de
prueba, escribir un caso para cubrir una nica clase no vlida no cubierta.
La razn de cubrir con casos individuales las clases no vlidas es que ciertos controles de entrada
pueden enmascarar o invalidar otros controles similares.
Por ejemplo, si tenemos dos clases vlidas: introducir cantidad entre 1 y 99 y seguir con
letra entre A y Z, el caso 105 & (dos errores) puede dar como resultado 105 fuera de rango
de cantidad, y no examinar el resto de la entrada no comprobando as la respuesta del
sistema ante una posible entrada no vlida.

Pgina N
La diapositiva muestra un ejemplo de aplicacin.
Supongamos una aplicacin bancaria en la que el operador debe proporcionar un cdigo, un
nombre para que el usuario identifique la operacin (por ejemplo, nmina) y una orden que
disparar una serie de funciones bancarias:
Especificacin:
Cdigo de rea: Nmero de tres cifras que no comienza ni por 0 ni por 1
Nombre: Seis caracteres
Orden: cheque, depsito, pago factura, retirada de fondos
Aplicacin de las reglas
Cdigo:
La entrada proporcionada podra ser o no un nmero. Por tanto, la condicin de entrada
es lgica, con lo que definiramos una clase valida (es nmero) y otra no valida (no es
nmero):
Clase vlida (es nmero). El nmero tiene que estar en un rango de valores, por
tanto:
Subclase vlida: (200 cdigo 999)
Dos subclases no vlidas: (cdigo < 200) y (999 < cdigo)
Clase invlida (no es nmero)
Nombre de identificador: nmero especfico de valores
Clase vlida: 6 caracteres
Dos clases invlidas: ms o menos de 6 caracteres
Orden: conjunto de valores (4 valores vlidos):
Una clase vlida para cada orden: cheque, depsito
Una clase no vlida: p.e. divisas
As, las tablas de la parte inferior de la diapositiva muestran los casos generados presuponiendo el
orden de entrada Cdigo Operacin Orden


Pgina N
La experiencia muestra que los casos de prueba que exploran las condiciones lmite producen
mejor resultado que aquellos que no lo hacen. Es decir, es ms probable que los defectos del
software se acumulen en estas condiciones lmite, que se hayan en los mrgenes de la clase de
equivalencia (directamente arriba y abajo), tanto de entrada como de salida.
Por ello, se ha desarrollado el anlisis de valores lmite como tcnica de prueba. Esta tcnica nos
lleva a elegir los casos de prueba que ejerciten los valores lmite.
As pues, el anlisis de valores lmite complementa la tcnica de particin de equivalencia de
manera que:
En lugar de seleccionar cualquier caso de prueba de las clases vlidas e invlidas, se eligen los
casos de prueba en los extremos.
En lugar de centrarse slo en el dominio de entrada, los casos de prueba se disean tambin
considerando el dominio de salida.

Pgina N
Las pautas para desarrollar casos de prueba con esta tcnica son:
Si una condicin de entrada especifica un rango de valores, se disearn casos de prueba para
los dos lmites del rango, y otros dos casos para situaciones justo por debajo y por encima de
los extremos.
Ejemplo de entrada: rango permitido de entrada (-1.0 valor 1.0)
Casos: -1.0; 1.0; -1.001 y 1.001 (suponiendo que se admitan 3 decimales)
Ejemplo salida: el descuento por compra al contado variar entre el 6 y el 50% del
importe total
Casos: escribir casos para intentar obtener descuentos del 5.99, el 6, el 50 y el 50.01%
Si una condicin de entrada especifica un nmero de valores, se disean dos casos de prueba
para los valores mnimo y mximo, adems de otros dos casos de prueba para valores justo
por encima del mximo y justo por debajo del mnimo.
Ejemplo entrada: el fichero de entrada tendr de 1 a 255 registros
Casos: 0, 1, 255, 256 registros
Ejemplo salida: el programa mostrar de 1 a 4 listados
Casos: escribir casos para intentar generar 0, 1, 4 y 5 listados.
Si la entrada o salida de un programa es un conjunto ordenado (p.e. una tabla, una lista, etc.)
habr que prestar atencin a los elementos primero y ltimo del conjunto.
Finalmente, respecto a los valores de salida conviene recordar que no siempre valores lmites de
entada generan valores lmites de salida.
Por ejemplo, vase la funcin seno
sen(90) = 1 pero sen(180) = 0

Pgina N

Pgina N
Una vez conocidas las tcnicas de diseo y ejecucin, debemos analizar cmo se plantea la
utilizacin de las pruebas en el ciclo de vida. La estrategia de aplicacin y la planificacin de las
pruebas pretenden integrar el diseo de los casos de prueba en una serie de pasos bien
coordinados a travs de la creacin de distintos niveles de prueba, con diferentes objetivos.
Adems, permite la coordinacin del personal de desarrollo, del departamento de aseguramiento
de calidad (o algn grupo independiente dedicado a la V&V) y del cliente, gracias a la definicin
de los papeles que deben desempear cada uno y la forma de llevarlos a cabo.
La estrategia proporciona 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.

Pgina N
Las pruebas son un conjunto de actividades que se pueden planificar por adelantado y llevar a
cabo sistemticamente. Por esta razn, se debe definir en el proceso una plantilla para las
pruebas del software: un conjunto de pasos en los que podamos situar los mtodos especficos de
diseo de casos de prueba. Una estrategia debe proporcionar una gua al profesional y
proporcionar un conjunto de hitos para el jefe de proyecto.
En la literatura se han propuesto diversas estrategias de prueba del software. Todas proporcionan
al ingeniero software una plantilla para la prueba y todas tienen las siguientes caractersticas
generales:
Las pruebas comienzan a nivel de mdulo y trabajan hacia fuera, hacia la integracin de
todo el sistema. Una estrategia de prueba de software debe incluir pruebas de bajo nivel que
verifiquen que todos los pequeos segmentos de cdigo fuente se han implementado
correctamente, as como pruebas de alto nivel que validen las principales funciones del
sistema frente a los requisitos del cliente. Segn el momento, son apropiadas diferentes
tcnicas de prueba.
La prueba la lleva a cabo el responsable del desarrollo del software y (para grandes proyectos)
un grupo independiente de pruebas.
La prueba y la depuracin son actividades diferentes, pero la depuracin se debe incluir en
cualquier estrategia de prueba.

Pgina N
En general, la estrategia de pruebas suele seguir las siguientes etapas:
Las pruebas comienzan a nivel de mdulo.
Una vez terminadas, progresan hacia la integracin del sistema completo y su instalacin.
Culminan cuando el cliente acepta el producto y se pasa a su explotacin inmediata.
Esta serie tpica de etapas se describe con mayor detalle a continuacin:
Se comienza con la prueba de cada mdulo, que normalmente la realiza el propio personal de
desarrollo en su entorno.
Con el esquema del diseo del software, los mdulos probados se integran para comprobar
sus interfaces en el trabajo conjunto (prueba de integracin).
El software totalmente ensamblado se prueba como un conjunto para comprobar si cumple o
no tanto los requisitos funcionales como los de rendimiento, seguridad, etc. (prueba funcional
o de validacin). Este nivel de prueba coincide con el de la prueba del sistema cuando no se
trate de software empotrado u otros tipos de especiales de aplicaciones.
El software ya validado se integra con el resto del sistema (por ejemplo, elementos mecnicos,
interfaces electrnicas, etc.) para probar su funcionamiento conjunto (prueba del sistema).
Por ltimo, el producto final se despliega de forma que el usuario compruebe en su propio
entorno de explotacin si lo acepta como est o no (prueba de aceptacin).
En realidad podemos establecer una correspondencia entre las distintas etapas del desarrollo y
los niveles de prueba.

Pgina N
As (vase la figura), dicha relacin se concreta en un modelo de ciclo de vida que resulta
clarificador para entender el proceso de pruebas, denominado ciclo en V (uve)
La prueba de mdulo (prueba de unidad) centra sus actividades en ejercitar la lgica del
mdulo (caja blanca) y los distintos aspectos de la especificacin de las funciones que debe
realizar el mdulo (caja negra).
La prueba de integracin debe tener en cuenta los mecanismos de agrupacin de mdulos
fijados en la estructura del programa, as como, en general, las interfaces entre los
componentes de la arquitectura del software.
La prueba del sistema debe centrar sus comprobaciones en el cumplimiento de los objetivos
indicados para el sistema.
La prueba de aceptacin sirve para que el usuario pueda verificar si el producto final se ajusta
a los requisitos por l fijados (normalmente en forma de criterios de aceptacin en el
contrato) o, en ltimo caso, en funcin de lo que indique el contrato.

Pgina N
La prueba de unidad es la primera fase de las pruebas dinmicas (recurdese la distincin
respecto a las revisiones formales, de naturaleza esttica) y se realizan sobre cada mdulo de
manera independiente.
El objetivo es comprobar que el mdulo, entendido como una unidad funcional, est
correctamente codificado.
Para ello, cada mdulo ser probado por separado, y lo har generalmente la persona que lo cre
(a diferencia de otros niveles de prueba, donde el grupo de aseguramiento de calidad interviene
en el proceso), utilizando herramientas de depuracin. Debemos recordar que nos referimos a las
pruebas formales que permiten declarar que un mdulo est listo y terminado (paso a control de
configuracin), no a las pruebas informales que los programadores efectan mientras desarrollan
el cdigo.
En este contexto, un mdulo se entiende como un componente software que cumple las
siguientes caractersticas:
Debe ser un bloque bsico de construccin de programas.
Debe implementar una funcin independiente y simple.
Podr ser probado al cien por cien por separado.
No deber tener ms de 500 lneas de cdigo.
El objetivo de la prueba de unidad es aproximarse todo lo posible al ideal de exhaustividad,
utilizando eminentemente el enfoque de caja blanca, aunque se complementa con caja negra
(criterios de cobertura lgica y funcional respectivamente). Ntese que las pruebas de caja negra
(los casos de prueba) se pueden especificar antes de que el mdulo sea programado, no as las
pruebas de caja blanca.
El hecho de incorporar casos de caja blanca (a diferencia de lo que ocurre en el resto de niveles)
se debe a las siguientes razones:
El tamao del mdulo o grupo de mdulos es apropiado para poder usar tcnicas de caja
blanca que permitan examinar toda la lgica del programa.
El tipo de defectos que se buscan coincide con los propios de la lgica detallada de cada
mdulo.

Pgina N
Debido a que un componente no es un programa independiente, cualquier prueba unitaria suele
implicar la necesidad de disponer de otro software que reemplaza a las unidades con las que la
unidad que queremos probar debe interactuar, simulando su comportamiento. En general, estos
mdulos adicionales pueden ser de dos tipos: controladores o drivers y resguardos o stubs.
Un controlador o driver no es ms que un programa principal que acepta los datos del caso de
prueba, pasa estos datos al mdulo e imprime los resultados importantes. Por tanto:
Se encarga de declarar o definir cualquier variable o constante que necesite el mdulo que
queremos probar y debe encargarse de comprobar el estado de esas variables o constantes
Proporciona los mecanismos necesarios para recoger las entradas y mostrar las salidas
necesarias
Invoca al mdulo que estamos probando y le proporciona la informacin que necesita cuando
se le invoca
Soporta la gestin de errores o interrupciones elevados desde el mdulo probado (los captura
o los eleva cuando sea necesario)
Un resguardo o stub proporciona la interfaz del mdulo subordinado, lleva a cabo una mnima
manipulacin de datos, imprime una verificacin de entrada y devuelve control al mdulo de
prueba que lo invoc. Por tanto, un stub:
Proporciona una interfaz idntica a la del mdulo que reemplaza
Soporta el mismo comportamiento que dicho mdulo. Por ejemplo, con una simple sentencia
de retorno.
Los controladores y los resguardos son una sobrecarga de trabajo, ya que ambos son software
que debe desarrollarse pero que no se entrega con el producto final. Si los controladores y
resguardos son sencillos, el trabajo adicional es relativamente pequeo. En cualquier caso, el
esfuerzo se ve compensado por el hecho de que podrn ser reutilizados innumerables veces a lo
largo del proceso de desarrollo (cada vez que se necesite probar el mdulo porque haya habido
un cambio en el sistema). Adems, existen algunas herramientas que facilitan o soportan la
generacin (semi-)automtica de drivers y stubs.
Finalmente, no debemos olvidar que la complejidad de drivers y stubs debe mantenerse
controlada: si resultan demasiado complejos llegamos a la situacin de tener que probarlos para
comprobar que no introducen ningn error por s mismos.


Pgina N
An cuando los mdulos de un programa funcionen bien por separado es necesario probarlos
conjuntamente: un mdulo puede tener un efecto adverso o inadvertido sobre otro mdulo; las
subfunciones, cuando se combinan, pueden no producir la funcin principal deseada; la
imprecisin aceptada individuamente puede crecer hasta niveles inaceptables al combinar los
mdulos; los datos pueden perderse o malinterpretarse entre interfaces, etc. Por ejemplo,
supongamos que la funcin B consume un valor producido por la funcin A. An siendo ambos
reales, podra ser que al funcionar conjuntamente, B no pudiese procesar la entrada
proporcionada por A porque fueran reales de distinta precisin.
Por lo tanto, es necesario probar el software ensamblando todos los mdulos probados
previamente. sta es el objetivo de las pruebas de integracin.
A menudo hay una tendencia a intentar una integracin no incremental, tambin denominada
enfoque big-bang: se prueba cada mdulo por separado y luego se integran todos de una vez y se
prueba el programa completo. Obviamente, el resultado puede ser un poco catico: se pueden
producir un gran nmero de errores y ser prcticamente imposible identificar el mdulo (o
mdulos) que los provoc.
Por contra, se puede aplicar la integracin incremental, donde se combina el siguiente mdulo
que se debe probar con el conjunto de mdulos que ya han sido probados. De esta forma el
programa se prueba en pequeas porciones y los errores y los defectos que los provocan son ms
fciles de detectar. Existen dos tipos de integracin incremental, la denominada ascendente y
descendente. Veamos a continuacin los pasos a seguir en cada caso.


Pgina N
La integracin incremental ascendente comienza con la construccin y prueba de los mdulos
atmicos.
1. Se combinan los mdulos de bajo nivel en grupos que realicen una funcin o sub-funcin
especfica (o quizs si no es necesario, individualmente).
2. Se escribe un controlador (un programa de control de la prueba) para coordinar la entrada y
salida de los casos de prueba. De este modo permitimos simular la llamada a los mdulos,
introducir datos de prueba y recoger resultados.
3. Se prueba el grupo utilizando su controlador
4. Se eliminan los controladores y se sustituyen por los mdulos de nivel superior en la
jerarqua, movindose hacia arriba por la estructura del programa.
Ntese que con este tipo de integracin incremental, la funcionalidad que deberan proporcionar
los mdulos subordinados siempre est disponible y se elimina la necesidad de resguardos

Pgina N
Ejemplo: supongamos la siguiente estructura de programa
(NOTA: en las siguientes figuras, a los controladores o drivers se
les denomina Impulsores)

En la primera fase se realizan las pruebas unitarias de E, F, G y D

En la segunda, sin embargo, se puede observar que se realizan
simultneamente la prueba unitaria de B y C, y la integracin de
B-E y C-[F-G]. Esta mezcla de pruebas unitarias y de integracin
ocurre en todas las integraciones incrementales.

El ltimo paso consiste en la incorporacin de A y la prueba del
programa completo, que no requiere controlador, ya que todo
el cdigo de gestin de la entrada y la salida del programa est
incorporado. Por tanto, la introduccin de datos de prueba y la
visualizacin de resultados se hace por la entrada/salida
convencional.

Pgina N
Las etapas fundamentales de la integracin incremental descendente son:
Comienza por el mdulo de control principal (el de mayor nivel, tambin conocido como
programa principal o mdulo raz). Se escriben mdulos ficticios o stubs para simular la presencia
de los subordinados ausentes que sern llamados por el mdulo raz.
Una vez probado el mdulo raz se sustituye uno de los subordinados ficticios por el mdulo
correspondiente segn el orden elegido. Se incorporan nuevos stubs para recoger las llamadas del
nuevo mdulo incorporado.
Se ejecutan las pruebas correspondientes cada vez que se incorpora un mdulo nuevo y al
concluir se sustituye otro mdulo ficticio por el mdulo real correspondiente
Conviene repetir algunos casos de prueba de los ya ejecutados anteriormente para comprobar
que no se ha introducido ningn defecto nuevo.


Pgina N
No existe un procedimiento general para determinar cul de los mdulos subordinados posibles
es mejor incorporar primero, es decir, no se puede dar una regla general que permita determinar
la secuencia ptima de incorporacin de mdulos. Hay que estudiar cada caso para decidir la
estrategia optima. No obstante se pueden seguir las siguientes reglas generales:
Si hay secciones crticas (por ejemplo un mdulo especialmente complejo que implementa un
algoritmo nuevo y es por tanto ms propenso a errores) se debe definir la secuencia de
integracin de manera que se prueben lo antes posible.
El orden de integracin debe incorporar cuanto antes los mdulos de entrada/salida para
facilitar la ejecucin de pruebas
Existen dos formas ordenes fundamntales de integracin descendente:
Primero en profundidad: se van completando ramas del rbol (A B E C F G D)
Primero en anchura: se van completando niveles (horizontales) de jerarqua (A B C D E F
G)


Pgina N
La Figura muestra un ejemplo de integracin descendiente por profundidad.
Si se prueba M1, M2 y M4 sera entonces necesario preparar resguardos para M5 y M6, y para
M7 y M3.
Estos resguardos se han representado en la figura como R5, R6, R7 y R4 respectivamente.
Una vez realizada esta primera prueba se sustituira R5 por M5, seguidamente R6 por M6 y as
sucesivamente hasta probar todos los mdulos.


Pgina N
La Figura muestra un ejemplo de integracin descendiente por profundidad.
Si se prueba M1, M2 y M4 sera entonces necesario preparar resguardos para M5 y M6, y para
M7 y M3.
Estos resguardos se han representado en la figura como R5, R6, R7 y R4 respectivamente.
Una vez realizada esta primera prueba se sustituira R5 por M5, seguidamente R6 por M6 y as
sucesivamente hasta probar todos los mdulos.


Pgina N
Cada vez que se aade un nuevo mdulo como parte de una prueba de integracin, el software cambia:
Se establecen nuevos caminos de flujo de datos
Pueden ocurrir nuevas E/S
Se invoca una nueva lgica de control
Estos cambios pueden causar problemas con funciones que antes trabajaban perfectamente. La prueba de regresin es
una estrategia importante para reducir este tipo de efectos colaterales. En general, se deben ejecutar pruebas de
regresin cada vez que se realice un cambio importante en el software (incluyendo la integracin de nuevos mdulos)
En el contexto de las pruebas de integracin, la prueba de regresin es volver a ejecutar un subconjunto de pruebas que
se han llevado a cabo anteriormente para asegurarse de que los cambios no han propagado efectos colaterales no
deseados.
En un contexto ms amplio, las pruebas con xito (de cualquier tipo) dan como resultado el descubrimiento de errores, y
los errores hay que corregirlos. Cuando se corrige el software, se cambia algn aspecto de la configuracin del software
(el programa, su documentacin o los datos que lo soportan). La prueba de regresin es la actividad que ayuda a asegurar
que los cambios (debidos a las pruebas o por otros motivos) no introducen un comportamiento no deseado o errores
adicionales. As, la prueba de regresin consiste en la repeticin selectiva de pruebas para detectar fallos introducidos
durante la modificacin de un sistema o componente de un sistema. Es decir, su objetivo es comprobar que los cambios
no han producido efectos adversos no intencionados o que se siguen cumpliendo los requisitos especificados. Este tipo de
pruebas ha de realizarse, tanto durante el desarrollo cuando se produzcan cambios en el software, como durante el
mantenimiento.
La prueba de regresin se puede hacer manualmente, volviendo a realizar un subconjunto de todos los casos de prueba o
automatizarse utilizando herramientas de reproduccin de captura. Estas herramientas permiten capturar casos de
prueba y sus resultados para su subsiguiente reproduccin y comparacin.
A medida que progresa la prueba de integracin, el nmero de pruebas de regresin puede crecer demasiado. Por tanto,
el conjunto de pruebas de regresin debera disearse para incluir slo aquellas pruebas que traten una o ms clases de
errores en cada una de las funciones principales del programa. No es prctico ni eficiente volver a ejecutar cada prueba
de cada funcin del programa despus de un cambio.
Por lo tanto, las pruebas de regresin deben disearse de manera que:
Se prueben ntegramente los mdulos que se han cambiado.
Se contemple cuales son los mdulos que no han cambiado y que han sido afectados por los cambios producidos.
De esta formar, el conjunto de pruebas de regresin contiene tres clases diferentes de casos de prueba:
Una muestra representativa de pruebas que ejercite todas las funciones del software
Pruebas adicionales que se centran en las funciones del software que se van a ver probablemente afectadas por el
cambio
Pruebas que se centran en los componentes del software que han cambiado

Pgina N
Finalmente, ya hemos introducido con anterioridad los principios de la integracin NO
incremental. En este tipo de integracin cada mdulo requiere para ser probado:
Un controlador que transmite los datos de prueba al mdulo y muestra los resultados de
dichos casos de prueba
Uno o ms stubs o resguardos que simulan la funcin de cada mdulo subordinado llamado
por el mdulo que se va a probar
As, la prueba de cada mdulo sigue el esquema mostrado en la diapositiva.
Despus de probar cada mdulo por separado se ensamblan todos de una sola vez para formar el
programa completo y probarlo en conjunto.
Ntese que la integracin NO incremental es el nico caso en el que las pruebas de unidad y las
de integracin estn totalmente separadas.


Pgina N
En la Integracin No Incremental se requiere menos tiempo dedicado a la ejecucin de las pruebas, ya que
se prueba de una sola vez la combinacin de los mdulos, en lugar de ejecutar pruebas cada vez que se
incorpora un mdulo. A cambio, se dedica ms tiempo para la codificacin de mdulos auxiliares
(controladores y resguardos) ya que la prueba de cada mdulo implica el desarrollo de controladores y
resguardos ad-hoc.
Por otro lado, cuando se adopta un enfoque de Integracin Incremental se reduce obviamente el tiempo
dedicado la codificacin de mdulos auxiliares para las pruebas unitarias. Adems, los defectos y errores en
las interfaces se detectan antes, ya que se empiezan a probar antes las interacciones entre mdulos.
Finalmente, se simplifica el proceso de depuracin, ya que la fuente de un error o defecto en cualquier paso
del proceso de integracin, ser muy probablemente el ltimo mdulo incorporado
Respecto a la seleccin de una aproximacin incremental ascendente o descendente, podemos decir que las
ventajas de una estrategia tienden a convertirse en desventajas de la otra.
La principal desventaja del enfoque descendente es la necesidad de codificar muchos resguardos, que
suelen ser ms complejos que los controladores. Por ejemplo, la entrada/salida suele descansar en los
mdulos de bajo nivel y codificar mdulos que la simulen suele resultar tarea complicada, sino
imposible. No obstante, los problemas asociados con la complejidad de los resguardos podra verse
compensada por la ventaja de poder probar de antemano las principales funciones de control. Una vez
codificados dichos resguardos, el enfoque descendente permite ver antes una estructura previa del
programa, lo que facilita el hacer demostraciones y ayuda a mantener la moral del equipo de desarrollo.
Por otro lado, la principal desventaja de la integracin ascendente es que el programa como entidad no
existe hasta que se ha aadido el ltimo mdulo. No obstante, este inconveniente se compensa con la
mayor facilidad de diseo de casos de prueba y con el hecho de que la necesidad de desarrollar
resguardos se reemplace por la de desarrollar controladores, menos complejos. Adems, dado su
carcter ms especfico, suele resultar ms fcil crear entradas para probar estos mdulos que los
mdulos de alto nivel.
Obviamente, ya que en el enfoque ascendente se prueban antes los mdulos de bajo nivel, resultar ms
adecuado para desarrollar pruebas en aquellos sistemas en los que esperamos que sean la principal fuente
de defectos.
La seleccin de una estrategia de integracin depende de las caractersticas del software y, a veces, de la
planificacin del proyecto. En general, el mejor compromiso puede ser un enfoque combinado (a veces
denominado prueba sndwich) que use la descendente para los niveles superiores de la estructura del
programa, junto con la ascendente para los niveles subordinados.

Pgina N
Este tipo de pruebas tiene como propsito ejercitar profundamente el sistema para verificar que
se han integrado adecuadamente todos los elementos hardware y software del propio sistema
entre s, y con los elementos software o hardware de otros sistemas con los que deba interactuar.
Concretamente se debe comprobar:
El cumplimiento de los requisitos funcionales establecidos. Para ello, se disean casos de
prueba aplicando tcnicas de caja negra a las especificaciones.
El funcionamiento y rendimiento de las interfaces hardware, software y de usuario. Para ello
se deben disear casos de prueba que prueben toda la informacin procedente de otros
elementos del sistema.
La adecuacin de la documentacin de usuario.
El rendimiento y respuesta en condiciones lmite y de sobrecarga. Para ello se disearn casos
de prueba que comprueben el rendimiento del sistema (pruebas de volumen de datos, de
lmites de procesamiento, etc.) Este tipo de pruebas suelen llamarse pruebas de sobrecarga
(stress-testing)
Hay cuatro tipos de pruebas de sistema. Aunque cada una tiene un propsito distinto, todas
trabajan para verificar que se han integrado adecuadamente todos los elementos del sistema y que
realizan las funciones apropiadas.

Pgina N
Muchos sistemas deben ser capaces recuperarse de los fallos y continuar trabajando. En estos
casos, el sistema debe ser capaz de corregir un fallo en un determinado periodo de tiempo para
evitar que se produzca un serio dao econmico. Incluso existen sistemas an ms exigentes, que
deberan ser capaces de tolerar los fallos; es decir, un fallo no debera hacer que cesara el
funcionamiento de todo el sistema.
El objetivo de la prueba de recuperacin es comprobar que el sistema es capaz de recuperarse de
un fallo grave y seguir funcionando. Para ello, fuerza el fallo del sistema de diferentes formas y
verifica que la recuperacin se lleva a cabo de manera apropiada. De esta forma, podremos
identificar cuanto tiempo necesita el sistema para volver a su estado normal y si efectivamente
recupera dicho estado normal.
Si la recuperacin es automtica (llevada a cabo por el propio sistema) hay que comprobar
que el sistema se inicializa correctamente y que los mecanismos de recuperacin del estado
del sistema, de recuperacin de datos y el proceso de re-arranque funcionan correctamente.
Si la recuperacin requiere la intervencin humana, hay que evaluar los tiempos medios de
reparacin (MTTR - Mean/Minimum/Maximum Time to Recovery/ Repair/Respond/Restore)
para determinar si estn dentro de unos lmites aceptables

Pgina N
Cualquier sistema que maneje informacin sensible o lleve a cabo acciones que puedan perjudicar
(o beneficiar) impropiamente a sus usuarios es un posible objetivo para entradas impropias o
ilegales al sistema.
Este acceso al sistema incluye desde piratas informticos que intentan entrar en los sistemas por
deporte o aficin a empleados disgustados que lo hacen por venganza o delincuentes
cibernticos.
La prueba de seguridad intenta verificar que los mecanismos de proteccin incorporados en el
sistema lo protegern de este tipo de accesos no deseados.
Durante la prueba, el responsable desempea el papel de un individuo que desea realizar un
acceso no autorizado al sistema. En este sentido todo vale: debe intentar conseguir las claves de
acceso por cualquier medio, desarrollar programas a medida para atacar al sistema,
bloquendolo, denegando el servicio a otras personas, provocando cadas, etc.
Con tiempo y recursos suficientes, una buena prueba de seguridad terminar por acceder al
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.

Pgina N
Frente a las pruebas que hemos estado viendo, cuyo objetivo era la evaluacin del
funcionamiento y rendimiento del programa en condiciones normales, las pruebas de resistencia
estn diseadas para enfrentar a los programas con situaciones anormales. En esencia, el objetivo
de la prueba de resistencia es responder a la pregunta: A qu potencia puedo ponerlo a
funcionar antes de que falle?
Para ello, la prueba de resistencia ejecuta un sistema de forma que se produzca una demanda de
recursos en cantidad, frecuencia o volmenes anormales.
Ejemplos: casos de prueba que generen diez interrupciones por segundo, cuando lo normal son
una o dos; que requieran el mximo de memoria o de otros recursos; que que produzcan
excesivas bsquedas en disco; que incrementen la frecuencia de datos de entrada con el fin de
comprobar cmo responden las funciones de entrada.
En esencia, lo que el responsable de la prueba intenta es 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 vlidos puede producir un resultado errneo o una profunda
degradacin del rendimiento. Esta situacin es anloga a la singularidad matemtica, que se da
con algunas funciones que presentan comportamientos extraos e inesperados cuando se le
asignan determinados valores a la variable independiente (p.e.: 1/x; x=0).
La prueba de sensibilidad intenta descubrir combinaciones de datos dentro de una clase de
entrada vlida que pueda producir inestabilidad o resultados anmalamente incorrectos.

Pgina N
El aspecto clave en los sistemas de tiempo real y los sistemas empotrados lo juegan los requisitos
no funcionales, es decir, los requisitos de rendimiento. Un sistema de este tipo que satisface los
requisitos funcionales pero no es capaz de hacerlo ajustndose a los requisitos de rendimiento
especificados no es un sistema correcto.
La prueba de rendimiento est diseada precisamente para probar el rendimiento del software
en tiempo de ejecucin dentro del contexto de un sistema integrado. En realidad abarca todos los
pasos del proceso de prueba, ya que deberamos ser capaces de asegurar que se satisfacen los
requisitos de rendimiento incluso a nivel de mdulo. Y la mejor forma de hacerlo es realizar
pruebas de rendimiento unitarias en paralelo con las pruebas de caja blanca. Sin embargo, hasta
que no estn completamente integrados todos los elementos del sistema no se puede asegurar
realmente que el rendimiento del sistema es el adecuado.
Las pruebas de rendimiento suelen realizarse en paralelo con las de resistencia y se acostumbra a
utilizar software y hardware que soporte la medicin exacta de la utilizacin de recursos.

Pgina N
Si la prueba del sistema determin la capacidad real del sistema y permiti a la organizacin de
desarrollo tener confianza en que estaba listo para el funcionamiento, la prueba de aceptacin
pretende transmitir esta confianza al usuario.
As, el objetivo de la prueba de validacin aceptacin es comprobar si el producto est listo
para ser desplegado y utilizado en el entorno del usuario. En el fondo, lo ms importante para
evaluar el uso operativo del software suele ser la fiabilidad y la facilidad de uso del mismo. As, la
prueba de aceptacin pretende comprobar que el software funciona de acuerdo con las
expectativas razonables del cliente, que debieron quedar recogidas en la Especificacin de
Requisitos del Software (lo deseable es que quedaran recogidos en un seccin ad-hoc
denominada Criterios de validacin).
Podemos decir entonces que la prueba de aceptacin est centrada en comprobar que se
satisfacen los requisitos de usuario. En realidad, la prueba intenta demostrar que no se cumplen
los requisitos, los criterios de aceptacin o el contrato. Si no se consigue demostrar esto el cliente
deber aceptar el producto y la prueba puede considerarse entonces como la fase final del
proceso de desarrollo software (que da paso a la de mantenimiento).
Las recomendaciones generales que pueden darse para la prueba de aceptacin son las
siguientes:
Se debe contar con la participacin activa del usuario, que debe ejecutar los casos de prueba
ayudado por miembros del equipo de pruebas.
Debemos disponer de criterios de aceptacin previamente aprobados por el usuario.
No hay que olvidar validar tambin la documentacin y los procedimientos de uso (por
ejemplo, mediante una auditora)
En el resultado de la prueba puede darse una de las dos condiciones siguientes:
Las caractersticas de funcionamiento o de rendimiento estn de acuerdo con las
especificaciones y son aceptables
Se descubre una desviacin de las especificaciones y se crea una lista de deficiencias. En
general, las desviaciones o errores descubiertos en esta fase del proyecto raramente se
pueden corregir antes de la terminacin planificada, por lo que a menudo es necesario
negociar con el cliente un mtodo para resolver las deficiencias


Pgina N
Es virtualmente imposible que un desarrollador de software pueda prever cmo utilizar el
usuario realmente el programa.
Se pueden malinterpretar las instrucciones de uso
Se pueden utilizar combinaciones de datos extraas
Una salida que puede parecer clara para el responsable de las pruebas puede ser ininteligible
para el usuario
En proyectos de desarrollo de software a medida, se llevan a cabo una serie de pruebas de
aceptacin que, idealmente, se deben realizar en el entorno en el que se utilizar el sistema (lo
que incluye al personal que lo maneja). Si se trata de un sistema contratado, la prueba se realiza
bajo control de la organizacin de desarrollo en el entorno real de trabajo, ayudando al usuario
(prueba alfa). Podemos decir por tanto que las pruebas alfa se llevan a cabo en un entorno
controlado.
En el caso de productos de inters general (por ejemplo, paquetes informticos), se entregan
versiones (versiones beta) a usuarios. Por tanto, la prueba beta es una aplicacin en vivo del
software en un entorno que no puede ser controlado por el desarrollador. El cliente registra
todos los problemas (reales o imaginarios) que encuentra durante la prueba beta e informa a
intervalos regulares al desarrollador. Para responder a los problemas encontrados durante la
prueba beta, el equipo de desarrollo introduce modificaciones que resultan en una nueva versin
del producto para todos los clientes.


Pgina N
La documentacin de las pruebas es necesaria, no slo para una buena organizacin de las mismas,
sino tambin para asegurar su reutilizacin y la eficacia y eficiencia del proceso de pruebas. En este
sentido, la figura muestra los distintos documentos de trabajo que deberan producirse o
manejarse segn el estndar IEEE 829-1998, que describe los tipos de documentos que pueden o
deben producirse durante el proceso de prueba.
El objetivo del Plan de Pruebas es sealar el enfoque, los recursos y el esquema de actividades de
prueba, as como los elementos a probar, las caractersticas, las actividades de prueba, el personal
responsable y los riesgos asociados.
En el fondo, si pensamos en las pruebas como un proceso independiente, podemos ver el Plan de
Pruebas como el Plan de Proyecto del proyecto de pruebas que especifica actividades, tiempos,
personal, recursos, riesgos, etc. para el desarrollo de las pruebas.
La estructura fijada por el estndar para dicho plan es la siguiente:
1. Identificador nico del documento (para gestin de la configuracin)
2. Introduccin y resumen de elementos y caractersticas a probar
3. Elementos software a probar (programas o mdulos)
4. Caractersticas a probar
5. Caractersticas que no se probarn
6. Enfoque general de la prueba (actividades, tcnicas, herramientas, etc.)
7. Criterios de paso/fallo para cada elemento
8. Criterios de suspensin y requisitos de reanudacin
9. Documentos a entregar (al menos los descritos en el estndar)
10. Actividades de preparacin y ejecucin de pruebas
11. Necesidades de entorno
12. Responsabilidades en la organizacin y realizacin de las pruebas
13. Necesidades de personal y formacin
14. Esquema de tiempos (tiempos estimados, hitos, etc.)
15. Riesgos asumidos por el plan y planes de contingencias para cada riesgo
16. Aprobaciones y firmas con nombre y puesto desempeado

Pgina N
El objetivo de la Especificacin del Diseo de Pruebas es especificar los refinamientos necesarios
sobre el enfoque general reflejado en el plan e identificar las caractersticas que se deben probar
con este diseo de pruebas.
Podemos ver este documento como una forma de describir la estrategia concreta que seguiremos
para un conjunto de caractersticas particular y la forma en que pondremos en puesta cada
tcnica.
La estructura fijada por el estndar para dicho documento es la siguiente:
Identificador nico para la especificacin. Proporcionar tambin una referencia del plan
asociado (si existe)
Caractersticas a probar de los elementos software (y combinaciones de caractersticas)
Detalles sobre el plan de pruebas del que surge este diseo, incluyendo las tcnicas de prueba
especfica y los mtodos de anlisis de resultados
Identificacin de cada prueba:
Identificador
Casos que se van a utilizar
Procedimientos que se van a seguir
Criterios de paso/fallo de la prueba (criterios para determinar si una caracterstica o
combinacin de caractersticas ha pasado con xito la prueba o no)

Pgina N
El objetivo de la Especificacin del Caso de Prueba es definir uno de los casos de prueba
identificado por una especificacin del diseo de las pruebas.
Identificador nico de la especificacin
Elementos software (por ejemplo, mdulos) que se van a probar: definir dichos elementos y
las caractersticas que ejercitar este caso
Especificaciones de cada entrada requerida para ejecutar el caso (incluyendo las relaciones
entre las diversas entradas; por ejemplo, la sincronizacin de las mismas)
Especificaciones de todas las salidas y las caractersticas requeridas (por ejemplo, el tiempo
respuesta) para los elementos que se van a probar
Necesidades de entorno (hardware, software y otras como, por ejemplo, el personal)
Requisitos especiales de procedimiento (o restricciones especiales en los procedimientos para
ejecutar este caso).
Dependencias entre casos (por ejemplo, listar los identificadores de los casos que se van a
ejecutar antes de este caso de prueba)

Pgina N
El objetivo de la Especificacin del Procedimiento de Prueba es especificar los pasos para la
ejecucin de un conjunto de casos de prueba o, ms generalmente, los pasos a seguir para
analizar un elemento software con el propsito de evaluar un conjunto de caractersticas del
mismo.
Identificador nico de la especificacin y referencia a la correspondiente especificacin de
diseo de prueba
Objetivo del procedimiento y lista de casos que se ejecutan con l
Requisitos especiales para la ejecucin (por ejemplo, entorno especial o personal especial)
Pasos en el procedimiento. Adems de la manera de registrar los resultados y los incidentes
de la ejecucin, se debe especificar:
La secuencia necesaria de acciones para preparar la ejecucin
Acciones necesarias para empezar la ejecucin
Acciones necesarias durante la ejecucin
Cmo se realizarn las medidas (por ejemplo, el tiempo de respuesta)
Acciones necesarias para suspender la prueba (cuando los acontecimientos no previstos
lo obliguen)
Puntos para reinicio de la ejecucin y acciones necesarias para el reinicio en estos puntos
Acciones necesarias para detener ordenadamente la ejecucin
Acciones necesarias para restaurar el entorno y dejarlo en la situacin existente antes de
las pruebas
Acciones necesarias para tratar los acontecimientos anmalos

Pgina N
Al igual que en el diseo de las pruebas la documentacin de la ejecucin es clave para asegurar
la eficacia en la deteccin y correccin de defectos y dejar constancia de los resultados de las
pruebas.
La figura muestra el conjunto de documentos que se relaciona directamente con la ejecucin de
las pruebas segn el estndar IEEE Std. 829.
El objetivo de Histrico de Pruebas (test log) es documentar todos los hechos relevantes
ocurridos durante la ejecucin de las pruebas.
Identificador
Descripcin de la prueba: elementos probados y entorno de la prueba
Anotacin de datos sobre cada hecho ocurrido (incluido el comienzo y el final de la prueba)
Fecha y hora
Identificador de informe de incidente
Otras informaciones

Pgina N
El objetivo del Informe de Incidente (test incident report) es documentar cada incidente (por
ejemplo, una interrupcin en las pruebas debido a un corte de electricidad, bloqueo del teclado,
etc.) ocurrido en la prueba y que requiera una posterior investigacin.
Identificador
Resumen del incidente
Descripcin de datos objetivos (fecha/hora, entradas, resultados esperados, etc)
Impacto que tendr sobre las pruebas

Pgina N
El objetivo del Informe Resumen (test summary report) es resumir los resultados de las
actividades de prueba (las sealadas en el propio informe) y aportar una evaluacin del software
basada en dichos resultados
Identificador
Resumen de la evaluacin de los elementos probados
Variaciones del software respecto a su especificacin de diseo, as como las variaciones en las
pruebas
Valoracin de la extensin de la prueba (cobertura lgica, funcional, de requisitos, etc.)
Resumen de los resultados obtenidos en las pruebas
Evaluacin de cada elemento software sometido a prueba (evaluacin general del software
incluyendo las limitaciones del mismo)
Firmas y aprobaciones de quienes deban supervisar el informe

Pgina N

Pgina N
Volvamos al proceso propuesto para las pruebas y veamos dnde encaja la DEPURACIN

Pgina N
La depuracin es el proceso de localizar, analizar y corregir los defectos que se sospecha que contiene el
software. Suele ser la consecuencia de una prueba con xito, es decir, cuando un caso de prueba descubre
un error, la depuracin es el proceso que provoca la eliminacin del error.
Aunque puede y debe ser un proceso ordenado, sigue teniendo mucho de arte: al evaluar los resultados de
una prueba, lo que el ingeniero se encuentra frecuentemente es slo una indicacin sintomtica de un
problema en el software, pero an hay que identificar ese problema, ya que la manifestacin externa del
error y la causa interna del mismo pueden no estar relacionados de una forma obvia. De hecho, el proceso
mental que conecta el sntoma con la causa es parte de la depuracin.
La Figura muestra una vista simplificada del proceso de prueba centrado en la depuracin: comienza con la
ejecucin de un caso de prueba. Se evalan los resultados y aparece una falta de correspondencia entre los
resultados esperados y los devueltos por la prueba. En muchos casos, los datos que no concuerdan son un
sntoma de una causa subyacente que todava permanece oculta. Estos datos se pasan entonces al proceso
de depuracin que intenta identificar las causas del error y corregir el defecto.
Si no lo consigue, se debern llevar a cabo nuevas pruebas que ayuden a localizarlo, reduciendo en cada
pasado el dominio de existencia del defecto. En caso de conseguirlo y haber corregido el defecto, se
efectuarn nuevas pruebas que comprueben si efectivamente se ha eliminado el problema.
Conviene tener en cuenta las implicaciones psicolgicas de la depuracin: es una de las actividades ms
frustrantes del desarrollo de software. Combina la necesidad de resolver un problema (un rompecabezas),
con la desagradable tarea de reconocer que se ha cometido un error. Dicho de otro modo, la depuracin es
una tarea extremadamente difcil ya que se enfrenta a la ansiedad provocada por no encontrar la solucin y
la natural tendencia a no aceptar la posibilidad de cometer errores. Afortunadamente, tambin se da un
gran alivio y disminuye la tensin cuando el error es finalmente corregido.
El resultado del proceso de depuracin puede ser:
(1) se encuentra la causa, se corrige y se elimina;
(2) no se encuentra la causa. En este caso, el responsable debe conjeturar una posible la causa, disear
un caso de prueba que ayude a confirmar dicha conjetura y repetir el ciclo.
Las dos etapas principales en el proceso de depuracin son la localizacin del error y la correccin del
mismo, siendo la primera la mas compleja. A continuacin damos algunas guas o consejos para facilitar la
actividad de localizacin.

Pgina N
Analizar la informacin y pensar. La depuracin es un proceso mental de resolucin de un
problema y lo mejor para el mismo es el anlisis. No se debe utilizar un enfoque aleatorio de
bsqueda del defecto.
Al llegar a un punto muerto, pasar a otra cosa. Refrescar la mente para empezar de nuevo o para
que el subconsciente nos termine por dar la solucin por si mismo. Alternativamente podemos
describir el problema a otra persona, el simple hecho de describir el problema a alguien puede
ayudarnos a descubrir muchas cosas.
Usar herramientas de depuracin slo como recurso secundario. Deben ayudar al anlisis mental
pero no sustituirlo.
No experimentar cambiando el programa. Debemos evitar depurar con esa actitud que
podramos resumir como no s qu est mal, as que cambiar esto y ver lo que sucede
Se deben atacar los errores individualmente, de uno en uno, si no queremos complicar an ms el
proceso de depuracin.
Adems, debemos fijar la atencin tambin en los datos que maneja el programa y no slo en la
lgica que implementa.

Pgina N
Respecto a la correccin del error
Donde hay un defecto, suele haber ms. Esta es una conclusin obtenida de la experiencia:
cuando corrijamos un error debemos examinar el cdigo y los mdulos prximos buscando
otros elementos sospechosos.
Debe fijarse el defecto, no sus sntomas. Es decir, el objetivo es corregir y hacer desaparecer el
defecto que provoca los sntomas, no enmascarar dichos sntomas. Por ejemplo, una mala
prctica relativamente habitual es controlar ciertas entradas que sabemos que provocan
resultados equivocados y enmascararlas produciendo artificialmente el resultado esperado.
La probabilidad de corregir completamente un defecto no es del 100% (de hecho ronda el 50%
segn los expertos). Por tanto se deben revisar las correcciones antes de implantarlas (mediante
tcnicas de revisin: walkthroughs, inspecciones, revisiones, etc. antes de la correccin). Despus
de la correccin debemos realizar pruebas especficas que comprueben, no slo que la correccin
ha cumplido con su objetivo, sino tambin que no se han introducido nuevos defectos. En
resumen: cuidado con crear nuevos defectos (al corregir defectos se producen otros nuevos)
En este sentido, Van Vleck (1989) sugiere tres preguntas sencillas antes de hacer la correccin:
Se repite la causa del error en otra parte del programa?
Cul es el siguiente error que se podr presentar a raz de la correccin que hoy voy a
realizar?
Qu podramos haber hecho para prevenir este error la primera vez?
La correccin debe situarnos temporalmente en la fase de diseo. Tenemos que mentalizarnos de
que la correccin implica re-disear y no slo modificar el cdigo.

Pgina N

Pgina N
La OO introduce nuevos aspectos y la naturaleza de los programas OO cambian las estrategias y tcticas de prueba.
Conceptos como la reutilizacin, la abstraccin o la encapsulacin influyen directamente en todos los aspectos del
desarrollo software y en particular en el proceso de pruebas. Por ejemplo, uno de los problemas que plantea la OO en el
contexto de las pruebas es el tratamiento de la herencia. Las dificultades proceden del hecho de que la prueba de un
mtodo, que es heredado en clases inferiores, suponga probar no slo el mtodo genrico sino tambin todas las
implementaciones en las clases hijas y en todo el rbol de herencia que genera. Otro ejemplo es el polimorfismo, que
interviene para complicar las pruebas, ya que nos obliga a generar casos de prueba adicionales para cada implementacin
adems de los que se heredan o solapan con los de la prueba en las clases madre.
Por otro lado, la construccin del software orientado a objetos comienza con la creacin de los modelos de anlisis y
diseo. Debido a la naturaleza evolutiva del paradigma de ingeniera de software OO, estos modelos comienzan como
representaciones, relativamente informales, de los requisitos del sistema, y evolucionan hacia modelos detallados de
clases, conexiones y relaciones de clases, el diseo del sistema y el diseo de objetos. En cada etapa, los modelos pueden
probarse, en un intento de descubrir errores, antes de su propagacin a la siguiente iteracin. As, la definicin de
pruebas para sistemas OO debe ser ampliada para incluir tcnicas que descubran errores (revisiones tcnicas formales) en
los modelos de Anlisis y Diseo y evalen la integridad, completitud y consistencia de dichos modelos.
Igualmente, la arquitectura de software OO se basa en una serie de subsistemas organizados por capas, que encapsulan
clases que colaboran entre s. Por lo tanto es necesario definir pruebas para los diferentes niveles del sistema, en un
esfuerzo por descubrir los errores que aparecen cuando las clases colaboran y los subsistemas se comunican a travs de
las distintas capas arquitectnicas.
Finalmente, recordemos que la estrategia clsica para la prueba de software comienza con probar lo pequeo y
funciona hacia fuera haciendo probar lo grande. Se comienza con las pruebas de unidad, despus se progresa hacia las
pruebas de integracin y se culmina con las pruebas de validacin del sistema. En aplicaciones convencionales, las
pruebas de unidad se centran en las unidades de programa compilables ms pequeas - el subprograma (por ejemplo,
mdulo, subrutina, procedimiento, componente). Una vez que cada una de estas unidades han sido probadas
individualmente, se integran en una estructura de programa, mientras que se ejecutan una serie de pruebas de regresin
para descubrir errores, debidos a las interfaces entre los mdulos y los efectos colaterales producidos por aadir nuevas
unidades. Por ltimo, el sistema se comprueba como un todo para asegurarse de que se descubren los errores en
requisitos.
Cuando se considera el software orientado a objetos, el concepto de unidad cambia. La encapsulacin conduce a la
definicin de clases y objetos. Esto significa que cada clase y cada instancia de una clase (objeto), envuelven atributos
(datos) y operaciones (tambin conocidos como mtodos o servicios), que manipulan estos datos. En vez de probar un
mdulo individual, la unidad ms pequea comprobable es la clase u objeto encapsulado. Ya que una clase puede
contener un nmero de operaciones diferentes, y una operacin particular debe existir como parte de un nmero de
clases diferentes, el significado de la unidad de prueba cambia drsticamente.
En resumen, las estrategias y tcticas de prueba deben tener en cuenta las caractersticas propias del software OO.

Pgina N
Durante el anlisis y diseo, la exactitud semntica debe juzgarse basada en la conformidad del modelo con
el dominio del problema en el mundo real. Si el modelo refleja con exactitud el mundo real (al nivel de
detalle apropiado a la etapa de desarrollo en la que se revisa el modelo), entonces es semnticamente
correcto. Para determinar si el modelo en realidad refleja el mundo real, debe presentarse a expertos en el
dominio del problema, quienes examinarn las definiciones de las clases y sus jerarquas, para detectar
omisiones o ambigedades. Las relaciones entre clases (conexiones de instancia) se evalan para determinar
si reflejan con exactitud conexiones del mundo real'.
La notacin y sintaxis que se utiliza para representar los modelos de anlisis y diseo se corresponder con
el mtodo especfico de anlisis y diseo, elegido para el proyecto. Por consiguiente, la exactitud sintctica
se juzga en el uso apropiado de la simbologa; cada modelo se revisa para asegurarse de que se han
mantenido las convenciones propias del modelado. Por ejemplo, deberemos comprobar si el modelo incluye
todas las partes necesarias para su correcta definicin (nombre de los mtodos, tipos de datos,
parmetros..).
La consistencia de los modelos de anlisis y diseo debe juzgarse considerando las relaciones entre
entidades dentro del modelo. Un modelo inconsistente tiene representaciones en una parte, que no se
reflejan correctamente en otras partes del modelo. Por ejemplo, debemos comprobar los diferentes
modelos de anlisis son consistentes entre si, pero tambin que lo son con los modelos de diseo. El diseo
de sistema se revisa examinando el modelo objeto-comportamiento desarrollado durante el anlisis y la
correspondencia necesaria del comportamiento del sistema, frente a los subsistemas diseados para lograr
este comportamiento.

Pgina N
Al tratar con software OO cambia el concepto de unidad. El encapsulamiento dirige la definicin de clases y
objetos. Esto significa que cada clase e instancia de clase (objeto) empaqueta los atributos (datos) y las
operaciones (tambin conocidas como mtodos o servicios) que manipulan estos datos. Por lo tanto, en vez
de mdulos individuales, la menor unidad a probar es la clase u objeto encapsulado. Una clase puede
contener un cierto nmero de operaciones, y una operacin particular puede existir como parte de un
nmero de clases diferentes. Por tanto, el significado de la prueba de unidad cambia ampliamente respecto
al concepto general visto antes.
No se puede probar ms de una operacin a la vez (la visin convencional de la unidad de prueba), pero s
como parte de una clase. Para ilustrar esto, considrese una jerarqua.de clases, en la cual la operacin X se
define para la superclase y se hereda por algunas subclases. Cada subclase utiliza la operacin X, pero se
aplica en el contexto de los atributos y operaciones privadas que han sido definidas para la subclase. Ya que
el contexto en el que la operacin X se utiliza vara de manera sutil, es necesario para probar la operacin X
en el contexto de estas subclases. Esto significa que probar la operacin X en vaco (la aproximacin de la
prueba de unidades tradicionales) no tiene sentido en el contexto orientado a objetos
De esta manera, la prueba de clases para el software OO es el equivalente a la prueba de unidad para
software convencional. A diferencia de la prueba de unidad del software convencional, la cual tiende a
centrarse en el detalle algortmico de un mdulo y los datos que fluyen a lo largo de la interfaz de ste, la
prueba de clases para software OO est dirigida por las operaciones encapsuladas en la clase y el estado del
comportamiento de la clase. As, la prueba de una clase debe haber probado mediante las correspondientes
tcnicas de caja blanca y caja negra el funcionamiento de cada uno de los mtodos de dicha clase. Adems,
se deben haber generado casos de prueba para probar valores representativos de los atributos de dicha
clase (esto puede realizarse aplicando la tcnica de clases de equivalencia y anlisis de valores lmite)


Pgina N
Debido a que el software OO no tiene una estructura de control jerrquica, las estrategias convencionales de
integracin ascendente y descendente poseen un significado poco relevante en este contexto.
Generalmente se pueden encontrar dos estrategias diferentes de pruebas de integracin en sistemas OO.
La primera, prueba basada en hilos (o threads), integra el conjunto de clases necesario para responder a una
entrada o evento del sistema. Cada hilo se integra y prueba individualmente.
El segundo enfoque para la integracin, prueba basada en el uso, comienza la construccin del sistema
integrando y probando aquellas clases (llamadas clases independientes) que usan muy pocas de las dems
clases. Despus de probar las clases independientes, se comprueba la prxima capa de clases, llamadas
clases dependientes, que usan las clases independientes. Esta secuencia de capas de pruebas de clases
dependientes contina hasta construir el sistema por completo.
A diferencia de la integracin convencional, el uso de drivers y stubs debe evitarse siempre que sea posible
Ntese cmo la prueba basada en hilos proporciona una estrategia ms ordenada para realizar la prueba
que la prueba basada en el uso.
Esta prueba basada en hilos, suele aplicarse utilizando los diagramas de secuencia de objetos que disean
cada evento de entrada al sistema. Concretamente, se pueden realizar los siguientes pasos para generar
casos de prueba a partir de un diagrama de secuencias:
1.Definir el conjunto de secuencias de mensajes a partir del diagrama de secuencia. Cada secuencia ha
de comenzar con un mensaje m sin predecesor (habitualmente, un mensaje enviado al sistema por un
actor), y estar formada por el conjunto de mensajes cuya ejecucin dispara m
2. Analizar sub-secuencias de mensajes a partir de posibles caminos condicionales en los diagramas de
secuencia.
3.Identificar los casos de prueba que se han de introducir al sistema para que se ejecuten las secuencias
de mensajes anteriores, en funcin de los mtodos y las clases afectadas por la secuencia. Tanto valores
vlidos como invlidos deberan considerarse.
De esta forma, resulta evidente que el conjunto de casos de prueba puede aumentar exponencialmente si se
trabaja con un sistema OO con un nmero elevado de interacciones. Por lo tanto, es necesario tener en
cuenta este factor a la hora de realizar el diseo


Pgina N
La figura muestra un diagrama de secuencia que podramos utilizar para definir una secuencia de integracin
concreta: partiramos de la clase IU_Solicitud_de_Pago, para pasar a las clases de control
Procesamiento_de_Solicitudes_de_Pago y Procesamiento_de_Facturas, etc.

Pgina N
En este nivel de prueba, los detalles de las conexiones entre clases no afectan. El software debe
integrarse con los componentes hardware correspondientes y se ha de comprobar que el sistema
completo funciona de acuerdo a los requisitos.
Por tanto, como en el caso del software convencional, la validacin del software OO se centra
en las acciones visibles del usuario y las salidas del sistema reconocibles por ste.
Para asistir en la identificacin de casos de prueba debemos basarnos en los casos de uso que
forman parte del modelo de anlisis. La utilizacin de los casos de uso eleva la probabilidad de
detectar errores encubiertos en los requisitos de interaccin del cliente.
En general, los mtodos convencionales de prueba de caja negra son los que se utilizan para
desarrollar estas pruebas.

Pgina N

Pgina N
Una vez que tenemos una idea general de las diferencias entre las pruebas en sistemas
convencionales (o estructurados) y sistemas orientados a objetos, vamos a concretar un poco ms
estas ideas, mostrando cmo podemos disear casos de prueba para sistemas Orientados a
Objetos.
A diferencia del diseo de pruebas convencional, que se conduce mediante una visin entrada-
proceso-salida, o el detalle algortmico de los mdulos individuales, la prueba orientada a objetos
se enfoca en las secuencias de operaciones de diseo apropiadas para probar los estados de una
clase.
Por lo tanto, aunque los mtodos de diseo de casos de prueba para software orientado a objetos
continan evolucionando, una aproximacin global al diseo de casos de prueba OO sera la
siguiente:
Cada caso de prueba debe ser identificado separadamente, y explcitamente asociado con la clase o
clases a probar.
Debe declararse el propsito de la prueba.
Debe desarrollarse una lista de pasos a seguir, como consecuencia de la prueba, pero adems debe
contener:
definicin de una lista de estados, especficos para la clase o clases a probar.
una lista de mensajes y operaciones, que se ejercitarn como consecuencia de las pruebas.
una lista de excepciones, que pueden ocurrir conforme se ejecuta la prueba.
una lista de condiciones externas (por ejemplo, otros sistemas software o hardware con quien
interacta el sistema) que debe existir para conducir apropiadamente las pruebas.
informacin adicional, que ayudar a la comprensin e implementacin de la prueba.

Pgina N
A continuacin daremos una vista general de los principales mtodos para el diseo de casos de
prueba, que se dividen en mtodos para clases y mtodos para probar la interaccin entre clases
(o interclases)
En primer lugar, ya hemos mencionado varias veces que la prueba de software comienza en lo
pequeo y lentamente progresa hacia lo grande. En el contexto de la OO la prueba en
pequeo, se enfoca en una sola clase y los mtodos que encapsula. Algunos de los mtodos
para el diseo de pruebas de clase son la verificacin al azar y la particin. Esta ltima da lugar a
varios sub-tipos en funcin del criterio utilizado para definir la particin.
Por otro lado, el diseo de casos de prueba se vuelve ms complicado cuando comienza la
integracin. Es en esta etapa donde hay que verificar las colaboraciones entre clases. Al igual que
para la verificacin de clases individuales, existen mtodos de verificacin de colaboraciones de
clases (o interclases). Adems de la verificacin al azar (basada en escenarios) y la particin,
podemos seguir una aproximacin basada en el comportamiento para disear las pruebas
interclases.


Pgina N
A manera de ejemplo, considrese una aplicacin bancaria en la cual una clase Cuenta contiene las
siguientes operaciones: abrir, configurar, ingresar, retirar, saldo, movimientos, limite y cerrar. Ntese que la
naturaleza del problema implica algunas limitaciones. Por ejemplo, la cuenta debe ser abierta antes de que
se puedan realizar otras operaciones y cerrada despus de que todas las operaciones hayan sido
completadas. An con estas limitaciones, existen muchas combinaciones vlidas de operaciones.
Como poco, durante la vida de un objeto Cuenta, suelen darse las siguientes operaciones: abrir()
configurar() ingresar() retirar() cerrar().
La secuencia anterior representa la mnima secuencia de operaciones que deberamos probar para probar la
clase cuenta. An respetando esta secuencia, existen infinitas posibilidades. Cualquiera combinacin
producida aleatoriamente a partir de la siguiente (meta)secuencia es vlida:
abrir() configurar() ingresar() - [ingresar() / retirar() / consultarSaldo() / consultarMovimientos() /
consultarLimite() ]
n
retirar() cerrar()
Por ejemplo, las siguientes secuencias son igualmente vlidas:
Prueba r1: abrir() - configurar() - ingresar() - consultarSaldo() - consultarMovimientos() - retirar() -
cerrar().
Prueba r2: abrir() - configurar() - ingresar() - retirar() - ingresar() - consultarSaldo() - consultarLimite() -
retirar() - cerrar()
As, la idea sera disear casos de prueba para ejecutar estas y/o otras secuencias de prueba generadas
aleatoriamente.

Pgina N
La prueba de particin reduce el nmero de casos de prueba requeridos para validar la clase, de forma
anloga a la particin equivalente que vimos para software convencional o estructurado. Las entradas y
salidas se clasifican en categoras (particin) y los casos de prueba se disean para validar cada categora.
Pero cmo identificamos las diferentes categoras?
La particin basada en estados clasifica las operaciones de la clase en funcin de su habilidad de
cambiar el estado de la clase. Por ejemplo, para la clase Cuenta, las operaciones de estado seran
ingresar() y retirar(), mientras que las operaciones de no-estado seran consultarSaldo(),
consultarMovimientos() y consutlarLimite(). La idea es disear las pruebas de manera que las
operaciones que cambian el estado, y aquellas que no lo cambian, se ejerciten separadamente. As:
Prueba p1: abrir() configurar() ingresar() ingresar() - retirar() - retirar() - cerrar().
Prueba p2: abrir() - configurar() - ingresar() consultarMovimientos() consultarSaldo() -
consultarLimite() - retirar() - cerrar().
La prueba p1 cambia el estado, mientras que la prueba p2 ejercita las operaciones que no cambian
el estado (aunque incluye las operaciones necesarias de la secuencia mnima de prueba, que
obviamente si cambian el estado del objeto).
La particin basada en atributos clasifica las operaciones de la clase en funcin de los atributos que
utilizan.
Para la clase cuenta, los atributos saldo y lmite pueden usarse para definir particiones.
De esta manera las operaciones se dividen en tres particiones:
(1) Operaciones que utilizan limite
(2) operaciones que lo modifican
(3) operaciones que no utilizan o modifican lmite
Las secuencias de prueba se disean entonces para cada particin.
Finalmente, la particin basada en categoras clasifica las operaciones de la clase de acuerdo a la
funcin genrica que cada una lleva a cabo. Por ejemplo, las operaciones de la clase cuenta pueden
clasificarse en operaciones de inicializacin (abrir() y configurar()), operaciones computacionales
(ingresar() y retirar()), consultas (consultarSaldo(), consultarMovimientos() y consultarLimite()) y
operaciones de terminacin (cerrar())

Pgina N
Tengamos en mente que nuestro objetivo ahora es verificar las colaboraciones entre las clases.
En primer lugar, as como la verificacin de clases individuales, la verificacin de colaboraciones de clases
puede completarse aplicando mtodos de verificacin al azar y metodos de particin. En realidad a la
primera se le suele denominar basada en escenarios, pero es una combinacin de aleatoriedad y uso de
escenarios.
La idea se recoge en la diapositiva.

Pgina N
Veamos un ejemplo para la clase Banco en el sistema del cajero.
Una secuencia vlida para dicha clase sera

Un caso aleatorio, conforme a dicha secuencia podra ser:

Para ejecutar las operaciones de dicha secuencia, la clase Banco tiene que colaborar con las clases
ValidationInfo (para las operaciones verifyAcct y verifyPin) y Cuenta (para la operacin depositReq
Por tanto, un nuevo caso de prueba que ejercite estas colaboraciones sera:

A continuacin, podramos estudiar cuales son las clases y operaciones invocadas por
ValidationInfo y Account para ejecutar estas operaciones y generar un nuevo caso de prueba, y
as sucesivamente .

verifyAcctverifyPIN[[verifyPolicywithdrawReq]|depositReq|acctInfoREQ]
n
Caso p1 = verifyAcctverifyPINdepositReq
verifyAcctBank[validAcct
ValidationInfo
]verifyPINBank[validPin
ValidationInfo
]depositReq [deposit
Account
]

Pgina N
Respecto al diseo de pruebas interclases basado en la particin, la idea es identificar las diferentes
categoras en funcin de la interfaz de la clase.
De vuelta al ejemplo del cajero, los mtodos de la clase Banco podran dividirse entre aquellos que reciben
mensajes de la clase ATM y aquellos que reciben mensajes de la clase Cashier

Pgina N
En realidad, el diseo de pruebas basado en comportamiento se puede ver como una estrategia de prueba
de clases que puede extenderse para utilzarse interclases.
Los Diagramas de Transicin de Estados (DTE) sirven para representar el comportamiento dinmico de una
clase. En el contexto de las pruebas interclases, podemos utilizarlos para disear el conjunto de casos de
prueba que ejerciten dicho comportamiento dinmico (y el de las clases que colaboren con la clase).
Volviendo a la clase Cuenta que ya hemos visto, la figura muestra el DTE de dicha clase. Ntese que los
objetos de la clase Cuenta entregarn la mayor parte de su funcionalidad mientras el objeto est en el
estado Working acct.
El objetivo de la prueba basada en comportamiento es alcanzar una cobertura total de estados, es decir, las
secuencias de operaciones que ejercitaran los casos de prueba deben causar que los objetos transiten por
todos los estados posibles. La siguiente secuencia cumplira este objetivo:

Obsrvese que la secuencia coincide con la secuencia bsica que definimos como secuencia mnima cuando
veamos la verificacin al azar.
Se pueden derivar an ms casos de prueba para asegurarse de que todos los comportamientos para la clase
han sido adecuadamente ejercitados. Por ejemplo:

Finalmente, en situaciones en las que el comportamiento de la clases resulte en una colaboracin con una o
ms clases del sistema, se utilizan mltiples DTEs para registrar el flujo de comportamiento de todo el
sistema.

Pgina N
La prueba del software contabiliza el mayor porcentaje del esfuerzo tcnico del proceso de desarrollo de software.
Su objetivo es descubrir errores. Para conseguir este objetivo, se planifica y se ejecutan una serie de pasos: pruebas de
unidad, de integracin, de validacin y del sistema.
Las pruebas de unidad y de integracin se centran en la verificacin funcional de cada mdulo y en la incorporacin de los
mdulos en una estructura de programa. La prueba de validacin demuestra el seguimiento de los requisitos del software
y la prueba del sistema valida el software una vez que se ha incorporado en un sistema superior.
Cada nivel de prueba se lleva a cabo mediante una serie de tcnicas sistemticas de prueba que ayudan en el diseo de
casos de prueba. Con cada paso de prueba se ampla el nivel de abstraccin con el que se considera el software.
El principal objetivo del diseo de casos de prueba es obtener un conjunto de pruebas que tengan la mayor probabilidad
de descubrir los defectos del software. Para llevar a cabo este objetivo, se usan dos categoras diferentes de tcnicas de
diseo de casos de prueba: prueba de caja blanca y prueba de caja negra.
Las pruebas de caja blanca se centran en la estructura de control del programa. Se obtienen casos de prueba que
aseguren que durante la prueba se han ejecutado, por lo menos una vez, todas las sentencias del programa y que se
ejercitan todas las condiciones lgicas.
La prueba del camino bsico, una tcnica de caja blanca, hace uso de grafos de programa (o matrices de grafos) para
obtener el conjunto de pruebas linealmente independientes que aseguren la total cobertura. La prueba de condiciones y
del flujo de datos ejercita ms an la lgica del programa y la prueba de los bucles complementa a otras tcnicas de caja
blanca, proporcionando un procedimiento para ejercitar bucles de distintos grados de complejidad.
Por otro lado, la prueba de caja negra ampla el enfoque y se puede denominar prueba a gran escala. Las pruebas de
caja negra son diseadas para validar los requisitos funcionales sin fijarse en el funcionamiento interno de un programa.
Las tcnicas de prueba de caja negra se centran en el mbito de informacin de un programa, de forma que se
proporcione una cobertura completa de prueba.
La particin equivalente divide el campo de entrada en clases de datos que tienden a ejercitar determinadas
funciones del software. El anlisis de valores lmite prueba la habilidad del programa para manejar datos que se
encuentran en los lmites aceptables.
A diferencia de la prueba (una actividad sistemtica y planificada), la depuracin, que de por s implica una contradiccin
entre la bsqueda de una solucin y la admisin de un error, se puede considerar un arte. A partir de una indicacin
sintomtica de un problema, la actividad de depuracin debe rastrear y corregir la causa del error.
El objetivo global de la verificacin orientada a objetos -encontrar el mximo nmero de errores con un mnimo de
esfuerzo, es idntico al objetivo de prueba del software convencional. Pero la estrategia y tcticas difieren de modo
significativo. La visin de verificacin se ampla, para incluir la revisin de ambos modelos de diseo y de anlisis.
En resumen, el enfoque de prueba se aleja del componente procedimental (el mdulo) hacia la clase. Adems, ya que los
modelos de anlisis y diseo OO y el cdigo fuente resultante se acoplan semnticamente, la prueba (a manera de
revisiones tcnicas formales) comienza en estas actividades de ingeniera.

Pgina N

Pgina N

AIS Tema3 PruebasSoftware Materialapoyo

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

AIS Tema3 PruebasSoftware Materialapoyo

Transféré par

Droits d'auteur :

Formats disponibles

Ampliacin de Ingeniera del Software

Grado en Ingeniera Informtica

Vous aimerez peut-être aussi