Contenido. Profesor: Ing. MSc. Eliomar Nieves

Transcripción

1 Contenido Qué son las pruebas de software?... 2 Principios de la fase de prueba y validación de software... 2 Defectos vs fallas en las pruebas de software... 2 Tipos de defectos de software... 2 Clases equivalentes... 4 Pruebas de Limites... 4 Pruebas de caja blanca... 5 Método de prueba de caja blanca del camino básico... 5 Método de prueba de caja blanca de condiciones... 8 Método de prueba de caja blanca de bucles... 9 Pruebas estructurales Pruebas de caja negra Estrategias de prueba Prueba de unidad Prueba de integración Prueba de validación Prueba de sistema Perfil de la especificación de prueba Revisión y validación del software Qué son las herramientas para pruebas de Software?

2 En esta unidad se tiene como objeto establecer los conceptos y fundamentos involucrados en las técnicas de pruebas de software donde el alumno entenderá: Qué son la pruebas de software?; Principios de la fase de prueba y validación de software; Defecto Vs Falla en el desarrollo de software; Que son las clases equivalentes?; En que se fundamentan las pruebas de cajas blanca y cajas negra? ; Que son las pruebas estructurales?; En qué consiste la estrategia de prueba espiral; Qué es la revisión y validación del software? Y finalmente se explicara la que son las herramientas de prueba y su utilidad. Qué son las pruebas de software? Las pruebas de software se aplican en la fase de prueba y validación del desarrollo de un sistema de información y son un conjunto de herramientas técnicas y métodos que tienen como objeto comprobar los requerimientos establecidos con los usuarios o beneficiarios del producto. Estas técnicas tienen como objeto detectar problemas y son extensamente variadas y van desde el uso del ingenio por parte del personal de pruebas hasta herramientas automáticas que ayudan a aliviar el peso y el costo de esta actividad. Las pruebas no pueden asegurar la ausencia de errores; sólo puede demostrar que existen defectos en el software. Principios de la fase de prueba y validación de software En la aplicación de las pruebas de software es necesario tener en cuenta lo siguientes principios. Antes de generar algún código es necesario planificar y diseñar las pruebas Una parte necesaria de la prueba es la definición de los resultados esperados los cuales tienen que estar en concordancia con los requerimientos establecidos. Se debe comenzar las pruebas con módulos individuales y avanzar hasta probar el sistema completo Los resultados de las pruebas se debe revisar en profundidad haciendo un seguimiento hasta los requisitos del cliente. Un programador u organización deben evitar validar sus propios desarrollos, estos deben siempre ser avalados por terceros o clientes solicitantes de los requerimientos. Las pruebas deben incluir casos con entradas inválidas e inesperadas. Defectos vs fallas en las pruebas de software En la fase de prueba y validación de software se debe de entender lo que son defectos y fallas en los software a continuación sus definiciones. Defecto: de software (computer bug en inglés), son los comportamientos no deseados por resultado de un fallo o deficiencia durante el proceso de creación de programas de computadora (software). Falla: Deficiencia o error que puede presentarse en cualquiera de las etapas del ciclo de vida del software aunque los más evidentes se dan en la etapa de desarrollo y programación. Es así Si falla = discrepancia visible al ejecutar un programa con un defecto. Entonces Una falla es el síntoma de un defecto. Es así como para un software se pueden detectar las fallas y manejar las excepciones o no detectarlas y tener comportamientos no deseados o defectos. A continuación se relacionan algunos tipos defectos Tipos de defectos de software 1. REQUERIMIENTOS 2

