evento cda abstracta - perú 2015 - testing de performance y testing automático. federico toledo

74
Noviembre 2015, Lima, Perú TESTING Automatización y Performance Herramientas para optimizar tiempos y garantizar calidad. PhD. Federico Toledo federico.toledo@abstracta. com.uy Twitter: @fltoledo

Upload: federico-toledo

Post on 20-Jan-2017

397 views

Category:

Software


0 download

TRANSCRIPT

Presentacin de PowerPoint

Noviembre 2015, Lima, Per TESTING Automatizacin y PerformanceHerramientas para optimizar tiempos y garantizar calidad. PhD. Federico [email protected]: @fltoledo

1

Per 2010 - 2015Historia Global y Local Noviembre 2015

Quines somos en el Per y resto de la regin?Fundada en el ao 1986 en Argentina y desde el ao 2010 en el Per Casi 500 profesionales de IT en total, en el Per ms de 60 y creciendo da a daMs de 9 millones de horas empleadas en la actividadMs de 50 bancos, compaas e industrias lderes en la regin nos eligieronOficina en Lima ubicada en el centro financiero de la ciudadPresencia internacional en seis pases:

Argentina Chile Espaa Mxico Per - Uruguay

3

Nuestra historia4

19861998200120042008201120122010

Creacin de la empresaPrimera Sede nacional en Arg

Renovamos la marcaPrimera Software Factory

Apertura Sede Mxico

ISO 9001

Certificaciones InternacionalesApertura Chile

Apertura Sede PerApertura Sede Espaa

Sede Corporativa en Bs.As2009

Nuestros Clientes en el rea de Desarrollo de SW 5ServiciosClientesDesarrollo y Mantenimiento de Sistemas

Software Factories

Nuestros Clientes en el rea de Calidad de SW 6ServiciosClientesTesting Funcional, RegresinTesting Automatizado, Stress

Una breve presentacinbit.do/librodetesting

Community+270

+180www.meetup.com/Testing-Uywww.testing.uy

+100Charlas, cursos, papers, artculosblog.abstracta.com.uy+5000 visitas mensuales

Aprovechemos la comunidad, aprovechemos la cantidad de empresas y universidades con foco en mejorar la industriaTesting Uy ms de 270 inscriptos el da anteriorMeetup Smense para debatir y proponer temas y discusiones en meetup.comApoyen los Open Device Lab !8

www.nahual.uy+15 colaboradores3 chicos trabajando+30 formados

Por qu trabajas en testing?No conseguiste otra cosa mejor?Prejuicios del testing:Es aburridoEs repetitivoNo tiene desafosEs el trabajo para el programador nuevo

10

#TestingRocks

Hablemos dePerformance testingDel lado del clienteDel lado del servidorPruebas automticas de regresinPara garantizar la calidad

Les aseguro que en todas estas cosas que vamos a ver ac, veremos que el testing no es aburrido, no es repetitivo, tiene desafos12

Usuarios acostumbrados a usar el celular en todo momento y a exigir cada vez ms velocidad, usabilidad, etc.

Los usuarios afectan el mercado, comentarios y calificaciones en GooglePlay o AppStore.

Performance+60% de los problemas de las apps que fracasan son de performance.Gold Standard era 6s, luego 3s, Google apunta a 1s.El usuario espera que en su celular funcione mejor que en us PC.

No s de dnde saqu esa estadstica, pero si la repetimos 1000 veces se convierte en verdad15

Performance Computer performanceis characterized by the amount of useful work accomplished by a computer system compared to the time and resources used.

Requisito no funcional del sistema

Notar que esta definicin tiene sentido con lo que veamos antes, presta especial atencin a los dos factores de calidad time-behavior y resources used.16

Y si no hay performance, qu pasa?

Contar ancdota de un banco que hace ambas, y casi le dan ms importancia a la simulacin con las personas.17

El trabajo equivocado

Entonces, los bomberos en las empresas se transforman en los recursos mas importantes!Encaramos muchas veces el trabajo en forma reactiva en vez de preventiva.En vez de andar apagando algunos incendios, tenemos que dedicarnos a resolver OTROS problemas.El testing, como todas las actividades, tiene sus desafos y dificultades18

Las soluciones equivocadasMs hardware!!

