Newsgroup: it.comp.lang.delphi
Titolo: Testare applicazione

Ciao a tutti,
vorrei porvi una domanda alla quale pensavo ieri !
Premetto di non aver ancora guardato in giro e voi siete i primi che
interpello.
Esiste un software o un modo per testare i programmi fatti ??
Mi spiego ... creare un software che simuli un utente medio e inserisca
casualmente i dati e testi tutto per vedere di trovare eventuali bug ??
Qualcuno usa qualcosa già in commercio oppure si è inventato un software ad
ok !
Prima che cominci a pensarci troppo... suggeritemi... grazie ..
a voi ... esperti del settore  (Morde, Sortek, .. Salviat.. ecc)
Stefano

Si, esistono, ma sono costosissimi (attorno ai 5-6000 euro e quindi
fatti per aèpplicazioni di un certo valore.
Però esistono e sono free dei componenti per simulare la tastiera ed il
mouse, puoi crearti dei casi e farli
girare in continuo, poi se vuoi complicarti la vita puoi generare degli
eventi random e fare dei casi di prova a caso.
Considera che comunque i software esistenti non inventano mai le
sequenze e non sono in grado di
provare i programmise prima non sono stati istruiti
Ciao
Gianluca
www.klemy.it
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

cio che riguarda il test va chiarito bene.
Ad esempio, in "principi di ingegneria del software" si sottolinea che "il
test non sostituisce la corretta progettazione".
Gli sforzi vanno quindi fatti PRIMA, non per sfornare software 100% bugfree,
ma per evitare almeno il grosso dei problemi.
Per fare cio esistono varie tecniche, metodologie, et similia.
Un metodo che sto provando ad applicare è quello cosidetto "incrementale".
Consiste nel creare un primo "pezzo" di applicazione, testarlo in modo
approfindito e, quando i vari test danno esito positivo, si inizia con un
altro pezzo e si procede nello stesso modo.
L'idea è che, se ogni singolo "pezzo" ha una elevata percentuale di
affidabilità, si riduce di molto la quantità di errori che saranno poi
trovati in sede di debug della applicazione completa.
Riguardo il test ci sono varie tecniche e sistemi, vedi ad esempio la dunit
per delphi e la junit per java.
Ma, nel gia citato testo, l'idea di fondo che viene suggerita è che prima di
creare un "qualcosa" si deve pensare ai test che ci permetteranno di sapere
se il "qualcosa" fa quel che deve fare in modo corretto.
Pensiamo ad esmepio, ad una funzione che, data in ingresso una stringa,
restituisce 4 valori che compongono un indirizzo ip:
function StringToIp(const AValue: string; var ip1, ip2, ip3, ip4: byte):
integer;
ci sono delle condizioni che la stringa deve rispettare affinche si possa
estrarre da essa un ip valido, giusto?
ad esempio, ogni blocco separato dai punti deve contenere un valore numerico
compreso tra 0 e 255
quindi, una procedura di test potrebbe passare a questa funzione:
127.0.0.1 ok
255.0.0.255 ok
127.0.0 errato
1.1.1.256 errato
(stringa vuota) : ''
(stringa con solo uno spazio): ' ';
Questo è un caso che ho affrontato.
Ho scirtto la funzione è, con stringhe simili  a queste tutto funzionava a
dovere e avevo la risposta che mi apsettavo di avere.
Ma poi, nella lista delle stringh di test ho aggiunto questa:
1.1.1.1.1.1.1.1
e la funzione ha fallito xche, tra le condizioni, avevo dimenticato di
impostare che i gruppi devono essere 4.
In termni di codice, avevo un loop che cercava la posizione del punto nella
stringa, ma avevo commesso l'errore di non tener conto del numero di punti
che essa conteneva (stavo proprio in trance quando l'ho scritta.....).
Quel testo, principi di igegneria del sw, è tosto un  accidente, ma si
trovano parecchie cose utili.
Ovviamente non si può applicare tutto in blocco dall'oggi al domani, ma un
passo alla volta porta sicuramente ad affinare il proprio modo di lavorare.
Bye
A
Nel caso di una funzione, ad esempio:
function


[Cut]
Il test si applica sulla logica non sul valore.  Il principio da te
enunciato è comunque valido ma fino a un certo punto.
Cooper,

 
A parte l'ovvia distinzione tra le varie modalita' di test possibili 
(unit test, integration test, etc...), pare che a te serva un software 
per i test della GUI.
Questi software esistono, pochi e parecchio costosi. Non sono certo alla 
portata di un singolo programmatore, purtroppo.
Di software simile ma open-source o semplicemente freeware non ne ho mai 
visti.
Sarebbe anche possibile costruire qualcosa di "fatto in casa", 
semplicemente simulando l'azione dell'utente su tastiera e mouse, ma non 
avrebbero le funzionalita' sofisticate dei software professionali (che 
comunque devono essere adattati, es. tramite script/regole, al programma 
da testare).
Tali software professionali sono comunque spesso insufficienti, perche' 
l'umano, beh, e' difficilmente sostituibile ;-)
Oltretutto il test dell'interfaccia del programma e' di solito legato al 
cosiddetto "acceptance test", ossia il test che il cliente fa per 
verificare che il programma fa e agisce come richiesto. Automatizzare un 
acceptance test sarebbe anche possibile, ma richiede un approccio 
piuttosto rigoroso al processo di produzione del software, soprattutto 
nelle fasi di analisi e design.
Una alternativa potrebbe essere quella di spostare la maggior parte del 
test ad un livello concettuale piu' basso, ossia sfruttando gli unit 
test (piu' semplici da implementare, es. con DUnit) in modo da 
assicurare che, per qualsiasi valore o combinazione di dati sia inserito 
dall'utente, la logica del programma reagisca sempre in modo corretto 
(magari restituendo errore).
Ma questo presuppone un design del software che separa la logica 
applicativa dall'interfaccia utente (cosa che tutti gli esperti di 
ingegneria del software consigliano, comunque).
-- 
Roal Zanazzi

 trovati in sede di debug della applicazione completa.
