Verificación y Validación de Software
Ingeniería en Sistemas de Información
Departamento de Ciencias e Ingeniería de la Computación 2015
Verificación y Validación de Software
2015 / DCIC / UNS
VyVS
Testing Orientado a Objetos
Object Oriented Testing
Verificación y Validación de
Software
Herencia Múltiple
Verificación y Validación de
Software
The Yo-Yo Problem
TOO / Tablas de Decisiones
Podemos usar las tablas para modelar el flujo de control de lo que estamos testeando o las responsabilidades de la clase.
Verificación y Validación de
Software
TOO / Tablas de Decisiones
Criterios de Cubrimiento
All-Explicit Variants
All-Variants, All-True, All-False, All-Prime Each-Condition/All-Conditions
BDD-Determinants
Nonbinary Variable Domain Analysis
Verificación y Validación de
Software
Testing Orientado a Objetos
Object Oriented Testing
Verificación y Validación de
Software
Testing a Nivel de Métodos
Method Scope Testing
Verificación y Validación de
Software
Testing a Nivel de Métodos
Method Scope Testing
Las técnicas que vimos de caja blanca son aplicables en este caso
Grafo de Flujo de Control
Cubrimiento de Sentencias
Cubrimiento de Condiciones y Decisiones Cubrimiento de Caminos, etc.
Verificación y Validación de
Software
Testing a Nivel de Métodos
Method Scope Testing
Las técnicas que vimos de caja blanca son aplicables en este caso
Flujo de Datos
Verificación y Validación de
Software
Testing a Nivel de Métodos
Method Scope Testing
Las técnicas que vimos de caja blanca son aplicables en este caso
Clases de Equivalencia, Tablas de Decisión
Verificación y Validación de
Software
Testing a Nivel de Métodos / Recursive Function Test
Method Scope Testing
Verificación y Validación de
Software
Testing a Nivel de Métodos / Recursive Function Test
Method Scope Testing
Problemas conocidos:
La ejecución continua cuando la precondición no se satisface en el primer llamado o durante los llamados recursivos.
Se omite el caso base.
La lógica del caso base/recursivo es incorrecta.
La condición del caso base contiene el operador incorrecto.
El caso base retorna el valor incorrecto.
La postcondición no se satisface al volver de la recursividad.
Verificación y Validación de
Software
Testing a Nivel de Métodos / Recursive Function Test
Method Scope Testing
Problemas conocidos al recorrer estructuras:
No se reconoce una estructura corrupta.
Se inicializa en forma incorrecta o corrupta la estructura.
No se recorre correctamente la estructura.
El algoritmo no es apropiado para la estructura.
Verificación y Validación de
Software
Testing a Nivel de Métodos / Recursive Function Test
Method Scope Testing
Diseñar casos de test que:
Intenten violar la precondición en el primer llamado y por lo menos una vez durante la secuencia recursiva.
Intenten violar la postcondición en la vuelta de la recursividad.
Análisis de Valores Límites en la profundidad de la recursión, 0, 1 y máximo.
Buscar generar todas las excepciones posibles en el contexto donde está el método.
Verificación y Validación de
Software
Testing a Nivel de Métodos / Recursive Function Test
Method Scope Testing
Diseñar casos de test que:
Usar Análisis de Dominio sobre los parámetros de entrada.
Usar Análisis de Dominio sobre la estructura de datos.
Verificación y Validación de
Software
Testing a Nivel de Métodos / Polymorphic Message Test
Method Scope Testing
Verificación y Validación de Software
A +f()
B +f()++
C +f()++
No nos daría confianza un método al cual no se le testearon todos los posibles caminos de su ejecución.
De la misma manera, no nos daría confianza un método sobre el cual no se testearon todas las variantes posibles de un llamado polimórfico.
Testing a Nivel de Métodos / Polymorphic Message Test
Method Scope Testing
Verificación y Validación de Software
A +f()
B +f()++
C +f()++
No nos daría confianza un método al cual no se le testearon todos los posibles caminos de su ejecución.
De la misma manera, no nos daría confianza un método sobre el cual no se testearon todas las variantes posibles de un llamado polimórfico.
Testing a Nivel de Métodos / Polymorphic Message Test
Method Scope Testing
Verificación y Validación de Software
A +f()
B +f()++
C +f()++
No nos daría confianza un método al cual no se le testearon todos los posibles caminos de su ejecución.
De la misma manera, no nos daría confianza un método sobre el cual no se testearon todas las variantes posibles de un llamado polimórfico.
Testing a Nivel de Métodos / Polymorphic Message Test
Method Scope Testing
Verificación y Validación de Software
A +f()
B +f()++
C +f()++
No nos daría confianza un método al cual no se le testearon todos los posibles caminos de su ejecución.
De la misma manera, no nos daría confianza un método sobre el cual no se testearon todas las variantes posibles de un llamado polimórfico.
Testing a Nivel de Métodos
Method Scope Testing
Si nos limitamos solamente a testear a nivel de métodos podemos estar obviando problemas en las interacciones dentro de las clases.
Verificación y Validación de
Software
Testing a Nivel de Clase
Class Scope Testing
Verificación y Validación de
Software
Integración a Nivel de Clase
Class Scope Integration
La Integración a Nivel de Clase es un paso anterior a comenzar el testing de la clase. Lo que se busca es determinar si la clase está lista para ser testeada, esto es, que no contenga errores groseros.
Small Pop
Alpha-Omega Cycle
Verificación y Validación de
Software
Integración a Nivel de Clase / Small Pop
Class Scope Integration
El Small Pop es una Integración Big Bang pero a nivel de clase.
Se escribe la clase completa y cuando se termina se hace un driver para hacer un test general de la misma.
La clase debe ser simple
Los servidores que la clase usa deben ser estables Los elementos heredados deben ser estables
Hay poca interacción dentro de la clase
Verificación y Validación de
Software
Integración a Nivel de Clase / Alpha-Omega Cycle
Class Scope Integration
Alpha y Omega representan dos estados asociados a la vida de un objeto. Alpha es el estado en el que se está, antes de la creación del objeto y Omega es el estado al que se llega después de la destrucción del objeto.
La técnica Alpha-Omega Cycle tiene como objetivo llevar un objeto desde Alpha hasta Omega, enviando cada mensaje posible disponible en el objeto (por lo menos una vez).
Verificación y Validación de
Software
Integración a Nivel de Clase / Alpha-Omega Cycle
Class Scope Integration
No es el objetivo lograr un cubrimiento de sentencias ni de responsabilidades, sólo se busca ejecutar todos los métodos del objeto y llegar a Omega. Sí se logra cumplir este ciclo, entonces se puede pasar a test más complejos.
Verificación y Validación de
Software
Integración a Nivel de Clase / Alpha-Omega Cycle
Class Scope Integration
Existe un orden sugerido para ejecutar el ciclo:
1. Llamar al constructor
2. Llamar a los métodos get
3. Llamar a los métodos booleanos 4. Llamar a los métodos set
5. Llamar a los iteradores 6. Llamar al destructor
Verificación y Validación de
Software
Testing Orientado a Objetos
Object Oriented Testing
Algunos de los problemas que genera el paradigma orientado a objetos en el testing, no son exclusivos del testing.
Verificación y Validación de
Software
Testing Orientado a Objetos
Object Oriented Testing
Verificación y Validación de Software
Testing
Cálculo de Métricas Serialización
Tipos de Herencia
Recordemos los tres usos posibles de la herencia Extensión (me traigo todo lo que heredo)
Sobreescritura (cambio la implementación de lo que heredo) Especialización (agrego cosas nuevas)
Verificación y Validación de
Software
Principio de Sustitución de Liskov
Si S es un subtipo de T, entonces los objetos de tipo T pueden ser sustituidos por objetos de tipo S sin alterar ninguna de las propiedades deseables del sistema.
Verificación y Validación de
Software
OO Testing Manifesto
Principios:
● Unique Bug Hazzard. El testing debería primero centrarse en los bugs propios del paradigma y ser “expandido” con técnicas clásicas.
● Object-oriented Test Automation. Las herramientas de testeo deben ajustarse al paradigma.
● Test-effective Process. El proceso de testing debe ser iterativo e incremental. El tester debe considerar testing a nivel de clase, método y paquete simultáneamente.
Verificación y Validación de
Software
Bugs de Herencia
¿Cuáles son los bugs más comunes relacionados con la herencia?
Verificación y Validación de
Software
Bugs de Herencia
Incorrect Initialization: Se omite la inicialización apropiada de una superclase o se hace en forma incorrecta.
Inadvertent Binding: Vinculaciones incorrectas por un mal entendimiento de las reglas de alcance.
Missing Override: No se indica explícitamente que un método es una sobreescritura de otro.
Verificación y Validación de
Software
Bugs de Herencia
Naked Access: Un atributo público de una superclase es visto por las subclases y modificado directamente.
Square Peg in a Round Hole: Una subclase está incorrectamente ubicada dentro de una jerarquía de clases.
Naughty Children: Una subclase no acepta todos los mensajes que su superclase acepta o la subclase deja al objeto en un estado inválido con respecto a la superclase.
Verificación y Validación de
Software
Bugs de Herencia
Worm Holes: La subclase computa valores que no son válidos con respecto al invariante de la superclase.
Spaghetti Inheritance: Mucha herencia múltiple + herencias muy profundas.
Gnarly Hierarchies: Una subclase modifica el dominio de una operación.
Verificación y Validación de
Software
Bugs de Herencia
Weird Hierarchies: Se abusa de la herencia para compartir código.
Fat Interfaces: Una subclase hereda métodos que son inapropiados para la clase. Nunca los va a utilizar pero igual están disponibles.
Verificación y Validación de
Software
Clase Aplanada
Class Flattening
Una clase aplanada es una clase que hace explícito todo lo que hereda.
Verificación y Validación de
Software
Clase Aplanada
Class Flattening
Verificación y Validación de Software
+a +b* -c
Clase A
+d +e -f
Clase B +a +b+
+d +e++
Clase C
+a +b++ +g +h
A
B
C
Clase Aplanada
Class Flattening
¿Cómo aplanar una clase?
Tenemos que tener en cuenta las semánticas involucradas en la herencia de Java.
Verificación y Validación de
Software
Clase Aplanada
Class Flattening
A nivel de visibilidad, tenemos cuatro modificadores:
público, privado, protegido y paquete
Una subclase puede acceder directamente a todo lo que esté declarado como público, protegido o paquete. Todo lo que sea privado sólo puede ser accedido directamente dentro de la clase que lo declara.
Verificación y Validación de
Software
Clase Aplanada
Class Flattening
A nivel de visibilidad, tenemos cuatro modificadores:
público, privado, protegido y paquete
Público, paquete y protegido lo vamos a llamar “visible”. Todo lo que sea privado lo vamos a llamar “invisible”.
Verificación y Validación de
Software
Attribute & Method Flattening
Los atributos que no son overridden y que son visibles, se bajan directamente de la superclase a la subclase. Si un atributo no es overridden y es invisible entonces tenemos que analizar si algún método visible lo accede en la superclase.
Sí un método de la superclase accede al atributo invincible (no overridden) entonces el atributo se debe bajar a la subclase, excepto que ninguno de los métodos que acceden a este atributo bajen (method flattening).
Verificación y Validación de
Software
Attribute & Method Flattening
Los atributos que son overridden se deben bajar de la superclase a la subclase sí también se están bajando los métodos que los utilizan. Es importante notar que en el caso de los atributos que son overridden se debe hacer un renombramiento del atributo y de cada referencia al mismo en los métodos que se bajan y lo utilizan. También hay que cambiar las referencias al atributo (si existen) en la subclase (super.)
Verificación y Validación de
Software
Attribute & Method Flattening
El único caso donde no se baja un atributo es cuando es invisible y no es utilizado por métodos que se bajan.
Verificación y Validación de
Software
Attribute & Method Flattening
El único caso donde no se baja un atributo es cuando es invisible y no es utilizado por métodos que se bajan.
El análisis es equivalente para los métodos.
Verificación y Validación de
Software
Attribute & Method Flattening
Verificación y Validación de Software
¿Visible?
¿Overridden?
¿Accessible?
¿Accessible?
No se baja Sí se baja
Renombrar y bajar
¿Overridden?
Sí
Sí
Sí
Sí
Sí No
No
No No
No
Class Scope & Flatten Class Scope
Class Scope = “A nivel clase”, hace referencia a todo lo visible a nivel de una clase; sus atributos y métodos.
Flatten Class Scope = “A nivel clase aplanada”, hace referencia a todo lo visible de una clase, más todo lo que contiene por herencia.
Verificación y Validación de
Software
Testing a Nivel de Clase
Class Scope Testing
Algunas clases pueden aceptar un mensaje en cualquier momento, bajo cualquier estado. Sin embargo, existen clases que imponen restricciones sobre cuándo pueden recibir cierto mensaje.
Estás restricciones pueden involucrar mensajes anteriores o el contenido del objeto. Esta situación se conoce como Class Modality
Verificación y Validación de
Software
Testing a Nivel de Clase
Class Scope Testing
Hay 4 tipos de Modalities
Nonmodal Class: La clase no impone restricciones sobre la secuencia de llamados.
Unimodal: La clase impone restricciones sobre la secuencia de llamados, pero las restricciones no involucran el contenido del objeto sino los llamados anteriores.
Quasi-Modal: La clase impone restricciones sobre la secuencia de llamados y las restricciones sólo dependen del contenido del objeto.
Modal: La clase impone restricciones sobre la secuencia de llamados y las restricciones dependen del contenido del objeto y de los llamados anteriores.
Verificación y Validación de
Software
Testing a Nivel de Clase / Nonmodal Class Test
Class Scope Testing
Testear una clase que no impone restricciones sobre la secuencia de llamados. ¿Cómo seleccionamos secuencias de llamados que puedan revelar problemas en la clase?
Verificación y Validación de
Software
Testing a Nivel de Clase / Nonmodal Class Test
Class Scope Testing
Verificación y Validación de Software
ALPHA OMEGA
constructor 1
constructor 2
constructor constructor1
constructor1 ...
Testing a Nivel de Clase / Nonmodal Class Test
Class Scope Testing
Estrategias
Define-use sequence: Esa secuencia consiste de un método def, seguido de todos los métodos use posibles.
Random sequence: La secuencia de sets y gets se genera en forma aleatoria.
Suspect sequence: Si existen secuencias que son sospechosas, por alguna razón, entonces se prueban.
Verificación y Validación de
Software
Testing a Nivel de Clase / Unimodal Class Test
Testing at Class Scope
Testear una clase que impone restricciones sobre la secuencia de llamados y dichas restricciones sólo dependen de llamados anteriores.
Los autores Kirani & Tsai desarrollaron una propuesta para esta situación, denominada “Especificación de Secuencia de Métodos”
Verificación y Validación de
Software
Testing a Nivel de Clase / Unimodal Class Test
Testing at Class Scope
Dada una clase C, Methods(C) es el conjunto de métodos públicos definidos en C. Una secuencia de métodos S, es una secuencia finita de métodos pertenecientes a Methods(C).
C = Clase Pila;
Methods(Clase Pila) = {Push, Pop, isEmpty}
S1 = {Push . Push . Pop}
S2 = {isEmpty . Pop}
Verificación y Validación de
Software
Testing a Nivel de Clase / Unimodal Class Test
Testing at Class Scope
Se pueden usar expresiones regulares para declarar el uso correcto de los métodos.
Clase Caja_Ahorro;
Methods(Caja_Ahorro) = {Crear, Verificar, Depositar, Retirar, Borrar}
SeqSpec(Caja_Ahorro) -> Crear . Verificar . Operar . Borrar Operar -> Depositar . Transacciones
Transacciones -> (Depositar | Retirar)*
Verificación y Validación de
Software
Testing a Nivel de Clase / Unimodal Class Test
Testing at Class Scope
SafeSeq(C) es el conjunto de todas las secuencias Si que se pueden derivar de SeqSpec(C).
Esta técnica es posible utilizarla tanto para un análisis estático como para un análisis en ejecución.
Verificación y Validación de
Software
Testing a Nivel de Clase / Quasi-modal Class Test
Testing at Class Scope
Testear una clase cuyas restricciones en la secuencia de llamados dependen del contenido del objeto.
Es muy probable que esta clase tenga algún tipo de estructura asociada, por lo que debemos prestar atención a la misma. También es muy probable que existan invariantes y precondiciones asociadas a las restricciones.
Verificación y Validación de
Software
Testing a Nivel de Clase / Quasi-modal Class Test
Testing at Class Scope
Estrategia
Describir las restricciones de contenido como un diagrama de estados o tabla de transiciones.
Utilizar los invariantes y precondiciones como condiciones guardia en las transiciones.
Verificación y Validación de
Software
Testing a Nivel de Clase / Quasi-modal Class Test
Testing at Class Scope
Verificación y Validación de Software
ALPHA VACIA CON OMEGA
COSAS LLENA
add(x)
[sizeOf==Max-1]
add(x) new()
Testing a Nivel de Clase / Quasi-modal Class Test
Testing at Class Scope
Verificación y Validación de Software
Estado Actual Evento/Condición Acción Nuevo Estado
Browsing Click link Display Browsing
Browsing Add to cart Selection Dialog Selecting
Browsing Continue Shopping Undefined Undefined
Browsing Check out Undefined Undefined
Browsing Login[bad] Undefined Undefined
Browsing Login[good] Undefined Undefined
Browsing Purchase[bad] Undefined Undefined
Browsing Purchase[good] Undefined Undefined
Browsing Abandon <no action> Left
Browsing Resume Shopping Undefined Undefined
Browsing Go elsewhere Undefined Undefined
Selecting Click link Undefined Undefined
Testing a Nivel de Clase / Quasi-modal Class Test
Testing at Class Scope
Verificación y Validación de Software
Estado Actual Evento/Condición ALPHA VACIA ….
ALPHA new OK
ALPHA add(x)
... ... ... ... ...
Testing a Nivel de Clase / Modal Class Test
Testing at Class Scope
Testear una clase que impone restricciones sobre la secuencia de llamados, las restricciones dependen del contenido del objeto y de llamados anteriores.
Verificación y Validación de
Software
RESUMEN
Testing a Nivel de Métodos
Method Scope Testing
Las técnicas que vimos de caja blanca son aplicables en este caso
Grafo de Flujo de Control
Cubrimiento de Sentencias
Cubrimiento de Condiciones y Decisiones Cubrimiento de Caminos, etc.
RESUMEN
Testing a Nivel de Métodos / Polymorphic Message Test
Method Scope Testing
RESUMEN
A +f()
B +f()++
C +f()++
No nos daría confianza un método al cual no se le testearon todos los posibles caminos de su ejecución.
De la misma manera, no nos daría confianza un método sobre el cual no se testearon todas las variantes posibles de un llamado polimórfico.
Testing a Nivel de Métodos
Method Scope Testing
Si nos limitamos solamente a testear a nivel de métodos podemos estar obviando problemas en las interacciones dentro de las clases.
RESUMEN
Clase Aplanada
Class Flattening
RESUMEN
+a +b* -c
Clase A
+d +e -f
Clase B +a +b+
+d +e++
Clase C
+a +b++ +g +h
A
B
C
Testing a Nivel de Clase
Class Scope Testing
Hay 4 tipos de Modalities
Nonmodal Class: La clase no impone restricciones sobre la secuencia de llamados.
Unimodal: La clase impone restricciones sobre la secuencia de llamados, pero las restricciones no involucran el contenido del objeto sino los llamados anteriores.
Quasi-Modal: La clase impone restricciones sobre la secuencia de llamados y las restricciones sólo dependen del contenido del objeto.
Modal: La clase impone restricciones sobre la secuencia de llamados y las restricciones dependen del contenido del objeto y de los llamados anteriores.
RESMEN
Verificación y Validación de Software
Ingeniería en Sistemas de Información
Departamento de Ciencias e Ingeniería de la Computación 2015