Pruebas de performanceCmo ayudamos:Simular situaciones de carga para conocer el desempeo del sistema del lado del servidorAnalizar oportunidades de mejoraOptimizaciones Mejoras, cambios, ajustesPara qu:Verificar si el sistema soporta la carga esperadaVerificar si se cumplen acuerdos de nivel de servicio (SLA)Detectar errores u oportunidades de mejora, que solamente son observables ante la concurrenciaDetectar bottle-necksObjetivo:Asegurar satisfaccin de los usuarios

Presentacin de los presentesQuin ha estado relacionado en tareas de pruebas de performance?21

Cundo necesitamos las pruebas de performance?MetasSatisfaccin del usuarioVerificar nuevo componente/migracinRequisitosSLA, homologacionesRestriccionesPresupuesto, tiempoLimitantesInfraestructura de pruebas

Performance Criteria are boundariesdictated or presumed by someone orsomething that matters

Goals: Soft Boundaries (User Satisfaction)Requirements: Firm Boundaries (Business or Legal)Constraints: Arbitrary Boundaries(Budget or Timeline)Thresholds: Hard Boundaries (Laws of Physics)

22

Qu buscamos?El objetivo de la ejecucin en gran parte es buscar los bottlenecks para mejorar el sistema

Las dos caras

Performance Client SideWebappPageSpeed Insights developers.google.com/speed/pagespeed/insights Webpage Test www.webpagetest.orgSiteSpeed run.sitespeed.io Yslow www.yslow.org Mobile Nativa Monkop www.monkop.com

Qu aplicacin probamos?Necesito un conejillo de indiasQuin se anima a prestar su aplicacin para la demo?

Sitios ms visitados en PerSacando Facebook, Youtube, Google, porno y otroshttp://elcomercio.pehttp://www.sunat.gob.pe

PageSpeed InsightsPerformance y usabilidad.

Informacin para optimizacin del lado del cliente: Web desktopMobile

Basado en best-practices.

Luego de que la pgina es analizada, el Page Speed despliega una lista de los 29 escenarios comentados anteriormente clasificados segn 4 colores (verde, amarillo, rojo, y azul) y ordenados de acuerdo a su importancia junto con una valoracin general de la pgina.

27

PageSpeed Insights

Luego de que la pgina es analizada, el Page Speed despliega una lista de los 29 escenarios comentados anteriormente clasificados segn 4 colores (verde, amarillo, rojo, y azul) y ordenados de acuerdo a su importancia junto con una valoracin general de la pgina.

28

PageSpeed Insights

Luego de que la pgina es analizada, el Page Speed despliega una lista de los 29 escenarios comentados anteriormente clasificados segn 4 colores (verde, amarillo, rojo, y azul) y ordenados de acuerdo a su importancia junto con una valoracin general de la pgina.

29

PageSpeed InsightsLuego nos plantea cmo solucionarlo:

Optimizar trfico

Performance Client SideWebappPageSpeed Insights developers.google.com/speed/pagespeed/insights Webpage Test www.webpagetest.orgSiteSpeed run.sitespeed.io Yslow www.yslow.org Mobile Nativa Monkop www.monkop.com

by

Monkop

Monkop

Monkop

Explorando la app de FIFA

Todo con lo de FIFA

Ms de 1000 apps probadasMs de 40 betatesters

Esto es lo que tenemos hoyEvaluamos ya ms de 1000 aplicaciones, encontrando oportunidades de mejoras para todas ellas.

Hay una versin beta que se est usando, por ahora gratis por perodo de evaluacin, sin estar facturando an.37

Explorando otras aplicaciones

Encuentro GeneXusMarcaFotocasaLa LigaVivaVideo

ac estn los top de espaa para androidhttp://www.appannie.com/apps/google-play/top/spain/overall/

38

Monkop

Reporte de ejemplo: https://goo.gl/bMf46T

Las dos caras

Cmo hacerlo?

41En otras disciplinas est mucho ms patente y arraigada la necesidad de realizar pruebas de stress y carga.La pregunta es: siempre hablamos de lo mismo cuando se realiza test de carga?

Tipos de pruebas de performancePruebas de carga (load test)Pruebas de estrs (stress test)Pruebas de resistencia (endurance test)

Otras Pruebas de escalabilidad Pruebas de picos

Hay muchos tipos de pruebas, y veremos que de acuerdo al tipo de prueba que hagamos ser el objetivo que tendremos, y as ser distinta la simulacin que estaremos haciendo.42

Load test

Mostrar distintos tipos de pruebas que se le pueden hacer a un puente43

