Caractersticas del testingIntroduccinLuego de la breve introduccin al software y su desarrollo, queremos obtener respuestas a:

Qu esel testing? Para qu sirveel testing? Quin tiene que probar el software?A medida que avancemos en la leccin vamos a dar y analizar varias definiciones de testing. Como una primera aproximacin podemos decir que testear es ejecutar pruebas, obtener resultados y compararlos con el comportamiento esperado. Testear es probar.Para testear tenemos que

Caractersticas del testingPrueba exhaustivaSupongamos que queremos probar un software que recibe 2 nmeros enteros como entrada y los suma.

Cuntas combinaciones de entradas de enteros deberas probar?

Supongamos que es posible representar 2 a la 32 enteros. Si combinamos las posibles entradas, y hacemos algunos clculos, tardaramos 0.5 billones de aos en probar exhaustivamente un sistema tan sencillo como una suma de 2 enteros.

Unaprueba exhaustivaes aquella en la que se prueban todas las combinaciones de entradas posibles. En este caso sera imposible hacer una prueba exhaustiva.

Una de las primeras ideas que nos tiene que quedar en la cabeza es que en general, es impracticable probar todo.Tenemos que seleccionar un subconjunto de pruebas de un conjunto inmenso.Aunque tuviramos que probar una funcionalidad con una cantidad limitada de entradas, y pudiramos ejecutar en un tiempo razonable todas las combinaciones, no es posible ejecutar las pruebas considerando las combinaciones de todo el hardware de base, con todos los sistemas operativos y en todos los navegadores.

En algunos casos podemos ejecutar pruebas exhaustivas en un contexto dado, pero nunca podremos decir Prob la funcionalidad X exhaustivamente.

Caractersticas del testingLas fallas estn ocultas

El testingpuede asimilarse a la accin de sacar de una vasija, bolitas de diferentes colores:

bolita negra = entrada para la cual el software falla bolita blanca = entrada para la cual el software no fallaSiel testingfuera exhaustivo la vasija quedara vaca.

Si sacramos todas las bolitas de la vasija encontraramos todas las fallas, Pero qu sucede si tenemos un lmite de tiempo? Qu sucede si no conocemos a priori todos los entornos en los cuales se ejecutar el software?

El objetivo del testing es sacar la mayor cantidad de bolitas negras en un plazo acotado.Una forma sera cambiar la forma de la vasija de modo que todas las bolitas negras, si existen, se puedan seleccionar rpidamente en el muestreo.

Cambiar la forma de la vasija se refiere a:

Elegir inteligentemente las entradas con las cuales se va a probar, de forma de encontrar fallas en el software (responsabilidad del tester) Construir software testeable, de forma que sea ms fcil y ms probable detectar las fallas.Qu podemos decir si sacamos 10 bolitas y son todas negras?Las respuestas podran ser por ejemplo:1. Detectamos todas las fallas2. En la vasija quedan ms entradas para las cuales el software falla3. No sabemos si en la vasija hay ms entradas para las cuales el software fallaA menos que hagamos una prueba exhaustiva, que usualmente es imposible, no podemos demostrar la ausencia de fallas, slo podemos mostrar su presencia.

Este razonamiento se expresa en elAxioma del Testing.Caractersticas del testingAxioma del TestingLa prueba de un programa slo puede mostrar la presencia de defectos, no su ausencia."Edsger Wybe Dijkstra

En los siguientes links podrn encontrar informacin sobre Dijkstra y su trabajo.http://www.cs.utexas.edu/users/EWD/http://video.google.com/videoplay?docid=-6873628658308030363#

Cuando testeamos slo conocemos los resultados que obtenemos luego de ejecutar cada prueba. Tal vez ejecutamos 10 pruebas y obtenemos 10 fallas, o ninguna, o 4, pero en ningn caso sabemos el estado interno del software, la cantidad de defectos que contiene.

Para obtener resultados valiosos de las pruebas, tenemos que seleccionar cuidadosamente las pruebas, disendolas para encontrar la mayor cantidad de fallas severas, con los recursos y en el plazo disponible.Caractersticas del testingParadoja del pesticidaPara explicar la paradoja del pesticida nos remontamos a los primeros computadores. En la dcada de los 40, los computadores ocupaban cientos de metros cuadrados y pesaban toneladas.