3 1.1 Requerimientos incorrectos 1.2 Requerimientos Lógicos 1.3 Requerimientos, Completitud 1.5 Presentación, Documentación 1.6 Cambios en los requerimientos 2. CARACTERÍSTICAS Y FUNCIONALIDAD 2.1 Corrección de característica/funcionalidad 2.2 Características completas 2.3 Casos funcionales completos 2.4 Defectos del dominio 2.5 Mensajes de usuario y diagnóstico 2.6 Mal manejo de las condiciones de excepción 2.9 Otros defectos funcionales 3. DEFECTOS ESTRUCTURALES 3.1 Control de flujo y secuencia 3.2 Procesamiento 4. DATOS 4.1 Definición y estructura de datos 4.2 Manipulación y acceso de datos 4.9 Otros problemas de datos 5. IMPLEMENTACIÓN Y CÓDIFICACIÓN 5.1 Codificación y tipografía 5.2 Estilo y violación de estándares 5.3 Documentación 5.9 Otros aspectos de implementación 6. INTEGRACIÓN 6.1 Interfaces internas 6.2 Interfaces externas, sincronización, rendimiento 6.9 Otros aspectos de integración 7. SISTEMA, ARQUITECTURA DE SOFTWARE 7.1 Usos y llamadas al sistema operativo 7.2 Arquitectura de software 7.3 Recuperación y responsabilidad 7.4 Funcionamiento 7.5 Diagnóstico incorrecto, excepciones 3

4 7.6 Particiones, capas 7.7 Generación del sistema,ambiente 8. DEFINICIÓN DE PRUEBAS Y EJECUCIÓN 8.1 Defectos en el diseño de pruebas 8.2 Defectos en la ejecución de pruebas 8.3 Pruebas de documentación 8.4 Casos de prueba incompletos 8.9 Defectos en otros aspectos de pruebas Clases equivalentes Una clase de equivalencia representa establecer en las pruebas un conjunto de estados válidos o inválidos para condiciones de entrada en los casos de pruebas. A continuación un ejemplo Ejemplo: Aplicación bancaria en la que el operador debe proporcionar un código, un nombre y una operación. Condición de Entrada Clases Válidas Clases Inválidas Código de Área # de 3 dígitos que no empieza con 0 ni 1: Nombre Para identificar la operación Orden Una de las Siguientes 1) 200 código 999 5) Seis caracteres. 8) Cheque 9) Depósito 10) Pago factura 11) Retiro de fondos 2) Código < ) Código > ) No es número. 6) Menos de 6 caracteres. 7) Más de 6 caracteres. 12) Ninguna orden válida Con las clases equivalentes se manejan las excepciones (Clases Invalidas) y el flujo principal (Clase validas) de los casos de usos. Pruebas de Limites Este tipo de pruebas consiste en llevar la elección de casos de prueba "en los bordes" o límites establecidos. En lugar de centrarse solamente en las condiciones de entrada, las pruebas de límites derivan casos también para el campo de salida. A continuación los aspectos a considerar en este tipo de pruebas. 1. Si una condición de entrada especifica un rango delimitado por los valores a y b, se deben diseñar casos de prueba para los valores a y b y para valores justo por debajo y justo por encima de a y b 2. Si una condición de entrada especifica un número de valores, se deben desarrollar casos de prueba que ejerciten los valores máximo y mínimo. También se deben probar los valores justo por debajo del máximo y del mínimo. 3. Aplicar las directrices 1 y 2 a las condiciones de salida. 4

5 4. Si las estructuras de datos internas tienen límites preestablecidos hay que asegurarse de diseñar un caso de prueba que ejercite la estructura de datos en sus límites Pruebas de caja blanca Son pruebas con acceso al código fuente (datos y lógica). Se trabaja con entradas, salidas y el conocimiento interno. A continuación algunas de sus características. Por lo menos se prueban una vez todos los caminos independientes de cada módulo o unidad de software. Se prueban todas las decisiones lógicas en sus vertientes verdadera y falsa de cada módulo o unidad de software. Se prueban todos los bucles en sus límites y con sus límites operacionales de cada módulo o unidad de software. Se prueba todas las estructuras internas de datos para asegurar su validez para cada módulo o unidad de software. Método de prueba de caja blanca del camino básico Es una técnica propuesta inicialmente por Tom McCabe, que permite al diseñador de casos de prueba obtener una medida de la complejidad lógica de un diseño procedimental. Y permite usar esa medida como guía para la definición de un conjunto básico de caminos de ejecución. Los casos de prueba obtenidos del conjunto básico garantizarán que durante la prueba se ejecuta por lo menos una vez cada sentencia del programa. Algunos elementos y conceptos utilizados alrededor de éste método son los siguientes: Grafo de flujo o grafo del programa: Representa el flujo de control lógico de un programa y se utiliza para trazar más fácilmente las caminos de éste. Cada nodo representa una o más sentencias procedimentales y cada arista representa el flujo de control. (Ver Figura No. 1 y Figura No. 2). Nodos: representan cero, una o varias sentencias en secuencia. Cada nodo comprende como máximo una sentencia de decisión (bifurcación). Aristas: líneas que unen dos nodos. Regiones: áreas delimitadas por aristas y nodos. Cuando se contabilizan las regiones de un programa debe incluirse el área externa como una región más. Nodos predicado: cuando en una condición aparecen uno o más operadores lógicos (AND, OR, XOR,...) se crea un nodo distinto por cada una de las condiciones simples. Cada nodo generado de esta forma se denomina nodo predicado. Figura No. 1 Ejemplos de grafos de programas o grafos de flujo 5

