Contenido. Tipos y niveles de pruebas de software Pruebas de caja negra



Documentos relacionados
Técnicas de prueba 1. FUNDAMENTOS DE LA PRUEBA DEL SOFTWARE

Ingeniería de Software. Pruebas

Elementos requeridos para crearlos (ejemplo: el compilador)

Aseguramiento de la Calidad, QA. Materia: Desarrollo Industrial de Software Alumno: David Alejandro González Díaz y Froylan Ruiz Cirilo.

Plan de estudios ISTQB: Nivel Fundamentos

PRUEBAS DE SOFTWARE TECNICAS DE PRUEBA DE SOFTWARE

GESTION OPERATIVA. Niveles de gestión

Ingeniería del Software I Clase de Testing Funcional 2do. Cuatrimestre de 2007

Hoy terminamos caja blanca

Empresa Financiera Herramientas de SW Servicios

ISO 9001:2015 Cuestionario de autoevaluación

Guía Metodológica para el diseño de procesos de negocio

1. Descripción y objetivos

Estándares para planes de calidad de software. Escuela de Ingeniería de Sistemas y Computación Desarrollo de Software II Agosto Diciembre 2008

Estas visiones de la información, denominadas vistas, se pueden identificar de varias formas.

Técnicas Avanzadas de Testing Automatizado

Beatriz Pérez. Jornada de Testing en Vivo - 1, 2, 3 probando!

GUIA SOBRE LOS REQUISITOS DE LA DOCUMENTACION DE ISO 9000:2000

TESTING. Universidad Simón Bolívar. Ing. de Software. Profa. Marlene Goncalves

Charter de la A.I.S.E. para una Limpieza sostenible

PLAN DE PRUEBAS SISTEMA DE GESTIÓN HOSPITALARIA. Plan de Pruebas. File: QA-INF-V2-PLAN DE PRUEBAS.odt STD-INF-GENERAL Versión: 1.

SIIGO Pyme. Análisis de Rentabilidad y Participación. Cartilla I

ACTUALIZACIÓN A LA NORMA ISO

Sistemas de Información Administrativo - Universidad Diego Portales. Cátedra : Sistemas de Información Administrativa S.I.A.

6.4 ESTRATEGIAS DE PRUEBA

LEGISLACION Y NORMATIVAS COMO FACTORES DETERMINANTES DE LA CALIDAD DEL SOFTWARE

PROCEDIMIENTO ELABORACIÓN Y CONTROL DE DOCUMENTOS

GUÍA 14 Diseño de Planes y Programas. Descripción

QUÉ ES LA ISO 14000? DIFERENCIAS ENTRE ISO Y EMAS. 1 Para Mayor información

Metodología básica de gestión de proyectos. Octubre de 2003

PROCEDIMIENTO DE MANTENIMIENTO PREVENTIVO Y CORRECTIVO PROCESO GESTIÓN TECNOLÓGICA

Testing. Tipos, Planificación y Ejecución de Pruebas

SIIGO Pyme. Informes de Activos Fijos. Cartilla I

Calidad Escuela de Ingeniería de Sistemas y Computación Desarrol o de Software II Agosto Diciembre 2007

SIIGO Pyme. Informes de Saldos y Movimientos de Inventarios. Cartilla I

GUÍA DE SERVICIOS El puesto requiere desarrollar una variedad de actividades de oficina y/o aspectos técnicos.

Proceso Unificado de Rational PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes:

SIIGO Pyme. Informes de Liquidación de Comisiones. Cartilla I

NORMA DE ADMINISTRACIÓN DE INCIDENTES DE SEGURIDAD

PRC-DTI-006 Administración de Roles de los Sistemas de Información de la DTI Procedimiento Dirección de TI - COSEVI

INFORME TÉCNICO PREVIO DE EVALUACIÓN DE SOFTWARE

3. GESTIÓN DE CONFIGURACIÓN DE SOFTWARE

capitulo3 MARCO TEÓRICO Para el diseño de la reubicación de los procesos se hará uso de la Planeación

Marco Normativo de IT