i programmi moderni sono tutti modulari, e ogni modulo e' profondamente
interagente con gli altri, quindi per quanto tu possa testare un singolo
modulo, non potrai mai testare tutte le combinazioni di operazioni che i
moduli potranno fare gli uni con gli altri, ne' le condizioni di errore che
si potranno verificare in ambienti complessi (es. reti, o con danneggiamenti
a parte degli archivi).
Ciao, Sandro


Se A,B,C sono tre moduli bugfree, qualunque combinazione logica fra A,B,C è
bugfree. E' chiaro che se l'input per quanto grammaticalmente valido è
errato semanticamente, il risultato semantico restituito è errato.
La classica frase:  "Il pesce mangia luisa" è italianamente corretta dal
punto di vista grammaticale, l'elaboratore quindi la interpreta nel modo
corretto... ma è semanticamente errata.
L'elaboratore non dispone di quella capacità umana di capire e comprendere
se la frase ha senso o meno... e di conseguenza il test termina qui.
Cooper.
PS: Il tuo discorso ha senso nel momento in cui entra in gioco l'aleatorietà
di un evento.

 enunciato è comunque valido ma fino a un certo punto.
cioè....
A


Mi riferivo alla frase:
"Gli sforzi vanno quindi fatti PRIMA, non per sfornare software 100%
bugfree"
Ovvero alle volte, ci si accorge del bug, dopo aver scritto il codice non
prima :) cioè sul campo non sulla teoria... da quello che dici, emerge che
lo sforzo maggiore va fatto prima e non dopo, ok siamo d'accordo, ma non
sempre.... :)
Cooper.
-- 
------------------------------------
BlueWare di Impastato Marcello
 [web] 
http://www.blueware.it
 [msn] 
coo...@blueware.it
 [icq] 146781935
 [Irc] 
http://www.italchat.it

