Pruebas de software

Andrés Camilo González Romero

430060550
David Enrique Velandia Ávila
430061745

Ing. Alexander Montoya

Universidad Piloto De Colombia Seccional Del Alto Magdalena

Ingeniería De Sistemas
Métodos Formales de Construcción de Software
Cundinamarca, Girardot
2021
 1. Como define las pruebas

R/
son las investigaciones empíricas y técnicas cuyo objetivo es proporcionar información
objetiva e independiente sobre la calidad del producto a la parte interesada o stakeholder.
Es una actividad más en el proceso de control de calidad.

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

La definición de prueba que aporta Myers es:

“La prueba es el proceso de ejecución de un programa con la intención de encontrar

errores”.

El ISTQB (International Software Testing Qualifications Board), una organización sin

ánimo de lucro creada en el año 2002 por empresas, instituciones, organizaciones y
personas especializadas en el campo de las pruebas y la industria del software define las
pruebas como:

“El proceso que consiste en todas las actividades del ciclo de vida, tanto estáticas como
dinámicas relacionadas con la planificación, preparación y evaluación de productos de
software y productos relacionados con el trabajo para determinar que cumplen los
requisitos especificados, para demostrar que son aptos para el propósito y para detectar
defectos”.

Error: está provocado por la acción humana. Por ejemplo, el error lo provocará el
desarrollador que realizará una incorrecta interpretación de un método del programa que
producirá un resultado no esperado.
Defecto: provocado por un error de implementación. Por ejemplo, el defecto lo provocará
el haber utilizado el operador “x + y > z” en vez de “x + y => z”

Fallo: al ejecutar el programa con un defecto obtendremos resultados no deseados, por

ejemplo, cuando el resultado de la suma de los dos componentes fuese igual, no
obtendríamos los mismos resultados al compararlos con las sentencias indicadas
anteriormente. En sistemas muy complejos, como pueden ser una lanzadera espacial o una
central eléctrica, pueden llegar a producir efectos catastróficos.

2. Historia
R/
El objetivo de las pruebas es presentar información sobre la calidad del producto a las
personas responsables de este. Las pruebas de calidad presentan los siguientes objetivos:
encontrar defectos o bugs, aumentar la confianza en el nivel de calidad, facilitar
información para la toma de decisiones, evitar la aparición de defectos.

Teniendo esta afirmación en mente, la información que puede ser requerida es de lo más
variada. Esto hace que el proceso de testing sea completamente dependiente del contexto en
el que se desarrolla. El ambiente ideal de las pruebas es aquel que es independiente del
desarrollo del software, de esta manera se logra objetividad en las pruebas. A pesar de lo
que muchos promueven, no existen las "mejores prácticas" como tales. Toda práctica puede
ser ideal para una situación, pero completamente inútil o incluso perjudicial en otra.

Por esto, las actividades técnicas, documentación, enfoques y demás elementos que
condicionarán las pruebas a realizar deben ser seleccionadas y utilizadas de la manera más
eficiente según contexto del proyecto.

Demostración (1957-1958)

En esta fase se encargaban de utilizar de forma masiva la prueba para asegurar que se
cumplía con la especificación. Se realizaban al finalizar el desarrollo del Software.
Destrucción (1979 – 1982)

Los cambios en la metodología se hicieron notar, en este período pasaron de demostrar que
un programa era correcto mediante pruebas y demostraciones teóricas a demostrar que el
programa no funciona o tiene fallos, con este cambio de óptica, se tiene una mayor
posibilidad de encontrarlos, las pruebas se transforman en casos de prueba que se aplican a
los productos de los desarrolladores para encontrar errores y corregirlos.

Evaluación (1983 – 1984)

Esta fue una etapa donde se comenzó a integrar las pruebas de Software en el ciclo de vida
del desarrollo del software.

Prevención (1985 – Actual)

Finalmente, en esta época se diversificaron las pruebas incorporándolas en todas las fases
del desarrollo, para con esto poder verificar todos los tipos de componentes, modelos,
módulos, subsistemas y sistemas que conforman el software.

3. Como es el proceso de Desarrollo de software

R/

Tenemos el proceso de desarrollo en cascada, se denomina de este modo, ya que a cada

salida de una etapa cae en la siguiente, es decir, las etapas se llevan a cabo una a
continuación de la otra. Una de las peculiaridades de este proceso, es que no está previsto
volver a una etapa anterior, es decir si se olvidó relevar algún requerimiento al comienzo,
no tiene una alternativa para considerar este caso. Este proceso supone cada etapa
independiente de las etapas anteriores.

También tenemos el desarrollo iterativo y creciente, se tiene las mismas etapas que en el
Proceso de Desarrollo en Cascada, sin embargo, en este proceso, la etapa de relevamiento
se divide en distintos sub conjuntos,y cada uno de estos sub conjuntos se construye de la
misma forma que con el ciclo de vida en cascada. Se van desarrollando por partes que
luego se integran, una vez finalizadas las mismas.

