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

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.............................. 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, Rendimie nto, pruebas de carga y estrés .................................. ................. ................................... ................................... ....................... ...... 31

5.3.

Las pruebas de rendimiento rendimient o 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. 5.4.1.

MÉTODOS PARA REALIZAR PRUEBAS DE RENDIMIENTO .............................. 33 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...................... comparativo............................... ................... ................... .................. .............. ..... 49 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 ANÁ LISIS COMPARATIVO DE HERRAMIENTAS HERRAMIENT AS..................................................... . 51

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.

9

1. OBJETIVOS 1.1.

OBJETIVO GENERAL

Construir el estado del del arte de métodos, métodos, tipos de 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.

10

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.

11

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.

12

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)

13

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

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.

15

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

16

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

17

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.

18

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.

19

PARTE I TRABAJOS EXISTENTES

20

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 clave 2. ÁREAS CLAVE

Estrategia de pruebas

Modelo del ciclo 2

DESCRIPCIÓN 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 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. Dentro del proceso de pruebas se distinguen algunas fases: planeamiento, preparación, diseño, ejecución y terminación.

(Koomen & Pol, 1999)

21

de vida

Momento de involucración

Estimación y planeación

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. 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. 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. Una técnica de diseño de pruebas se define como ―un modelo para derivar 

Técnicas de diseño de pruebas Técnicas de pruebas estáticas

Métricas

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

Herramientas de prueba

Entorno de pruebas

- 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 La ejecución de la prueba tiene lugar en el llamado ―Entorno de Pruebas‖. Este entorno de pruebas consta de los siguientes componentes: 

Hardware

22

   

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. El compromiso y la motivación del personal involucrado en las pruebas son condiciones indispensables para lograr un proceso de pruebas ―maduro‖. El

Compromiso y motivación

Funciones de prueba y capacitación

Alcance de la metodología

Comunicación

Informes Manejo de defectos Administración de Testware

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

23

Administración del proceso de pruebas Revisión estructurada

Pruebas de caja blanca

erróneas de programas, etc. Una buena administración de estos productos incrementa la factibilidad de pruebas (y por ende la calidad) del software. 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 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. 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.

24

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.

25

Grafica 3: Modelo TMMi

Grafica 2: Modelo CMMI Grupo Tecnis

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 información a las personas que están usando los 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)

26

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

27

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 la mejora y evaluación de los procesos de desarrollo y mantenimiento de sistemas y productos de software.

Los dos primeros documentos 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.

28

PARTE II ESTADO DEL ARTE

29

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)

30

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, respuesta, estas miden que tan bien o no una aplicación provee un servicio al usuario final.

5

(Molyneaux, 2009)

31

Los indicadores orientados a eficiencia son rendimiento y utilización, 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.

32

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 Objetos para el Ciclo 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. agiles/evolutivos. La razón por la la que presento FLOOT de una forma ―tradi cional‖ es para volver explicito el hech o 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)

33

Grafica 4: Aseguramiento de la calidad 1

Técnica FLOOT

Descripción prueba verifica que el ítem que se está probando, Prueba de Caja- La cuando se dan las entradas apropiadas produce los Negra resultados esperados. Prueba de Es la prueba de situaciones extremas o inusuales que el Valores-Frontera ítem debe ser capaz de manejar. Prueba de Es el acto de asegurar que una clase y todas sus instancias cumplen con el comportamiento definido. Clases Prueba de Es el acto de asegurar que las clases, y sus instancias, Integración de conforman un software que cumple con el comportamiento Clases definido. Una forma de revisión técnica en la que el entregable que Revisión de Código se revisa en el código fuente. Prueba de Es el acto de validar que un componente funciona tal como Componente está definido. Prueba de Es el acto de asegurar que toda línea de código es ejercita Cubrimiento al menos una vez. Revisión de Una revisión técnica en la cual se inspecciona un modelo de Diseño diseño. Prueba de Es el acto de ejecutar casos de prueba de las súper clases, Regresión de tanto de forma directa como indirecta, en una subclase especifica. Herencia Prueba de Consiste en realizar pruebas para verificar que un gran 34

conjunto de partes del software funcionan juntas. Consiste en realizar pruebas para verificar que un método (función miembro) funciona tal como está definido. Un tipo de inspección, que puede ser desde una revisión técnica formal hasta un recorrido informal, realizado por Revisión de Modelos personas diferentes a las que estuvieron directamente involucradas en el desarrollo del modelo. Prueba de Es el acto de asegurar que todos los caminos lógicos en el Caminos código se ejercitan al menos una vez. Es un proceso mediante el cual los usuarios trabajan a través de una colección de casos de uso, utilizando un Revisión de prototipo como si fuera el sistema real. El objetivo principal Prototipos es probar si el diseño del prototipo satisface las necesidades de esos usuarios. La mejor forma de determinar si un u n modelo realmente refleja Demostrar con el lo que se necesita, o lo que se debe construir, es construyendo software basado en el modelo para mostrar código que el modelo está bien. El acto de asegurar que los comportamientos previamente Prueba de probados todavía trabajan como se espera luego que se Regresión han realizado cambios a la aplicación. El acto de asegurar que el sistema funciona como se espera Prueba de Stress bajo grandes volúmenes de transacciones, usuarios, carga y demás. Una técnica de aseguramiento de la calidad en la cual el diseño de tu aplicación es revisado de forma exhaustiva por grupo de tus compañeros. Una revisión típicamente se Revisión Técnica un 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. Una técnica de prueba en la cual una o más personas Prueba de Escenarios de validan un modelo siguiendo la lógica de los escenarios de Uso uso. Consiste en probar la interfaz de usuario para garantizar Prueba de que cumple los estándares y requerimientos definidos. Interfaz de Usualmente se refiere a la prueba de interfaz de usuario Usuario gráfica. en realizar pruebas para verificar que líneas Prueba de Caja- Consiste específicas de código funcionan tal como está definido. Blanca También se le conoce como prueba de caja-transparente. Integración Prueba de Método

