CARRERA:

Ingeniera en Sistemas Computacionales

MATERIA:
Fundamentos del proceso de pruebas de software
PROFESOR:
Ing. Marn Gonzlez Eugenio Conrado
ALUMNO:
Martnez Lpez Luis !odrigo
TTULO
In"estigacin unidad #
$%&cnicas de prueba 'ue se utilizan en las empresas(
Fecha: 27/Mayo/2014
Propuesta de Procedimiento para realizar pruebas de Caja Blanca a las aplicaciones que se
desarrollan en lenguaje Python
Resumen
Uno de los mayores problemas que se afrontan en la esfera de la informtica es la calidad de
software. El proceso de pruebas al software (tambin conocido como beta testing) es uno de los
aspectos fundamentales para medir el estado de calidad de un sistema informtico e introducirlo
satisfactoriamente en el mercado mundial. El objetivo del presente trabajo de diploma, es elaborar
la propuesta de un procedimiento para realiar pruebas, aplicando el mtodo de !aja "lanca, a las
aplicaciones que se desarrollan con lenguaje #yt$on en el !entro de %esarrollo de la &acultad
'egional (ranma de la Universidad de las !iencias )nformticas.
En esta investigaci*n se $io un anlisis de las principales bibliograf+as especialiadas en el tema,
profundiando en los diferentes mtodos de pruebas que e,isten, fundamentalmente en las
tcnicas encaminadas a la revisi*n del c*digo fuente de un sistema informtico.
El trabajo propone un procedimiento para realiar pruebas de !aja "lanca a los sistemas que se
desarrollan en #yt$on. En el mismo se e,ponen las actividades a seguir por el (rupo de !alidad de
la &acultad 'egional (ranma, reflejando cada uno de los artefactos de entrada y salida que se
generan, indicando c*mo se utilian y se completan.
#ara confirmar la valide del trabajo realiado se aplic* el procedimiento al -istema de (esti*n de
)nformaci*n para la Empresa de .cueducto y .lcantarillado de (ranma. %e acuerdo a lo planteado
en la propuesta se realiaron sus actividades y se evidenciaron los resultados en cada uno de los
artefactos involucrados.
Palabras clave: .rtefactos, !entro de %esarrollo, !*digo &uente, (rupo de !alidad,
#rocedimiento, #ruebas de !aja "lanca.

Abstract
-oftware quality is one of t$e bigest issues in )nformatics. /$e process of software testing (also
0nown as beta testing) is a fundamental aspect to measure t$e quality state of an informatics
system so as to successfully introduce it into t$e mar0et. /$e objective of t$is researc$ is to present
a proposal of procedure to apply tests as t$e beta testing (1$ite "o,) met$od to software
developed in #yt$on language at t$e University of )nformatics -ciences %evelopment !enter from
(ranma 'egional &aculty.
/o conduct t$is researc$, an analysis of t$e main specialied publications on t$e topic was carried
out to deepen on t$e different testing met$ods available, mainly about t$e tec$niques to c$ec0 t$e
source code of software.
/$is researc$ proposes a procedure to conduct software testing to t$e systems developed using
#yt$on language. /$e main activities to follow by t$e 2uality (roup from t$e (ranma 'egional
&aculty s$ow t$e entry and e,it artifacts generated as well as indicate $ow t$ey are used and
complemented.
/$e procedure was applied to t$e )nformation 3anagement -ystem of t$e .queduct Enterprise in
(ranma so as to confirm t$e validity of t$e proposal. .ccording to w$at it is stated in t$e proposal,
all t$e activities were carried out and t$e results were evidenced in eac$ of t$e artifacts involved.

Keywords: artifacts, development center, source code, quality group, procedure, beta test.
duardo !alazar "art#nez: )ngeniero en !iencias )nformticas. #rofesor. &acultad 'egional
(ranma de la Universidad de las !iencias )nformticas.
4
Correo lectr$nico: esalaar5grm.uci.cu
% stado del Arte&
!on el crecimiento acelerado de las tecnolog+as y la informtica, la producci*n de software
desempe6a un papel importante, provocando a su ve una competencia en los sistemas, donde la
calidad es fundamental para conseguir rentabilidad en la producci*n. 7a necesidad de realiar
pruebas de calidad converge $acia el aseguramiento de la eficiencia del producto antes de salir al
mercado.
3uc$as empresas e,istentes dedicadas a la producci*n de software y gesti*n de la calidad, goan
de un alto prestigio y cuentan con sus propias estrategias de pruebas y $erramientas de apoyo.
8tras contratan a empresas e instituciones que se especialian en este proceso, entre ellas
podemos mencionar a 'reen!(A ((reen -oftware 2uality .ssurance), con la misi*n de contribuir
a la madure de las empresas e industrias mediante el uso de servicios espec+ficos de pruebas de
software e implementaci*n de sistemas de gesti*n de calidad, garantiando as+ procesos giles,
confiables y eficientes.
8tro ejemplo es la empresa !(! !&A (-oftware 2uality -ystem -..), que lleva acabo procesos de
pruebas tanto en sus propias instalaciones como en las de sus clientes, asegurando la reducci*n
de costes y el aumento de la calidad. #ara ofrecer un mejor servicio a sus clientes, la compa6+a $a
decidido organiar estos servicios de pruebas llevados a cabo en sus instalaciones bajo el nombre
de !)(*!+ el ,aboratorio de -esting de !(!&
En este caso la RCC! ('ed !olombiana de !alidad de -oftware), es un instrumento de gesti*n de
conocimiento fundamentado en un modelo de ingenier+a, que tiene como objetivo gestionar
programas de apoyo a la implementaci*n de modelos de software para fortalecer la industria
nacional.
/ambin al incremento de las tecnolog+as se vincula el desarrollo de aplicaciones, y en este caso
nos interesan a aquellas que son creadas con la meta de poder automatiar el proceso de pruebas
de c*digo que se realian sobre el software. %entro del almacn de programas con este objetivo
podemos encontrar las que estn relacionadas con las pruebas de !aja "lanca. . continuaci*n se
mencionan algunas de estas $erramientas.
.-est: Es el primer sistema automtico de b9squeda de errores en el c*digo de programaci*n para
programadores de :ava. Esta nueva tecnolog+a desarrollada por la empresa ParaSoft, utilia la
/est (eneration /ec$nolgy (/ecnolog+as de (eneraci*n de #ruebas) para analiar programas en
:ava. -e trata de una $erramienta que permite realiar anlisis de c*digo, pruebas unitarias
automticas y cobertura de c*digo, as+ como generaci*n dinmica de pruebas funcionales.
En el mbito de los anlisis dinmicos, .-est es capa de generar automticamente todas las
pruebas unitarias que sean necesarias, teniendo en cuenta los parmetros de cobertura de c*digo
e intentando encontrar pruebas que deriven en errores de ejecuci*n. (enera pruebas funcionales
filtradas por las acciones y los datos, incluyendo peticiones HTTP2 y JDBC3.

/nsure00: Es un entorno automatiado en una aplicaci*n de $erramientas de prueba !;!<< que
detecta errores dif+ciles de localiar= como corrupci*n de la memoria, asignaci*n de errores de
memoria, errores de iniciaci*n de variables, definici*n de conflictos entre variables, indicador de
errores, errores de biblioteca, errores l*gicos y errores en algoritmos. -in embargo tiene licencia la
cual $ay que pagar un monto significativo cada cierto per+odo de tiempo.
BullseyeCoverage: Es un analiador de c*digo de cobertura para ! << y ! que indica c*mo gran
parte del c*digo fuente se pone a prueba. #uede usar esta informaci*n para rpidamente centrar
su esfuero de ensayo y determinar las reas que necesitan ser revisadas. El c*digo cobertura de
anlisis es 9til durante la unidad de verificaci*n, integraci*n de pruebas y la liberaci*n final. #ermite
crear c*digo ms fiable y a$orrar tiempo. -in embargo la licencia se debe comprar cada cierto
per+odo de tiempo, seg9n el cliente determine, oscilando de >?? euros a @??? euros.
,1RA: Es una $erramienta de control de calidad que ofrece un potente c*digo fuente de pruebas y
anlisis para la validaci*n y verificaci*n de aplicaciones de software. Es importante cuando el
software informtico requiere ser fiable, robusto y libre de errores. -e trata de un potente y
plenamente integrado suite de $erramientas, que permite al software avanado de tcnicas de
anlisis que puedan aplicarse en las etapas claves del desarrollo del ciclo de vida. -in embargo
sus $erramientas no contienen la comprobaci*n de estndares de codificaci*n y para su empleo
$ay que comprarla a precios estimados.
,ogiscope -estChec2er: .plicaci*n para la representaci*n grfica de cobertura del c*digo fuente.
Eval9a el nivel de cobertura del c*digo, el usuario debe de comprar la licencia por per+odo de
tiempos, no realia evaluaciones al c*digo de ! -$arp y no cuenta con la verificaci*n de
estndares.
C"-00: Es una $erramienta para la medida de la complejidad para !;! <<, la misma es fcil de
utiliar para ambos lenguajes. /ambin el c*digo en ensamblador se puede medir con esta
$erramienta. !3/<< est destinado para organiaciones desarrolladoras de software que se
esfueran por un proceso de desarrollo productivo resultante en productos de alta calidad.
.yuda a estimar el mantenimiento general del c*digo base y a localiar fcilmente las partes
complejas de este. -e pueden evaluar por separadoA poniendo especial atenci*n a las pruebas, o
tal ve redise6ndolas. -e puede utiliar !3/<< tambin para medir la cantidad de c*digo que se
tieneA l+neas f+sicas, l+neas de comentarios, l+neas de programa, declaraciones. Es una $erramienta
que a pesar de sus caracter+sticas no es gratuita y la documentaci*n para su aprendiaje se
encuentra en otros idiomas e,ceptuando el castellano.
C-C00: !on esta $erramienta ocurre lo mismos inconvenientes que con !3/<<, aunque no se
debe de dejar de mencionar que /estwell !/!<< (/est .naliador de !obertura para ! y !<<) es
una $erramienta de cobertura c*digo;prueba potente y fcil de usar, la cual muestra las partes del
c*digo que $an sido ejecutadas (probadas). 7a $erramienta analia todos los niveles de cobertura
requeridos en proyectos Bcr+ticosB y ayuda a garantiar una mayor calidad del c*digo. /estwell
!/!<< puede utiliarse para obtener las certificaciones en la industria automotri, area y mdica.
Cisto el estudio y anlisis en el marco internacional de las empresas desarrolladoras de software y
gesti*n de la calidad, y ejemplos de aplicaciones e,istentes que se suelen emplear para garantiar
la mayor calidad posible de los sistemas sometindolos a procesos de pruebas, la idea de alcanar
una empresa o sistema que asegure la calidad en el desarrollo de software se $a venido
fortaleciendo en !uba de forma continua. E,isten empresas en el territorio que se inclinan $acia el
mismo objetivo, como C/-"A-, (Empresa de /ecnolog+as de la )nformaci*n y -ervicios
/elemticos .vanados) que se distingue entre las entidades cubanas por su e,celencia y
creciente proyecci*n $acia el mercado e,terno e interno, con una amplia diversidad de productos y
servicios integrales de alto valor agregado. Entre las principales l+neas de trabajo se destaca el
desarrollo de sistemas dirigidos a automatiar la gesti*n en empresas de todo tipo.
8tro ejemplo es A,B- (.lbet )ngenier+a y -istemas), cuyo origen y desarrollo se vincula
estrec$amente a la Universidad de !iencias )nformticas (U!)), modelo de universidad productiva
que agrupa una multitud de profesionales, tcnicos y estudiantes. Do podemos dejar de mencionar
que la U!) cuenta tambin con un !entro para la !ertificaci*n de la !alidad de -oftware
!.7)-8&/, unido al %epartamento de #roducci*n de -oftware. El centro cuenta con trabajos de
diploma investigativos que se $an realiado referentes a los temas sobre procedimientos generales
de pruebas de !aja "lanca y procesos de pruebas referidos al mtodo de !aja Degra. E,isten en
algunos proyectos productivos en la U!), la utiliaci*n de $erramientas que aplican diferentes
pruebas de !aja Degra, probando la funcionalidad del software y en la minor+a (prcticamente
ninguno) se aplica el mtodo de !aja "lanca de forma manual a un peque6o fragmento de c*digo.
El (rupo de !alidad de la &acultad 'egional de la U!) en (ranma, tambin participa en la
realiaci*n de pruebas de software, aplicando generalmente pruebas de !aja Degra y de !arga.
#or consiguiente e,iste la carencia de procedimientos de pruebas de !aja "lanca o empleo de
aplicaciones de apoyo que permitan la automatiaci*n de estos proceso en la universidad.
3 Calidad de !o4tware&
7a calidad de software es un problema actual que afecta tanto a los productores de software como
a los clientes. !on el aumento de la informatiaci*n a escala mundial la demanda de software
crece e,ponencialmente y los desarrolladores le $an brindado poco inters a la calidad de sus
productos. -ucede que muc$as veces los clientes reciben el software cuando se $an violado las
etapas de pruebas.
7a calidad del software puede definirse de muc$as maneras. Una de las ms limitadas, conocida
como "calidad pequea", define la calidad como la ausencia de defectos EFG. #ara evaluarla de esta
forma se emplean procedimientos estad+sticos a partir de las tendencias de aparici*n de fallas
durante la prueba de software.
"Existen estndares industriales que marcan aceptabilidad cuand se estima el n!mer de
de"ects residuales en #$#2 de"ects pr millar de l%neas de c&di' ( a!n mens$" E>G
")trs en"ques de calidad cnsideran di*erss "actres, entre ells la cn"iabilidad" EHG. E,iste una
larga tradici*n de estudio de la confiabilidad que se asocia estad+sticamente con el comportamiento
del software.
E,isten varias formas de definir la confiabilidad, en unos casos se considera tiempo de operaci*n y
en otros la variedad de usos propuestos. Una definici*n ms reciente, plantea queA "+a
cn"iabilidad es la prbabilidad de peraci&n exitsa de un pr'rama dad, en un inter*al de
tiemp, en un ambiente espec%"ic". EHG
8bteniendo la calidad requerida en el software, se logra reducir su n9mero de errores o eliminarlos
completamente, se alcana una mayor fiabilidad para las funciones que debe realiar el mismo,
mayor eficiencia e integridad de los datos as+ como fle,ibilidad y reusabilidad
"+a calidad de s"t,are es una acti*idad de prtecci&n que se aplica a l lar' de td el prces
de -n'enier%a del ."t,are$ Esta en'lba ls si'uientes aspects/" EHG
I Un enfoque de gesti*n de calidad.
I /ecnolog+a de )ngenier+a del -oftware efectiva (mtodos y $erramientas).
I 'evisiones tcnicas formales que se aplican durante el proceso del software.
I Una estrategia de prueba multiescala.
I El control de la documentaci*n del software y de los cambios realiados.
I Un procedimiento que asegure un ajuste a los estndares de desarrollo del software.
I 3ecanismos de medici*n y de generaci*n de informes.
"+a calidad debe ser especi"icada, plani"icada, administrada, medida ( certi"icada$ Est implica una
*isi&n inte'ral que arr0a la cmprbaci&n del s"t,are, cn el "in de l'rar un ma(r 'rad de
satis"acci&n ( cn"ian1a del cliente 2acia la r'ani1aci&n prductra de s"t,are$ Cnstitu(e
entnces las pruebas de ls s"t,are, tarea de alta priridad para las empresas prductras"$ EJG.
.naliando los concepto e,puesto sobre la calidad por varios autores y $aciendo una inclinaci*n
por este 9ltimo e,presado por #ressman gracias a que se considera como uno de los ms
completos y acordes al objeto de estudio, tambin cabe decir que la calidad es considerada una
disciplina integral y a la ve una cualidad indisoluble del software para su comprobaci*n, muy
ligada a las empresas productoras como tarea fundamental en sus procesos de pruebas.
5 Pruebas de !o4tware&
Unas de las v+as ms importantes para determinar el estado de la calidad de un producto de
software es el proceso de pruebas. Estas estn dirigidas a componentes del sistema en su
totalidad, con el objetivo de medir el grado en que cumple con los requerimientos. En ellas se usan
casos de prueba, especificados de forma estructurada mediante tcnicas. -us objetivos, mtodos y
tcnicas usadas se describen en el plan de prueba.
7a prueba es una actividad fundamental en muc$os procesos de desarrollo, incluyendo el del
software. Estas permiten detectar la presencia de errores que pudieran generar las entradas o
salidas de datos y comportamientos inapropiados durante su ejecuci*n. Un concepto ms
espec+fico dado por algunos desarrolladores de software esA
"Cualquier intent de demstrar que el s"t,are tiene prpiedades pr deba0 de la calidad
requerida"$ EKG.
%e acuerdo a la )EEE ELG el concepto de prueba se define comoA
"3na acti*idad en la cual un sistema cmpnente es e0ecutad ba0 cndicines espec%"icas, se
bser*an almacenan ls resultads ( se reali1a una e*aluaci&n de al'!n aspect del sistema
cmpnente". EMG.
8tro concepto importante a tomar en consideraci*n es el emitido por #ressman en su edici*n de
@MML, que plantea lo siguienteA
"+a prueba del s"t,are es un element cr%tic para la 'arant%a de calidad del s"t,are (
representa una re*isi&n de las especi"icacines, del dise ( de la cdi"icaci&n"$ EMG.
/eniendo en cuenta las definiciones anteriores se puede concluir que la prueba de software es una
actividad en la cual el sistema es ejecutado bajo condiciones espec+ficas para demostrar que no
tiene la madure necesaria para ser implantado. %entro de las actividades que se practican para
obtener un software con la madure necesaria estnA
I Revisiones: consiste en que cada integrante del equipo de desarrollo revisa el producto que
va generando.
I /nspeccionesA revisi*n de cada producto por parte de colegas.
I 6alidaciones: es el cliente quien revisa el producto para decir si cumple con sus
necesidades.
Esta definici*n implica que se considera una prueba e,itosa si se demuestran deficiencias en el
software. 7as fallas pueden ser en el c*digo o en el modelado, en dependencia del tipo de pruebas
que se le apliquen al software.
-e distinguen pruebas tcnicas y pruebas funcionales. 7as pruebas tcnicas son la responsabilidad
de los ingenieros de software que $an desarrollado el producto, pero estos ingenieros en ocasiones
deben $acerse cargo de las pruebas funcionales
En proyectos a gran escala las pruebas funcionales son la responsabilidad de un equipo de
pruebas, formado por uno o varios tcnicos, un coordinador de pruebas y un gestor de pruebas o
de calidad.
5&% Caracter#sticas generales de la strategia de Prueba&
.l aplicarles las pruebas al software se deben seguir un conjunto de estrategias para lograr que
estas se $agan en el menor tiempo posible y con la calidad requerida, adems de garantiar que
arrojen los resultados esperados.
%entro de las caracter+sticas generales de la estrategia de prueba se encuentran. EJG
@. 7a rueba comiena en el nivel de m*dulo y trabaja B$acia fueraB, $acia la integraci*n
completa del sistema completo.
J. En diferentes puntos es adecuada la utiliaci*n de tcnicas de prueba distintas.
N. 7a prueba la lleva a cabo el que desarrolla el software y para grandes proyectos, un grupo
de prueba independiente.
F. 7a prueba y la depuraci*n son actividades diferentes, pero la depuraci*n puede entrar en
cualquier estrategia de prueba.
Oay dos estrategias generales para la prueba de softwareA las estrategias de pruebas de
especificaci*n (Ca0a 4e'ra) y pruebas de c*digo (Ca0a Blanca).
7 "8todos de Pruebas&
E,isten diversos mtodos para realiar las pruebas de software, entre las ms importantes se
encuentran la prueba de !aja "lanca, prueba de !aja Degra y prueba de la Estructura de !ontrol.
El uso de la prueba de !aja "lanca es mejor para verificar que se recorran todos los caminos y
detectar un mayor n9mero de errores. 7a !aja Degra brinda la posibilidad de cubrir la mayor parte
de las combinaciones de entradas y lograr as+ un juego de pruebas ms efica.
7as pruebas mencionadas permiten probar cada una de las condiciones e,istentes en el programa,
identificar claramente las entradas, salidas y estudiar las relaciones que e,isten entre ellas,
permitiendo as+ ma,imiar la calidad de las pruebas y en dependencia del resultado se constar
con un sistema ms estable y confiable.

7&% Prueba de speci4icaci$n 9Caja :egra;&
Pruebas de Caja :egra: /ambin suelen ser llamadas funcionales y basadas en especificaciones.
En ellas se pretende e,aminar el programa en busca de que cuente con las funcionalidades que
debe tener y como lleva a cabo las mismas, analiando siempre los resultados que devuelve y
probando todas las entradas en sus valores vlidos e invlidos.
.l ejecutar las pruebas de !aja Degra se desarrollan casos de prueba reales para cada condici*n o
combinaci*n de condiciones y se analian los resultados que arroja el sistema para cada uno de
los casos. En esta estrategia se verifica el programa considerndolo una caja negra. 7as pruebas
no se $acen en base al c*digo, sino a la interfa. Do importa que se cubran todas las rutas dentro
del programa, lo importante es probar todas las entradas en sus valores vlidos e invlidos y lograr
que el sistema tenga una interfa amigable.
7&%&% ,imitaciones
7ograr una buena cobertura con pruebas de caja negra es un objetivo deseable= pero no suficiente
a todos los efectos. Un programa puede pasar con $olgura millones de pruebas de especificaci*n y
sin embargo tener defectos internos que surgen en el momento ms inoportuno
#or ejemplo, una computadora que contenga el virus CiernesP@N puede estar pasando pruebas de
caja negra durante a6os y a6os. -*lo falla si es viernes y es d+a @N= pero Qa quin se le iba a
ocurrir $acer esa pruebaR E@@G
7as pruebas de caja negra nos convencen de que un programa realiar bien sus funcionalidades
programadas, pero no de que $aga (adems) otras cosas menos aceptables.
7&3 Prueba de C$digo 9Caja Blanca;&
Pruebas de Caja Blanca: /ambin suelen ser llamadas estructurales o de cobertura l*gica. En
ellas se pretende investigar sobre la estructura interna del c*digo, e,ceptuando detalles referidos a
datos de entrada o salida, para probar la l*gica del programa desde el punto de vista algor+tmico.
'ealian un seguimiento del c*digo fuente seg9n se va ejecutando los casos de prueba,
determinndose de manera concreta las instrucciones, bloques, etc. que $an sido ejecutados por
los casos de prueba.
En las pruebas de !aja "lanca se desarrollan casos de prueba que producan la ejecuci*n de
cada posible ruta del programa o m*dulo, considerndose una ruta como una combinaci*n
espec+fica de condiciones manejadas por un programa.
Oay que se6alar que no todos los errores de software se pueden descubrir verificando todas las
rutas de un programa, $ay errores que se descubren al integrar unidades del sistema y pueden
e,istir errores que no tengan relaci*n con el c*digo espec+ficamente.
7&3&% Caracter#sticas de las pruebas de Caja Blanca&
En las pruebas de !aja "lanca, se pretende indagar sobre la estructura interna del c*digo,
omitiendo detalles referidos a datos de entrada o salida. -u objetivo principal es probar la l*gica del
programa desde el punto de vista algor+tmico.
Estas se basan en el dise6o de !asos de #rueba que usa la estructura de control del dise6o
procedimental para derivarlos. 3ediante las pruebas de !aja "lanca el ingeniero de software
puede obtener !asos de #rueba queA E@@G
I (aranticen que se ejerciten por lo menos una ve todos los caminos independientes de cada
m*dulo, programa o mtodo.
I Ejerciten todas las decisiones l*gicas en las vertientes verdadera y falsa.
I Ejecuten todos los bucles en sus l+mites operacionales.
I Ejerciten las estructuras internas de datos para asegurar su valide.
7as pruebas de !aja "lanca son consideradas entre las ms importantes que se aplican a los
sistemas, con la que se obtienen como resultados la disminuci*n en un gran porciento el n9mero
de errores e,istentes en el software y por ende una mayor calidad y confiabilidad en la codificaci*n
7&3&3 -ipos de pruebas de Caja Blanca&
1e estructura de datos locales:
-e centran en el estudio de las variables del programa. "usca que toda variable est declarada y
que no e,istan con el mismo nombre, ni declaradas local y globalmente, que $aya referencias a
todas las variables y para cada variable, analia su comportamiento en comparaciones.
1e cobertura l$gica:
I De Cbertura de .entencias/ !omprueba que todas las sentencias se ejecuten al menos una
ve.
I De Cbertura de Decisi&n/ Ejecuta casos de prueba de modo que cada decisi*n se pruebe al
menos una ve a Cerdadero (True) y otra a &also (False).
I De Cbertura de Cndici&n/ Ejecuta un caso de prueba a True y otro a False por cada
condici*n, teniendo en cuenta que una decisi*n puede estar formada por varias condiciones.
I De Cbertura de Cndici&n5Decisi&n/ -e realian las pruebas de cobertura de condici*n y las
de decisi*n a la ve.
I De Cndici&n 6!ltiple/ !ada decisi*n multicondici*n se traduce a una condici*n simple,
aplicando posteriormente la cobertura de decisi*n.
I De Cbertura de Camins/ -e escriben casos de prueba suficientes para que se ejecuten
todos los caminos de un programa. Entendindose camino como una secuencia de sentencias
encadenadas desde la entrada del programa $asta su salida. E@@G

7&3&5 Prueba del Camino B<sico&
"uscando una mejor comprensi*n de los contenidos, se $ace importante definir primeramente
algunos conceptos fundamentales
Camino: ".ecuencia de tdas las instruccines de un pr'rama de principi a "in"$ EJG Un camino
se puede definir como la ruta de secuencias que se siguen dentro del c*digo de fuente de un
programa, un ejemplo es, desde la entrada de valores al sistema $asta la devoluci*n de resultados
que arroja, respetando la estructura de c*digo.
Camino B<sico: Es una tcnica de prueba de !aja "lanca que permite obtener una medida de
complejidad l*gica para generar un conjunto bsico de caminos que se ejecutan por lo menos una
ve durante la ejecuci*n del programa. E@JG
7a prueba del camino bsico es una tcnica de pruebas de !aja "lanca propuesta por /om
3ac!abe. Esta tcnica permite obtener una medida de la complejidad l*gica de un dise6o y usar
esta medida como gu+a para la definici*n de un conjunto bsico. 7a idea es derivar casos de
prueba a partir de un conjunto dado de caminos independientes por los cuales puede circular el
flujo de control.
Camino independiente: "Es cualquier camin del pr'rama que inclu(e nue*as instruccines de
un prces una nue*a cndici&n". E@JG
El conjunto de caminos independientes se obtiene construyendo el (rafo de &lujo asociado y se
calcula su complejidad ciclomtica. #or 9ltimo se dise6an los casos de prueba y se ejecutan los
mismos.
Complejidad: Es proporcional al n9mero de errores en un segmento de c*digo. "Entre ms
cmple0, ms susceptible a errres"$ E@NG -e relaciona con el esfuero requerido para
probar. "Entre ms cmple0, ma(r atenci&n para prbar"$ E@NG
Complejidad ciclom<tica: Es la Bmedida de la cmple0idad l&'ica de un m&dul "7" ( el es"uer1
m%nim necesari para cali"icarl$ Es el n!mer de rutas lineales independientes de un m&dul "7",
pr l tant es el n!mer m%nim de rutas que deben prbarse"$ E@NG
Esta tcnica ofrece una gran ventaja con respecto a las otras tcnicas, ya que el n9mero m+nimo
requerido de pruebas se sabe por adelantado y por tanto el proceso de prueba se puede planear y
supervisar en mayor detalle.
7os pasos a seguir para aplicar esta tcnica sonA
@) 'epresentar el programa en un grafo de flujo.
J) !alcular la complejidad ciclomtica.
N) %eterminar el conjunto bsico de caminos independientes.
F) %erivar los casos de prueba que fueran la ejecuci*n de cada camino.
. continuaci*n, se detallan cada uno de estos pasos.
1) Representacin de un grafo de flujo:
El grafo de flujo se utilia para representar el flujo de control l*gico de un programa. Este emplea
los tres elementos siguientesA
I :odos: 'epresentan cero, una o varias sentencias en secuencia. !ada uno comprende
como m,imo una sentencia de decisi*n (bifurcaci*n).
I Aristas: 7+neas que unen dos nodos.
I Regiones: Sreas delimitadas por aristas y nodos. !uando se contabilian las regiones de un
programa debe incluirse el rea e,terna como una regi*n ms.
.s+, cada construcci*n l*gica de un programa tiene una representaci*n. 7a Figura 1 muestra un
grafo de flujo del diagrama de m*dulos correspondiente. D*tese c*mo la estructura principal
corresponde a un while y dentro del bucle se encuentran anidados dos constructores if. E@FG
Figura 1: Ejemplo de grafo de flujo correspondiente a un diagrama de mdulos.







) !alcular la complejidad ciclom"tica:
7a complejidad ciclomtica es una mtrica del software que proporciona una medida cuantitativa de
la complejidad l*gica de un programa. -e basa en la representaci*n grfica del flujo de control del
programa, el anlisis desprende una medida cuantitativa de la dificultad de prueba y una indicaci*n
de la fiabilidad final. !uando se utilia en el conte,to del mtodo de prueba del camino bsico, el
valor calculado como complejidad ciclomtica define el n9mero de pruebas que se deben realiar
para asegurar que se ejecute cada sentencia al menos una ve.
"8trica: "6edida estad%stica que se aplica a tds ls aspects de calidad de s"t,are, ls cuales
deben ser medids desde di"erentes punts de *ista"$ E@NG 7a mtrica se define como trmino para
valorar en una medida la calidad de software considerando diferentes puntos necesario a evaluar.
Es una de las mtricas de software ms ampliamente aceptada, ya que $a sido creada para ser
independiente del lenguaje. -e $an realiado investigaciones y ensayos, en los cuales se $a
medido un gran n9mero de programas, a modo de establecer rangos de complejidad que ayuden al
ingeniero de software a determinar la estabilidad y riesgo in$erente de un programa. 7a medida
resultante puede ser utiliada en el desarrollo, mantenimiento y reingenier+a para estimar el riesgo,
costo y estabilidad.
Estos estudios indicaron la e,istencia de distintas relaciones entre la mtrica de 3c!abe y el
n9mero de errores e,istentes en el c*digo fuente, as+ como el tiempo requerido para encontrar y
corregir esos errores. B.e puede cmparar la cmple0idad ciclmtica cntra un cn0unt de
*alres l%mites cm se bser*a en la Tabla 8". E@NG

Ta#la 1. !omplejidad ciclom"tica $s E$aluacin de riesgo.







El mbito ms com9n de utiliaci*n para probar m*dulos unitarios es la prueba estructural (!aja
"lanca). 3c!abe tambin e,pone que se puede utiliar la complejidad ciclomtica para dar una
indicaci*n cuantitativa del tama6o m,imo de un m*dulo. . partir del anlisis de muc$os proyectos
se encontr* que un valor @? es un l+mite superior prctico para el tama6o de un m*dulo.
!uando la complejidad supera este valor se $ace muy dif+cil probarlo, entenderlo y modificarlo. 7a
limitaci*n deliberada de la complejidad en todas las fases del desarrollo ayuda a evitar los
problemas asociados a proyectos de alta complejidad. El l+mite propuesto por 3c!abe sin embargo
es fuente de polmicas. .lgunas organiaciones $an utiliado el valor @> con bastante ,ito. Do
obstante, un valor superior a @? deber+a ser reservado para proyectos que tengan ventajas
operacionales con respecto a proyectos t+picos.
7a complejidad ciclomtica puede ser aplicada en varias reas incluyendoA E@>G
9nlisis de :ies' en desarrll de c&di'/ 3ientras el c*digo est en desarrollo, su
complejidad puede ser medida para estimar el riesgo in$erente.
9nlisis de ries' de cambi durante la "ase de mantenimient/ 7a complejidad del c*digo
tiende a incrementarse a medida que es mantenido durante el tiempo. 3idiendo la
complejidad antes y despus de un cambio propuesto, puede ayudar a decidir c*mo
minimiar el riesgo del cambio.
Plani"icaci&n de Pruebas/ El anlisis matemtico $a demostrado que la complejidad
ciclomtica indica el n9mero e,acto de casos de prueba necesarios para probar cada
punto de decisi*n en un programa.
:ein'enier%a/ #rovee conocimiento de la estructura del c*digo operacional de un sistema.
El riesgo involucrado en la reingenier+a de una piea de c*digo est relacionado con su
complejidad.
%Por &u' es tan importante(
#ermite apreciar la calidad del dise6o de software de una manera rpida y con independencia del
tama6o de la aplicaci*n. Es una medida esencial cuando se necesita "tmar la temperatura" de un
dise6o de software de un tama6o considerable (ms si se est realiando una auditor+a e,terna y
no se conoc+a de antes la aplicaci*n), y que se puede obtener fcilmente de manera automatiada.
/ambin se $a utiliado para planificar proyectos de mejora de grandes productos de software,
para prioriar las partes del dise6o.
#or otro lado, en muc$as ocasiones, es base para calcular el valor de las mejoras del dise6o, o el
valor que aporta introducir un patr*n o buena prctica. .dems, da el n9mero de casos de prueba
unitarios bsicos para obtener una cobertura del @?? porciento, y un apro,imado al grado de
comprensibilidad.
%!mo ser)a su c"lculo(
"Existen *arias "rmas de calcular la cmple0idad ciclmtica ;CC< de un pr'rama a partir de un
'ra" de "lu0/ E@FG
CC = arcs > nds ? 2
CC = n!mer de nds de decisi&n ? 8
CC = n!mer de re'ines"$
Esta complejidad ciclomtica determina el n9mero de casos de prueba que deben ejecutarse para
garantiar que todas las sentencias de un programa se $an ejecutado al menos una ve, y que
cada condici*n se $abr ejecutado en sus vertientes verdadera y falsa. . continuaci*n se e,pone
c*mo se identifican estos caminos.
*) +eterminar el conjunto de caminos #"sicos independientes:
Camino linealmente independiente de otros: )ntroduce por lo menos un nuevo conjunto de
sentencias de proceso o una nueva condici*n.
Un camino independiente es cualquier camino del programa que introduce, por lo menos, un nuevo
conjunto de sentencias de proceso o una condici*n, respecto a los caminos e,istentes. En trminos
del diagrama de flujo, un camino independiente est constituido por lo menos por una arista que no
$aya sido recorrida anteriormente a la definici*n del camino. En la identificaci*n de los distintos
caminos de un programa para probar se debe tener en cuenta que cada nuevo camino debe tener
el m+nimo n9mero de sentencias nuevas o condiciones nuevas respecto a los que ya e,isten. %e
esta manera se intenta que el proceso de depuraci*n sea ms sencillo.
El conjunto de caminos independientes de un grafo no es 9nico. Do obstante, a continuaci*n, se
muestran algunas $eur+sticas para identificar estos caminosA E@FG
Elegir un camino principal que represente una funci*n vlida que no sea un tratamiento de
error. %ebe intentar elegirse el camino que atraviese el m,imo n9mero de decisiones en
el grafo.
)dentificar el segundo camino mediante la localiaci*n de la primera decisi*n en el camino
de la l+nea bsica alternando su resultado mientras se mantiene el m,imo de n9mero de
decisiones originales del camino inicial.
)dentificar un tercer camino, colocando la primera decisi*n en su valor original a la ve que
se altera la segunda decisi*n del camino bsico, mientras se intenta mantener el resto de
decisiones originales.
!ontinuar el proceso $asta $aber conseguido tratar todas las decisiones, intentando
mantener como en su origen el resto de ellas.
=eur#stica: +a b!squeda a cie'as es aquella dnde n existe nin'una in"rmaci@n para decidir
que nd expandir, n se cnce la cantidad de pass el cst del camin desde el estad
actual 2asta el b0eti*$ TambiAn se denmina b!squeda n in"rmada$ En el tr cas, cuand
existe in"rmaci@n para decidir, la b!squeda se denmina in"rmada 2eur%stica. E@HG
Este mtodo permite obtener de la complejidad ciclomtica, caminos independientes cubriendo el
criterio de cobertura de decisi*n y sentencia.
#or ejemplo, para la el grafo de la Figura 1 los cuatro posibles caminos independientes generados
ser+anA
!amino @A @PM
!amino JA @PJPFPLP@PM
!amino NA @PJPNP>PKPLP@PM
!amino FA @PJPNPHPKPLP@PM
,) +eri$ar los casos de prue#a:
El 9ltimo paso es construir los casos de prueba que fueran la ejecuci*n de cada camino. Una
forma de representar el conjunto de casos de prueba ser+a llenar la "Tabla 8$2"$ E@FG que se
muestra a continuaci*n.

