76765984 ejecucion-de-pruebas-original

Calidad de Software
Ing. Alonso Morales

2011 EJECUCIÓN DE PRUEBAS

Integrantes:
Alvarado Pachas, Euler Hardy.
Orellana Paucar, Rony Eduardo.
Quispe Gamboa, Omar Ernesto.
Saravia Soto, Jhonathan
Vargas Castilla, Kelvin Renzo.

Facultad de Ingeniería de Sistemas

Ejecución de pruebas 2011

2


Contenido
INTRODUCCION ............................................................................................................. 5
1. CONCEPTOS INTRODUCTORIOS ............................................................................... 6
1.1. DEFINICIONES ............................................................................................................ 6
1.2. RELACION ENTRE DEFECTO, FALLA Y ERROR ................................................................ 6
1.3. CICLO DE LAS PRUEBAS DE SOFTWARE ........................................................................ 7
1.4. ¿QUÉ ES PROBAR? ..................................................................................................... 8
1.5. ¿PORQUÉ ES IMPORTANTE HACER PRUEBAS EN NUESTRO SOFTWARE? ....................... 8

2. EJECUCIÓN DE PRUEBAS ......................................................................................... 9
2.1. DEFINICIÓN................................................................................................................ 9
2.2. FASES ...................................................................................................................... 10
2.3. HERRAMIENTAS PARA IMPLEMENTAR Y EJECUTAR PRUEBAS .................................... 12
2.3.1. E-TESTER ................................................................................................................................. 12
2.3.2. RATIONAL FUNCTIONAL TESTER............................................................................................. 13
2.3.3. QUICK TEST PRO ..................................................................................................................... 15
2.3.4. RATIONAL ROBOT ................................................................................................................... 15
2.3.5. TESTPARTNER ......................................................................................................................... 16
2.3.6. WINRUNNER........................................................................................................................... 17

3. CASOS DE PRUEBA ................................................................................................ 18
3.1. CONCEPTO ............................................................................................................... 18
3.2. OBJETIVOS ............................................................................................................... 20
3.3. TECNICAS DE PRUEBAS ............................................................................................. 21
3.3.1. TECNICAS DE PRUEBAS GENERALES: ...................................................................................... 21
3.3.1.1. PRUEBA POSITIVA .............................................................................................................. 21
3.3.1.2. PRUEBA NEGATIVA ............................................................................................................ 22
3.3.1.3. PRUEBA DE CAJA NEGRA.................................................................................................... 22
3.3.1.4. PRUEBA DE CAJA BLANCA .................................................................................................. 23
3.3.1.5. ADIVINAR ERRORES............................................................................................................ 24
3.3.1.6. PRUEBA DE SOFTWARE AUTOMATIZADO .......................................................................... 25
3.3.2. TECNICAS DE PRUEBAS FUNCIONALES: .................................................................................. 25
3.3.2.1. EQUIVALENCIA DE PARTICIONAMIENTO ........................................................................... 25
3.3.2.2. ANALISIS DEL VALOR LÍMITE .............................................................................................. 26

4. CLASES DE EQUIVALENCIA..................................................................................... 27

3


4.1. DEFINICIÓN.............................................................................................................. 27
4.2. DIRECTRICES ............................................................................................................ 27
4.3. PARTICIÓN EQUIVALENTE ........................................................................................ 27
4.3.1. DEFINICIÓN ............................................................................................................................. 27
4.3.2. ¿QUÉ PASOS SEGUIR?............................................................................................................. 27
4.3.3. EJERCICIO DE PRUEBA DE CAJA NEGRA – CLASES DE EQUIVALENCIA .................................... 28
4.3.3.1. ENUNCIADO ....................................................................................................................... 28
4.3.3.2. SOLUCIÓN .......................................................................................................................... 29

5. INFORME Y SEGUIMIENTO DE PRUEBAS ................................................................ 31
5.1. DOCUMENTACIÓN EN EL PROCESO DE PRUEBAS ....................................................... 31
5.1.1. DOCUMENTACIÓN EN LA PREPARACION DE LAS PRUEBAS ................................................... 32
5.1.1.1. PLAN DE PRUEBAS ............................................................................................................. 33
5.1.1.2. DOCUMENTO DE ESPECIFICACIÓN DE DISEÑO DE PRUEBAS ............................................. 34
5.1.1.3. DOCUMENTO DE ESPECIFICACIÓN DE CASOS DE PRUEBA ................................................ 34
5.1.1.4. DOCUMENTO DE ESPECIFICACIÓN DE LOS PROCEDIMIENTOS DE PRUEBA ...................... 35
5.1.1.5. INFORME DE TRANSMISIÓN DE ELEMENTOS DE PRUEBAS ............................................... 36
5.1.2. DOCUMENTACION DURANTE LA EJECUCION DE LAS PRUEBAS ............................................. 36
5.1.2.1. REGISTRO DE PRUEBAS (HISTÓRICO DE PRUEBAS O TEST LOG) ........................................ 37
5.1.2.2. INFORME DE INCIDENTES .................................................................................................. 38
5.1.3. DOCUMENTACIÓN PARA LA FINALIZACION DE LAS PRUEBAS ................................................ 38
5.1.3.1. INFORME DE RESUMEN DE PRUEBAS ................................................................................ 38

5.2. SEGUIMIENTO DE LAS PRUEBAS ............................................................................... 39
5.2.1. DEPURACIÓN (DEBUGGING) .................................................................................................. 39
5.2.1.1. DEFINICIÓN ........................................................................................................................ 39
5.2.1.2. CONSEJOS PARA LA DEPURACIÓN ..................................................................................... 40
5.2.2. ¿CUÁNDO PARAR DE PROBAR? .............................................................................................. 41

CONCLUSIÓN ............................................................................................................... 42
RECOMENDACIONES.................................................................................................... 43
BIBLIOGRAFIA ............................................................................................................. 44

4


INTRODUCCION

Una de las últimas fases del ciclo de vida antes de entregar un programa para su explotación, es la
fase de pruebas. Las pruebas de software se aplican como una etapa más del proceso de
desarrollo de software, su objetivo es asegurar que el software cumpla con las especificaciones
requeridas y eliminar los posibles defectos que este pudiera tener. En un principio la mayoría
de empresas de desarrollo contaban con una etapa de pruebas demasiado informal, en la
actualidad las pruebas de software se han convertido en una de las etapas más críticas del ciclo de
vida del desarrollo de software y esto ha causado el origen de diversas metodologías.

En la actualidad la prueba de software se hace más complicada ya que debe hacer frente a una
gran cantidad de metodologías de desarrollo, lenguajes de programación, sistemas operativos,
hardware etc.

Es por esto que la prueba debe apoyarse en metodologías generales que revisan los aspectos más
fundamentales que debe considerar todo proceso de pruebas. Debido a esta complejidad
actualmente se cuentan con una gran cantidad de software diseñado exclusivamente para la etapa
de pruebas, incluyendo la gestión del proceso de prueba de software, la administración y
seguimiento de errores, la administración de los casos de prueba, automatización de pruebas, etc.

5


1. CONCEPTOS INTRODUCTORIOS
1.1.DEFINICIONES

 PRUEBAS (test): una actividad en la cual un sistema o uno de sus componentes se ejecuta
en circunstancias previamente especificadas, los resultados se observan y registran y se
realiza una evaluación de algún aspecto.

 CASO DE PRUEBA (test case): un conjunto de entradas, condiciones de ejecución y
resultados esperados desarrollados para un objetivo particular.

 DEFECTO (defect, fault, «bug»): un defecto en el software como, por ejemplo, un
proceso, una definición de datos o un paso de procesamiento incorrectos en un
programa.

 FALLO (failure): La incapacidad de un sistema o de alguno de sus componentes para
realizar las funciones requeridas dentro de los requisitos de rendimiento especificados.

 ERROR (error): La diferencia entre un valor calculado, observado o medio y el valor
verdadero, especificado o teóricamente correcto.

1.2.RELACION ENTRE DEFECTO, FALLA Y ERROR

En la figura 1.1 podemos observar graficamente la relación directa que existe entre las
definiciones de defecto, falla y error.

Figura 1.1. Relación entre Defecto, Falla y Error

6


Así podemos entablar la relación consecuencial como nos muestra la figura 1.2:

Figura 1.2. Relación Consecuencial entre Defecto, Falla y Error

1.3.CICLO DE LAS PRUEBAS DE SOFTWARE

Figura 1.3. Ciclo de Vida de las Pruebas de Software

7


1.4.¿QUÉ ES PROBAR?

