Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

Técnicas de pruebas

No description
by

Sebastian Villegas

on 30 May 2014

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Técnicas de pruebas

Derivación de casos de prueba
El método de prueba de ruta básica puede aplicarse a un diseño de procedimientos o a un código fuente. En esta sección se presenta la prueba de ruta básica como una serie de pasos.
Técnicas de pruebas
de software
Las pruebas representan un interesante reto para los ingenieros de software, quienes por naturaleza son personas constructivas, para realizar las pruebas es necesario que los desarrolladores diseñen casos, para botar el software.
"existe un mito que dice, si uno es buen programador no tendríamos que reparar errores"
¿Las pruebas son realmente destructivas?

Con las revisiones y otras actividades de aseguramiento de la calidad del software, se pueden y deben descubrir errores
Pero no basta con esto. El cliente prueba el programa una vez que se le entrega, por tanto se tiene que ejecutar el programa antes de que llegue al cliente. Y el objetivo específico será encontrar y eliminar todos los errores posibles.

¿Porque es importante realizar pruebas?
¿Cuáles son los pasos para realizar las pruebas?
En aplicaciones convencionales el software se aplica de dos perspectivas diferentes.

1-. Lógica interna del programa: se comprueba médiate técnicas de diseño de casos de pruebas de caja blanca

2.-los requisitos de software se comprueban empleando técnicas de diseño de pruebas de caja negra.

En el caso de aplicaciones orientas a objetos las pruebas empieza antes de la existencia del código fuente.

¿Cuál es el producto obtenido?


Se diseña y documenta un conjunto de casos de pruebas diseñados para comprobar la lógica interna, las interfaces, las colaboraciones entre componentes y requisitos internos, además se definen los resultados esperados y se registran los resultados reales.

¿Cómo puedo estar seguro de que lo he hecho correctamente?

El objetivo es "romper" el software, es por esto qué deben diseñarse casos de pruebas que abarquen todas las funciones del software.

Fundamentos de las pruebas del software.
___________________
El objetivo de las pruebas es encontrar errores y que una buena prueba es la que tiene una alta probabilidad de encontrar un error, por tanto cuando un ingeniero en software diseñe e implemente un sistema de prueba debe tener en mente la facilidad de estas, con el objetivo de encontrar la mayor cantidad de errores con el mínimo esfuerzo.
“Todo programa hace algo bien, pero tal vez sea lo que no queremos que haga"
James Bach .- "La facilidad de pruebas de software indica simplemente si es fácil o no probar [un programa de computadora]".

Operatividad
:
cuanto mejor funcione con mayor eficiencia podrá probarse.
Observabilidad:
lo que se ve es lo que se prueba.
Controlabilidad:
cuanto mejor se controle el software mejor se automatizaran y se mejoraran las pruebas.
Capacidad para descomponer:
al controlar el alcance de la prueba se asistirán los problemas más rápidamente y se aplicaran las pruebas nuevamente con mayor inteligencia. El sistema de software se construye a partir de módulos independientes que también se prueban independientemente.
Simplicidad:
cuanto menos haya que probar más rápido se realizaran las pruebas.
Estabilidad:
cuanto menos cambios haya menores alteraciones habrá en la prueba.
Facilidad de comprensión:
cuanta mayor información se tenga, con mayor inteligencia se realizara la prueba.

Facilidad de prueba
Características de las pruebas
¿Y que hay con las propias pruebas?

Kaner Falk Nguyen sugiere los siguientes atributos para una buena prueba:

Una buena prueba tiene una elevada probabilidad de encontrar un error.
Una buena prueba no es redundante
: El tiempo y los recursos destinados a las pruebas son limitados, por lo que cada prueba debe tener un propósito diferente.
Una buena prueba debe ser "la mejor de su clase".
Una buena prueba no debe ser ni muy simple ni demasiado compleja.

Prueba de caja negra y caja blanca
___________________________
1.- Si se conoce la función específica para la que se diseñó el producto, se aplican pruebas que demuestren que la función es plenamente operacional, mientras se buscan los errores de cada función.
2.- Si se conoce el funcionamiento interno del producto, se aplican pruebas para asegurar de que todas las piezas "encajan". Es decir, que las operaciones internas se realizan de acuerdo con las especificaciones y que se han probado todos los componentes internos de manera adecuada.
En ocasiones llamada pruebas de caja de cristal, es un método de diseño que se usa estructura de control discreta, como parte del diseño a nivel de componentes

