Vicerrectoría Académica IP – CFT

Dirección de Desarrollo Curricular

ASEGURAMIENTO DE LA CALIDAD
Documento: Técnicas de Análisis

1. ANÁLISIS DE ALGORITMOS
La calidad de un programa requiere esencialmente un funcionamiento correcto, una buena documentación y
ser eficiente. El diseño descendente y un refinamiento sucesivo deberían conducir a la obtención de buenos
programas. Hoy en día la legibilidad es, sin duda, uno de los criterios más sobresalientes a la hora de decidir si
un programa es o no bueno. Gracias a los avances del Hardware, el estilo de programación se ha vuelto más
importante que el ahorro de memoria y el tiempo de ejecución.
El estilo en la construcción de programas, no es una cosa que pueda adquirirse sólo a partir del conocimiento
de las reglas de sintaxis de un lenguaje y las técnicas básicas de programación No obstante, es posible reunir
la inventiva y la ingeniosidad con unas reglas de disciplina y orden en el diseño de programas. El estilo de la
buena programación está íntimamente unido con la legibilidad de los programas. La legibilidad es la clave para
la comprensión de un programa, un programa que no se puede comprender no se podrá modificar ni mantener
actualizado.
La calidad de un programa se puede medir con diferentes parámetros, entre ellos, destacaremos:
▪ El programa debe funcionar: Un programa se dice que funciona correctamente cuando proporciona unos
resultados correctos para todo el rango posible de datos de entrada y en todos sus estados.
▪ La documentación: Es muy importante que el programa esté documentado. La documentación sirve para
ayudar a comprender y utilizar un programa. Puede ser interna (comentarios) o externa (manuales,
guías…)
▪ La eficiencia: Antiguamente los programadores gastaban mucho tiempo en ahorrar espacio de memoria
y disminución de tiempos de ejecución. Hoy, aunque se debe tener presente siempre el ahorro de memoria
y el tiempo de ejecución, los avances de hardware hacen que esta variable no sea tan exigente como en
tiempos pasados.
▪ La corrección: El programa debe coincidir exactamente con las especificaciones: proporcionar la
respuesta correcta para cualquier rango válido de datos.
▪ La flexibilidad: Los programas deben permitir cambios con ligeros retoques.
▪ La Fiabilidad: La exactitud y precisión de los resultados debe estar acorde con los tipos y rangos de datos
y las características de proceso del computador.
▪ La presentación: El formato de la presentación del código de un programa es decisivo a la hora de mejorar
su legibilidad. Hay que poner especial atención a los comentarios, identación (sangría) y nombres de las
variables.
Se recomienda descomponer el programa en módulos. Cada módulo representa una actividad completa y se
codifica independientemente.
El desarrollo se puede hacer mediante el método “Top-down” o “Bottom-up”.

Página 1 de 12
 Vicerrectoría Académica IP – CFT
Dirección de Desarrollo Curricular

▪ Top-Down Es una técnica para diseñar que consiste en tomar el problema en forma inicial como una
cuestión global y descomponerlo sucesivamente en problemas más pequeños y por lo tanto, de solución
más sencilla. La descomposición del problema original (y de las etapas subsecuentes), puede detenerse
cuando los problemas resultantes alcanzan un nivel de detalle que el programador o analista pueden
implementar fácilmente.
▪ Bottom-Up Esta técnica consiste en partir de los detalles más precisos del algoritmo completando
sucesivamente módulos de mayor complejidad, se recomienda cuando ya se cuenta con experiencia y ya
se sabe lo que se va a hacer. Conforme se va alcanzando el desarrollo de módulos más grandes se
plantea como objetivo final la resolución global del problema. Este método es el inverso del anterior y es
recomendable cuando se tiene un modelo a seguir o se cuenta con amplia experiencia en la resolución de
problemas semejantes.
Hay varias razones por las que es deseable analizar el comportamiento de un algoritmo.
1. Analizando se pueden descubrir características generales y particulares de un algoritmo y evaluar la
facilidad de emplearlo en una aplicación, o compararlo con otras opciones de algoritmo para la misma
aplicación.
2. El análisis de un algoritmo sirve para entender mejor sus propiedades y puede sugerir mejoras posteriores.
3. El análisis puede servir para identificar maneras de sacar las mayores ventajas del ambiente de
programación (arquitectura de la computadora, sistema operativo, compilador), que puede tener un efecto
significativo en el desempeño del algoritmo.
4. Muchos algoritmos poseen una estructura compleja que despierta interés matemático y permite el
desarrollo de teoría útil para otras situaciones (como el análisis de otros algoritmos).
El método empleado en el análisis de un algoritmo depende por completo de la naturaleza del algoritmo que se
trate. Por otra parte, un algoritmo puede ser analizado de distintas formas y más aún si consideramos que
muchos se pueden programar iterativa o recursivamente. En algunas ocasiones se pueden establecer
esquemas generales de análisis como los que a continuación se presentan:
Correctitud
Un error común es hacer una prueba de escritorio con algunos valores y concluir que el algoritmo funciona.
Este método empírico puede no encontrar errores oscuros que no sean fáciles de detectar en pruebas
experimentales.

