Uso de propiedades y modelos para las pruebas de sistemas distribuidos basados en la integración de componentes heterogéneos

Transcripción

1 Uso de propiedades y modelos para las pruebas de sistemas distribuidos basados en la integración de componentes heterogéneos Miguel A. Francisco 1 Laura M. Castro 2 1 Interoud Innovation S.L. (Spain) miguel.francisco@interoud.com 2 MADS Group Dept. Computer Science University of A Coruña (Spain) lcastro@udc.es 17 de Septiembre 2013, Madrid

2 VoDKATV Interoud es una compañía gallega (A Coruña) nacida en Marzo de Desarrollo de software para entornos IPTV/OTT (hospitality, telcos, etc): middleware, STB y back-end. VoDKATV es el prinicipal producto de Interoud. VoDKATV es un middleware IPTV/OTT que ofrece una experiencia interactiva al usuario a través de su televisión, PC o dispositivo móvil (smartphones, tablets, dispositivos Android, etc)

3 Interoud Pruebas de unidad Pruebas de componente Servicios VoDKATV VoDKATV ofrece una serie de servicios al usuario: Videoclub. Canales IPTV. PVR (grabación). Navegación por Internet. Juegos. etc. Pruebas de integración Conclusiones

4 Pruebas Software implementado usando diferentes lenguajes de programación: Erlang, Java, C, JavaScript, etc. Las pruebas del software permiten validar el correcto funcionamiento de nuestros sistemas. Sin embargo, muchas veces las pruebas son omitidas. Para muchos programadores, las pruebas son: Un proceso tedioso Algo para lo que nunca sobra tiempo Buscar nuevas técnicas de prueba que puedan paliar estos inconvenientes.

5 Pruebas Participación en proyectos europeos relacionados con las pruebas del software: ProTest ( ): Property-Based Testing Prowess ( ): Property-Based Testing for Web Services El rol de Interoud (anteriormente LambdaStream) es proporcionar casos de estudio reales en donde se apliquen y evalúen las técnicas y aproximaciones para probar el software. Las nuevas técnicas están basadas en el uso de propiedades Property-Based Testing.

6 Property-Based Testing (PBT) Tradicionalmente el código fuente se prueba escribiendo casos de prueba manualmente: Example remove(i: Integer, L: List<Integer>):List<Integer> Se escriben casos de prueba y se comprueba si el resultado es el correcto: Caso de prueba lists:delete(i, L) I = 5, L = [5] lists:delete(5, [5]) = [] I = 0, L = [1, 2] lists:delete(0, [1, 2]) = [1, 2]......

7 Property-Based Testing (PBT) En Property-Based Testing, las pruebas se especifican como una serie de propiedades que el software debe cumplir. Las propiedades describen los requisitos del sistema a probar. Los casos de prueba no se escriben manualmente, sino que existen herramientas que generan casos de prueba a partir de las propiedades. Example remove(i: Integer, L: List<Integer>):List<Integer> La operación remove borra todas las ocurrencias del entero I de una lista de enteros L: {I, L} {int(), list(int())}, I / remove(i, L)

8 QuickCheck QuickCheck es una herramienta de Property-Based Testing, implementada en Erlang, que automatiza la generación, ejecución y evaluación de casos de prueba. prop_remove()->?forall({i, L}, {int(), list(int())}, not lists:member(i, lists:delete(i, L))). Caso de prueba lists:delete(i, L) Propiedad I = 0, L = [] lists:delete(0, []) = [] true I = 0, L = [0, 1] lists:delete(0, [0, 1]) = [1] true I = 1, L = [1,6,1] lists:delete(1, [1, 6, 1]) = [6,1] false Cuando QuickCheck encuentra un error, intenta obtener el caso mínimo que provoca el mismo error (shrinking): {1,[1,1]}

9 Test Driven Development Test Driven Development consiste en repetir iterativamente las siguientes fases: 1 Añadir una prueba simple. 2 Ejecutar las pruebas y comprobar que falla. 3 Implementar funcionalidad hasta pasar las pruebas.

10 Test Driven Development Example Implementar una función string que reemplace las ocurrencias de los elementos por valores concretos. [{"nombre", "Miguel"}]) = "Hola Miguel"

