Survey sui Framework per Testing di

Sistemi Basati su Web Services

Severoni FrancescoFacoltà di Scienze

Dipartimento di InformaticaUniversità degli Studi - L’Aquila

67100 L’Aquila, Italia

Argomenti Trattati • Introduzione• Coyote: un framework basato su XML• Test Harness: testing funzionale, del carico di lavoro e delle

performance• Auditorium: framework per testare l’interoperabilità dei Web Services• Tecnica di progressive group testing• Automatic conformance testing• Testing di Web Services basato sui contratti • Stress test in applicazioni Web Services • Testing dei Web Services basato sugli Scenari, con l’utilizzo di agenti

distribuiti• Classificazione dei Framework• Conclusioni

Introduzione• Architetture Orientate ai Servizi e Web Services sono le tecnologie emergenti che

hanno ereditato complessivamente vantaggi e svantaggi dell’approccio basato su componenti, potenziando gli aspetti di libera associazione, distribuzione e dinamismo di componenti

• I Web Services supportano comunicazioni interoperabili fra applicazioni software

• La rilevanza dell’interoperabilità è messa in luce dall’emergenza delle iniziative WS-I, un consorzio che raggruppa le organizzazioni più importanti nella comunità Web Services

• L’obiettivo delle WS-I è l’introduzione di regole e profili specifici che dovrebbero ridurre i problemi di interoperabilità, per lo meno a livello di formati dei messaggi

• WS-I ha definito un profilo base che specifica differenti regole, anche nell’organizzazione degli aspetti, e delle relazioni che devono essere considerare tra le parti di informazioni contenute nei relativi file WSDL, messaggi SOAP e UDDI entries, per facilitare la comunicazione fra diversi servizi.

Web Services & Testing

“ Un Web services è un sistema software, modellato per permetterel’interoperabilità macchina macchina.

Ha una interfaccia descritta in un formato WSDL. Altri sistemi interagiscono con il Web Service nel modo prescritto dalla sua descrizione,

usando messaggi SOAP, tipicamente convertiti con l’uso di Http e serializzazione XML insieme agli altri standard relativi al Web ”

“Il Testing è la verifica dinamica del comportamento di un sistema, eseguita su un insieme finito di casi di test, opportunamente selezionati fra un dominio di input,

rispetto alla specifica di un comportamento atteso”

Testing di Web Services• Disciplina immatura

• Forte bisogno di ricerca, sia nel campo accademico che in quello industriale

• La ricerca non da attenzione alla comunità di testing dei WSs• Cause:

• Continua sovrapposizione con gli altri paradigmi emergenti ( CBSE)• Dettagli tecnici che questa disciplina implica

• Il testing dei Web Services é una disciplina difficile• Architetture debolmente accoppiate richiedono alta qualità• Comportamento run time: scoperta e collegamento con altri Web Services• Invocazioni da unità sconosciute, con richieste imprevedibili tra fornitore e richiedente• Esecuzione concorrente e condivisione di oggetti• Problemi di performance• Problemi di sicurezza

Concetti Base• L’architettura dei Web Service è basata su tre elementi principali:

• WSDL (Web Service Description Language): linguaggio usato per descrivere WSs

• Basato su XML• Specifica:

• Servizi offerti, • Punti di accesso, • Formato dei parametri di input/output • Meccanismi usati per scambiare i messaggi

• UDDI (Universal Description and Discovery Integration): tecnologia sviluppata dal consorzio OASIS

• Definisce un meccanismo comune per fornire e recuperare le informazioni dei WS

• SOAP (Simple Object Access Protocol): protocollo usato per scambiare messaggi basati su XML

• Fornisce la comunicazione tra Web Services

• Coinvolge 3 Attori

• Service Requestor • Responsabile dell’invocazione del servizio• Localizza il Web Service attraverso il service broker• Invoca i servizi e li esegue

• Service Broker• Comunemente conosciuto come registro dei servizi• Responsabile della registrazione, ricerca e localizzazione dei servizi

• Service Provider• Responsabile dello sviluppo e della pubblicazione del Web Service attraverso il