6 Figura No. 2 Ejemplo de conversión a grafos de flujo La complejidad ciclomática de un grafo de flujo V(G) establece el número de caminos independientes. Puede calcularse de tres formas alternativas: El número de regiones del grafo de flujo V(G) = A - N + 2, donde A es el número de aristas y N es el número de nodos V(G) = P + 1, donde P es el número de nodos predicado Ejemplo de cálculo de complejidad ciclomática 6

7 Es así como este método su idea es confeccionar casos de prueba que garanticen que se verifiquen todos los caminos independientes. Efectuando verificaciones para cada camino independiente, probando sus dos facetas desde el punto de vista lógico, es decir, verdadera y falsa. Ejecutando todos los bucles en sus límites operacionales y ejercitando las estructuras internas de datos. Ejemplo de tratamiento de condiciones compuestas Pasos para realizar las pruebas del camino básico: 1. A partir del diseño o del código fuente, dibujar el grafo de flujo asociado 2. Se calcula la complejidad ciclomática del grafo 3. Se determina un conjunto básico de caminos independientes 4. Se preparan los casos de prueba que obliguen a la ejecución de cada camino del conjunto básico A continuación un ejemplo de la aplicación de los pasos. 7

8 Método de prueba de caja blanca de condiciones Prueba los tipos de errores que pueden aparecer en una condición: Existe un error en un operador lógico Existe un error en un paréntesis lógico Existe un error en un operador relacional Existe un error en una expresión aritmética 8

9 Método de prueba de caja blanca de bucles Pruebas para Bucles simples (Ver figura No. 3) (n es el número máximo de iteraciones permitidos por el bucle). En este método sus objetivos son los siguientes: Pasar por alto totalmente el bucle Pasar una sola vez por el bucle Pasar dos veces por el bucle Hacer m pasos por el bucle con m < n Hacer n-1, n y n + 1 pasos por el bucle Para las pruebas de Bucles Anidados (Ver figura No. 4), sus objetivos son los siguientes Figura No. 3 Comenzar en el bucle más interior estableciendo los demás bucles en sus valores mínimos Realizar las pruebas de bucle simple para el más interior manteniendo los demás en sus valores mínimos Avanzar hacia fuera confeccionando pruebas para el siguiente bucle manteniendo todos los externos en los valores mínimos y los demás bucles anidados en sus valores típicos Continuar el proceso hasta haber comprobado todos los bucles Pruebas para Bucles concatenados (Ver Figura No 5) Siempre que los bucles concatenados sean independientes se puede aplicar lo relativo a bucles simples/anidados. En caso de ser dependientes se evaluarán como bucles anidados Figura No 4 Figura No 5 9

10 Pruebas para Bucles no estructurados (Ver Figura No. 6) Siempre que se usen los mecanismos que aporta la programación estructurada, este tipo de bucles no estarán presentes Figura No. 6 Pruebas estructurales Las pruebas estructurales son de tipo caja blanca y son una aproximación al diseño de casos de prueba en donde las pruebas se derivan a partir del conocimiento de la estructura e implementación del software, tomando en cuenta los siguientes aspectos. 10