Página 2 de 12
 Vicerrectoría Académica IP – CFT
Dirección de Desarrollo Curricular

Si el algoritmo es iterativo se procede de la siguiente manera:

1. Escribir una especificación para la salida que debe producirse en términos de los datos de entrada.
2. Para cada ciclo (comenzando de los más internos), diseñar un invariante que se mantenga verdadero en
cada iteración y que capture el progreso del ciclo.
3. Probar que el invariante se cumple. Esto generalmente se hace por inducción sobre el número de
iteraciones. Se puede comenzar generando una lista de los valores de las variables a partir de sus valores
anteriores (esto se puede usar como hipótesis de inducción).
4. Utilizar el invariante de cada ciclo para verificar la finitud.
5. Utilizar el invariante de cada ciclo y las condiciones de terminación para probar que el algoritmo obtiene
el resultado esperado.
Si el algoritmo es recursivo se prueba por inducción sobre el tamaño del problema:
6. Identificar lo que será utilizado como tamaño del problema.
7. Probar la base de la inducción (generalmente sólo involucra la base de la llamada recursiva).
8. Probar que cada llamada recursiva es un problema del mismo tipo pero más pequeño
9. Probar la hipótesis de inducción, asumiendo que cada llamada recursiva trabaja de manera correcta para
demostrar que la llamada actual trabaja correctamente.

Complejidad algorítmica
Las ideas detrás del análisis son relativamente simples aunque generalmente muy difíciles de aplicar. En el
caso de algoritmos iterativos, se carga O a cada segmento de código que no incluya ciclos y se usan las reglas
de sumas y productos de la notación asintótica para incluir ciclos.
En el caso de los algoritmos recursivos, la clave está en determinar la relación de recurrencia que describe la
complejidad y resolverla. La solución de recurrencias generalmente se obtiene por iteración, sustitución o con
el Teorema Maestro.
Aún algoritmos sencillos pueden requerir un análisis para el que se necesite un buen conocimiento de
matemáticas. Para muchos algoritmos es más sencillo realizar un análisis amortizado, tomando ideas de los
economistas. En el análisis amortizado se obtiene como resultado el costo por operación, calculando el total
para n operaciones y luego sacando un promedio, T(n)/n.
El análisis amortizado posee las siguientes características:
- Puede utilizarse para mostrar que el costo medio de una operación es pequeño.
- No interviene la probabilidad, a diferencia del análisis del caso medio.
- Garantiza el desempeño de cada operación en el caso medio.
- Es relativamente sencillo de aplicar en algoritmos sofisticados como los árboles de Fibonacci

Página 3 de 12
 Vicerrectoría Académica IP – CFT
Dirección de Desarrollo Curricular

Hay tres métodos posibles:

▪ Agregación, considerando el mismo peso por operación.
▪ Conteo, asignando pesos distintos a las operaciones (su peso amortizado).
▪ Potencial, asociando energía potencial a la estructura como un todo. Si Dk es el estado de la estructura
después de la k-ésima operación y Φ (Dk) su energía potencial y ck el costo de la operación k-ésima,
entonces el costo amortizado a por operación se calcula como:
ai = ci + (Dk) -  (Dk-1).
Un esquema general para aplicar análisis amortizado incluye tener que contestar las preguntas siguientes.
- ¿Cuánto se compra a crédito?
- ¿Cuál es la regla de uso del crédito?
- ¿Cuál es el costo asignado por operación?

