Sei sulla pagina 1di 39

PRINCIPIOS DE LAS PRUEBAS

JOHN ANDERSON MOTTA MOSQUERA SARHA SOPHIA SANDOVAL SANDOVAL

CONTENIDO
1. 2. 3. 4. 5. 6. Objetivos Definiciones Mtodos de prueba Niveles de pruebas Tipos de pruebas Principios

1. OBJETIVOS
Probar si el software no hace lo que debe. Probar si el software hace lo que debe hacer, es decir, si provoca efectos secundarios adversos. Descubrir un error que an no ha sido descubierto. Encontrar el mayor nmero de errores con la menor cantidad de tiempo y esfuerzo posibles. Mostrar hasta qu punto las funciones del software operan de acuerdo con las especificaciones y requisitos del cliente.

2. DEFINICIONES
Testing: es la ejecucin de programas de software con el objetivo de detectar defectos y fallas. Test Exitoso: aquel que detecta errores. Test No exitoso: aquel que no los detecta.

Definicines

3. METODOS DE PRUEBA
Test incrementales: Testeo continuo, distribuye las pruebas de integracin en la integracin diaria del cdigo compartido
Top Down: Se formula un resumen del sistema, sin especificar detalles. Cada parte del sistema se refina diseando con mayor detalle.
Mtodos de Prueba

Bottom-up: las partes individuales se disean con detalle y luego se enlazan para formar componentes ms grandes, que a su vez se enlazan hasta que se forma el sistema completo. Caja Negra:

Mtodos de Prueba

Caja Blanca:

Mtodos de Prueba

4. NIVELES DE PRUEBAS
Niveles de pruebas Test Unitario Objetivo Detectar errores en los datos, lgica, algoritmos Detectar errores de interfaces y relaciones entre componentes Participantes Programadores Ambiente Desarrollo Mtodo Caja Blanca Caja Blanca, TopDown,Bottom Up

Integracin

Programadores

Desarrollo

Funcional

Detecta errores implementacin requerimientos

en

la de

Testers, Analistas

Desarrollo

Funcional

Sistema

Detecta fallas en el cubrimiento de los Testers, Analistas requerimientos Detecta fallas implementacin sistema en la del Testers, Analistas, Cliente

Desarrollo

Funcional

Aceptacin

Productivo

Funcional

5. TIPOS DE PRUEBA
Prueba de Regresin
Intentan descubrir errores (bugs), carencias de

funcionalidad, o divergencias funcionales con respecto al comportamiento esperado del software, causados por la realizacin de un cambio en el programa. Utilizar la tcnica top-down.
Tipos de Prueba

Pruebas de Humo
Comprobar que no sale humo del software, es decir el sistema no detecta errores graves que van a impedir el desarrollo previsto del plan de prueba. Realizar una integracin de todo el sistema cada cierto periodo (se recomienda un da, mximo una semana)
Tipos de Prueba

Pruebas de Stress Verificar que el sistema funciona apropiadamente y sin errores. Las pruebas de stress se proponen encontrar errores debidos a recursos bajos o completitud de recursos. Use los scripts utilizados en las pruebas de desempeo.
Tipos de Prueba

Pruebas de desempeo Validar el tiempo de respuesta para las peticiones. Miden tiempos de respuesta, ndices de procesamiento de transacciones y otros requisitos sensibles al tiempo. Modifique archivos de datos (para incrementar el nmero de transacciones) o los scripts para incrementar el nmero de veces que ocurre cada transaccin.
Tipos de Prueba

Pruebas de carga Permiten verificar y validar el desempeo de un elemento de un sistema bajo diferentes condiciones de carga: Nmero de usuarios Nmero de transacciones

Tipos de Prueba

Pruebas de volumen
Las pruebas de volumen hacen referencia a grandes cantidades de datos para determinar los lmites en que se causa que el Sistema falle. Deben usarse mltiples clientes, ya sea corriendo las mismas pruebas o pruebas complementarias para producir el peor caso de volumen.

Tipos de Prueba

Pruebas de Recuperacin y Tolerancia a fallas Verificar que los procesos de recuperacin (manual o automtica) restauran apropiadamente la Base de datos. Estas pruebas aseguran que una aplicacin o sistema se recupere de una variedad de anomalas de hardware, software o red con prdidas de datos o fallas de integridad. Se deben utilizar las pruebas creadas para la Funcionalidad del sistema y Procesos de Negocios para crear una serie de transacciones.
Tipos de Prueba

Prueba de Mltiples Sitios Detectar fallas en configuraciones y comunicaciones de datos entre mltiples sitios. El propsito de esta prueba es evaluar el correcto funcionamiento del sistema o subsistema en mltiples instalaciones.

Tipos de Prueba

Prueba de Compatibilidad y Conversin Buscar problemas de compatibilidad conversin en los sistemas. y

El propsito es demostrar que los objetivos de compatibilidad no han sido logrados y que los procedimientos de conversin no funcionan.

Compatibilidad entre programas y Conversin de datos.


Tipos de Prueba

Pruebas de Integridad de Datos y Base de Datos


Asegurar que los mtodos de acceso y procesos funcionan adecuadamente y sin ocasionar corrupcin de datos. La Base de datos y los procesos de Base de datos deben ser probados como sistemas separados del proyecto.
Invoque cada mtodo de acceso y proceso de la Base de datos, utilizando en cada uno datos vlidos e invlidos. Analizar la BD
Tipos de Prueba