11 Pruebas de caja negra Se basa en pruebas funcionales sin acceso al código fuente de las aplicaciones. Se trabaja con entradas y salidas, entre los errores a encontrar con este tipo de pruebas se pueden mencionar los siguientes: Funciones Incorrectas o Ausentes; Errores de Interfaz; Errores en estructuras de datos o acceso a bases de datos externas; Errores de rendimiento; Errores de inicialización y terminación. En fin todos aquellos errores que se pueden detectar conociendo y accediendo al código fuente. Estrategias de prueba Las pruebas del software en el proceso de desarrollar Sistemas de Información se aplican similar a una espiral (Ver Figura No. 7). Donde la estrategia se ejecuta moviéndonos de adentro hacia a fuera. La PRUEBA DE UNIDAD comienza en el vértice de la espiral y se centra en cada unidad del software, tal como está implementada en código fuente. La prueba avanza para llegar a la PRUEBA DE INTEGRACIÓN, donde el foco de atención es el diseño y construcción de la arquitectura del software. Otra vuelta hacia afuera encontramos la PRUEBA DE VALIDACIÓN, donde se validan los requisitos establecidos como parte del análisis de requisitos del software, comparándolos con el sistema que ha sido construido. Finalmente, llegamos a la PRUEBA DEL SISTEMA en la que se prueban como un todo el software y otros elementos del sistema. Figura No 7 Estrategia de prueba tipo espiral Prueba de unidad La prueba de unidad centra el proceso de verificación en la menor unidad del diseño: el módulo (Clases en el paradigma orientado a objeto). Usando la descripción del diseño detallado como guía. Se prueban los caminos de control importantes, con el fin de descubrir errores dentro del módulo. También se prueba la interfase para asegurar que la información fluye de forma adecuada hacia y desde la unidad del programa que está siendo probada. Además se examinan las estructuras de datos locales para asegurar que los datos que se mantienen temporalmente conservan su integridad durante la ejecución del algoritmo. Se prueban las CONDICIONES LÍMITE para asegurar que el módulo funciona correctamente con los límites 11

12 establecidos. Se ejercitan TODOS los caminos independientes de la estructura de control para asegurar que todas las sentencias del módulo se ejecuten por lo menos una vez. Y finalmente SE PRUEBAN TODOS LOS CAMINOS de manejo de errores. Prueba de integración Si todos los módulos funcionan bien luego de las pruebas de unidad por qué dudar de que funcionen bien juntos?. El problema es "ponerlos juntos". La prueba de integración detecta errores de interacción. El procedimiento adecuado se llama integración incremental con el cual se construye y se prueba en pequeños segmentos en los que los errores son más fáciles de aislar y corregir Un plan general de integración y una descripción de las pruebas específicas deben quedar documentados en una ESPECIFICACIÓN DE PRUEBA, es parte esencial del proceso de ingeniería de software y forma parte de la configuración del software Prueba de validación Una vez ensamblado como paquete probamos la validación, la cual se logra cuando el software funciona de acuerdo con las expectativas razonables del cliente. Estas expectativas están definidas en la especificación de requisitos que describe los atributos del software visibles al usuario, basado en los criterios de validación de dicho documento. La prueba de validación se lleva a cabo con pruebas de la caja negra que demuestran la conformidad con los requisitos. Una vez probado cada caso pueden darse dos condiciones: las características de funcionamiento ó de rendimiento están de acuerdo con las especificaciones y son aceptables, ó se descubre una desviación de las especificaciones y se crea una lista de deficiencias Se pueden realizar pruebas ALFA Ó BETA, la prueba alfa es conducida por un cliente en el lugar de desarrollo; la prueba beta en uno ó más lugares de clientes y usuarios finales. En la ALFA el desarrollador observa, en la BETA es una aplicación en vivo en un entorno que no controla el desarrollador. Como resultado el equipo de desarrollo de software lleva a cabo modificaciones y así prepara una versión del producto de software para toda la base de cliente Prueba de sistema Constituida por una serie de pruebas diferentes cuyo propósito es ejercitar profundamente el sistema. Entre pruebas de sistema tenemos: Prueba de recuperación: Se fuerza el fallo del software de muchas formas y verifica que la recuperación se lleva a cabo apropiadamente. Se evalúa la corrección de re inicialización, mecanismos de recuperación del estado del sistema, recuperación de datos y re arranque. Prueba de seguridad: intenta verificar que los mecanismos de protección del sistema lo protegerán adecuadamente. Prueba de resistencia: Está diseñada para enfrentar a los programas con situaciones anormales, es decir, ejecuta un sistema de forma que demande recursos en cantidad, frecuencia ó volúmenes anormales. Una variación de esta prueba es la prueba de sensibilidad, utilizando datos que produzcan inestabilidad ó procesamiento incorrecto. Prueba de rendimiento: Prueba el rendimiento del software en tiempo de ejecución. Se da en todos los pasos del proceso de prueba Prueba de configuración : Por medio de la configuración se le da a conocer al software con que parámetros debe trabajar. Por ejemplo, los nombres de las personas que pueden usar el software, como verificar su clave de ingreso, la ruta donde se encuentran los archivos con 12