1) garanticen que todas las rutas independientes dentro del módulo se han ejecutado por lo menos una vez.

2) ejecutan los lados verdaderos y falsos de todas las decisiones lógicas

3) ejecutan todos los bucles en sus límites operacionales

4) ejecuten todas las estructuras de datos internos para ejecutar su valides


"Los errores abundan en los rincones y se acumulan en los límites" Boris Beizer
Pruebas de caja blanca
__________________
Es una técnica de prueba de caja blanca que propuso inicialmente Tom McCabe, es el método de la ruta básica, la permite que el diseñador de caso de prueba obtenga una medida de complejidad lógica de un diseño procedimental. Y que use estas medida como guía para definir un conjunto básico de ruta de ejecución, es decir las pruebas deben ejecutar cada instrucción del programa por lo menos una vez.
Prueba De La Ruta Básica
Notación de grafica de flujo.
Antes de tratar el método de la ruta básica, debe presentarse una notación simple para la representación del flujo de control, llamado grafica de flujo (o grafica de programa)

Aquí se describe la estructura de control del programa mediante un diagrama de flujo.
Se correlaciona (o mapea) el diagrama de flujo con su grafico correspondiente. (Condiciones compuestas en las decisiones) cada circulo llamado nodo representa una o más instrucciones procedimentales y un diamante de decisión se correlaciona con un solo nodo
Para cada condición debajo del diamante de decisiones se crean nodos diferentes, cada nodo que contiene una condición es un nodo predicado y se caracteriza porque de él salen 2 o más aristas
Rutas independientes del programa
Por ejemplo se muestran las siguientes rutas independientes

ruta 1: 1-11
ruta 2: 1-2-3-4-5-10-1-11
ruta 3: 1-2-3-6-8-9-10-1-11
ruta 4: 1-2-3-6-7-9-10-1-11
Una ruta independiente es cualquier ruta del programa que ingresa un nuevo conjunto de instrucciones de procesamiento o una nueva condición. Una ruta independiente debe recorrer por lo menos una arista que no se haya recorrido antes.
¿Cómo se sabe cuántas rutas buscar?

El cálculo de la complejidad ciclomatica proporciona la respuesta.
La complejidad ciclomatica es una métrica de software que proporciona una medida cuantitativa de la complejidad lógica del programa. Cuando se emplea el método de ruta básica del programa, el valor calculado define el número de rutas independientes en el conjunto básico de un programa, proporciona un límite superior para el número de pruebas que deben aplicarse para asegurar que todas las instrucciones se hayan ejecutado por lo menos una vez.

La complejidad se calcula en una de tres formas:


1. El número de regiones del gráfico de flujo corresponde a la complejidad ciclomática.

2. La complejidad ciclomática V(G) para un gráfico de flujo G se define como

V(G) =E - N +2
donde E es el número de aristas del gráfico de flujo y N el número de nodos del gráfico de flujo.

3. La complejidad ciclomática V(G) para un gráfico de flujo G también se define como
V(G) = P+ 1
Donde P es el número de nodos predicado contenidos en el gráfico de flujo G.


___________________
Al usar el diseño o el código como cimiento, se dibuja el gráfico de flujo correspondiente.
Se determina la complejidad ciclomática del gráfico de flujo resultante.


V(G) = 6 regiones
V(G) =17 aristas - 13 nodos + 2 = 6
V(G) = 5 nodos predicado + 1 =6
Determina un conjunto básico de rutas linealmente independientes
ruta 1: 1-2-10-11-13
ruta 2: 1-2-10-12-13
ruta 3: 1-2-3-10-11-13
ruta 4: 1-2-3-4-5-8-9-2-...
ruta 5: 1-2-3-4-5-6-8-9-2-...
ruta 6: 1-2-3-4-5-6-7-8-9-2-...
Matrices gráficas
_______________
"una matriz gráfica se compone de filas y columnas, en este caso es igual el al número de nodos que se muestran en la gráfica de flujo y cada fila corresponde a un nodo identificado, las entradas de matriz corresponden a las conexiones (aristas) entre los nodos la matriz gráfica no es más que una representación de la gráfica de flujos y a esta se le asigna algunas propiedades"
-La probabilidad de que se ejecute un enlace (arista)

