ESTADO DEL ARTE DE MÉTODOS, TIPOS DE TESTING Y

HERRAMIENTAS PARA APLICAR PRUEBAS DE

RENDIMIENTO

ESTADO DEL ARTE DE MÉTODOS, TIPOS DE TESTING Y HERRAMIENTAS PARA APLICAR PRUEBAS DE

RENDIMIENTO

JUAN OLIVER NAVARRO

FUNDACIÓN UNIVERSITARIA TECNOLÓGICO COMFENALCO

FACULTAD DE INGENIERÍA PROGRAMA INGENIERÍA DE SISTEMAS

DIPLOMADO EN GERENCIA DE PROYECTOS INFORMÁTICOS

CARTAGENA DE INDIAS D. T. Y C. 2010

ESTADO DEL ARTE DE MÉTODOS, TIPOS DE TESTING Y HERRAMIENTAS PARA APLICAR PRUEBAS DE

RENDIMIENTO

JUAN OLIVER NAVARRO

Trabajo presentado como requisito para optar por el Título de Ingeniero de Sistemas

FUNDACIÓN UNIVERSITARIA TECNOLÓGICO COMFENALCO

FACULTAD DE INGENIERÍA PROGRAMA INGENIERÍA DE SISTEMAS

DIPLOMADO EN GERENCIA DE PROYECTOS INFORMÁTICOS

CARTAGENA DE INDIAS D. T. Y C. 2010

Tabla de contenido ÍNDICE DE ILUSTRACIONES

ÍNDICE DE TABLAS

INTRODUCCIÓN ..............................................................................................................................9

1. OBJETIVOS ............................................................................................................................ 10

1.1. OBJETIVO GENERAL ................................................................................................... 10

1.2. OBJETIVOS ESPECÍFICOS ........................................................................................ 10

2. JUSTIFICACIÓN .................................................................................................................... 11

3. MARCO TEÓRICO ................................................................................................................ 13

3.1. 1° Etapa. Desde la revolución industrial hasta 1930 .................................................... 15

3.2. 2° Etapa. 1930-1949 .......................................................................................................... 16

3.3. 3° Etapa. 1950-1979 .......................................................................................................... 16

3.4. 4° Etapa. Década del 80 ................................................................................................... 17

3.5. 5° Etapa. 1990 hasta la fecha .......................................................................................... 17

3.6. Pruebas de software 1.0 ................................................................................................... 18

3.7. Pruebas de software 2.0 ................................................................................................... 18

PARTE I ........................................................................................................................................... 20

TRABAJOS EXISTENTES ........................................................................................................... 20

4. EN BUSCA DE MEJORES PRÁCTICAS PARA PRUEBAS DE RENDIMIENTO ...... 21

4.1. MODELO DE MEJORA DE PROCESOS DE SOFTWARE (TPI) .......................... 21

4.2. MODELO DE INTEGRACIÓN Y MADUREZ DE LAS PRUEBAS .......................... 24

4.3. CMMI................................................................................................................................. 26

4.4. ISO ..................................................................................................................................... 27

PARTE II .......................................................................................................................................... 29

ESTADO DEL ARTE ............................................................................................................................. 29

5. ESTADO DEL ARTE ............................................................................................................. 30

5.1. LAS PRUEBAS DE RENDIMIENTO SEGÚN MICROSOFT ................................... 30

5.2. Rendimiento, pruebas de carga y estrés ........................................................................... 31

5.3. Las pruebas de rendimiento según Ian Molyneaux .......................................................... 31

5.3.1. Disponibilidad ............................................................................................................... 32

5.3.2. Tiempo de respuesta .................................................................................................. 32

5.3.3. Rendimiento ................................................................................................................. 32

5.3.4. Utilización ..................................................................................................................... 32

5.4. MÉTODOS PARA REALIZAR PRUEBAS DE RENDIMIENTO .............................. 33

5.4.1. Metodología Orientada a Objetos para el Ciclo de Vida Completo .................... 33

5.5. Metodología de Control de Rendimiento ........................................................................ 36

5.5.1. Identificar el entorno de pruebas .............................................................................. 36

5.5.2. Identificar los criterios de aceptación de rendimiento ........................................... 36

5.5.3. Planear y diseñar las pruebas ................................................................................... 37

5.5.4. Configurar el entorno de pruebas ............................................................................. 37

5.5.5. Implementar el diseño de pruebas ........................................................................... 37

5.5.6. Ejecutar las pruebas ................................................................................................... 37

5.5.7. Analizar, reportar y re-probar .................................................................................... 37

5.6. Tipos de pruebas de rendimiento .................................................................................... 38

5.7. Herramientas para llevar a cabo pruebas de rendimiento ........................................... 41

5.7.1. Pruebas manuales .......................................................................................................... 41

5.7.2. Pruebas automatizadas ................................................................................................. 41

5.7.3. Aplicaciones de software libre o gratis ............................................................................... 41

5.7.3.1. JMeter .......................................................................................................................... 42

5.7.3.2. JCrawler .................................................................................................................... 43

5.8. Aplicaciones comerciales .................................................................................................. 43

5.8.1. WAPT ............................................................................................................................ 43

5.8.2. Netsparker .................................................................................................................... 44

5.8.3. OPENSTA ......................................................................................................................... 45

5.8.4. Web load and performance testing ................................................................................ 45

5.8.5. Testmaker ....................................................................................................................... 45

PARTE III ......................................................................................................................................... 46

ANÁLISIS COMPARATIVO .................................................................................................................. 46

6. ANÁLISIS COMPARATIVO DE HERRAMIENTAS .......................................................................... 47

6.1. Diferencia entre pruebas de rendimiento, pruebas de carga y pruebas de estrés ............... 47

6.2. Características a medir en el estudio comparativo................................................................ 49

7. CONCLUSIONES ............................................................................................................................. 52

8. Bibliografía .................................................................................................................................... 53

ÍNDICE DE ILUSTRACIONES

GRAFICA 1: NIVELES DE MADUREZ TMMI............................................................................ 25

GRAFICA 2: MODELO CMMI ................................................................................................. 26

GRAFICA 3: MODELO TMMI ................................................................................................. 26

GRAFICA 4: ASEGURAMIENTO DE LA CALIDAD 1 ................................................................. 34

GRAFICA 5: PERFILES JMETER .............................................................................................. 42

GRAFICA 7: INTERFAZ NETSPARKER ..................................................................................... 44

ÍNDICE DE TABLAS

TABLA 1: ÁREAS DE PROCESO TPI ........................................................................................ 24

TABLA 2: TÉCNICAS DE PRUEBA ........................................................................................... 35

TABLA 3: TIPOS DE PRUEBAS ................................................................................................ 40

TABLA 4: ANÁLISIS COMPARATIVO DE HERRAMIENTAS ...................................................... 51

9

INTRODUCCIÓN

Esta monografía trata de plasmar en un contenido estructurado las pruebas que se ejecutan en el desarrollo de software, dividiendo el contenido de una manera práctica, que comienza mostrando de cómo se puede lograr un producto software capaz de satisfacer las necesidades del cliente, pasando por las distintas fases en el desarrollo del proyecto y haciendo énfasis en la importancia de las pruebas en las distintas fases de desarrollo del producto y detallando la importancia de las pruebas de rendimiento para asegurar que el software cumple con las características establecidas y con los requisitos necesarios para la satisfacción del cliente. El documento está dividido en cuatro (4) partes principales. En la primera parte del documento se habla de trabajos existentes a nivel mundial que consisten en algunas de las metodologías más usadas para el desarrollo de proyectos testing de software y sobre estándares sobre calidad. En la segunda parte se describen conceptos básicos sobre testing, metodologías de forma más explicitas, y posturas con respecto al testing de rendimiento y se mencionan distintas herramientas para ejecutar pruebas de rendimiento. Por último, se encuentra una tabla comparativa entre las herramientas más usadas en el mercado, tanto gratuitas como comerciales. Todo esto busca mostrarle al lector, la importancia de las pruebas de software en el desarrollo de proyectos de este tipo y como inciden en la consecución de un software con características más acorde con las nuevas metodologías de trabajo aplicadas al desarrollo de productos de software.

10

1. OBJETIVOS

1.1. OBJETIVO GENERAL

Construir el estado del arte de métodos, tipos de testing y herramientas para aplicarlas en pruebas de rendimiento y determinar las herramientas más importantes para estas pruebas, teniendo en cuenta el método utilizado.

1.2. OBJETIVOS ESPECÍFICOS

Identificar y clasificar los avances más importantes relacionados

con los métodos, tipos de testing y herramientas más utilizadas en las pruebas de rendimiento.

Analizar y comparar los métodos y herramientas más utilizados en el mercado para efectuar pruebas de rendimiento.

Determinar las herramientas más representativas teniendo en cuenta el tipo de prueba y método aplicado a la prueba.

11

2. JUSTIFICACIÓN