Y entonces se prosigue a
1. mostrar que hay crédito suficiente para pagar una operación, y
2. mostrar que, después de una operación, hay suficiente crédito para satisfacer la regla de uso.

El teorema maestro proporciona una solución sencilla en términos asintóticos (usando una Cota superior
asintótica) para ecuaciones de recurrencia que ocurren en muchos algoritmos recursivos tales como en el
Algoritmo divide y vencerás. Fue popularizado por el libro Introducción a los algoritmos por Cormen, Leiserson,
Rivest, y Stein, en el cual fue tanto introducido como probado formalmente. No todas las ecuaciones de
recurrencia pueden ser resueltas con el uso del teorema maestro.
El teorema maestro proporciona una solución sencilla en términos asintóticos (usando una Cota superior
asintótica) para ecuaciones de recurrencia que ocurren en muchos algoritmos recursivos tales como en el
Algoritmo divide y vencerás. Fue popularizado por el libro Introducción a los algoritmos por Cormen, Leiserson,
Rivest, y Stein, en el cual fue tanto introducido como probado formalmente. No todas las ecuaciones de
recurrencia pueden ser resueltas con el uso del teorema maestro.
Considere un problema que puede ser resuelto a través de un algoritmo recursivo como el siguiente:
Procedimiento T(n : tamaño del problema ) definición:
if n < 1 then exit

Hacer trabajo f(n)

T(n/b)
T(n/b)
...repetir una cantidad de a veces...
T(n/b)
fin procedimiento

Página 4 de 12
 Vicerrectoría Académica IP – CFT
Dirección de Desarrollo Curricular

En el algoritmo mostrado arriba se divide el problema original en una cantidad menor de subproblemas de
manera recursiva, cada uno de estos subproblemas siendo del tamaño de n/b. Esto podría ser visualizado como
la construcción de un árbol de llamadas al problema, siendo cada nodo del árbol una instancia recursiva del
mismo y sus hijos siendo instancias de las llamadas subsiguientes. En el ejemplo de arriba, cada nodo tendría
un número a de hijos. Cada nodo hará la cantidad de trabajo correspondiente al tamaño del subproblema n,
pasado a esa instancia en particular, estando la cantidad de trabajo realizado determinado por {\displaystyle
f(n)} {\displaystyle f(n)}. El trabajo total realizado por todas las llamadas del árbol es la suma de los trabajos
hechos por cada uno de los nodos del árbol.

Técnicas experimentales
Hay varios esquemas pero los más utilizados son el de caja negra y el de caja blanca. Son complementos
indispensables de las pruebas formales pues las constantes introducidas por la codificación de los algoritmos
pueden mermar seriamente su desempeño en la práctica.
- Caja negra: Consiste en tomar una muestra suficientemente representativa del conjunto de las posibles
entradas y verificar que la salida es la correcta sin ver la forma como el algoritmo está trabajando.
- Caja blanca: Consiste en preparar un conjunto de entradas que aseguren que cada línea de código será
ejecutada alguna vez y que las condiciones serán evaluadas en sus límites.
Es posible utilizar estos dos métodos de manera complementaria.

2. TÉCNICAS DE ANÁLISIS DE SIMULACIÓN

En los años 60, R.M. Graham hizo un comentario crítico sobre la manera en que se construían los sistemas
basados en computadora: «Construimos sistemas igual que los hermanos Wright construían aviones:
construimos todo el sistema, lo empujamos barranco abajo, le dejamos que se estrelle y empezamos de nuevo.»
De hecho, para al menos un tipo de sistema -el sistema reactivo- lo continuamos haciendo hoy en día.
Muchos sistemas basados en computadora interaccionan con el mundo real de forma reactiva. Es decir, los
acontecimientos del mundo real son vigilados por el hardware y el software que componen el sistema, y
basándose en esos sucesos, el sistema aplica su control sobre las máquinas, procesos e incluso las personas
que motivan los acontecimientos. Los sistemas de tiempo real y sistemas empotrados pertenecen a menudo a
la categoría de sistemas reactivos.
Desgraciadamente, los desarrolladores de sistemas reactivos luchan a veces para hacerlos funcionar
correctamente. Hasta hace poco, ha sido difícil predecir el rendimiento, la eficacia y el comportamiento de estos
sistemas antes de construirlos. Realmente, la construcción de muchos sistemas de tiempo real era una
aventura.
Las sorpresas (la mayoría desagradables) no se descubrían hasta que el sistema era construido y «arrojado
colina abajo». Si el sistema se estrellaba debido a un funcionamiento incorrecto, comportamiento inapropiado
o escaso rendimiento, cogíamos las piezas y empezábamos de nuevo.
Muchos sistemas de la categoría de los reactivos controlan máquinas y/o procesos (por ejemplo, aerolíneas
comerciales o refinerías de petróleo) que deben operar con extrema fiabilidad.

