Caractersticas del testing

Introduccin

Luego de la breve introduccin al software y su desarrollo, queremos obtener respuestas a:

Qu es el testing?
Para qu sirve el 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 testing

Prueba exhaustiva

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

Una prueba exhaustiva es 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 testing
Las fallas estn ocultas

El testing puede 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
Si el testing fuera exhaustivo la vasija quedara vaca.

el

software

no

falla

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

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.

a:

Qu podemos decir si sacamos 10 bolitas y son todas negras?

Las respuestas podran ser por ejemplo:
1.
Detectamos todas las fallas
2.
En la vasija quedan ms entradas para las cuales el software falla
3.
No sabemos si en la vasija hay ms entradas para las cuales el software falla
A 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 el Axioma del Testing.
Caractersticas del testing
Axioma del Testing

La 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 testing
Paradoja del pesticida

Para 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
sutiles, contra los que ese mtodo no es efectivo.

bugs deja como residuo los ms

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 1

Conceptos generales
En este bloque veremos conceptos generales de testing funcional, automatizacin de pruebas funcionales y
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 Funcional

Testing funcional
A 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: el Testing Funcional.
El Testing funcional 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 Funcional

Error, defecto y falla

En general, los trminos falla, defecto y error se 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):

Un error es una accin humana que provoca un resultado no esperado.

Un defecto o 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.

Una falla es un resultado observado no esperado.

En ingls las palabras error y mistake se traducen como error, y la accin humana que
provoca un resultado incorrecto es definida por IEEE 610 como mistake.
Adems se define el trmino error para 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 Funcional

Ejemplos

Recordemos que en el mdulo de Introduccin a la gestin de incidentes definimos:

Un incidente se define como un comportamiento del software que difiere de lo esperado por algn
actor.
Tambin podemos decir que un incidente es 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.
Un error humano puede generar un defecto interno en un programa, que puede producir
una falla externa 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
el tipo de errores que se cometen dependen del contexto, muchos de los defectos presentes
en los programas se deben a carencias 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 cuento I 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 testing
Automatizando

Imaginen 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 y le
dejamos a las mquinas la ejecucin de las pruebas y la verificacin de los resultados?
Por supuesto, alguien deber esforzarse para que las mquinas trabajen por nosotros. En este curso nos
dedicaremos a comprender en qu consiste este esfuerzo.
La automatizacin de pruebas funcionales consiste 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 testing
Herramientas

De 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 performance
James 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 (Swebok 2004):
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 de automatizacin de pruebas funcionales nos enfocaremos en herramientas
para la ejecucin de pruebas.

James Bach define la automatizacin del testing

como 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 Funcionales

Contexto

En el contexto actual, las empresas que compiten en el mercado globalizado tienen 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 temprano y 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.
Ms frecuente, 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.

Automatizacin de Pruebas Funcionales

Es 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,
la ejecucin manual resulta ms beneficiosa.

El testing manual 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 se introducen 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 complementa el testing manual, no lo sustituye.
Automatizacin de Pruebas Funcionales

Beneficios
Las 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 incidentes si 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 que no se han introducido defectos en la nueva
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 Funcionales
Costos

Cules son los costos de automatizar?

La automatizacin es un 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 Funcionales

El rol del automatizador

Quin 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 y libreras
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 Performance
Comenzando

En 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,
movimientos, etc. de las estructuras frente a distintas situaciones.

resistencia,

En la construccin de software, las pruebas de performance procuran tambin obtener

informacin acerca del sistema construido.

Introduccin al Testing de Performance

Introduccin

En 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.
La performance de 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
Un requerimiento de performance es 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
Las pruebas de performance son 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.
Las pruebas de performance tienen 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 fundamental para 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 Performance

Arquitecturas

Segn el Diccionario de la Real Academia Espaola:

Arquitectura (Del
1.
2.

lat.

architectra).

f. Arte de proyectar y construir edificios.

f. Inform. Estructura lgica y fsica de los componentes de un computador
Real Academia Espaola

Todo sistema de software tiene una arquitectura definida, se haya pensado en sta o no. La
arquitectura es el esqueleto del 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 . 610 y SWEBOK v3 definen arquitectura como:

Arquitectura
Estructura organizacional de un sistema o componente.
IEEE St . 610
Arquitectura
Descripcin 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
sistema ante 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
denominados cuellos
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 decisiones personales de 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 Performance

Ejemplos

Arquitecturas comunes
Los 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 la distribucin de
los
componentes
de
software
que
interactan
en
un
sistema.
Arquitectura
monoltica
En 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-Servidor
Una 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
capas
En 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 Performance

Clasificacin

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