Erróneamente, la mayoría de la gente piensa que:

 Probar es el proceso de demostrar que no hay errores.
 Probar nos permite demostrar que el programa realiza lo que se supone que debe
hacer.

Como parte que es de un proceso industrial, la fase de pruebas añade valor al producto que
se maneja: todos los programas tienen errores y la fase de pruebas los descubre; ese es el
valor que añade. El objetivo específico de la fase de pruebas es encontrar cuantos más
errores, mejor. Es frecuente encontrarse con el error de afirmar que el objetivo de esta fase
es convencerse de que el programa funciona bien. En realidad ese es el objetivo propio de
las fases anteriores (¿quién va a pasar a la sección de pruebas un producto que sospecha
que está mal?). Cumplido ese objetivo, lo mejor posible, se pasa a pruebas. Esto no obsta
para reconocer que el objetivo último de todo el proceso de fabricación de programas sea
hacer programas que funcionen bien; pero cada fase tiene su objetivo específico, y el de las
pruebas es destapar errores. Probar un programa es ejercitarlo con la peor intención a fin
de encontrarle fallos.

 DEFINICIÓN CORRECTA:

“Probar es el proceso de ejecutar un programa con la intención de
encontrar errores”.

1.5.¿PORQUÉ ES IMPORTANTE HACER PRUEBAS EN NUESTRO SOFTWARE?

En la cadena de valor del desarrollo de un software específico, el proceso de prueba es clave
a la hora de detectar errores o fallas. Conceptos como estabilidad, escalabilidad, eficiencia y
seguridad se relacionan a la calidad de un producto bien desarrollado. Las aplicaciones de
software han crecido en complejidad y tamaño, y por consiguiente también en costos. Hoy
en día es crucial verificar y evaluar la calidad de lo construido de modo de minimizar el costo
de su reparación. Mientras antes se detecte una falla, más barata es su corrección.

El proceso de prueba es un proceso técnico especializado de investigación que requiere de
profesionales altamente capacitados en lenguajes de desarrollo, métodos y técnicas de
pruebas y herramientas especializadas. El conocimiento que debe manejar un ingeniero de
prueba es muchas veces superior al del desarrollador de software.

8


2. EJECUCIÓN DE PRUEBAS
2.1.DEFINICIÓN

Es la actividad donde los procedimientos de pruebas o scripts son especificados
combinando los casos de prueba en un orden particular e incluyendo cualquier otra
información necesaria para la ejecución de pruebas, el ambiente se preparara y se ejecutan
las pruebas.

Se ejecutan las pruebas mediante la definición de las actividades requeridas para ejecutar
los requerimientos de pruebas identificados en la fase de diseño de pruebas, reportar los
hallazgos y asegurar su corrección por parte del equipo de desarrollo de software.

Figura 2.1. Proceso de Ejecución de Pruebas

9


La fase de ejecución de pruebas se realiza por iteraciones de pruebas. (Total o un
subconjunto de los requerimientos de pruebas).

En cada iteración de pruebas se registran los hallazgos o No Conformidades de software tal
como se muestra en la figura 2.2.

El objetivo de esta etapa es contrastar el comportamiento esperado del software con su
comportamiento real, analizar las diferencias y reportar los resultados.

Durante la etapa de ejecución, los responsables de pruebas deben ejecutar la mayor
cantidad posible de iteraciones y regresiones de prueba hasta poder demostrar
gráficamente que existe una tendencia sostenida a la baja en la cantidad de no
conformidades encontradas.

Figura 2.2. Curva de Registro de Hallazgos o No Conformidades

El resultado real de ejecución debe cumplir con dos características fundamentales que
permiten evidenciar su cumplimiento:

 La correctitud: exactitud de los resultados reales versus los esperados.
 La completitud: cobertura de los resultados reales versus los esperados.

2.2.FASES

a) El proceso de ejecución de pruebas según el estándar IEEE Std. 829, abarca las
siguientes fases:
 Ejecutar las pruebas, cuyos casos y procedimientos han sido ya diseñados
previamente.

10


 Comprobar si se ha concluido el proceso de prueba (según ciertos criterios de
compleción de prueba que suelen especificarse en el plan de pruebas).

 En el caso que hayan terminado las pruebas, se evalúan los resultados; en caso
contrario hay que generar las pruebas adicionales para que se satisfagan los
criterios de compleción de pruebas.

b) El proceso de ejecución propiamente dicho, consta de las siguientes fases:
 Se ejecutan las pruebas.

 Se comprueba si ha habido algún fallo al ejecutar.

 Si lo ha habido, se puede deber a un defecto del software, lo que nos lleva al
proceso de depuración o corrección del código. Se puede deber también a un
defecto en el propio diseño de las pruebas. En ambos casos, las nuevas pruebas o
las corregidas se deberán ejecutar.

 De no existir fallos, se pasará a la comprobación de la terminación de las pruebas.

c) Las fases del proceso de comprobación de la terminación de las pruebas son:
 Tras la ejecución, se comprueba si se cumplen los criterios de compleción de
pruebas descritos en el correspondiente plan de pruebas.

 En caso de terminar las pruebas, se pasa a la evaluación de los productos probados
sobre la base de los resultados obtenidos (terminación normal).

 En caso de no terminar las pruebas se debe comprobar la presencia de condiciones
anormales en la prueba.

 Si hubiesen existido condiciones anormales, se pasa de nuevo a la evaluación; en
caso contrario, se pasa a generar y ejecutar pruebas adicionales para satisfacer
cualquiera de las dos terminaciones.

Los criterios de compleción de pruebas hacen referencia a las áreas (características,
funciones, etc.) que deben cubrir las pruebas y el grado de cobertura para cada una de esas
áreas. Como ejemplos genéricos de este tipo de criterios se pueden indicar los siguientes:

 Se debe cubrir cada característica o requerimiento del software mediante un caso
de prueba o una excepción aprobada en el plan de pruebas.
 En programas codificados con lenguajes procedurales, se deben cubrir todas las
instrucciones ejecutables mediante casos de prueba.

11


2.3.HERRAMIENTAS PARA IMPLEMENTAR Y EJECUTAR PRUEBAS

Sabemos que las pruebas de software es el acto de la ejecución de software para satisfacer
una, algunas o todas de las siguientes metas:

 Para asegurar que el software cumple con los requisitos especificados.
 Identificar los defectos en el software (estos defectos se refieren a menudo como
"bugs").
 Para entender el nivel de calidad del software.

En la actualidad, para cumplir estos objetivos, muchas organizaciones utilizan las pruebas de
software manual, es decir, la gente se sienta delante de un ordenador y usa los scripts para
realizar sus pruebas. A menudo, muchos de estos scripts de prueba deben ser ejecutados en
varias ocasiones, como emisiones sucesivas del software. Esto no sólo puede resultar
monótono y aburrido para los individuos que han de ejecutar las pruebas, pero desde una
perspectiva organizacional puede ser muy intensivo en el uso de recursos. Con el fin de
ayudar a aliviar este problema, algunas compañías desarrollaron herramientas
automatizadas de prueba. En términos simples, una vez la gente utiliza estas herramientas
para crear scripts automatizados de prueba. Estas herramientas pueden ejecutar los scripts
cada vez que lo indique, con poca supervisión necesaria de los seres humanos. Esto permite
a los probadores que normalmente ejecutan el script manualmente, automatizar las
pruebas para concentrarse en otros aspectos más interesantes en el desarrollo del software.
Ahora estamos a lo largo de varias generaciones en términos de herramientas de pruebas
automatizadas. En su mayor parte, en las primeras generaciones eran difíciles de usar, y las
secuencias de comandos automatizadas que se utilizan para crear no eran fáciles de
mantener. Sin embargo, las últimas herramientas que se han desarrollado son más fáciles
de utilizar, de manera que pueda ser utilizado por un mayor número de personas que tienen
diferentes niveles y tipos de habilidades. En este capítulo tratare de explicar cuáles son las
herramientas que se emplean para implementar y ejecutar pruebas funcionales y de
regresión, así como ver cuáles son sus características. Entre las herramientas más usadas
para realizar pruebas funcionales y de regresión tenemos las siguientes:

2.3.1. E-TESTER

Empirix e-Tester es una herramienta de prueba automatizada
que forma parte de la suite de e-test de aplicaciones. E-Tester
proporciona a los usuarios la capacidad de crear scripts
automatizados de prueba de funcionamiento.

Está diseñado para ser utilizado para probar web, soluciones
inalámbricas y aplicaciones multimedia.

12


¿CÓMO FUNCIONA?