> Se A,B,C sono tre moduli bugfree, qualunque combinazione logica fra A,B,C
è bugfree.
la cosa secondo me va distinta ulteriormente dal punto di vista logico, tra
"correttezza (logica)" e "robustezza": un modulo puo' essere logicamente e
funzionalmente corretto, ma, messo di fronte ad un input non previsto,
fornire un risultato errato all'utente o ad un altro modulo che a sua volta
puo' generare errori o blocchi dell'applicazione. Quindi: modulo corretto ma
non robusto.
Il programmatore non dovrebbe puntare solo alla correttezza delle
funzionalita', ma anche alla robustezza del programma nel suo complesso, ad
esempio puntando ad un sistema di autodiagnosi, a controlli incrociati, a
pre-elaborazioni di verifica prima dell'elaborazione vera e propria. E'
quello, ad esempio, che faccio io nei miei programmi nella fase successiva
alle prime distribuzioni e relativa scrematura dei bug.
Ciao, Sandro

 a parte degli archivi).
Quello che sto leggendo in quel libro non č la panacea.
Si tratta solo di tecniche per RIDURRE il numero di problemi, cercando di
testare non tutti i casi xche sarebbe impossibile, ma almeno quelli +
rappresentativi.
Inoltre, quella di cui ho parlato non č l'unica: ve ne sono delle altre.
magari, l'uso alcune di esse possono essere usate insieme per ridurrwe
ulteriormente i casini.
A
--
Per rispondere non usare il reply ma scrivere al seguente indirizzo:
alsalvati(at)
supereva.it

 
E' per questo che gli unit test non sono sufficienti se non affiancati 
da test di integrazione.
Gli unit test sono fatti per testare i singoli componenti/moduli.
I test di integrazione servono, appunto, per testare il sistema (o 
sotto-sistemi complessi) composti da piu' componenti.
=> gli unit test da soli (se fatti bene) ti garantiscono una buona 
qualita' dei singoli componenti (e la loro aderenza alle specifiche di 
interfaccia definite nel design), ma non ti possono dare alcuna 
gaaranzia, da soli, che il sistema si comporti in modo corretto.
P.S. ovviamente, come e' ben noto, non e' possibile garantire la NON 
esistenza di bug, si puo' solo limitarne il numero il piu' possibile.
-- 
Roal Zanazzi

 
Gia', e poi dicono che i computer sono deterministici! :-P
-- 
Roal Zanazzi

 
Oltre, ovviamente, a controllare tutte le possibili condizioni di errore 
(valori di ritorno, eccezioni).
 > E' quello, ad esempio, che faccio io nei miei programmi nella fase
 > successiva alle prime distribuzioni e relativa scrematura dei bug.
 >
Curioso, io tendenzialmente metto tutti i controlli possibili _prima_ 
della prima release. Se per "distribuzione" intendi "release".
-- 
Roal Zanazzi


Se per bug intendiamo falle nel modulo allora l'affermazione è vera, se
invece intendiamo il comportamento assunto al variare dell'ordine logico dei
tre moduli allora è falso; perchè entra in gioco l'errato input dei dati il
cui risultato sarà chiaramente errato.
A titolo di controesempio, presentami un caso (anche elementare) in cui tre
moduli (composti anche da una sola riga) e privi falle, combinati fra loro,
diano una falla.
Mi permetto un esempio banalissimo:
        consideriamo le tre istruzioni in seguito, (esse possono essere un
modello di modulo complesso):
             a)   writeln (a);
             b)   readln (b)
             c)   a := b+1
se combiniamo come:
              readln (b);
              a := b+1;
              writeln(a);
visualizzeremo il successore di b. se invece abbiamo:
              a := b+1;
              readln (b);
              writeln(a);
otterremo un risultato imprevisto indipentemente da b, in quanto ha assume
un valore aleatorio essendo b non inizializzato; se invece abbiamo:
              a := b+1;
              writeln(a);
              readln (b);
