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

PRUEBAS GUI

No description
by

felipe carmona

on 8 October 2012

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of PRUEBAS GUI

Pruebas GUI (GUI Testing)

Presentado por:
Andrés Felipe Patiño Cano
Jeison Saldarriaga
Juan Felipe Carmona INTRUDUCCION Actualmente, la interfaz gráfica de usuario suele ser una de las partesDe un proyecto software que se prueba de forma menos completa y menosSistemática .No obstante, por desafiantes que sean estos retos, no se pueden obviar lasPruebas en ninguno de los componentes de una aplicación si deseamos obtenerUn producto de calidad. Hoy en día, la calidad no es ya algo deseable, sinoimprescindible, en una sociedad donde la ingeniería del software adquiere cadavez mayor protagonismo y responsabilidad.en diversos campos de aplicaciones. La automatización deeste tipo de pruebas resulta más interesante que otras, ya que, además depermitir la repetición y realización de pruebas en menos tiempo, es posiblegenerar un gran número de test, más variados y con mayor cobertura que losque se puedan producir manualmente. En definitiva, un importante aumentode la eficiencia y la eficacia, al mejorar la calidad de las pruebas y reducir elcosto asociado. Muchos componentes en un sistema no son simples funciones u objetos, sino que
son componentes compuestos formados por varios objetos que interactúan.
La ingeniería del software es basada en componentes, se accede a las
funcionalidades de estos componentes a través de sus interfaces definidas.
Entonces las pruebas de estos componentes se ocupan principalmente de probar
que la interfaz del componente se comporta de acuerdo con su especificación
Dos de las cualidades de las interfaces graficas que se puedan someter a
Pruebas son su funcionalidad y su usabilidad.
Las pruebas de interfaces son particularmente importantes para el desarrollo
orientado a objetos y basado en componentes. Los objetos y componentes se
definen por sus interfaces y pueden ser reutilizados en combinación con otros
componentes en sistemas diferentes Desarrollo Existen diferentes tipos de interfaces entre los componentes del programa, los cuales son: • INTERFACES DE PARAMETROS: Son interfaces en las que los datos, o
algunas veces referencias a funciones, se pasan de un componente a otro
en forma de parámetros.
• INTERFACES DE MEMORIA COMPARTIDA: Son interfaces en las que
un bloque de memoria se comparte entre los componentes. Los datos se
colocan en la memoria por un subsistema y son recuperados desde aquí
por otros subsistemas.
• INTERFACES PROCEDURALES: Son interfaces en las que un
componente encapsula un conjunto de procedimientos que pueden
ser llamados por otros componentes. Los objetos y los componentes
reutilizables tienen esta forma de interfaz.
INTERFACES DE PASO DE MENSAJES: Son interfaces en las que un