Tabla 2: Técnicas de Prueba

35

5.5. Metodología de Control de Rendimiento Microsoft (Microsoft Corporation, 2007), 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. 2. 3. 4. 5. 6. 7.

Identificar el entorno de pruebas. Identificar los criterios criterios de aceptación de rendimiento. Planear y diseñar las las pruebas. Configurar el entorno de pruebas. Implementar el diseño de pruebas. Ejecutar las pruebas. 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)

36

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.

37

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 Prueba de rendimiento

Prueba de carga

8

PROPÓSITO Se lleva a cabo para determinar o validar velocidad, escalabilidad y/o estabilidad.

OBSERVACIONES 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. Sirve para verificar el Las pruebas de carga se comportamiento de la realizan para comprobar aplicación en condiciones que la aplicación cumple normales y situaciones con los objetivos especiales. 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

(Microsoft Corporation, 2007)

38

que el punto de ruptura se encuentra por debajo de la carga máxima. Prueba de resistencia. Es

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.

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

39

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.

carga que en ocasiones aumentan mas allá de las operaciones de producción previstas para cortos periodos de tiempo. 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.

40

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.

41

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 con tenido 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.

Grafica 5: Perfiles JMeter

9

(Apache Software Foundation)

42

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.. ade lante.. 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 11

(The Development Gateway Foundation, 2004) (SoftLogica)

43

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

Grafica 6: Interfaz Netsparker

12

(Mavituna Security Ltd.)

44

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, 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 14

(OpenSTA, 2008) (PushToTest)

45

PARTE III ANÁLISIS COMPARATIVO

46

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)

b)

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

c)

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. 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 ca ntidad 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.

48

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 licencia y precio: el tipo de licencia delimita mucho 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 asignarle a los usuarios virtuales 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 s cripts 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. 49

NOMB RE

OPENST A

WEB LOAD AND PERFOR MANCE LOAD TESTIN G

1

Direc ción url

http:// openst a.org

www. gomez .com

http://jakart a.apache.or g/jmeter

http://jcraw ler.sourcefo rge.net/

www.p ushtote st.com

www.v erisium .com

www.load testingtoo l.com/

www.mavi tunasecuri ty.com

2

Tipo de licen cia/p recio

FREEW ARE – OPENS OURCE

Licenci a ilimita da US$20 000

FREEWARE – OPEN SOURCE

FREEWARE OPENSOURC E

FREEW ARE – OPEN SOURCE

TIENE DOS VERSIONE S. CON PRECIOS DE US$350 – US$700

MLTIPLATAF ORMA

MULTIPLATA FORMA

MULTIP LATAFO RMA

TIENE 3 VERSIONE S: COMMUN ITY (GRATIS), ESTÁNDAR (US$1000) , PROFESSI ONAL (US$3000) LA LICENCIA DE USO ES POR SUSCRIPCI ON ANUAL WINDOWS

SI

Windo ws, Linux, Solaris SI

US$99 5.00 (50 UV). US$59 95 (200 UV). Para más de 200 UV poners e en contact o con la empres a Windo ws

SI

SI

SI

SI

SI

NO ESPECIFIC A

NO

NO

SI

NO ESPECIFICA

NO

NO

SI

SI

SI

SI

SI

SI

SI

SI

SI

SI

HTTP HTTP

HTTP HTTP,,

H HTT TTP P

HTTP HTTP

HTTP HTTP

HTTP HTTP

HTTP HTTP,,

HTTP HTTP..

#

3

4

Plata form a

Man ejo de perfil es de usuar ios virtu ales 5 Sopo rte IP Spoo fing 6 Proxy HTTP 7 Prot Proto o

WIND OWS

JMETER

JCRAWLER

TESTMAK ER

vPERFOR MER

WAPT

NETSPARKER

TIENE DOS VERSIO NES: COMM UNITY ENTERP RISE

50

WINDOW S

#

NOMB RE

OPENST A

WEB LOAD AND PERFOR MANCE LOAD TESTIN G

colos

1.0/1.1

HTTPS

1.0/1.1 – HTTPS

HTTPS NO

NO

NO

NO ESPECIFICA

NO

SI

SI

SI

SI

SI

NO ESPECI FICA

SI

NO ESPECIFICA

 –

8

Moni toreo de bases de datos 9 Man ejado r de Cooki es 1 Escal 0 abilid ad de usuar ios

JMETER

JCRAWLER

TESTMAK ER

vPERFOR MER

WAPT

NETSPARKER

HTTPS

HTTPS

SI

SI

SI

SI

SI

SI

SI

NO ESPECIF ICA

SI

SI

NO ESPECIFIC A

1.0/1.1  – HTTPS

Tabla 4: Análisis comparativo de herramientas

51

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.

52

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/ 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 P erformance Test . Recuperado el 8 de Junio de 2010, de http://www.loadtestingtool.com/ 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.

53