Introducción a la Computación @let@token Introducción al Testing

Introducción a la Computación
Introducción al Testing
Esteban E. Mocskos (emocskos@dc.uba.ar)
Facultad de Ciencias Exactas y Naturales, UBA
CONICET
10/06/2013
E. Mocskos (UBA–CONICET)
Introducción al Testing
10/06/2013
1 / 15
¿Por qué?
Ariane 5 fue un sistema de lanzamiento descartable diseñado
y construido por la Comisión Europea.
Los constructores fueron: Airbus Defence and Space y
Arianespace, pero era un conglomerado de empresas
sub-contratistas.
On 4 June 1996, the maiden flight of the Ariane 5 launcher ended in a failure. Only
about 40 seconds after initiation of the flight sequence, at an altitude of about
3700m, the launcher veered off its flight path, broke up and exploded.
The failure of the Ariane 501 was caused by the complete loss of guidance and
attitude information 37 seconds after start of the main engine ignition sequence (30
seconds after lift-off). This loss of information was due to specification and design
errors in the software of the inertial reference system.
The internal SRI* software exception was caused during execution of a data
conversion from 64-bit floating point to 16-bit signed integer value. The
floating point number which was converted had a value greater than what could be
represented by a 16-bit signed integer.
E. Mocskos (UBA–CONICET)
Introducción al Testing
10/06/2013
2 / 15
Introducción
The weather at the launch site at Kourou on the morning of 4 June 1996 was acceptable for a launch that day, and presented no obstacle to the
transfer of the launcher to the launch pad. In particular, there was no risk of lightning since the strength of the electric field measured at the
launch site was negligible. The only uncertainty concerned fulfilment of the visibility criteria.
The countdown, which also comprises the filling of the core stage, went smoothly until H0-7 minutes when the launch was put on hold since the
visibility criteria were not met at the opening of the launch window (08h35 local time). Visibility conditions improved as forecast and the launch
was initiated at H0 = 09h 33mn 59s local time (=12h 33mn 59s UT). Ignition of the Vulcain engine and the two solid boosters was nominal, as
was lift-off. The vehicle performed a nominal flight until approximately H0 + 37 seconds. Shortly after that time, it suddenly veered off its flight
path, broke up, and exploded. A preliminary investigation of flight data showed:
nominal behaviour of the launcher up to H0 + 36 seconds;
failure of the back-up Inertial Reference System followed immediately by failure of the active Inertial Reference System;
swivelling into the extreme position of the nozzles of the two solid boosters and, slightly later, of the Vulcain engine, causing the launcher
to veer abruptly;
self-destruction of the launcher correctly triggered by rupture of the links between the solid boosters and the core stage.
The origin of the failure was thus rapidly narrowed down to the flight control system and more particularly to the Inertial Reference Systems, which
obviously ceased to function almost simultaneously at around H0 + 36.7 seconds.
Ası́ terminó el Arianne 5, costó 8000000000 dolares.
E. Mocskos (UBA–CONICET)
Introducción al Testing
10/06/2013
3 / 15
¿Qué pasó?
The launcher started to disintegrate at about H0 + 39 seconds because of high aerodynamic loads due to an angle of attack of more than 20
degrees that led to separation of the boosters from the main stage, in turn triggering the self-destruct system of the launcher.
This angle of attack was caused by full nozzle deflections of the solid boosters and the Vulcain main engine.
These nozzle deflections were commanded by the On-Board Computer (OBC) software on the basis of data transmitted by the active Inertial
Reference System (SRI 2). Part of these data at that time did not contain proper flight data, but showed a diagnostic bit pattern of the computer
of the SRI 2, which was interpreted as flight data. The reason why the active SRI 2 did not send correct attitude data was that the unit had
declared a failure due to a software exception.
The OBC could not switch to the back-up SRI 1 because that unit had already ceased to function during the previous data cycle (72 milliseconds
period) for the same reason as SRI 2.
The internal SRI software exception was caused during execution of a data conversion from 64-bit floating point to 16-bit signed integer value. The
floating point number which was converted had a value greater than what could be represented by a 16-bit signed integer. This resulted in an
Operand Error. The data conversion instructions (in Ada code) were not protected from causing an Operand Error, although other conversions of
comparable variables in the same place in the code were protected.The error occurred in a part of the software that only performs alignment of
the strap-down inertial platform. This software module computes meaningful results only before lift-off. As soon as the launcher lifts off, this
function serves no purpose.
The alignment function is operative for 50 seconds after starting of the Flight Mode of the SRIs which occurs at H0 - 3 seconds for Ariane 5.
Consequently, when lift-off occurs, the function continues for approx. 40 seconds of flight. This time sequence is based on a requirement of
Ariane 4 and is not required for Ariane 5.
The Operand Error occurred due to an unexpected high value of an internal alignment function result called BH, Horizontal Bias, related to the
horizontal velocity sensed by the platform. This value is calculated as an indicator for alignment precision over time. The value of BH was much
higher than expected because the early part of the trajectory of Ariane 5 differs from that of Ariane 4 and results in considerably higher
horizontal velocity values.
E. Mocskos (UBA–CONICET)
Introducción al Testing
10/06/2013
4 / 15
Otro ejemplo
determine the distribution of water on Mars
monitor the daily weather and atmospheric conditions
record changes on the martian surface due to wind and
other atmospheric effects
determine temperature profiles of the atmosphere
monitor the water vapor and dust content of the
atmosphere
look for evidence of past climate change.
The Mars Climate Orbiter was launched aboard a Delta 7425 in December 1998, and arrives
at Mars in September 1999. Burnout of the 3rd stage is followed by yo-yo despin of the
entire stack, followed by spacecraft separation. At this point both the spacecraft and upper
stage have been injected onto a Type 2 trajectory whose aimpoint is biased away from the
nominal Mars Orbit Insertion (MOI) aimpoint, to assure that the upper stage has less than
a 1E- 4 probabilty of impacting Mars, as required by Planetary Protection regulations.
E. Mocskos (UBA–CONICET)
Introducción al Testing
10/06/2013
5 / 15
¿Qué pasó con el Mars Climate Orbiter?
La misión estaba controlada por una computadora de alta gama: un procesador IBM
RAD6000 capaz de realizar operaciones a 5MHz, 10MHz y 20MHz.
Los datos se almacenaban en una memoria de trabajo RAM de 128MB y se usaba
un disco FLASH de 128MB para los datos permanentes.
La memoria flash se usaba para almacenar copias por triplicado de los datos crı́ticos
(i.e. el sistema de control de vuelo).
The contractor who was given the responsibility of planning the navigation system
got the specifications from NASA but instead of using the metric system, he carried
out measurements using imperial units.
What happened was that the space craft crashed into Mars and over 600 million
dollars were lost:
$327,6 million total for the orbiter and lander
$193,1 million for spacecraft development
$91,7 million for launching
$42,8 million for mission operations
E. Mocskos (UBA–CONICET)
Introducción al Testing
10/06/2013
6 / 15
Program testing can be used to show the presence of bugs, but never to show their
absence!
Edsger Wybe Dijkstra (5 de Noviembre de 1930 - 6 de Agosto de 2002).
Computólogo holandés (uno de los héroes de la Computación). En 1972 ganó el premio
Turing.
E. Mocskos (UBA–CONICET)
Introducción al Testing
10/06/2013
7 / 15
Objectivos del testing
Es una de las técnicas dinámicas de verificación de software:
Testing es el proceso de ejecutar un programa con el fin de encontrar un error.
Busca verificar que el programa satisface los requerimientos
Busca identificar diferencias entre el comportamiento real y el comportamiento
esperado
Un buen caso de test es aquel que tiene una alta probabilidad de encontrar un error
que no se conocı́a hasta el momento.
Un test exitoso es aquel que descubre un error que no habı́a sido reportado.
Importante
¡Hacer testing no es probar corrección del programa!
¡Qué el sistema pase los casos de test no significa que no queden bugs!
E. Mocskos (UBA–CONICET)
Introducción al Testing
10/06/2013
8 / 15
¿Cómo se hace?
Se debe saber cuál es la salida esperada del programa para una dada entrada
(oráculo).
Se ejecuta el programa.
Se compara la salida real con la esperada.
Si dio bien: ¡Joya!
Si dio mal: ¡¡Mejor!!
E. Mocskos (UBA–CONICET)
Introducción al Testing
10/06/2013
9 / 15
Dificultades
Una de las mayores dificultades es encontrar un conjunto de tests adecuado:
Sea lo suficientemente grande para abarcar el dominio y maximizar la probabilidad
de encontrar errores.
Sea lo suficientemente pequeño para poder ejecutar el proceso de testing con cada
elemento del conjunto y minimizar el costo del testing (ahorrar dinero).
E. Mocskos (UBA–CONICET)
Introducción al Testing
10/06/2013
10 / 15
Test de requerimientos no funcionales
Algunos ejemplos:
Test de seguridad: validando disponiblidad, integridad y confidencialidad de datos y
servicios.
Test de performance: validando los tiempos de acceso y respuesta del sistema
Test de stress: validando el uso del sistema en sus lı́mites de capacidad y verificando
sus reacciones más allá de los mismos
Test de usabilidad: cómo responde el usuario.
E. Mocskos (UBA–CONICET)
Introducción al Testing
10/06/2013
11 / 15
Niveles de test
Se organizan los casos de test de manera jerárquica:
Test de sistema (o subsistema)
Test de integración
Test de unidad
Cada uno busca cubrir distintos aspectos del sistema.
E. Mocskos (UBA–CONICET)
Introducción al Testing
10/06/2013
12 / 15
Test de sistema
Se evalúa que el sistema como un todo cumpla con los requerimientos especificados.
Se usa al sistema sin tomar en cuenta caracterı́sticas de cómo está diseñado ni
implementado.
Este nivel de testing toma todos los componentes integrados con los dispositivos de
hardware (si los hubiera) para formar el sistema que serı́a el producto a entregar.
Muchas veces, no solo se prueba el diseño, pero también las expectativas que el
usuario/cliente tenı́a sobre el sistema.
E. Mocskos (UBA–CONICET)
Introducción al Testing
10/06/2013
13 / 15
Test de integración
Test orientado a verificar que las partes de un sistema que funcionan bien
aisladamente, también lo hacen en conjunto Se pone el foco en la comunicación o
interacción entre las partes del sistema.
Unimos y testeamos partes ya testeadas (que se suponen correctas) La “estrategia”
depende del tipo de sistema.
Para poder realizar los tests, muchas veces hay que desarrollar mucho código solo para
esto. Hay dos tipos de programas auxiliares:
1
Driver simula las llamadas. Es un módulo que se dedica a llamar a las funciones del
otro módulo con los distintos valores que se quieren probar.
2
Stub simula el subprograma. Es un módulo en el que se responden las llamadas de
las distintas funciones de un modo fijo o muy simple (depende del caso).
En total, todo esto exige un gran esfuerzo de programación... además quién nos puede
asegurar que el código generado para probar no tenga errores.
E. Mocskos (UBA–CONICET)
Introducción al Testing
10/06/2013
14 / 15
Testing de Unidad
Ataca el nivel más bajo en cuanto a complejidad del sistema:
Se realiza sobre una unidad de código pequeña, claramente definida (se lo define
como unidad, de ahı́ el nombre).
En general es llevado a cabo por los mismos desarrolladores.
Hay dos estrategias fundamentales para testear:
1
Test de Caja Blanca: es una metodologı́a que usa el código mismo a probar para
derivar (generar) los casos de tests. Posibles opciones (o criterios de cobertura):
buscar que todos los caminos independientes dentro de un módulo sean atravesados al
menos una vez.
Hacer que todos los if evalúen a las dos opciones al menos una vez.
Se ejecuten todos los ciclos en sus valores lı́mites (que llegue hasta el final)
Utilicen todas las estructuras internas para asegurarse que funcionan.
2
Test de Caja Negra: considera solo la interface pública del módulo, programa o
tipo. La idea es jugar con las entradas y las salidas para verificar que funciona.
Normalmente se realiza por el grupo de desarrollo (aunque no por el mismo
programador para que no meta mula).
E. Mocskos (UBA–CONICET)
Introducción al Testing
10/06/2013
15 / 15