Articolo del Mese - Settembre 2008

Soa, una strategia di test

by Randy Rice

Le architetture orientate al servizio, Soa (Service-oriented architecture), sono soggette a un’attenzione sempre maggiore da parte delle imprese. Si tratta di un fenomeno dovuto alla costante ricerca di nuove modalità per essere più pronte e più flessibili nel rispondere alle necessità dei clienti, utilizzando al meglio le tecnologie nuove e quelle esistenti.
L’adozione delle tecniche Service-oriented, come strategia sia tecnologica che per l’intera impresa è in costante aumento. Negli anni più recenti, le persone coinvolte hanno focalizzato la propria attenzione sugli aspetti riguardanti lo sviluppo dell’architettura. Tuttavia, diviene sempre più evidente la necessità di sottoporre a test queste nuove soluzioni, man mano che vengono applicate, rendendosi conto che risultano molto diverse dalle altre architetture sotto molti aspetti fondamentali.

Necessaria una nuova strategia di test

Tradizionalmente, nel campo del software le strategie di test si evidenziano dopo alcuni mesi dalla definizione di quelle di sviluppo. Nel caso delle architetture Soa, anche se gli strumenti necessari sono conosciuti, la consapevolezza della necessità dei test risulta differita nel tempo.
Ogni volta che emerge una nuova tecnologia, una delle prime cose da fare è definire i test appropriati all’unicità della tecnologia stessa.

Cosa considerare nella strategia di test

L’unicità di questa architettura è evidenziata dalle modalità con le quali vengono costruiti i servizi e da come questi supportano i processi dell’impresa. Perciò, una strategia di test Soa deve necessariamente considerare sia le prospettive strutturali che quelle funzionali.

La prospettiva strutturale

Questa prospettiva di test si focalizza sulle componenti interne alla struttura Soa e può comprendere la codifica utilizzata per creare i servizi, così come gli elementi della struttura stessa.
Per molte persone, fino a oggi questa è stata l’attenzione posta ai rispettivi test Soa. Un atteggiamento che si spiega con il fatto che la creazione dei servizi fornisce la prima opportunità di test per la nuova architettura. Anche se la prospettiva strutturale dei test specifici è molto importante, rappresenta solo un aspetto dell’architettura in questione. Più avanti esamineremo gli altri tipi di test da applicare.
Un esempio di test strutturale è costituito dall’esame del Web services description language (Wsdl), ovvero del linguaggio per la descrizione dei servizi, da effettuare per rendersi conto di come gli elementi dei dati vengano forniti ai servizi. Il Wsdl utilizza Xml per descrivere i servizi di rete come un insieme di punti di arrivo delle comunicazioni, tutti in grado di scambiare messaggi gli uni con gli altri. Imparando come leggere e comprendere il linguaggio Wsdl, i responsabili dei test possono identificare molti aspetti importanti da sottoporre a verifica. Tuttavia, molte tra queste persone possono non essere in grado di dedicare molto tempo al livello del Wsdl e, quindi, a tale scopo può aiutare il coinvolgimento degli sviluppatori.

La prospettiva funzionale

I test funzionali sono necessari per essere sicuri che i servizi supportino i processi dell’impresa. I servizi possono e debbono essere sottoposti prima di tutto a test individuali, ma quelli più critici riguardano la verifica dell’integrazione tra servizi e processi dell’impresa. Fino al momento in cui i servizi non siano testati nell’ambito del contesto dei processi dell’impresa, non potrete avere la sicurezza che agiscano correttamente quando vengono chiamati a eseguire le funzioni attese.
Un esempio di questo tipo di procedimento di verifica è la modellazione dei test sulla base di transazioni e di processi di attività. Normalmente, questo modo di procedere è definito “verifica di scenario” o “verifica di processo”. In tale approccio, i processi dell’impresa vengono descritti in modo da identificare singoli scenari. I servizi che supportano ciascun scenario sono identificati in modo che possano essere testati in relazione gli uni con gli altri.

Altri tipi di test

Nel definire una strategia di test, i fattori critici di successo definiscono i rischi associati con la tecnologia o con il progetto e i tipi di verifiche da effettuare, con lo scopo di ottenere una riduzione dei rischi.
Per le architetture Soa, alcuni tra i principali fattori critici di successo sono:
Correttezza – I servizi e le architetture producono risultati corretti?
Prestazioni – L’architettura Soa fornisce i risultati attesi in maniera rapida ed efficiente?
Sicurezza – L’ambiente Soa è protetto in maniera adeguata contro eventuali attacchi esterni? I dati sono protetti nei confronti di tentativi di accesso non autorizzati?
Interoperabilità – I servizi operano insieme in un contesto di processi dell’impresa, in modo da fornire risultati corretti?
Naturalmente, esistono altri fattori di successo da poter considerare in base alle caratteristiche peculiari del vostro progetto. Tra questi, ricordiamo la facilità d’uso, la manutenibilità, l’affidabilità e la portabilità su altre piattaforme.