Otro Proceso de Desarrollo que tenemos es el Iterativo, en este tenemos las mismas etapas
de desarrollo que los procesos anteriores, pero trabajamos sobre el todo, no necesariamente
conocemos al comienzo todos los detalles del producto que queremos construir.

Y por último tenemos el desarrollo ágil de software, este es un proceso iterativo e

incremental, se caracteriza por contar con iteraciones cortas y por no tener fases lineales,
tipo cascada en cada iteración. Existen distintas metodologías Ágiles, que entre las más
conocidas y utilizadas encontramos "Scrum" y "XP: Extreme Programming".

Ilustración 1. Modelo en cascada del desarrollo de software

En la imagen anterior se puede observar las fases que se desarrollan en este método, se
llevarían a cabo una seguida de la otra. Además, también se puede volver a la anterior. La
documentación se realiza durante todo el proceso.

Definición:
En esta etapa se elige la posible solución con mejores especificaciones y sea la adecuada.
Se plantea la estructura que tendrá el software, para tener totalmente definido y estar listos
para la siguiente etapa.
En este nivel se concreta la estructura de control y flujo de datos, para entender los
algoritmos. Por último, el resultado de esta etapa puede ser un organigrama, un
pseudocódigo, etc.

Codificación:
Es el proceso donde se comienza a realizar la programación mediante un lenguaje. Pero se
debe tener en cuenta que el diseño sea el correcto y que este bien estructurado para no tener
inconvenientes.
Para calificar que la codificación fue la correcta se debe llevar un trabajo muy grande.
Debido a que para un diseño pueden existir gran variedad de posibles soluciones y por lo
tanto es difícil decidir cuál es la mejor. Por otro lado, cuando son varios los programadores
los que intervienen pueden generar algunos problemas al realizar cambios, porque cada
programador tiene diferente forma de pensar. Por eso es importante tener claro los
estándares del software.

Integración:
En esta etapa una vez todo este codificado, se procede a unir todas las partes. Pero no solo
es el proceso de ensamble. También eso donde se corrigen problemas entre módulos.
Cuando el software es demasiado grande, las versiones se vuelven parte fundamental para
el desarrollo correcto.

Prueba:
En esta etapa se busca que se cumplan todos los objetivos de manera correcta. Aunque en la
práctica es casi imposible lograr que alguien pruebe por completo el software, por esto
siempre quedan algunos errores o bugs que más adelante serán corregidos. Pero si no son
corregidos a tiempo se generan actualizaciones que, en vez de aportar soluciones, aportan
son más problemas.

Documentación:
La documentación es una parte fundamental en el desarrollo del software porque
prácticamente es el software en sí, contiene todo lo relacionado con él. Partiendo desde
documentar todo el ciclo de vida, hasta el código de programación.
Además, es donde se plasman todas las funciones y como el usuario puede hacer uso de
todas las herramientas que el software otorga.
 4. Pruebas estáticas vs dinámicas
R/
Pruebas de software
Dinámicas
Todas aquellas pruebas que para su
ejecución requieren la ejecución de
la aplicación.
Las pruebas dinámicas permiten el
uso de técnicas de caja negra y caja
blanca con mayor amplitud. Debido
a la naturaleza dinámica de la
ejecución de pruebas es posible
medir con mayor precisión el
comportamiento de la aplicación
desarrollada.
En ejecución: Las pruebas se
realizan mientras el código está en
ejecución.
Detección: Estas pruebas se enfocan
en la detección de defectos
Pruebas tardías: Estas pruebas se
realizan cuando el código es
desplegado a un ambiente de
pruebas.
Técnicas: Se utilizan tipos de
pruebas
• Funcionales
• No funcionales
Estáticas
Son el tipo de pruebas que se
realizan sin ejecutar el código de la
aplicación.
Puede referirse a la revisión de
documentos, ya que no se hace una
ejecución de código. Esto se debe a
que se pueden realizar "pruebas de
escritorio" con el objetivo de seguir
los flujos de la aplicación.
No ejecución: Las pruebas se
realizan a productos de trabajo como
documentos de requerimientos, casos
de prueba, planes de prueba y
código.
Prevención: Estas pruebas se
enfocan en la prevención de
defectos.
Pruebas tempranas: Estas pruebas
pueden ser realizadas desde las
primeras etapas del ciclo de vida del
software.
Técnicas: Se utilizan técnicas como
• Revisión técnica
• Inspección
• Revisión de código
• Revisión informal
• Revisión informal
 5. Como es la clasificación de las pruebas
R/
PRUEBAS UNITARIAS

Objetivo de la Prueba: Se focaliza en ejecutar cada módulo, lo que provee un mejor modo
de manejar la integración de las unidades en componentes mayores.