Stress test

Lo bueno que esto se puede hacer en el software, porque si se rompe es simplemente apagar y prender, ac en un puente es ms complicado pero se hace de un modo u otro.44

Endurance

Mostrar distintos tipos de pruebas que se le pueden hacer a un puente45

Scalability

Mostrar distintos tipos de pruebas que se le pueden hacer a un puente46

Performance Server SideCmo simulamos el uso real del sistema?Manualmente Usando herramientas Conceptos importantesSimulacin de cargaConcurrencia Usuarios virtuales

Mostrar primero qu se necesita para hacerlo en forma manualDe todos modos se necesita automatizacin, el sistema, la infraestructura y todo esoLa complicacin es la coordinacin y repetitibilidad de las pruebasAh metemos herramientas de generacin de carga en forma automatizada y soluciona mucho estos problemas y baja costosCon pocas mq

Performing load testing without an automated load-testing tool is problematic. Manual load testing is costly, time consuming, and not practical. With manual load testing, it is difficult to replicate the tests over and over again; there is no repeatability. It is almost impossible to simulate tens of thousands of users, while coordinating time, people, machines and the overall testing environment. Also, because it is hard to replicate the tests over again, the results become difficult to analyze.

Automated load testing tools on the other hand allow QA professionals to re-run the exact tests over and over again with different premises. With an automated load-testing tool, QA can simulate load conditions, such as number of sessions per hour and then simulate users accessing the application at the same time. For example, QA can run a test that simulate a load of 100 users, then with 200 users, up to tens of thousands of users. At each load, QA will find out how well the application scales and behaves. Also, automated load testing tools allow QA professionals to easily gain access to client side response time and server statistics, such as CPU and memory utilization.With an automated load-testing tool, QA can gain repeatability, reusability, and results that matter. Automated load-testing tools also allow Managers to utilize their QA staff and computer resources more efficiently in order to ensure the optimum stability, responsiveness, scalability, and throughput of an application before it is deployed

uinas y sin requerir coordinacin con 100s de personas podemos simular su uso.48

Automatizacin / robotizacin

El esquema no lo planteamos nosotros, sino que es lo que se usa

Se pueden llegar a hacer las pruebas manuales (simulaciones) + las pruebas de performance en concurrencia

Easy to useWorkflow bar guides you through all stepsSingle point of control: Health control for agents as well as automatic agent detection, VUser load balancing, remote agent setupPowerful project concept

PowerfulReplaces tests with virtual users (vs. manual load testing)Automatically synchronizes all virtual users (vs. manual load testing)Systematic and reproducible (vs. manual load testing)Runs thousands of VUs on a single machine (TrueScale technology !!!)IP spoofing and DNS lookup with full scalability (without any penalty on performance or scalability)Various TrueLog formats

AccurateAccurately simulates the load of realistic usersTrueCacheTrueModemTrueLogReliable error detection on application level (automated link verification)

Isolate problems simply and quickly throughContent verifications, even under heavy loadVisual logs that show you the click paths to your errors (TrueLog On Error)Detailed response time breakdown analysis (also on error e.g. threshold exceeded during a load test)Real-time performance monitors for your back-end systemsIn-depth management reports

50

Cmo se prepara un UV?

51Para entender lo que significa grabar un script, vamos a ver cmo lo hace

Generalmente lo que se hace es que la herramienta se ponga en el medio de forma de proxy. De esta manera los pedidos HTTP van a pasar por ah.-

Automatizacin en MobilePor lo general es ms fcil que en webInvocacin a servicios REST

Viajan menos datos, menos para parametrizar

BlazeMeterhttps://blazemeter.comURLPrueba de JMeter Prueba de Webdriver (Selenium)

Ejecucin Plan de Pruebas

BaseLineMejor tiempo posibleIterativo para tener datos estadsticos

EscenarioIncrementalComenzar con un 20% de la cargaEscalar hasta llegar al 100%

Baseline Ya podemos ir analizando los tiempos unitarios. Si con un nico usuario esto no funciona en los tiempos que establecimos en un inicio como aceptables, entonces la carga no va a funcionar tampoco en los tiempos que nos propusimos. Adems nos servir como comparacin de rendimiento ante carga y rendimiento standalone.Se ejecutan varias iteraciones para tener resultados estadsticos, y poder as descartar casos anmalos que se pueden dar.Escenarios comenzamos con una pequea carga. Nos sirve tambin para verificar que los scripts y el resto de los componentes de prueba estn funcionando bien antes de lanzar la carga objetivo. Si tiramos el 100% de la carga al comienzo y nos da muchos errores o problemas, es ms dificil atacar eso, q ir incrementando desde pocas cantidades ya que los problemas irn saltando de a uno.