Un usuario inicia la generación de una secuencia de comandos mediante e-Tester
para grabar su interacción con la aplicación que se estudia. E-Tester registra todos
los objetos en cada página web que se ve, y valida estos objetos cuando el script se
ejecuta. El script se puede personalizar para utilizar los valores de los archivos de
datos como entradas de prueba.

Empirix afirma que las secuencias de comandos utilizables prueba puede ser creado
sin ningún tipo de codificación que sea.

Facilidad de uso es una de las principales características de este producto. Sin
embargo, para extender la funcionalidad de scripts registrados, los usuarios pueden
utilizar Visual Basic para Aplicaciones (VBA).

E-Tester utiliza el entorno de desarrollo de VBA para proporcionar a los usuarios
avanzados con script de prueba las funciones de depuración y la capacidad de crear
funciones reutilizables. C + +, J + +, VBScript y JavaScript también puede utilizarse
para mejorar e-Tester scripts. Scripts de prueba creada con e-Tester también se
puede utilizar para la realización de pruebas de rendimiento en Empirix e-carga.
Además, E-Tester se integra con e-Manager, la herramienta de gestión de pruebas
de Empirix.

2.3.2. RATIONAL FUNCTIONAL TESTER

Rational Functional Tester antes conocida como XDE
Tester, es una herramienta de prueba que permite a los
usuarios grabar, editar y ejecutar scripts de prueba
funcional automatizada. Un usuario puede crear y
modificar los scripts de prueba utilizando Java o Visual
Basic .Net, por lo que algunos conocimientos de
programación y la experiencia es esencial.

Fue diseñado para probar aplicaciones Java, .Net y
aplicaciones Web, mas no en aplicaciones Cliente/Servidor.

CARACTERÍSTICAS:

 Soporte para pruebas de aplicaciones java, web y visual studio .net basadas
en winform: A menudo se le requiere a los equipos de pruebas el evaluar
aplicaciones construidas sobre más de una base tecnológica. Provee el mismo
soporte robusto de automatización para aplicaciones construidas usando
tecnología Java, HTML/DHTML y Visual Studio .NET en WinForm.

13


 Elección del lenguaje - java o visual basic .net - para la customización de los
test script: La customización de los test scripts es mandatorio en orden a
realizar algún test que no sea el más básico. Rational Functional Tester da la
opción de seleccionar entre lenguajes poderosos de scripting para hacerlo
posible, siendo las posibilidades tanto Java como Visual Basic .NET - ambas
opciones pueden ser usadas con todas las tecnologías de interfaz de usuario
soportadas. Al trabajar con el Functional Tester, los testeadores aprenden
rápidamente a trabajar con construcciones básicas del lenguaje adquiriendo
experiencia de programación que facilitará una comunicación más productiva
con los desarrolladores.
 Editor y debugger nativos para testeadores avanzados java y visual basic
.net:
Esta herramienta proporciona opciones más fuertes de la industria para estos
fines, los testeadores que usan Java pueden trabajar con el Eclipse Java
Development Toolkit (JDT), y los que usan Visual Basic .NET pueden hacerlo en
Visual Studio .NET. Ambos ambientes integrados de desarrollo ofrecen una
gran cantidad de opciones para simplificar la optimización de los test,
incluyendo una característica útil de completamiento del código que sugiere la
sentencia para acelerar la edición.
Los desarrolladores GUI encontrarán esta característica particularmente útil,
ya que podrán accederla desde la misma interfaz a la que acceden para
construir la interfaz de usuario.
 Tecnología scriptassure para adecuar los cambios frecuentes a las interfaces
de usuario: Los cambios frecuentes a la interfaz de usuario de las aplicaciones
pueden desbaratar las pruebas que involucran asunciones respecto a la forma
en que se identificarán los objetos de la interfaz durante el playback.
Permite a los probadores automatizar las pruebas de forma flexible cuando se
realizan cambios frecuentes en la interfaz de usuario de las aplicaciones con la
tecnología ScriptAssure.
 Correlación automatizada de datos y testing orientado al dato eliminando la
necesidad de codificación manual: Las pruebas funcionales generalmente
necesitan de variar los datos para simular adecuadamente los usuarios reales.
Rational Functional Tester puede detectar automáticamente los datos
ingresados durante la grabación del test y preparar el test para orientarlo a los
datos.
Usando una hoja de cálculo como editor de datos, de esta manera se pueden
crear juegos de datos customizados para ser insertados dentro del script
durante el playback. De esta manera, se pueden producir pruebas altamente
personalizados sin codificación manual.
 Soporte para ejecución y edición de test bajo linux: Para los testeadores
interesados en Java, Rational Functional Tester ofrece capacidad de scripting

14


para crear, editar y ejecutar pruebas sobre plataforma Linux - incluyendo todo
excepto el grabador de test. También soporta la plataforma Windows para
todas las capacidades de grabación, edición y ejecución.

2.3.3. QUICK TEST PRO

Herramienta para realizar pruebas automatizadas, es tan fácil de usar como el
WinRunner.

Muchas de las cosas que requiere de la escritura de código en WinRunner, como
agregar bucles IF a los scripts de pruebas automatizadas se pueden realizar a través
del Quick Test Pro que es una funcionalidad integrada y no existe la necesidad de
escribir el código.

Funcionalidad que permite a individuos con poca o sin conocimiento de
programación podrá hacer uso de esta herramienta.

2.3.4. RATIONAL ROBOT

El objetivo de IBM Rational Robot es facilitar la creación y ejecución de scripts
automatizados para probar la funcionalidad de una aplicación mediante la
simulación de un usuario que interactúa con la interfaz gráfica de la aplicación.
Rational Robot también permite a los usuarios crear datapools, que vienen a ser un
conjunto de datos de prueba que pueden ser utilizados por los scripts automatizados
para variar los valores de entrada durante la ejecución del script.

CARACTERÍSTICAS:

 Brinda soporte a múltiples tecnologías de interfaz de usuario (ui) para
cualquier entorno, desde Java y la web hasta todos los controles de VS.NET,
incluidos VB.NET, J#, C# y C++ gestionado.
 Incluye herramientas para administración de Pruebas y está integrado al las
soluciones propuestas en el Rational Unified Process para el seguimiento de
defectos, administración de cambios y trazabilidad de requerimientos.

15


 Simplifica la configuración de pruebas - Rational Robot puede usarse para
distribuir las pruebas funcionales entre varias máquinas, cada una de ellas
configurada en forma diferente. Se pueden correr simultáneamente los
mismas Pruebas funcionales, reduciendo el tiempo necesario para identificar
los problemas con configuraciones específicas.
 Asegura la Profundidad de las pruebas - Prueba más allá de la interfaz de
usuario de la aplicación los cientos de propiedades de los objetos
componentes de la misma - tales como Controles ActiveX , OCXs, applets Java
y muchos otros - con solo un click.
 Prueba los controles y objetos usuales - Rational Robot permite hacer
pruebas a cada componente de la aplicación bajo variadas condiciones
proveyendo casos de prueba para menús, listas, caracteres alfanuméricos,
bitmaps y muchos otros objetos.
 Facilita el rehúso - Rational Robot permite que los mismas pruebas de scripts,
sin ninguna modificación, se pueden rehusar para probar una aplicación que
corre sobre Microsoft Windows XP, Windows, ME, Windows 2000, Windows
98 o Windows NT.
 Ayuda a analizar rápidamente los problemas - Rational Robot registra
automáticamente los resultados del test en el Rational Repository integrado y
colorea el código par un rápido análisis visual. Haciendo doble clic sobre una
entrada, se posiciona directamente sobre la línea correspondiente de la
prueba de script, asegurando en consecuencia un rápido análisis y corrección
de los errores del test script.

2.3.5. TESTPARTNER

TestPartner de Compuware es una herramienta que permite a los usuarios para
crear scripts automatizados de prueba que valide funcionalidad de la aplicación que
se está probando.

CARACTERÍSTICAS:

 Puede ser utilizado para probar web y las aplicaciones cliente / servidor.
 TestPartner también tiene una funcionalidad integrada que permite a los
usuarios probar los sistemas SAP.
 TestPartner scripts se crean utilizando Microsoft Visual Basic para
Aplicaciones (VBA), que es un lenguaje no propietario que tiene una base de
usuarios bastante grande fuera del campo de pruebas de software
automatizadas.
 TestPartner también proporciona algunas de las características del entorno de
Microsoft VBA, incluida la asistencia con la depuración y la información sobre
las variables de tiempo de ejecución. Wizards están disponibles para ayudar a

16