Busca asegurar que el código funciona de acuerdo con las especificaciones y que el módulo
lógico es válido.

Descripción de la Prueba: Particionar los módulos en pruebas en unidades lógicas fáciles

de probar. Por cada unidad hay que definir los casos de prueba (pruebas de caja blanca).

Para esto los casos de prueba deben diseñarse de forma tal que se recorran todos los
caminos de ejecución posibles dentro del código bajo prueba; por lo tanto, el diseñador
debe construirlos con acceso al código fuente de la unidad a probar.

Los aspectos para considerar son los siguientes: Rutinas de excepción, Rutinas de error,
Manejo de parámetros, Validaciones, Valores válidos, Valores límites, Rangos, Mensajes
posibles.

Técnica: Comparar el resultado esperado con el resultado obtenido. Si existen errores,

reportarlos.

Criterio de Completitud: Todas las pruebas planeadas han sido ejecutadas. Todos los
defectos que se identificaron han sido tenidos en cuenta.

Consideraciones Especiales: Para la elaboración de pruebas unitarias en java se puede

utilizar el JUNIT y CACTUS.
PRUEBAS DE INTEGRACIÓN

Objetivo de la Prueba: Identificar errores introducidos por la combinación de programas

probados unitariamente.

• Determina cómo la base de datos de prueba será cargada.

• Verificar que las interfaces entre las entidades externas (usuarios) y las aplicaciones
funcionan correctamente.
• Verificar que las especificaciones de diseño sean alcanzadas.

• Determina el enfoque para avanzar desde un nivel de integración de las

componentes al siguiente.

Descripción de la Prueba:

• Describe cómo verificar que las interfaces entre las componentes de software
funcionan correctamente.
• Determina cómo la base de datos de prueba será cargada.
• Determina el enfoque para avanzar desde un nivel de integración de las
componentes al siguiente.
• Decide qué acciones tomar cuando se descubren problemas.

Por cada Caso de Prueba ejecutado: Comparar el resultado esperado con el resultado
obtenido.

Técnica:

Utilizar la técnica top-down. Se empieza con los módulos de nivel superior, y se verifica
que los módulos de nivel superior llaman a los de nivel inferior de manera correcta, con los
parámetros correctos.
Criterio de Completitud:

• Todas las pruebas planeadas han sido ejecutadas.

• Todos los defectos que se identificaron han sido tenidos en cuenta.

Consideraciones Especiales: Ninguna

PRUEBA DE REGRESIÓN

Objetivo de la Prueba: Determinar si los cambios recientes en una parte de la aplicación

tienen efecto adverso en otras partes.

Descripción de la Prueba: En esta prueba se vuelve a probar el sistema a la luz de los

cambios realizados durante el debugging, mantenimiento o desarrollo de la nueva versión
del sistema buscando efectos adversos en otras partes.

Técnica: La prueba de regresión es una nueva corrida de casos de prueba previos. Se

requiere de políticas para ser creada la prueba de regresión y decidir qué casos de prueba
incluir, para probar eficientemente.

• La prueba de regresión es un buen candidato para automatización. Desde que estas

pruebas se repiten una y otra vez, las herramientas para minimizar el esfuerzo del
trabajo son útiles.
• La prueba de viejas funcionalidades es más importante que la de nuevas
funcionalidades.
• Aquellos casos de uso (y los casos de prueba asociados) que descubren defectos
tempranamente deben ser incluidos en la prueba de regresión.

Criterio de Completitud: Todas las pruebas planeadas han sido ejecutadas. Todos los
defectos que se identificaron han sido tenidos en cuenta.

Consideraciones Especiales: Ninguna

PRUEBAS DE HUMO (SMOKE TESTING O AD HOC)

Objetivo de la Prueba: Detectar los errores en realeases tempranos y de manera fácil

• Probar el sistema constantemente

• Garantizar poco esfuerzo en la integración final del sistema
• Asegurar los resultados de las pruebas unitarias
• Se reducen los riesgos y a baja calidad.

Descripción de la Prueba:

Toma este nombre debido a que su objetivo es probar el sistema constantemente buscando
que saque “humo” o falle. En algunos proyectos este tipo de prueba va junto con las
pruebas funcionales. Permite detectar problemas que por lo regular no son detectados en las
pruebas normales. Algunas veces, si las Pruebas ocurren tarde en el ciclo de desarrollo está
será una forma de garantizar el buen desarrollo.

Técnica:

• Realizar una integración de todo el sistema cada cierto periodo (se recomienda un
día, máximo una semana).
• Realizar los casos de prueba asignados a los casos de uso finalizados ese día más los
realizados en días anteriores.
• Buscar eficientemente errores.

Criterio de Completitud:

• Todas las pruebas planeadas han sido ejecutadas.

• Todos los defectos que se identificaron han sido tenidos en cuenta.

Consideraciones Especiales:

Cuando se encuentre un error en el reléase correspondiente al periodo elegido para hacer las
integraciones del sistema, se detiene el desarrollo hasta que el error es corregido.
Este tipo de pruebas es útil en la programación extrema (extremme programming) y de
sistemas complejos. Es útil el uso de programas de prueba automáticas que se encarguen de
probar os casos de prueba ya ejecutados en realeases anteriores.

PRUEBAS DEL SISTEMA

Objetivo de la Prueba: Asegurar la apropiada navegación dentro del sistema, ingreso de

datos, procesamiento y recuperación.

Descripción de la Prueba: Las pruebas del sistema deben enfocarse en requisitos que
puedan ser tomados directamente de casos de uso y reglas y funciones de negocios. El
objetivo de estas pruebas es verificar el ingreso, procesamiento y recuperación apropiado
de datos, y la implementación apropiada de las reglas de negocios. Este tipo de pruebas se
basan en técnicas de caja negra, ésto es, verificar el sistema (y sus procesos internos), la
interacción con las aplicaciones que lo usan via GUI y analizar las salidas o resultados.

En esta prueba se determina qué pruebas de Sistema (usabilidad, volumen, desempeño, etc.)
asegurarán que la aplicación alcanzará sus objetivos de negocio.

La prueba de Sistema incluye:

• Prueba funcionalidad
• Prueba de Usabilidad
• Prueba de Performance
• Prueba de Documentación y Procedimientos
• Prueba de Seguridad y Controles
• Prueba de Volumen
• Prueba de Esfuerzo (Stress)
• Prueba de recuperación
• Prueba de múltiples sitios
Para sistemas web se recomienda especialmente realizar mínimo el siguiente grupo de
pruebas de sistema:

• Humo.
• Usabilidad
• Performance
• Funcionalidad

Para capitalizar el trabajo hasta ahora completado, los casos de prueba de las pruebas
previas realizadas pueden frecuentemente ser reorganizados y rehusados durante la prueba
de sistema. No obstante, deben ser desarrollados casos de prueba adicionales para aquellos
aspectos del sistema, tales como documentación, procedimientos y desempeño que no han
sido probados durante la prueba unitaria y de integración.

La prueba de sistema es compleja porque intenta validar un número de características al

mismo tiempo, a diferencia de otras pruebas que sólo se centran en uno o dos aspectos del
sistema al mismo tiempo.

Técnica:

Ejecute cada caso de uso, flujo básico o función utilizando datos válidos e inválidos, para
verificar que:

• Los resultados esperados ocurren cuando se utiliza un dato válido.

• Los mensajes de error o de advertencia aparecen en el momento adecuado, cuando
se utiliza un dato inválido.
• Cada regla de negocios es aplicada adecuadamente.

Criterio de Completitud:

• Todas las pruebas planeadas han sido ejecutadas.

• Todos los defectos que se identificaron han sido tenidos en cuenta.

Consideraciones Especiales: Identifique o describa aquellos aspectos (internos o externos)

que impactan la implementación y ejecución de las pruebas del Sistema
PRUEBAS DE DESEMPEÑO

Objetivo de la Prueba:

Validar el tiempo de respuesta para las transacciones o funciones de negocios bajo las
siguientes dos condiciones:

• Volumen normal anticipado

• Volumen máximo anticipado.

Descripción de la Prueba:

Las pruebas de desempeño miden tiempos de respuesta, índices de procesamiento de

transacciones y otros requisitos sensibles al tiempo. El objetivo de las pruebas de
desempeño es verificar y validar los requisitos de desempeño que se han especificado (en
este caso, el desempeño ofrecido por el proponente).

Las pruebas de desempeño usualmente se ejecutan varias veces, utilizando en cada una,
carga diferente en el sistema. La prueba inicial debe ser ejecutada con una carga similar a la
esperada en el sistema. Una segunda prueba debe hacerse utilizando una carga máxima.

Adicionalmente, las pruebas de desempeño pueden ser utilizadas para perfilar y refinar el
desempeño del sistema como una función de condiciones tales como carga o
configuraciones de hardware.

Las principales actividades son:

• Comparar el desempeño del sistema actual con los requisitos.

• Poner a punto el sistema para mejorar las métricas de desempeño y proyectar la
capacidad futura de carga del sistema.

Los objetivos de nivel de servicio definidos deben guiar la prueba de performance.

Algunas características que afectan el desempeño son:

• Errores lógicos
• Procesamiento ineficiente
 • Diseño pobre: muchas interfases, instrucciones y entradas/salidas.
• Cuellos de botella en discos, CPU ó canales de entrada/salida
• Salidas del sistema
• Tiempos de respuesta
• Capacidad de almacenamiento
• Tasa de entrada/salida de datos
• Número de transacciones que pueden ser manejadas simultáneamente.
• Las pruebas de desempeño utilizan las técnicas de caja blanca y caja negra.