Desde que el ser humano comenzó a tratar de hacer de su vida algo más placentera y a crear productos para lograrlo, se dio cuenta de que los productos que creaba podían llegar a ser mejores, es así como nació el concepto de calidad, que no es más que hacer que un producto o servicio conste de características óptimas para satisfacer una necesidad. Para lograr que un producto tenga ciertas características que lo hagan diferenciarse de otro y que al mismo tiempo cumpla con el propósito para el cual fue producido no basta con que pueda ser usado durante cierto tiempo sin que se deteriore o se dañe, también tiene que cuidar, dependiendo de quién lo use, de no causar daños derivados de su uso. A nivel de software no es muy distinto el paisaje. El desarrollo de software es todavía para mucha gente, la mayoría, algo que parece magia y creen que desarrollar un software es tarea fácil y solo consiste en ―tirar código‖ frente a un computador y quemar un CD. Pero la realidad es otra, desde el comienzo de los lenguajes de programación los usuarios han querido hacer más con los programas de computador, tanto que muchos de esos usuarios se han hecho a la tarea de crear software que puede que solucione sus problemas específicos pero que a la larga no cumplen con muchos factores importantes para el uso de software a lo largo de mucho tiempo. Esa falta de características de calidad fueron las que hicieron que el profesional del desarrollo de software, preocupado por la falta de esas características, se diera a la tarea de investigar en donde radicaba el problema. Es así como se crearon metodologías para el desarrollo de software que van desde la concepción misma de la idea del software hasta la entrega de este, y abarca todo lo que implica su desarrollo, el personal, la documentación, los recursos, la infraestructura, la tecnología y desde hace algunos años, las pruebas. Hace años las tareas de desarrollo de software eran hechas solo por el desarrollador o programador, este se encargaba de todas las tareas necesarias para hacer un programa y muchas veces se limitaba a entregar la aplicación con las funciones que le pedían y no le importaba mucho si lo que entregaba realmente cumplía con las expectativas del cliente y de ahí en adelante se desentendía del software. La falta de documentación y de una metodología definida para el desarrollo del producto hizo que la gente común desconfiara de los productos de software y preferían hacer sus tareas manualmente.

12

Al ver que en otras industrias se implementaban nuevas formas de hacer los productos de consumo el profesional de los sistemas de información se puso a la tarea de mejorar la forma en que se desarrollaba software a de entregar productos que cumplieran con las características que aseguraran que su producto y él tendrían un lugar de renombre en el mercado, de esta forma, asegurando que el producto de software que entregaba tenia características de calidad estándares, podía asegurar su mejoramiento. En este documento vamos a ver como se hace para asegurar que un producto software cumpla con las características necesarias para asegurar su calidad teniendo en cuenta las pruebas o testing.

13

3. MARCO TEÓRICO

Abordar el tema de la calidad desde cualquier ángulo implica siempre serios compromisos que ineludiblemente obligan a referirse a los llamados cinco grandes de la calidad, ellos son William Edwards Deming, Joseph M. Juran, Armand V. Feigenbaum, Kaoru Ishikawa y Philip B. Crosby1. Otros han surgido después y son de reconocimiento mundial, pero los aportes de estas cinco personas fueron los que más impacto ocasionaron. Basado en los planteamientos de grandes mentes en lo que tiene que ver con calidad, hago referencia a los más representativos. Deming, desarrolló el Control Estadístico de la Calidad, demostrando en el año 1940, que los controles estadísticos podrían ser utilizados tanto en operaciones de oficina como en las industriales. En 1947 fue reclutado para que ayudara al Japón a preparar el censo de 1951, y en esa época vivió los horrores y miserias de la postguerra y se concientizó de la necesidad de ayudar al Japón. En 1949, Ishikawa, se vincula a la UCIJ (Unión de Científicos e Ingenieros Japoneses) y empezó a estudiar los métodos estadísticos y el control de la calidad. Los pasos que siguió y que lo guiaron fueron: 1. Los ingenieros tienen que conocer de memoria los métodos estadísticos y cómo utilizarlos. 2. Como el Japón no tiene abundancia de recursos naturales sino que debe importarlos, es necesario que amplíe sus exportaciones produciendo productos de alta calidad y bajo costo. 3. Consideró que la aplicación del control de la calidad podía lograr la revitalización de la industria y efectuar una revolución conceptual de la gerencia. En 1950 el director administrativo de la Unión de Científicos e Ingenieros Japoneses (UCIJ), Kenichi Koyanogi, le escribió para que dictara unas

1 (PIATTINI, GARCÍA, & CABALLERO, 2007)

14

conferencias sobre los métodos de control de la calidad a investigadores, directores de plantas e ingenieros, y el 19 de Junio de 1950 pronunció la primera de una docena de conferencias. Para demostrar su aprecio por Deming, los japoneses establecieron en 1951 el Premio Deming. Además le entregaron la Segunda Orden del Sagrado Tesoro, siendo el primer norteamericano en recibir tal honor. El éxito de Deming en Japón no fue reciprocado en los EEUU, donde no lo descubrieron hasta 30 años después. En 1954, Juran visitó por primera vez el Japón y orientó el Control Estadístico de la Calidad a la necesidad de que se convierta en un instrumento de la alta dirección. Ese propio año dictó seminarios a gerentes altos y medios. A partir de ese entonces hubo un cambio en las actividades del control de calidad en Japón. Juran señaló que el control estadístico de la calidad tiene un límite y que es necesario que el mismo se convierta en un instrumento de la alta dirección, y dijo que ―para obtener calidad es necesario que todos participen desde el principio. Si sólo se hiciera como inspecciones de la calidad, estuviéramos solamente impidiendo que salgan productos defectuosos y no que se produzcan defectos‖. Feigenbaum fue el fundador del concepto de Control Total de la Calidad (CTC) al cual define como ―un sistema eficaz para integrar los esfuerzos en materia de desarrollo de calidad, mantenimiento de la calidad, realizados por los diversos grupos de la organización, de modo que sea posible producir bienes y servicios a los niveles más económicos y que sean compatibles con la plena satisfacción de los clientes‖ Siendo la calidad tarea de todos en una organización, él temía que se convirtiera en tarea de nadie, entonces sugirió que el control total de la calidad estuviera respaldado por una función gerencial bien organizada, cuya única área de especialización fuera la calidad de los productos y cuya única área de operaciones fuera el control de la calidad, de ahí es que nacen los llamados Departamentos de Control de la Calidad. Años más tarde, Ishikawa retoma el término de Feigenbaum de Control Total de la Calidad, pero al estilo japonés y prefiere llamarlo ―control de calidad en toda la empresa‖, y significa que toda persona de la empresa deberá estudiar, participar y practicar el control de la calidad. Otro de los grandes, Crosby, desarrolla toda una teoría basado fundamentalmente en que lo que cuesta dinero son las cosas que no tienen calidad, de todas las acciones que resaltan de no hacer las cosas bien desde la primera vez, de ahí su tesis de la prevención.

15

Comparte la idea de Ishikawa de que la calidad es la oportunidad y obligación de los dirigentes, y para lograr el compromiso por la calidad en la alta dirección, desarrolló como instrumento el ―cuadro de madurez‖ que permite realizar un diagnóstico y posibilita saber qué acciones desarrollar. Muchas otras personas han surgido con concepciones e ideas particulares derivadas de su experiencia, pero a la vez todos coinciden en un conjunto de ideas que son básicas para que la calidad tenga un carácter total, ellas son: 1. Esta filosofía es una tarea que tiene que ser impulsada por el número uno de la organización. 2. Es un problema de todos. 3. Tiene que estar orientada al consumidor. 4. Es un proceso de mejoramiento continuo. 5. Requiere de una educación permanente, tanto de dirigentes como de trabajadores. 6. Necesita de una medición permanente que identifique cuál es el costo del incumplimiento. Para ver cómo ha evolucionado la calidad durante el presente siglo, se lo puede apreciar a través del análisis de sus características fundamentales, considerando las cinco etapas principales de su desarrollo.

3.1. 1° Etapa. Desde la revolución industrial hasta 1930

La Revolución Industrial, desde el punto de vista productivo, representó la transformación del trabajo manual por el trabajo mecanizado. Antes de esta etapa el trabajo era prácticamente artesanal y se caracterizaba en que el trabajador tenía la responsabilidad sobre la producción completa de un producto. En los principios de 1900 surge el supervisor, que muchas veces era el mismo propietario, el cual asumía la responsabilidad por la calidad del trabajo. Durante la Primera Guerra Mundial, los sistemas de fabricación se hicieron más complicados y como resultado de esto aparecen los primeros inspectores de calidad a tiempo completo, esto condujo a la creación de las áreas organizativas de inspección separadas de las de producción.

16

Esta época se caracterizaba por la inspección, y el interés principal era la detección de los productos defectuosos para separarlos de los aptos para la venta.

3.2. 2° Etapa. 1930-1949

Los aportes que la tecnología hacía a la economía de los países capitalistas desarrollados eran de un valor indiscutible. Sin embargo, se confrontaban serios problemas con la productividad del trabajo. Este estado permaneció más o menos similar hasta la Segunda Guerra Mundial, donde las necesidades de la enorme producción en masa requirió del control estadístico de la calidad. La contribución de más significación del control estadístico de la calidad fue la introducción de la inspección por muestreo, en lugar de la inspección al 100 por ciento. El interés principal de esta época se caracteriza por el control que garantice no sólo conocer y seleccionar los desperfectos o fallas de productos, sino también la toma de acción correctiva sobre los procesos tecnológicos. Los inspectores de calidad continuaban siendo un factor clave del resultado de la empresa, pero ahora no sólo tenían la responsabilidad de la inspección del producto final, sino que estaban distribuidos a lo largo de todo el proceso productivo. Se podría decir que en esta época ―la orientación y enfoque de la calidad pasó de la calidad que se inspecciona a la calidad que se controla‖