-El tiempo de procesamiento gastado durante el recorrido de un enlace

-La memoria requerida durante el recorrido de un enlace

-Los recursos requeridos durante el recorrido de un enlace

"Un error clásico es prestar más atención a la ejecución de la prueba que a su diseño" Brian Marid
Prueba de la estructuras de control
___________________________
Prueba de condición:

Es un método de diseño de caso de prueba que ejercitan las condiciones lógicas en un módulo del programas es decir es una condición simple ya sea con una variable booleana o una expresión racional.

Una expresión racional tiene la siguiente forma:

E1 <operación racional> E2
Donde E1 y E2 son expresiones aritméticas y las <operaciones racionales> pueden ser (<,>,=,<>, etc).

Una operación compuesta la integran dos o más condiciones simples, operadores booleanos (or, and y not)

Una condición sin expresiones racionales se considera una expresión booleana.
Si una condición es incorrecta, entonces por lo menos un componente de la condición es incorrecto, por tanto, entre los errores posibles de una condición se incluyen los booleanos (incorrectos/faltantes/adicionales) en una variable.

En los operadores racionales y en las expresiones aritméticas el método de prueba de condición se concentra en la prueba de cada condición del programa para asegurar que no contiene errores

Prueba de flujos de datos
Este método selecciona rutas de pruebas en un programa de acuerdo con la ubicación de las definiciones y el uso de las variables en el programa, suponiendo que cada instrucción del programa se le asigna un número,

Pruebas de bucle
Es una técnica de prueba de caja blanca que se concentra exclusivamente en la validez de la construcción de bucles. Es posible definir cuatro tipos:
-simple:
-concatenados
-anidados
-no estructurado
Pruebas de caja negra
__________________

También denominadas pruebas de comportamiento, se concentran en los requisitos funcionales del software, es decir permiten identificar las condiciones de entrada para ejecutar todo los requisitos funcionales de un programa. La prueba de caja negra a diferencia de la caja blanca tiene probabilidades de descubrir una clase diferente de errores. Por lo tanto, la caja blanca está orientada a la estructura de un software en cambio la caja negra trata de encontrar errores en las siguientes categorías de manera funcional.
1.- Funciones incorrectas o faltantes
2.- Errores de interfaz
3.-Errores de estructura de datos o acceso a bases de datos externas
4.- Errores de comportamiento oh desempeño
5.- Errores de inicialización y término

¿Cuales preguntas responden las pruebas de caja negra?
¿Como se prueba la validez funcional?
¿Como se prueba el comportamiento y el desempeño del sistema?
¿Cuales clases de entradas serian buenos casos de pruebas
¿El sistema es particularmente sensible a cierto s valores de entrada
¿ Como se aíslan los limites de clases de datos?
¿Cuales tazas de datos y cual volumen tolera el sistema?
¿Que efecto tienen combinaciones especificas de datos sobre las operaciones del sistema?

Al aplicar estas técnicas se identifica un conjunto de caso de prueba que satisface los siguientes criterios:

1.-Casos de pruebas que reducen en números de pruebas adicionales para alcanzar los casos razonables

2.-casos de prueba que indican la presencia o ausencia de errores, en lugar de un error asociado a ella

Métodos gráficos de prueba
_______________________
El primer paso en la prueba de caja negra es comprender los objetos, modelados en el software y la relación entre ellos. Una vez se ha logrado, consiste en definir la serie de pruebas que verifican que todos los objetos tienen relación esperada entre sí. Explicando de otra manera, la prueba de software empieza al crear una gráfica de objetos importantes y sus relaciones y luego una serie de pruebas que cubran la gráfica de tal manera que se ejecute cada objeto y relación, y que se descubran los errores.
Modelado del flujo de transacción:
los nodos representan pasos de alguna transacción, los enlaces representan la conexión lógica entre los pasos.
Modelado de estado finito:
los nodos representan los diferentes estados que el usuario observa en el software, los enlaces representan transacciones que ocurren para ir de un estado a otro
Modelado del flujo de datos:
los nodos son objetos de datos y los enlaces son las transformaciones que ocurren para traducir un objeto de datos en otro
Modelado relacionado con el tiempo:
Los nodos son objetos de programas y los enlaces son las conexiones secuenciales entre esos objetos. Con los pesos de enlace se especifican los tiempos de ejecución requeridos mientras el programa se ejecuta.

