testing = especificación + programación

IntroducciónTesting Basado en Modelos

Un Caso de EstudioConclusiones

Testing = Especificación + ProgramaciónHaciendo posible el testing

Maximiliano Cristiá

Flowgate [email protected]

CIFASISUniversidad Nacional de Rosario

[email protected]

Primera Jornada de Calidad e Innovaciónen la Producción de Software

Maximiliano Cristiá Testing = Especificación + Programación



Aspectos económicos del testingLos costos de testearAlcance de la charla

Audiencia¿Para quiénes está destinada la charla?

Para los que testeanPorque quieren reducir los costos de testing.Porque quieren testear más por el mismo costo.Porque el trabajo manual y repetitivo los harta.

Para los que no testean pero quieren testearPorque testear es muy caro.Porque testear es muy complejo.Porque testear es muy laborioso.Porque testear requiere profesionales que no tienen.





Madurez

Esta charla es para equipos con cierto nivel de madurezEs necesario tener los requerimientos escritos.Es necesario separar los roles de testing y programación.

Es conveniente tener documentación del código fuente.





El testing es muy caro

Según Fred Brooks (The Mythical Man-Month)

El testing de software de base ronda el 50 % del costo total.

Según el Software Engineering InstituteEl testing ronda entre el 30 % y el 40 % del costo total.

Según IBM y Gartner

Si reparar un error durante la ingeniería de requerimientoscuesta $1, repararlo durante el testing cuesta $60 y repararlodespués de la entrega $100.





Calcular casos de prueba es lo más caro

Retesting

La fase más costosa del testing es el retesting.Con las metodologías clásicas esto puede implicarrecalcular muchos casos de prueba.

Calcular los casos de pruebaTécnicamente, lo más costoso del testing es calcular todosy cada uno de los casos de prueba.En cierto sentido el retesting es costoso porque hay querecalcular casos de prueba.





¿Cómo reducir el costo de testing?

Posibles solucionesNo testear.Hacer programas correctos por construcción.Automatizar el testing.

¿Es posible?Sí, en gran medida es posible.





Validación & Verificación (V&V)

Validación¿Implementamos el programa que quiere el usuario?Testing de aceptación→ Tarde y caro (IBM & Gartner).

Verificación¿Implementamos el programa especificado?Testing de unidad, de integración y de sistema.Esta charla es sobre verificación y testing de unidad.

requerimientos especificación programa

verificación

validación





Corrección de un programa

Considerando sólo verificación:

DefiniciónUn programa es correcto si verifica su especificación.Por lo tanto, para poder testear es necesario tener unaespecificación.A la especificación también se la llama modelo.




Model-Based Testing (MBT)

El testing se realiza partiendo deun modelo del software.Al inicio, el modelo se utiliza paragenerar casos de prueba.Al final, el modelo se utiliza comooráculo.Teniendo el modelo, el proceso esmuy automático.En esta charla sólo veremos“generar”.

Proceso de MBTrequerimientos

modelo

test

abstractos

tests resultados

resultados

abstractos

¿error?

generar

refinar

ejecutar

abstraer

comprobar




¿Quiénes usan MBT?

Empresas y sectoresMicrosoft – Sun – France Telecom – CiscoControl de tráfico aéreo.La industria automovilística europea.La industria de tarjetas inteligentes.

El reporte IBMGOTCHA-TCBeans – FSMTesting de la implementación POSIX de fnctl.Testing de parte del garbage collector de JVM.IBM reporta un ahorro sustancial y mayor cubrimiento.




MBT formal→ Testing automático

Modelos formalesPara automatizar MBT se utilizan modelos formales.Un modelo formal es una descripción lógico-matemática(abreviada) de un programa: es una abstracción.Esta charla es sobre MBT formal.

Notaciones formalesPara escribir una especificación formal se utiliza unanotación formal.Notaciones formales: Z, Statecharts, CSP, B, TLA+ . . .