Service Broker

Architettura dei Web Services

COYOTEFRAMEWORK DI TESTING

BASATO SU XML

Coyote: un Framework di Testing basato su XML

• Usato per testare Web Services in modo rapido

• Composto da due componenti:

• Test Master: permette ai tester di specificare gli scenari ed i casi di test.

• Permette di eseguire analisi: • delle dipendenze, • di completezza e di consistenza,

• e convertire le specifiche WSDL in scenari di test

• Test Engine: interagisce con il Web Service sotto test e fornisce le informazioni esaminate

• Si focalizza sul testing di integrazione

Architettura di Coyote• Test Master

• Mappa le specifiche WSDL in scenari di test

• Estrae le informazioni dalle interfacce del file WSDL e mappa gli scenari di test

• Test Engine • Legge lo script di test prodotto dal

test master ed esegue il test sul Web Services

• Registra traccia dell’esecuzione• Invia i risultati al test master

WS’S TEST HARNESSA FUNCTIONAL, LOAD, AND

PERFORMANCE TESTING FRAMEWORK FOR WSs

Web Service's Test Harness

• Supporta: • Testing delle performance, • Testing del carico di lavoro• Stress testing • CHO testing (ore continue di

operazione) per Web Services.

• E’ un framework configurabile

• Permette la simulazione di utenti multipli

• Può variare il numero di iterazioni dei casi di test

THE AUDITION FRAMEWORK FOR TESTING WSs

INTEROPERABILITY

The Audition Framework: per testare l’Interoperabilità dei WSs

• Estendere il ruolo dell’ UDDI dal corrente servizio di directorypassivo

• Valida i comportamenti dei WSs prima della registrazione reale

• Si focalizza sull’ interoperabilità dei WSs

• L’audizione dipende dalle specifiche del Web Service

• Propone l’estensione del WSDL• Introduzione di Protocol State Machine: diagramma di comportamento

appena introdotto in UML 2.0

Protocol State Machine• Introdotto in UML 2.0 allo scopo di supportare lo

sviluppo basato su componenti

• E’ un particolare tipo di macchina a stati che si focalizza su

• Transazione• Stati • Regole

• Dirige l’ordine di esecuzione delle operazioni

• Fornisce regole chiare per descrivere interazioni di comunicazione tra differenti oggetti

• Etichette sulle transizioni• [ pre condizione]operazione/[post condizione]

Architettura dell’Audition

TESTING WSs USING PROGRESSIVE GROUP

TESTING

Testing Web Services usando Progressive Group Testing

• Si focalizza sullo unit, e sull’integration testing

• Propone tecniche di progressive group testing• Testare un numero elevato di WSs

• L’idea è testare in gruppo i WSs che realizzano stesse funzionalità• Aumento progressivo dei casi di test

• Consiste di due fasi: • Prescreening • Testing group a run time

• Prescreening: processo veloce e sbrigativo• Elimina immediatamente i candidati improbabili

• La fase di group testing: processo elaborato• I risultati del test sono valutati con un meccanismo di voto basato su una

maggioranza pesata• Obiettivo: selezionare il WS migliore fra tutti quelli disponibili

• Il servizio di voto è usato come oracolo: principio di maggioranza

• Peso del Web Service entrante = 0

• Peso degli altri Web Service = Reliability

• Il peso di un WS aumenta se l’output prodotto è uguale all’output di maggioranza

• La raffinatezza del testing aumenta progressivamente ed il vincitore finale sarà testato in maniera rigorosa

• Le strategie per escludere un Web Service si basano sul

• Numero di Casi di Test che un Web Service fallisce ad un livello della gerarchia• Criticità dei Casi di Test che un Web Service fallisce ad un livello della gerarchia• Importanza dei Casi di Test che un Web Service fallisce ad un livello della gerarchia

• Per ogni strategia ci sono differenti livelli di tolleranza

Testing Web Services usando Progressive Group Testing

Progressive Group Testing e Group testing Schema

• CSn è un composite service composto da S1, s2,…,Sn