componente solicita un servicio de otro componente mediante el paso de
un mensaje. Un mensaje de retorno incluye los resultados de la ejecución
del servicio. Algunos sistemas orientados a objetos tienen esta forma de
interfaz, así como los sistemas cliente-servidor Podemos establecer tres
categorías de técnicas para la prueba de la funcionalidadde las interfaces graficas: métodos manuales, métodos formales y métodosautomatizados Métodos manuales:
Consisten en la utilización intensiva y aleatoria de la interfaz.Cuando las realiza un experto suele denominar “inspección"; cuandolas realizan usuarios reales, beta testing. En cualquier caso, los mayoresinconvenientes de estos métodos son la dificultad a la hora de reproducir un
error después de detectarlo Métodos formales:
Los métodos formales más habituales son la prueba de teoremas y el model checking. En el caso de los métodos formales, el nivel de especialización requerido porparte de quienes deben realizar las pruebas o escribir los modelos se traduceen que, a día de hoy, solo la industria del hardware utiliza este tipo de técnicasde manera efectiva, mientras que su uso en la industria del software es todavía anecdótico. Métodos Automatizados: la estrategia más utilizada es la llamada prueba basada en modelos, que consiste en modelar la interfaz con alguna abstracción conocida. Por ejemplo, es habitual emplear una máquina de estados finitos (FSM)en la que cada estado de la interfaz gráfica se mapea a un estado de la máquina.A partir del modelo, se generan casos de prueba según alguno de los algoritmos conocidos, como. Por último, se comparan los resultados de la ejecución de loscasos de prueba en la aplicación real con los esperados (los que produce elmodelo, la máquina de estados) para determinar el correcto funcionamiento de la interfaz. Una forma de especificar formalmente un sistema de software es mediante propiedades, esto es, mediante enunciados declarativos. Por ejemplo:
Una vez aplicada la función de borrado a un entero y una listade enteros, el entero no ha de aparecer en ninguna posición de la lista.Podemos escribir dicho enunciado más formalmente como:
Lista; N; N =2 borra todos(N; Lista)
La prueba basada en propiedades se basa en contrastar las propiedades que especifican la funcionalidad de una aplicación, componente o sistema software con los resultados arrojados por su implementación para comprobar su corrección. Es una estrategia de prueba sistemática, de alto nivel y muy potente. QuickCheck es una librería para automatizar este tipo de pruebas. Está disponible para varios lenguajes de programación, aunque la única versión
comercial es para el lenguaje funcional Erlang, desarrollada por QuviQ AB.Definir la propiedad anterior con QuickCheck es así de inmediato:

propiedad_borrar_lista() ->
?FORALL(N, int(),)
?FORALL(Lista, list(int()),
not lists:member(N, mi_lista:borra_todos(N, Lista)))).





el cuantificador universal del mismo nombre, y cuya sintaxis permite indicar donde ?FORALL es una macro proporcionada por la librería para representar una variable (N, Lista), una función generadora de valores para esa variable (int(), un generador de enteros; list(int()), un generador de listas de enteros) y un predicado donde la variable se utilice para expresar una propiedad de tipo booleano . En el ejemplo anterior, mi lista es el modulo en el que la función borra todos esta implementada, y que queremos someter a prueba. Para traducir el enunciado booleano, utilizamos la función member del modulo lists, que forma parte de la libreria estándar de Erlang, cuya implementación consideramos libre de errores. Definida una propiedad, esta librería es capaz de generar casos de prueba para ella y ejecutarlos automáticamente:

1> eqc:quickcheck(mi_lista:propiedad_borrar_lista
OK, passed 100 tests







Si se encontrase algún fallo, es decir, si alguno de los casos de prueba generados incumpliese la propiedad especificada al ejecutarse (es decir, hiciese falsa la evaluación del enunciado), QuickCheck reduce el caso de prueba que lo ocasiono hasta obtener uno equivalente de menor tamaño. Por ejemplo, si nuestra implementación de borrar todos solo eliminase la primera aparición de N en Lista, nos mostrara este mensaje:

2> eqc:quickcheck(mi_lista:propiedad_borrar_lista
.Failed! After 92 tests.
25[25,-24,7,17,25,18,-19,-28]
Shrinking....(4 times)
25
[25,25]
False

El primer error se encuentra al intentar borrar un elemento (25) de una lista de ocho elementos ([25,-24,7,17,25,18,-19,-28]), tras 92 casos de prueba con diferentes valores de N y diferentes tamaños y composiciones de
Lista generados aleatoriamente, para los que si se cumpliera la propiedad. El algoritmo es capaz entonces de reducir ese contraejemplo a una lista con solo dos elementos ([25, 25]) que produce el mismo error. Este proceso, denominado shrinking, permite así obtener un contraejemplo con el que reproducir sistemáticamente el error encontrado del menor tamaño posible. Así, resulta trivial en este caso identificar que el error seguramente tenga que ver con eliminaciones en listas con elementos repetidos y podríamos depurar la implementación utilizando este caso sencillo como referencia.
Full transcript