Análisis y modelación de sistemas de software
4. Pruebas
Blanca A. Vargas Govea [email protected]
Mayo 3, 2013
2
Contenido
● Introducción a las pruebas de software
3
Introducción a las pruebas de software¿Cómo pruebas tu software?
4
Pruebas (testing)
● Proceso de encontrar defectos en elementos de software como diagramas UML o código.
● Un defecto es un error que hace que el sistema falle.
5
¿Cómo funciona?
● Consiste en utilizar un programa con diferentes combinaciones de entradas para detectar defectos.
● Testing muestra solamente la presencia de defectos, no su ausencia.
¿0 fallas en tus pruebas = ausencia de defectos?
6
¿Puedes garantizar la ausencia de defectos?
● El número de combinaciones posibles generalmente crece exponencialmente con el tamaño del software
● Errores malintencionados
● Secuencias que activan errores
7
No es posible probar que un programa funcionará correctamente para todas las secuencias de entrada
imaginables
8
¿Qué son las técnicas de pruebas de software?
● Son procedimientos para seleccionar ó diseñar pruebas– basados en un modelo
funcional o estructural del software
– exitosas para encontrar fallas
9
¿Qué son las técnicas de pruebas de software?
● Son métodos o formas de aplicar estrategias de detección de defectos.
● Las estrategias de detección de defectos son teorías acerca de– ¿cómo restringir el número
de pruebas necesarias?
– ¿Cómo lograr cobertura en las pruebas?
– -¿Cómo encontrar cierto tipo de defectos?
10
¿Por qué son necesarias las pruebas?
● Disminuyen el número de pruebas necesarias– Deben ser un sub-conjunto de todas las pruebas.– El sub-conjunto debe tener una alta probabilidad de
detectar fallas.
● Se necesitan métodos sistemáticos que ayuden a seleccionar los casos de prueba de forma inteligente.
11
¿Por qué son necesarias las pruebas?
● Que distintas personas tengan las mismas probabilidades de encontrar las fallas.– La idea es tener independencia de las habilidades personales
del tester.
● Pruebas efectivas: encontrar más fallas.– Enfocar la atención en tipos específicos de fallas.
– Saber que se está probando lo correcto.
● Pruebas eficientes: encontrar fallas con menos esfuerzo.– Evitar pruebas redundantes.
– Las técnicas sistemáticas son medibles.
12
Clasificación tradicional de técnicas de pruebas
Juha Itkonen SoberIT - slides
13
Tipos de pruebas
Estructural Funcional
● El tester examina la estructura interna del programa y la lógica.
● Caja Blanca.
● El tester prueba el programa con base en las salidas esperadas. No conoce la estructura interna.
● Caja Negra.
14
Niveles de pruebas
1. Unitarias
3. del Sistema
2. de Integración
4. de Aceptación
5. de Regresión
6. Beta
Stress testing
Performance
Usabilidad
15
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.
16
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.
17
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.
18
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.
19
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.
20
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.
21
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.
22
5. Pruebas de Regresión
● Probar contínuamente el sistema o componente para verificar que las modificaciones no han causado efectos inesperados.
● Documentos: cambios en la documentación, diseño de alto nivel.
● Tipo: Caja Blanca/Caja Negra.
● Testers: desarrolladores.
23
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.
24
Los tipos de pruebas en los seis niveles
Caja Blanca Caja Negra
25
Testing basado en estados
26
Enfoque: máquina de estados
Se define un conjunto de estados para evaluar el comportamiento de la unidad comparando los estados actuales con los esperados
27
Pasos
1. Construir el diagrama de estados para la unidad que se va a probar.
2. Definir estados y transiciones. Para una clase, las transiciones ocurren generalmente al invocar un método.
3. Se seleccionan valores de prueba para cada estado.
4. Un conjunto de prueba consiste en definir escenarios que pasen por un camino dado del diagrama.
28
Cobertura
● El objetivo es – Cubrir los estados al menos una vez– Cubrir las transiciones válidas al menos una vez– Disparar las transiciones inválidas al menos una vez
● El objetivo no es– Cubrir todas las combinaciones de caminos
29
● Los caminos
1-2-3-5-6-7-11-16
1-2-4-5-6-8-9-11-16
serían suficientes para probar puesto que tocan todos los estados y todas las transiciones
● Combinaciones como
1-2-4-5-6-7-11-16
no son necesarias
30
31
Estados: Cerrado (C), Abierto (A), Procesando(P), Bloqueado (B)Eventos: clave-válida, clave-inválida
max = 3
Caso Camino Evento equivocaciones
T1 C-A clave-válida 0
T2 C-P-A clave-inválida 1
T3 C-P-B clave-inválida 4
● Se pasa por todos los estados● Se pasa por todas las tran-● siciones● Se prueba el valor inválido
32
Caso Camino Evento equivocaciones
Resultado esperado
Resultadoactual
Estatus
T1 C-A clave-válida 0 Abierto Abierto Pass
T2 C-P-A clave-inválida
1 Abierto Abierto Pass
T3 C-P-B clave-inválida
4 Bloqueado Abierto Fail
Pruebas
33
Actividad 26 - Equipo
● De su proyecto, seleccionar las unidades de software a evaluar.
● Construir la máquina de estados (es posible que ya la tengan).
● Definir los casos de prueba, construir la tabla (como la del slide 32).
34
Tarea 26 - equipo
● A partir de la Actividad 26, ejecutar las pruebas y elaborar un reporte que incluya
– Máquina de estados a evaluar (si ya existe, poner la referencia).
– Tabla de casos de prueba con el estatus (Pass/Fail)
– Agregar al reporte final del proyecto.● Entrega de reporte final: Martes 7 de Mayo
35
Referencias● Ballena Photo Credit: <a
href="http://www.flickr.com/photos/82882348@N00/2636021346/">somenice</a> via <a href="http://compfight.com">Compfight</a> <a href="http://creativecommons.org/licenses/by-nc/2.0/">cc</a>
● Errores Photo Credit: <a href="http://www.flickr.com/photos/11821713@N00/3647655051/">Zanthia</a> via <a href="http://compfight.com">Compfight</a> <a href="http://creativecommons.org/licenses/by-nc-sa/2.0/">cc</a>
Top Related