• S1 è funzionalmente equivalente a S11, S12,…,S1m

• S1 viene valutato

• Il numero di casi di test applicato ad un Web Service aumenta in maniera progressiva rispetto al livello della gerarchia

AUTOMATIC CONFORMANCE TESTING OF WSs

Automatic Conformance Testing di Web Services

• Esegue conformance e stress testing

• Introduce agenzie di high-quality service discovery• forniscono garanzie sulla compatibilità delle interfacce e

l’implementazione dei servizi

• Utilizza discovery service• per il testing automatico • per la validazione dei WS prima della fase di registrazione

• Prevede l’ aumento della descrizione sintattica e comportamentale del servizio

• Utilizzo di regole GT• specificano le operazioni individuali del servizio

Dinamica dell’AutomaticConformance Testing

1. P fa l’upload del documento WSDL e delle regole GT

2. U genera automaticamente un insieme di specifiche di test dalle regole GT

3. I casi di test concreti, sono generati ed eseguiti in remoto usando la testing interface T

4. I risultati dei casi di test sono giudicati sulla base dei

• Risultati ritornati • Stati concettuali del servizio

• P = Fornitore • U = Discovery Service

Descrizione dei Web Services con Regole GT

• Modellano il comportamento del servizio fornito, ed i requisiti del client

• Raffinano le signature del servizio• specificando l’utilizzo e la modifica dei parametri e dei dati interni

• Specificano i comportamenti del Web Services a livello concettuale

• Note:

• Lo stato del servizio di cui è descritta l’evoluzione, non coincide con lo stato concreto dei dati

• Il testing è eseguito sull’implementazione del Web Services

• I casi di test sono generati dalla specifica

• Il testing è quindi usato per dimostrare la conformità della specifica con l’implementazione

Generazione di Casi di Test• L’idea è generare casi di test per testare:

• la conformità dell’implementazione con l’utilizzo di regole individuali• generare sequenze di test “stressando” le interazioni fra le regole

• E’ possibile fare una distinzione fra • Generazione dei casi di test per servizi singoli, • Generazione di test per sequenze di operazioni.

• La generazione dei casi di test per servizi singoli usa una strategia basata sul dominio, conosciuta anche come partition testing

• La generazione di casi di test per sequenze di operazioni, garantisce che lo stato del sistema evolverà secondo la specifica, almeno per quanto riguarda le coppie di invocazione dei servizi.

Esecuzione di Casi di Test• Un caso di test ha una pre condizione

• consiste in un insieme di vincoli, i quali devono essere soddisfatti nello stato corrente

• Assumiamo che un Web Service fornisca un’interfaccia di testing con tre caratteristiche addizionali di base:

• La possibilità di settare lo stato iniziale del servizio• Un insieme di operazioni• Un’implementazione della funzione di astrazione

• Uno stato che permette l’esecuzione di un dato caso di test è ottenuto scegliendo uno stato iniziale dall’insieme degli stati forniti dal Web Service, e cercando una sequenza adeguata di richieste che cambiano lo stato scelto in uno che soddisfa la pre condizione dello stato del caso di test.

• Nell’esecuzione di un caso di test, lo stato finale del Web Service è recuperato e confrontato con lo stato finale generato dalle regole, nel caso siano uguali il caso di test è stato superato con successo.

TOWARD CONTRACT-BASED TESTING OF WSs

Testing basato sui Contratti

• Il meccanismo per realizzare questa visione architettura aperta e dinamica conta su due assunzioni:

• Che i servizi forniti siano funzionalmente corretti rispetto alle loro descrizioni

• Che il “matching” fra descrizioni ed esigenze sia sufficiente per stabilire l’interoperabilità fra fornitore e richiedente.

• Design by Contract è una tecnica OO che ha delle somiglianze nell’instaurare contratti legali

• Un contratto descrive cosa una componente si aspetta dai suoi client e cosa un client può aspettarsi dalla componente

Contratti• Un contratto è definito tipicamente con asserzioni e concetti associati

• Una asserzione è una espressione booleana valutata a run time durante l’esecuzione del sistema.