3.3. 3° Etapa. 1950-1979

Esta etapa, corresponde con el período posterior a la Segunda Guerra Mundial y la calidad se inicia al igual que en las anteriores con la idea de hacer hincapié en la inspección, tratando de no sacar a la venta productos defectuosos. Poco tiempo después, se dan cuenta de que el problema de los productos defectuosos radicaba en las diferentes fases del proceso y que no bastaba con la inspección estricta para eliminarlos. Es por esta razón que se pasa de la inspección al control de todos los factores del

17

proceso, abarcando desde la identificación inicial hasta la satisfacción final de todos los requisitos y las expectativas del consumidor. Durante esta etapa se consideró que éste era el enfoque correcto y el interés principal consistió en la coordinación de todas las áreas organizativas en función del objetivo final: la calidad. A pesar de esto, predominaba el sentimiento de vender lo que se producía. Las etapas anteriores ―estaban centradas en el incremento de la producción a fin de vender más, aquí se pasa a producir con mayor calidad a fin de poder vender lo mejor, considerando las necesidades del consumidor y produciendo en función del mercado‖. Comienzan a aparecer Programas y se desarrollan Sistemas de Calidad para las áreas de calidad de las empresas, donde además de la medición, se incorpora la planeación de la calidad, considerándose su orientación y enfoque como la calidad se construye desde adentro.

3.4. 4° Etapa. Década del 80

La característica fundamental está en la Dirección Estratégica de la Calidad, por lo que el logro de la calidad en toda la empresa no es producto de un Programa o Sistema de Calidad, sino que es la elaboración de una estrategia encaminada al perfeccionamiento continuo de ésta, en toda la empresa. El énfasis principal de esta etapa no es sólo el mercado de manera general, sino el conocimiento de las necesidades y expectativas de los clientes, para construir una organización empresarial que las satisfaga. La responsabilidad de la calidad es en primer lugar de la alta dirección, la cual debe liderarla y deben participar todos los miembros de la organización. En esta etapa, la calidad era vista como ―una oportunidad competitiva, la orientación o enfoque se concibe como la calidad se administra‖

3.5. 5° Etapa. 1990 hasta la fecha

La característica fundamental de esta etapa es que pierde sentido la antigua distinción entre producto y servicio. Lo que existe es el valor total para el cliente. Esta etapa se conoce como Servicio de Calidad Total. El cliente de los años 90 sólo está dispuesto a pagar por lo que significa valor para él. Es por eso que la calidad es apreciada por el cliente desde dos puntos de vista, calidad perceptible y calidad factual. La primera es la clave para que la gente

18

compre, mientras que la segunda es la responsable de lograr la lealtad del cliente con la marca y con la organización. Un servicio de calidad total es un enfoque organizacional global, que hace de la calidad de los servicios, según la percibe el cliente, la principal fuerza propulsora del funcionamiento de la empresa. Hasta aquí la evolución histórica de la calidad podría resumirse a través de los siguientes cuadros. Hung Nguyen, CEO de LogiGear, en su presentación titulada Software Testing 3.0, en la conferencia de STPCON, San Mateo, California, 2007, estableció la evolución de las pruebas de software de la siguiente manera: Es muy común para los procesos de negocio evolucionar con el tiempo. Sin duda el desarrollo de software ha sufrido evolución sustancial durante los años. Del mismo modo, las pruebas de software también han experimentado un proceso evolutivo.

3.6. Pruebas de software 1.0

En la primera etapa de las pruebas de software, las pruebas se consideraban una tarea complementaria al desarrollo de las aplicaciones, se dejaba a personal menos calificado y mal pagado quienes pensaban que las pruebas de software eran solo un punto más en el desarrollo de software. Durante la fase de pruebas de software 1.0 hubo pocas herramientas de pruebas útiles y métodos para lograr un alto grado de automatización. Las herramientas que existían eran caras, complejas, difíciles de utilizar e ineficaces a la hora de abordar las necesidades de productividad y preocupaciones. Lo que es importante, en esta fase, la dirección ejecutiva fue principalmente desconectada de las pruebas de software - suponiendo que de alguna manera se consiguió hacer.

3.7. Pruebas de software 2.0

En esta etapa se reconoció que las pruebas de software son una parte importante del proceso de desarrollo, las pruebas de software se pusieron de moda y todo el mundo hacia pruebas en serio. En este punto el problema se presentó en saber dónde encajaban las pruebas desde el punto de vista organizativo, administrativo, principalmente en lo referente al presupuesto y su dirección y toma de decisiones.

19

También se presentó una explosión de herramientas disponibles. Estas herramientas eran a menudo fuente de distracción para los que elaboraban las pruebas, haciendo que se invirtiera más tiempo en la selección de dicha herramienta y descuidando los objetivos, la arquitectura y la dirección de las pruebas. En esta etapa la comprensión y la participación de la dirección ejecutiva eran todavía rudimentarias.

20

PARTE I

TRABAJOS EXISTENTES

21

4. EN BUSCA DE MEJORES PRÁCTICAS PARA PRUEBAS DE RENDIMIENTO

Como estudiante de ingeniería de sistemas he visto como se han implementado en distintas ramas de la carrera, herramientas que buscan mejorar la resolución de los problemas que se nos presentan en nuestro trabajo diario. Es así como para la ingeniería de software se crearon modelos como RUP, RAD, modelo en espiral en cascada y UML entre otros, que buscaron estandarizar una forma de trabajar para llevar a cabo el desarrollo de aplicaciones de forma ordenada y bien documentada. Por tanto el testing no es la excepción. Las pruebas de software se han vuelto tan importantes en el desarrollo de aplicaciones que la industria se ha tomado la tarea de buscar y difundir modelos de desarrollo que nos ayuden a efectuar pruebas de software de una manera ordenada, consciente, siempre buscando la madures de la industria. Dentro de los modelos para la mejora de procesos de pruebas de software podemos encontrar entre otros el Modelo de Mejora de Procesos de Prueba (TPI, por sus siglas en ingles), el Modelo de Integración y Madurez de las Pruebas (TMMi, por sus siglas en ingles).

4.1. MODELO DE MEJORA DE PROCESOS DE SOFTWARE (TPI)

Este modelo establece unas áreas claves que constituyen la base para la mejora de los procesos de pruebas. El modelo TPI consta de 20 áreas clave2.

ÁREAS CLAVE DESCRIPCIÓN

Estrategia de pruebas

La estrategia de pruebas debe estar dirigida a encontrar los defectos más importantes con la mayor rapidez y el menor costo posible. En la estrategia de pruebas se determinan los defectos (de calidad) descubiertos al realizar las pruebas. Al involucrar más pruebas y medidas de detección, se puede definir mejor la estrategia. Las duplicidades u omisiones involuntarias que tengan lugar entre diferentes pruebas pueden ser evitadas coordinando a los probadores y las actividades de pruebas, así como fijando el alcance de la prueba.

Modelo del ciclo Dentro del proceso de pruebas se distinguen algunas fases: planeamiento, preparación, diseño, ejecución y terminación.

2 (Koomen & Pol, 1999)

22

de vida En cada fase se efectúan algunas actividades. Para cada actividad se registran aspectos tales como: objetivo, entradas, proceso, conceptos, dependencias, técnicas y herramientas, instalaciones y documentación. La importancia de contar con un modelo de ciclo de vida reside en tener un mejor control del proceso de pruebas, dado que las actividades pueden ser planeadas y controladas consistentemente.

Momento de involucración

Aunque el momento de ejecución de la pruebas se inicia normalmente al concluir el diseño del software, el proceso de pruebas debe iniciarse mucho antes. La involucración temprana de las pruebas en el ciclo de vida del desarrollo de sistemas ayuda a detectar los defectos con mayor antelación y/o con más facilidad, e incluso ayuda a prevenir defectos. Ello redunda en una mejor coordinación entre las pruebas además de reducir enormemente la ruta crítica de las pruebas.

Estimación y planeación

Se necesita estimar y planear para definir las actividades que deben realizarse en cada momento y los recursos que serán necesarios. Estimar y planear son la base para ahorrar capacidad y para coordinar las actividades de prueba y las actividades del proyecto.

Técnicas de diseño de pruebas

Una técnica de diseño de pruebas se define como ―un modelo para derivar casos de prueba de la documentación‖. El uso de estas técnicas incrementa la visibilidad de la calidad y la cobertura de pruebas y conduce a una mayor reusabilidad de pruebas. En base a una estrategia de pruebas, se utilizan diferentes técnicas de diseño de pruebas para obtener la cobertura del código de las partes de software cuyo alcance fue acordado.

Técnicas de pruebas estáticas

No todo puede ni requiere ser probado dinámicamente, por ejemplo, ejecutando los programas. Al fenómeno de validar productos sin ejecutar los programas o evaluar métricas de calidad específicas, se le llama ―Pruebas Estáticas‖. Las listas de verificación y mecanismos similares son muy útiles en este caso.

Métricas

