Pruebas de Software - ITSPA

5/10/2018 Pruebas de Software - ITSPA - slidepdf.com

http://slidepdf.com/reader/full/pruebas-de-software-itspa 1/37

Pruebas de Software

Sistemas de Información II

ITSPA – ISC Alfredo Ayala Ortega



Definición de Prueba

¤ Testing: es el proceso orientado a demostrar que unprograma no tiene errores.

¤ Testing: es la tarea de demostrar que un programa realizalas funciones para las cuales fue construido.

¤ Testing: es la tarea de probar que un programa realiza loque se supone debe hacer. Aún haciendo lo esperado,

puede contener errores.

¤ Testing: es la ejecución de programas de software con elobjetivo de detectar defectos y fallas. Proceso destructivo,sádico.



Otras definiciones

¤ Error: una equivocación de una persona al desarrollar alguna actividad de desarrollo de software.

¤ Defecto: se produce cuando una persona comete un error.

¤ Falla: es un desvío respecto del comportamiento esperadodel sistema, puede producirse en cualquier etapa

¤ Notas:

¤ Defecto es una vista interna, lo ven los desarrolladores. Fallaes una vista externa, la ven los usuarios.



Costos



Principios

¤ Una parte necesaria de un test es la definición de los

resultados esperados

¤ Un programador debe evitar probar su propio desarrollo

¤ Una organización no debe probar sus propios desarrollos

¤ Revise los resultados de los test en profundidad

¤ Los test deben incluir entradas inválidas e inesperadas así como las válidas y esperadas



Principios

¤ Revisar un programa para verificar que hace lo que se

espera que haga es sólo la mitad de la prueba; la otramitad consiste comprobar que no haga lo que no seespera

¤ No tirar los test a la basura a menos que el programa seabasura

¤ No planear esfuerzos de pruebas asumiendo que no seencontrarán errores



Principios

¤ La probabilidad de encontrar errores en una sección de

un programa es proporcional al número de errores yaencontrados en esa sección

¤ El “test ing” const ituye una tarea creativa eintelectualmente desafiante



El proceso de pruebas en el ciclo devida

¤ El estándar ISO/IEC 12207 (ISO/IEC 1995) identifica tres

grupos de procesos en el ciclo de vida software:¤ Procesos principales

¤ Procesos de la organización

¤ Procesos de soporte o auxiliares

¤ No define, como vemos, un proceso de Pruebas comotal, sino que aconseja, durante la ejecución de losprocesos principales o de la organización, utilizar losprocesos de soporte.



Pruebas

¤ Entre éstos se encuentran los procesos de Validación y

de Verificación:¤ El proceso de Validación tiene como objetivo determinar si

los requisitos y el sistema final cumplen los objetivos para losque se construyó el producto, respondiendo así a lapregunta ¿el producto es correcto?

¤ El proceso de Verificación intenta determinar si los

productos software de una actividad se ajustan a losrequisitos o a las condiciones impuestas en actividadesanteriores. De este modo, la pregunta a la que respondeeste proceso es ¿se está construyendo el productocorrectamente?



UNA ESTRATEGIA DE PRUEBA DEL SW ¤ La prueba en el contexto de espiral



Niveles de Prueba

¤ Test Unitarios

¤ Test de Componentes / Test de Integración

¤ Test de Funcionalidad

¤ Test de Sistema

¤ Test de Aceptación

¤ Test de Instalación



Modelo Tradicional



Modelo Actual



Niveles de prueba



Tipo de Pruebas

Pruebas Unitarias

¤ Hacen uso intensivo de técnicas de prueba de caja blanca.

¤ Se prueba la interfaz del módulo (Primero que todo, si nofunciona, NO seguir. Verificar que la información llega y salede manera correcta).

¤ Estructuras de datos locales (datos se conservan íntegrosdurante la ejecución).



Tipo de Pruebas

Pruebas Unitarias

¤ Condiciones límites. (Caminos de control para asegurar quese ejecutan al menos una vez; luego se prueban todos loscaminos de manejo de errores).

¤ Validez Funcional.



Tipo de Pruebas

Pruebas de integración

¤ Usa fundamentalmente técnicas de caja negra.

¤ Algunas veces usa técnicas de prueba de caja blanca paraasegurar que se cubren los principales caminos de control.



Tipo de Pruebas

Pruebas de Alto Nivel

Sirven para comprobar si se cumplen los criterios devalidación.

Prueba de Validación

Se usa para verificar si se cumplen todos los requerimientosfuncionales, de comportamiento y de rendimiento.



Tipo de Pruebas

Prueba del Sistema

Operando en condiciones reales.

¤ Pruebas de recuperación

¤ Pruebas de seguridad

¤ Pruebas de resistencia (pruebas en situaciones anormales)