• In un sistema software valido, tutte le asserzioni sono valutate a vero

• Nel design by contract identifichiamo tre tipi di asserzioni:

• Pre Condizione: specifica le condizioni da considerate prima dell’esecuzione di un operazione

• Post Condizione: valutate dopo il completamento di una operazione

• Invariant: valutato sempre prima e dopo l’esecuzione di una operazione

Contratti

• Durante il processo di sviluppo di un Web Service siamo di fronte alla rappresentazione di tre livelli differenti di contratti:

• Livello Implementazione: gli attuali Web Services, sono nella maggior parte dei casi basati su linguaggi di programmazione orientati agli oggetti, e la maggior parte di questi linguaggi supporta solo contratti sintattici

• Livello XML: i linguaggi di descrizione dei Web Service definiscono le interfacce come una collezione di porte, in termini di signature e operazioni

• Livello di modello: il cui scopo è derivare contratti a livello di implementazione in modo automatico dalle specifiche e cioè dal modello

Specifiche di Contratti basate su modelli

• Un modello di un Web Service dovrebbe comprendere

• Interfacce fornite• Modello di dati visibili all’esterno del servizio (tutti i tipi di dati necessari per

comunicare con i suoi clienti)• Operazioni offerte dal servizio

• Per descrivere un’interfaccia sono state usate interfacce UML

• Per rappresentare i modelli di dati di si utilizzano Class Diagram

• Ai Class Diagram si applicano Regole GT

Contratti Forniti e Richiesti• Fornitore

• La parte sinistra della regola specifica le pre condizioni

• La parte destra della regola descrive la post condizione

• Richiedente• La parte sinistra della regola

rappresenta l’informazione che questo è disposto a fornire al servizio

• La parte destra della regola rappresenta la situazione che questo vuole raggiungere usando il servizio.

In Conclusione• Usare design by contract, a livello di implementazione è un modo per introdurre

informazioni delle specifiche nel codice stesso

• Questo approccio si interessa al testing funzionale derivato dai contratti

• Assicura che il prodotto consegnato corrisponda alle specifiche

• Ha senso usare i contratti forniti • per la creazione di casi di test • che per l’oracolo del test

• Potrebbe divenire impossibile o troppo costoso chiamare altri Web Services al solo scopo del testing

• Obiettivo del framework: usare i contratti richiesti per guidare la simulazione

STRESS TESTING WEB SERVICES

Stress Testing su Web Services• Lo stress testing è un metodo valido per scoprire difetti di codice

• Creato per “affaticare” il software allocando un carico di lavoro molto elevato

• Può scoprire bug poco noti, che altre tecniche di testing non avrebbero mai rilevato

• Considerato uno dei Testing più efficienti

• Il processo è spesso confuso da altri elementi del sistema o di testing funzionali

• I metodi impiegati, a volte, non sono correttamente implementatioppure non hanno un giusto approccio

Bug Rilevati dallo Stress Testing• Ci sono diversi tipi di bug che ci si aspetta di scoprire con lo stress

testing

• Due di questi sono:

• Memory Leaks: estremamente difficile da rilevare con l’utilizzo di semplici test funzionali. Richiede la ripetizione in successione di operazioni, al fine di un consumo elevato di memoria

• Concorrenza e Sincronizzazione: i test di stress primeggiano nella scoperta di problemi di concorrenza, dovuti ai differenti percorsi nel codice e alle condizioni temporali.Come regola generale, uno stress test esegue il più a lungo possibile, tutte, o quasi tutte le combinazioni dei “path” del codice, al fine di rilevare i problemi di concorrenza e sincronizzazione

Condizioni dello Stress Testing• Ci sono quattro condizioni di base che i test di stress dovrebbero

applicare:

• Ripetizione = Esecuzione ripetuta di una operazione (condizione più ovvia)

• Concorrenza = Esecuzione simultanea di differenti operazioni• In pratica si eseguono diversi test nello stesso momento

• Dimensioni = Ammontare del carico di lavoro applicato ad ogni singola operazione