En esta charla se utilizarán especificaciones Z.




¿Es más barato el MBT formal?




El modeloDetalle del paso “generar”Testing asistido por Fastest

Veamos un ejemplo concreto

Los requerimientosUn banco tiene un cierto conjunto de cajas de ahorro enlas cuales se puede depositar y extraer dinero.Cada caja de ahorro se identifica con un número decuenta.Los montos a depositar y los saldos serán númerosenteros.Sólo se debe mantener el saldo de cada caja de ahorro.Sólo modelaremos la operación de depósito.





La especificación ZLos tipos básicos

[NCTA] Un tipo para los números de cuenta

SALDO == N Un tipo para los saldos

ComentariosNo nos importa la estructura de un número de cuenta.Para simplificar consideramos que los saldos son númerosnaturales.





La especificación ZEl conjunto de estados

Bancocajas : NCTA 7→ SALDO

ComentariosDel banco sólo nos importan las cajas de ahorro.A cada número de cuenta le corresponde un único saldo.No nos importan: la persistencia, la performance, ellenguaje de programación, las estructuras de datos, etc.





La especificación ZLa operación de depósito

DepositarOk∆Banco Se cambia el estadonum? : NCTA; monto? : Z Parámetros de entrada

num? ∈ dom cajas ¿Existe la cuenta?monto? > 0 No se puede depositar 0 o menos

cajas′ = cajas ⊕ {num? 7→ cajas(num?) + monto?}

Comentarioscajas′ representa la “base de datos” luego del depósito.El operador ⊕ se parece a update de SQL.





La especificación ZLa operación de depósito (cont.)

DepositarE1 ==[ΞBanco; num? : NCTA | num? /∈ dom cajas]

DepositarE2 == [ΞBanco; monto? : Z | monto? ≤ 0]

Depositar == DepositarOk ∨ DepositarE1 ∨ DepositarE2

ComentariosDepositarE1 y DepositarE2 especifican posibles errores.La operación final se arma usando todos los esquemas.Depositar es la operación que vamos a testear.





Usamos el modelo para generar casos de prueba

Proceso de MBT

modelo

test

abstractos

tests resultados

resultados

abstractos

¿error?

generar

refinar

ejecutar

abstraer

comprobar

Detalle de “generar”

VIS

partición VIS . . . partición VIS

árbol de pruebastests

abstractostáctica

táctica táctica

podar

Siempre el costoEl mayor costo de testing escalcular los casos de prueba.





Fastest: automatización de MBT

El proyectoI+D conjunto entre Flowgate Consulting y CIFASIS.Parcialmente financiado por FONTAR.Prototipo disponible en www.flowgate.net.

CaracterísticasProcesamiento distribuido – Cliente-servidor.Extensible y configurable por el usuario – Tácticas.Multiplataforma – Java.Auto-documentación – Latex y PDF.Interfaz de texto muy simple – A mejorar.





VIS y tácticas

En teoría

VIS == [cajas : NCTA 7→ SALDO; num? : NCTA; monto? : Z]

Dos tácticas de testing:DNF: considera cada uno de los esquemas por separado.Partición estándar sobre ⊕ considera valoresrepresentativos para cajas y {num? 7→ cajas(num?) + monto?}.

Con Fastestloadspec banco.texselop Depositaraddtactic Depositar SP \oplus

cajas \oplus \{num? \map cajas(num?) + monto?\}





El árbol de pruebas

En teoríaCada nodo del árbol es un objetivo de prueba.Cada objetivo es un conjunto de condiciones que tiene quecumplir un caso de prueba.Los objetivos se tornan más específicos a medida que sedesciende por el árbol.Los casos de prueba se extraen de las hojas del árbol.

Con Fastestgenallttshowtt -p Depositar





El árbol de pruebas de Depositar

VIS

DNF1

SP1 . . . SP8

DNF2