crear los controles que los artículos validar tales como propiedades de objetos
y datos del sistema.
 TestPartner también tiene la capacidad para probar el lado del cliente y los
objetos del lado del servidor COM, que permite las pruebas para comenzar
antes de interfaz de la aplicación se está probando se ha creado.

2.3.6. WINRUNNER

WinRunner es una herramienta empresarial para pruebas funcionales que asegura
que los procesos de negocio funcionen perfectamente la primera vez y mantiene la
fiabilidad.
Consiste en capturar, reproducir y verificar las interacciones entre usuarios de forma
automática, con el fin de identificar los defectos y determinar si los procesos de
negocio trabajan como fue diseñado.

ETAPAS DE PRUEBA DEL WINRUNNER:

1. CREACIÓN DE PRUEBAS:
 Crear pruebas con la grabación y la programación.
 Mientras se realizan las pruebas de grabación, se puede añadir
puntos de control para comprobar el comportamiento de la
aplicación.
2. PRUEBAS DE FUNCIONAMIENTO:
 Mientras se ejecuta una prueba, WinRunner emula un usuario
humano mediante la utilización del mouse y teclado en la aplicación.
3. ANÁLISIS DE LOS RESULTADOS DE LA PRUEBA:
 Cuando una ejecución de prueba termina, WinRunner realiza una
lista de todos los eventos importantes que tuvieron lugar durante la
realización de la prueba, tales como puntos de control, los errores o
mensajes.

17


3. CASOS DE PRUEBA
3.1. CONCEPTO

Según la IEEE, estándar 610 define un caso de prueba como “Conjunto de entrada de
prueba, condición de ejecución, y resultado esperado desarrollados para un objetivo en
particular, como el ejercicio de una ruta de programa en particular o para verificar el
cumplimiento de un requisito específico, y como documentación que especifique las
entradas, los resultados previos, y un conjunto de condiciones de ejecuciones de un elemento
de prueba”. A partir de esta definición, se puede deducir acerca de los casos de pruebas:

 Los casos de prueba se utilizan para la ejecución de una prueba en un producto de
software.

 Los casos de prueba se compone de entradas de usuario que se proporcionan a la
aplicación y el procedimiento para la ejecución del caso de prueba durante la
prueba.

 Prueba de detalle de los casos los resultados esperados desde el software cuando la
prueba se ejecuta con los insumos especificados por el usuario.

 Los casos de prueba son específicos de un artefacto de código de software o una
clase de artefactos de código de software.

 Los casos de prueba de facilitar y asegurar el cumplimiento de los artefactos de
código de software con un requisito específico.

 Los casos de prueba están documentados.

La práctica habitual es el de documentar los casos de prueba en una hoja de cálculo como
Microsoft Excel o en una herramienta como TestPal. (Esta herramienta está disponible
como descarga gratuita desde la Web de descarga de Valor Agregado en el Centro de
Recursos www.jrosspub.com). La práctica general es el de documentar los casos de
prueba para un componente de software (artefacto de código de software) en un
documento. (Ver figura 3.1)

18


Figura 3.1. Formato de definición casos de prueba

Una tabla de condiciones es otra manera de describir los casos de prueba. Una tabla de
condiciones describe el comportamiento del sistema para diferentes combinaciones de
insumos. Por ejemplo, en una pantalla de registro, el usuario introduce un nombre de
usuario y una contraseña y haga clic ya sea en el botón Aceptar o el botón Cancelar. Cuando
el botón se hace clic en Cancelar, el diario de la acción debe ser cancelada, pero cuando el
usuario hace clic en el botón Aceptar, el sistema se comporta como se describe en la Figura
3.2.

Figura 3.2. Tabla de condición para una pantalla de registro

19


El diseño de casos de prueba es muy importante en las pruebas de software. Diseñados
adecuadamente los casos de prueba pueden descubrir todos los defectos y mal diseñado los
casos de prueba, dejando defectos residuales en el producto de software.

3.2.OBJETIVOS

El objetivo del diseño de casos de prueba es descubrir todos los defectos que acechan en el
software y para poner a prueba todo el software completo, con la minimización de la
restricción quede esfuerzo y tiempo.

Los casos de prueba deben derivarse de los artefactos de software de información. En la
siguiente figura se mostrara la lista de artefactos que ayudan la obtención de un caso de
prueba. (Ver figura 3.3)

Figura 3.3. Información de los artefactos del software que
asisten en derivados de caso de pruebas

El número de casos de prueba para ser diseñado y documentado es bastante grande.
Considere las siguientes implicaciones en el diseño de casos de prueba:

 Por cada entrada de datos numérico (incluido los datos de tipo fecha), cinco casos de
pruebas, usando el particionamiento y técnica de análisis del valor limite.

 Verificar que el tamaño debe ser realizada por todo los datos no numéricos, uno por
cada elemento.

 Todos los datos no numéricos deben ser evaluados para verificar que han sido
introducido y que el área de entrada no se deja en blanco.

20


 Las pruebas de lógica es necesaria para comprobar la presencia de datos no validos,
como dos puntos decimales en tipo numérico, numérico y caracteres especiales en el
campo de nombre, etc.

Por lo tanto, el caso de prueba para establecer incluso una unidad de complejidad
moderada es enorme.

Los proyectos modernos son de gran tamaño, y el esfuerzo requerido para
preparar exhaustivamente un conjunto de caso de prueba sea muy amplio. Por esta razón,
es común para preparar los casos de prueba donde se espera que el probador no pueda
entender intuitivamente los casos de prueba en si mismo. Según las guías de pruebas es de
uso general para los siguientes tipos de pruebas de software:

 Prueba GUI.

 Prueba de navegación (entorno web).

 Prueba negativas.

 Prueba de carga.

 Prueba de estrés.

 Prueba paralelo y concurrente.

Las organizaciones utilizan estas directrices para evitar tener que preparar los casos de
prueba exhaustiva. Las pruebas de integración, pruebas del sistema, y las pruebas de
aceptación que normalmente se llevan a cabo contra los casos de prueba.

3.3.TECNICAS DE PRUEBAS

Describimos una serie de técnicas de pruebas que el Analista de Pruebas puede emplear en
el diseño y desarrollo de casos de pruebas efectivas.

Las técnicas de pruebas están organizadas en:

3.3.1. TECNICAS DE PRUEBAS GENERALES:

3.3.1.1. PRUEBA POSITIVA

Prueba de positivo en las pruebas del software tal como se especifica y no trata de
acciones que no se espera de un usuario sincera, para asegurarse de que todas las
funciones definidas es el esperado. No está diseñado para descubrir defectos en el
software.

21


La prueba positiva se realiza principalmente durante los clientes y usuarios
finales las pruebas de aceptación, pruebas funcionales y pruebas de extremo a
extremo. Se lleva a cabo sobre la base de casos de prueba diseñados
para demostrar que el producto de software está trabajando según lo
previsto. Este tipo de pruebas se utiliza justo antes de la entrega de un producto a
los clientes, para asegurar que el producto está funcionando.

3.3.1.2. PRUEBA NEGATIVA

La prueba negativo implica el uso del software de una manera en la que no se
espera que sea utilizado, lo que revela todos los otros defectos ocultos no
relacionados directamente con la funcionalidad definida en el software. Esto es
para asegurar que incluso el uso malicioso no afectará el software o la integridad
de los datos.

Con el advenimiento de sistemas de eventos activados por software, las pruebas
negativas se han convertido en muy importante. Cada control en la pantalla,
como un cuadro de texto, cuadro combinado, cuadro de lista, etc., tiene un gran
número de eventos asociados. Por ejemplo, haga clic, doble clic, cambiar, ratón
arriba, ratón abajo, tiene el foco, perdido el foco, presione la tecla, tecla, tecla,
etc. están asociados con un cuadro combinado. Se tiene mucho cuidado en el
código de control para que la acción del usuario de la activación de un evento
es validado por un segmento de código y los fracasos se previenen.

Las pruebas negativas desentierran prueba deficiencias en el software centrado
en el manejo de errores y facilita la mejora del software para que las
fallas inesperadas no se produzcan en las instalaciones del
cliente. Recomiendo llevar a cabo esta prueba en todos los productos de software,
ya sea en el escenario del proyecto o producto escenario.

3.3.1.3. PRUEBA DE CAJA NEGRA

En las pruebas de caja negra, el software es tratado como un "caja negra", y su
lógica interna para el procesamiento de los datos no se considera. Un conjunto de
entradas se introduce en el software y los productos entregados por el software se
comparan con los resultados esperados. Para utilizar esta técnica, el
auditor considera que la funcionalidad del software y administra la prueba. La
prueba de caja negra es representada de la siguiente manera. (Ver figura 3.4)