13 datos o la dirección de nuestro proveedor de correo electrónico. Para sistemas complejos se debe desarrollar el Software Configuration Management Existen aplicaciones que soportan una variedad de configuraciones, incluyendo varios tipos y números de dispositivos de entrada-salida y líneas de comunicaciones, o diversos tamaños de memoria. Con frecuencia el número de configuraciones posibles es demasiado grande para probarlas todas, pero en lo posible, se debe probar el programa con la configuración mínima y máxima Si el SOFTWARE por sí mismo se puede configurar para omitir componentes, o si puede funcionar en diversas computadoras, cada configuración posible de este debe ser probada. Prueba de compatibilidad: COMPATIBILIDAD característica que presenta los sistemas informáticos que pueden funcionar conjuntamente de manera correcta. El mejor ejemplo de la compatibilidad es la de los PCs, que pueden conectarse perfectamente y que permiten el intercambio de información a través de las aplicaciones que corren, en ellos sin problemas. Estas ayudan a determinar, si el producto funcionará correctamente con otro hardware y/o software en el entorno de operación esperado. Pueden ayudar a las compañías a averiguar si sus productos funcionaran inclusive en plataformas diferentes. Este tipo de pruebas se trabaja en conjunto con el equipo técnico del cliente para desarrollar planes de pruebas que permitan verificar sistemáticamente todas las funciones principales de una aplicación en diferentes configuraciones y detectar incompatibilidades con estándares y funcionalidades especificadas. Prueba de Sitios WEB: En este tipo de prueba se evalúa la usabilidad del servicio, entendiendo por esto como la utilidad, facilidad de uso y satisfacción de los usuarios del sitio Web. Se llevan a cabo dos tipos de pruebas: Evaluación heurística, realizada por expertos en el área de interfaces hombre-máquina para la Web, buscan la satisfacción del usuario. Test de usabilidad con usuarios reales mientras ejecutan tareas específicas en el sitio Web que analizamos. En este caso, se definimos el plan del Test, llevamos a cabo un Test piloto y finalmente realizamos el Test real a partir del cual sacamos conclusiones que nos indican la eficiencia, eficacia y satisfacción del usuario en el sitio Web Perfil de la especificación de prueba Las pruebas deben ser documentadas, un perfil o contenido de estos documentos puede ser el siguiente. I. Alcance de la prueba. II. Plan de prueba. A. Fases de prueba. B. Agenda. C. Software adicional. D. Entorno y recursos. III. Procedimiento de prueba N. A. Orden de integración. 1. Propósito. 2. Módulos a ser probados. B. Pruebas de unidad para los módulos de la subfase. 1. Descripción de pruebas para el módulo M. 2. Descripción del software adicional. 3. Resultados esperados. C. Entorno de prueba. 1. Herramientas o técnicas especiales. 2. Descripción del software adicional. D. Datos de los casos de prueba. E. Resultados esperados para la subfase N. 13