¤ Pruebas de rendimiento



Un problema típico es la «delegación de culpabilidad», estoocurre cuando se descubre un error y cada uno de loscreadores de cada elemento del sistema echa la culpa delproblema a los otros. Se debe anticipar a los posiblesproblemas y:1. diseñar caminos de manejo de errores que prueben toda la

información procedente de los elementos del sistema;2. llevar a cabo una serie de pruebas que simulen la presencia

de datos en mal estado o de otros posibles errores en lainterfaz del software;

3. registrar los resultados de las pruebas como «evidencia» enel caso de que se le señale con el dedo;

4. participar en la planificación y el diseño de pruebas delsistema para asegurarse de que el software se prueba deforma adecuada.

PRUEBA DEL SISTEMA.



Pruebas Alfa y BetaPara descubrir errores que pareciera que sólo el usuario puededescubrir.

¤ Prueba Alfa

Se hace en el lugar de desarrollo y con un cliente que la realiza. Eldesarrollador es un observador del usuario y registra errores y

problemas de uso.

¤ Pruebas BetaLa hacen los usuario finales. Se hacen después de haber acogidolas pruebas del sistema y las pruebas alfa.



¤ Desde el punto de vista procedimental

UNA ESTRATEGIA DE PRUEBA DEL

SW Pruebas de

alto nivel

Dirección della prueba

Codificación

Diseño

Requisitos

Prueba de

unidad

Prueba deIntegración

Etapas de prueba del SW



Pruebas de Software23

Profesor:

JuanAnto

nio

Estrategias de prueba del software.Niveles de prueba

1. Prueba de unidad: es la prueba de cada módulo, quenormalmente realiza el propio personal de desarrollo en su entorno

2. Prueba de integración: con el esquema del diseño del software, los

módulos probados se integran para comprobar sus interfaces en eltrabajo conjunto

3. Prueba de validación: el software totalmente ensamblado seprueba como un todo para comprobar si cumple los requisitosfuncionales y de rendimiento, facilidad de mantenimiento,

recuperación de errores, etc.

4. Prueba del sistema: el sw. ya validado se integra con el resto delsistema (rendimiento, seguridad, recuperación y resistencia)

5. Prueba de aceptación: el usuario comprueba en su propio entorno

de explotación si lo acepta como está o no



Pruebas de Software24

Profesor:

JuanAnto

nio

Relación entre productos dedesarrollo y niveles de prueba

Requisitosde usuario

Especificación

de requisitos

Diseño modular

Especificaciónlógica delmódulo

Código

Pruebas deaceptació

n

Pruebas desistema

Pruebas deintegración

Pruebas deunidad

(Piattini et al. 96)



Tipos de prueba

¤ Test de Facilidad

¤ Test de Volumen

¤ Test de Stress

¤ Test de Usabilidad

¤ Test de Seguridad

¤ Test de Performance

¤ Test de Configuración



Tipos de prueba

¤ Test de Insta labilidad

¤ Test de Fiabilidad

¤ Test de Recuperación

¤ Test de Documentación

¤ Test de Mantenibilidad



Caja Negra

¤ Pruebas funcionales sin acceso al código fuente de lasaplicaciones, se trabaja con entradas y salidas



Caja Negra



Pruebas de Caja Negra

Permiten obtener conjuntos de condiciones de entrada que

ejecuten todos los requisitos funcionales de un programa.Las pruebas de caja negra NO son una alternativa a lastécnicas de prueba de caja blanca. Es un enfoquecomplementario.

Las pruebas de caja negra intentan hallar errores tales como:



Pruebas de Caja Negra

1. Funciones incorrectas o ausentes.

2. Errores de interfaz.

3. Errores en estructuras de datos o en accesos a BDexternas.

4. Errores de rendimiento.

5. Errores de inicialización y de terminación.



Otras Pruebas

¤ Pruebas de GUI (Interfaces Gráficas de Usuario).

¤ Pruebas de Arquitectura Cliente/Servidor.

¤ Pruebas de Documentación y Ayudas.



Caja Blanca

¤ Pruebas con acceso al código fuente (datos y lógica). Setrabaja con entradas, salidas y el conocimiento interno.

1. Garanticen que se ejercitan por lo menos una vez TODOS loscaminos, independientemente de cada módulo.

2. Ejerciten todas las decisiones lógicas por sus vertientesCierto y Falso.

3. Ejecuten todos los ciclos en sus límites y límitesoperacionales.

4. Ejerciten las estructuras internas de datos para asegurar suvalidez.



Caja Blanca



Diseño de caso de prueba

¤ Clases de equivalencia

¤ Decisiones/condiciones

¤ Valores límites

¤ Tester Visitante



Pruebas

Pruebas de Software - ITSPA

Documents

Transcript of Pruebas de Software - ITSPA