22


Figura 3.4. La prueba de caja negra

La prueba de caja negra normalmente se lleva a cabo desde la interfaz de usuario
o la línea de comandos. El programa se invoca, y los insumos necesarios se dan en
el software para que los procesos de los datos de prueba y las entradas del usuario
para generar resultados que se pueden comparar con los resultados esperados.
Esto determina si el software funcionaba correctamente.

La eficacia de las pruebas de caja negra depende del cuidado con que los casos de
prueba y datos de prueba están diseñados. Si los casos de prueba se completan, la
prueba es exhaustiva y tiene una mejor oportunidad de detectar anomalías en el
software.

3.3.1.4. PRUEBA DE CAJA BLANCA

La prueba de caja blanca considera las declaraciones de lógica interna y el
programa del software. Se trata de pasar a través de cada línea de código y
de todas las ramas en el código. Para utilizar esta técnica, el auditor debe tener
conocimiento en el lenguaje de programación de software y debe entender la
estructura del programa. La prueba de caja blanca se asegura de que todas las
declaraciones de los programas y todas las estructuras de control se ponen a
prueba al menos una vez. La prueba de caja blanca es representada de la siguiente
manera. (Ver figura 3.5)

23


Figura 3.5. La prueba de caja blanca

La prueba de caja blanca puede llevarse a cabo desde la línea de comandos, la
interfaz de usuario, o desde el programa. Si la prueba se lleva a cabo desde la línea
de comandos o la interfaz de usuario, la exhaustividad de la prueba depende
de los casos de prueba para recorrer a través de cada ruta en el software. La otra
forma es la realización de pruebas de caja blanca con el entorno de desarrollo
interactivo (IDE) o un depurador de lenguaje específico. Esta herramienta ha
facilitado para realizar lo siguiente:

 Paso a través de cada línea de código.

 Establecer puntos de interrupción en el código en la ejecución espera a que
el probador para reanudar la ejecución.

 Establecer el valor inicial o cambiar el valor de las variables o constantes,
sin la necesidad de cambiar el programa.

 Recorrer a través de todos los caminos de las estructuras de
control de configurar dinámicamente los valores de la variable de control.

 Detener la ejecución en cualquier punto en el programa y continuar con las
pruebas desde el principio o en cualquier parte del programa.

 Mover la ejecución de cualquier punto a cualquier otro punto en el
programa.

3.3.1.5. ADIVINAR ERRORES

Como es generalmente aceptado que las pruebas exhaustivas de todos los
escenarios posibles no son prácticas, las organizaciones tratan de garantizar un
producto libre de defectos de diseño de casos de prueba para estos casos, si los
defectos son posibles. Por lo general, una guía para adivinar el error se ha
desarrollado. En esta técnica, el diseñador de caso de prueba utiliza la experiencia,

24


la intuición y el sentido común para diseñar casos de prueba que puedan detectar
errores.

Como su propio nombre indica, hay una cierta cantidad de errores por
adivinar involucrados, lo que significa que los ingenieros de software
son propensos a cometer errores. Usando esta técnica sin duda requiere de
muchos años de experiencia en el desarrollo y pruebas de software.

Algunos ejemplos de áreas en un campo de fecha en que los errores pueden
ocurrir incluyen una fecha no válida como el 30 de febrero entró en un
conjunto de 13 meses o un año malo como el 9999 entró.

3.3.1.6. PRUEBA DE SOFTWARE AUTOMATIZADO

Aunque estrictamente hablando no es una técnica de prueba, las pruebas
automatizadas se incluyen en este apartado, ya que puede proporcionar una
solución de pruebas eficaces.

Una ventaja importante en esta prueba es su capacidad para operar sin
supervisión (por ejemplo, para ejecutar durante la noche o el fin de semana), que
proporciona ganancias significativas en productividad para la tarea de
comprobación. Las herramientas automatizadas también pueden generar una
confianza adicional en la automatización, permitiendo más pruebas para ser
ejecutado en el momento mismo que el dado por una prueba manual equivalente.

3.3.2. TECNICAS DE PRUEBAS FUNCIONALES:

3.3.2.1. EQUIVALENCIA DE PARTICIONAMIENTO
El espacio de entrada se divide en entradas válidas y entradas no validas. Un
ejemplo ilustrará esta técnica. (Ver figura 3.6)

Figura 3.6. Equivalencia de particionamiento

En una aplicación de los recursos humanos, la edad del empleado puede ser de un
mínimo de 16 (edad laboral mínima) y un máximo de 65 (la edad de jubilación). La

25


partición de valores válidos es de entre 16 y 65 años. Hay dos particiones de datos
inválidos uno por debajo de 16 y otro de 65 años. Por lo tanto, hay
tres particiones en este caso - un válido y dos inválidos. Un caso de prueba se
puede diseñar para cada partición, lo que resulta en tres casos de prueba.

3.3.2.2. ANALISIS DEL VALOR LÍMITE

Mostrando con el ejemplo de las particiones (ver figura 3.7) hay dos límites: la edad
mínima para el empleo y la edad máxima para el empleo (edad de jubilación)

Figura 3.7. Análisis del valor limite

Estos dos límites: 16 y 65 deben ser aceptadas, y todos los valores por debajo de
16 y mayores de 65 debe ser rechazada. Por lo tanto, los casos de prueba están
diseñados, que combinan las técnicas de partición de equivalencia y análisis del
valor límite. En este ejemplo, hay cinco casos de prueba:

 Un valor entre 16 y 65 - valor válido.

 Un valor en el límite inferior de 16 - valor válido.

 Un valor justo por debajo del límite inferior (es decir, menos de 16) - valor no
válido (por lo general este valor se le daría como un día menos de 16).

 Un valor en el límite superior de 65 un valor válido.

 Un valor justo por encima del límite superior (es decir, mayor que 65) - valor no
válido (por lo general este valor se le daría como 65 años y 1 día).

26


4. CLASES DE EQUIVALENCIA
4.1.DEFINICIÓN

Una clase de equivalencia representa un conjunto de estados válidos o no válidos para
condiciones de entrada. Típicamente, 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.

Si un conjunto de objetos puede unirse por medio de relaciones simétricas, transitivas y
reflexivas, entonces existe una clase de equivalencia.

4.2.DIRECTRICES

Las clases de equivalencia se pueden definir de acuerdo con las siguientes directrices:

1. Si una condición de entrada especifica un rango, se define una clase de equivalencia
válida y dos no válidas.

2. Si una condición de entrada requiere un valor específico, se define una clase de
equivalencia válida y dos no válidas.

3. Si una condición de entrada requiere un valor específico, se define una clase de
equivalencia válida y dos no válidas.

4. Si una condición de entrada es lógica, se define una clase de equivalencia válida y
una no válida.

4.3.PARTICIÓN EQUIVALENTE

4.3.1. DEFINICIÓN

La partición equivalente es un método de prueba de caja negra que divide el campo
de entra de un programa en clases de datos de los que se pueden derivar casos de
prueba. Un caso de prueba ideal descubre de forma inmediata una clase de errores
(por ejemplo proceso incorrecto de todos los datos de carácter) 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 prueba que descubran
clases de errores, reduciendo así el número total de casos de prueba que hay que
desarrollar.

4.3.2. ¿QUÉ PASOS SEGUIR?

En el diseño de casos de prueba para partición equivalente se procede en dos pasos:

27


1. Se identifican las clases de equivalencia. Las clases de equivalencia son
identificadas tomando cada condición de entrada (generalmente una oración
o una frase en la especificación) y repartiéndola en dos o más grupos.
Es de notar que dos tipos de clases de equivalencia están identificados: las
clases de equivalencia válidas representan entradas válidas al programa, y las
clases de equivalencia no válidas que representan el resto de los estados
posibles de la condición (es decir, valores erróneos de la entrada).

2. Se define los casos de prueba. El segundo paso es el uso de las clases de
equivalencia para identificar los casos de prueba. El proceso es como sigue:
se asigna un número único a cada clase de equivalencia. Hasta que todas las
clases de equivalencia válidas han sido cubiertas por los casos de prueba, se
escribe un nuevo caso de prueba que cubra la clase de equivalencia válida. Y
por último hasta que los casos de prueba hayan cubierto todas las clases de
equivalencia inválidas, se escribe un caso de la prueba que cubra una, y
solamente una, de las clases de equivalencia inválidas descubiertas.

4.3.3. EJERCICIO DE PRUEBA DE CAJA NEGRA – CLASES DE EQUIVALENCIA

