Guia Unidad 01 Tecnicas de Prueba Lista

Unidad I Tcnicas de prueba Unidad Curricular Ingeniera de Software II; Modulo: PRUEBAS Y VALIDACION DE SOFTWARE
Contenido
Contenido...............................................................................................................................1 Qu son las pruebas de software?........................................................................................2 Principios de la fase de prueba y validacin de software .....................................................2 Defectos vs fallas en las pruebas de software ......................................................................2 Tipos de defectos de software............................................................................................3 Clases equivalentes................................................................................................................4 Pruebas de Limites ................................................................................................................4 Pruebas de caja blanca...........................................................................................................5 Mtodo de prueba de caja blanca del camino bsico .......................................................5 ................................................................................................................................................7 ................................................................................................................................................9 ................................................................................................................................................9 Mtodo de prueba de caja blanca de condiciones.............................................................9 Mtodo de prueba de caja blanca de bucles....................................................................10 Pruebas estructurales ...........................................................................................................11 Pruebas de caja negra...........................................................................................................12 Estrategias de prueba ..........................................................................................................12 ..............................................................................................................................................12 Prueba de unidad .............................................................................................................12 Prueba de integracin ......................................................................................................13 Prueba de validacin .......................................................................................................13 Prueba de sistema ............................................................................................................13 Perfil de la especificacin de prueba ..............................................................................14 Revisin y validacin del software......................................................................................15 Qu son las herramientas para pruebas de Software? .....................................................17
1 Profesor: Alfonso Galea Bracho
En esta unidad se tiene como objeto establecer los conceptos y fundamentos involucrados en las tcnicas de pruebas de software donde el alumno entender: Qu son la pruebas de software?; Principios de la fase de prueba y validacin 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 revisin y validacin 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 validacin del desarrollo de un sistema de informacin y son un conjunto de herramientas tcnicas y mtodos que tienen como objeto comprobar los requerimientos establecidos con los usuarios o beneficiarios del producto. Estas tcnicas tienen como objeto detectar problemas y son extensamente variadas y van desde el uso del ingenio por parte del personal de pruebas hasta herramientas automticas que ayudan a aliviar el peso y el costo de esta actividad. Las pruebas no pueden asegurar la ausencia de errores; slo puede demostrar que existen defectos en el software.
Principios de la fase de prueba y validacin de software

En la aplicacin de las pruebas de software es necesario tener en cuenta lo siguientes principios.
Antes de generar algn cdigo es necesario planificar y disear las pruebas Una parte necesaria de la prueba es la definicin de los resultados esperados los cuales tienen que estar en concordancia con los requerimientos establecidos. Se debe comenzar las pruebas con mdulos 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 organizacin 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 invlidas e inesperadas.
Defectos vs fallas en las pruebas de software

En la fase de prueba y validacin de software se debe de entender lo que son defectos y fallas en los software a continuacin sus definiciones. Defecto: de software (computer bug en ingls), son los comportamientos no deseados por resultado de un fallo o deficiencia durante el proceso de creacin 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 ms evidentes se dan en la etapa de desarrollo y programacin. Es as Si falla = discrepancia visible al ejecutar un programa con un defecto. Entonces Una falla es el sntoma 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 continuacin se relacionan algunos tipos defectos
Tipos de defectos de software

