Ejecución de pruebas(original)

5/12/2018 Ejecución de pruebas(original) - slidepdf.com

http://slidepdf.com/reader/full/ejecucion-de-pruebasoriginal 1/44

Integrantes:

Alvarado Pachas, Euler Hardy.

Orellana Paucar, Rony Eduardo.

Quispe Gamboa, Omar Ernesto.

Saravia Soto, Jhonathan

Vargas Castilla, Kelvin Renzo.

2011 EJECUCIÓN DE PRUEBAS

Calidad de SoftwareIng. Alonso Morales

Facultad de Ingeniería de Sistemas



Ejecución de pruebas 2011

2




3

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




4

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




5

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.




6

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




7

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

1.3. CICLO DE LAS PRUEBAS DE SOFTWARE

Figura 1.3. Ciclo de Vida de las Pruebas de Software

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




8

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 seahacer 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 deprueba es muchas veces superior al del desarrollador de software.




9

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




10

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.

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.

Figura 2.2. Curva de Registro de Hallazgos o No Conformidades




11

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ónde 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.




12

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 deayudar 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-Testerproporciona 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.




13

¿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 dedatos 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 crearfunciones 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 losusuarios 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.




14

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 enVisual 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 formaen 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




15

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.




16

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 quecorre 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 paraAplicaciones (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




17

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.




18

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)




19

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.1. Formato de definición casos de prueba

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




20

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)

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

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




21

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.




22

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 pruebasnegativas 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 lasfallas 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)




23

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 usuariopara 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 elprograma 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)

Figura 3.4. La prueba de caja negra




24

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 desarrollointeractivo (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,

Figura 3.5. La prueba de caja blanca




25

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 unasolució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)

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

Figura 3.6. Equivalencia de particionamiento




26

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)

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

Figura 3.7. Análisis del valor limite




27

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 equivalenciavá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 descubranclases 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:




28

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 deseerealizar. Puede estar en blanco o se una de las dos cadenas siguientes:

o “Talonario”

o “Movimientos”




29

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ónde Entrada

Tipo Clase Equivalencia Válida Clase Equivalencia no Válida

Códigobanco

Lógica (puedeestar o no)

Si está es Rango

1. En blanco2. 100<=Código banco<=999

3. Un valor no numéric4. Código banco<100

5. Código banco>999Códigosucursal

Rango 6. 1000<=Código sucursal<=9999 7. Código sucursal<1008. Código sucursal>=99

Nº cuenta Valor 9. Cualquier número de 5 dígitos 10. Número de menos cinco dígitos

11. Número de menos cuatro dígitos

Clave Valor 12. Cualquier cadena de caracteresalfanuméricos de 5 posiciones

13. Cadena de menos cinco posiciones

14. Cadena de más de ciposiciones

Orden Conjunto, concomportamientodistinto

15. “” 16. “Talonario” 17. “Movimientos”

18. Cadena distinta blanco y de las válida

19. “Talonarios” 20. “Movimiento”

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.

Tabla1. Clases de Equivalencia




30

Nº Caso Clase deEquivalencia

Banco Sucursal Cuenta Clave Orden Resultado

11, 6a, 9a,12a, 15

- 1000 00000 00000 “” Todos los movimtalonario

2 2a, 6b, 9b,12b, 16

100 9999 99999 zzzzz “Talonario” Envío de talonario

32b, 6, 9, 12,17

999 1001 12345 Hyu56 “Movimientos” Envío de movimie

4 3, 6, 9, 12, 15 30A 1989 12347 Kuh98 “” Código banco erró

5 4, 6, 9, 12, 15 99 1989 12347 Kuf98 “” Código banco erró

6 5, 6, 9, 12, 15 1000 1989 12347 Abc80 “” Código banco erró

7 1, 7, 9, 12, 15 - 999 12347 Def85 “” Código sucursal e

8 1, 8, 9, 12, 16 - 10000 12345 Hyu56 “Talonario” Código sucursal e

91, 6, 10, 12,16

- 2345 9999 Jkgy5 “Talonario” Número cuenta e

10 1, 6, 11, 12,16

- 7863 100000 Jkgy5 “Talonario” Número cuenta e

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




31

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:




32

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




33

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




34

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 nuestraespecificació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:




35

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.


Según el estándar IEEE 829 la estructura que debería contener nuestra

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




36


Según el estándar IEEE 829 la estructura que debería contener nuestra

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

A. Identificador único de la especificación y referencia a la correspondienteespecificació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.




37

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)

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




38

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




39


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




40

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.

Figura 5.3. Proceso de Depuración




41

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




42

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




43

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.




44

BIBLIOGRAFIA

[Libros de Consulta]

[Sitios y Anexos Web]

Documents

Ejecución de pruebas(original)