Gli strumenti

Gli strumenti software aggiungono una grande forza per il test di qualsiasi tecnologia, ma l’ambiente Soa possiede caratteristiche che rendono praticamente indispensabile l’uso di particolari tools. Il grande dilemma nell’utilizzo di strumenti di test Soa è se può essere esteso l’uso di tools tradizionali o se, piuttosto, sono necessari strumenti completamente nuovi.
Molto dipende dal tipo di mezzi di cui disponete correntemente e della loro capacità di gestire le necessità dei test.
Prima di investire un mucchio di denaro e di tempo nell’acquisire strumenti “specifici Soa”, procedete ad alcuni test per essere sicuri che i tools a vostra disposizione siano veramente inadatti allo scopo. Infatti, le imprese possono aver già effettuato forti investimenti in strumenti e software di test, per cui assicuratevi di considerarli correttamente prima di passare a un insieme di strumenti completamente nuovo.

Gli strumenti di test sono necessari in ambiente Soa perché:

1. Possono fornire una struttura per l’accesso a servizi che, altrimenti, sarebbe difficile sottoporre a test. Infatti, una forte difficoltà nel test dei servizi è spesso la mancanza di interfacce utenti. Questa situazione viene definita come “test senza testa” perché non esistono punti singoli di accesso ai servizi.
2. Una volta creata l’automazione del processo di test, possono verificare le funzionalità del sistema in maniera molto più veloce delle persone.
3. Possono fornire una maggiore precisione in verifiche come i test di regressione o di performance.

Fortunatamente, gli strumenti di test Soa sono apparsi presto, insieme al diffondersi degli ambienti stessi, consentendo così agli strumenti correntemente sul mercato di avere il tempo di maturare.

Le persone

L’attività di test è basata molto sul fattore umano. Quando elencate i problemi principali che le persone affrontano nei test di qualsiasi tipo di software, la maggior parte sono di natura umana. Anche se la tecnologia Soa ha una preminenza di tipo tecnico, avete ancora la necessità di considerare chi pianificherà, effettuerà e valuterà i test.
Gli sviluppatori posseggono una forte capacità nei test strutturali, ma il problema può essere la loro scarsa volontà di impegnarsi in quest’area. Tuttavia, se incoraggiati, con strumenti adeguati e supporto manageriale, gli stessi sviluppatori possono testare tranquillamente il proprio lavoro.
Le altre persone coinvolte, con particolare riferimento agli utenti finali, possono aggiungere ai test la prospettiva delle necessità operative dell’impresa. Il problema con gli utenti finali è di riuscire a impegnarli per tutto il tempo necessario per effettuare i test.
Gli specialisti dei test possono apportare un forte bagaglio di conoscenza specifica al progetto. Possono adattare test per l’ambiente Soa definiti in precedenza, così come adattare o aiutare a scegliere gli strumenti necessari. Potreste aver bisogno di utilizzare specialisti nei test, come nel caso di prove di performance e di sicurezza.

Controllare l’ambiente dei test

Le vostre verifiche saranno affidabili per quanto lo sarà l’intero ambiente di test. Se non siete in grado di identificare completamente quanto sia contenuto nel vostro ambiente di test come, per esempio, nel caso dei servizi, i risultati ottenuti non saranno affidabili. Negli ambienti Soa, è necessaria una gestione delle informazioni che indichi quando i servizi vengono creati o modificati e quando debbono essere inseriti nell’ambiente dei test.
Sfortunatamente, spesso le persone non si rendono conto dell’importanza del controllo dell’ambiente di test fino al momento in cui si presenta una malfunzione dovuta a test non corretti.

Il “riuso” dei test

La tecnologia Soa comporta nuove considerazioni sui test, ma la buona notizia è che molte delle tecniche necessarie possono essere adattate da quelle in uso nelle tecnologie precedenti. In termini generali, l’efficacia dei test è materia di un corretto bilanciamento tra persone, processi e strumenti, tutti operanti insieme in un ambiente di test integrato. L’ambiente Soa non è diverso. All’inizio del vostro primo progetto basato su questa architettura, prendendovi il tempo necessario per definire l’unicità della tecnologia, potrete affrontare il progetto stesso con la consapevolezza di averne considerato tutti i punti principali. Questo vi darà la sicurezza di avere non solo pianificato dei buoni test ma che questi risulteranno anche corretti e adeguati.