11 Test Driven Development El primer paso consiste en implementar una prueba para dicha función (todavía sin implementación). Example?assertEqual( "Hola Miguel", lstd_template:string( "Hola [{"nombre", "Miguel"}])).

12 Test Driven Development A continuación ejecutamos la prueba: Example test: string_test (module test )...*failed* ::error:undef in function lstd_template:string/2 called as ["nombre","miguel"]) in call from test: -string_test/0-fun-0- /1 in call from test:string_test/0 =================================================== Failed: 1. Skipped: 0. Passed: 0. error

13 Test Driven Development Finalmente implementamos la función para que pase la prueba: Example string(string, Subs) -> "Hola Miguel".

14 Test Driven Development Ejecutamos de nuevo la prueba: Example Test passed. ok

15 Test Driven Development Seguimos añadiendo más pruebas: Example?assertEqual( "Hola Miguel", lstd_template:string( "Hola [{"nombre", "Miguel"}])).?assertEqual( "Hola Laura", lstd_template:string( "Hola [{"nombre", "Laura"}])).

16 Test Driven Development Ejecutamos las pruebas y refinamos la implementación: Example test: string2_test...*failed* ::error:{assertequal_failed, [{module,test}, {line,15}, {expression, "lstd_template : string ( [ \"nombre\", \"Laura\" ] )"}, {expected,"hola Laura"}, {value,"hola Miguel"}]} in function test: -string2_test/0-fun-0- /1 =================================================== Failed: 1. Skipped: 0. Passed: 1. error

17 Test Driven Development + Property Based Testing Qué casos de prueba usar? Textos vacíos: "" Textos Textos con líneas en blanco: \n etc. Hay demasiados casos límites, incluso para módulos sencillos. Usando Property Based Testing, los casos de prueba son generados automáticamente.

18 Test Driven Development + Property Based Testing Example prop_string_empty_list() ->?FORALL( S, string(), S =:= lstd_template:string(s, [])). Caso de prueba String = Â/e", Subs = [] String = [], Subs = [] String = "U", Subs = [] String = "ðqa", Subs = []...

19 Test Driven Development + Property Based Testing specify requirement [incorrect specification] transform requirement into property test implementation against properties modify implementation [bug in property] [bug in implementation] [ok] [test fail] analyze failure [bug in specification]

20 Arquitectura de VoDKATV: integraciones Las integraciones entre componentes se realiza mayoritariamente a través de servicios web. Admin Core Backend AdminGUI Third-party app HTTP/XML VoDKATV-server HTTP/JSON EPG-server Java Asset-Manager HTTP/XML Client HTTP/JSON Erlang Device JDBC Database Third-party app Third-party app HED-STB PC Tablet

21 API de integración Los componentes provee de una API de integración. Uso de Property Based Testing para probar APIs de integración. En concreto, uso de máquinas de estado QuickCheck para especificar cómo debe funcionar el protocolo de comunicación.

22 API de integración Una API de integración está formada por una serie de operaciones: API = {op 1, op 2,..., op o } Cada operación op i : recibe una serie de parámetros devuelve un resultado tiene una serie de precondiciones que deben ser válidas para poder ejecutar la operación tiene una serie de postcondiciones que deben ser válidas después de ejecutar la operación

23 Servicios web Cuando la API de integración es un servicio web, cada operación es una URI. Petición: Método: GET, POST, PUT, HEAD, DELETE. Cabeceras (Accept-Language, Cookie, Date, etc). Parámetros. Respuesta: Cabeceras (Location, Pragma, Set-Cookie, etc). Cuerpo de la respuesta (XML, JSON).

24 Servicios web Por ejemplo: POST <?xml version="1.0" encoding="utf-8"?> <room> <roomid>room_id</roomid> <description>description</description> </room> GET GET GET

25 Pruebas de servicios web SUT QuickCheck State Machine WS Connector HTTP WS

26 La máquina de estados QuickCheck -behaviour(eqc_statem).... % Definir la lista de operaciones command(s) -> oneof( [{call,?module, createroom, [gen_room()]}] ++ [{call,?module, findroombyid, [gen_roomid()]}] ++ [{call,?module, findallrooms, []}] precondition(s, {call,?module, createroom, Room})->... % Normalmente true postcondition(s, {call,?module, createroom, Room}, R)-> % Chequear postcondición para la operación createroom createroom(room)-> % Invocar GET findroombyid(roomid)-> % Invocar GET

27 La máquina de estados QuickCheck QuickCheck genera automáticamente secuencias de operaciones cumpliendo las precondiciones. QuickCheck ejecuta las secuencias de operaciones, comprobando las postcondiciones para cada operación. GET POST <?xml version="1.0" encoding="utf-8"?> <room> <roomid>a</roomid> </room> GET GET GET GET GET GET

28 La máquina de estados QuickCheck Generación automática de la máquina de estados QuickCheck a partir de una descripción del servicio web a probar. WSDL + OCL Generator SUT QuickCheck State Machine WS Connector HTTP WS

29 Pruebas de integración Los componentes software suelen estar estructurados en diferentes módulos. Las interacciones entre los módulos también deben ser probada. QuickCheck module SUT <<use>> Other component

30 Pruebas de integración Con Property Based Testing es posible generar secuencias de operaciones que nos permitan comprobar que se están realizando las llamadas correctas en otros módulos. La prueba de integración no requiere el uso del componente real integrado: se evitan efectos colaterales. QuickCheck module SUT <<use>> Mock component

31 Conclusiones El uso de Property Based Testing nos permite probar más casos de prueba escribiendo menos código de pruebas. El uso de Test Driven Development junto con Property Based Testing nos permite aumentar la cobertura de nuestras pruebas. Uso de QuickCheck como herramienta de Property Based Testing. Uso de Erlang como lenguaje de especificación de pruebas.

32 Uso de propiedades y modelos para las pruebas de sistemas distribuidos basados en la integración de componentes heterogéneos Miguel A. Francisco 1 Laura M. Castro 2 1 Interoud Innovation S.L. (Spain) miguel.francisco@interoud.com 2 MADS Group Dept. Computer Science University of A Coruña (Spain) lcastro@udc.es 17 de Septiembre 2013, Madrid