Las métricas son observaciones cuantitativas ( mediciones ). Para el proceso de pruebas, medir el progreso y la calidad del software probado es muy importante, así como también lo son las métricas en estas áreas. Las métricas se utilizan para poder administrar el proceso de pruebas, para poder tener evidencia al momento de expresar una opinión, y también para comparar diferentes sistemas o procesos. Ayudan a contestar preguntas tales como: ―¿ Por qué el sistema A tiene mucho menos fallos en producción que el sistema B ?‖ ; ―¿ Por qué el proceso de pruebas del sistema A puede ser ejecutado con mayor rapidez y con mayor alcance que el proceso del sistema B ?‖. En la mejora del proceso de pruebas, las métricas son esencialmente importantes para juzgar los resultados de ciertas acciones de mejora. Esto se hace midiendo antes y después de que la mejora sea implantada.

Herramientas de prueba

La automatización del proceso de pruebas puede efectuarse de muy diversos modos. Como regla, la automatización sirve a alguna de las metas siguientes: - Menor consumo de recursos - Menos consumo de tiempo - Mejor cobertura de pruebas - Mayor flexibilidad - Mayor o más rápida comprensión del estado del proceso de pruebas - Mayor motivación del personal de pruebas

Entorno de pruebas

La ejecución de la prueba tiene lugar en el llamado ―Entorno de Pruebas‖. Este entorno de pruebas consta de los siguientes componentes:

Hardware

23

Software Instalaciones de comunicaciones Herramientas para la creación y el uso de datos de prueba Procedimientos

El entorno debe quedar establecido para poder hacer pruebas de forma óptima. El entorno de pruebas influye en gran medida en la calidad, duración y coste del proceso de pruebas. Algunos aspectos importantes del entorno de pruebas son: roles y responsabilidades, control, disponibilidad suficiente y a tiempo, flexibilidad y representatividad de los entornos reales de producción.

Entorno de oficina

El personal de pruebas necesita oficinas, escritorios, sillas, ordenadores, grabadoras, impresoras, teléfonos, etc. Un arreglo adecuado y a tiempo del entorno de oficina influye positivamente en la motivación de dicho personal, y en la comunicación y eficiencia de la ejecución de las tareas de pruebas.

Compromiso y motivación

El compromiso y la motivación del personal involucrado en las pruebas son condiciones indispensables para lograr un proceso de pruebas ―maduro‖. El personal involucrado en el proceso de pruebas incluye no solamente a los miembros del equipo de pruebas, sino también, entre otros, a líderes de proyectos y a los directivos. El proceso de pruebas debe disponer del tiempo, dinero y recursos suficientes (cuantitativa y cualitativamente) para efectuar una buena prueba. La cooperación y comunicación con los otros miembros del proyecto da como resultado un proceso eficiente y una involucración temprana.

Funciones de prueba y

capacitación

El personal de pruebas requiere de una cierta preparación. Se requiere una combinación de diferentes materias, funciones, conocimientos y habilidades. Por ejemplo, aparte de tener experiencia específica sobre pruebas, también se requiere conocimiento del sistema que está siendo probado, conocimiento de la organización y conocimiento general de automatización. También es importante contar con ciertas habilidades sociales. Para poder tener estas cualidades, es necesario ofrecer educación y capacitación.

Alcance de la metodología

Para cada proceso de pruebas se utiliza cierta metodología o acercamiento, que consiste en actividades, procedimientos, estándares, técnicas, etc. Si estas metodologías difieren para cada proceso de pruebas en la organización, o si la metodología usada es demasiado genérica, muchas cosas tienen que ser reinventadas una y otra vez. El objetivo de una organización es utilizar una metodología que sea lo suficientemente genérica como para ser ampliamente aplicable, pero al mismo tiempo que sea lo suficientemente detallada para poder evitar las reinvenciones en cada nuevo proceso de pruebas.

Comunicación

En un proceso de pruebas, la comunicación se lleva a cabo de diversos modos, tanto entre los controladores como grupo, como entre los controladores y otros miembros del proyecto, tales como el desarrollador, el usuario final, y el líder del proyecto. Algunos temas objeto de comunicación son la estrategia de pruebas, así como el progreso y la calidad del software bajo prueba.

Informes

Realizar pruebas no está relacionado solamente con la detección de defectos, sino también con informar sobre la calidad ( o falta de calidad) del software. Los informes deben dirigirse a proporcionar información bien fundada hacia el proyecto y el cliente sobre la calidad del software e incluso sobre el proceso de desarrollo del software.

Manejo de defectos

Aunque el manejo de defectos es de hecho responsabilidad del líder de proyecto, los probadores están altamente involucrados en ello. Una buena administración debería ser capaz de controlar el ciclo de vida de un defecto y crear diferentes informes (estadísticos). Estos informes se usan para prestar asesoramiento bien fundado sobre la calidad del software.

Administración de Testware

El testware o los elementos de prueba deberían ser mantenibles y reutilizables, y por lo tanto, deben ser administrados. Aparte de los elementos de pruebas, también los productos de fases previas, tales como el diseño y la construcción, deben estar bien administrados (¡aunque no por los probadores!). El proceso de pruebas puede verse seriamente interrumpido por la entrega de versiones

24

erróneas de programas, etc. Una buena administración de estos productos incrementa la factibilidad de pruebas (y por ende la calidad) del software.

Administración del proceso de

pruebas

Con el fin de administrar cada proceso y cada actividad, son esenciales los cuatro pasos del llamado círculo de calidad de Deming: Planear, Hacer, Comprobar, Actuar. Un proceso de pruebas bien administrado es de la mayor importancia para efectuar la mejor prueba posible en la a veces turbulenta área de pruebas.

Revisión estructurada

Revisión Estructurada en este contexto significa validar algunos conceptos tales como el diseño funcional. En comparación con las pruebas, la ventaja de la revisión estructurada es que ofrece la oportunidad de detectar defectos con prontitud. Esto lleva a que los costes de reparación sean considerablemente más bajos. Además, realizar dicha revisión es relativamente simple dado que ningún programa debe ser ejecutado y no se requiere establecer ningún entorno de pruebas, etc.

Pruebas de caja blanca

Una prueba de caja blanca está definida como una prueba de las propiedades internas de un objeto, mediante el conocimiento de funciones internas. Estas pruebas son ejecutadas por los desarrolladores. La prueba unitaria y la de integración son pruebas bastante conocidas de caja blanca. Al igual que la Revisión Estructurada, estas pruebas son efectuadas en las etapas iniciales del ciclo de vida antes de llegar a las pruebas de caja negra. Por otro lado, las pruebas de caja blanca son relativamente baratas porque se requiere menor comunicación y porque el análisis es más sencillo (la persona que detecta los defectos es regularmente la misma persona que hace las reparaciones. Además, se prueban menos objetos).

Tabla 1: Áreas de proceso TPI

4.2. MODELO DE INTEGRACIÓN Y MADUREZ DE LAS PRUEBAS

TMMi, desarrollado por el TMMi Fundation, es la evolución de TMM, creado por el Illinois Institute of Technology en 1996, ambos, muy en la línea CMMI, definen cinco niveles de madurez específicos para pruebas. El TMMi se ha desarrollado como un modelo por etapas. Este modelo por etapas predefinidas utiliza un conjunto de áreas de procesos para definir una ruta de mejora para una organización. Este camino de mejora es descrito por un componente modelo llamado nivel de madurez. Un nivel de madurez en un estado bien definido hacia el logro de la evolución en la mejora de procesos de la organización.

25

Grafica 1: Niveles de madurez TMMi

Mientras que algunos modelos se centran principalmente en el proceso de pruebas de alto nivel, como TPI, el TMMi da importancia a todos los niveles de prueba, incluso las pruebas estáticas y aspectos de la prueba estructurada. Este modelo abarca tanto las pruebas de bajo nivel como las de alto nivel (TMMI Fundation, 2009). El modelo TMMi está establecido con base a cuatro pilares: ciclo de vida, técnicas, infraestructura y organización. Es importante señalar que el modelo TMMi es complementario al CMMI, en muchos casos un determinado nivel de TMMi se apoya específicamente en su equivalente de CMMI. Por ejemplo, en el área de proceso de la gestión de la configuración no se ha analizado en profundidad dentro de TMMi, ya que, está ampliamente especificada dentro de CMMI.

26

En las anteriores graficas se pueden ver las similitudes entre ambos modelos.

4.3. CMMI

En CMMI existen tres (3) áreas de proceso que están dirigidas explícitamente al

aseguramiento de la calidad3, estas son:

QA o Aseguramiento de la Calidad: hace parte del segundo nivel de madurez de CMMI (nivel gestionado) y su objetivo principal es que los procesos y los elementos de trabajo cumplan los procesos; de ésta forma la norma sugiere la realización de ciertas tareas para cumplir con dicha área de proceso las cuales incluyen:

a) Evaluar objetivamente la ejecución de los procesos, los elementos de

trabajo y servicios contra las descripciones de procesos, estándares y procedimientos.

b) Identificar y documentar los elementos no conformes. c) Proporcionar información a las personas que están usando los procesos y a

los gestores de los resultados de las actividades de aseguramiento de la calidad.

d) Asegurar que los elementos no conformes son corregidos. Generalmente en la industria del software, al momento de implantar ésta área de proceso se tiende a subcontratar las pruebas de software bajo el modelo de “Outsourcing”. En otros casos la subcontratación no se da; en su lugar se establece un área de pruebas al interior de la empresa ligada al proceso

3 (Carnegie Mellon University, 2006)

Grupo Tecnis

Grafica 3: Modelo TMMi Grafica 2: Modelo CMMI