Técnica:

Utilice los procedimientos de prueba desarrollados para las pruebas del modelo del negocio
(Pruebas del Sistema).

Modifique archivos de datos (para incrementar el número de transacciones) o los scripts

para incrementar el número de veces que ocurre cada transacción. ·

Los scripts deben ser ejecutados en una máquina y deben ser repetidos con múltiples
clientes (virtuales o actuales).

Criterio de Completitud:

Un Usuario / Una Transaccion. Se completaron las pruebas sin ninguna falla y dentro del
tiempo esperado o requerido por transacción.

Múltiples transacciones, múltiples usuarios. Se completaron las pruebas de los scripts sin
ninguna falla y dentro del tiempo esperado.

Consideraciones Especiales:

Unas pruebas de desempeño integrales incluyen tener una carga en background en el

servidor. Hay varios métodos que pueden ser utilizados para hacer esto:

Transacciones dirigidas directamente al servidor, usualmente en forma de sentencias SQL.

Creación de usuarios virtuales para simular muchos clientes (usualmente varios cientos). Se
utilizan herramientas de Emulación de Terminales Remotas para obtener esta carga. Esta
técnica también puede ser utilizada para cargar de tráfico la red.

Use múltiples clientes físicos, cada uno corriendo los scripts de prueba.

Las pruebas de desempeño deben ser ejecutadas en una máquina dedicada o en un tiempo
dedicado. Esto permite control total y medidas precisas.

La Base de datos utilizada para pruebas de desempeño debe ser de un tamaño real o
proporcionalmente más grande que la diseñada.

PRUEBAS DE CARGA

Objetivo de la Prueba:

Verificar el tiempo de respuesta del sistema para transacciones o casos de uso de negocios,
bajo diferentes condiciones de carga.

Descripción de la Prueba:

Las pruebas de carga miden la capacidad del sistema para continuar funcionando
apropiadamente bajo diferentes condiciones de carga.

La meta de las pruebas de carga es determinar y asegurar que el sistema funciona

apropiadamente aún más allá de la carga de trabajo máxima esperada. Adicionalmente, las
pruebas de carga evalúan las características de desempeño (tiempos de respuesta, tasas de
transacciones y otros aspectos sensibles al tiempo).

Técnica:

• Use los scripts desarrolladas para Pruebas del Negocio.

• Modifique archivos de datos (para incrementar el número de transacciones o veces
que cada transacción ocurre).
Criterio de Completitud:

Múltiples transacciones, múltiples usuarios. Se completaron las pruebas de los scripts sin
ninguna falla y dentro del tiempo esperado.

Consideraciones Especiales:

Las pruebas de carga deben ser ejecutadas en una máquina dedicada o en un tiempo
dedicado. Esto permite control total y medidas precisas.

La Base de datos utilizada para pruebas de desempeño debe ser de un tamaño real o
proporcionalmente más grande que la diseñada.

PRUEBAS DE STRESS

Objetivo de la Prueba:

Verificar que el sistema funciona apropiadamente y sin errores, bajo estas condiciones de
stress:

• Memoria baja o no disponible en el servidor.

• Máximo número de clientes conectados o simulados (actuales o físicamente
posibles).
• Múltiples usuarios desempeñando la misma transacción con los mismos datos.
• El peor caso de volumen de transacciones (ver pruebas de desempeño).

Descripción de la Prueba:

Las pruebas de stress se proponen encontrar errores debidos a recursos bajos o completitud
de recursos. Poca memoria o espacio en disco puede revelar defectos en el sistema que no
son aparentes bajo condiciones normales. Otros defectos pueden resultar de incluir recursos
compartidos, como bloqueos de base de datos o ancho de banda de la red. Las pruebas de
stress identifican la carga máxima que el sistema puede manejar.
El objetivo de esta prueba es investigar el comportamiento del sistema bajo condiciones
que sobrecargan sus recursos. No debe confundirse con las pruebas de volumen: un
esfuerzo grande es un pico de volumen de datos que se presenta en un corto período de
tiempo.

Puesto que la prueba de esfuerzo involucra un elemento de tiempo, no resulta aplicable a

muchos programas. Por ejemplo, a un compilador o a una rutina de pagos.

Es aplicable, sin embargo, a programas que trabajan bajo cargas variables, interactivos, de
tiempo real y de control de proceso.

Aunque muchas pruebas de esfuerzo representan condiciones que el programa encontrará

realmente durante su utilización, muchas otras serán en verdad situaciones que nunca
ocurrirán en la realidad. Esto no implica, sin embargo, que estas pruebas no sean útiles.

Si se detectan errores durante estas condiciones “imposibles”, la prueba es valiosa porque

es de esperar que los mismos errores puedan presentarse en situaciones reales, algo menos
exigentes.

Técnica:

• Use los scripts utilizados en las pruebas de desempeño.