4.3.3.1. ENUNCIADO

Considere una aplicación bancaria, donde el usuario puede conectarse al banco
por internet y realizar una serie de operaciones bancarias. Una vez accedido al
banco con las consiguientes medidas de seguridad (clave de acceso y demás),
la información de entrada del procedimiento que gestiona las operaciones
concretas a realizar por el usuario requiere las siguientes entradas:

 Código del banco: En blanco o número de tres dígitos. En este caso, el
primero de los dígitos tiene que ser mayor que 1.

 Código de sucursal: Un número de cuatro dígitos. El primero de ellos
mayor de 0.

 Número de cuenta: Número de cinco dígitos.

 Clave personal: Valor alfanumérico de cinco posiciones.

 Orden: En este valor se introducirá según la orden que se desee
realizar. Puede estar en blanco o se una de las dos cadenas siguientes:

o “Talonario”

o “Movimientos”

28


En el primer caso el usuario recibirá un talonario de cheques, mientras que en
el segundo recibirá los movimientos del mes en curso. Si este código está en
blanco, el usuario recibirá los dos documentos.

4.3.3.2. SOLUCIÓN

Siguiendo los pasos de la partición equivalente, como primer paso
identificaremos las clases de equivalencia para este ejercicio, tal como se
muestra en la tabla. Cada una de las clases ha sido numerada para facilitar
después la realización de los casos de prueba.

Condición
Tipo Clase Equivalencia Válida Clase Equivalencia no Válida
de Entrada
Código Lógica (puede 1. En blanco 3. Un valor no numérico
banco estar o no) 2. 100<=Código banco<=999 4. Código banco<100
Si está es Rango 5. Código banco>999
Código Rango 6. 1000<=Código sucursal<=9999 7. Código sucursal<1000
sucursal 8. Código sucursal>=9999

Nº cuenta Valor 9. Cualquier número de 5 dígitos 10. Número de menos de
cinco dígitos
11. Número de menos de
cuatro dígitos
Clave Valor 12. Cualquier cadena de caracteres 13. Cadena de menos de
alfanuméricos de 5 posiciones cinco posiciones
14. Cadena de más de cinco
posiciones
Orden Conjunto, con 15. “” 18. Cadena distinta de
comportamiento 16. “Talonario” blanco y de las válidas
distinto 17. “Movimientos” 19. “Talonarios”
20. “Movimiento”

Tabla1. Clases de Equivalencia

Para generar los casos de prueba, consideremos la técnica de Análisis de Valores
Límite. Esta técnica conduce a que determinadas clases de equivalencia se genere
más de un caso de prueba. Este es el caso por ejemplo, de la clase de equivalencia
2 y 6 que representan un rango de valores y para los que la técnica de Análisis de
Valores Límite indica que se generen dos casos de prueba con el límite inferior y el
superior del rango respectivamente (para identificar estos casos de prueba se ha
añadido el sufijo a y b a las clases de equivalencia correspondiente).

Los casos de prueba resultantes se muestran en la tabla.

29


Clase de
Nº Caso Banco Sucursal Cuenta Clave Orden Resultado
Equivalencia
1, 6a, 9a, Todos los movimientos y
1 - 1000 00000 00000 “”
12a, 15 talonario
2a, 6b, 9b,
2 100 9999 99999 zzzzz “Talonario” Envío de talonario
12b, 16
2b, 6, 9, 12,
3 999 1001 12345 Hyu56 “Movimientos” Envío de movimientos
17
4 3, 6, 9, 12, 15 30A 1989 12347 Kuh98 “” Código banco erróneo
5 4, 6, 9, 12, 15 99 1989 12347 Kuf98 “” Código banco erróneo
6 5, 6, 9, 12, 15 1000 1989 12347 Abc80 “” Código banco erróneo
7 1, 7, 9, 12, 15 - 999 12347 Def85 “” Código sucursal erróneo
8 1, 8, 9, 12, 16 - 10000 12345 Hyu56 “Talonario” Código sucursal erróneo
1, 6, 10, 12,
9 - 2345 9999 Jkgy5 “Talonario” Número cuenta erróneo
16
1, 6, 11, 12,
10 - 7863 100000 Jkgy5 “Talonario” Número cuenta erróneo
16
11 1, 6, 9, 13, 16 - 6754 89765 Jut8 “Talonario” Clave errónea
12 1, 6, 9, 14, 16 - 9998 89765 Jut890 “Talonario” Clave errónea
13 1, 6, 9, 12, 18 - 8765 89765 Gar78 988 Orden errónea
14 1, 6, 9, 12, 19 - 7654 89765 Gar78 “Talonarios” Orden errónea
15 1, 6, 9, 12, 20 - 8769 89765 Gar78 “Movimiento” Orden errónea
Tabla2. Casos de Pruebas

30


5. INFORME Y SEGUIMIENTO DE PRUEBAS
5.1.DOCUMENTACIÓN EN EL PROCESO DE PRUEBAS

En un proyecto de desarrollo de software existe un conjunto de documentos asociados a cada
una de las fases del ciclo de vida: planificación, análisis, diseño, construcción, pruebas, etc.
Podemos considerar el proceso de pruebas como un proyecto que se ejecuta en paralelo con
el desarrollo y en el que se pueden distinguir tres grandes etapas:

 Preparación de las pruebas.
 Ejecución de las pruebas.
 Finalización de las pruebas.

En cada una de estas fases hay que generar la documentación apropiada, lo cual puede ser
complicado si no se tiene una referencia adecuada. Para proporcionar una base estándar para
la documentación del proceso de pruebas se creó la norma IEEE 829. IEEE 829 propone una
serie de documentos que encajan en las etapas de prueba de la siguiente forma:

 Preparación de las pruebas.
o Plan de pruebas.
o Especificación de diseño de pruebas.
o Especificación de casos de prueba.
o Especificación de procedimientos de prueba.
o Informe de transferencia de elementos de prueba.
 Ejecución de las pruebas.
o Registro de pruebas.
o Informe de incidentes.
 Finalización de las pruebas.
o Informe de resumen de pruebas.

Aunque el estándar hace referencia a documentos distintos, en la práctica no tienen porqué
ser documentos físicos separados. Incluso en muchas ocasiones, gran parte de la información
no residirá en documentos, sino en herramientas orientadas a soportar el proceso de pruebas.
Por otro lado, no todos los proyectos requieren el mismo grado de formalidad en la
documentación del proceso de pruebas: seguramente no tendrá el mismo rigor documental
un proyecto de un software médico que uno sobre la construcción de un sencillo sitio web.
Otros factores como la cultura y política de la empresa pueden influir en la formalidad de la
documentación.

Podemos mencionar que los elementos imprescindibles en el proceso de pruebas y los cuales
serán usados durante todo el proceso son los siguientes:

o El plan de prueba:

31


Describe todos los métodos que se utilizarán para verificar que el software satisface
la especificación del producto y las necesidades del cliente. Incluye los objetivos de
calidad, necesidades de recursos, cronograma, asignaciones, métodos, etc.
o Casos de prueba:
Lista los ítems específicos que serán probados y describe los pasos detallados que
serán seguidos para verificar el software.
o Reporte de bugs:
Describen los problemas encontrados al ejecutar los casos de prueba.
o Herramientas de pruebas y automatización:
Documentación de las herramientas empleadas en el proceso de pruebas.
o Métricas, estadísticas y resúmenes:
Indican como ha sido el progreso del proceso de prueba. Toman la forma de gráficos,
tablas e informes escritos.

5.1.1. DOCUMENTACIÓN EN LA PREPARACION DE LAS PRUEBAS

La fase de preparación de las pruebas es la que más documentación requiere ya que
implica definir aspectos como el calendario de pruebas, qué se quiere probar, cómo se
va a probar, sobre qué entorno de pruebas, etc.

El primer paso en la documentación del proceso de pruebas es la creación del plan de
pruebas como se ve en la figura 5.1.

Figura5.1. Documentación relacionada en la Preparación de las pruebas según IEEE
829

32


5.1.1.1. PLAN DE PRUEBAS

El plan de pruebas constituye el plan maestro que va a dirigir los esfuerzos de
pruebas de un proyecto determinado. Un plan de pruebas debe contemplar los
siguientes aspectos:

 Qué elementos y funcionalidades del producto software van a ser probados (y
cuáles no), es decir el alcance de las pruebas.
 Quién va a realizar las pruebas (asignar responsabilidades) y qué recursos se
necesitan en cuanto a personas, software, hardware y formación.
 La planificación de las tareas de pruebas, con sus dependencias, calendario,