14 IV. Resultados de prueba obtenidos. V. Referencias. VI. Apéndices. El alcance de prueba resume las características funcionales, de rendimiento y diseño interno específicas a probar. Se limita el esfuerzo de prueba, se describen criterios de terminación de cada fase de prueba y se documentan las limitaciones del plan. El plan de prueba describe la estrategia general para la integración. Se divide en fases y subfases. En todas las fases se siguen los siguientes criterios: Integridad de interfase, validez funcional, contenido de la información y rendimiento. La sección de procedimiento de prueba describe detalladamente el procedimiento de prueba requerido para llevar a cabo el plan de prueba, describiendo el orden de integración y las pruebas de cada fase. Asimismo se incluye un listado de todos los casos de prueba y resultados esperados. En los resultados de prueba obtenidos se registran los resultados reales de prueba obtenidos, problemas y peculiaridades. Esta información es vital para el mantenimiento del software. Revisión y validación del software Es así como en la revisión nos preguntamos Estamos construyendo el producto correctamente? Donde el software debería ajustarse a su especificación. Y en la validación se pregunta Estamos construyendo el producto correcto? Donde el software debería hacer lo que el cliente realmente reclama. Es así como en la validación puede revelar la presencia de errores NO su ausencia y comprueban los requerimientos no funcionales ya que el software tiene que ser ejecutado para ver su comportamiento. En el proceso de inspección de software, las actividades son las siguientes (Ver Figura No.8) Se hace una visión de conjunto del sistema presentándose al equipo de inspección. Los códigos y documentos asociados se distribuyen al equipo de inspección por adelantado. La inspección tiene lugar y se anotan los errores encontrados. Se hacen modificaciones para reparar los errores descubiertos. Se hace una evaluación que requerirse o no una re inspección. Figura No. 8 Proceso de Inspección 14

15 Las Inspecciones de software se caracterizan por lo siguiente: Implican que las personas examinen la representación de la fuente con el propósito de descubrir anomalías y defectos No requieren la ejecución de un sistema por lo que debe utilizarse antes de la implementación. Pueden estar aplicados a cualquier representación del sistema (requerimientos, diseño, configuración, datos, pruebas de datos, u otros). Se ha demostrado que es una técnica efectiva para descubrir errores del programa Pueden descubrirse muchos diferentes defectos en una sola inspección. Al probar, un defecto puede enmascarar a otro así que se requieren varias ejecuciones. Las inspecciones y pruebas son complementarias y no técnicas opuestas de verificación. Las inspecciones pueden comprobar el ajuste con una especificación pero no la conformancia con los requerimientos reales del cliente. Las inspecciones no pueden comprobar características no funcionales como rendimiento, usabilidad, y otros. Está pensado explícitamente para la detección de defectos (no su corrección) Los defectos pueden ser errores lógicos, anomalías en el código que pueden indicar una condición errónea (p.ej: una variable no iniciada) o no conformidad con los estándares. Regularmente la inspección debería utilizarse una lista de errores comunes para guiar la inspección Estas listas de errores dependen del lenguaje de programación y reflejan los errores característicos que es probable que aparezcan en el lenguaje. En general cuanto más «débil» sea la comprobación del tipo, más grande será la lista..ejemplos: inicialización, nombramiento de constantes, terminación de bucles, límites de vectores y otros. Características de las precondiciones de la inspección. Debe haber una especificación precisa disponible. Los miembros del equipo deben estar familiarizados con los estándares de organización. Debe estar disponible un código sintácticamente correcto u otras representaciones del sistema. Debería prepararse una lista de errores. La gestión debe aceptar que la inspección aumentará los costes pronto en el proceso de software. La gestión no debería utilizar inspecciones para la evaluación del personal, es decir, para encontrar quién comete errores. Entre roles en el proceso de inspección se encuentran los siguientes. Autor propietario Inspector Lector Secretario o El programador o diseñador responsable de generar el programa o documento. Responsable de reparar los defectos descubiertos durante el proceso de inspección. Encuentra errores, omisiones e inconsistencias en los programas y documentos. También puede identificar cuestiones más generales que están fuera del ámbito del equipo de inspección. Presenta el código o documento en una reunión de inspección Registra los resultados de la reunión de inspección Presidente moderador o Gestiona el proceso y facilita la inspección. Realiza un informe de los resultados del proceso para el moderador jefe. 15