• Para probar recursos limitados, las pruebas se deben correr en un servidor con
configuración reducida (o limitada).
• Para las pruebas de stress restantes, deben utilizarse múltiples clientes, ya sea
corriendo los mismos scripts o scripts complementarios para producir el peor caso
de volumen de transacciones.

Criterio de Completitud:

Todas las pruebas planeadas han sido ejecutadas y excedidas sin que el sistema falle. (O si
las condiciones en que el sistema falle ocurren por fuera de las condiciones especificadas).

Consideraciones Especiales:

Producir stress en la red puede requerir herramientas de red para sobrecargarla de tráfico.
El espacio en disco utilizado para el sistema debe ser reducido temporalmente para limitar
el espacio disponible para el crecimiento de la Base de datos.

Técnicas de prueba

Para conseguir el objetivo de que el producto tenga la calidad deseada vamos a ver
diferentes técnicas de prueba que se pueden aplicar a la hora de realizar las pruebas. Estas
técnicas tienen el objetivo de identificar condiciones de la prueba, casos de prueba y datos
de la prueba.

Estudiaremos tres tipos de técnicas de prueba:

• Técnicas estáticas.
• Técnicas dinámicas.
• Técnicas basadas en la experiencia.

Como se verá más adelante, las pruebas dinámicas detectan los fallos, mientras que las
pruebas estáticas detectan sus causas, los defectos.

Técnicas estáticas

Este tipo de técnicas son aquellas que no ejecutan la aplicación. Se llevan a cabo a nivel de
especificaciones. No ejecutan código, pero si realizarán un análisis estático del código. Se
realizarán revisiones de todos los documentos del proyecto como pueden ser las
especificaciones de diseño, de requisitos, los casos de prueba, etc.

Análisis estático

El análisis estático tiene como objetivo detectar defectos en el código fuente del software y
en los modelos de software, y se realizará sin ejecutar dicho software.

Para llevar a cabo estas pruebas se utilizan herramientas que analizan el código del
programa y las salidas generadas.
Estas pruebas ayudan a la detección temprana de defectos, ya sean aspectos sospechosos
del código o del diseño. Permiten identificar defectos que no se encuentran fácilmente
mediante las técnicas dinámicas.

Técnicas dinámicas

Este tipo de técnicas son las realizadas ejecutando la aplicación y son las utilizadas para el
diseño de los casos de prueba.

La mayoría del software puede probarse de dos maneras diferentes. Conociendo el

funcionamiento interno, podemos probar que todos los módulos encajan unos con otros, es
decir, desde una visión interna. Estas pruebas son las pruebas de caja blanca.

Al conocer las funciones específicas del producto se pueden llevar a cabo pruebas que
demuestren que estas funciones son operativas y la búsqueda de errores en dichas
funciones. Estas pruebas se realizan desde una visión externa, mediante las pruebas de caja
negra.

Estas dos técnicas nos ayudarán a definir los casos de prueba para tener la mayor
probabilidad de encontrar errores ahorrando esfuerzo y tiempo.

Técnica de caja blanca

La técnica de caja blanca, a veces definida como prueba de “caja de cristal” o “caja
transparente”, es una técnica de diseño de casos de prueba que usa la estructura de control
para obtener los casos de prueba.
 Ilustración 2. Caja blanca

Dentro de esta estructura de control podemos encontrar la estructura de un componente de

software como puede ser sentencias de decisiones, caminos distintos del código, la
estructura de una página, web, etc.

Los métodos de prueba de caja blanca aportan los siguientes puntos:

• Garantizan que todas las rutas del código se revisan al menos una vez.
• Revisan las condiciones lógicas.
• Revisan estructuras de datos.

Técnicas basadas en la experiencia

El ISTQB define también las técnicas basadas en la experiencia y las define como, “las
pruebas basadas en la experiencia son aquellas en las que las pruebas se derivan de la
habilidad e intuición del probador y de su experiencia con aplicaciones y tecnologías
similares”.

Estas pruebas pueden tener poca o mucha efectividad dependiendo de la experiencia del
probador y suelen aplicarse en proyectos donde la documentación es escasa o inadecuada.

Dos de las técnicas basadas en la experiencia son:

• Predicción de error.
• Pruebas exploratorias.
 6. Que herramientas se utilizan para realizar las pruebas

R/

Todos los proyectos, por muy pequeños que sean, pueden llegar a tener una cantidad de
casos de pruebas muy elevado, sin contar que las pruebas se repetirán varias veces debido a
las pruebas de regresión. Estos proyectos, necesitan de una administración, planificación y
ejecución, así como de herramientas que permitan realizar pruebas automáticas.