abbiamo lo stesso risultato dell'esempio precedente, ma in nessuno dei tre
casi si è verificato un errore atto a interrompere la normale esecuzione del
programma, semplicemente vengono restuiti risultati diversi.
E ciò è quanto volevasi dimostrare.
Ciò premesso, se b è definito come intero,  è chiaro che in b non possiamo
inserire una stringa, (qui ecco che nasce una falla) che manda in crash.
Ma è sempre legato come si può notare al tipo di input fornito. Per ovviare
a questo inconveniente la capacità di un analista è proprio quella di
prevedere i casi limite e prevenirli in modo da rispondere egregiamente a
tali situazioni.
In ogni caso considerando l'esempio in questione, se b è un intero, in fase
di test, è sufficiente valutare l'ipotesi della stringa (e si opera) e nel
caso di un intero, inserire un intero e aspettarsi il suo successore.
E' altrettanto chiaro che l'intero inserito non deve nemmeno superare un
certo limite altrimenti nasce fuori un altra falla... e anche questa va
prevenuta.
Da tutto questo si può facilmente constatare che più un analista è bravo e
con esperienza maggiori sono le probabilità che il software realizzato sia
privo di bug o meglio ancora che le probabilità dii incontrare un bug non
saranno nulle ma tendenti a zero. Il fattore umano non va trascurato.
In generale, se si considera l'analista come un modello ideale, il software
prodotto da questo analista ideale è 100% bugfree. Quindi la robustezza
dipende dall'esperienza sia dell'analista che prevede i vari casi sia del
programmatore che li implementa (nel modo corretto).
Detto questo, penso di aver chiarito ulteriormente il motivo della mia
risposta.
Cooper.

 
Chiarissimo, semplicemente abbiamo concetti diversi del termine "bugfree".
-- 
Roal Zanazzi


Succede ^_^
Cooper.

 della prima release. Se per "distribuzione" intendi "release".
si, intendo proprio la release, il "rilascio ufficiale". Di controlli ne
metto anche io, lo stretto indispensabile per gestire le situazioni-tipo di
errore (es. dati inseriti incompleti o errati). Non posso permettermi di
allungare a dismisura i tempi di rilascio per prevedere situazioni di errore
che poi magari non si verificheranno mai. Preferisco una release rapida e
che sara' poi "limata" nel tempo venendo incontro a cio' che gli utenti,
nell'uso quotidiano, andranno a segnalare. Ad esempio in uno dei miei
gestionali piu' complessi - AlteaWin - ho integrato a distanza di un anno
circa dalla prima release un modulo di ricostruzione giacenze di magazzino
sulla base del movimentato storico; si e' reso necessario dopo che ad un
paio di utenti si erano sballati i dati per spegnimenti improvvisi.
Ciao, Sandro

 
Non dovrebbe. I problemi di comunicazione tra i vari "attori" che 
lavorano alla produzione di un software (clienti, analisti, esperti di 
dominio, designer, grafici, programmatori, tester, e <sigh> management) 
sono notevoli cause di bug.
Scusa se ti sono sembrato un po' duro, ma leggere certe affermazioni da 
un programmatore mi lascia molto perplesso.
Poi magari usi Delphi solo per hobby e non te ne frega niente di 
diventare programmatore per professione, pero' anche un hobby dovrebbe 
essere fatto nel modo migliore possibile, altrimenti meglio lasciar 
perdere, non credi?
-- 
Roal Zanazzi


I. Marcello (alias Cooper)


Se guardate alcuni programmi per vendere polize on-line si accede in modo
graduale ai dati.
Ossia :
Dove Abiti ?
Provincia _________
Città ________
Località _______
Cap _______
via ______
ecc...
Se si vuole essere precisi la provincia può essere una ComboBox
e la città un'altra ComboBox se si filtra una tabella Provicie+città lo
stesso per il cap.
Ovviamente non si eliminano gli errori ma concretamente si fa qualcosa per
diminiure le possibilità di errore.
P.S. si può anzi iniziare dalle regioni.
Per altri problemi sapete dove trovarmi.
--------------------------------
Inviato via 
http://usenet.libero.it