1. REQUERIMIENTOS 1.1 Requerimientos incorrectos 1.2 Requerimientos Lgicos 1.3 Requerimientos, Completitud 1.5 Presentacin, Documentacin 1.6 Cambios en los requerimientos 2. CARACTERSTICAS Y FUNCIONALIDAD 2.1 Correccin de caracterstica/funcionalidad 2.2 Caractersticas completas 2.3 Casos funcionales completos 2.4 Defectos del dominio 2.5 Mensajes de usuario y diagnstico 2.6 Mal manejo de las condiciones de excepcin 2.9 Otros defectos funcionales 3. DEFECTOS ESTRUCTURALES 3.1 Control de flujo y secuencia 3.2 Procesamiento 4. DATOS 4.1 Definicin y estructura de datos 4.2 Manipulacin y acceso de datos 4.9 Otros problemas de datos 5. IMPLEMENTACIN Y CDIFICACIN 5.1 Codificacin y tipografa 5.2 Estilo y violacin de estndares 5.3 Documentacin 5.9 Otros aspectos de implementacin 6. INTEGRACIN 6.1 Interfaces internas 6.2 Interfaces externas, sincronizacin, rendimiento 6.9 Otros aspectos de integracin 7. SISTEMA, ARQUITECTURA DE SOFTWARE 7.1 Usos y llamadas al sistema operativo 7.2 Arquitectura de software 7.3 Recuperacin y responsabilidad 3 Profesor: Alfonso Galea Bracho
7.4 Funcionamiento 7.5 Diagnstico incorrecto, excepciones 7.6 Particiones, capas 7.7 Generacin del sistema ,Ambiente 8. DEFINICIN DE PRUEBAS Y EJECUCIN 8.1 Defectos en el diseo de pruebas 8.2 Defectos en la ejecucin de pruebas 8.3 Pruebas de documentacin 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 vlidos o invlidos para condiciones de entrada en los casos de pruebas. A continuacin un ejemplo Ejemplo: Aplicacin bancaria en la que el operador debe proporcionar un cdigo, un nombre y una operacin. Condicin de Entrada Cdigo de rea # de 3 dgitos que no empieza con 0 ni 1: Nombre Para identificar la operacin Clases Vlidas Clases Invlidas 2) Cdigo < 200. 3) Cdigo > 999. 4) No es nmero. 6) Menos de 6 caracteres. 7) Ms de 6 caracteres. 12) Ninguna orden vlida
1) 200 cdigo 999
5) Seis caracteres. 8) Cheque 9) Depsito 10) Pago factura 11)Retiro de fondos
Orden Una de las Siguientes
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 eleccin de casos de prueba "en los bordes" o lmites establecidos. En lugar de centrarse solamente en las condiciones de entrada, las pruebas de lmites derivan casos tambin para el campo de salida. A continuacin los aspectos a considerar en este tipo de pruebas. 1. Si una condicin de entrada especifica un rango delimitado por los valores a y b, se deben disear 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 condicin de entrada especifica un nmero de valores, se deben desarrollar casos de prueba que ejerciten los valores mximo y mnimo. Tambin se deben probar los valores justo por debajo del mximo y del mnimo. 3. Aplicar las directrices 1 y 2 a las condiciones de salida. 4 Profesor: Alfonso Galea Bracho
4. Si las estructuras de datos internas tienen lmites preestablecidos hay que asegurarse de disear un caso de prueba que ejercite la estructura de datos en sus lmites
Pruebas de caja blanca

Son pruebas con acceso al cdigo fuente (datos y lgica). Se trabaja con entradas, salidas y el conocimiento interno. A continuacin algunas de sus caractersticas.
Por lo menos se prueban una vez todos los caminos independientes de cada mdulo o unidad de software. Se prueban todas las decisiones lgicas en sus vertientes verdadera y falsa de cada mdulo o unidad de software. Se prueban todos los bucles en sus lmites y con sus lmites operacionales de cada mdulo o unidad de software. Se prueba todas las estructuras internas de datos para asegurar su validez para cada mdulo o unidad de software.
Mtodo de prueba de caja blanca del camino bsico