Para llevar a cabo estas tareas existen diferentes tipos de herramientas que ayudarán en todo
lo posible a que el proyecto se maneje más eficientemente y que ayudarán a conseguir la
calidad deseada. Existen herramientas que se utilizan para diseñar casos de prueba,
gestionar y administrar pruebas y monitorizar sistemas en pruebas. Una simple hoja de
datos puede ser considerada una herramienta de pruebas. Al inicio del proyecto, el
desarrollador y el probador son los encargados de estudiar y plantear el tipo de
herramientas necesarias que se van a usar durante el proyecto.

Se van a clasificar en varias categorías dependiendo del uso que se pueda hacer de ellas:

• Herramientas para pruebas estáticas.

• Herramientas para planificación y gestión de pruebas.
• Herramientas para pruebas de automatización.
• Drivers y Stubs.
• Herramientas para pruebas carga y rendimiento.
• Herramientas de monitorización y seguridad.

En los ejemplos que se mencionarán de las diferentes herramientas se diferenciará entre

herramientas de código abierto que serán gratuitas (libres) y herramientas comerciales
(pago por licencia), ya que todas ellas tienen sus ventajas e inconvenientes.
Herramientas para pruebas estáticas

Este tipo de herramientas ayudan a encontrar defectos en las etapas tempranas del proyecto.

Existen diferentes tipos de herramientas de pruebas estáticas. Se van a diferenciar entre

herramientas de revisión, análisis estático y herramientas de modelado.

Herramientas de revisión

Son útiles en los procesos de revisión, listas de comprobación y directrices de revisión, y se

utilizan para almacenar y comunicar comentarios de revisión, informes sobre defectos y
esfuerzos [ISTQB].

Análisis estático

Estas herramientas sirven para localizar defectos en el código antes de realizar las pruebas
dinámicas proporcionando soporte para aplicar las normas de codificación, análisis de
estructuras y las dependencias [ISTQB].

Herramientas de modelado

Herramientas que sirven para validar modelos de software, como por ejemplo modelos de
datos físicos (PDM) de una base de datos relacional, enumerando inconsistencia y
localizando defectos [ISTQB].

Ejemplos de herramientas

Hay una gran cantidad de herramientas presentes para las pruebas estáticas. A continuación,
se muestran algunas de estas herramientas:
PMD (libre): es un analizador de código fuente. Encuentra defectos comunes de
programación como las variables utilizadas, bloques catch vacíos, la creación de objetos
innecesarios, y así sucesivamente [WEB25].

ChekStyle (libre): es una herramienta de desarrollo para ayudar a los programadores a

chequear que el código Java cumple un estándar de codificación [WEB26].

SONAR (libre): es una herramienta que permite analizar, recopilar y visualizar métricas del
código fuente. Podríamos decir que es una mezcla entre las dos anteriores PMD y
ChekStyle [WEB27].

Simian (libre): herramienta que detecta software duplicado. Entre los lenguajes de
programación que acepta están, Java, C#, C++, C COBOL, Ruby, ASP, JSP, HTML, XML
y Visual Basic [WEB28].

FindBugs (libre): es una herramienta que detecta errores en el código. Se utiliza en java y
es capaz de encontrar errores con el manejo de hilos, el mal uso de los métodos del API,
etc. [WEB29].

MacCabeTest (pago por licencia): implementa una gran variedad de técnicas de prueba
derivadas de una evaluación de complejidad ciclomática y de otras mediciones [WEB30].

Herramientas para planificación y gestión

Las herramientas de gestión ayudan al probador a documentar y evaluar los casos de

pruebas. Tienen como objetivo proporcionar mecanismos que permitan realizar de una
manera controlada la documentación, el mantenimiento de las pruebas y la gestión de
resultados. Dentro de las herramientas de gestión no sólo tenemos las que gestionan las
pruebas, sino que también tenemos las que gestionan incidencias. Estas herramientas se
utilizan para documentar, analizar, distribuir y gestionar las incidencias dentro de un
proyecto

Las herramientas de planificación permiten al probador escoger una estrategia de prueba,

así como tener una visión general de los casos de prueba del proyecto.
Ejemplos de herramientas

Teslink (libre): es una herramienta que permite crear y gestionar casos de prueba y
organizarlos dentro de planes de prueba. Se puede ejecutar los casos de prueba a partir de
los planes creados en la misma herramienta. También permite la generación de informes,
así como priorizar y asignar tareas [WEB31].

Redmine (libre): es una aplicación para gestión y planificación de proyectos con interfaz
web. Está diseñada para facilitar el control y seguimiento de proyectos [WEB32].

Trello (libre): es una herramienta con interfaz web que permite organizar proyectos y
tareas. Está basada en el método ágil Kanban. [WEB33].

Mantis (libre): es una herramienta para gestionar incidencias. Permite llevar un control y
mantener un historial de las incidencias, así como especificar un número indeterminado de
opciones de la incidencias, como los estados de éstas (abierta, cerrada, resuelta, reabierta,
etc.), la severidad (baja, media, alta), etc. Es una herramienta con interfaz web [WEB34].