• Variazione Casuale = Elemento di casualità d’ordine.

SCENARIO-BASED WEBSERVICE TESTING WITH

DISTRIBUTED AGENTS

• Fornisce caratteristiche per effettuare testing funzionale e nonfunzionale

• Propone• Verifica Automatica del Servizio con la Registrazione UDDI• Estendere WSDL

• Dipendenze di input-output;• Sequenze di invocazioni;• Descrizioni funzionali gerarchiche;• Specifiche di sequenze concorrenti.

• Scoperta e collegamento dinamico di WSs• Analisi di Sistema• Simulazione

Testing di WSs basato sulloScenario con Agenti Distribuiti

Analisi e Specifica dello Scenario• L’interoperabilità dei Web Services definisce tre

scenari di interazione • One-Way• Richiesta/Risposta Sincrona• Basic Callback

• Per derivare gli scenari, il tester può usare tre passi• Derivare le specifiche dello scenario per ogni sottosistema• Specificare le interazioni fra ogni coppia di sottosistemi• Derivare gli scenari globali per il sistema distribuito

combinando gli scenari per i sottosistemi individuali

Testing di WSs basato sulloScenario con Agenti Distribuiti

• Test Master• Amministra le informazioni d’interazione e dipendenza tra i sistemi• Genera gli script dei test e i casi di test • Inizia il testing• Verifica la struttura di interazione

• Test Agent• Mappa le pre condizioni e gli eventi degli script dei test • Esegue il testing• Verifica i risultati confrontandoli con le post condizioni• Invia i risultati del test al testMaster

• Test Monitor• Controlla lo scambio dei messaggi • Traccia i cambiamenti di stato del sistema

Componenti Utilizzate

Algoritmo di Esecuzione• Un tester specifica uno o un gruppo di scenari, ed inizia l’esecuzione

• Il test master carica i dati dello scenario

• Il test master genera gli script di test con i dati dello scenario

• Il test master richiede al test agent di eseguire la funzione di sistema

• Il test agent unisce e invoca la funzione del sistema

• Il test monitor cattura i messaggi scambiati fra i sistemi, ed i cambiamenti di stato del sistema

• Il test monitor cattura le informazioni e le rimanda al test master e al test agent

• Il test master colleziona le informazioni relative allo scenario e verifica i risultati del test e l’interazione fra i sistemi

ANALISI E CONFRONTO DEI FRAMEWORK ANALIZZATI

Componenti usate dai Framework

• Test Master: genera gli script e i casi di test; invia i commenti ai test agent;

• Test Agent: esegue e verifica i risultati del testing;• Test Monitor: controlla lo scambio dei messaggi fra

richiedenti e fornitore.

Testing di Web Service basato sullo Scenario con Agenti Distribuiti

• Configurator: fa il setting iniziale del test;• Runtime Engine: amministra gli altri sottosistemi;• Report Generator: processa i risultati dei test.

Web Service's test Harness:

• Test Master: permette ai tester di specificare gli scenari e i casi di test, così come eseguire le diverse analisi;

• Test Engine: interagisce con il WS sotto test e fornisce le informazioni esaminate.

Coyote: An XML-Based Framework

• WS- I Monitor: piazzato fra client e WS, registra tutti i messaggi: richieste e risposte;

• WS- I Analyzer: controlla ogni messaggio nel registro in previsione dei requisiti di interoperabilità.

Testing Web Services Using Progressive Group Testing

Componenti UsateFramework

Stakeholder Interessati nel Testing dei Web Services

• Principalmente ci sono tre tipi di stakeholder:

• Sviluppatori di Web Services (Service Provider)• Interessato nella valutazione del risultato, ed in particolare se questo

corrisponde al risultato aspettato• Valutazione in termini di funzionalità, interazione con altre componenti, e

qualità del servizio

• Fornitore Intermediario del Servizio (Service Broker Provider)• Interessate nel testing dei Web Services prima della registrazione

• Agenzie di Standard (Standards Body)

• Definiscono generalmente interfacce chiare per specificare servizi, allo scopo di aumentare le probabilità che i servizi sviluppati indipendentemente potranno essere in grado di interoperare correttamente