Página 5 de 12
 Vicerrectoría Académica IP – CFT
Dirección de Desarrollo Curricular

Si el sistema falla, podrían ocurrir pérdidas económicas o humanas significativas. Por este motivo, el enfoque
descrito por Graham es penoso y peligroso.
Hoy en día se utilizan herramientas software para el modelado y simulación de sistemas para ayudar a eliminar
sorpresas cuando se construyen sistemas reactivos basados en computadora. Estas herramientas se aplican
durante el proceso de ingeniería de sistemas, mientras se están especificando las necesidades del hardware,
software, bases de datos y de personas.
Las herramientas de modelado y simulación capacitan al ingeniero de sistemas para probar una especificación
del sistema.

Herramientas para realizar pruebas de software

▪ Testopia es un administrador de casos de prueba, el cual maneja extensiones para interactuar con Bugzilla.
Testopia está diseñado para ser una herramienta genérica para el seguimiento de casos de prueba,
permitiendo a las organizaciones realizar las pruebas de software e integrar reportes de defectos
encontrados, así como el resultado de los de los caso de prueba. Testopia está diseñado desde el punto de
vista de la actividad de pruebas, este puede ser usado para llevar el seguimiento de pruebas, así como el
seguimiento virtual de cualquier proceso de ingeniería.
▪ QaManager es una aplicación web independiente de plataforma para administrar proyectos de control de
calidad de manera efectiva con una instalación muy simple. QaManager tiene seguimiento de proyectos,
administración de recursos, administración de TC, biblioteca en línea, alertas y más.
▪ El Test Environmet Toolkit (TET) se proporciona como un producto de línea de comandos de código
abierto y no compatible. Se usa ampliamente en muchas aplicaciones de prueba, incluido el programa de
certificación UNIX de The Open Group y el programa de certificación LSB de Free Standards Group.
▪ SoapUI es la herramienta de prueba funcional líder en el mundo para pruebas de SOAP y REST. Con su
interfaz gráfica fácil de usar y sus características de clase empresarial, SoapUI le permite crear y ejecutar
de manera fácil y rápida las pruebas automatizadas de funcionalidad, regresión y carga. En un entorno de
prueba único, SoapUI proporciona una cobertura de prueba completa, desde servicios web basados en
SOAP y REST hasta capas de mensajería empresarial JMS, bases de datos, aplicaciones de Internet
enriquecidas y mucho más.
▪ Solex es una herramienta gratuita de prueba de aplicaciones web de código abierto creada como
complemento para el IDE de Eclipse. Proporciona funciones para grabar una sesión de cliente, ajustarla de
acuerdo con varios parámetros y reproducirla más tarde, normalmente para garantizar que no se regrese el
comportamiento de la aplicación (con capacidades de pruebas de estrés que se agregarán en una etapa
posterior).
▪ HP LoadRunner Reduce drásticamente la cantidad de tiempo y habilidad requerida para simular las
transacciones de los usuarios en el software de prueba de carga. Integra las pruebas de carga en sus
herramientas de desarrollo: IDE, jUnit, nUnit, Jenkins, Selenium y Microsoft Visual Studio. A partir de la
versión 12.55, puede ejecutar sus scripts de JMeter e integrar JMeter con tipos de scripts adicionales en
cualquier prueba de rendimiento. Con más de 50 protocolos, puede probar fácilmente una amplia gama de

Página 6 de 12
 Vicerrectoría Académica IP – CFT
Dirección de Desarrollo Curricular

