Distinción entre validación y verificación.

Enfoques estáticos y
dinámicos. Fundamentos de "testing", testeo de caja negra y de caja
blanca.

VALIDACION

Validación es la acción y efecto de validar (convertir algo en válido, darle fuerza

o firmeza). El adjetivo válido, por otra parte, hace referencia a aquello que tiene
un peso legal o que es rígido y subsistente
Por ejemplo: “Hemos intentado comprobar la autenticidad del producto, pero lo
cierto es que no pasó el proceso de validación”, “El dueño ya realizó la
validación del proyecto, el cual será desarrollado en los próximos meses”, “El
programa no superó el proceso de validación y, por lo tanto, dejó de funcionar”.
En el ámbito de la creación de software, se conoce como pruebas de
validación al proceso de revisión al que se somete un programa informático
para comprobar que cumple con sus especificaciones. El mismo, que suele
tener lugar al final de la etapa de desarrollo, se realiza principalmente con la
intención de confirmar que la aplicación permita llevar a cabo las tareas que
sus potenciales usuarios esperan de ella.
Las pruebas de validación también se llevan a cabo para determinar si la
licencia de un software es legal o si se trata de una falsificación (una copia
pirata). Algunas versiones del sistema operativo Windows realizan estas
pruebas de validación de manera automática (sin que el usuario lo requiera).
Cuando sucede que el proceso no es superado, el propio sistema avisa al
usuario que podría ser víctima de una falsificación.
La validación cruzada, por último, es una práctica estadística que consiste en
fragmentar una muestra de datos en subconjuntos para analizar uno de ellos y,
luego, validar dicho análisis con el resto de los subconjuntos
PRUEBA DE VALIDACION
Las pruebas de validación en la ingeniería de software son el proceso de
revisión que verifica que el sistema de software producido que cumple con las
especificaciones y que logra su cometido. Es normalmente una parte del
proceso de pruebas de software de un proyecto, que también utiliza técnicas
tales como evaluaciones, inspecciones y tutoriales. La validación es el proceso
de comprobar que lo que se ha especificado es lo que el usuario realmente
quería.
Se trata de evaluar el sistema o parte de este durante o al final del desarrollo
para determinar si satisface los requisitos iniciales. La pregunta a realizarse es:
¿Es esto lo que el cliente quiere?.
Enfoques a la verificación de las pruebas
1
 Dinámica de verificación, también conocido como ensayos o
experimentación.
 Estática de verificación, también conocido como análisis.

Tipos de pruebas

 Pruebas de aceptación: desarrolladas por el cliente.

 Pruebas alfa realizadas por el usuario con el desarrollador como
observador en un entorno controlado (simulación de un entorno de
producción).
 Pruebas beta: realizadas por el usuario en su entorno de trabajo y sin
observadores.
 Versiones

Prueba Alfa
Es la primera versión completa del programa, la cual es enviada a los
verificadores para probarla.
Algunos equipos de desarrollo utilizan el término alfa informalmente para
referirse a una fase donde un producto todavía es inestable, aguarda todavía a
que se eliminen los errores o a la puesta en práctica completa de toda su
funcionalidad, pero satisface la mayoría de los requisitos.
El nombre se deriva de alfa, la primera letra en el alfabeto griego.

Prueba Beta
Una beta representa generalmente la primera versión completa de un programa
informático o de otro producto, que es posible que sea inestable pero útil para
que sea considerada como una versión preliminar (preview) o como una
preliminar técnica (technical preview [TP]). Esta etapa comienza a menudo
cuando los desarrolladores anuncian una congelación de las características del
producto, indicando que no serán agregadas más características a esta versión
y que solamente se harán pequeñas ediciones o se corregirán errores. Las
versiones beta están en un paso intermedio en el ciclo de desarrollo completo.
Los desarrolladores las lanzan a un grupo de probadores de betas o beta
testers (a veces el público en general) para una prueba de usuario. Los
probadores divulgan cualquier error que encuentran y características, a veces
de menor importancia, que quisieran ver en la versión final.
Cuando una versión beta llega a estar disponible para el público en general, a
menudo es extensamente probada por los tecnológicamente expertos o
familiarizados con versiones anteriores, como si el producto estuviera acabado.
Generalmente los desarrolladores de las versiones betas del software gratuito o
de código abierto los lanzan al público en general, mientras que las versiones
beta propietarias van a un grupo relativamente pequeño de probadores.
En febrero de 2005, ZDNet publicó un artículo acerca del fenómeno reciente de
las versiones beta que permanecían a menudo por años y que eran utilizada
como si estuvieran en nivel de producción. Gmail, igual que las Google
2
Noticias, por ejemplo, estuvieron en beta por un período de tiempo muy largo
(cinco años). Esta técnica puede también permitir a un desarrollador retrasar el
ofrecimiento de apoyo total o la responsabilidad de ediciones restantes. Los
receptores de betas altamente propietarias pueden tener que firmar un acuerdo
de no revelación. Como esta es la segunda etapa en el ciclo de desarrollo que
sigue la etapa de alfa, esta se nombra como la siguiente letra griega beta.
Versión candidata a definitiva