Ta#la 1.. Posi#le representacin de casos de prue#a para prue#as estructurales.




>& Plan de Pruebas&
"El prp&sit del plan de pruebas es de0ar de "rma expl%cita el alcance, el en"que, ls recurss
requerids, el calendari, ls respnsables ( el mane0 de ries's de un prces de pruebas"$ E@KG
Est constituido por un conjunto de pruebas. !ada prueba debeA

%ejar claro qu tipo de propiedades se quieren probar (correcci*n, robuste, fiabilidad,
amigabilidad, etc.).
%ejar claro c*mo se mide el resultado.
Especificar en qu consiste la prueba ($asta el 9ltimo detalle de c*mo se ejecuta).
%efinir cul es el resultado que se espera (identificaci*n, tolerancia,...). Q!*mo se decide
que el resultado es acorde con lo esperadoR
7as pruebas carecen de utilidad, tanto, s+ no se sabe e,actamente lo que se quiere probar, s+ no se
est claro c*mo se prueba, o si el anlisis del resultado se $ace a simple vista.
Estas mismas ideas se suelen agrupar diciendo que un caso de prueba consta de tres bloques de
informaci*nA
@. El prop*sito de la prueba.
J. 7os pasos de ejecuci*n de la prueba.
N. El resultado que se espera.
/odos y cada uno de esos puntos deben quedar perfectamente documentados. El plan de pruebas
se6ala el enfoque, los recursos y el esquema de actividades de prueba, as+ como los elementos a
probar, las caracter+sticas, las actividades de prueba, el personal responsable y los riesgos.
? l Proceso de Pruebas&
El proceso de pruebas de un software consta de varias etapas dentro de ellas las ms importantes
sonA

@. /nspecci$n del an<lisis: -e verifica si se cometieron errores o falla en la etapa de
anlisis.
J. /nspecci$n del dise@o: -e comprueba el dise6o y se trata de $allarle defectos.
N. /nspecci$n del c$digo: -e observa el entendimiento y facilidad del c*digo.
F. Pruebas unitarias: -e debe probar cada mtodo de las clases implementadas por
separado.
>. Pruebas de integraci$n: -e prueban todas las clases, verificando que compaginen entre
s+.
H. Pruebas de validaci$n de requerimientos: Calidan que se cumple con todos los
requerimientos e,igidos por el cliente.
K. Pruebas de sistema: Ejecutar el programa para verificar si cumple con los requisitos
e,igidos.

-.1 Prue#as de .nidad.
-e comprueban los m*dulos cada uno por separado, buscando errores en el funcionamiento de
ese m*dulo como sistema independiente. Estas pruebas deben ser $ec$as por el dise6ador y el
programador del m*dulo.
-. Prue#as de Sistema.
-u objetivo es la comprobaci*n del sistema global, se realian pruebas de tres tipos distintosA
!eguridad: protecci*n en aplicaciones especialmente sensibles a entradas no deseadas.
Resistencia: se prueba la robuste del sistema frente al mal uso de la aplicaci*n por parte
de ciertos usuarios.
Rendimiento: Eficiencia medida en velocidad de proceso y recursos consumidos.
-.* Prue#as de /ntegridad.
7as pruebas de integraci*n se llevan a cabo durante la construcci*n del sistema, involucran a un
n9mero creciente de m*dulos y terminan probando el sistema como conjunto. Estas pruebas se
pueden plantear desde un punto de vista estructural o funcional.
7as pruebas estructurales de integraci*n son similares a las pruebas de caja blanca= pero trabajan
a un nivel conceptual superior. En lugar de referirse a sentencias del lenguaje, se refiere a
llamadas entre m*dulos. -e trata de identificar todos los posibles esquemas de llamadas y
ejercitarlos para lograr una buena cobertura de segmentos o de ramas.
7as pruebas funcionales de integraci*n son similares a las pruebas de caja negra. .qu+ trataremos
de encontrar fallos en la respuesta de un m*dulo cuando su operaci*n depende de los servicios
prestados por otro(s) m*dulo(s). -eg9n nos vamos acercando al sistema total, estas pruebas se
van basando ms y ms en la especificaci*n de requisitos del usuario.
7as pruebas finales de integraci*n cubren todo el sistema y pretenden cubrir plenamente la
especificaci*n de requisitos del usuario. .dems, a estas alturas ya suele estar disponible el
manual de usuario, que tambin se utilia para realiar pruebas $asta lograr una cobertura
aceptable.
-., Prue#as de 0ceptacin.
El uso de cualquier producto de software tiene que estar justificado por las ventajas que ofrece. -in
embargo, antes de su puesta en marc$a es muy dif+cil determinar si sus ventajas realmente
justifican su uso. El mejor instrumento para esta determinaci*n es la llamada Bprueba de
aceptaci*nB. En esta prueba se eval9a el grado de calidad del software con relaci*n a todos los
aspectos relevantes para que el uso del producto se justifique.
Eliminar la influencia de conflictos de intereses, y para que sea lo ms objetiva posible, la prueba
de aceptaci*n no deber+a ser responsabilidad de los ingenieros de software que $an desarrollado
el producto.
En la preparaci*n, ejecuci*n y evaluaci*n de las pruebas de aceptaci*n no se requiere de
conocimientos informticos. -in embargo, un conocimiento amplio de mtodos y tcnicas de
prueba y de la gesti*n de la calidad en general facilita esta labor.
7a persona adecuada (o el equipo adecuado) para llevar a cabo la prueba de aceptaci*n disponen
de estos conocimientos y adems son capaces de interpretar los requerimientos especificados por
los futuros usuarios del sistema de software en cuesti*n.
Estas pruebas las realia el cliente. -on bsicamente pruebas funcionales sobre el sistema
completo, y buscan una cobertura de la especificaci*n de requisitos y del manual del usuario. Estas
pruebas no se realian durante el desarrollo, pues ser+a impresentable al cliente= sino que se
realian sobre el producto terminado e integrado o pudiera ser una versi*n del producto o una
iteraci*n funcional pactada previamente con el cliente.
7a e,periencia muestra que a9n despus del ms cuidadoso proceso de pruebas por parte del
desarrollador, quedan una serie de errores que s*lo aparecen cuando el cliente comiena a usarlo.
-ea como sea, el cliente siempre tiene ra*n. %ecir que los requisitos no estaban claros, o que el
manual es ambiguo puede salvar la cara= pero ciertamente no deja satisfec$o al cliente.
Una prueba de aceptaci*n puede ir desde un informal caso de prueba $asta la ejecuci*n
sistemtica de una serie de pruebas bien planificadas. %e $ec$o, las pruebas de aceptaci*n
pueden tener lugar a lo largo de semanas o meses, descubriendo as+ errores latentes o escondidos
que pueden ir degradando el funcionamiento del sistema. Estas pruebas son muy importantes, ya
que definen las nuevas fases del proyecto como el despliegue y mantenimiento.
-e emplean dos tcnicas para las pruebas de aceptaci*nA

1a prue#a alfa.
-e lleva a cabo, por un cliente, en el lugar de desarrollo y en un entorno controlado. -e usa el
software de forma natural con el desarrollador como observador del usuario. #ara que tengan
valide, se debe primero crear un ambiente con las mismas condiciones que se encontrarn en las
instalaciones del cliente. Una ve logrado esto, se procede a realiar las pruebas y a documentar
los resultados. ENG
1a prue#a #eta.
-e lleva a cabo por los usuarios finales del software y se realia en el entorno de los clientes. .
diferencia de la prueba alfa, el desarrollador no est presente normalmente. .s+, la prueba beta es
una evaluaci*n Ben tiempo realB del software en un entorno no planificado 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.
!omo resultado de los problemas informados durante la prueba beta, el desarrollador del software
lleva a cabo modificaciones y as+ prepara una versi*n del producto de software para todos los
cliente donde se despliegue el producto. ENG
A Blujo Actual de los Procesos&
El proceso de control de calidad antes, durante y despus de la implementaci*n de un producto de
software es una tarea bastante complicada incluso para los e,pertos en el tema, ya que nunca se
tiene la 9ltima palabra a cerca de estos factores y cada situaci*n que se presenta puede resultar
novedosa y problemtica simultneamente
En la &acultad 'egional de la Universidad de las !iencias )nformticas en (ranma (&'(PU!)) se
producen sistemas destinados al -ector de !ultura, en su mayor+a con dimensiones grandes y
compuestos por diferentes l+neas de trabajo como los -istemas de (esti*n de )nformaci*n,
'ealidad Cirtual y %esarrollo de .plicaciones para dispositivos m*viles.
El proceso de pruebas en estos sistemas se realia mensualmente por el (rupo de !alidad ((!)
de la &'(PU!), y una ve estn terminados los productos, el personal implementador tambin
forma parte de este proceso. 7as pruebas que se realian con mayor frecuencia son las #ruebas
de Estrs, #ruebas de &uncionalidades y a la %ocumentaci*n por lo general. El jefe del equipo de
prueba recibe todo el sistema y la documentaci*n a probar, por medios de la $erramienta de
control de versiones "aaar, y a medidas que se realian las revisiones, manualmente se van
conformando los registros de no conformidades guiado por una plantilla, estos 9ltimos los recibe el
l+der de proyecto para $acer cambios a favor de superar la calidad de la aplicaci*n y nuevamente
someterla a otra revisi*n, y as+ se repite el proceso $asta que el producto quede con el m+nimo
n9mero de errores posible.
7as pruebas de !aja "lanca todav+a no se comprenden dentro de las que se practican el (! a los
productos en desarrollo. !ada proyecto revisa el c*digo fuente usando la tcnica ms conveniente
o que mejor conoca, y los pocos que documentan los resultados de las pruebas no lo $acen
debidamente.
Conclusiones
7os conceptos principales sobre la calidad y pruebas de software logran describir aspectos
relacionados con los procesos de pruebas de sistemas identificando las estrategias de pruebas.
7as b9squedas de los tipos de pruebas ayudan a resumir sus caracter+sticas y a describir los flujos
actuales del proceso de calidad.

Re4erencias Bibliogr<4icas&
C%D. %).T Uanersy, 387)D. Uenisel. Dise de una aplicaci&n para el .e'uimient de
Errres de ls prducts s"t,are de la Bacultad C$ U!). J??K. !uidad de la Oabana.
C3D. '8(E' -. #ressmanA ."t,are En'ineerin'/ 9 PractitinerDs 9pprac2 (European
.daptation), 3c(rawOill. J???. )-"DA ??KK?MHKK?.
C5D& 3.'2UET .7#)T.' Uaim+, C.7%ET OE!O.C.''). Uenni. Prcedimient 7eneral
de Pruebas de Ca0a Blanca aplicand la tAcnica de Camin Bsic. U!), J??K. !uidad de
7a Oabana. !ap. @. J?, J@ p.
C7D& V.D, -.O. @MM>A 6etrics and mdels in s"t,are qualit( en'ineerin', .ddison1esley,
'eading, 3a., U-., @MM>.
C>D. U.3.U'., /suneo @MMLA H, t desi'n practical test cases, )EEE -oftware. Col. @>,
nH, november;december @MML, pp N?NH.
C?D. 3EUE', ". @MMKA )b0ect riented s"t,are cnstructin, Jnd. %e., Upper -addle 'iver,
#rentice Oall, @MMK.
CAD. !)(W7."-. T2e Hme " 7rundbreaEin' ."t,are Fualit( 3anagement 'esearc$,
Een l+neaG. Econsultado @?;?J;J?@JG.
%isponibleA www.cigitallabs.com;reso;definitions;softwareWtesting.$tml.
CED. )EEE -td @MM>, 6etrics, )EEE, @MM@.
CFD. '8(E' -. #ressman, '. Can -nternetbased 9pplicatins Be En'ineeredG in )EEE
-oftware, -eptember;8ctober )EEE #ress, @?F@@?, @MML.
C%GD. &E'D.D%ET #EX. :. 3. )#D 3,ico. Pruebas de inte'raci&n para cmpnentes de
s"t,are, 3aro J??J.
C%%D. %.').- #E'ET %arling, 9nlisis ( Dise de Cmpnentes para Pruebas de Ca0a
Blanca. U!), J??L. !uidad de 7a Oabana, !ap. @. @F, @> p.
C%3D. #878 U-.87., %r. 3acario. Curs de dctrad sbre Prces s"t,are ( 'esti&n
del cncimient. #ruebas del -oftware. %epartamento de /ecnolog+as y -istemas de
)nformaci*n. !iudad 'eal. J??H. (J??L). FH p.
C%5D. /. :. 3c!abe, .tructured testin'/ a testin' met2dl'( t2e c(clmatic cmplexit(
metric, /ec$nical 'eport D)-/ >??PJJ>, @MMH.