Survey sui Framework per Testing di Sistemi Basati su Web Services

Транскрипт

1 Survey sui Framework per Testing di Sistemi Basati su Web Services Severoni Francesco Facoltà di Scienze Dipartimento di Informatica Università degli Studi - L Aquila L Aquila, Italia

2 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

3 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.

4 Web Services & Testing Un Web services è un sistema software, modellato per permettere l 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

5 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

6 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

7 Responsabile dello sviluppo e della pubblicazione del Web Service attraverso il Service Broker Architettura dei 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

8 COYOTE FRAMEWORK DI TESTING BASATO SU XML

9 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

10 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

11 WS S TEST HARNESS A FUNCTIONAL, LOAD, AND PERFORMANCE TESTING FRAMEWORK FOR WSs

12 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

13 THE AUDITION FRAMEWORK FOR TESTING WSs INTEROPERABILITY

14 The Audition Framework: per testare l Interoperabilità dei WSs Estendere il ruolo dell UDDI dal corrente servizio di directory passivo 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

15 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]

16 Architettura dell Audition

17 TESTING WSs USING PROGRESSIVE GROUP TESTING

18 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

19 Testing Web Services usando Progressive Group Testing 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

20 Progressive Group Testing e Group testing Schema Il numero di casi di test applicato ad un Web Service aumenta in maniera progressiva rispetto al livello della gerarchia CSn è un composite service composto da S1, s2,,sn S1 è funzionalmente equivalente a S11, S12,,S1m S1 viene valutato

21 AUTOMATIC CONFORMANCE TESTING OF WSs

22 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

23 Dinamica dell Automatic Conformance 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 P = Fornitore U = Discovery Service 4. I risultati dei casi di test sono giudicati sulla base dei Risultati ritornati Stati concettuali del servizio

24 Il testing è quindi usato per dimostrare la conformità della specifica con l implementazione 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

25 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.

26 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.

27 TOWARD CONTRACT-BASED TESTING OF WSs

28 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

29 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

30 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

31 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

32 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.

33 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

34 STRESS TESTING WEB SERVICES

35 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 implementati oppure non hanno un giusto approccio

36 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

37 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.

38 SCENARIO-BASED WEB SERVICE TESTING WITH DISTRIBUTED AGENTS

39 Testing di WSs basato sullo Scenario con Agenti Distribuiti Fornisce caratteristiche per effettuare testing funzionale e non funzionale 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

40 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

41 Testing di WSs basato sullo Scenario con Agenti Distribuiti

42 Componenti Utilizzate 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

43 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

44 ANALISI E CONFRONTO DEI FRAMEWORK ANALIZZATI

45 Componenti usate dai Framework Framework Testing Web Services Using Progressive Group Testing Coyote: An XML-Based Framework Web Service's test Harness: Testing di Web Service basato sullo Scenario con Agenti Distribuiti Componenti Usate 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à. 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. Configurator: fa il setting iniziale del test; Runtime Engine: amministra gli altri sottosistemi; Report Generator: processa i risultati dei test. 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.

46 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 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)

47 Stakeholder Interessati nel Testing dei Web Services Framework Sviluppatore Fornitore Intermedio Agenzia di Standard Audition Framework for Testing Web Services Interoperability X X Testing Web Services Using Progressive Group Testing X X X Coyote: An XML-Based Framework for Web Services Testing X Web Service's Test Harness X Automatic Conformance Testing of Web Services X X Towards Contract-based Testing of Web Services X X Stress Testing Web Services X X X Testing di Web Service basato sullo Scenario con Agenti Distribuiti X X X

48 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

49 Specifiche Utilizzate e Tipo di Estensioni Proposte Framework The Audition Framework for Testing Web Services Interoperability Testing Web Services Using Progressive Group Testing Coyote: An XML-Based Framework for Web Services Testing Specifiche e Documenti Utilizzati File WSDL + Protocol State Machine (PSM) File WSDL + Proposta di Estendere WSDL File WSDL Web Service's test Harness Automatic Conformance Testing of Web Services Towards Contract-based Testing of Web Services Stress Testing Web services Testing di Web Service basato sullo Scenario con Agenti Distribuiti File WSDL + Regole GT File WSDL + Contratto File WSDL + Proposta di Estendere WSDL

50 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

51 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.

52 Tipo di Testing Supportato Regression Testing Testing Funzionale Testing Carico di Lavoro Testing Performance Stress Testing Unit Testing Testing di Integrazione

53 Vantaggi e Innovazioni Framework The Audition Framework for Testing Web Services Interoperability Testing Web Services Using Progressive Group Testing Coyote: An XML-Based Framework for Web Services Testing Web Service's test Harness: A Functional, Load, and Performance Testing Framework for Web Services Vantaggi e Innovazioni 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. 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. Testa i WSs in modo rapido; Fornisce supporti per il regression testing; Può essere configurato per effettuare semplici test o testing distribuito. 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.

54 Vantaggi e Innovazioni Automatic Conformance Testing of Web Services Towards Contract-based Testing of Web Services Stress Testing Web services Testing di Web Service basato sullo Scenario con Agenti Distribuiti 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 per sequenze di operazioni. 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. Riesce a scoprire bug che altri testing non riescono a trovare; Fondamentale per migliorare la qualità dei WSs. 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.

55 Svantaggi e Note Negative Framework The Audition Framework for Testing Web Services Interoperability Testing Web Services Using Progressive Group Testing Coyote: An XML-Based Framework for Web Services Testing Web Service's test Harness: A Functional, Load, and Performance Testing Framework for Web Services Svantaggi e Note Negative Richiede uno sforzo da parte degli sviluppatori dei servizi; La generazione automatica di un oracolo non è semplice e richiede molte informazioni; 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. Ad una prima analisi non presenta grandi svantaggi. Ad una prima analisi non presenta grandi svantaggi.

56 Svantaggi e Note Negative Automatic Conformance Testing of Web Services Towards Contract-based Testing of Web Services Stress Testing Web services Testing di Web Service basato sullo Scenario con Agenti Distribuiti I fornitori del servizio possono fornire maliziosamente modelli migliori dei servizi. 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. Non può essere visto come un Framework vero e proprio; Non è semplici da progettare; Richiede un esecuzione molto lunga. Non presenta note negative.

57 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

58 DOMANDE?