Stakeholder Interessati nel Testing dei Web Services

XXXTesting di Web Service basato sullo Scenario con Agenti Distribuiti

XXXStress Testing Web Services

XXTowards Contract-based Testing of Web Services

XXAutomatic Conformance Testing of Web Services

XWeb Service's Test Harness

XCoyote: An XML-Based Framework for WebServices Testing

XXXTesting Web Services Using Progressive Group Testing

XXAudition Framework for Testing Web Services Interoperability

Agenzia diStandard

FornitoreIntermedioSviluppatoreFramework

Documenti Utilizzati per Derivare i Casi di Test

• Il documento su cui si basano i casi di test è il file WSDL • Basato su XML

• Le informazioni all’interno del file WSDL specificano• Servizi offerti• Punti di accesso, • Formato dei parametri di input/output• Meccanismi usati per scambiare i messaggi

• Queste informazioni sono usate per derivare casi di test, con cui verranno, poi, testati i Web Services

• Conclusione comune a tutti i framework• Insufficienza e l’inadeguatezza delle specifiche WSDL nel fornire

informazioni adeguate su cui fondare i casi di test

Specifiche Utilizzate e Tipo di Estensioni Proposte

•File WSDL + Proposta di Estendere WSDLTesting di Web Service basato sullo Scenario

con Agenti Distribuiti

Stress Testing Web services

•File WSDL + ContrattoTowards Contract-based Testing of Web Services

•File WSDL + Regole GTAutomatic Conformance Testing of Web Services

Web Service's test Harness

•File WSDLCoyote: An XML-Based Frameworkfor Web Services Testing

•File WSDL + Proposta di Estendere WSDLTesting Web Services Using Progressive Group Testing

•File WSDL + Protocol State Machine (PSM)The Audition Framework for Testing Web Services Interoperability

Specifiche e Documenti UtilizzatiFramework

Tipi di Estensioni Proposte• Protocollo State Machine

• Diagramma di comportamento UML • Particolare tipo di macchina a stati • Si focalizza nelle transazioni di stati e nelle regole• Dirige l’ordine di esecuzione delle operazioni

• Regole GT: • specificano i comportamenti del Web Services a livello concettuale• Raffina la signature del servizio• A livello di modello, lo stato è rappresentato da un grafico degli attributi,

visualizzato come un Object Diagram UML

• Contratto: • accordo formale, in cui vengono espressi diritti e doveri di entrambe le parti• Descrive cosa le componenti si aspettano dai Client e cosa questi possono

aspettarsi dalle componenti

Tipo di Testing Supportato• Prima classificazione

• Testing basato su codice • Structural testing

• Testing basato sulla specifia• Functional o conformance testing

• Seconda classificazione

• Unit Testing• Integration Testing• System Testing

• Recovery testing• Security testing• Stress testing • Testing delle performance

• Regression testing• Usato, di solito per verificare le funzionalità del sistema dopo aver effettuato

modifiche.

Tipo di Testing Supportato

Regression Testing

Testing Funzionale

Testing Carico di Lavoro

Testing Performance

Stress Testing

Unit Testing

Testing di Integrazione

Vantaggi e Innovazioni

• Supporta diversi tipi di testing: performance, carico di lavoro, stress testing e CHO testing;

• Si sta pensando di estendere Harness per applicazioni all’infuori dei WSs.

Web Service's test Harness:A Functional, Load, and

Performance Testing Framework for Web Services

• Testa i WSs in modo rapido;• Fornisce supporti per il regression testing;• Può essere configurato per effettuare semplici test o testing

distribuito.

Coyote: An XML-Based Frameworkfor Web Services Testing

• Introduce un sistema di voto pesato con il quale si costruisce l’oracolo;

• I pesi dei voti si basano sull’affidabilità dei WSs sotto test;• Testa un gran numero di WSs;• I WSs sono valutati sulla base di misure oggettive;• Solo il migliore WS viene accettato;• Il testing viene effettuato mentre il WS sta lavorando realmente