16 Moderador jefe Responsable de las mejoras del proceso de inspección, actualización de las listas de comprobación, estándares de desarrollo, etc. Puntos claves La revisión y la validación no son lo mismo. La revisión muestra el ajuste con la especificación; La validación muestra que el programa cumple las necesidades del cliente. Las inspecciones del programa son muy efectivas para descubrir errores. Qué son las herramientas para pruebas de Software? Estas ayudan a los equipos de desarrollo de software a investigar los errores de software y verificar la funcionalidad de los sistemas y asegurarse de que el software que desarrollan es seguro y confiable. Existen herramientas especiales para cada una de las etapas de un proyecto de desarrollo de software. Algunos proveedores ofrecen una serie integrada que da soporte tanto a las pruebas como al desarrollo de software durante todo un proyecto, desde que se reúnen los requisitos hasta que se inicia el funcionamiento en vivo del sistema. Sin embargo, hay otros proveedores que se concentran en una parte del ciclo de desarrollo de aplicaciones. Entre algunas ventajas de las herramientas para pruebas de software, se encuentran las siguientes: Mejoran la calidad de las aplicaciones de software Miden el desempeño del software Mejoran los procesos de gestión del ciclo de vida de los productos Sirven para llevar a cabo análisis de riesgo y pruebas comparativas Ayudan a uniformizar los procedimientos de pruebas, gracias a que son herramientas de pruebas automatizadas (en lugar de pruebas manuales, que pueden producir resultados inconstantes) Mejoran los periodos de comercialización porque permiten detectar con eficacia los problemas funcionales, de desempeño y de seguridad Generan ahorros en los costos de desarrollo y mantenimiento del software Sobre los riesgos de estas herramientas, se encuentran las siguientes: Las pruebas automatizadas pueden involucrar grandes cantidades de datos. La herramienta que seleccione debe ser capaz de transformar estos datos para facilitar su manipulación y procesamiento Hay que tener extremo cuidado de no pasar por alto la funcionalidad de inyección de fallos, que puede servir para detectar las debilidades que no son aparentes con las rutas de código típicas -particularmente, las rutas que son propensas a sufrir ataques a la seguridad Seleccionar la herramienta de software incorrecta presenta dos desventajas importantes; por un lado, se gastan tiempo y recursos, y por el otro, se genera un obstáculo que sus equipos no podrán resolver fácilmente Por qué usar el Centro de evaluación de herramientas para pruebas de software?, entre algunas razones se encuentran las siguientes: Se debe seleccionar la herramienta para pruebas de software que mejor se adapte a su ambiente de desarrollo y pruebas de software Asegurarse de que la herramienta seleccionada es la correcta para su presupuesto, su conjunto de habilidades y sus demás requisitos 16

17 Se debe descubrir qué herramientas para pruebas le dan el justo valor por el precio. Una herramienta para pruebas de software que imita las pruebas manuales no podrá identificar todos los riesgos Las primeras 10 herramientas gratuitas de prueba de velocidad de sitios web 1. FreeSpeedTest.com 2. WebSiteOptimization.com 3. Rapid Search Metrics 4. Aptimize.com 5. Pingdom Tools 6. iwebtools.com 7. Website Goodies 8. WebToolHub.com 9. Web-Inspect.com 10. HooverWebDesign Otras herramientas Demand Management RFP Template Gestión de la demanda Reporte de evalución de software BPM RFP Template El JMeter es una herramienta libre, además es una herramienta Java, que permite realizar pruebas de Rendimiento y pruebas Funcionales sobre Aplicaciones Web JUnit ( (Java) NUnit (entorno.net) Análisis de cobertura de código: Clover Software testing tools FAQ Software QA Testing and Test Tool Resources Bibliografía y enlaces recomendados Pressman, Roger S. 2006, Ingeniería del Software: Un enfoque práctico, Sexta edición, México DF, Editorial McGraw Hill. Sommerville Ian, 2005, Ingeniería del Software, Sétima edición, México DF, Editorial Pearson. Otras herramientas de prueba 17

18 Unidad I TECNICAS DE PRUEBA Unidad Curricular Ingeniería de Software II; Modulo: PRUEBA Y VALIDACION DE SOFTWARE MINISTERIO POPULAR PARA LA EDUCACION SUPERIOR UNIVERSIDAD POLITECNICA DEL GUÀRICO GUÀRICO DEPARTAMENTO DE INFORMATICA. UNIDAD CURRICULAR: Ingeniería de Software II MÓDULO: PRUEBA Y VALIDACION DE SOFTWARE GUIA DE LA UNIDAD I TECNICAS DE PRUEBA PROFESOR: ING. MSC ELIOMAR NIEVES