Pruebas de Seguridad y Control de Acceso Nivel de seguridad de la aplicacin: Verifica que un actor solo pueda acceder a las funciones y datos que su usuario tiene permitido Seguridad del sistema, incluyendo acceso a datos o Funciones de negocios e incluyendo accesos remotos. Funciones / Seguridad de Datos: Identificar cada tipo de usuario y las funciones y datos a los que se debe autorizar.
Tipos de Prueba

Pruebas del Ciclo del Negocio


Asegurar que el sistema funciona de acuerdo con el modelo de negocios emulando todos los eventos en el tiempo y en funcin del tiempo. Deberan emular las actividades ejecutadas en el a travs del tiempo. Debera identificarse un periodo, como por ejemplo un ao, y las transacciones y actividades que podran ocurrir durante un periodo
Ejecute cada caso de uso, flujo bsico o funcin utilizando datos vlidos e invlidos.
Tipos de Prueba

Pruebas de GUI (Interfaz grafica de usuario)


La navegacin , Los objetos de la ventana y caractersticas, tales como mens, medidas, posiciones, estados y focos. La prueba de interfaz de usuario verifica la interaccin del usuario con el software. Pruebas de crear / modificar cada ventana para verificar la adecuada navegacin y estado de los objetos.
Tipos de Prueba

Pruebas de Configuracin

Estas pruebas verifican la operacin del sistema en diferentes configuraciones de hardware y software. Incluya la apertura o cierre de varias aplicaciones Microsoft, como Excel y Word (o algn tipo de software similar a la que se esta probando).

Tipos de Prueba

Prueba de Estilo Comprobar que la aplicacin sigue los estndares de estilo propios del cliente. Se entienden como tales el formato de las ventanas, colores corporativos, tipos de letra etc. Se realiza una navegacin por la aplicacin verificando si se cumplen con los estndares de GUI del cliente.
Tipos de Prueba

Prueba de Aceptacin
Determinacin por parte del cliente de la aceptacin o rechazo del sistema desarrollado.

La prueba de aceptacin es ejecutada antes de que la aplicacin sea instalada dentro de un ambiente de produccin. Realizacin de los documentos de planes de prueba de aceptacin y especificacin de los mismos, basados en los criterios de aceptacin del cliente.
Tipos de Prueba

Prueba de Instalacin
Verificar y validar que el sistema se instala apropiadamente en cada cliente, bajo las siguientes condiciones: Instalaciones nuevas y actualizaciones El primero es asegurar que el sistema puede ser instalado en todas las configuraciones posibles .El segundo propsito verificar que, una vez instalado, el sistema opera correctamente. Disear scripts para validar las condiciones de la mquina a instalar .

Prueba de Documentacin Y Procedimiento

Evaluar la documentacin del usuario. Evaluar la exactitud y claridad de la documentacin del usuario y para determinar si el manual de procedimientos trabajar correctamente como una parte integral del sistema. Revisar la documentacin del proyecto contra las funcionalidades del sistema y su configuracin fsica.
Tipos de Prueba

Prueba de Usabilidad

Determinar la usabilidad del sistema. Determina cun bien el usuario podr usar y entender la aplicacin. Identifica las reas de diseo que hacen al sistema de difcil uso para el usuario. Verificar que la aplicacin no presenta los problemas de usabilidad tpicos.
Tipos de Prueba

Prueba de Campo
Correr el sistema en el ambiente real para encontrar errores y validar el producto contra sus especificaciones originales. Realizar un subconjunto vlido de pruebas de sistema. Determinar que pruebas de sistema sern corridas para validar el sistema en produccin.
Tipos de Prueba

6. PRINCIPIOS DE LAS PRUEBAS


1. Las pruebas evidencian la presencia de defectos: El testing puede mostrar la presencia de defectos pero no puede probar que no hay defectos. El testing reduce la probabilidad de que defectos no descubiertos permanezcan en el software. Aunque no se encuentren defectos, esto no es prueba de que no los haya.

2. El testing en forma exhaustiva es imposible: Probar todo no es factible, excepto en casos muy triviales. En lugar de pretender hacer pruebas exhaustivas, se deben realizar anlisis de riesgos y prioridades para centralizar los esfuerzos de las pruebas.

3. Probar en fases tempranas: Comenzar las pruebas al inicio del proyecto de desarrollo del software Realizar test esttico sobre los requerimientos, diseo y cdigo. La correccin de defectos luego de la implementacin del software es muchsimo mas costosa que si estos son detectados durante la elicitacin de los requerimientos.

4. Agrupamiento de los defectos: La mayora de las fallas se originan en unos pocos mdulos Realizar un anlisis del origen de las fallas a partir del testing en fases tempranas Repetir esas pruebas hacia el final del proceso

5. Paradoja del pesticida: Repetir siempre las mismas pruebas, con el correr del tiempo, no har posible hallar nuevos bugs. Los casos de prueba se deben revisar peridicamente para evitar este fenmeno. Se deben escribir nuevos casos de prueba que ejerciten diferentes partes del software para hallar nuevos y mas defectos.

6. Las pruebas son dependientes del contexto: El testing se realiza de forma diferente en contextos diferentes Definir los objetivos de las pruebas segn el contexto Adaptar esos objetivos segn el nivel de riesgo aceptable

7. Falacia de la ausencia de errores: Encontrar y reparar los defectos no ayuda si el sistema desarrollado no cumple con las especificaciones. Tampoco sirve el software desarrollado si el mismo no llena las necesidades y expectativas del usuario.

Talento educadopas desarrollado!!

MUCHAS GRACIAS!

Potrebbero piacerti anche