En el ao 1947, uno de estos gigantescos computadores empez a fallar. No se poda correr ningn programa. Buscaron por horas y horas, hasta que dentro de un montn de cables encontraron a una polilla muerta, cuyo cadver estaba haciendo cortocircuito con la memoria (vlvulas), del aparato. La sacaron con mucho cuidado, y todo mgicamente se arregl.Esta es la famosa historia del primer bug o bicho. Desde ese entonces, el trmino se ha usado para identificar cualquier anomala en el software.El trmino bug se usa para referirse a un defecto o una falla. Cuando alguien reporta un bug puede estar haciendo referencia a un defecto, una falla o una limitacin en el programa que lo hace menos valioso para el usuario.

Compartimos la paradoja del pesticida:

Cualquier mtodo que se use para prevenir o encontrar bugs deja como residuo los ms sutiles, contra los que ese mtodo no es efectivo.

Boris Beizer

El pesticida mata un gran porcentaje de los insectos, pero deja un residuo, los ms fuertes sobreviven. Como consecuencia, al ao siguiente es preciso un pesticida ms fuerte.

Cuando hacemos testing pensamos pruebas, las ejecutamos, detectamos bugs, se corrigen y volvemos a ejecutar pruebas para verificar su correccin.Luego el conjunto de casos de prueba pensados, ya no detectan bugs, pues los que detectaron en un principio ya fueron corregidos. Pero an puede haber bugs en el software que no hayamos detectado. Tenemos que pensar y ejecutar nuevas pruebas para detectar esos bugs que an persisten.Podemos considerar las pruebas que pensamos y ejecutamos como un pesticida que va matando bugs. Tenemos que actualizarlas, y agregar nuevas pruebas al conjunto inicial para ir matando el residuo que queda.Si se hace un buen testing, los errores van a ir cambiando, y tenemos que cambiar los casos de prueba para mantener la efectividad.

Tema 1Conceptos generales

En este bloque veremos conceptos generales de testing funcional,automatizacin de pruebas funcionalesy testing de performance. Te invitamos a que recorras las lecciones y te inscribas luego en la carrera. Introduccin al Testing FuncionalLeccin Automatizacin del testingLeccin Automatizacin de Pruebas FuncionalesLeccin Introduccin al Testing de Performance.

Introduccin al Testing FuncionalPrincipio del formularioTesting funcionalA partir de la estrategia general de pruebas que vimos en el curso "Introduccin al testing", de las habilidades del equipo de pruebas, y del entrenamiento necesario para que la informacin que obtengamos de las pruebas sea de valor, empezamos a profundizar en uno de los tipos de testing: elTesting Funcional.El Testingfuncional es necesario en todos los proyectos de desarrollo y mantenimiento de software. Involucra muchos actores y roles, a los que hicimos alusin en los mdulos anteriores. En este mdulo vamos a ver y aplicar estrategias y tcnicas de testing funcional, profundizar en el significado del cubrimiento de las pruebas e introducir un proceso de testing funcional. Simultneamente, se propondrn distintas actividades tendientes a mejorar algunas de las capacidades cognitivas involucradas.Antes de entrar en las estrategias, tcnicas y habilidades, vamos a definir en esta seccin los siguientes conceptos: fallas, defectos, errores, caso de prueba y orculo.

Introduccin al Testing FuncionalError, defecto y fallaEn general, los trminos falla, defecto y errorse utilizan indistintamente. Sin embargo, cada uno de estos trminos se refiere a un concepto diferente. Es importante que el tester tenga clara la diferencia para poder ser preciso cuando transmite los comportamientos observados.Definiciones segn el estndar IEEE 610.12-1990 (Glosario de trminos de ingeniera de software): Unerrores una accin humana que provoca un resultado no esperado. Undefectoo falta es una imperfeccin, o deficiencia de un componente o sistema que puede provocar que el sistema o componente no se comporte como es esperado. Unafallaes un resultado observado no esperado.En ingls las palabraserrorymistakese traducen como error, y la accin humana que provoca un resultado incorrecto es definida por IEEE 610 comomistake.Adems se define el trminoerrorpara nombrar indistintamente un error (mistake), defecto o falla.Por lo tanto, en espaol, cuando hablamos de error, podemos referirnos a la accin humana que provoca un resultado incorrecto o a la diferencia entre el comportamiento observado y el esperado y/o especificado.Extracto del estndar IEEE 610 mencionado:

Introduccin al Testing FuncionalPrincipio del formularioEjemplosRecordemos que en el mdulo de Introduccin a la gestin de incidentes definimos:Unincidentese define comoun comportamiento del software que difiere de lo esperado por algn actor.Tambin podemos decir que unincidentees un defecto, problema o anomala en el software, inyectado en los requerimientos, el diseo, el cdigo y otros productos por omisin o por un error que se muestra como una falla del software.Es importante destacar que el trmino incidente es ms amplio que el de error. Un incidente puede ser una mejora identificada, mientras que un error, en el sentido ms amplio, slo abarca errores humanos, defectos y fallas.Unerrorhumano puede generar undefectointerno en un programa, que puede producir unafallaexterna del programa, la cual puede provocar daos graves.Quienes participan en el desarrollo del software, introducen los defectos. Pero los errores que se cometen pueden estar relacionados al cdigo fuente, las especificaciones, la eleccin de una tecnologa o el proceso de desarrollo, entre otros.Tengan en cuenta que, si bien eltipo de errores que se cometen dependen del contexto, muchos de los defectos presentes en los programas se deben acarencias o imprecisiones en las especificaciones.

Las fallas se producen debido a defectos presentes en el cdigo del programa. Por ejemplo, un defecto en el cdigo del programa de gestin de aeropuertos puede ser la causa de que un avin se estrelle, como se ilustra en el ejemplo.Tambin podra suceder que ese mismo defecto se mantuviera latente (recuerden el cuentoI am a bug) en el programa sin que se revelara una falla durante un cierto perodo de tiempo, que podra ser muy largo.Automatizacin del testingPrincipio del formularioAutomatizandoImaginen que todo lo visto hasta ahora lo hace una mquina, un robot, sera fabuloso No?El tester ya no debera entender sobre los requerimientos, ni disear, ni ejecutar, ni tampoco verificar los casos de prueba. Slo presionar un botn y esperar resultados.Aterricemos de vuelta.Vamos a pedir un poco menos, y ser menos ambiciosos.Qu tal si nosotros nos encargamos de entender los requerimientos y de disear las pruebas yle dejamos a las mquinas la ejecucin de las pruebas y la verificacin de los resultados?Por supuesto, alguien deber esforzarse para que las mquinastrabajen por nosotros. En este curso nos dedicaremos a comprender en qu consiste este esfuerzo.Laautomatizacin de pruebas funcionalesconsiste en el uso del software para controlar la ejecucin de pruebas y comparar el resultado obtenido con el esperado.Es importante notar que en nuestra definicin de automatizacin deja fuera muchas tareas de testing.Por esta razn, Cem Kaner se refiere a la automatizacin en los trminos siguientes:La automatizacin del testing es testing asistido por computadoras (computer-assisted testing).O sea, en qu nos puede ayudar el hardware y el software en las tareas de testing. De qu tareas puede liberarnos? La mquina puede ejecutar las pruebas, registrar y evaluar los resultados.Sin embargo, la mquina no puede analizar los requerimientos, disear los casos de prueba, pensar los juegos de datos, ejecutar por primera vez un prueba y evaluar su resultado,reportar incidentes, revisar las pruebas, elaborar informes, seleccionar las pruebas a ejecutar y mantenerlas. Slo el ser humano puede hacerlo! Y ms an, cuando se detecta una falla, es el ser humano quien tiene que investigar sus posibles causas.Automatizacin del testingPrincipio del formularioHerramientasDe todas maneras, distintas herramientas ofrecen una ayuda muy valiosa en diferentes actividades.Ustedes ya conocen algunas: Mantis, que ayuda en la gestin de los incidentes JMeter y Perfmon que permiten generar carga y monitorizar el sistema bajo prueba en las pruebas de performanceJames Bach define la automatizacin en trminos de su uso:La automatizacin del testing es todo uso de herramientas para asistir a las pruebas.A continuacin se lista una clasificacin de herramientas que asisten al testing (Swebok2004): Generadores de pruebas. Estas herramientas asisten en el diseo de casos de prueba. Framework de ejecucin de pruebas.Estas herramientas permiten la ejecucin de pruebas en un ambiente controlado y observar el comportamiento del elemento bajo prueba. Evaluacin de pruebas.Estas herramientas asisten en la evaluacin del resultado de las pruebas, ayudando a determinar si el resultado observado es el esperado. Gestin de pruebas.Estas herramientas proveen apoyo en la gestin del proceso de pruebas. Anlisis de performance.Estas herramientas son usadas para medir y analizar el desempeo de los sistemas.En este curso deautomatizacin de pruebas funcionalesnos enfocaremos en herramientas para la ejecucin de pruebas.James Bach definela automatizacin del testingcomo la ejecucin automtica de casos de prueba.como el entendimiento de requerimientos, diseo de casos de prueba, ejecucin y verificacin de resultados en forma automtica.como el diseo de casos de prueba orientado a las herramientas.como cualquier uso de herramientas para asistir a las pruebas.Automatizacin de Pruebas FuncionalesPrincipio del formularioContextoEn el contexto actual, las empresasque compiten en el mercado globalizadotienen exigencias de calidad crecientes. Los productos que desarrollan estn en continuo mantenimiento, mejora y muchos de estos productos funcionan sobre mltiples plataformas: sistemas operativos, bases de datos, navegadores.Las pruebas automatizadas surgen como alternativa para reducir costos y tiempos en las pruebas de regresin, disponer de un conjunto de pruebas de humo automatizadas, ejecutar pruebas sobre mltiples plataformas, etc.La automatizacin de pruebas contribuye a mejorar la calidad del software, ya que posibilita un testing ms tempranoy ms frecuente, adems de una mayor cobertura de pruebas.Ms temprano,porque el equipo de desarrollo puede ejecutar estas pruebas y detectar, luego de una modificacin en el cdigo fuente, pruebas que fallan por comportamientos no esperados. Esto permite corregir inmediatamente el cambio, con el beneficio de que ste an est fresco en la mente del desarrollador.Msfrecuente,porque las pruebas se ejecutan ms rpido que en forma manual y por lo tanto se pueden correr en la noche, o una vez por semana, dependiendo del contexto.La automatizacin permite mayor cobertura si cubrimos las funcionalidades bsicas o crticas del producto, y enfocamos las pruebas manuales en el resto.Reduciendo el tiempo de testing estaremos reduciendo el tiempo de salida al mercado (time to market), lo cual genera una ventaja competitiva, desde el punto de vista del negocio, en el sentido ms amplio.Final del formulario