Es una tcnica propuesta inicialmente por Tom McCabe, que permite al diseador de casos de prueba obtener una medida de la complejidad lgica de un diseo procedimental. Y permite usar esa medida como gua para la definicin de un conjunto bsico de caminos de ejecucin. Los casos de prueba obtenidos del conjunto bsico garantizarn que durante la prueba se ejecuta por lo menos una vez cada sentencia del programa. Algunos elementos y conceptos utilizados alrededor de ste mtodo son los siguientes: Grafo de flujo o grafo del programa: Representa el flujo de control lgico de un programa y se utiliza para trazar ms fcilmente las caminos de ste. Cada nodo representa una o ms 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 mximo una sentencia de decisin (bifurcacin). Aristas: lneas 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 regin ms. Nodos predicado: cuando en una condicin aparecen uno o ms operadores lgicos (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
Figura No. 2 Ejemplo de conversin a grafos de flujo
La complejidad ciclomtica de un grafo de flujo V(G) establece el nmero de caminos independientes. Puede calcularse de tres formas alternativas:
El nmero de regiones del grafo de flujo V(G) = A - N + 2, donde A es el nmero de aristas y N es el nmero de nodos V(G) = P + 1, donde P es el nmero de nodos predicado
Ejemplo de clculo de complejidad ciclomtica
Es as como este mtodo 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 lgico, es decir, verdadera y falsa. Ejecutando todos los bucles en sus lmites operacionales y ejercitando las estructuras internas de datos. Ejemplo de tratamiento de condiciones compuestas
Pasos para realizar las pruebas del camino bsico: 1. 2. 3. 4. A partir del diseo o del cdigo fuente, dibujar el grafo de flujo asociado Se calcula la complejidad ciclomtica del grafo Se determina un conjunto bsico de caminos independientes Se preparan los casos de prueba que obliguen a la ejecucin de cada camino del conjunto bsico
A continuacin un ejemplo de la aplicacin de los pasos.
Mtodo de prueba de caja blanca de condiciones

Prueba los tipos de errores que pueden aparecer en una condicin: Existe un error en un operador lgico Existe un error en un parntesis lgico Existe un error en un operador relacional Existe un error en una expresin aritmtica
Mtodo de prueba de caja blanca de bucles

Pruebas para Bucles simples (Ver figura No. 3) (n es el nmero mximo de iteraciones permitidos por el bucle). En este mtodo 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
Figura No. 3 Para las pruebas de Bucles Anidados (Ver figura No. 4), sus objetivos son los siguientes Comenzar en el bucle ms interior estableciendo los dems bucles en sus valores mnimos Realizar las pruebas de bucle simple para el ms interior manteniendo los dems en sus valores mnimos Avanzar hacia fuera confeccionando pruebas para el siguiente bucle manteniendo todos los externos en los valores mnimos y los dems bucles anidados en sus valores tpicos Continuar el proceso hasta haber comprobado todos los bucles
Figura No 4 Pruebas para Figura No 5) Bucles concatenados (Ver
Siempre que los bucles concatenados sean independientes se puede aplicar lo relativo a bucles simples/anidados. En caso de ser dependientes se evaluarn como bucles anidados
Figura No 5
Pruebas para Bucles no estructurados (Ver Figura No. 6) Siempre que se usen los mecanismos que aporta la programacin estructurada, este tipo de bucles no estarn presentes
Figura No. 6
Pruebas estructurales
Las pruebas estructurales son de tipo caja blanca y son una aproximacin al diseo de casos de prueba en donde las pruebas se derivan a partir del conocimiento de la estructura e implementacin del software, tomando en cuenta los siguientes aspectos.
Pruebas de caja negra

Se basa en pruebas funcionales sin acceso al cdigo 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 inicializacin y terminacin. En fin todos aquellos errores que se pueden detectar conociendo y accediendo al cdigo fuente.
Estrategias de prueba
Las pruebas del software en el proceso de desarrollar Sistemas de Informacin se aplican similar a una espiral (Ver Figura No. 7). Donde la estrategia se ejecuta movindonos de adentro hacia a fuera. La PRUEBA DE UNIDAD comienza en el vrtice de la espiral y se centra en cada unidad del software, tal como est implementada en cdigo fuente. La prueba avanza para llegar a la PRUEBA DE INTEGRACIN, donde el foco de atencin es el diseo y construccin de la arquitectura del software. Otra vuelta hacia afuera encontramos la PRUEBA DE VALIDACIN, donde se validan los requisitos establecidos como parte del anlisis de requisitos del software, comparndolos 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 verificacin en la menor unidad del diseo: el mdulo (Clases en el paradigma orientado a objeto). Usando la descripcin del diseo detallado como gua. Se prueban los caminos de control importantes, con el fin de descubrir errores dentro del mdulo. Tambin se prueba la interfase para asegurar que la informacin fluye de forma adecuada hacia y desde la unidad del programa que est siendo probada. Adems se examinan las estructuras de datos locales para asegurar que los datos que se mantienen temporalmente conservan su integridad durante la ejecucin del algoritmo. Se prueban las CONDICIONES LMITE para asegurar que el mdulo funciona correctamente con los lmites establecidos. Se ejercitan TODOS los caminos independientes de la estructura de control para asegurar que 12 Profesor: Alfonso Galea Bracho
todas las sentencias del mdulo se ejecuten por lo menos una vez. Y finalmente SE PRUEBAN TODOS LOS CAMINOS de manejo de errores.
Prueba de integracin
Si todos los mdulos funcionan bien luego de las pruebas de unidad por qu dudar de que funcionen bien juntos ?. El problema es "ponerlos juntos". La prueba de integracin detecta errores de interaccin. El procedimiento adecuado se llama integracin incremental con el cual se construye y se prueba en pequeos segmentos en los que los errores son ms fciles de aislar y corregir Un plan general de integracin y una descripcin de las pruebas especficas deben quedar documentados en una ESPECIFICACIN DE PRUEBA, es parte esencial del proceso de ingeniera de software y forma parte de la configuracin del software
Prueba de validacin
Una vez ensamblado como paquete probamos la validacin, la cual se logra cuando el software funciona de acuerdo con las expectativas razonables del cliente. Estas expectativas estn definidas en la especificacin de requisitos que describe los atributos del software visibles al usuario, basado en los criterios de validacin de dicho documento. La prueba de validacin 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 caractersticas de funcionamiento de rendimiento estn de acuerdo con las especificaciones y son aceptables, se descubre una desviacin 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 ms lugares de clientes y usuarios finales. En la ALFA el desarrollador observa, en la BETA es una aplicacin 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 versin del producto de software para toda la base de cliente
Prueba de sistema
Constituida por una serie de pruebas diferentes cuyo propsito es ejercitar profundamente el sistema. Entre pruebas de sistema tenemos: Prueba de recuperacin: Se fuerza el fallo del software de muchas formas y verifica que la recuperacin se lleva a cabo apropiadamente. Se evala la correccin de re inicializacin, mecanismos de recuperacin del estado del sistema, recuperacin de datos y re arranque. Prueba de seguridad: intenta verificar que los mecanismos de proteccin del sistema lo protegern adecuadamente. Prueba de resistencia: Est diseada para enfrentar a los programas con situaciones anormales, es decir, ejecuta un sistema de forma que demande recursos en cantidad, frecuencia volmenes anormales. Una variacin 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 ejecucin. Se da en todos los pasos del proceso de prueba Prueba de configuracin : Por medio de la configuracin se le da a conocer al software con que parmetros 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 datos o la direccin de nuestro proveedor de correo electrnico. Para sistemas complejos se debe desarrollar el Software Configuration Management
Existen aplicaciones que soportan una variedad de configuraciones, incluyendo varios tipos y nmeros de dispositivos de entrada-salida y lneas de comunicaciones, o diversos tamaos de memoria. Con frecuencia el nmero de configuraciones posibles es demasiado grande para probarlas todas, pero en lo posible, se debe probar el programa con la configuracin mnima y mxima Si el SOFTWARE por s mismo se puede configurar para omitir componentes, o si puede funcionar en diversas computadoras, cada configuracin posible de este debe ser probada. Prueba de compatibilidad: COMPATIBILIDAD caracterstica que presenta los sistemas informticos 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 informacin a travs 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 operacin esperado. Pueden ayudar a las compaas a averiguar si sus productos funcionaran inclusive en plataformas diferentes. Este tipo de pruebas se trabaja en conjunto con el equipo tcnico del cliente para desarrollar planes de pruebas que permitan verificar sistemticamente todas las funciones principales de una aplicacin en diferentes configuraciones y detectar incompatibilidades con estndares y funcionalidades especificadas. Prueba de Sitios WEB: En este tipo de prueba se evala la usabilidad del servicio, entendiendo por esto como la utilidad, facilidad de uso y satisfaccin de los usuarios del sitio Web. Se llevan a cabo dos tipos de pruebas: Evaluacin heurstica, realizada por expertos en el rea de interfaces hombre-mquina para la Web, buscan la satisfaccin del usuario. Test de usabilidad con usuarios reales mientras ejecutan tareas especficas 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 satisfaccin del usuario en el sitio Web
Perfil de la especificacin 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 integracin. 1. Propsito. 2. Mdulos a ser probados. B. Pruebas de unidad para los mdulos de la subfase. 1. Descripcin de pruebas para el mdulo M. 2. Descripcin del software adicional. 3. Resultados esperados. C. Entorno de prueba. 1. Herramientas o tcnicas especiales. 2. Descripcin del software adicional. D. Datos de los casos de prueba. E. Resultados esperados para la subfase N. IV. Resultados de prueba obtenidos. V. Referencias. VI. Apndices.
El alcance de prueba resume las caractersticas funcionales, de rendimiento y diseo interno especficas a probar. Se limita el esfuerzo de prueba, se describen criterios de terminacin de cada fase de prueba y se documentan las limitaciones del plan. El plan de prueba describe la estrategia general para la integracin. Se divide en fases y subfases. En todas las fases se siguen los siguientes criterios: Integridad de interfase, validez funcional, contenido de la informacin y rendimiento. La seccin de procedimiento de prueba describe detalladamente el procedimiento de prueba requerido para llevar a cabo el plan de prueba, describiendo el orden de integracin 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 informacin es vital para el mantenimiento del software.
Revisin y validacin del software

Es as como en la revisin nos preguntamos Estamos construyendo el producto correctamente? Donde el software debera ajustarse a su especificacin. Y en la validacin se pregunta Estamos construyendo el producto correcto? Donde el software debera hacer lo que el cliente realmente reclama. Es as como en la validacin 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 inspeccin de software, las actividades son las siguientes (Ver Figura No.8)
Se hace una visin de conjunto del sistema presentndose al equipo de inspeccin.
Los cdigos y documentos asociados se distribuyen al equipo de inspeccin por adelantado. La inspeccin tiene lugar y se anotan los errores encontrados. Se hacen modificaciones para reparar los errores descubiertos. Se hace una evaluacin que requerirse o no una re inspeccin. Figura No. 8 Proceso de Inspeccin
Las Inspecciones de software se caracterizan por lo siguiente: Implican que las personas examinen la representacin de la fuente con el propsito de descubrir anomalas y defectos 15 Profesor: Alfonso Galea Bracho
No requieren la ejecucin de un sistema por lo que debe utilizarse antes de la implementacin. Pueden estar aplicados a cualquier representacin del sistema (requerimientos, diseo, configuracin, datos, pruebas de datos, u otros). Se ha demostrado que es una tcnica efectiva para descubrir errores del programa Pueden descubrirse muchos diferentes defectos en una sola inspeccin. Al probar, un defecto puede enmascarar a otro as que se requieren varias ejecuciones. Las inspecciones y pruebas son complementarias y no tcnicas opuestas de verificacin. Las inspecciones pueden comprobar el ajuste con una especificacin pero no la conformancia con los requerimientos reales del cliente. Las inspecciones no pueden comprobar caractersticas no funcionales como rendimiento, usabilidad, y otros. Est pensado explcitamente para la deteccin de defectos (no su correccin) Los defectos pueden ser errores lgicos, anomalas en el cdigo que pueden indicar una condicin errnea (p.ej: una variable no iniciada) o no conformidad con los estndares. Regularmente la inspeccin debera utilizarse una lista de errores comunes para guiar la inspeccin Estas listas de errores dependen del lenguaje de programacin y reflejan los errores caractersticos que es probable que aparezcan en el lenguaje. En general cuanto ms dbil sea la comprobacin del tipo, ms grande ser la lista..Ejemplos: inicializacin, nombramiento de constantes, terminacin de bucles, lmites de vectores y otros.
Caractersticas de las precondiciones de la inspeccin. Debe haber una especificacin precisa disponible. Los miembros del equipo deben estar familiarizados con los estndares de organizacin. Debe estar disponible un cdigo sintcticamente correcto u otras representaciones del sistema. Debera prepararse una lista de errores. La gestin debe aceptar que la inspeccin aumentar los costes pronto en el proceso de software. La gestin no debera utilizar inspecciones para la evaluacin del personal, es decir, para encontrar quin comete errores. Entre roles en el proceso de inspeccin se encuentran los siguientes. Autor propietario Inspector o El programador o diseador responsable de generar el programa o documento. Responsable de reparar los defectos descubiertos durante el proceso de inspeccin. Encuentra errores, omisiones e inconsistencias en los programas y documentos. Tambin puede identificar cuestiones ms generales que estn fuera del mbito del equipo de inspeccin. Presenta el cdigo o documento en una reunin de inspeccin Registra los resultados de la reunin de inspeccin o Gestiona el proceso y facilita la inspeccin. Realiza un informe de los resultados del proceso para el moderador jefe. Responsable de las mejoras del proceso de inspeccin, actualizacin de las listas de comprobacin, estndares de desarrollo, etc.
Lector Secretario Presidente moderador Moderador jefe Puntos claves
La revisin y la validacin no son lo mismo. La revisin muestra el ajuste con la especificacin; La validacin 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 renen 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 desempeo del software Mejoran los procesos de gestin del ciclo de vida de los productos Sirven para llevar a cabo anlisis 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 comercializacin porque permiten detectar con eficacia los problemas funcionales, de desempeo 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 manipulacin y procesamiento Hay que tener extremo cuidado de no pasar por alto la funcionalidad de inyeccin de fallos, que puede servir para detectar las debilidades que no son aparentes con las rutas de cdigo tpicas -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 obstculo que sus equipos no podrn resolver fcilmente
Por qu usar el Centro de evaluacin 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 dems requisitos 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 http://www.sip.gob.mx/noticias-sobre-desarrollo-web/793-las-primeras-10-herramientasgratuitas-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 http://www.technologyevaluation.com/search/for/herramientas-de-prueba.html Demand Management RFP Template Gestin de la demanda Reporte de evalucin de software BPM RFP Template El JMeter es una herramienta libre, adems es una herramienta Java, que permite realizar pruebas de Rendimiento y pruebas Funcionales sobre Aplicaciones Web JUnit (http://www.junit.org/) (Java) NUnit (entorno .NET) Anlisis de cobertura de cdigo: Clover http://www.cenqua.com Software testing tools FAQ http://www.testingfaqs.org/ Software QA Testing and Test Tool Resources http://www.aptest.com/resources.html
Bibliografa y enlaces recomendados

Pressman, Roger S. 2006, Ingeniera del Software: Un enfoque prctico, Sexta edicin, Mxico DF, Editorial McGraw Hill. Sommerville Ian, 2005, Ingeniera del Software, Stima edicin, Mxico DF, Editorial Pearson. http://standards.ieee.org/reading/ieee/std_public/description/se/610.121990_desc.html http://www.sip.gob.mx/noticias-sobre-desarrollo-web/793-las-primeras-10-herramientas-gratuitasde-prueba-de-velocidad-de-sitios-web Otras herramientas de prueba http://www.technologyevaluation.com/search/for/herramientas-de-prueba.html
Unidad I TECNICAS DE PRUEBA Unidad Curricular Ingeniera de Software II; Modulo: PRUEBA Y VALIDACION DE SOFTWARE
MINISTERIO POPULAR PARA LA EDUCACION SUPERIOR UNIVERSIDAD POLITECNICA MARACAIBO MARACAIBO EDO. ZULIA DEPARTAMENTO DE INFORMATICA. UNIDAD CURRICULAR: Ingeniera de Software II MDULO: PRUEBA Y VALIDACION DE SOFTWARE
GUIA DE LA UNIDAD I TECNICAS DE PRUEBA
PROFESOR: ALFONSO R. GALEA BRACHO

Guia Unidad 01 Tecnicas de Prueba Lista

Încărcat de

Informații document

Descriere originală:

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Guia Unidad 01 Tecnicas de Prueba Lista

Încărcat de

Drepturi de autor:

Formate disponibile

Unidad I Tcnicas de prueba Unidad Curricular Ingeniera de Software II; Modulo: PRUEBAS Y VALIDACION DE SOFTWARE

1 Profesor: Alfonso Galea Bracho

Qu son las pruebas de software?

Principios de la fase de prueba y validacin de software

Defectos vs fallas en las pruebas de software

2 Profesor: Alfonso Galea Bracho

Tipos de defectos de software

1) 200 cdigo 999