27

productivo. En general los autores aseguran que la clave de éxito o fracaso de los pruebas de software están asociadas a la subcontratación o no de las mismas. Algunos como Myers aseveran que la subcontratación es vital para que la calidad del software sea conforme debido a que no se sesgan los resultados de las pruebas. Contrariamente, otros autores dicen que los procesos de aseguramiento de la calidad, específicamente los relacionados con las pruebas de software, deben ir inmersos totalmente en el proceso productivo de la organización, dado que la retroalimentación y su interrelación agregan madurez a todo el proceso. La verificación y la validación, pretenden en cualquier estándar (y particularmente en CMMI convertirse en una herramienta para la colaboración y el incremento del rendimiento de los equipos de trabajo, permitiendo así la conformidad del producto final basada en altos estándares de calidad.

Verificación: hace parte del tercer nivel de madurez en CMMI [1] (nivel

definido). Su propósito principal es el de asegurar que los productos de trabajo seleccionados responden a los requisitos especificados. Sus objetivos o metas específicas son: preparar la verificación, realizar revisiones por terceros y verificar los productos de trabajo seleccionados.

Validación: Hace parte del tercer nivel de madurez en CMMI [1] (nivel definido). Su propósito es el de demostrar que un producto o componente satisface su uso, en el ambiente operativo planeado. Sus objetivos o metas específicas son: preparar la validación y realizar la validación de los productos o componentes de trabajo.

Aunque ambas áreas de proceso no son consideradas como pruebas de software directamente, si tiene un valor relevante a la hora de hacer que los productos de software posean características de alta calidad. Las prácticas que se derivan permiten realizar pruebas de software sobre productos más maduros y confiables. Es importante tener en cuenta que los procesos de pruebas no componen ni aseguran la calidad, las pruebas proveen de elementos y prácticas de mejora con el fin de retroalimentar los procesos.

4.4. ISO

La evaluación de la calidad de los productos mediante normas internacionales es una práctica muy utilizada en la industria del software actual dada la relevancia de la calidad en la negociación de éste en el mundo contemporáneo. Tres de los

28

documentos más importantes generados por la ISO que hacen referencia a la calidad del software y a las pruebas son:

ISO/FDIS 9126 Information Technology — Software Product Quality o Modelo de calidad de producto.

ISO 14598 Software Product Evaluation o Evaluación del producto software

ISO/IEC 15504 Modelo para la mejora y evaluación de los procesos de desarrollo y mantenimiento de sistemas y productos de software.

Los dos primeros documentos tienen una relación directa y permiten abarcar los principales aspectos de la producción conforme de las piezas de software, el último es un modelo de madurez para la calidad del software que se enfoca en evaluar los procesos, siendo éste compatible con CMMI, pero no equivalente en cuanto a sus contenido y propósito explícito.

29

PARTE II

ESTADO DEL ARTE

30

5. ESTADO DEL ARTE

Según la IEEE las pruebas de rendimiento (perfomance testing) es ―el grado en que un sistema o componente realiza sus funciones designadas dentro de las limitaciones dadas, tales como velocidad, precisión o el uso de la memoria‖. Las pruebas de rendimiento originalmente fueron vistas como la forma de ―romper‖ o ―quebrar‖ las aplicaciones existentes buscando errores. Con el tiempo se entendió que la idea no es destruir una aplicación, sino, hallar los defectos que hacen que la aplicación no cumpla con todos los aspectos esperados de esta, y de esta forma fomentar su mejoramiento.

5.1. LAS PRUEBAS DE RENDIMIENTO SEGÚN MICROSOFT

Según J.D. Meier, Scott Barber y otros autores, lo que busca el performance testing es descubrir y direccionar uno o más riesgos, oportunidad de costos, reputación de la empresa4. Estos mismos autores proponen, para un proyecto de pruebas exitoso, que las tareas del proyecto deben ser relevantes al contexto del proyecto. S esto no se da se cometen errores en los cuales los testers acostumbran a concentrarse y asumir aspectos del proyecto que realmente no son los más importantes para las pruebas, todo esto conlleva a que se generan conflictos, frustración y pérdida de tiempo. El contexto del proyecto se puede entender como los aspectos importantes del proyecto de desarrollo que se quieren alcanzar y evaluar en las pruebas, estos aspectos pueden ser el alcance del proyecto, el ciclo de vida del proyecto, los criterios de funcionamiento exitoso de la aplicación, entre otros.

4 (Microsoft Corporation, 2007)

31

5.2. Rendimiento, pruebas de carga y estrés

Pruebas de rendimiento: Estas pruebas validan la velocidad, escalabilidad y estabilidad del sistema. El rendimiento es afectado por los tiempos de respuesta y los niveles de utilización de los recursos. Pruebas de carga: Esta prueba se centra en determinar o validarlas características de rendimiento del sistema cuando se somete a cargas de trabajo durante las tareas de producción. Pruebas de estrés: Estas pruebas van más allá de las pruebas de carga, ya que evalúan las condiciones en las que la aplicación evaluada se somete a pruebas como reducción de memoria, poco espacio en disco, falla en el servidor y todos los aspectos evaluables que podrían hacer que la aplicación dejara de funcionar o disminuyera su rendimiento considerablemente y en base a esto establece las características críticas a tener en cuenta y vigilar para evitar un fracaso o malfuncionamiento del sistema.

5.3. Las pruebas de rendimiento según Ian Molyneaux

Ian Molyneaux, mira el rendimiento de software desde el punto de vista del usuario final y analiza la percepción cuando este lleva a cabo varias tareas al mismo tiempo en la aplicación y verifica los retrasos en la ejecución de tareas simultáneas5. Mientras Meier y Barber se concentran en cómo llevar a cabo las pruebas de rendimiento, Molyneaux se inclina a cómo medir y analizar los resultados de esas pruebas. Para esto establece unos indicadores clave que deben ser tenidos en cuenta a la hora de analizar los resultados de las pruebas. Estos indicadores los divide en dos grupos: orientados a servicio y orientados a eficiencia. Los indicadores orientados a servicio son disponibilidad y tiempo de respuesta, estas miden que tan bien o no una aplicación provee un servicio al usuario final.

5 (Molyneaux, 2009)

32

Los indicadores orientados a eficiencia son rendimiento y utilización, estos indicadores miden que tan bien o no la aplicación hace uso del escenario en el que se está usando. Los anteriores indicadores se pueden definir de la siguiente manera:

5.3.1. Disponibilidad

La cantidad de tiempo que una aplicación está disponible para el usuario final. La falta de disponibilidad es importante porque muchas aplicaciones tendrán un costo importante negocio, incluso por un pequeño corte de energía. En cuanto a las pruebas de rendimiento, esto significaría la completa incapacidad de un fin usuario a hacer uso efectivo de la aplicación.

5.3.2. Tiempo de respuesta

La cantidad de tiempo que le toma a la aplicación para responder a una solicitud del usuario. Para pruebas de rendimiento, que normalmente se mide el tiempo de respuesta del sistema, que es el tiempo entre el usuario de solicitar una respuesta de la solicitud y el tiempo en que una respuesta completa llegar a la estación de trabajo del usuario.

5.3.3. Rendimiento

La velocidad a la que los eventos orientados a la aplicación ocurren. Un buen ejemplo sería el número de accesos a una página web en un plazo determinado de tiempo.

5.3.4. Utilización

El porcentaje de la capacidad teórica de un recurso que se está utilizando. Ejemplos incluyen la cantidad de ancho de banda de red está siendo consumido por el tráfico de aplicaciones y la cantidad de memoria utilizada en un servidor cuando un millar de visitantes son activos. En conjunto, estos indicadores pueden darnos una idea exacta de cómo es el desempeño de una aplicación y su impacto, en términos de capacidad, en el entorno de las aplicaciones.

33

5.4. MÉTODOS PARA REALIZAR PRUEBAS DE RENDIMIENTO

Como todas las tareas que realizamos diariamente en nuestro diario vivir no podemos esperar que todo el mundo haga las cosas de la misma forma, en las pruebas de software aplica la misma teoría, por eso encontramos varias metodologías para llevar a cabo las pruebas de rendimiento. Estas metodologías dependen en gran parte de la aplicación que vamos a probar y de lo que queremos probar dentro de la aplicación. Podemos encontrar la metodología orientada a objetos para el ciclo de vida completo, metodología de control de rendimiento, entre otros.

5.4.1. Metodología Orientada a Objetos para el Ciclo de Vida Completo

La metodología de Pruebas Orientada a Objetos para el Ciclo de Vida Completo (en inglés "Full Life-Cycle Object-Oriented Testing", FLOOT)6, es una colección de técnicas para verificar y validar software orientado a objetos. La metodología FLOOT, indica una amplia variedad de técnicas (descritas en la tabla 1) que están disponibles en todos los aspectos del desarrollo de software. La lista de técnicas no pretende ser completa – por el contrario su objetivo es hacer explícito el hecho de que se cuenta con un amplio rango de opciones disponibles. Es importante entender que aunque el método FLOOT es presentado como una colección de fases secuenciales no necesariamente tiene que ser así: las técnicas de FLOOT pueden ser aplicadas también con procesos agiles/evolutivos. La razón por la que presento FLOOT de una forma ―tradicional‖ es para volver explicito el hecho de que en realidad se puede realizar pruebas en todos los aspectos del desarrollo de software no solamente durante la codificación.

6 (Ambler, 2001)

34

Grafica 4: Aseguramiento de la calidad 1

Técnica FLOOT Descripción

Prueba de Caja-Negra

La prueba verifica que el ítem que se está probando, cuando se dan las entradas apropiadas produce los resultados esperados.

Prueba de Valores-Frontera

Es la prueba de situaciones extremas o inusuales que el ítem debe ser capaz de manejar.

Prueba de Clases

Es el acto de asegurar que una clase y todas sus instancias cumplen con el comportamiento definido.

Prueba de Integración de

Clases

Es el acto de asegurar que las clases, y sus instancias, conforman un software que cumple con el comportamiento definido.

Revisión de Código

Una forma de revisión técnica en la que el entregable que se revisa en el código fuente.

Prueba de Componente

Es el acto de validar que un componente funciona tal como está definido.

Prueba de Cubrimiento

Es el acto de asegurar que toda línea de código es ejercita al menos una vez.

Revisión de Diseño

Una revisión técnica en la cual se inspecciona un modelo de diseño.

Prueba de Regresión de

Herencia

Es el acto de ejecutar casos de prueba de las súper clases, tanto de forma directa como indirecta, en una subclase especifica.

Prueba de Consiste en realizar pruebas para verificar que un gran

35

Integración conjunto de partes del software funcionan juntas.

Prueba de Método

Consiste en realizar pruebas para verificar que un método (función miembro) funciona tal como está definido.

Revisión de Modelos

Un tipo de inspección, que puede ser desde una revisión técnica formal hasta un recorrido informal, realizado por personas diferentes a las que estuvieron directamente involucradas en el desarrollo del modelo.

Prueba de Caminos

Es el acto de asegurar que todos los caminos lógicos en el código se ejercitan al menos una vez.

Revisión de Prototipos

Es un proceso mediante el cual los usuarios trabajan a través de una colección de casos de uso, utilizando un prototipo como si fuera el sistema real. El objetivo principal es probar si el diseño del prototipo satisface las necesidades de esos usuarios.

Demostrar con el código

La mejor forma de determinar si un modelo realmente refleja lo que se necesita, o lo que se debe construir, es construyendo software basado en el modelo para mostrar que el modelo está bien.

Prueba de Regresión

El acto de asegurar que los comportamientos previamente probados todavía trabajan como se espera luego que se han realizado cambios a la aplicación.

Prueba de Stress El acto de asegurar que el sistema funciona como se espera bajo grandes volúmenes de transacciones, usuarios, carga y demás.

Revisión Técnica

Una técnica de aseguramiento de la calidad en la cual el diseño de tu aplicación es revisado de forma exhaustiva por un grupo de tus compañeros. Una revisión típicamente se enfoca en la precisión, calidad, facilidad de uso y completitud. A este proceso usualmente se le llama recorrido, inspección, o revisión de compañeros.

Prueba de Escenarios de

Uso

Una técnica de prueba en la cual una o más personas validan un modelo siguiendo la lógica de los escenarios de uso.

Prueba de Interfaz de

Usuario

Consiste en probar la interfaz de usuario para garantizar que cumple los estándares y requerimientos definidos. Usualmente se refiere a la prueba de interfaz de usuario gráfica.

Prueba de Caja-Blanca

Consiste en realizar pruebas para verificar que líneas específicas de código funcionan tal como está definido. También se le conoce como prueba de caja-transparente.

Tabla 2: Técnicas de Prueba

36

5.5. Metodología de Control de Rendimiento

Microsoft (Microsoft Corporation, 2007), establece siete (7) actividades claves sobre las cuales hay que trabajar para desarrollar un plan de pruebas de rendimiento exitoso. Las actividades son las siguientes:

1. Identificar el entorno de pruebas. 2. Identificar los criterios de aceptación de rendimiento. 3. Planear y diseñar las pruebas. 4. Configurar el entorno de pruebas. 5. Implementar el diseño de pruebas. 6. Ejecutar las pruebas. 7. Analizar, Reportar y Re-Probar

Cada una de estas actividades tiene su importancia dentro del proyecto de pruebas de rendimiento que propone Microsoft7.

5.5.1. Identificar el entorno de pruebas

Identifica el entorno físico donde se van a realizar las pruebas y el entorno de producción, así como las herramientas y recursos disponibles para el equipo de pruebas. En esta actividad se incluyen el hardware, software y configuraciones de red. Tener un conocimiento más profundo del entorno de pruebas permite crear un mejor diseño de las pruebas y anticiparse a posibles problemas y riesgos durante el desarrollo del proyecto de pruebas. Esta actividad debe realizarse periódicamente para detectar posibles cambios que puedan afectar la ejecución de las pruebas.

5.5.2. Identificar los criterios de aceptación de rendimiento

En esta actividad se establecen e identifican los valores mínimos con los cuales los resultados de las pruebas son aceptados. Los factores que se identifican son los que tienen que ver con tiempo de respuesta, utilización de recursos y limitaciones. En esta actividad se establecen tres (3) entes que son los directamente afectados por los factores antes mencionados: usuario (tiempo de respuesta), Rendimiento (empresa) y sistema (recursos). El resultado de esta

7 (Microsoft Corporation, 2007)

37

actividad son los datos con los cuales se establecen las configuraciones deseables para que la aplicación trabaje de la forma más adecuada.

5.5.3. Planear y diseñar las pruebas

En esta actividad se identifican los escenarios clave y los usuarios que interactúan con el sistema, se establece la variabilidad de estos (usuarios), se definen los datos de prueba y los parámetros que deben recogerse con las pruebas. Al tener estos datos se consolidan en uno o más modelos de uso del sistema a ser implementado, ejecutado y analizado.

5.5.4. Configurar el entorno de pruebas

Preparar el entorno de pruebas y establecer las herramientas y recursos necesarios para ejecutar cada estrategia, así como los componentes en el mercado para llevar a cabo las pruebas.

5.5.5. Implementar el diseño de pruebas

En esta actividad se llevan a cabo las pruebas de acuerdo al plan de pruebas.

5.5.6. Ejecutar las pruebas

En esta actividad se ejecutan y supervisan las pruebas, se recopilan y validan los datos de las pruebas.

5.5.7. Analizar, reportar y re-probar

En esta actividad se analizan, consolidan y comparten los resultados de los datos. Se realizan cambios y se vuelve a probar. Se comparan los resultados con la prueba anterior, luego de cada prueba las mejoras se volverán más pequeñas que la anterior. ¿Cuándo se detiene? Al llegar a un cuello de botella en la CPU, en este punto las opciones son mejorar el código o añadir más CPU´s.

38

5.6. Tipos de pruebas de rendimiento

Comúnmente las pruebas de rendimiento se llevan a cabo a aplicaciones web, ya que estas son las que tienen más pedidos para su ejecución por el entorno en el que se ejecutan. Los distintos tipos de pruebas de rendimiento que podemos encontrar y aplicables a la mayoría de las aplicaciones son las siguientes8:

TIPO DE PRUEBA PROPÓSITO OBSERVACIONES

Prueba de rendimiento Se lleva a cabo para determinar o validar velocidad, escalabilidad y/o estabilidad.

La prueba de rendimiento es una técnica de investigación hecha para determinar o validar tiempos de respuesta, velocidad, escalabilidad y/o características de estabilidad de la aplicación que se está probando.

Prueba de carga Sirve para verificar el comportamiento de la aplicación en condiciones normales y situaciones especiales.

Las pruebas de carga se realizan para comprobar que la aplicación cumple con los objetivos deseados de rendimiento, estos objetivos por lo general se especifican en un Acuerdo de Nivel de Servicio (SLA, por sus siglas en ingles). Una prueba de carga permite medir tiempos de respuesta, tasas de rendimiento y los niveles de utilización de los recursos e identificar el punto de ruptura de la aplicación, suponiendo

8 (Microsoft Corporation, 2007)

39

que el punto de ruptura se encuentra por debajo de la carga máxima. Prueba de resistencia. Es un subconjunto de las pruebas de carga. En esta prueba la aplicación se somete a volúmenes de carga anticipada durante las operaciones de producción en jornadas de tiempo largas, de esta forma se determinan o validan las características de rendimiento de la aplicación.

Prueba de estrés Sirve para determinar o validar el comportamiento de una aplicación cuando es empujada más allá de lo normal o a condiciones de pico de carga.

Lo que busca la prueba de estrés es revelar errores bajo condiciones de carga alta. Estos errores pueden incluir cosas tales como errores de sincronización y pérdidas de memoria. Esta prueba permite identificar los puntos débiles de la aplicación y muestra cómo se comporta en condiciones extremas de carga. Pruebas de Spike. Es un subconjunto de las pruebas de estrés. Esta prueba se centra en la determinación o validación de las características de rendimiento del producto cuando se someten a carga de trabajo de modelos y volúmenes e

40

carga que en ocasiones aumentan mas allá de las operaciones de producción previstas para cortos periodos de tiempo.

Pruebas de capacidad Esta prueba sirve para determinar que tantos usuarios y/o transacciones es capaz de soportar la aplicación y aun así satisfacer los objetivos de rendimiento.

Este test es conducido en conjunto con el plan de capacidad, el cual se usa para planear el crecimiento ya sea de los usuarios o el volumen de datos. Por ejemplo, para dar cabida a futuras cargas, se necesita saber cuántos recursos adicionales (procesadores, memoria, disco duro, ancho de banda, etc.) son necesarios para soportar los niveles de uso futuros. Esta prueba también permite identificar una estrategia para saber si el sistema es escalable horizontal o verticalmente.

Tabla 3: Tipos de pruebas

Las preocupaciones más comunes en cuanto a rendimiento radican en ¿Qué tan rápida es mi aplicación? ¿Podrá soportar todos mis clientes? ¿Qué ocurre si algo sale mal? ¿Qué necesito planificar cuando voy a recibir más clientes? En una conversación normal sobre el tema salen a relucir estas preguntas, la mayoría de la gente asocia el rendimiento con la rapidez de la aplicación. Los riesgos plasmados en las anteriores preguntas son la base de las cuatro (4) tipos de pruebas de rendimiento descritas anteriormente.

41

5.7. Herramientas para llevar a cabo pruebas de rendimiento

Las pruebas de software sin importar el tipo de prueba que se lleva a cabo (funcional, no funciona, rendimiento, etc.), se pueden llevar a cabo de forma manual o de forma automatizada.

5.7.1. Pruebas manuales

Las pruebas manuales son el tipo de pruebas más antiguo que existe, estas radican en que una persona (tester) ejecute de manera manual operaciones en el sistema sin ayuda de herramientas de automatización. En este tipo de pruebas el tester debe ser paciente, observador, creativo, entre otras cualidades. Las pruebas manuales están enfocadas a la funcionalidad del producto, la usabilidad y la interfaz gráfica de usuario.

5.7.2. Pruebas automatizadas

La automatización de las pruebas es la parte del ciclo de calidad del software donde una aplicación de automatización es usada para controlarla ejecución de las pruebas, comparar resultados, crear precondiciones, etc. Existen en el mercado gran cantidad de herramientas de pruebas automatizadas y frameworks de trabajo. Estas herramientas son conocidas como Computer Aided Software Testing (CAST) y las hay de libre distribución y comerciales.

5.7.3. Aplicaciones de software libre o gratis

Entre las aplicaciones de software libre o gratis para llevar a cabo pruebas de rendimiento más representativas podemos encontrar JMeter, JCrawler. Estas y otras herramientas se comparan en un aparte más adelante.

42

5.7.3.1. JMeter

Aplicación 100% Java de la gente de Apache, que nos permite definir comportamientos para casos de test y medir su rendimiento. Válido para contenido estático y dinámico (ficheros, Servlets, scripts de Perl, objetos Java, bases de datos y queries, FTP). Puede simular una gran carga en el servidor, HTTP y FTP testing y bases de datos mediante JDBC, multithreading y con grandes facilidades para extender su funcionalidad mediante plugins9.

9 (Apache Software Foundation)

Grafica 5: Perfiles JMeter

43

5.7.3.2. JCrawler

Aplicación opensource para realizar test de estrés a aplicaciones web. Le pasas una URL y puedes realizar una navegación. Admite redirecciones HTTP y cookies. Es independiente de la plataforma, posee un modo consola y es sencillo de configurar10.

5.8. Aplicaciones comerciales

Entre las aplicaciones de software libre o gratis para llevar a cabo pruebas de rendimiento más representativas podemos encontrar WAPT, netsparker, estas y otras herramientas se muestran en el cuadro comparativo más adelante..

5.8.1. WAPT

Herramienta para cargar y estresar una aplicación web, de fácil uso, consistente, que te permite analizar el rendimiento y encontrar cuellos de botellas según distintas configuraciones. Ofrece simulaciones precisas de la navegación realizada por un usuario, admite diferentes usuarios en un único test, válido para aplicaciones dinámicas y contenidos HTTP/SSL y devuelve detallados informes y datos sobre los tests realizados11.

10

(The Development Gateway Foundation, 2004) 11

(SoftLogica)

44

5.8.2. Netsparker

Mavituna Security es una pequeña empresa que desarrolla un producto de análisis de vulnerabilidades web llamado NetSparker que hemos tenido la suerte de poder evaluar.

Entre sus principales características se anuncia que está libre de reportar falsos

positivos, o lo que es lo mismo, identificar como vulnerabilidades peticiones que

realmente no lo son. Aunque esta característica tiene truco, ya que las que no

puede garantizar como vulnerables las etiqueta como "posibles", para que

posteriormente el auditor haga las comprobaciones oportunas.

Los motores soportan la detección de los riesgos más comunes: Inyección SQL ,

XSS, inclusión local y remota de ficheros, inyección de comandos, CRLF,

archivos obsoletos, código fuente, recursos ocultos, listado de directorios,

vulnerabilidades de configuración de los distintos servidores web, etc. Pero sin

duda el que más destaca y funciona mejor es el de inyección SQL, que

además permite la ejecución de comandos y de sentencias una vez se detecta un

parámetro vulnerable12.

12

(Mavituna Security Ltd.)

Grafica 6: Interfaz Netsparker

45

5.8.3. OPENSTA

Es un software de pruebas diseñado alrededor de CORBA, originalmente desarrollado para ser

comercializado por CYRANO13.

OpenSTA es un conjunto de herramientas tiene la pacidad de realizar pruebas por medio de scripts

y pruebas de carga pesada con mediciones de rendimiento en plataformas Win32.

5.8.4. Web load and performance testing

Consta de varias aplicaciones enfocadas a diferentes áreas de acción. Permite medir la carga y el

rendimiento desde el lado del desarrollador hasta el usuario final, incluso desde el ISP usado para

acceder a las aplicaciones web. Entre otras características, permite configurar hasta 100 mil

usuarios virtuales en diferentes pruebas de hasta 25 mil usuarios cada una.

5.8.5. Testmaker

Esta aplicación es capaz de realizar pruebas funcionales, de regresión, de carga y de rendimiento. Ofrece dos versiones: Community y Enterprise, ambas gratis pero el soporte lo brinda la versión Enterprise14.

13

(OpenSTA, 2008) 14

(PushToTest)

46

PARTE III

ANÁLISIS COMPARATIVO

47

6. ANÁLISIS COMPARATIVO DE HERRAMIENTAS

Las aplicaciones web actuales además de factores de funcionalidad y operatividad, exigen más que nunca niveles de calidad del servicio (QoS) óptimos, directamente relacionados con los tiempos de respuestas y la disponibilidad del servicio. Gracias a las pruebas de rendimiento es posible encontrar fallos de diseño arquitectónico facilitando la realización de ajustes con el fin de mejorar sus aracterísticas y rendimiento. En éste documento se compararan 5 herramientas de software para realizar pruebas a aplicaciones basadas en protocolos de Internet y software con arquitecturas cliente servidor. La comparativa estará orientada a estudiar las características más representativas de las herramientas comparadas y a analizar la tendencia del desarrollo de las mismas en cuanto a funcionalidades se refiere. El estudio comparativo planteado permitirá identificar grupos de aplicaciones con características similares, permitiendo elegir el uso de alguna de ellas según el ambiente y las características de lo que se quiere probar. El artículo se estructura así: en primera instancia se describirán los elementos conceptuales relevantes en el tema de las pruebas de rendimiento, posteriormente se listarán y explicarán las características a tener en cuenta al realizar el estudio comparativo; seguidamente se definirán 3 categorías de herramientas de pruebas y se detallará cada herramienta de cada categoría con sus características específicas mediante un conjunto de tablas; en el segmento siguiente se realizarán los análisis de los resultados de las pruebas comparativas.

6.1. Diferencia entre pruebas de rendimiento, pruebas de carga y pruebas de

estrés

a) Pruebas de rendimiento: Pruebas de rendimiento (performace testing): Su objetivo principal es desarrollar estrategias eficaces para la mejorar el rendimiento del sistema. En las pruebas de rendimiento se recopila y analiza información mediante un proceso de medición en el que se recogen datos para predecir cuando los niveles de carga agotará los recursos del sistema.