Automatizacin de Pruebas FuncionalesPrincipio del formularioEs beneficioso automatizar todas las pruebas?A medida que se va construyendo o manteniendo un producto de software, hay siempre un conjunto de funcionalidades que se consolidan y estabilizan, mientras otras se continan ajustando o sufren mayores vaivenes. Las funcionalidades tienen un conjunto de casos de prueba asociados. El desafo es decidir cules automatizar para que las pruebas sean ms eficientes y eficaces.No siempre hay que automatizar, no se trata de automatizar el 100% de los casos de prueba.Para las pruebas funcionales asociadas a nuevos requerimientos, o que an no estn maduros, laejecucin manualresulta ms beneficiosa.El testingmanual es un proceso que se adapta al cambio. Cuando los requerimientos o la aplicacin se modifican (por ejemplo si se agrega una nueva ventana de informacin o vara un mensaje de error),el tester percibe el cambio, evala si se trata de un incidente y contina con las pruebas haciendo los ajustes correspondientes.

Las pruebas automatizadas son menos flexibles al cambio.Las pruebas manuales pueden detectar varios problemas a primera vista, por ejemplo probando cierta funcionalidad de clculo detectar problemas con la interfaz grfica o de almacenamiento.Por otra parte,en cada nueva ejecucin seintroducen variantes tiles para detectar incidentes. Es probable que el tester no utilice exactamente los mismos datos en todas las ejecuciones de los mismos casos de prueba.Las pruebas automatizadas, en cambio, se limitan a la verificacin definida explcitamente en el guin. Esto tiene sus desventajas pues son menos flexibles, pero tienen la ventaja de ser repetibles y ms rigurosas. Si se detecta un incidente con una prueba automatizada, se conocen exactamente los pasos y datos que lo pusieron de manifiesto.Para automatizar resulta importante asegurarse que las reas bajo prueba estn suficientemente maduras de manera de reducir el costo de mantener las pruebas. De lo contrario, puede ser ms rentable la prueba manual.La automatizacin complementael testingmanual, no lo sustituye.Automatizacin de Pruebas FuncionalesPrincipio del formularioBeneficiosLas grandes candidatas para automatizar son las pruebas de regresin ya que estn asociadas a las funcionalidades ms importantes y estables. Sin embargo, las pruebas de regresin tienen poca probabilidad de detectar incidentessi no se han encontrado en ejecuciones anteriores, ya que se ejecutan exactamente de la misma forma y con los mismos datos.Para qu ejecutar las pruebas entonces?El valor de este tipo de prueba recae en verificar queno se han introducido defectosen lanueva versin. No slo las pruebas que detectan incidentes tienen valor. El objetivo es brindar tranquilidad para salir en produccin o liberar el producto, asegurando las prestaciones ms importantes.Los ajustes y mejoras en la aplicacin son ms confiables, ya que rpidamente, obtenemos informacin sobre eventuales impactos negativos de nuestros cambios. De lo contrario, estaremos haciendo los cambios en la aplicacin a oscuras.Automatizacin de Pruebas FuncionalesPrincipio del formularioCostosCules son los costos de automatizar?La automatizacin esun proyecto de desarrollo de software (inmerso en un proyecto de desarrollo mayor)que tiene varios costos asociados. Primero hay que adquirir conocimiento en automatizacin (en eso estamos) y conocer las herramientas de automatizacin disponibles, que sean compatibles con el sistema bajo prueba.Se puede descomponer el costo de un proyecto de automatizacin en el costo de cada una de las actividades que demandar.Es preciso destinar esfuerzo a la seleccin y aprendizaje de la herramienta, ya sea estudiando documentacin en Internet, asistiendo a cursos presenciales, cursos en lnea, etc.Un proyecto tambin involucra la planificacin, el diseo de las pruebas, el desarrollo y la verificacin de los scripts. Un tiempo no menor se destina a mantener los scripts y a la ejecucin de las pruebas.Es importante documentar y gestionar todas las actividades del proyecto para dar visibilidad del avance del trabajo y los beneficios que se obtienen, aprender de las dificultades y poder estimar mejor en el futuro.Automatizacin de Pruebas FuncionalesPrincipio del formularioEl rol del automatizadorQuin puede desempear el rol de automatizador?El equipo de testing tiene el conocimiento de las pruebas, sabe qu y cmo probar. El equipo de desarrollo, por su parte, sabe cmo llevar adelante el diseo y la programacin de piezas de software, adems de conocer la tecnologa involucrada. Ambos equipos tienes sus fortalezas a la hora de automatizar pruebas.Lo importante es notar que el perfil del automatizador rene las caractersticas de un tester y las de un desarrollador. Tambin puede pensarse en equipos mixtos donde trabajen testers y desarrolladores a la par.Las habilidades del automatizador incluyen: Manejo fludo de la herramienta de automatizacin, de los componentes de ejecucin,de grabacin, de gestin,etc. Conocimiento del lenguaje de programacin de pruebas ylibreras disponibles.Conocer las posibilidades que ofrece la herramienta de automatizacin. Conocer la interfaz de la aplicacin sobre la cual se ejecutarn las pruebas. Incorporar y/o definir los estndares de programacin para las pruebas a crear.