54

Herramientas de Generacin de cargaLa herramienta no hace al tester

Enterprise grade load generation tools are designed to look easy in sales demos. Dont be fooled.Scott Barber

Alonso en un autito (foto del mo?)Mi madre en un ferrari?55

Automatizacin de pruebas funcionales

Automatizar ejecucin de pruebasLograr que los casos de prueba sean ejecutados por una mquina

Lo primero es Qu significa automatizar pruebas?

Una definicin coloquial es lograr que los casos de prueba que ejecutamos manualmente sean ejecutados por una mquina.57

Aumentar la cobertura de pruebas y calidad del productoReducir tiempos de ejecucin y salida al mercadoEjecucin en distintos ambientesEl trabajo queda documentado en los scripts de prueba

Beneficios

58

Los resultados quedan registrados y nos sirven para tomar decisionesDeteccin temprana de erroresReducir el costo total de la aplicacinApoyo y motivacin al equipo manual para pensar en pruebas alternativas

Beneficios

Adems hay otros beneficios como:- documentar las funcionalidades dejar registrados automticamente los resultados de esas pruebas. Sacar luego estadsticas en base a eso. se puede ejecutar con mnimo costo en distintos ambientes

Les planteo otra cuestin. Si maana se nos va alguien, un tester o analista, que tena el conocimiento de cmo deba funcionar determinado mdulo o funcionalidades. Este es un problema para nada despreciable, no? Es un riesgo con el que siempre estamos jugando. He aqu una forma de disminuir los impactos de este riesgo. Intentemos registrar el conocimiento sobre el comportamiento esperado de la aplicacin. Si un especialista indica que es interesante verificar que la funcionalidad se comporta correctamente en determinada situacin, entonces al menos eso hay que registrarlo en un papel, en un inventario de pruebas, cosa de tener la posibilidad de volver a ejecutarlo a futuro. Mucho mejor si eso lo podemos automatizar fcilmente y agregarlo a la batera de pruebas. Servir como documentacin clara y NO ambigua del resultado esperado.Documentacin con casos de pruebaDejar el know-how de testing en un formato ejecutable un testcase es entendible, legible, no ambiguo59

Cmo automatizar?Se debe utilizar una herramienta

Algunos conceptos importantesRecord & PlaybackData-Driven TestingPage ObjectModel-Based Testing

Cmo Automatizar?En primer lugar, para automatizar es necesario una herramienta.Estas son algunas de las caractersticas de este tipo de herramientas:Record & Playback: Grabar y ReproducirData Driven Testing: Testing dirigido por DatosModel Based Testing: Testing Basado en Modelos Lo que se suele hacer para armar los artefactos de prueba, es lo que se llama record and playback. Esta funcionalidad permite automatizar casos de prueba con herramientas que son capaces de grabar/capturar (record) las acciones que realiza el usuario, para luego poder reproducirlas (playback). Por otro lado, el enfoque de testing dirigido por datos, es una tcnica para construir casos de prueba basndose en los datos entrada, y separando el flujo que se toma en la aplicacin. Esto permite agregar nuevos casos de prueba fcilmente, ingresando simplemente los datos de entrada y los datos de salida esperados.El testing basado en modelos (MBT) es un paradigma que consiste en tener pruebas basadas en una abstraccin de la realidad mediante un modelo. Esto permite trabajar con un mayor grado de abstraccin, sin tener que lidiar con los problemas tcnicos, concentrndose slo en el modelado del problema, y haciendo que sean ms fciles de entender y mantener. 60

Selenium Record and PlaybackUser interface level automation

Lets start with functional testing automationDo you know about . Record and playback approach? User interface level automation? .. And what about Selenium, that it is a tool for that?61

Cmo funciona Selenium

Tester / UserSUT: System Under TestManual Test Case Execution

Just in case you dont know it, basically, we use the tool (that is an addon of Firefox) to capture the actions we do on the system, so we open the tool and the first time we execute the test case manually on the browser, on firefox in this case.62

Como funciona Selenium

Functional Test ScriptsSelenium captura las interacciones del usuario