b) Pruebas de carga (load testing): evalúan el rendimiento del sistema con una carga predefinida. La prueba de carga mide cuánto se tarda un sistema para realizar diversas tareas y funciones del programa bajo condiciones normales o predefinidas. Debido a que el objetivo de las pruebas de carga

48

es determinar si el rendimiento del sistema satisface los requisitos no funcionales de carga del sistema, es pertinente que la configuración mínima y máxima y los niveles de actividad se determine antes de comenzar las pruebas.

c) Pruebas de estrés (stress testing): evalúan el comportamiento de los sistemas cuando éstos son llevados más allá de sus límites operacionales (esto puede ser muy por encima de los requisitos no funcionales). Se evalúa las respuestas del sistema y de la aplicación a periodos de mayor volumen de actividad que superen las limitaciones del sistema. El objetivo principal de las pruebas de estrés es determinar si un sistema se bloquea o se recupera en dichas condiciones. Las pruebas de estrés deben ser diseñadas para llevar los límites de los recursos del sistema hasta el punto en que los puntos débiles de la aplicación queden expuestos.

Existen también algunos conceptos utilizados en el ámbito de las pruebas de carga que son relevantes a la hora de realizar un análisis de resultados y van directamente relacionadas con las características a medir mediante las herramientas de pruebas de carga. Los más destacados son:

Punto de quiebre: cantidad máxima de usuarios concurrentes que la aplicación puede soportar antes de no entregar una respuesta efectiva.

UVC (Usuarios Virtuales Concurrentes): Es la cantidad de usuarios virtuales que son configurados para generar la concurrencia establecida en la prueba de carga.

Sesión: Es el espacio de tiempo donde el usuario virtual ejecuta la acción programada mediante la herramienta de carga.

MTR (Máximo Tiempo de Respuesta): Es la variable que permite medir el tiempo máximo de respuesta que arroja algún objeto o elemento que ha ido probado mediante la herramienta.

Throughput: Es la respuesta del servidor de aplicaciones a la petición que envía el generador de carga, específicamente con lo relacionado a la capacidad de transmisión de un medio de comunicación en cualquier momento; se suele medir en bits por segundo (bps).

Response time (Tiempo de respuesta): tiempo que pasa entre la petición y la respuesta de un servicio cliente servidor.

Al evaluar posibles herramientas para realizar pruebas de carga surgen conceptos y consideraciones que permiten realizar una escogencia correcta de acuerdo tanto al ambiente como a las necesidades organizacionales y funcionales de la prueba.

49

6.2. Características a medir en el estudio comparativo

En la comparativa se tendrán en cuenta 10 factores o funcionalidades