INFORME Nº1 PROPUESTA METODOLÓGICA Y PLAN DE TRABAJO DESARROLLO DE UN SISTEMA INTEGRADO DE GESTIÓN PARA EL GOBIERNO REGIONAL DE ATACAMA

SISTEMAS DE INFORMACIÓN III TEORÍA

Traducción del. Our ref:

Criterios de clasificación

IBM Global Services España, S.A C/ Mar Adriático, 2 San Fernando de Henares MADRID. Servicios IBM de Soporte Técnico Remoto

Ingeniería del Software. Pruebas. Pruebas en el PUD. Las pruebas del software. Tipos de prueba Estrategias de prueba

Manual de usuario clientes portal web KRCC. Fecha:

Versión: 01. Fecha: 01/04/2013. Código: F004-P006-GFPI GUÍA DE APRENDIZAJE Nº 5 1. IDENTIFICACIÓN DE LA GUIA DE APRENDIZAJE

Guía de Preparación de Muestras para PLASTICOS para el Software de Formulación de Datacolor

Modelo para el Aseguramiento de Calidad en el Desarrollo de Software Libre

Inter American Accreditation Cooperation. Grupo de prácticas de auditoría de acreditación Directriz sobre:

PROCEDIMIENTO COMPRAS, SELECCIÓN Y EVALUACIÓN DE PROVEEDORES

PROCEDIMIENTO DE COMPRA DE MATERIAL Y SERVICIOS

Conciliación bancaria en CheqPAQ Cargado de estado de cuenta

Tabla de contenido. Someter hojas de Horario 3. Hoja de registro para IVR 11

NOTAS TÉCNICAS SOBRE EL SIT: Definición y Configuración de Usuarios

CONTROL DE DOCUMENTOS

INDICADORES DE DIAGNOSTICO, SEGUIMIENTO EVALUACIÓN Y RESULTADOS. ELEMENTOS CONCEPTUALES PARA SU DEFINICIÓN Y APLICACIÓN

NORMA INTERNACIONAL DE AUDITORÍA 720 CONTENIDO

PROCESO ADMINISTRACIÓN DE RECURSOS TECNOLÓGICOS SUBPROCESO ADMINISTRACIÓN DE CONTINGENCIAS

Instituto Nacional de Conservación y Desarrollo Forestal, Áreas Protegidas y Vida Silvestre

ESTRUCTURA ARCHIVOS PARA EL INGRESO DE CUENTAS PDI (Tipo P)

Diseño orientado al flujo de datos

Tecnológico de Estudios Superiores de Coacalco. Instituto Tecnológico Superior de Comalcalco, Fresnillo, Santiago Papasquiaro y Zapopan.

PROPÓSITO... 2 DETERMINANTES PARA UNA BUENA EXPERIENCIA DE USO...

Adelacu Ltda. Fono Graballo+ Agosto de Graballo+ - Descripción funcional - 1 -

Instructivo para el análisis y solución de problemas

Capítulo 4 Pruebas e implementación de la aplicación CAPÍTULO 4 PRUEBAS E IMPLEMENTACIÓN DE LA APLICACIÓN

Prueba de software. Ingeniería de software Eduardo Ferreira, Martín Solari

INSTITUTO NACIONAL DE SEGUROS DIRECCIÓN DE INFORMÁTICA. Manual de Usuario de Automóvil Individual -Emisión- Versión: 2

PRUEBAS, CALIDAD Y MANTENIMIENTO DEL SOFTWARE

-OPS/CEPIS/01.61(AIRE) Original: español Página Estructura del programa de evaluación con personal externo

PROCESO DE GESTION DE ALMACEN DE MANTENIMIENTO DEL SISTEMA MACROBÚS

LINEAMIENTOS ESTÁNDARES APLICATIVOS DE VIRTUALIZACIÓN

Guía de Normas de Correcta Fabricación de Medicamentos de Uso Humano y Veterinario. Anexo 11: Sistemas informatizados

LINEAMIENTOS PARA LA ELABORACIÓN DEL PROGRAMA ANUAL DE TRABAJO

PROCEDIMIENTO OPERATIVO DESARROLLAR SISTEMAS INFORMÁTICOS PDO-COCTI-DTIN-04