aplicaciones que incluyen web, móvil, Ajax, Flex, HTML 5, .NET, Java, GWT, Silverlight, SOAP, Citrix, ERP
y más.
▪ Telerik Test Studio permite realizar pruebas automatizadas de forma rápida y sencilla, integrarlos en su
entorno de CI / CD siguiendo su ágil flujo de trabajo, encontrar defectos antes y enviar un producto de
software de mejor calidad. Automatiza las tareas manuales de control de calidad repetitivas y garantiza un
alto nivel de calidad del software continuamente a tiempo sin sorpresas de última hora.
▪ Bitbar Testing presenta una nube de dispositivos móviles con miles de dispositivos Android y iOS reales
para equipos móviles con sabores únicos para lograr pruebas continuas y aumentar la eficiencia de las
pruebas, asistida por AI Testbot.
▪ SpiraTest proporciona una solución completa de control de calidad que gestiona los requisitos, pruebas,
errores y problemas en un entorno, con una trazabilidad completa desde su inicio hasta su finalización.

3. TÉCNICAS DE INSPECCIÓN DE CÓDIGO

Actualmente se ha evidenciado que en la industria del software se generan inconvenientes a la hora de
garantizar la calidad del software de los productos entregados. Una de las principales causas es que en las
metodologías utilizadas no se tienen en cuenta las prácticas para minimizar los defectos de los artefactos, que
permitan reducir costos en recurso humano y en tiempos de ejecución. Por esta razón es fundamental indagar
sobre técnicas que permitan garantizar la calidad del software y cumplir con las especificaciones entregadas
por el cliente.
La inspección de Fagan se refiere al proceso estructurado de intentar encontrar defectos en documentos de
desarrollo tales como código de programación, especificaciones, diseño, y otros, durante las fases del proceso
de desarrollo del software. Es llamado así debido a Michael Fagan, quien es reconocido como el inventor de la
inspección formal del software
Consiste en hacer una revisión por pares, es decir; se definen roles:
▪ Autor: Desarrollador del producto que será inspeccionado
▪ Revisores: responsables de revisar el documento desde el punto de vista de las pruebas
▪ Moderador: Miembro del grupo de aseguramiento de la calidad, quien se encargará de verificar que
los artefactos se inspeccionen correctamente.
Todos deben tener las habilidades y conocimientos para realizar la práctica de esta técnica. Es importante tener
en cuenta que las inspecciones de código son de mejora incremental, esto quiere decir que los defectos deben
reducirse en el tiempo.
A continuación se relacionan los objetivos de las inspecciones:
▪ Encontrar tempranamente los defectos.
▪ Prevenir el mal funcionamiento de los procesos o planes establecidos.
▪ Proporcionar mejoras en la fiabilidad, disponibilidad, y la facilidad de mantenimiento del software.

Página 7 de 12
 Vicerrectoría Académica IP – CFT
Dirección de Desarrollo Curricular

▪ Descubrir continuamente la información técnica, asociada con las funciones, formularios y actividades
internas que aseguran el producto.
▪ Continuar el mejoramiento del proceso de desarrollo.
▪ Establecer una igualdad de conocimiento dentro de los desarrolladores para la buena práctica de los
estándares y técnicas de desarrollo.
La inspección de Fagan (Fagan inspection) es un método de revisiones agrupadas usado para evaluar la salida
de un proceso dado.
La inspección de Fagan define un proceso como una cierta actividad con una entrada preespecificada y criterios
de salida. En cada actividad u operación para la cual se especificaron criterios de entrada y salida se puede
usar la inspección de Fagan para validar si la salida cumple con el criterio especificado para el proceso.
Ejemplos de actividades para las que se puede utilizar la Inspección Fagan son:
▪ Especificaciones de requerimientos
▪ Software / Arquitectura de Sistemas de Información (por ejemplo DYA)
▪ Programación (por ejemplo, para las iteraciones en XP o DSDM)
▪ Pruebas de software (por ejemplo, para la creación de scripts de prueba)
Dado que los costos de remediar un defecto en las primeras instancias del proceso son hasta 10-100 veces
menores que hacerlo en la fase de mantenimiento, es esencial encontrarlos lo antes posible y es aquí donde
ayuda la inspección de la salida de cada operación y su comparación con los requisitos de salida previstos.
Un típico proceso de inspección involucra las siguientes operaciones::1
▪ Planificación:
Preparación de materiales
Determinar y convocar a los participantes
Organizar la reunión
▪ Información general
Poner al tanto a los participantes acerca de los materiales a ser examinados
Asignación de roles
▪ Preparación
Los participantes se preparan para la reunión revisando los ítems a ser analizados, estudiando el material
de apoyo y preparando preguntas o señalando posibles defectos
Los participantes ensayan su rol
▪ Reunión de inspección
Comprobación efectiva de los defectos
▪ Rehacer
Es el paso en el método de inspección de software en el que los defectos encontrados durante la reunión
de inspección se resuelven por el autor, diseñador o programador. Partiendo de la lista de defectos del
documento de bajo nivel, se corrige hasta que se cumplen los requisitos en el documento de alto nivel.