relacionados con cada una de las herramientas. Los factores se describen a

continuación:

1. Dirección url del fabricante: sitio web de donde se puede descargar la

aplicación, manuales y recursos disponibles.

2. Tipo de licencia y precio: el tipo de licencia delimita mucho las capacidades

de la aplicación.

3. Plataforma: sistemas operativos soportados para la instalación de la

herramienta.

4. Manejo de perfiles de usuarios virtuales: usualmente este tipo de

aplicaciones tiene en cuenta los perfiles de usuarios y derechos sobre el

sistema a probar, de esta manera las pruebas son más realísticas.

5. Soporte IP Spoofing: esta utilidad permite asignarle a los usuarios virtuales

una IP, haciendo que la prueba sea más cercana a la realidad emulando

usuarios concurrentes conectados desde distintas terminales.

6. Proxy http: esta funcionalidad hace conexión con el navegador web

grabando las acciones y generando scripts para realizar la prueba.

7. Protocolos: son los protocolos de comunicación que puede capturar y

emular la aplicación. Entre ellos los más comunes son HTTP 1.0/1.1,

HTTPS (SSL). Normalmente esta es una característica básica en este tipo

de aplicaciones, pero termina siendo una ventaja entre unas y otras por el

uso de proxy http o HTTPS.

8. Monitoreo de base de datos: funcionalidad propia de las aplicaciones que

se conectan a los motores de base de datos de la aplicación web y permite

visualizar su comportamiento en términos de rendimiento y uso de recursos

a medida que se ejecuta la prueba.

9. Manejador de Cookies: son archivos temporales donde se guarda

información sobre la sesión de usuarios. Cuando se hacen las pruebas de

rendimiento estos archivos son esenciales, ya que si no es soportado por la

herramienta se presentan errores de denegación de servicios que no

reflejan nada en los resultados de las pruebas.

10. Escalabilidad de usuarios: permite generar un número de usuarios virtuales

de acuerdo a los recursos disponibles en la maquina en la que se ejecuta la

prueba.

50

# NOMB

RE OPENST

A

WEB LOAD AND

PERFORMANCE LOAD

TESTING

JMETER JCRAWLER TESTMAK

ER vPERFOR

MER WAPT NETSPARKER

1 Dirección url

http://opensta.org

www.gomez.com

http://jakarta.apache.or

g/jmeter

http://jcrawler.sourcefo

rge.net/

www.pushtotest.com

www.verisium

.com

www.loadtestingtoo

l.com/

www.mavitunasecuri

ty.com

2 Tipo de

licencia/precio

FREEWARE – OPENSOURCE

Licencia

ilimitada

US$20000

FREEWARE – OPEN

SOURCE

FREEWARE - OPENSOURC

E

FREEWARE – OPEN

SOURCE

TIENE DOS

VERSIONES:

COMMUNITY - ENTERP

RISE

US$995.00 (50

UV). US$59

95 (200 UV). Para

más de 200 UV poners

e en contacto con

la empres

a

TIENE DOS

VERSIONES. CON

PRECIOS DE

US$350 – US$700

TIENE 3 VERSIONE

S: COMMUN

ITY (GRATIS),

ESTÁNDAR (US$1000)

, PROFESSI

ONAL (US$3000)

LA LICENCIA

DE USO ES POR

SUSCRIPCION ANUAL

3 Plataform

a

WINDOWS

Windows,

Linux, Solaris

MLTIPLATAFORMA

MULTIPLATAFORMA

MULTIPLATAFO

RMA

Windows

WINDOWS

WINDOWS

4 Manejo de

perfiles de usuar

ios virtuales

SI SI SI SI SI SI SI NO ESPECIFIC

A

5 Soporte IP Spoofing

NO NO SI NO ESPECIFICA

NO NO SI SI

6 Proxy HTTP

SI SI SI SI SI SI SI SI

7 Proto HTTP HTTP, HTTP HTTP HTTP HTTP HTTP, HTTP.

51

# NOMB

RE OPENST

A

WEB LOAD AND

PERFORMANCE LOAD

TESTING

JMETER JCRAWLER TESTMAK

ER vPERFOR

MER WAPT NETSPARKER

colos 1.0/1.1 –

HTTPS

HTTPS 1.0/1.1 – HTTPS

1.0/1.1 – HTTPS

HTTPS HTTPS

8 Monitoreo

de bases

de datos

NO NO NO NO ESPECIFICA

NO SI SI SI

9 Manejador de

Cookies

SI SI SI SI SI SI SI SI

10

Escalabilidad de usuar

ios

SI NO ESPECI

FICA

SI NO ESPECIFICA

NO ESPECIF

ICA

SI SI NO ESPECIFIC

A

Tabla 4: Análisis comparativo de herramientas

52

7. CONCLUSIONES

Las pruebas de software, como parte de los planes de aseguramiento de la calidad, ofrecen a las empresas desarrolladoras la posibilidad de detectar y remover los defectos que surgen durante el proceso de desarrollo del producto. Los organismos de estandarización ofrecen diferentes formas de implementar los procesos de pruebas, todos ellos basados en ciclos de madurez que permiten la medición y optimización de las mismas. En la búsqueda de la documentación el inconveniente se presentó en la poca documentación existente en nuestro país y en idioma español, pero no represento problema alguno a la hora del estudio de los estándares y de los puntos de vista de empresas del sector, profesionales y experiencias de otras personas sobre el tema. En los últimos tiempos a nivel mundial la competencia por estacionarse en el que tal vez es el mercado más competitivo, la tecnología, con todo lo que esta arrastra, las empresas han centrado sus esfuerzos en brindar productos de software con altos índices de calidad de acuerdo a los estándares y de esta forma satisfacer al usuario final, que a la larga es el que más gana, claro, apartando el factor monetario y la ubicación de la empresa desarrolladora en el mercado competitivo. Llama la atención la cantidad de factores que se evalúan a la hora de seleccionar la herramienta con la cual se van a hacer las pruebas, yo escogí solamente 10 con el fin de mostrar el contraste entre algunas de las herramientas existentes en el mercado. Predecir el comportamiento de una aplicación bajo condiciones específicas como un gran número de usuarios, recursos restringidos o ancho de banda limitado, entre otros, se vuelve en una tarea de suma importancia para los usuarios y para la empresa dueña de la aplicación y es por esto que existen estas herramientas en el mercado.

53

8. BIBLIOGRAFÍA

Ambler, S. W. (2001). The Object Primer. Second Edition. Cambridge, UK: Cambridge University

Press.

Apache Software Foundation. (s.f.). JMeter - Apache JMeter. Recuperado el 20 de Junio de 2010,

de http://jakarta.apache.org/jmeter/

Carnegie Mellon University. (2006). Capability Maturity Model® Integration (CMMI) 1.1.

Koomen, T., & Pol, M. (1999). Test Process Improvement: a Practical Step-by-Step Guide to

Structured Testing. Addison Wesley Longman.

Mavituna Security Ltd. (s.f.). Netsparker. Recuperado el 12 de Junio de 2010, de

http://www.mavitunasecurity.com/

Microsoft Corporation. (2007). Performance Testing Guidance for Web Applications.

Molyneaux, I. (2009). The Art of Application Performance Testing. O’Reilly Media, Inc.

Nguyen, H. (2007). Software Testing 3.0. San Mateo, California.

OpenSTA. (27 de Octubre de 2008). OpenSTA. Recuperado el 30 de Junio de 2010, de

http://opensta.org/

PIATTINI, M., GARCÍA, F., & CABALLERO, I. (2007). Calidad de Sistemas Informaticos. Mexico D.F.:

ALFAOMEGA GRUPO EDITOR.

PushToTest. (s.f.). Software Testing Tools. Recuperado el 30 de Junio de 2010, de

http://www.pushtotest.com/

SoftLogica. (s.f.). WAPT - Web Application Load, Stress and Performance Test. Recuperado el 8 de

Junio de 2010, de http://www.loadtestingtool.com/

The Development Gateway Foundation. (2004). JCrawler. Recuperado el 20 de Junio de 2010, de

http://jcrawler.sourceforge.net/

TMMI Fundation. (2009). Test Maturity Model Integration (TMMi) V. 2.0. Erik van Veenendaal.