SIIGO Pyme. Definición Plan Único de Cuentas. Cartilla I

Este procedimiento aplica a todos aquellos estudios y diseños a ser realizados por el AMCO para el desarrollo de sus proyectos.

QUE PASA CON LOS CERTIFICADOS VIGENTES EN ISO 9001:2000 AL MOMENTO DE QUE ENTRE LA VERSIÓN 2008?

DOCUMENTACIÓN DE LAS PRUEBAS DE INTEGRACIÓN

Plan de Gestión de Configuración. Universidad Nacional de la Patagonia Austral

Bloqueo/Etiquetado 1

AVA-RPSystem. Introducción Características del producto Especificaciones Técnicas

Orientación acerca de los requisitos de documentación de la Norma ISO 9001:2000

Plan de tarificación. Redes telefónicas. Requisitos a cumplir por el plan.

Aseguramiento de la calidad y pruebas de software 5- Pruebas del software Estándar IEEE-829 Standard for Software Test Documentation

SSTQB. Nivel Fundamentos. Examen ejemplo. Programa de estudios 2010

Proceso: AI2 Adquirir y mantener software aplicativo

CMMI (Capability Maturity Model Integrated)

2 Métodos combinatorios

Solutions ÑAIKOTEVẼVA RYRU. VERSIÓN 1, Feb.

SOLUCIÓN CASO GESTIÓN DE PERSONAL I

CONSEJO DE NORMALIZACIÓN Y CERTIFICACIÓN DE COMPETENCIA LABORAL NORMAS TÉCNICAS DE COMPETENCIA LABORAL

Dirección General de Educación Superior Tecnológica

Transcripción:

Hoy, la caja negra Aseguramiento de la calidad y pruebas de software 5- Pruebas del software Niveles y Caja Negra Blanca A. Vargas Govea vargasgovea@itesm.mx Marzo 1, 2013

Contenido Tipos y niveles de pruebas de software Pruebas de caja negra 2

Tipos de pruebas Estructural El tester examina la estructura interna del programa y la lógica. Funcional Caja Blanca. El tester prueba el programa con base en las salidas esperadas. No conoce la estructura interna. Caja Negra. 3

Niveles de pruebas 1. Unitarias 2. de Integración Stress testing 3. del Sistema Performance 4. de Aceptación Usabilidad 5. de Regresión 6. Beta 4

1. Pruebas unitarias Es la prueba de software que se hace generalmente en una clase o componente, una función. Documentos: código, diseño de bajo nivel. Tipo: Caja Blanca. Testers: desarrolladores. 5

2. Pruebas de Integración Los componentes de software son combinados y probados para evaluar la integración entre ellos. Documentos: diseño de bajo y alto nivel Tipo: Caja negra/caja Blanca. Testers: desarrolladores. 6

3. Pruebas del Sistema El sistema se prueba como un todo para evaluar si cumple con los requerimientos. Documentos: diseño de alto nivel, especificación de requerimientos. Tipo: Caja negra. Testers: desarrolladores. 7

3.1 Stress testing Se evalúa el sistema más allá de los límites de sus especificaciones. Se está desarrollando un sistema para cajas registradoras. Un requerimiento dice que se podrán operar simultáneamente 30 cajas. Se ejecutan pruebas automáticas con 34 cajas durante 12 horas contínuas para ver si el sistema excede sus requerimientos. 8

3.2 Performance Se evalúa si el sistema o componente cumple con las especificaciones. En la prueba de cajas registradoras el requerimiento decía que la búsqueda de precios la completan en menos de 1 segundo. Las pruebas evalúan si el sistema cumple aún con 30 cajas operando simultáneamente. 9

3.3 Usabilidad Evalúa el alcance en el cual el usuario puede aprender a operar, preparar entradas e interpretar salidas de un sistema o componente. Se selecciona un grupo de personal de caja para hacer pruebas de usabilidad. Estas pruebas no son automáticas. 10

