Análisis y modelación de sistemas de software

4. Pruebas

Blanca A. Vargas Govea vargasgovea@itesm.mx

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>