Estas habilidades requieren un esfuerzo importante al inicio,la productividad se incrementa a medida que se adquiere conocimiento y experiencia en el rea.Por lo tanto, es esencial la especializacin en la tarea de automatizacin!Introduccin al Testing de PerformancePrincipio del formularioComenzandoEn otras disciplinas como la ingeniera civil o la ingeniera aeronutica las "pruebas de performance" son obligatorias en el proceso de construccin. Las imgenes a continuacin muestran el caso de la ingeniera aeronutica donde se realizan pruebas para verificar que las alas de los aviones tengan la flexibilidad adecuada para soportar las distintas situaciones a las que los factores climticos puedan exponerlas.En el caso de la ingeniera civil, en particular la construccin de puentes, stos tambin son probados con carga significativa.Estas pruebas permiten a los ingenieros evaluar el comportamiento, resistencia, movimientos, etc. de las estructuras frente a distintas situaciones.En la construccin de software, las pruebas de performance procuran tambinobtener informacinacerca del sistema construido.Introduccin al Testing de PerformancePrincipio del formularioIntroduccinEn el curso "Introduccin al Testing" se vieron distintos tipos de pruebas y clasificaciones, y se estudiaron los sistemas de software como un conjunto de componentes y subsistemas interactuando entre s.En este curso se abordarn las pruebas de performance de un sistema viendo los distintos elementos que lo componen y sus interacciones. Profundizaremos en qu tipo de informacin acerca de la calidad del producto podemos obtener al realizar este tipo de pruebas y cmo analizarla.En el material de Introduccin al Testing se adelant que las pruebas de performance se pueden clasificar en: carga, volumen, estrs, entre otras. Antes de profundizar en cada tipo de prueba de perfomance, se analizan las definiciones de la norma 610 de la IEEE (IEEE St. 610) referentes a la performance.