Partición equivalente

La partición equivalente es un método de prueba de caja negra que divide el dominio de entrada de un programa en clases de datos a partir de las cuales pueden identificarse casos de pruebas. Un caso de prueba ideal de manejo simple descubre la ruta más rápida para que se ejecuten todas las funciones de un programa que normalmente tomaría mucho tiempo antes de detectar un error

Métodos de prueba orientados a objetos
La arquitectura de software orientada a objetos genera una serie de subsistemas separados en capas que encapsulan las clases que colaboran entre sí. Cada elemento del sistema realiza funciones que ayudan a cumplir con los requisitos del sistema, por lo que es necesario probar un sistema orientado a objetos en diferentes niveles para descubrir errores que podrían ocurrir a medida que las clases colaboran entre si, aunque estas pruebas son muy similares a las de los sistemas convencionales, se diferencian en que la pruebas orientadas a objetos se realizan a las clases del sistema y examinan si existen errores a medida que las clases van interactuando entre si
I
mplicaciones del concepto orientado a objetos en el diseño de casos de prueba



Debido a que los atributos y las operaciones dentro de las clases están encapsulados, las operaciones de prueba fuera de la clase suelen ser improductivas aunque el encapsulamiento es un concepto de diseño esencial de la orientación a objetos, representa un obstáculo menor cuando se prueban las funciones ya que el propósito de las pruebas es informar sobre el estado concreto y abstracto de un objeto, aunque la adquisición de esta información se dificulta se pueden proporcionar operaciones integradas para representar los valores de los atributos de la clase para poder obtener dicha información

Aplicabilidad de métodos convencionales de diseño de casos de prueba

Los métodos de prueba de caja blanca descritos en secciones anteriores pueden aplicarse en las operaciones definidas para una clase.
Las técnicas de flujo de datos como prueba de la ruta básica de un bucle ayudan a asegurar que se han probado todas las instrucciones de una operación
Los métodos de caja negra son tan apropiados para los sistemas orientados a objetos como a los sistemas convencionales, además los casos de uso proporcionan información para el diseño de pruebas de caja negra y basadas en estado

Prueba basada en fallas


El objetivo de estas pruebas dentro del sistema orientado a objetos es diseñar pruebas que tengan una alta probabilidad de descubrir posibles fallas. Para poder determinar si existen estas fallas se requiere diseñar casos de prueba que revisen el diseño y el código, si las fallas reales en un sistema orientado a objetos se consideran poco posible, entonces este método no es mejor que cualquier técnica de prueba al azar.

La prueba basada en fallas pasa por alto 2 tipos importantes de errores que son:

1) especificaciones incorrectas
2) interacciones entre subsistemas.

Cuando ocurren errores relacionados con especificaciones incorrectas, el programa podría hacer lo incorrecto u omitir funcionalidades importantes

Pruebas basadas en escenarios


La estructura de superficie es la estructura observable, es decir esta interactúa directamente por el usuario final, en lugar de realizar funciones se le dan objetos determinados (interfaces). Las pruebas aun se basan en tareas de usuario para realizar la captura de dichas tareas se requiere de mucha comprensión, observación y comunicación con los usuarios que valga la pena tomar en cuenta

Estructuras de superficie y de fondo en pruebas
Las mejores pruebas se generan cuando el diseñador observa el sistema desde una perspectiva nueva o poco convencional, un ejemplo de esta perspectiva es cuando un diseñador se pregunta
:

¿El usuario deseara usar esta operación?
¿Para qué le sirve realizar esta operación?


La estructura de fondo representa los detalles técnicos internos de un programa orientado a objetos, es decir la estructura que se comprende al examinar el diseño, código o ambos.

La prueba de estructura de fondo está diseñada para ejecutar dependencias, comportamientos y mecanismos de comunicación que se han establecido