Tester / UserEjecuta y reportaSUT: System Under TestManual Test Case ExecutionEsto es record and playback!

So, Selenium captures the actions on the webpage, in a script file. This script can be used later to execute the same actions as many times we want, when we want. This is useful to execute in an easier way all the test cases each time we want. This is record and playback. It is important to hinghlight that for these tools the test cases are executed on the browser. So, if we decide to playback a test case, Selenium opens the browser, and executes all the actions of the script on the browser. 63

Data-driven con Selenium

Selenium also let us improve the script, actually we can execute the script from java code (Integrating the selenium scripts with junit), what gives us a lot of flexibility. For example, the same script could be executed with different test data (what is known as data-driven testing).

Junit parametrizadoData-driven testing

64

Distintas dimensiones para aprovechar:

Tiempo Plataformas Datos Beneficios solo a largo plazo?

Siempre nos pasa que es difcil dedicar tiempo a algo que da principalmente beneficios a largo plazo. Pero el truco est en hacer que nos de beneficios a corto plazo, inmediatamente!Para ver como les cuento un ejemplo

En un proyecto anterior, el incluir una estrategia de automatizacin era parte de la mentalidad y objetivos de la alta gerencia, aunque no as por parte de la gerencia media. Se propona que los equipos de automatizacin enfocaran su tiempo y esfuerzos en automatizar absolutamente todos los casos de prueba de regresin. Para ello, pudimos demostrar que no slo era una meta y objetivo imposible de lograr, sino que tambin no habra de reportarles los beneficios en un marco de tiempo que les proporcionara agilidad con las pruebas de sus productos.

En su lugar, planteamos que en un principio se comenzara con la automatizacin de las pruebas de humo, las cuales aunque requirieron de un esfuerzo, comenzaron en el corto plazo a ser de utilidad tanto para los equipos de testing como tambin para los equipos de desarrollo, puesto que podan ejecutarse simultneamente en distintos ambientes, ayudando a reducir los tiempos de testing del equipo manual con la ejecucin de estas pruebas.

http://www.kaner.com/pdfs/autosqa.pdf

Todos sabemos que mientras ms tarde detectemos los bugs ms costar corregirlo. Si dedicamos tiempo a hacer pruebas automatizadas tendremos menos tiempo para probar otras funcionalidades, entonces haremos que corregir esas pruebas sea ms caro.Por otro lado, automatizando una prueba podremos ejecutarla con muchos datos, y de esa forma acelerar la ejecucin de otros casos, que de ser ejecutados manualmente demoraramos ms tiempo por lo que entonces estaramos ahorrando el costo de correccin de estos bugs.65

Framework Xtest

Automatizar el caos, solo traer ms caos ms rpido.

Las herramientas NO piensan.Lo bueno es que siempre ejecutan lo mismo.Lo malo es que siempre ejecutan lo mismo.

Priorizar, seleccionar y disear las pruebas pensando en automatizarlas.

Cuidado!

Las herramientas no nos evitan el trabajo de pensar. Por suerte :D

Hay empresas que han fracasado con automatizacin pero no por la herramienta, sino por no haber seguido el camino correcto. O sea, hay que pensar para priorizar y seleccionar y disear pruebas que den valor, y no automatizar cualquier cosa. Incluso una buena prctica podra ser, tomar la lista de casos de prueba que tenemos diseados y revisar cules de esos vale la pena automatizar. No tienen por qu ser todos! Tenemos que pensar cules van a darme ms valor. Cules van a ser fciles de mantener, cules son crticos, cules me interesa probar siempre. Si automatizamos as no ms sin pensar nos va a ir mal.