duración, etc.
 Los tipos de pruebas a realizar (de componentes, de integración, etc.) y las
técnicas elegidas para diseñar las pruebas, así como el nivel de cobertura y los
criterios de salida. Es decir los aspectos relativos a la calidad de las pruebas.
 Los principales riesgos a tener en cuenta, en especial las circunstancias bajo
las cuales se parará o se reiniciará el proceso de pruebas.

ESTRUCTURA FIJADA EN EL ESTÁNDAR

Según el estándar IEEE 829 la estructura que debería contener nuestro plan de
pruebas debería ser la siguiente:
A. Identificador único del documento (para la gestión de configuración).
B. Introducción y resumen de elementos y características a probar.
C. Elementos software que se van a probar (por ejemplo, programas o
módulos).
D. Características que se van a probar.
E. Características que no se prueban.
F. Enfoque general de la prueba (actividades, técnicas, herramientas, etc.).
G. Criterios de paso/fallo para cada elemento.
H. Criterios de suspensión y requisitos de reanudación.
I. Documentos a entregar (como mínimo, los descritos en el estándar).
J. Actividades de preparación y ejecución de pruebas.
K. Necesidades de entorno.
L. Responsabilidades en la organización y realización de las pruebas.
M. Necesidades de personal y de formación.
N. Esquema de tiempos (con tiempos estimados, hitos, etc.).
O. Riesgos asumidos por el plan y planes de contingencias para cada riesgo.
P. Aprobaciones y firmas con nombre y puesto desempeñado.
Q. Glosario

33


5.1.1.2. DOCUMENTO DE ESPECIFICACIÓN DE DISEÑO DE PRUEBAS

La especificación del diseño de pruebas es el primer paso en el desarrollo real de
las pruebas. Este documento especifica las características y funcionalidades que se
quieren probar del producto software (condiciones de la prueba o requisitos de la
prueba) y su priorización, así como los criterios de éxito/fallo de las pruebas. Por
ejemplo, en un módulo de gestión de usuarios, las siguientes podrían ser
condiciones de prueba: “Un usuario puede darse de alta en el sistema”, “Un
usuario puede darse de baja en el sistema”. El documento de especificación de
diseño de pruebas ayuda a determinar en una fase temprana dónde se quieren
centrar los esfuerzos de la prueba, de tal forma que después no se malgasten
energías en crear casos de prueba para elementos que no merecen la pena.

ESTRUCTURA FIJADA POR EL ESTÁNDAR

Según el estándar IEEE 829 la estructura que debería contener nuestra
especificación de diseño de pruebas debería ser la siguiente:

A. Identificador (único) para la especificación. Proporcionar también una
referencia del plan asociado (si existe).
B. Características a probar de los elementos software (y combinaciones de
características).
C. Detalles sobre el plan de pruebas del que surge este diseño, incluyendo
las técnicas de prueba específica y los métodos de análisis de resultados.
D. Identificación de cada prueba:
 Identificador.
 Casos que se van a utilizar.
 Procedimientos que se van a seguir.
E. Criterios de paso/fallo de la prueba (criterios para determinar si una
característica o combinación de características ha pasado con éxito la
prueba o no).

5.1.1.3. DOCUMENTO DE ESPECIFICACIÓN DE CASOS DE PRUEBA

Las condiciones o requisitos de la prueba suelen estar especificadas de forma muy
vaga. Un caso de prueba realiza una especificación más detallada indicando:

 Los datos de entrada concretos que hay que utilizar (por ejemplo, “ejecutar
proceso de alta con nombre de usuario “Juan” y contraseña “123”).
 Cuál es el resultado esperado tras la ejecución de la prueba. Otros elementos
relevantes que deben indicar el documento de casos de prueba son:

34


 Las precondiciones que se han de dar antes de la ejecución del caso de
prueba. Por ejemplo, “El usuario con nombre “Juan” no debe existir en el
sistema”.
 Interdependencias entre los casos de test. Por ejemplo, si hay un caso de test
que crea con éxito un usuario con nombre “Juan”, tendría que ser ejecutado
después del caso anterior para que las precondiciones del primero se puedan
cumplir.


especificación de casos de prueba debería ser la siguiente:

A. Identificador único de la especificación.
B. Elementos software (p. ej., módulos) que se van a probar: definir dichos
elementos y las características que ejercitará este caso.
C. Especificaciones de cada entrada requerida para ejecutar el caso
(incluyendo las relaciones entre las diversas entradas; p. ej., la
sincronización de las mismas).
D. Especificaciones de todas las salidas y las características requeridas (p. ej.,
el tiempo de respuesta) para los elementos que se van a probar.
E. Necesidades de entorno (hardware, software y otras como, por ejemplo,
el personal).
F. Requisitos especiales de procedimiento (o restricciones especiales en los
procedimientos para ejecutar este caso).
G. Dependencias entre casos (p. ej., listar los identificadores de los casos que
se van a ejecutar antes de este caso de prueba).

5.1.1.4. DOCUMENTO DE ESPECIFICACIÓN DE LOS PROCEDIMIENTOS DE
PRUEBA
Este documento especifica aspectos como:

 Los pasos detallados de cómo ejecutar cada test y el orden de ejecución.
 La configuración exacta del entorno de pruebas.

Por ejemplo, un procedimiento de pruebas podría contener instrucciones como las
siguientes:

 Paso 1: Recrear la base de datos ejecutando el script “bbdd.sql”.
 Paso 2: Cargar usuarios en base de datos con el script “usuarios.sql”.
 Paso 3: Acceder a la URL http://pruebas/login
 Etc.

35



especificación de los procedimientos de prueba debería ser la siguiente:

A. Identificador único de la especificación y referencia a la correspondiente
especificación de diseño de prueba.
B. Objetivo del procedimiento y lista de casos que se ejecutan con él.
C. Requisitos especiales para la ejecución (p. ej., entorno especial o personal
especial).
D. Pasos en el procedimiento. Además de la manera de registrar los
resultados y los incidentes de la ejecución, se debe especificar:
 La secuencia necesaria de acciones para preparar la ejecución.
 Acciones necesarias para empezar la ejecución.
 Acciones necesarias durante la ejecución.
 Cómo se realizarán las medidas (p. ej., el tiempo de respuesta).
 Acciones necesarias para suspender la prueba (cuando los
acontecimientos no previstos lo obliguen).
 Puntos para reinicio de la ejecución y acciones necesarias para el
reinicio en estos puntos.
 Acciones necesarias para detener ordenadamente la ejecución.
 Acciones necesarias para restaurar el entorno y dejarlo en la
situación existente antes de las pruebas.
 Acciones necesarias para tratar los acontecimientos anómalos.

5.1.1.5. INFORME DE TRANSMISIÓN DE ELEMENTOS DE PRUEBAS

Detrás de este nombre tan complicado se esconde un documento cuyo propósito
es describir los elementos que van a entrar en una fase de pruebas. De esta forma
los técnicos de pruebas pueden tener la garantía de que los elementos que van a
probar están preparados y saben dónde localizarlos.

5.1.2. DOCUMENTACION DURANTE LA EJECUCION DE LAS PRUEBAS

Durante la ejecución de las pruebas es fundamental conocer el estado del proceso
de prueba, saber qué pruebas se han ejecutado y cuáles quedan pendientes, qué
defectos se han encontrado, etc. Para ello, se crean los registros de pruebas (o los
también llamados Históricos de pruebas o test log) y los informes de incidentes tal
como se muestra en la figura 5.2.

36


Figura 5.2. Documentación relacionada durante la Ejecución de las pruebas según IEEE
829

5.1.2.1. REGISTRO DE PRUEBAS (HISTÓRICO DE PRUEBAS O TEST LOG)

Un objetivo fundamental del proceso de prueba es proporcionar información
acerca del sistema que se está probando. El registro de pruebas documenta los
aspectos relativos a la ejecución de las pruebas: qué prueba se han ejecutado,
quién y cuándo los ha ejecutado, en qué orden, en qué entorno, si la prueba ha
pasado o ha fallado. En este documento es importante también, asociar la
información de ejecución de cada prueba con versiones específicas del software
en prueba para garantizar la trazabilidad. La información recogida en el registro de
pruebas permite conocer el progreso de la fase de ejecución de pruebas y tomar
decisiones acerca de si el software está listo para pasar a la siguiente fase.


Según el estándar IEEE 829 la estructura que debería contener nuestro registro de
pruebas debería ser la siguiente:

A. Identificador
B. Descripción de la prueba: elementos probados y entorno de la prueba
C. Anotación de datos sobre cada hecho ocurrido (incluido el comienzo y el
final de la prueba)