5) Seis caracteres. 8) Cheque 9) Depsito 10) Pago factura 11)Retiro de fondos

Orden Una de las Siguientes

Pruebas de caja blanca

Mtodo de prueba de caja blanca del camino bsico

5 Profesor: Alfonso Galea Bracho

Figura No. 2 Ejemplo de conversin a grafos de flujo

Ejemplo de clculo de complejidad ciclomtica

6 Profesor: Alfonso Galea Bracho

7 Profesor: Alfonso Galea Bracho

A continuacin un ejemplo de la aplicacin de los pasos.

8 Profesor: Alfonso Galea Bracho

Mtodo de prueba de caja blanca de condiciones

9 Profesor: Alfonso Galea Bracho

Mtodo de prueba de caja blanca de bucles

Figura No 4 Pruebas para Figura No 5) Bucles concatenados (Ver

11 Profesor: Alfonso Galea Bracho

Pruebas de caja negra

13 Profesor: Alfonso Galea Bracho

Perfil de la especificacin de prueba

14 Profesor: Alfonso Galea Bracho

Revisin y validacin del software

Se hace una visin de conjunto del sistema presentndose al equipo de inspeccin.

Lector Secretario Presidente moderador Moderador jefe Puntos claves

16 Profesor: Alfonso Galea Bracho

Qu son las herramientas para pruebas de Software?

Sobre los riesgos de estas herramientas, se encuentran las siguientes:

17 Profesor: Alfonso Galea Bracho

Bibliografa y enlaces recomendados

18 Profesor: Alfonso Galea Bracho

GUIA DE LA UNIDAD I TECNICAS DE PRUEBA

PROFESOR: ALFONSO R. GALEA BRACHO

S-ar putea să vă placă și