4. Pruebas de Aceptación Determinan si el sistema satisface o no el criterio de aceptación establecido por el usuario. Documentos: especificación de requerimientos. Tipo: Caja Negra. Testers: aunque el cliente es el que evalúa si se acepta o no, los desarrolladores son responsables de realizar las pruebas previamente. 11

5. Pruebas de Regresión Probar contínuamente el sistema o componente para verificar que las modificaciones no han causado efectos inesperados. Tipo: Caja Blanca/Caja Negra. Testers: desarrolladores. Documentos: cambios en la documentación, diseño de alto nivel. 12

6. Beta Cuando se tiene una versión completa o muy cercana se da a usuarios beta que reportarán los errores. Documentos: ninguno. Tipo: Caja Negra. Testers: usuarios beta. 13

Los tipos de pruebas en los seis niveles Caja Blanca Caja Negra 14

Técnicas de Caja Negra Partición equivalente Caja Negra Análisis de límites Transición de estados Oráculo (adivinación) 15

Objetivo de las técnicas Escoger un conjunto apropiado de entradas a partir del conjunto total de posibles entradas válidas e inválidas. Yo quiero probar con todas Limitación de tiempo y recursos para pruebas exhaustivas. 16

Partición equivalente Consiste en particionar el dominio de entrada del software que se está probando. La idea es que un valor de entrada de la clase de equivalencia sea representativa del conjunto completo. Dos pruebas son equivalentes si son tan parecidas que es redundante hacer ambas. 17

Cómo identificar particiones equivalentes? A partir de condiciones de entrada interesantes. Existen guías para seleccionar las clases Es un proceso heurístico en el que se deben considerar clases de equivalencia válidas e inválidas. No siempre es sencillo identificarlas. 18

Guías 1. Si la entrada es un rango de valores, selecciona una clase válida que cubra un rango permitido y dos clases de equivalencia inválida, una fuera de cada extremo del rango. Ejemplo: suponer que la especificación dice que la longitud de un widget en mm está en el rango de 100-499 Clase 1 Clase 2 Clase 3 100-499 Valores < 100 Valores > 499 19

Guías Ejemplo: edades en el perfil de usuario. Especificación: 12-70 años Clase 1 Clase 2 Clase 3 12-70 Valores < 12 Valores > 70 Problemas experimentados al no probar estos valores. Información inútil. Consecuente pérdida de tiempo en el análisis. 20

Guías Ejemplos proyecto 21

Guías 2.Si las entradas se especifican como un número de valores, selecciona Una clase válida que incluya el número de valores permitidos. Dos clases inválidas que estén fuera de los dos extremos. Ejemplo: una casa puede tener de 1 a 4 propietarios. Clase 1 Clase 2 Clase 3 1-4 Valor < 4 Valor > 4 22

Guías Ejemplos proyecto 23

Guías 3.Si las entradas se especifican como un conjunto de valores, seleccionar una clase que contenga a todos los miembros válidos. una clase inválida que contenga valores distintos al conjunto permitido. Ejemplo: el conjunto válido de colores está formado por ROJO, AZUL, VERDE Clase 1 Clase 2 ROJO, AZUL,VERDE ROSA, AMARILLO 24

Guías 4. Si una condición de entrada especifica que una condición que debe-ser, selecciona una clase que representa la condición debe ser y una clase inválida que no la incluya. Ejemplo: el primer caracter de un identificador debe ser una letra. Clase 1 Clase 2 TC3044 9C3044 25

Guías Ejemplos proyecto 26

Actividad 12 - Equipo Con base en tu proyecto, describir 6 ejemplos de partición de equivalencia y elabora una tabla para cada ejemplo con las posibles clases que identificas. Enviar por correo o entregar por escrito. 27

Tarea 12 - Individual Define las clases de equivalencia para las siguiente descripciones de módulos: 1. El módulo es parte de un sistema de membresía de TV. El módulo permite como entrada una contribución de $0.01 a $99,999.99. También recibe el estatus del miembro que puede tomar valores de: regular, estudiante y retirado. 2. El módulo es componente de un cajero automático. El módulo lee la cantidad que el usuario desea desea retirar de su cuenta. La cantidad debe ser un múltiplo de $5.00 y debe ser menor que o igual a $200.00. 28