Skip to content

narrow screen resolution wide screen resolution auto screen resolution Increase font size Default font size Decrease font size default color brick color green color
Home Tutorial Test
Test PDF Stampa E-mail
<<  Sviluppo Conclusioni >>
Indice articolo
  1. Primo test: un'attivazione "normale"
  2. Secondo test: ritardo nella spedizione al Carrier
  3. Terzo test: ritardo nella spedizione al Carrier
  4. Quarto test: un ordine cancellato, ed un ordine andato a buon fine

Proviamo a testare il funzionamento dell'applicazione in modo informale. Eseguiremo questi test simulando l'"attraversamento" di una serie di stati con precisi intervalli temporali, per verificare la (eventuale) dipendenza di alcune "decisioni" dal tempo di esecuzione.

Le informazioni di debug sono quelle poste al di sotto della linea orizzontale che intuitivamente determina la fine dell'interfaccia utente della nostra applicazione di esempio. Tali informazioni saranno utili per determinare il punto dell'automa in cui ci troviamo ad ogni passo. In particolare la sezione intitolata "Current State" mostra, rispettivamente, il nome dello stato corrente, lo stato delle variabili dell'automa, le informazioni (statiche) delle variabili temporali con cui viene inizializzato l'automa, le informazioni (statiche) degli stati specificate nella definizione dell'automa e le informazioni (statiche) delle transizioni, anch'esse specificate nella definizione dell'automa. In ultimo troviamo l'elenco dei riferimenti alle porzioni di codice che formano l'Action Pool dell'automa. Tale codice sara` invocato, di volta in volta, come funzione di metrica o di azione associata ad un automa.

 

 

1. Primo test: un'attivazione "normale"

Simuliamo il processo di attivazione di una linea, rimanendo nei tempi previsti. Eseguiamo questa sequenza di azioni sull'interfaccia grafica:
1. Process Beginning/Start -[START]->
2. Order Creation/NewOrder (scegli "ISDN") -[SEND]->
3. {clockA := 0} Order sent to Carrier/OrderLine 
          -[START PROCESSING]-{clockA < 60 secondi}->
4. {clockB := 0} Order is being processed by carrier/PerformLineActivation
          -[CARRIED_OUT]-{clockB < 60 secondi}->
5. Processing carried out by carrier/LineActivationPerformed -[ACTIVATED]->
6. Line properly activated/LineWorking -[COMPLETED]->
7. Line activated/OrderPerformed -[START]->
8. Process Beginning/Start
Spieghiamo il "percorso" di test specificato sopra. Ogni riga indica il titolo dello stato in cui ci si dovrebbe trovare e il nome dello stato stesso, sperati da una barra obliqua. Ad esempio al punto 3 dovremmo trovarci nello stato che ha per titolo "Order sent to carrier" e per nome "OrderLine". Per verificare che ciò avvenga, al terzo passo del nostro test dovremo confrontare il nome dello stato (per l'appunto "OrderLine"), con l'informazione di Debug sotto l'intestazione "Current State:". L'etichetta specificata fra parentesi quadre, sta invece ad indicare il nome del link/bottone su cui si dovrebbe premere per far compiere un salto al nostro automa. Nel nostro esempio, per "saltare" dal passo 3 al passo 4 si dovrebbe premere sul link etichettato con "START PROCESSING".

Quando specifichiamo una direttiva {clockA := 0} (clock-reset) e dopo poco una direttiva {clockA < 60 secondi} (clock-check) vogliamo dire che devono trascorrere al più 60 secondi tra le due azioni. Chiamiamo clockA pseudo-variabile perchè essa è utilizzata solo nelle specifiche del test, non deve necessariamente corrispondere ad una clock-variable del programma. Questo per il principio che chi esegue il test non deve necessariamente conoscere il codice del programma, bensì avrà bisogno di proprie specifiche. Notiamo inoltre che le due direttive (clock-reset e clock-check) riferite ad uno stessa pseudo variabile di clock possono trovarsi in righe diverse delle specifiche di test.

Nel test sopra verifichiamo che, se rispettiamo i due vincoli temporali, corrispondenti a quelli specificati nei requisiti delle applicazioni iniziali, l'attivazione va a buon fine e si ritorna allo stato iniziale. Verifichiamo inoltre che quando scegliamo "isdn" nello stato con titolo "Order creation", in realtà stiamo assegnando il valore "isdn" alla variabile (POST) "lineChosen". Essendo tale variabile omonima ad una variabile dell'automa, la sezione "Environment:" tra le informazioni di debug aggiornerà lo stato della variabile (dell'automa) "lineChosen".

 

2. Secondo test: ritardo nella spedizione al Carrier

Simuliamo il processo di attivazione di una linea, ritardando la spedizione della pratica al Carrier:
1. Process Beginning -[START]->
2. Order Creation (scegli "ADSL") -[SEND]->
3. {clockA := 0} Order sent to Carrier -[START_PROCESSING]-{clockA > 60sec}->
4. Processing cancelled -[START]->
5. Process Beginning
In questo test evidenziamo che se attendiamo per un qualsiasi lasso di tempo superiore ai 60 secondi, siamo portati in uno stato di "errore" in cui eventualmente saremo informati del troppo tempo trascorso e potremo avvisare il cliente che, a causa di cio`, lui è libero da eventuali obblighi verso la nostra azienda..

 