Una versión candidata a definitiva, candidata a versión final o candidata para el

lanzamiento (del inglés release candidate), comprende un producto preparado
para publicarse como versión definitiva a menos que aparezcan errores que lo
impidan. En esta fase el producto implementa todas las funciones del diseño y
se encuentra libre de cualquier error que suponga un punto muerto en el
desarrollo. Muchas empresas de desarrollo utilizan frecuentemente este
término. Otros términos relacionados incluyen gamma, delta (y tal vez más
letras griegas) para versiones que están prácticamente completas pero todavía
en pruebas; y omega para versiones que se creen libres de errores y se hallan
en el proceso final de pruebas. Gamma, delta y omega son, respectivamente,
la tercera, cuarta y última letras del alfabeto griego.
Considerada muy estable y relativamente libre de errores con una calidad
adecuada para una distribución amplia y usada por usuarios finales. En
versiones comerciales, puede estar también firmada (usado para que los
usuarios finales verifiquen que el código no ha sido cambiado desde su salida).
La expresión de que un producto sea dorada significa que el código ha sido
completado y que está siendo producido masivamente y estará a la venta
próximamente.

Versión disponibilidad General

La versión de disponibilidad general (también llamada dorada) de un producto

es su versión final. Normalmente es casi idéntica a la versión candidata final,
con sólo correcciones de última hora. Esta versión es considerada muy estable
y relativamente libre de errores con una calidad adecuada para una distribución
amplia y usada por usuarios finales. En versiones comerciales, puede estar
también firmada (usado para que los usuarios finales verifiquen que el código
no ha sido cambiado desde su salida). La expresión de que un producto sea
dorado significa que el código ha sido completado y que está siendo producido
masivamente y estará en venta próximamente.
El término dorado se refiere anecdóticamente al uso del disco maestro de
oro que fue frecuentemente usado para enviar la versión final a los fabricantes
que lo usan para producir las copias de venta al detalle. Esto puede ser una
herencia de la producción musical. En algunos casos, sin embargo, el disco
maestro está realmente hecho de oro, tanto por apariencia estética como por
resistencia a la corrosión.