nell’ambiente operazionale reale, quindi non richiede tempo supplementare.

Testing Web Services Using Progressive Group Testing

• Estende il ruolo dell’UDDI dal vecchio servizio di directory passivo;• Valuta dinamicamente l’interoperabilità dei WS;• Migliora le specifiche dei WS con i protocol state machine (PSM);• Garantisce che tutti i servizi registrati possono collaborare.

The Audition Framework for Testing Web Services Interoperability

Vantaggi e InnovazioniFramework

Vantaggi e Innovazioni

• Verifica automatica del servizio con la registrazione;• Aggiunge quattro tipi di estensioni al WSDL: dipendenze di

input/output, sequenze di invocazioni, descrizione funzionale gerarchica e specifiche di sequenze concorrenti di sequenze;

• Scoperta e collegamento dinamico dei WSs;• Permette le seguenti analisi: completezza e consistenza, dei rischi,

della tempestività, dell’uso, e delle dipendenze.• Migliora il servizio UDDI;• Permette testing funzionale e non funzionale.

Testing di Web Service basato sulloScenario con Agenti Distribuiti

• Riesce a scoprire bug che altri testing non riescono a trovare;• Fondamentale per migliorare la qualità dei WSs.Stress Testing Web services

• Estende il WSDL con l’uso di contratti;• I contratti possono essere sviluppati su tre livelli differenti:

implementazione, XML e di modello;• Risolve i problemi: di costo nel chiamare altri WSs al solo scopo di

testare un WS ed il problema che si verifica quando il WS sotto test chiama un WS non ancora conosciuto.

Towards Contract-based Testing of Web Services

• Con questo framework il testing viene automatizzato;• Aumento della descrizione sintattica del WS.• Introduzione di regole di trasformazione grafiche per modellare il

comportamento del servizio fornito ed i requisiti del client, permettendo la generazione automatica dei casi di test;

• Per risolvere il problema dei comportamenti scorretti di fornitori “maliziosi”, introduce un servizio High-Quality Service Discovery;

• Prevede la generazione di casi di test per servizi singoli e persequenze di operazioni.

Automatic Conformance Testing of Web Services

Svantaggi e Note Negative

• Ad una prima analisi non presenta grandi svantaggi.

Web Service's test Harness:A Functional, Load, and Performance

Testing Framework for Web Services

• Ad una prima analisi non presenta grandi svantaggi.Coyote: An XML-Based Frameworkfor Web Services Testing

• Se un fornitore disonesto sottomette migliaia di WS per ottenere la maggioranza, c’è la possibilità che la maggioranza dei voti fallisca nello scegliere il miglior servizio.

Testing Web Services Using Progressive Group Testing

• Richiede uno sforzo da parte degli sviluppatori dei servizi;• La generazione automatica di un oracolo non è semplice e

richiede molte informazioni;

The Audition Framework for Testing Web Services Interoperability

Svantaggi e Note NegativeFramework

Svantaggi e Note Negative

• Non presenta note negative.Testing di Web Service basato sullo

Scenario con Agenti Distribuiti

• Non può essere visto come un Framework vero e proprio;• Non è semplici da progettare;• Richiede un’esecuzione molto lunga.

Stress Testing Web services

• I contratti sviluppati a livello di Implementazione e XML sono difficili da leggere e da scrivere;

• Lascia molte questioni aperte: come la definizione di un linguaggio basato su XML per la rappresentazione di contratti; una notazione basata su UML per contratti; ed infine un motore di simulazione per i servizi richiesti.

Towards Contract-based Testing of Web Services

• I fornitori del servizio possono fornire “maliziosamente”modelli migliori dei servizi.

Automatic Conformance Testing of Web Services

Conclusioni

• Problema dell’ inadeguatezza delle specifiche WSDL

• Idea:• Trovare un formalismo comune che risolve il problema • Inutile concentrare l’attenzione sull’architettura

• Presentazione IdealWSTF

• Impressioni sul lavoro svolto

• Realizzazione del lavoro e criteri utilizzati

DOMANDE ?