HP Quality Center (pago por licencia): esta herramienta es un todo en uno propiedad de
la empresa HP. El objetivo de esta herramienta es el control de la calidad de software y
tiene varios módulos que nos permitirán gestionar los requisitos de un proyecto, la gestión,
el diseño y la creación de pruebas y la gestión de incidencias. También tiene un módulo
para pruebas automáticas que se verá más adelante [WEB35].

IBM Rational Quality Manager (pago por licencia): tiene las mismas funciones y
características que la herramientas de HP, pero en este caso la empresa propietaria de esta
herramienta es IBM [WEB36].

Testopia (libre): Es un administrador de casos de prueba. Está diseñado para realizar el

seguimiento de casos de prueba desde el diseño de las pruebas hasta la gestión de
resultados. Es una herramienta con interfaz Web que maneja extensiones para interactuar
con Bugzilla [WEB37].

BugZilla (libre): Herramienta de gestión de incidencias al estilo de Mantis desarrollada por

Mozilla [WEB38].
Herramientas para pruebas de automatización

El objetivo de estas herramientas es la creación de scripts en diferentes lenguajes de

programación, dependiendo de la herramienta que vayamos a utilizar, que permitan ejecutar
las pruebas funcionales automáticamente.

Ejemplos de herramientas

Selenium (libre): es un conjunto de herramientas para automatizar los navegadores web a

través de muchas plataformas que nos permitirá crear conjuntos de prueba sobre
aplicaciones web. Permite la creación de scripts mediante una gran variedad de lenguajes
de programación como Java, Ruby, Phyton, etc. [WEB44].

QTP - Quick Test Professional (pago por licencia): es el módulo de automatización de la

empresa HP. Permite la automatización de casos de prueba y los scripts son programados
en Visual Basic Script [WEB36].

SoapUI (libre/pago por licencia): permite probar, simular y generar código de servicios
web partiendo del contrato de estos en formato WSDL y con vinculo SOAP sobre http
[WEB40].

Cucumber (libre): permite la automatización de la prueba de aceptación para aplicaciones

web. Está basada en BDD (Behaviour Driven development) y el lenguaje de generación de
scripts es Ruby [WEB41].

IBM Rational Automation Framework (pago por licencia): es el módulo para la

generación de scripts y automatización de pruebas de la empresa IBM que se puede integrar
con los módulos de gestión. Permite la generación de scripts con varios lenguajes de
programación [WEB36].
Herramientas de pruebas de carga y rendimiento

El objetivo de estas herramientas es simular situaciones límite en los sistemas y estudiar la

respuesta de estos. Muchos sistemas que trabajan en tiempo real requieren este tipo de
pruebas, donde se probará hasta dónde es capaz de llegar el sistema antes de sobrecargarse.
Estos sistemas en tiempo real como pueden ser, sistemas cliente/servidor o aplicaciones
web, tienen que cumplir un tiempo de respuesta.

Ejemplos de herramientas

Jmeter (libre): es una herramienta de pruebas de carga para analizar y medir el desempeño
de una variedad de servicios, con énfasis en aplicaciones web. Es una de las herramientas
más utilizadas para las pruebas de rendimiento [WEB42].

LoadUI (libre): es una herramienta de pruebas de carga y rendimiento que se integra con
SoapUI. Es la mejor alternativa a Jmeter [WEB43].

FunkLoad (libre): es una herramienta que permite realizar pruebas de carga de

aplicaciones web, monitorizar rendimiento de servidores o realizar pruebas de estrés para
comprobar la capacidad de recuperación de las aplicaciones [WEB44].

HP Load runner (pago por licencia): es el módulo de pruebas de carga que se integra
dentro del paquete de aplicaciones de HP [WEB35].
 Referencias

• fsevillablog. 2021. Pruebas de Software. [online] Available at:

<https://fsevillablog.wordpress.com/2017/02/18/pruebas-de-software/> [Accessed 3
October 2021].

• 2021. [online] Available at: <https://www.diariodeqa.com/post/pruebas-

din%C3%A1micas-vs-pruebas-est%C3%A1ticas> [Accessed 3 October 2021].

• Fyccorp.com. 2021. Pruebas de Software: Historia y Evolución. [online] Available

at: <https://www.fyccorp.com/articulo-pruebas-de-software:-historia-y-evolucion>
[Accessed 3 October 2021].

• Es.wikipedia.org. 2021. Pruebas de software - Wikipedia, la enciclopedia libre.

[online] Available at: <https://es.wikipedia.org/wiki/Pruebas_de_software>
[Accessed 3 October 2021].

• Oa.upm.es. 2021. [online] Available at:

<https://oa.upm.es/40012/1/PFC_JOSE_MANUEL_SANCHEZ_PENO_3.pdf>
[Accessed 3 October 2021].