3
Microsoft y otros usan el término distribución a fabricantes (RTM o release to
manufacturing) para referirse a esta versión (para productos comerciales como
Windows 7, se referirían a ella como "la compilación 7600 es la elegida como
Windows 7 RTM"), y distribución a web (RTW o release to Web) para productos
libremente descargables

Estables/inestables
En la programación de código abierto los números de las versiones, o los
términos estable e inestable, normalmente distinguen las fases del desarrollo.
En el pasado, el núcleo Linux usaba el número de versión para denotar si una
versión era estable o inestable. En efecto, las versiones estaban formada por
cuatro números, separados por un punto. Una cifra impar en el segundo
número de la versión indicaba una versión inestable. Hoy en día ya no se usa
esta convención, y todas las versiones son estables independientemente del
número de versión. En la práctica el uso de números pares e impares para
indicar la estabilidad de un producto ha sido usado por otros muchos proyectos
de software libre.
Este concepto también se aplica al software empaquetado en algunas
distribuciones Linux como Debian, de modo que existe una rama o conjunto de
paquetes considerados estables y otra rama considerada inestable. Esta última
rama aporta versiones de programas más recientes que la estable pero que no
están tan probados

Características de las pruebas

Comprobar que se satisfacen los requisitos:

 Se usan las mismas técnicas, pero con otro objetivo.

 No hay programas de prueba, sino sólo el código final de la aplicación.
 Se prueba el programa completo.
 Uno o varios casos de prueba por cada requisito o caso de
uso especificado.
 Se prueba también rendimiento, capacidad, etc. (y no sólo resultados
correctos).
 Pruebas alfa (desarrolladores) y beta (usuarios).

LA IMPORTANCIA DE LA VALIDACIÓN EN EL PROCESO DE

CONFIRMACIÓN EN LA AUDITORIA

En la actualidad el ejercicio de Auditoria requiere una constante actualización y

capacitación para generar un mayor valor en los entregables y planes de
ejecución dentro de las organizaciones. Además de que el Auditor cuente con
4
ciertas características y cualidades al momento de ejercer su auditoria como lo
pueden llegar a ser el escepticismo entre otros, la validación ha llegado a
consolidarse como uno de los principales ejes o pilares de los procesos de
confirmación en las auditorias. La validación dentro de los procesos de
confirmación en las auditorias, hace que sea tanto integra como confiable las
evidencias y posibles hallazgos encontrados durante el proceso de auditoría.
Seguidamente durante el proceso de confirmación en las auditorias la
tecnología ha pasado a jugar un papel muy importante. Un alto porcentaje de
los procesos de confirmación en las auditorias se están generando por medio
de correos electrónicos sin establecer al momento de recepción de los
documentos procesos de validaciones necesarias que pueden hacer que las
evidencias o hallazgos no sean reales o fiables. Existen algunos
procedimientos que posiblemente los auditores no han tenido en cuenta o han
validado en el proceso de confirmación en las auditorias como por ejemplo;
• Si es una dirección de correo electrónico valida (al momento de recibir las
confirmaciones)?

• La persona que confirma los saldos o información está habilitada dentro de la

organización para hacerlo?,
Estas son algunas de las posibles problemáticas que actualmente existen y
hacen que los posibles hallazgos y evidencias encontradas no sean fiables si
no existen procesos de validación. Esta problemática abarca graves
consecuencias puesto que puede que los hallazgos y evidencias se estén
utilizando en procesos de auditorías forenses, auditorias financieras, auditorias
de mercadeo, auditorias contables entre otras.
En el Libro Blanco “Understanding the importance of validation in the Audit
Confirmation Process” se hace referencia a que es posible crear el sistema
ideal para el proceso de confirmación en las auditorias, así mismo se señala
que es posible realizarlo si las firmas de auditoría cuentan con la tecnología
indicada en el momento indicado.
Estas son las principales recomendaciones a las cuales hace referencia el
texto:

• La primera recomendación es contar con un sistema o plataforma totalmente

segura digitalmente.

• La posibilidad de autenticar la información, es decir, que la información tanto

enviada sea validada y garantice que esta es real, y fiable.

• Contar con una herramienta tecnología que haga eficiente este proceso y no
existan posibles retardos, cuellos de botella, en el proceso de envíos o
recepciones de información cuando estos se realizan de forma física.

5
VERIFICACION

En el latín es donde podemos encontrar el origen etimológico del término

verificación que ahora nos ocupa. Es más, podemos dejar patente que emana
del vocablo “verificare”, un verbo que es la suma de estas dos partes
claramente diferenciadas: “veritas”, que puede traducirse como “verdadero”, y
“facere”, que ejerce como sinónimo de “hacer”.
Verificación es la acción de verificar (comprobar o examinar la verdad de algo).
La verificación suele ser el proceso que se realiza para revisar si una
determinada cosa está cumpliendo con los requisitos y normas previstos.
Por ejemplo: “Las obras ya están terminadas: ahora falta que pasen las
autoridades estatales a realizar la verificación de las instalaciones”, “Mañana
tengo que llevar el coche a la verificación para que podamos salir a la ruta sin
problemas”, “El software no superó la verificación, lo que quiere decir que se
trata de una copia pirata”.

La noción de verificación es frecuente en la computación, en el derecho y en el

ámbito de las ciencias en general. Puede decirse que la verificación es un paso
imprescindible para comprobar o refutar una teoría o una hipótesis.
Así, por ejemplo, dentro del ámbito de la informática se recurre a la verificación
en muchas ocasiones no sólo a nivel profesional sino también desde un plano
de usuario. De esta manera, una persona que quiera abrirse una nueva cuenta
en Google o que ya tenga una, se topará con el hecho de que se le ofrece la
posibilidad en dos sencillos pasos de poder apostar por la seguridad de
aquella.
En concreto, este proceso consiste en introducir la contraseña establecida y
hacer lo propio con un código que desde la mencionada empresa se le envía a
su número de teléfono mediante un sms. De esta manera, a través de ambos
elementos, se consigue que si un hacker consigue descubrir la contraseña se
encuentre con una barrera más de seguridad pues necesitará conocer ese
citado número telefónico para poder acceder a la cuenta por completo.
VERIFICACION DE SOFTWARE

La verificación de software es una disciplina de la ingeniería de software cuyo

objetivo es asegurar que el software satisface por completo todos los requisitos
esperados.
Amplio alcance y verificacion

6
Una definición de amplio alcance de la verificación la hace equivalente
al testing de software. Por ello, hay dos enfoques principales en cuanto a la
verificación
Verificación dinámica, también conocida como experimentación, testing
dinámico o, simplemente testing. - Que es apropiado para encontrar fallos
(bugs de software).
Verificación estática, también conocida como análisis or, testing estático - Que
es útil para probar la corrección de un programa. Aunque puede dar lugar a
falsos positivos cuando hay uno o más conflictos entre lo que hace realmente el
proceso del software y lo que la verificación estática asume que hace.
Verificación dinámica
La verificación dinámica es llevada a cabo durante la ejecución del software, y
dinámicante comprueba su comportamiento; se conoce comúnmente
como fase de testing. La verificación es un proceso de revisión. Dependiendo
de la extensión de los tests, se pueden catalogar en tres familias:
Test corto: un test que comprueba una única función o clase (test unitario)
Test largo: un test que comprueba un grupo de clases, como
Test de módulo (un único módulo)
Test de integración (más de un módulo)
Test de sistema (todo el sistema)
Test de aceptación: un test formal definido para comprobar el criterio de
aceptación del software
Test funcional
Test no funcional (ejecución, test de estrés)
El objetivo de la verificación dinámica de software es encontrar errores
presentados por una actividad (por ejemplo, tener un software para analizar
datos bioquímicos); o por la acción repetitiva de una o más acciones (como un
test de estrés para un servidor web, i.e. comprobar si el producto actual de la
actividad es tan correcto como lo era al comienzo de la actividad).
Verificación Estática
La verificación estática es el proceso de comprobar que el software cumple con
los requisitos, inspeccionándolo antes de ejecutar el código. Por ejemplo:
Verificación de convenciones de código
Detección de mala praxis (antipatrones)
Cálculo de métricas de software

7
Verificación formal
Verificación por análisis - El método de análisis de verificación se aplica a la
verificación por investigación, cálculos matemáticos, evaluación lógica y
cálculos usando métodos de libros de texto clásicos o métodos de ordenador
de uso general aceptados. El análisis incluye muestro, y correlación de datos
medidos y tests observados con valores esperados para establecer la
conformidad con los requisitos.

La verificación de software se confunde usualmente con la validación de

software. Las diferencias entre verificación y validación software son:
La verificación de software pregunta "¿Estamos construyendo correctamente el
producto?"; esto es, ¿el software cumple con sus requisitos? (como una casa
cumple con sus planos).
La validación de software pregunta "¿Estamos construyendo el producto
correcto?"; esto es, ¿hace el software lo que el usuario realmente requiere?
(como una casa cumple con lo que el propietario necesita y quiere

FUNDAMENTOS DEL TESTING

Las pruebas de software (en inglés testing) son las investigaciones empíricas y
técnicas cuyo objetivo es proporcionar información objetiva e independiente
sobre la calidad del producto.
Estas pruebas son básicamente un conjunto de actividades dentro del
desarrollo de software. Pueden ser implementadas en cualquier momento del
proceso de desarrollo, dependiendo del tipo de pruebas. Sin embargo, la
detección de errores en etapas tempranas reduce el “retrabajo”, por lo que
tienen una solución menos costosa para la empresa desarrolladora que si se
detectaran estos errores en una fase más avanzada del proyecto o una vez
puesto en producción. También conlleva una mejora de imagen de la empresa
desarrolladora, pues se reducen los fallos y se mejora la calidad del producto
entregado.
Generalmente se aplican las pruebas de software como una etapa más del
proceso de desarrollo, para asegurarnos de que el software cumple con las
especificaciones requeridas y eliminar los posibles defectos que éste pudiera
tener.
Por ejemplo, se usan las historias de usuario en metodología Scrum, con la que
es relativamente fácil diseñar un plan de pruebas, realizar pruebas de
seguridad, etc. Asimismo, se puede contar con un equipo de profesionales de
8
consultoría y técnicos especializados en servicios de ingeniería de testing, que
entre otras funciones realicen:
– Pruebas funcionales y de rendimiento. (con jMeter)
– Monitorización de sistemas.
– Integración con otros sistemas.
– Mantenimiento de aplicaciones.
– Métricas para medir la calidad del servicio. (con Sónar)
– Automatización de pruebas.
– Elaboración de documentación.

Las pruebas más comunes son las denominadas de cajas blancas y las de
cajas negras.

Pruebas de Cajas Blancas y Pruebas de Cajas Negra

Las PRUEBAS DE CAJA BLANCA (también conocidas como pruebas de caja
de cristal o pruebas estructurales) se centran en los detalles procedimentales
del software, por lo que su diseño está fuertemente ligado al código fuente. El
ingeniero de pruebas escoge distintos valores de entrada para examinar cada
uno de los posibles flujos de ejecución del programa y cerciorarse de que se
devuelven los valores de salida adecuados.
Al estar basadas en una implementación concreta, si esta se modifica, por
regla general las pruebas también deberán rediseñarse.
Aunque las pruebas de caja blanca son aplicables a varios niveles —
unidad, integración y sistema—, habitualmente se aplican a las unidades de
software. Su cometido es comprobar los flujos de ejecución dentro de cada
unidad (función, clase, módulo, etc.) pero también pueden probar los flujos
entre unidades durante la integración, e incluso entre subsistemas, durante las
pruebas de sistema.
A pesar de que este enfoque permite diseñar pruebas que cubran una amplia
variedad de casos de prueba, podría pasar por alto partes incompletas de
la especificación o requisitos faltantes, pese a garantizar la prueba exhaustiva
de todos los flujos de ejecución del código analizado.
Las principales técnicas de diseño de pruebas de caja blanca son:

 Pruebas de flujo de control

 Pruebas de flujo de datos
 Pruebas de bifurcación (branch testing)
 Pruebas de caminos básicos

9
PRUEBAS DE CAJA NEGRA
Estas pruebas permiten
obtener un conjunto de
condiciones de entrada
que ejerciten
completamente todos los
requisitos funcionales de
un programa. En ellas se
ignora la estructura de
control, concentrándose
en los requisitos
funcionales del sistema y Concepto: La prueba de Caja Negra se centra
ejercitándolos. principalmente en los requisitos
funcionales del software.
La prueba de Caja Negra
no es una alternativa a
las técnicas de prueba de la Caja Blanca, sino un enfoque complementario que
intenta descubrir diferentes tipos de errores a los encontrados en los métodos
de la Caja Blanca. Muchos autores consideran que estas pruebas permiten
encontrar:
Funciones incorrectas o ausentes.
Errores de interfaz.
Errores en estructuras de datos o en accesos a las Bases de Datos externas.
Errores de rendimiento.
Errores de inicialización y terminación.
Para preparar los casos de pruebas hacen falta un número de datos que
ayuden a la ejecución de los estos casos y que permitan que el sistema se
ejecute en todas sus variantes, pueden ser datos válidos o inválidos para el
programa según si lo que se desea es hallar un error o probar una
funcionalidad. Los datos se escogen atendiendo a las especificaciones del
problema, sin importar los detalles internos del programa, a fin de verificar que
el programa corra bien.
Para desarrollar la prueba de caja negra existen varias técnicas, entre ellas
están:
Técnica de la Partición de Equivalencia: esta técnica divide el campo de
entrada en clases de datos que tienden a ejercitar determinadas funciones del
software.
Técnica del Análisis de Valores Límites: esta Técnica prueba la habilidad del
programa para manejar datos que se encuentran en los límites aceptables.

10
Técnica de Grafos de Causa-Efecto: es una técnica que permite al encargado
de la prueba validar complejos conjuntos de acciones y condiciones.
Dentro del método de Caja Negra la técnica de la Partición de Equivalencia es
una de las más efectivas pues permite examinar los valores válidos e inválidos
de las entradas existentes en el software, descubre de forma inmediata una
clase de errores que, de otro modo, requerirían la ejecución de muchos casos
antes de detectar el error genérico. La partición equivalente se dirige a la
definición de casos de pruebas que descubran clases de errores, reduciendo
así en número de clases de prueba que hay que desarrollar.

TECNICA DE PRUEBA DE CAJA NEGRA

Partición equivalente
Una partición equivalente es una técnica de prueba de Caja Negra que divide el
dominio de entrada de un programa en clases de datos de los que se pueden
derivar casos de prueba. El diseño de estos casos de prueba para la partición
equivalente se basa en la evaluación de las clases de equivalencia.
El diseño de casos de prueba para la partición equivalente se basa en una
evaluación de las clases de equivalencia para una condición de entrada. Una
clase de equivalencia representa un conjunto de estados válidos o inválidos
para condiciones de entrada.
Regularmente, una condición de entrada es un valor numérico específico, un
rango de valores, un conjunto de valores relacionados o una condición lógica.
Las clases de equivalencia se pueden definir de acuerdo con las siguientes
directrices: Si un parámetro de entrada debe estar comprendido en un cierto
rango, aparecen 3 clases de equivalencia: por debajo, en y por encima del
rango.
Si una entrada requiere un valor concreto, aparecen 3 clases de equivalencia:
por debajo, en y por encima del rango.
Si una entrada requiere un valor de entre los de un conjunto, aparecen 2 clases
de equivalencia: en el conjunto o fuera de él.
Si una entrada es booleana, hay 2 clases: si o no.
Los mismos criterios se aplican a las salidas esperadas: hay que intentar
generar resultados en todas y cada una de las clases.
Aplicando estas directrices se ejecutan casos de pruebas para cada elemento
de datos del campo de entrada a desarrollar. Los casos se seleccionan de
forma que ejerciten el mayor número de atributos de cada clase de
equivalencia a la vez.
11
Para aplicar esta técnica de prueba se tienen en cuenta los siguientes pasos:
Primero se deben identificar las clases de equivalencia lo cual se hace
tomando cada condición de entrada y aplicándole las directrices antes
expuestas.
Para definir las clases de equivalencia hace falta tener en cuenta un conjunto
de reglas: Si una condición de entrada especifica un rango, entonces se
confeccionan una clase de equivalencia válida y 2 inválidas. Si una condición
de entrada especifica la cantidad de valores, identificar una clase de
equivalencia válida y dos inválidas. Si una condición de entrada especifica un
conjunto de valores de entrada y existen razones para creer que el programa
trata en forma diferente a cada uno de ellos, identificar una clase válida para
cada uno de ellos y una clase inválida. Si una condición de entrada especifica
una situación de tipo “debe ser”, identificar una clase válida y una inválida. Si
existe una razón para creer que el programa no trata de forma idéntica ciertos
elementos pertenecientes a una clase, dividirla en clases de equivalencia
menores.
Luego de tener las clases válidas e inválidas definidas, se procede a definir los
casos de pruebas, pero para ello antes se debe haber asignado un identificador
único a cada clase de equivalencia.
Luego entonces se pueden definir los casos teniendo en cuenta lo siguiente:
Escribir un nuevo caso de cubra tantas clases de equivalencia válidas no
cubiertas como sea posible hasta que todas las clases de equivalencia hayan
sido cubiertas por casos de prueba.
Escribir un nuevo caso de prueba que cubra una y solo una clase de
equivalencia inválida hasta que todas las clases de equivalencias inválidas
hayan sido cubiertas por casos de pruebas.
Con la aplicación de esa técnica se obtiene un conjunto de pruebas que reduce
el número de casos de pruebas y nos dicen algo sobre la presencia o ausencia
de errores. A menudo se plantea que las pruebas a los software nunca
terminan, simplemente se transfiere del desarrollador al cliente. Cada vez que
el cliente usa el programa está llevando a cabo una prueba.
Aplicando el diseño de casos de pruebas al software en cuestión se puede
conseguir una prueba más completa y descubrir y corregir el mayor número de
errores antes de que comiencen las “pruebas del cliente”.
Procedimientos de prueba
Un procedimiento de prueba especifica como realizar uno o varios casos de
prueba o parte de estos. Por ejemplo un procedimiento de prueba puede ser
una instrucción para un individuo sobre como ha de realizar un caso de prueba
manualmente, o puede ser una especificaron de cómo interaccionar

12
manualmente con una herramienta de automatización de pruebas para crear
componentes ejecutables de pruebas.
El como llevar a cabo un caso de prueba puede ser especificado por un
procedimiento de prueba pero es a menudo útil reutilizar un procedimiento de
prueba para varios casos de prueba y reutilizar varios procedimientos de
prueba para varios casos de prueba.
Componentes de prueba
Un componente de prueba automatiza uno o varios procedimientos de prueba o
parte de ellos.
Los componentes de pruebas pueden ser desarrollados utilizando lenguaje de
guiones o un lenguaje de programación o pueden ser grabados con una
herramienta de automatización de pruebas.
Los componentes de pruebas se utilizan para probar los componentes en el
modelo de implementación proporcionando entradas de prueba, controlando y
monitorizando la ejecución de los componentes a probar y, posiblemente
informando de los resultados de las pruebas.
Plan de Prueba
El propósito del plan de pruebas es dejar de forma explicita el alcance, el
enfoque, los recursos requeridos, el calendario, los responsables y el manejo
de riesgos de un proceso de pruebas.
Está constituido por un conjunto de pruebas. Cada prueba debe:
Dejar claro qué tipo de propiedades se quieren probar (corrección, robustez,
fiabilidad, amigabilidad,...).
Dejar claro cómo se mide el resultado.
Especificar en qué consiste la prueba (hasta el último detalle de cómo se
ejecuta).
Definir cual es el resultado que se espera (identificación, tolerancia,...). ¿Cómo
se decide que el resultado es acorde con lo esperado?
Las pruebas carecen de utilidad, tanto, sí no se sabe exactamente lo que se
quiere probar, sí no se está claro cómo se prueba, o si el análisis del resultado
se hace a simple vista. Estas mismas ideas se suelen agrupar diciendo que un
caso de prueba consta de 3 bloques de información:
El propósito de la prueba.
Los pasos de ejecución de la prueba.
El resultado que se espera.
Todos y cada uno de esos puntos deben quedar perfectamente documentados.
El plan de pruebas señala el enfoque, los recursos y el esquema de actividades
13
de prueba, así como los elementos a probar, las características, las actividades
de prueba, el personal responsable y los riesgos.
Una estrategia de prueba propone movernos hacía afuera en una espiral, de
manera que primero se prueban las unidades más pequeñas del diseño del
software (clases o módulos) y después como se integran los componentes en
los cuales están contenidas estas unidades.
RUP propone definir casos de prueba de integración para verificar que los
componentes interaccionan entre sí de forma apropiada.
A partir de un caso de uso se pueden realizar pruebas de caja negra,
obteniéndose varios casos de prueba que permiten:
Verificar el resultado de la interacción entre los actores y el sistema.
Comprobar que se satisfagan las precondiciones y poscondiciones del caso de
uso.
Comprobar que se siga la secuencia de acciones especificado por el caso de
uso.
También se pueden realizar pruebas de caja blanca a partir de la realización de
un caso de prueba que permiten obtener casos de prueba en los que se verifica
la integración ante los componentes que implementan dicho caso de uso.
Como conclusión se podría decir que se pueden definir múltiples casos de
prueba de integración para cada caso de uso en dependencia de las
condiciones de prueba que se tengan en cuenta. El formato para describirlos
podría ser:
Variante 1
Caso de uso: <Nombre>
Caso de prueba: <Nombre>
Entrada:<Descripción textual de lo que ocurre en el mundo real que hace
necesario ejecutar el caso de prueba, precisando la data de entrada y los
comandos a dar por el actor. Descripción textual del estado de la información
almacenada>
Resultado:<Descripción textual del estado en el que queda la información y las
alertas que puedan generarse, una vez ejecutado el caso de uso con los
valores y el estado especificado en la entrada>
Condiciones:<Condiciones que deben cumplirse mientras se ejecuta el caso de
prueba>
Variante 2
Caso de uso:<Nombre>
Rango de Valores de Entrada
14
Rango de Valores de Salida
Esta 2da variante se usa cuando hay varios casos de prueba que verifican
diferentes escenarios del mismo caso de uso.
Las pruebas del sistema se usan para probar que el sistema funciona
correctamente como un todo.
Como parte de estas pruebas hay que:
Probar la instalación del software en la plataforma del cliente.
Verificar el funcionamiento del software en diferentes configuraciones.
Realizar pruebas negativas que busquen que el sistema falle.
Realizar pruebas de tensión o estrés cuando hay competencia por los recursos.
Defecto
Un defecto es una anomalía del sistema, como por ejemplo un síntoma de una
fallo software o un problema descubierto en una revisión. Un defecto puede ser
utilizado para localizar cualquier cosa que los desarrolladores necesitan
registrar como síntoma de un problema en el sistema que ellos necesitan
controlar y resolver.
Evaluación de prueba
Una evaluación de prueba es una evaluación de los resultados de los esfuerzos
de prueba, tales como la cobertura del caso de prueba, la cobertura del código
y el estado de los defectos.

15
TECNICAS DE CAJA BLANCA

Las técnicas de evaluación dinámica proporcionan distintos criterios para generar casos de prueba que
busquen fallos en los programas.

Las técnicas de caja blanca o estructurales, que se basan en un minucioso examen de los detalles
procedimentales del código a evaluar, por lo que es necesario conocer la lógica del programa.
CARACTERÍSTICAS DE LAS TÉCNICAS DE CAJA BLANCA

A este tipo de técnicas se le conoce también como Técnicas de Caja Transparente o de Cristal.

• Este método se centra en cómo diseñar los casos de prueba atendiendo al comportamiento interno y la
estructura del programa.

• Se examina así la lógica interna del programa sin considerar los aspectos de rendimiento.

• El objetivo de la técnica es diseñar casos de prueba para que se ejecuten, al menos una vez, todas las sentencias
del programa, y/o todas las condiciones tanto en su vertiente verdadera como falsa.

CRITERIOS DE COBERTURA

Puede ser impracticable realizar una prueba exhaustiva de todos los caminos o sentencias de un programa => se
han definido distintos criterios de cobertura lógica, que permiten decidir qué sentencias o caminos se deben
examinar con los casos de prueba.

• Técnicas de cobertura de caminos

• Técnicas de control de flujo
• ‘Técnicas de cobertura de ciclos
TÉCNICAS DE COBERTURA DE CAMINOS

CRITERIOS DE COBERTURA

TÉCNICAS DE COBERTURA DECAMINOS

Camino: Secuencia de sentencias encadenadas desde la entrada del programa hasta su salida.

• Se escriben casos de prueba suficientes para que se ejecuten todos | algunos de los caminos de un programa.

• Criterios:

 Todos los caminos

 Cobertura de Sentencias

 Ramas

 Predicados

 Ruta básica
SÍMBOLOS DEL GRAFO DEL CONTROL DE FLUJO
EJEMPLOS DE CAMINOSPOSIBLES
CRITERIO DE COBERTURA DE TODOS LOS CAMINOS

• No es muy práctico por la cantidad de rutas a probar.

• Un programa puede tener un gran número de rutas a probar o un número infinito.

• Este criterio es considerable siempre que detecte los fallos, sin embargo se presenta mucha dificultad para llevar
a la práctica.

CRITERIO DE COBERTURA DESENTENCIA

• Una cobertura de sentencias se ha logrado si todos las declaraciones han sido ejecutadas al menos una vez.
• 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.
Ejemplos

• Asignaciones y llamados a métodos

• break, continue, return, throw, etc.
• Variables y miembros de declaraciones con asignación: (int i = 0)
EJEMPLO CRITERIO DE COBERTURA DE SENTENCIA
CRITERIO DE COBERTURA DERAMAS

Rama: es una arista saliente de un nodo.

• Todos los nodos rectángulo debe tener como máximo una rama de salida.
• Todos los nodos de diamante tiene dos ramas de salida.
• Cobertura de ramas completa significa la selección de un número de caminos de manera que cada rama se
incluye en al menos una ruta.
Ejemplos:

• if y else
• switch-branches: case and default

EJEMPLO CRITERIO DE COBERTURA DE RAMAS

CRITERIO COBERTURA DE PREDICADOS
PROCEDIMIENTO CRITERIO DE RUTA(CAMINO)BÁSICA(CO)

Se escriben casos de prueba suficientes para que se ejecuten todos los caminos de un programa.

• Los pasos a realizar para aplicar esta técnica son:

 Representar el programa en un grafo de flujo
 Calcular la complejidad ciclomática
 Determinar el conjunto básico de caminos
independientes
 Derivar los casos de prueba.
 REPRESENTAR EL PROGRAMA EN UN GRAFO DE FLUJO

WHILE • Nodos: Representan cero, una o varias

Secuencia sentencias.

•Aristas: líneas que unen dos nodos.

• Regiones: áreas delimitadas por aristas y
nodos. Cuando se contabilizan las regiones de
un programa debe incluirse el área externa
como una región más

IF Nodos Predicado: Cuando en una condición

aparecen uno o más operadores lógicos (AND, OR,
XOR,
...) se crea un nodo distinto por cada una de las
condiciones simples.
Cada nodo generado de esta forma
se denomina nodo predicado.

Case
REPRESENTAR EL PROGRAMA EN UN GRAFO DE FLUJO

Nodos
Predicado
a
IF a OR b
False True
THEN X
ELSE Y b x
ENDIF
False

y
REPRESENTAR EL PROGRAMA EN UN GRAFO DE FLUJO

1
Paso de diagrama de flujo a grafo de flujo

3 4
2

3
5 6
4
6

5 7
7 8
9 8
10
11

9
CALCULAR LA COMPLEJIDADCICLOMÁTICA

• 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 limite
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
Calculo de la complejidad ciclomática

• V(G) = Número de regiones

• V(G) = Aristas - Nodos + 2
• V(G) = Número de nodos predicado + 1
CALCULAR LA COMPLEJIDADCICLOMÁTICA

• Considerando el grafo, encontramos el siguiente

conjunto de caminos independientes:
 Camino 1: 1-9
 Camino 2: 1-2-4-8-1-9
 Camino 3: 1-2-3-6-7-8-1-9
 Camino 4: 1-2-3-5-7-8-1-9
• Cada nuevo camino introduce un arco nuevo.
• No se consideran caminos independientes
aquellos que resulten de la combinación de otros
caminos.
• El conjunto básico no es único.
• Se debe elegir como primer camino aquel que
atraviese el mayor número de decisiones en el
grafo.
CALCULAR LA COMPLEJIDADCICLOMÁTICA

Para el caso del grafo anterior, el conjunto básico calculado en todos los casos da 4.

• V(G) = Número de regiones = 4

• V(G) = Aristas – Nodos + 2 =11-9 + 2 = 4
• V(G) = Nodos Predicado + 1 = 3 +1 = 4
TÉCNICAS DE CONTROL DE FLUJO

TÉCNICAS DE CONTROL DEFLUJO

• 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.
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.

• Miremos el siguiente ejemplo:

if (a>0) { x = x + 1; }
if (b==3) { y = 0; }

COBERTURA DE DECISIÓN

• 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.
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.

• Para entender esto miremos el ejemplo:

 if (a>0) {x = x + 1;}
 if (b==3) {y = 0;}

• Supongamos que se van a ejecutar los siguientes casos de

prueba:

 a = 2 y b = 3 (a verdadero, b verdadero)
 a = -2 y b = 3 (a falso, b verdadero

COBERTURA DE CONDICIONES

Con la primera prueba, la parte válida de la condición será recorrida.

Con la segunda prueba, la parte inválida de la condición será ejecutada.

Sin embargo, notemos como el valor de b en los dos casos de

prueba es verdadero.

Tendríamos los mismos resultados que si probáramos los dos casos para la siguiente sentencia:

if (a>0) {x = x + 1;}

La condición b no estaría siendo evaluado en su parte invalida.

COBERTURA DE CONDICIONES

La cobertura de condición en este caso nos diría que ejecutáramos las siguientes pruebas:

1. (a verdadero, b falso)
2. (a falso, b verdadero)

La condición a sería probada en su parte valida e invalida y de igual manera la condición b.

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
COBERTURA DE CICLOS

Como existen diferentes tipos de ciclos hay que tenerlos en cuenta a la hora de analizarlos. Los tipos son:
• Simple
• Anidado
• Concatenado
• No estructurado
Además también hay que tener las diferentes sentencias que hay para representar un ciclo:
• While
• Repeat
• For
COBERTURA DE CICLOS

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.

COBERTURA DE 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<n
• Pasar n-1 y n+1 vecesConcatenado
COBERTURA DE CICLOS

Ciclos Anidados:
Estos ciclos son aquellos que tienen un ciclo en su interior

Tenemos las siguientes reglas

• Hacer pruebas con el bucle mas interno y tratarlo como si fuera

simple y el externo mantener el numero mínimo de iteraciones

• Pruebas hacia fuera, para los internos mantener valores típicos y

externos valores mínimos.
COBERTURA DE CICLOS

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 si 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.
COBERTURA DE CICLOS

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 practica de programación
y seria altamente riesgoso para el software
COBERTURA DE CICLOS

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 mas de 1 ejecución
COBERTURA DE CICLOS

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
COBERTURA DE CICLOS

Sentencias de ciclo For:

Con este aparentemente sería sencillo sólo se tendría que hacer 1 Prueba, pues el ya tiene el numero 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.

HERRAMIENTAS AUTOMÁTICAS PARA TÉCNICAS DE CAJA BLANCA

Herramienta Lenguaje

Coverage Pyton Pyton

PHPUnit PHP

JUnit JAVA

CodeCover Java, Cobol

JsCoverage JavaScript

Ncover Microsoft .Net