37


 Fecha y hora
 Identificador de informe de incidente
D. Otras informaciones

5.1.2.2. INFORME DE INCIDENTES

Hay que resaltar la referencia al término “incidente”; un incidente no tiene porqué
deberse necesariamente a un defecto en el sistema. Un incidente representa una
discrepancia entre los resultados esperados y los resultados obtenidos. Esta
discrepancia puede deberse a varios motivos, como un defecto, un error en la
especificación de los casos de prueba, una mala interpretación de los requisitos,
etc. El informe de incidentes debe contener toda la información necesaria para la
identificación y resolución del incidente: entradas utilizadas, resultados esperados,
resultados obtenidos, paso del procedimiento en el que se ha producido el
incidente, configuración del entorno, valoración del impacto, etc.


Según el estándar IEEE 829 la estructura que debería contener nuestro informe de
incidentes debería ser la siguiente:

A. Identificador
B. Resumen del incidente
C. Descripción de datos objetivos (fecha/hora, entradas, resultados
esperados, etc.)
D. Impacto que tendrá sobre las pruebas

5.1.3. DOCUMENTACIÓN PARA LA FINALIZACION DE LAS PRUEBAS

Una vez finalizado el proceso de pruebas, se tiene que proporcionar suficiente
información para que los involucrados en el proyecto puedan conocer los resultados
y tomar decisiones.

5.1.3.1. INFORME DE RESUMEN DE PRUEBAS

El informe final de pruebas se crea en hitos determinados del proyecto o al
finalizar un nivel de pruebas determinado. Permite comunicar a todos los
stakeholders los resultados obtenidos para así decidir si el software está listo para
pasar a la siguiente fase. Este informe proporciona información sobre las pruebas
realizadas y el tiempo consumido, así como valoraciones acerca de la calidad del
proceso de prueba realizado, del nivel de calidad alcanzado en el producto. Este
informe final puede servir como base para planificar mejoras futuras en el proceso
de prueba.

38



Según el estándar IEEE 829 la estructura que debería contener nuestro informe de
resumen de pruebas debería ser la siguiente:

A. Identificador
B. Resumen de la evaluación de los elementos probados
C. Variaciones del software respecto a su especificación de diseño, así como
las variaciones en las pruebas
D. Valoración de la extensión de la prueba (cobertura lógica, funcional, de
requisitos, etc.)
E. Resumen de los resultados obtenidos en las pruebas
F. Evaluación de cada elemento software sometido a prueba (evaluación
general del software incluyendo las limitaciones del mismo)
G. Firmas y aprobaciones de quienes deban supervisar el informe

5.2.SEGUIMIENTO DE LAS PRUEBAS

5.2.1. DEPURACIÓN (DEBUGGING)

5.2.1.1. DEFINICIÓN

Casi todos los compiladores suelen llevar asociada la posibilidad de ejecutar un
programa paso a paso, permitiéndole al operador conocer dónde está en cada
momento, y cuánto valen las variables. Los depuradores pueden usarse para
realizar inspecciones rigurosas sobre el comportamiento dinámico de los
programas. La práctica demuestra, no obstante, que su uso es tedioso y que sólo
son eficaces si se persigue un objetivo muy claro. El objetivo habitual es utilizarlo
como consecuencia de la detección de un error. Si el programa se comporta mal
en un cierto punto, hay que averiguar la causa precisa para poder repararlo. La
causa a veces es inmediata (por ejemplo, un operador booleano equivocado); pero
a veces depende del valor concreto de los datos en un cierto punto y hay que
buscar la causa en otra zona del programa. El depurador es el último paso para
convencernos de nuestro análisis y afrontar la reparación con conocimiento de
causa.

39


Figura 5.3. Proceso de Depuración

5.2.1.2. CONSEJOS PARA LA DEPURACIÓN

LOCALIZACIÓN DEL ERROR

 Analizar la información y pensar.
 Al llegar a un punto muerto, pasar a otra cosa.
 Al llegar a un punto muerto, describir el problema a otra persona.
 Usar herramientas de depuración sólo como recurso secundario.
 No experimentar cambiando el programa.
 Se deben atacar los errores individualmente.
 Se debe fijar la atención también en los datos.

CORRECCIÓN DEL ERROR

 Donde hay un defecto, suele haber más.
 Debe fijarse el defecto, no sus síntomas.
 La probabilidad de corregir perfectamente un defecto no es del 100%.
 Cuidado con crear nuevos defectos.
 La corrección debe situarnos temporalmente en la fase de diseño.
 Cambiar el código fuente, no el código objeto.

40


5.2.2. ¿CUÁNDO PARAR DE PROBAR?

¿Cuándo dejar de probar para una actividad de prueba específica?

¿Cuándo dejar de probar todas las actividades principales?

¿Cuándo dejar de probar y liberar el producto?”

CRITERIOS INFORMALES

 Basándonos en criterios de recursos
 Basándonos en criterios de actividad

CRITERIOS FORMALES

 Establecer una meta de confiabilidad durante la planificación de productos y
análisis de necesidades

41


CONCLUSIÓN

Actualmente podemos afirmar que probar es buscarle los fallos a un programa.

La fase de pruebas absorbe una buena porción de los costes de desarrollo de software. Además, se
muestra renuente a un tratamiento matemático o, simplemente, automatizado. Su ejecución se
basa en metodología (reglas que se les dan a los encargados de probar) que se va desarrollando
con la experiencia. Es tediosa, es un arte, es un trabajo que requiere una buena dosis de mala
intención, y provoca difíciles reacciones humanas.

Aunque se han desarrollado miles de herramientas de soporte de esta fase, todas han limitado su
éxito a entornos muy concretos, frecuentemente sólo sirviendo para el producto para el que se
desarrollaron. Sólo herramientas muy generales como analizadores de complejidad, sistemas de
ejecución simbólica y medidores de cobertura han mostrado su utilidad en un marco más amplio.
Pero al final sigue siendo imprescindible un artista humano que sepa manejarlas.

Así podemos afirmar que las herramientas son importantes pero una herramienta de prueba no es
una estrategia ni un proceso ni un plan de prueba.

Una herramienta de pruebas sin saber técnicas, prácticas y tener experiencia en pruebas es tan
útil como un entorno de programación sin saber el lenguaje.

42


RECOMENDACIONES

Con lo leído anteriormente se puede recomendar para la ejecución de una prueba exitosa los
siguientes puntos:

 Cada caso de prueba debe definir el resultado de salida esperado que se comparará con el
realmente obtenido.
 El programador debe evitar probar sus propios programas, ya que desea (consciente o
inconscientemente) demostrar que funcionan sin problemas.
 Además, es normal que las situaciones que olvidó considerar al crear el programa
queden de nuevo olvidadas al crear los casos de prueba.
 Se debe inspeccionar a conciencia el resultado de cada prueba, así, poder descubrir
posibles síntomas de defectos.
 Al generar casos de prueba, se deben incluir tanto datos de entrada válidos y esperados
como no válidos e inesperados.
 Las pruebas deben centrarse en dos objetivos (es habitual olvidar el segundo):
 Probar si el software no hace lo que debe hacer.
 Probar si el software hace lo que debe hacer, es decir, si provoca efectos
secundarios adversos.
 Se deben evitar los casos desechables, es decir, los no documentados ni diseñados con
cuidado.
 Ya que suele ser necesario probar muchas veces el software y por tanto hay que
tener claro qué funciona y qué no.
 No deben hacerse planes de prueba suponiendo que, prácticamente, no hay defectos en
los programas y, por lo tanto, dedicando pocos recursos a las pruebas  siempre hay
defectos.
 La experiencia parece indicar que donde hay un defecto hay otros, es decir, la probabilidad
de descubrir nuevos defectos en una parte del software es proporcional al número de
defectos ya descubierto.
 Las pruebas son una tarea tanto o más creativa que el desarrollo de software. Siempre se
han considerado las pruebas como una tarea destructiva y rutinaria.

Es interesante planificar y diseñar las pruebas para poder detectar el máximo número y variedad de
defectos con el mínimo consumo de tiempo y esfuerzo.

43


BIBLIOGRAFIA

[Libros de Consulta]

[Sitios y Anexos Web]

44

76765984 ejecucion-de-pruebas-original

Recomendados

Recomendados

Más contenido relacionado

Destacado

Destacado (20)

Similar a 76765984 ejecucion-de-pruebas-original

Similar a 76765984 ejecucion-de-pruebas-original (20)

76765984 ejecucion-de-pruebas-original