3. Terzo test: ritardo nella spedizione al Carrier

Simuliamo il processo di attivazione di una linea, simulando un ritardo nella attivazione della linea da parte del carrier:
1. Process Beginning -[START]->
2. Order Creation (scegli "ADSL") -[SEND]->
3. {clockA := 0} Order sent to Carrier -[START_PROCESSING]-{clockA 
4. {clockB := 0} Order is being processed by carrier 
            -[SUSPENSION]-{clockB == 10 sec}->
5. Suspension by carrier -[RESTART_PROCESSING]-{clockB == 70 sec}->
6. Resume line activation process -[CARRY OUT ORDER]-{clockB > 70 sec}->
7. Processing cancelled -[START]->
8. Process Beginning
In questo test mostriamo che se il lavoro viene portato a termine dal carrier (CARRY OUT ORDER) oltrepassato il limite di tempo specificato nei requisiti (60 secondi in questo esempio), l'ordine viene automaticamente cancellato e il cliente viene "liberato" da vincoli nei confronti della nostra azienda. In questo esempio mostriamo la possibilità di sospendere la lavorazione per poi riprenderla dopo 50 secondi (infatti la differenza fra clockB al passo 6 e clockB al passo 5 è di 50 secondi. Sospensione e ripresa dei lavori puo` ripetersi più volte (o nessuna) e a intervalli variabili (il lettore puo` testare anche questi comportamenti), ma se il comando di CARRY OUT ORDER viene scelto una volta passati i 60 secondi, l'ordine verrà comunque cancellato.

 

4. Quarto test: un ordine cancellato, ed un ordine andato a buon fine

Simuliamo il processo di attivazione di due linee: la prima, una adsl, viene cancellato per ritardo nella comunicazione della richiesta al carrier (come il secondo test), mentre la seconda attivazione, una linea isdn, va a buon fine (come il primo test). Omettiamo l'elenco dettagliato dei passi perchè è sufficiente eseguire i due sopra menzionati test per ottenere questo nuovo test.

Con questo, si vuole dimostrare che il nostro programma "resetta" correttamente le informazioni di un processo di attivazione una volta terminato. In particolare, perde le informazioni della linea precedentemente attivata, ed le variabili di clock vengono correttamente azzerate all'inizio di una nuova pratica.

 

<<  Sviluppo Conclusioni >>
 

Login


Parliamo di...

action  applicazione  applicazioni  attivazione  automa  azione  business  carrier  clock  codice  dall  designer  esempio  file  funzione  funzioni  informazioni  linea  linguaggio  metodi  metodo  metrica  nuova  operatore  order  parte  passo  più  pratica  process  processo  specifiche  stati  stato  sviluppo  test  tool  variabili  {clocka  {clockb 
By Zaragoza Clouds