SP9 . . . SP16

DNF3

SP17 . . . SP24

Ejemplos de objetivos de prueba

DNF1 == [VIS | num? ∈ dom cajas ∧ monto? > 0]

SP4 == [VIS | num? ∈ dom cajas ∧ monto? > 0∧ cajas 6= {}∧ dom cajas = dom{num? 7→ cajas(num?) + monto?}]





Podando el árbol de pruebas

En teoríaMuchos de los objetivos pueden ser inalcanzables.Son situaciones imposibles de testear.Es conveniente eliminar esos objetivos.

SP6 == [VIS | num? ∈ dom cajas ∧ monto? > 0∧ cajas 6= {}∧ dom cajas ∩ dom{num? 7→ cajas(num?) + monto?} = {}]

Con Fastest – Automático en la próxima versiónprunefrom SP_1, SP_2, SP_3, SP_6, SP_7, SP_8prunefrom SP_9, SP_11, SP_12, SP_13, SP_15, SP_16prunefrom SF_17, SP_19, SP_22, SP_23, SP_24





El árbol y los objetivos resultantes

5 objetivosVIS

DNF1

SP4 SP5

DNF2 DNF3

SP20 SP21

SP4 == [. . . ]

SP5 == [VIS | num? ∈ dom cajas ∧ monto? > 0∧ cajas 6= {}∧ dom{num? 7→ cajas(num?) + monto?} ⊂ dom cajas]

DNF2 == [VIS | num? /∈ dom cajas]

SP20 == [. . . ] SP21 == [. . . ]





Generando casos de prueba

En teoríaSe deben buscar constantes que satisfagan cada uno delos objetivos de prueba.Esto no es automatizable en el 100 % de los casos.

Con FastestEn promedio Fastest se acerca al 90 %, el resto es manual.En este ejemplo encuentra el 100 % de los casos.El comando es genalltca.





Los casos de prueba en Z

5 casosautomáticos

SP4T == [VIS | monto? = 1 ∧ num? = ncta0 ∧ cajas = {ncta0 7→ 1}]

SP5T == [VIS | monto? = 1 ∧ num? = ncta0 ∧ cajas = {ncta0 7→ 1, ncta1 7→ 1}]

DNF2T == [VIS | monto? = 0 ∧ num? = ncta0 ∧ cajas = ∅]

SP20T == [VIS | monto? = −1 ∧ num? = ncta0 ∧ cajas = {ncta0 7→ 1}]

SP21T == [VIS |monto? = −1∧ num? = ncta0∧ cajas = {ncta0 7→ 1, ncta1 7→ 1}]





¿Qué estamos testeando?

Los casos de prueba en castellanoSP4T : depositar en una cuenta existente una cantidadpositiva cuando es la única cuenta.SP5T : depositar en una cuenta existente una cantidadpositiva cuando no es la única cuenta.DNF2T : intentar un depósito cuando no hay cuentas.SP20T : depositar en una cuenta existente una cantidadnegativa cuando es la única cuenta.SP21T : depositar en una cuenta existente una cantidadnegativa cuando no es la única cuenta.




Ventajas y desventajas del MBT formal

VentajasEs la técnica de testing más económica.Es la técnica de testing más automática.Es la técnica de testing más disciplinada.Es la técnica de testing que más errores descubre.Es la técnica de testing menos orientada al código.Se puede comenzar el testing desde el inicio del proyecto.

DesventajasRequiere profesionales que puedan modelar formalmente.Requiere una herramienta como Fastest.




MBT formal hace posible el testing




Proyectos actuales de testing con Fastest

Con INPEInstituto Nacional de Pesquisas Espaciais (Brasil).Testing de protocolo de comunicación entre computadorasde satélites.

Con Critical Software y Universidad de CoimbraInstituciones portuguesas.Testing de software de abordo de satélites según estándarde la ESA.


testing = especificación + programación

Technology