Página 8 de 12
 Vicerrectoría Académica IP – CFT
Dirección de Desarrollo Curricular

▪ Seguimiento
En la fase de seguimiento, bajo la responsabilidad del moderador se inspecciona que todos los defectos
encontrados en la reunión de la inspección efectivamente se hayan corregido y que no hayan aparecido
nuevos.

Herramientas para realizar inspección de código

Con SonarQube, un desarrollador tiene todo a mano para hacerse cargo de la calidad de su código. Para
aplicar completamente una práctica de calidad de código en todos los equipos, necesita configurar un Quality
Gate. Este concepto básico de SonarQube es un conjunto de requisitos que indica si una nueva versión de un
proyecto puede entrar en producción o no. La puerta de calidad predeterminada de SonarQube comprueba lo
que sucedió en el período de fuga y falla si su nuevo código empeoró en este período.
Kiuwan es una solución SaaS de análisis estático de código multitecnología, dedicada a la analítica de las
aplicaciones software, así como a la medición de la calidad y medida de seguridad de las mismas. Kiuwan es
una de las herramientas en la lista de OWASP de herramientas de análisis estático del código fuente.
Insights garantiza la continuidad y la integridad de la gestión de código abierto con una solución multitecnología
completa que se integra perfectamente en las principales herramientas de SDLC. Insights le permite asegurar
y administrar cualquier vulnerabilidad, cumplimiento y riesgo operacional que pueda surgir del uso de
componentes de código abierto.

4. TÉCNICAS DE ANÁLISIS DE FLUJO/CONTROL

El programa se ve como una caja blanca. Se generan casos atendiendo a la estructura de control del programa.
Se usan criterios que buscan cubrir todas las sentencias o bloques de sentencias de un programa.
Técnicas de cobertura de caminos
Secuencia de sentencias encadenadas desde la entrada del programa hasta su salida. Una cobertura de
sentencias se ha logrado si todos las declaraciones han sido ejecutadas al menos una vez.
Todas las sentencias se ejecutan al menos una vez. Las condiciones son probadas para valores verdadero y
falso.
La cobertura de la sentencia completa es el criterio más débil de la cobertura en las pruebas.
El problema básico es seleccionar unos pocos caminos que recorran todos los nodos de un control de flujo
gráfico (CFG) para lograr la cobertura declaración completa.
La técnica de camino básico se basa en la medida de complejidad ciclomática que es una métrica de software
que provee una medición cuantitativa de la complejidad lógica de un programa.
Usada en el contexto testing, define el número de caminos independientes en el conjunto básico y entrega un
límite superior para el número de casos necesarios para ejecutar todas las instrucciones al menos una vez.
El inconveniente que presenta es que no da idea de la complejidad de los datos.

Página 9 de 12
 Vicerrectoría Académica IP – CFT
Dirección de Desarrollo Curricular

Técnicas de control de flujo

▪ Cobertura de Decisión: Se escriben casos de prueba suficientes para que cada decisión en el programa
se ejecute una vez con resultado verdadero y otra con el falso.
▪ Cobertura de Condiciones: Se escriben casos de prueba suficientes para que cada condición en una
decisión tenga una vez resultado verdadero y otra falso.
▪ Cobertura Decisión/Condición: Se escriben casos de prueba suficientes para que cada condición en
una decisión tome todas las posibles salidas, al menos una vez, y cada decisión tome todas las posibles
salidas, al menos una vez.
▪ Cobertura de Condición Múltiple: Se escriben casos de prueba suficientes para que todas las
combinaciones posibles de resultados de cada condición se invoquen al menos una vez.
Se escriben casos de prueba suficientes para que cada decisión en el programa se ejecute una vez con
resultado verdadero y otra con el falso.
Para aplicar esta técnica necesitaríamos emplear al menos los dos siguientes casos de prueba:
1. Evaluando la parte valida de la condición: a = 2 y b = 3 (a verdadero, b verdadero)
2. Evaluando la parte invalida de la condición: a = -2 y b = 3 (a falso, b verdadero)
Con estos dos casos de prueba son evaluadas al menos una vez, las salidas válidas o inválidas.