Citando una frase del libro de Software test Automation, automatizar el caos nos traer ms caos, ms rpido. Incluso escribimos algunas de estas ideas en un post de nuestro blog (http://blog.abstracta.com.uy/2010/08/automating-chaos-just-gives-faster.html), y bueno, para darle un poco ms de difusin lo tiramos por twitter, y para nuestra sorpresa rpidamente Michael Bolton (un referente en testing) nos responde que no slo ms rpido, sino que logra intensificar el caos, y hacer que aparezca caos donde antes nadie se imagin que poda haber caos!!67

Qu formas hay de automatizar?Se puede automatizar en distintos niveles:A nivel de cdigo: pruebas unitarias, invocando directamente mtodos de clases del sistema. A nivel de Componentes o Servicios: pueden ser a nivel de interfaces de los controllers, WS, etc. A nivel de Sistema (o End-to-End): desde la interfaz grfica.

Cmo debera ser?Pirmide de Cohn

Ms info:http://abstracta.us/2015/10/26/best-testing-practices-for-agile-teams-the-automation-pyramid/

http://www.javiergarzas.com/2015/01/automatizacion-pruebas.html69

Cmo se suele hacer?Antipatrn del Cono de Helado

Cmo debera ser?Casos de prueba

Exploratorio

1 hora

2 horas

http://www.javiergarzas.com/2015/01/automatizacion-pruebas.html71

Resumen

Vamos a hablar del proceso en orden segn suceden en un proyecto tpico, e incluso observen que los bloques tienen diferentes tamaos y no es por su importancia, porque ya veremos que cada etapa tiene vital importancia para el xito del proyecto, pero esto muestra el cmo se dan en el tiempo. Pretende ser algo as como un diagrama de Gantt, mostrando cunto dura cada uno en comparacin, y en qu momentos se dan. Lo dejaremos para discutirlo luego, pero vayan comenzando a pensar en esto.73

Introduccin a las Pruebas de Sistemas de Informacinhttp://blog.abstracta.com.uy/

Siguen pensando que el testing es aburrido y sin desafos tcnicos?testing es aburrido y sin desafos tcnicos?

PhD. Federico [email protected]: @fltoledoGracias!

#TestingRockshttp://www.slideshare.net/FedericoToledo

Subir las ppts a slideshare76

Framework Xtest

Por qu Xtest?Alto nivel ms fcil de aprenderGeneracin inicial de pruebas (OneClickStartup)Crossplatform (browsers, dispositivos)Adaptable (absorbe cambios)Reportes automticos (doc, web)

Por qu Xtest?Record and playback Data driven testingGestin centralizada, ejecucin distribuida Pruebas de performanceComparador de ejecuciones

ManagerRepositorio de pruebasAcceso WebAgenda de ejecucionesTesterDiseador de pruebas

Ejecucin DistribuidaComponentes de Xtest

Los componentes de Gxtest se pueden separar en 3 grupos o perfiles.El primer grupo, son los componentes que utilizar el tester. En este grupo est:GXtest Designer, que es el componente donde el tester va a disear sus casos de prueba, va a definir el flujo y los datos para la prueba, y va a probar el caso de prueba. (S, a los casos de prueba tambin hay que probarlos)GXtest Recorder es un plugin que se instala en el Internet Explorer, que nos permite grabar un flujo o secuencia de acciones que hacemos sobre la aplicacin en el navegador, y a partir de esto nos genera un caso de prueba de GXtest.GXtest Extension es una extensin para GeneXus para generar de manera automtica casos de prueba, a partir de informacin de los objetos de la base de conocimiento GeneXus.

Por otro lado, tenemos a Gxtest Manager, que es una aplicacin web donde se centralizan los casos de prueba, similar a un repositorio. Los testers pueden trabajar de manera colaborativa, compartiendo casos de pruebas y juegos de datos a travs del repositorio. Adems, en este componente se pueden agendar ejecuciones de pruebas de manera desatendida y en paralelo.

Por ltimo, tenemos a GXtest Executor, que es un componente liviano que se encarga de ejecutar las pruebas de manera desatendida, iniciando el navegador y ejecutando los comandos especificados en la prueba, cuando GXtest Manager se lo indique.80

Framework Xtest

Qu es ?Herramienta de testing especfica para aplicaciones Web GeneXus

GXtest es una herramienta de automatizacin de pruebas funcionales, especfica para aplicaciones generadas con GeneXus.Lo que logra es combinar los 3 paradigmas que mencion, permitiendo grabar casos de prueba mediante el enfoque de R&P, editarlos mediante un modelo grfico y luego variar los datos de entrada mediante la tcnica de DDT

82

Cmo se logra?GXtest asocia Artefactos de Prueba a la KB

Gxtest sigue el paradigma de Testing Basado en Modelos, utilizando modelos para expresar los casos de prueba. Esto permite acompaar la filosofa Genexus en la simplicidad que nos provee para el desarrollo. Los modelos son ms simples de entender y de mantener que el cdigo. A partir de los modelos luego se pueden obtener casos de prueba concretos y ejecutables.

Ahora bien, la clave de GXtest es que asocia estos modelos (que son nuestros casos de prueba) a elementos de la KB de Genexus, lo que permite mantener de manera sencilla los casos de prueba.

Bien pero veamos un ejemplo para entender mejor a que nos referimos con esto

83

EjemploTransaccin Clientes

Herramientas tradicionales:

GXtest:

Si tenemos en GeneXus una transaccin Clientes con un atributo ClienteNombre.Entonces en las herramientas tradicionales (en las cuales se utiliza algn lenguaje de programacin o scripting), los casos de prueba se automatizan en base a elementos HTML. De esta manera si se cambia ClienteNombre por ClienteNombreCompleto, tendramos que ejecutar todos los casos de prueba para ver donde se rompen. Con GXtest podemos impactar los cambios de la aplicacin y ver sin ejecutar los casos de pruebas como estos cambios los afectaron.Por otro lado si GX ya no genera el HTML de esa manera, entonces los casos de prueba se romperan, pero con GXtest no. Lo mismo pasa cuando decidimos generar la aplicacin en otra plataforma JAVA / .NET/ RUBY,Gxtest es capaz de ejecutar el mismo caso de prueba en distintas plataformas.

84

Casos de Prueba

DatapoolsDecisiones Inclusin

Login

ComandosOrden de ejecucin de las aristas

Veamos cmo expresamos un caso de prueba en GXtest.Un caso de prueba se representa mediante un modelo, en donde tenemos nodos que representan las pginas de la aplicacin y aristas que representan la transicin de una pgina a otra.Tambin tenemos los comandos que por un lado nos permiten expresar las interacciones del usuarios con la aplicacin, por ejemplo expresar un clic en un link o en un botn y por otro permiten validar que el estado de la aplicacin es el esperado por ejemplo corroborar si la aplicacin devolvi un determinado mensaje de error.

Otro concepto es el de DataPools (Click ->) que es una tabla que nos permite variar los datos de entrada al caso de prueba.

Otro concepto importante para expresar el caso de prueba es el de bifurcacin (Click ->), que permite indicar distintos flujos a seguir de acuerdo a una condicin.

Y por ltimo GXtest permite anidar casos de prueba para reutilizarlos. En el ejemplo, a este caso de prueba lo puedo llamar Login (Click ->) e incluirlo en otro caso de prueba.

El modelo busca mantener la simplicidad en la expresin de los casos de prueba, y busca ser flexible como para poder representar lo que se quiere automatizar.

Los comandos permite expresar tanto las intereacciones que el usuario puede realizar con la aplicacin como las validaciones, o estado esperado de la aplicacin luego de cada una de estas intereacciones. Los comandos pueden ser acciones, validaciones y eventos. Cada uno de estos puede recibir parmetros que le indican que deben ejecutar sobre la aplicacin.

Si hay ms de una arista saliente de uno nodo se indica el orden de ejecucin con una letra asociada a cada arista

Anidaciones: El objeto de tipo Test Case permite incluir en un caso de prueba otro caso de prueba. De esta manera se permite reutilizar modelos de casos de prueba.

85

Manager

GXtest tiene tres componentes principales: GXtest Designer, GXtest Recorder y GXtest Manager Como recin vimos, en GXtest Designer se crean los casos de prueba, se editan y prueban. Si, los casos de prueba tambin deben probarse. Una vez listos, se pueden centralizar en GXtest Manager, agrupndolos en suites. All se agendan tareas para correrlos peridicamente. Tambin se podrn obtener reportes de ejecuciones, configurar la notificacin sobre los resultados a las personas interesadas, etc. Por otro lado GXtest Manager utiliza para la ejecucin distintos Executors, los mismos son los encargados de ejecutar los casos de prueba en forma distribuida y con distintas configuraciones.

(click)86

Se abre

1.1

Se abre

1.2

Acciones

2

Terminar de grabar

3

3.1

Tenemos el script

Gateway(Proxy)

Browser

Http - Request

Http - Response

Http - Request

Http - Response

Ttulo del formularioModeller

Servidor Web

Http - Request

Http - Response

grabar

1

Servidor Web

Servidor Web

Servidor Web

Servidor Web

Se abre

1.1

Se abre

1.2

Acciones

2

Terminar de grabar

3

3.1

Tenemos el script

Gateway

Browser

Http - Request

Http - Response

Http - Request

Http - Response

Http - Request

Http - Response

Servidor Web

Servidor Web

Ttulo del formulario Tool

Servidor Web

Grabar

1