Métodos de prueba aplicables al nivel de clase
Prueba aleatoria para clases orientadas a objetos

Para resumir brevemente estos métodos, imagínese una aplicación bancaria en que una clase
CUENTA
tiene las siguientes operaciones:

abrir(), configurar(), depositar(), retirar(), sumar(), cerrar()

Cada una de estas operaciones se aplica a cuenta, pero existen ciertas restricciones
(por ejemplo, la cuenta debe abrirse antes de realizar cualquier otra operación y debe cerrarse al finalizar).

Aun con estas restricciones aun existen muchas acciones con las operaciones como las siguientes:
- abrir()-configurar()-cerrar()
-abrir()-depositar()-sumar()-cerrar()
-abrir()-retirar()-sumar()-cerrar()
Por lo que es posible generar al azar varias secuencias de operaciones para realizar las pruebas

prueba de partición al nivel de clase

La prueba de partición reduce el número de casos de prueba requeridos para ejecutar la clase de manera muy parecida a la partición equivalente. la entrada y salida se ordenan en categorías y se diseñan casos de pruebas para cada una de ellas

La partición basada en el estado:
ordena en categorías las operaciones de clases a partir de su capacidad para cambiar el estado de la clase.

Si se piensa una vez más en la clase cuenta:
Las operaciones de estado incluyen
depositar()
y
retirar()

La partición basada en atributos:
ordena en categorías las operaciones de clase basadas en los atributos que utilizan, en este caso los atributos:
saldo()
y
configurar(
) se utilizan para definir particiones, las operaciones se dividen en 3 particiones

1) operaciones que usan saldo
2) operaciones que modifican saldo
3) operaciones que no usan ni modifican saldo

La partición basada en categorías:
ordena en categorías, las operaciones de clase con base en la función que cada una realiza, por ejemplo.

Las operaciones de inicialización:
abrir() y configurar().
Las operaciones computacionales:
depositar(), retirar().
Las consultas:
saldo().

Prueba de entornos especializados: arquitectura y aplicaciones
Pruebas de interfaces graficas de usuario

Debido a que muchas interfaces de usuario modernas tienen un aspecto y modo de uso similares es posible diseñar una serie de pruebas estándar, pero a su vez las interfaces tienen muchos cambios asociados con las operaciones, por lo que las pruebas deben reducirse empleando herramientas automatizadas para ejecutar objetos específicos de datos y funciones que resulten relevantes para la
GUI.


Pruebas de arquitectura cliente/servidor
en general la prueba de software
cliente/servidor
se presenta en tres niveles diferentes:

1) aplicaciones de cliente individuales
2) el software de cliente y las aplicaciones asociadas del servidor se prueban en conjunto.
3) se prueba toda la arquitectura
cliente/servidor
incluida la operación y el desempeño de la red

Los siguientes enfoques de prueba suelen encontrarse para aplicaciones cliente/servidor

- Pruebas de funcionalidad de la aplicación
- Pruebas de servidor
- Pruebas de base de datos
- Pruebas de transacción
- Pruebas de comunicación de red

Prueba de la documentación y las funciones de ayuda
Los errores en la documentación son tan devastadores para la aceptación del programa como los errores en datos o el código fuente.
nada es más frustrante que seguir una guía de usuario o una función de ayuda en línea y no tener los resultados esperados, por eso la prueba de la documentación debe ser una parte significante de cualquier plan de prueba de software

Para las pruebas de estos sistemas el diseñador del caso de prueba no solo debe considerar los casos de prueba convencionales sino también el manejo de eventos (es decir, el procesamiento de interrupciones), la temporización de los datos, el paralelismo entre otros procesos que manejan datos.


Prueba de sistemas de tiempo real

para realizar estas pruebas se sugieren estos 4 pasos

1) pruebas de tarea
2) prueba de comportamiento
3) prueba de intertareas
4) prueba del sistema

La prueba basada en escenarios se concentra en lo que hace el usuario no el producto, esto significa que se deben capturar las tareas mediante casos de uso que el usuario tiene que realizar y luego aplicarlas, junto con sus variantes estas pruebas tienden a ejecutar varias funcionalidades a la vez, al igual que cualquier usuario
Pruebas Basadas en Escenarios
Full transcript