Laperformancede un sistema es el grado en que el sistema o componente ejecuta sus funcionalidades dentro de restricciones dadas, tales como la velocidad, la precisin, o el uso de memoria.IEEE St. 610

Unrequerimiento de performancees aqul que impone condiciones a un requisito funcional, como por ejemplo la velocidad, precisin, o el uso de memoria, con la cual se debe ejecutar una funcin determinada.IEEE St. 610

Laspruebas de performanceson aquellas realizadas para evaluar el cumplimiento de un sistema o componente, con los requerimientos de performance especificados.IEEE St. 610

En la misma lnea SWEBOK define las pruebas de performance.

Laspruebas de performancetienen como objetivo verificar que el software cumple con los requerimientos de performance especificados, por ejemplo, la capacidad y el tiempo de respuesta.SWEBOK

La arquitectura de un sistema es un concepto fundamentalpara poder estudiar su performance.Qu es la arquitectura de un sistema y cmo influye en la capacidad, tiempo de respuesta y otros atributos de calidad de un producto de software?Introduccin al Testing de PerformancePrincipio del formularioArquitecturasSegn el Diccionario de la Real Academia Espaola:

Arquitectura(Del lat. architectra).

1. f. Arte de proyectar y construir edificios.2. f. Inform. Estructura lgica y fsica de los componentes de un computadorReal Academia Espaola

Todo sistema de software tiene una arquitectura definida, se haya pensado en sta o no. La arquitectura es elesqueletodel sistema e influye en los atributos de calidad definidos. Algunos atributos de calidad son propiedades externamente visibles, como la seguridad, usabilidad, latencia, o modificabilidad, entre otros.

IEEE St . 610ySWEBOK v3 definenarquitecturacomo:

ArquitecturaEstructura organizacional de un sistema o componente.IEEE St . 610

ArquitecturaDescripcin de los subsistemas y componentes de un software as como el relacionamiento que mantienen entre ellos.SWEBOK v3

Estructura y organizacin son las claves de la arquitectura de un sistema. Incluyen, entre otros, los siguientes elementos:

la interaccin entre componentes y su distribucin fsica, las estructuras globales de control, los protocolos de comunicacin, la sincronizacin, el acceso a los datos.En este curso no se profundizar en las distintos estilos arquitectnicos de los sistemas, sus atributos de calidad y restricciones. Se estudiarn los datos que interesa conocer al momento de realizar una prueba de performance, as como ejemplos de algunas arquitecturas y cmo influyen en la performance del sistema.Los distintos elementos de la arquitectura se pueden pensar como motores de procesamiento. Cada uno de estos motores podr procesar distintas tareas en un determinado tiempo, utilizando ciertos recursos. Para estudiar la performance del sistemaante la solicitud de un usuario, ser vital conocer el flujo de los datos asociados a esa solicitud a travs de estos motores de procesamiento.En consecuencia, la performance global del sistema ser el resultado no lineal de la performance de los distintos componentes de la arquitectura. Por tal motivo:

Es importante conocer la arquitectura del sistema. Dependiendo de lo que se quiera mejorar, habr que centrarse en unos u otros componentes. Mejorando la performance de cada componente se mejorar la performance global del sistema.Para hacer testing de performance hay que tener en cuenta los elementos estructurales del sistema, ya que en stos y sus interacciones radican los posibles problemas de desempeo, los denominadoscuellos de botella.Cuando se construye un sistema, es importante pensar en la performance del sistema durante todo el desarrollo y tomar decisiones para cumplir con las restricciones y los atributos de calidad requeridos o deseados. En caso contrario, el desempeo o performance del sistema, quedar librado a decisiones de terceros. Depender por ejemplo, de decisiones que habrn tomado los constructores de productos o tecnologas de terceros que se elijan para integrar al sistema, o a decisionespersonalesde diseo o programacin, de los integrantes del equipo de desarrollo, que podran incluso ser contradictorias.As como en los distintos cursos de la carrera se transmite que es importante que integrantes del equipo de testing participen en actividades de anlisis de requerimientos, tambin se recomienda que participen en la toma de decisiones de arquitectura y diseo de los sistemas.

Hacer el sistema "correcto" requiere tambin tener en mente la performance que tendr el sistema.

Por qu est entre comillas el adjetivo "correcto"?

Se puede hacer testing de performance de cada algoritmo, componente o consulta a la base de datos por separado, as como tambin pruebas de performance sobre el sistema integrado.Las pruebas de performance unitarias y de integracin, permiten detectar y resolver tempranamente, problemas muy importantes como por ejemplo la concurrencia, o sea, varios usuarios pretendiendo acceder simultneamente a los mismos recursos del sistema. Por lo tanto, las pruebas de performance a nivel del sistema integrado, que se realizan en etapas posteriores, pueden as focalizarse en aspectos como el ajuste y configuracin de la infraestructura definitiva, ahorrando tiempo y recursos, permitiendo liberar el sistema a produccin ms rpido y con menos riesgos.

Introduccin al Testing de PerformancePrincipio del formularioEjemplosArquitecturas comunesLos sistemas han evolucionado. Si se revisa lo sucedido en las ltimas dcadas, se encuentran distintas modas y tecnologas en lo que respecta al uso de sistemas informticos.

Una de las diferencias ms marcadas entre las distintas arquitecturas, es ladistribucinde los componentes de software que interactan en un sistema.

Arquitectura monolticaEn una arquitectura monoltica el software se estructura en grupos funcionales muy acoplados. No hay distribucin, ni a nivel fsico (hardware) ni a nivel lgico, por lo que todo se ejecuta en una mquina.

Por ejemplo, si se presenta la situacin de una funcionalidad en una aplicacin de escritorio que tarda 20 segundos en entregar resultados, podemos analizar el problema estudiando si la Unidad de Procesamiento Central (CPU) se encuentra trabajando al mximo o si la memoria disponible es mnima.

Arquitecturas Cliente-ServidorUna arquitectura Cliente - Servidor consiste bsicamente en que un programa (cliente informtico) realiza peticiones a otro programa (el servidor) que le da respuesta.Uno de los clientes ms utilizados, es el navegador web. Muchos servidores son capaces de ofrecer sus servicios a travs de un navegador web en lugar de requerir la instalacin de un programa especfico.El sistema cliente y el sistema servidor podran estar en el mismo equipo aunque generalmente estn conectados a travs de una red de computadores. Si son varios los clientes que se conectan al mismo sistema servidor, toma la caracterstica de sistema multiusuario.En una arquitectura Cliente-Servidor, con componentes de software distribuidos, es necesaria la existencia de una red para que los componentes se comuniquen entre s. Esta comunicacin es otro elemento a tener en cuenta cuando se perciben problemas de performance. Por ejemplo, se puede analizar la velocidad con la que viajan las peticiones y las respuestas por la red.Hay que tener en cuenta que en sistemas con arquitectura cliente-servidor, no es suficiente no detectar problemas de performance con un slo usuario accediendo al sistema. Tal vez se detecten problemas de performance cuando varios usuarios estn accediendo, al mismo tiempo, al sistema. Por ejemplo, se podran sobrecargar las lneas de comunicacin o los recursos del servidor. O quizs no se puedan entregar tantas respuestas como para cumplir con todas las demandas de los usuarios.

Arquitecturas en capasEn un sistema con una arquitectura en capas se distinguen al menos las siguientes:

la capa de presentacin o interfaz de usuario, a travs de la cual los usuarios acceden al sistema, la capa lgica de negocio, en la cual se ejecutan los clculos y se toman decisiones de ejecucin segn las reglas del negocio, la capa de almacenamiento de datos, por ejemplo los sistemas de bases de datos y sus correspondientes manejadores.Cada capa tiene responsabilidades definidas y encapsula un conjunto de funcionalidades relacionadas. La forma de comunicacin entre las capas es definida a priori.La definicin de capas puede variar dependiendo de las necesidades y elecciones de diseo de la aplicacin, pero todas mantienen la divisin general de cliente lgica almacenamiento. Adems de las arquitecturas de 3 capas, pueden definirse capas intermedias con cometidos particulares, y se obtiene una arquitectura en n capas. Hoy en da las aplicaciones utilizadas por millones de usuarios (como son algunas redes sociales) se sitan en una arquitectura de este estilo.

Los clientes acceden desde distintos dispositivos, por ejemplo mviles, terminales o PCs a una infraestructura que brinda el servicio que el cliente est demandando. El uso o no de determinados artefactos de la infraestructura implicar la implementacin de una arquitectura en 1, 2, 3, N capas. Las arquitecturas cliente-servidor tambin se conocen como arquitecturas en 2 capas.Se puede decir que en general, la arquitectura va a determinar, entre otras cosas, dnde hay ms procesamiento y dnde estn los motores de la aplicacin.Los clientes informticos (hardware y software) pueden ser clientes finos o gruesos. La principal tarea de los clientes finos es presentar la informacin que entrega el servidor y permitir al usuario generar nuevas solicitudes. En el cliente grueso existe procesamiento de reglas de negocio o clculos que hacen que el procesamiento sea mayor.Un ejemplo de cliente fino es un componente de software que ejecuta en un navegador Web. En el caso de los clientes gruesos los componentes ejecutan comnmente directamente sobre el sistema operativo o mquinas virtuales (mquina virtual java).Por ejemplo el chat de la plataforma Moodle es un cliente fino y el Messenger y el Skype son clientes gruesos.En las arquitecturas Cliente-Servidor, el tipo de cliente con el que se accede al servidor determinar dnde estn los motores de procesamiento.Las arquitecturas utilizadas han variado con el paso de los aos. ltimamente, es comn el desarrollo de aplicaciones en ms de 2 capas, con un navegador como cliente fino que presenta al usuario lo que las otras capas procesaron. En este tipo de aplicaciones hay que definir y probar la performance de las capas que se ejecutan del lado de los servidores.En la siguiente imagen se visualiza la infraestructura que hay detrs de este tipo de aplicaciones, como ser Google, Facebook y Skype.

Si tenemos un cliente grueso se tendrn motores de procesamiento a ambos lados y la performance est claramente dividida.Cuando pensamos en la performance del sistema, nos imaginamos cmo optimizar determinado algoritmo, as como el procesamiento del lado del cliente y del lado del servidor. Integrantes del equipo de desarrollo pueden mejorar estos aspectos de performance en las distintas capas y componentes probando unidades as como su integracin, y midiendo los tiempos.

Es necesario identificar el tipo de arquitectura para evaluar los distintos tipos de simulacin y herramientas requeridas para las pruebas de performance.La siguiente imagen pretende mostrar que los tiempos de respuesta que perciben los clientes son la sumatoria de los insumidos en los distintos trayectos por los cuales fluye la informacin de una solicitud respuesta. Ante un problema de performance es imprescindible conocer los distintos elementos de la arquitectura para eventualmente, agregar monitorizacin, que indique dnde surgen los cuellos de botella, e irlos solucionando.Introduccin al Testing de PerformancePrincipio del formularioClasificacinLas pruebas de performance pueden ofrecer distintos beneficios, que dependen del tipo de prueba a realizar.Qu tipos de pruebas de performance existen?Recordemos que, dependiendo de su objetivo, las pruebas de performance se pueden clasificar en:

Carga,en las cuales se simula la carga prevista en el uso esperado del sistema. Stress,en las cuales se lleva al sistema a lmites de carga que exceden los previstos en el uso del sistema. Escalabilidad, que es un caso particular de una prueba de carga, en la cual se estudia la performance cuando se disminuyen o aumentan los recursos del sistema. Volumen, que es un caso particular de una prueba de carga, en la cual se estudia la performance cuando se incrementa el volumen de datos del sistema.Si bien en la industria se manejan estas categoras de pruebas de performance, lo ms importante a tener en cuenta a la hora de pensar en una prueba de performance no es en qu categora cae sino qu preguntas precisamos responder, qu informacin queremos obtener, qu riesgos queremos mitigar.Final del formulario