Técnicas de cobertura de ciclos

La Cobertura de ciclos es una técnica de Caja Blanca, en donde el objeto es verificar los ciclos de un programa
software. Estas técnicas se caracterizan por usar grafos para describir su funcionamiento. Estos grafos siempre
se componen de: Aristas, nodos y regiones

Como existen diferentes tipos de ciclos hay que tenerlos en cuenta a la hora de analizarlos.
Los tipos son:
▪ Simple
▪ Anidado
▪ Concatenado
▪ No estructurado

Página 10 de 12
 Vicerrectoría Académica IP – CFT
Dirección de Desarrollo Curricular

Además también hay que tener las diferentes sentencias que hay para representar un ciclo:
▪ While
▪ Repeat
▪ For
Para usar esta técnica es importante tener el código del programa que estamos evaluando, buscando los
algoritmos que contengan los ciclos. Una vez seleccionados los segmentos de código que contienen ciclos se
procede a dibujar el grafo, esto se hace para poder identificar el recorrido lógico del código. Con el grafo y el
código se identifica que criterio usar para aplicar pruebas. A continuación se explican los diferentes tipos de
ciclos y sentencias que se usan como criterios para evaluar ciclos.
Ciclos Simples: Estos ciclos son sencillos, generalmente tienen una condición
Para probar estos ciclos tenemos unas reglas. Teniendo en cuenta que n es el número de iteraciones del ciclo:
▪ Pasar por alto el bucle
▪ Pasar una sola vez
▪ Pasar 2 veces por el bucle
▪ Pasar m veces por el bucle, siendo m

Ciclos Anidados: Estos ciclos son aquellos que tienen un ciclo en su interior
Tenemos las siguientes reglas
• Hacer pruebas con el bucle más interno y tratarlo como si fuera simple y el
externo mantener el número mínimo de iteraciones.
• Pruebas hacia fuera, para los internos mantener valores típicos y externos
valores mínimos.

Ciclos Concatenados: Estos ciclos son aquellos que tienen un ciclo en su interior, pero a diferencia del anterior
vuelve no hasta el inicio del Ciclo externo, si no hasta sí mismo.
Para estos hay que verificar que forma de concatenación tiene, si es
concatenación independiente se prueba igual que los bucles simples,
pero si es concatenación no independiente, se trata como bucles
anidados.

Página 11 de 12
 Vicerrectoría Académica IP – CFT
Dirección de Desarrollo Curricular

Ciclos No Estructurados: Estos ciclos son aquellos que utilizan programación no Estructurada.
Para este tipo de bucles se recomienda no hacer pruebas y
replantearlos, pues son una muy mala práctica de programación
y sería altamente riesgoso para el software

Sentencias de ciclo While:

A este tipo de sentencias, por teoría se les deben aplicar como mínimo 3 pruebas:
▪ De cero ejecuciones
▪ De 1 ejecución
▪ De más de 1 ejecución
Sentencias de ciclo Repeat:
A este tipo de sentencias, por teoría se les deben aplicar como mínimo 2 pruebas:
▪ De 1 Ejecución
▪ De más de 1 Ejecución
Sentencias de ciclo For:
Con este aparentemente sería sencillo sólo se tendría que hacer 1 Prueba, pues el ya tiene el número de
veces que se va ejecutar en la cabecera, y las decisiones se pueden revisar con la técnica de cobertura de
ramas, pero el For tiene sus trampitas, como que en su interior la variable incremente más de lo debido, que
existan Loop, Goto, Exit, Breaks, que alteraría por completo el comportamiento del ciclo, por lo tanto no podría
hablar de 1 prueba, si no de un número incalculable de pruebas.

Fuentes:
- Técnicas de análisis y diseño de algoritmos, Ricardo Soto, PUCV,
- Introduction to Algorithms, Thomas Cormen, MIT Press, 2009
- An Introduction to the Analysis of Algorithms, Robert Sedgewick, Pearson Education, 2013

Página 12 de 12