Litigio sui test

Quote:

---

Originally Posted by Alkabar

Ah beh, la insegno, ci lavoro, la scrivo in progetti per cui mi danno soldi per assumere della gente a lavorarci sopra... mah... questa discussione sta diventando sterile, se hai bisogno di pomparti l'ego, trovati
una gnocca svedese e vacci in giro per la città, non venire a discutere sul forum.
Guarda che sei tu che fai lo studente spocchioso, io sto solamente parlando della materia su cui lavoro.

In piu':
Il model checking è tool formale per verificare che il modello astratto funziona, di nuovo non ti garantisce l'assenza di bug nel prodotto finito.
E soprattutto costa, perchè va quasi sempre a forza bruta in tutti gli stati per assicurare che delle proprietà siano soddisfatte.
Una tra tutte la liveness, cioè che non ci siano deadlock. Oppure che si possa raggiungere uno stato del sistema.
Da qua a dimostrare che il sistema è veloce e fa il caffe' ne passa. Quella si chiama evaluation e col testing c'entra si e no.
Alla evaluation si che controlli le caratteristiche non funzionali del software perchè se un software ha complessità fattoriale non sei proprio contento.



Non si chiama test. E' qualcosa di ben piu' complesso di un test. Per l'appunto in ricerca la chiamiamo evaluation. Test è abuso di linguaggio. Nel senso che lo stai stuprando.

---

evaluation che cazzo centra è il confronto tra il prodotto e il piano a livello di processo. Ti rimando ad una lettura, poi ripassa quando ci hai capito qualcosa, i primi due capitoli sono di sample ti dovrebbero bastare per inquadrare il discorso: http://ix.cs.uoregon.edu/~michal/book/

tu stai parlando di una materia che evidentemente non conosci, se hai un collega che si occupa di test seriamente bussagli alla porta e fagli leggere quel che hai scritto in ste pagine, ti riderà in faccia.

e nota che sono un signore che non sto rispondendo con i tuoi toni, ma da quando fai parlare il culo invece che la testa? è un discorso su argomenti scientifici, perchè non ti documenti prima di sparar perle di saggezza?

Separate il thread plz, all'OP non interessano queste cose, il povero Miave vuole provare a fare qualche programmino per diletto e state sminchiando il thread :)

ps: non ho letto nei dettagli la diatriba, quindi non entro nel merito del discorso (e appunto oltretutto è OT).

A mio avviso state parlando di due cose differenti:

alka tu ti stai limitando a parlare di test durante la fare di implementazione del software quelli che fai in fase di sviluppo a livello codice e in ambiente di dev.

Hador: invece sta parlando più con una lunga visione,partendo dallo sviluppo del software fino a ricadere nel discorso che ti facevo io di Ciclo di Vita del Software quindi da quando viene implementato dal team di sviluppo fino ad arrivare al Deploy in produzione e al supporto in esercizio, impattando quindi gruppi di QA gruppi di Stress&performance Test, Validation del software fino alla messa in esercizio con concetti di Sanity Check

Quote:

---

Originally Posted by Tanek

Separate il thread plz, all'OP non interessano queste cose, il povero Miave vuole provare a fare qualche programmino per diletto e state sminchiando il thread :)
ps: non ho letto nei dettagli la diatriba, quindi non entro nel merito del discorso (e appunto oltretutto è OT).

---

Logico sei solo un pigiatasti :kiss: :kiss:

sono io mod e decido io, la discussione si è evoluta, poi vi separo il thread se proprio vogliamo :nod:

io ovviamente sto parlando di tutte le fasi di testing, altrimenti avrei parlato di test unitario, ma lo ho scritto diverse volte. Non è neanche un problema di nomi dato che tutte sono fasi di test (test unitario, test di sistema, test strutturale, test di integrazione, stress test, ecc...), con le macro categorie verification e validation.

Tutto il discorso è nato dal fatto che è stato detto che non è possibile garantire, a qualsiasi livello, che un software funzioni bene e faccia quel che deve fare, e che i test servono solo per provare la funzionalità. Con alka che ha continuato dicendo che per garantire l'assenza di bug non si fa test ma debug (lol).

Cosa che accomuna le due persone che hanno sostenuto tale posizione è stato il fornire il loro stipendio/posizione lavorativa come motivazione del fatto che han ragione.

Quote:

---

Originally Posted by Hador

Tutto il discorso è nato dal fatto che è stato detto che non è possibile garantire, a qualsiasi livello, che un software funzioni bene e faccia quel che deve fare, e che i test servono solo per provare la funzionalità. Con alka che ha continuato dicendo che per garantire l'assenza di bug non si fa test ma debug (lol).

---

E di nuovo, io non ho detto niente di sbagliato, ma ahimè l'ignoranza è davvero una brutta bestia. Va beh continua da solo.

io il materiale te l'ho fornito, tu?

Concludo qua:

Quote:

---

Originally Posted by Hador

evaluation che cazzo centra è il confronto tra il prodotto e il piano a livello di processo. Ti rimando ad una lettura, poi ripassa quando ci hai capito qualcosa, i primi due capitoli sono di sample ti dovrebbero bastare per inquadrare il discorso: http://ix.cs.uoregon.edu/~michal/book/

---

Non c'è scritto niente di sbagliato qua. Sei tu che non capisci dove e come si applica, non avendo alcuna esperienza, appunto, assumi e parli a vanvera.

Quote:

---

tu stai parlando di una materia che evidentemente non conosci, se hai un collega che si occupa di test seriamente bussagli alla porta e fagli leggere quel che hai scritto in ste pagine, ti riderà in faccia.

---

Ma anche no.

Quote:

---

e nota che sono un signore che non sto rispondendo con i tuoi toni, ma da quando fai parlare il culo invece che la testa? è un discorso su argomenti scientifici, perchè non ti documenti prima di sparar perle di saggezza?

---

[/QUOTE]

Sei un signore ? Due persone che ci lavorano ti hanno detto che toppi, se magari ti fermassi due secondi invece che continuare con sto ioioioioioio.

Oh vabbeh, ti smusi anche quando ti danno davanti da integrare già solo 4 sistemi complessi assieme, vedrai che tutti i test andranno benissimo, ma il sistema sarà lento, capiteranno bug a muzzo e per quanti test metterai su, ci sarà sempre qualcosa
che ti sfugge di mano.

Quote:

---

Originally Posted by Alkabar

Due persone che ci lavorano ti hanno detto che toppi, se magari ti fermassi due secondi invece che continuare con sto ioioioioioio.

Oh vabbeh, ti smusi anche quando ti danno davanti da integrare già solo 4 sistemi complessi assieme, vedrai che tutti i test andranno benissimo, ma il sistema sarà lento, capiteranno bug a muzzo e per quanti test metterai su, ci sarà sempre qualcosa
che ti sfugge di mano.

---

la conclusione quale sarebbe? Procedere a tentoni dato che è difficile? Qua di ioioioio vedo solo un cercare di imporre la propria opinione senza nient'altro che il "ascolta me che sono uno che ne sà, mi pagano".

-ps sto in un lab con 3 post doc che fa capo 3 professori che dicono quel che sto ripetendo, loro non lavorano? :sneer:

Ragazzi piano perchè non vi si sta dietro

Quote:

---

Originally Posted by Hador

Se tu potessi provare tutti i valori di input avresti la garanzia dell'assenza di bug, in quanto hai verificato tutte le transizioni possibili a partire da quello stato.

---

Falso. Il pc è un sistema con memoria, e questo basta a contraddire la tesi. Hint: Stati non controllabili ma osservabili. It happens.

Quote:

---

Originally Posted by Alkabar

Il test di per se ti dice solo che lo stato del sistema è corretto o no dati certi input, non ti garantisce l'assenza di bug anche dentro ai componenti stessi che ti hanno computato il risultato corretto.

---

Vero

Quote:

---

Originally Posted by Alkabar

E sono caratteristiche emergenti del software.

---

Vero, cazzo, stavi andando bene

Quote:

---

Originally Posted by Alkabar

Cioè sono cose che si possono valutare solo a posteriori, dopo che il software è in piedi e gira, perchè hanno senso solo alla fine del processo.

I test, si fanno per la parte funzionale. Perchè non esiste un test, nel mentre che si programma, per vedere se il software è perfomante è semplicemente stupido.

---

FALSO, FALSISSIMO, quasi la morte. Se tu non avessi modo di conoscere il tempo di esecuzione A PRIORI non esisterebbero i sistemi operativi real-time, con tutto quello che ne deriverebbe, visto che sono dappertutto. Ma proprio ovunque. Ci sono campi nei quali conoscere le performances E' UN REQUISITO CRITICO, e in tali campi si conosce perfettamente il tempo di esecuzione. Se ne può discutere ma neanche tanto, o le macchine non avrebbero le centraline. Sommerville deve decisamente fare più attenzione a quello che dice, o qualcuno gli tira in testa un WCET :asd:

Quote:

---

Originally Posted by marlborojack

FALSO, FALSISSIMO, quasi la morte. Se tu non avessi modo di conoscere il tempo di esecuzione A PRIORI non esisterebbero i sistemi operativi real-time, con tutto quello che ne deriverebbe, visto che sono dappertutto. Ma proprio ovunque. Ci sono campi nei quali conoscere le performances E' UN REQUISITO CRITICO, e in tali campi si conosce perfettamente il tempo di esecuzione. Se ne può discutere ma neanche tanto, o le macchine non avrebbero le centraline. Sommerville deve decisamente fare più attenzione a quello che dice, o qualcuno gli tira in testa un WCET :asd:

---

E anche no, tu capitomboli proprio male, pure qua il buon Sommerville ha ragione per un banale fatto: se il sistema non è montato, software o meno, a meno di chiamarti Otelma, tu come si comporta dal punto di vista delle performance non lo sai DI CERTO. Test sui componenti non ti aiutano, test incrociati ti aiutano un po'... lo vedi quando hai una larga base di utenti che lo usano se va o no, perchè solo loro saranno in grado di ispezionare una gran parte dei sotto rami del codice.

E' lo stesso motivo per cui metti su degli omarini a giocare tutto il giorno con il giochino 3D e ripetere un miliardo di volte le stesse azioni nel gioco...

E' anche l'esatto motivo per cui i costi di mantenimento del software o di un sistema sono 3 volte piu' grandi di qualunque altro costo di sviluppo...

Quote:

---

Originally Posted by Hador

Cosa che accomuna le due persone che hanno sostenuto tale posizione è stato il fornire il loro stipendio/posizione lavorativa come motivazione del fatto che han ragione.

---

Posto che non mi interessa piu' la discussione perchè TU sei il depositario unico della verità assoluta e chiunque non la pensi come te ha torto, e quindi io ho torto perchè non la penso come te.

Posto che sto postando (giochi di parole ftw) solo per staccare un attimo dal lavoro.

quello che volevo dire è che io mi sono limitato a dire che i test non possono mostrare tutto il ciclo di vita del software e che i dettagli implementativi di un software distinguono un'applicazione solida da una debole.
Ho persino giustificato brevemente la mia affermazione e non ho nessuna intenzione di scrivere un libro per renderla piu' prolissa nella speranza che faccia colpo su di te.
Se io sostengo che i dettagli implementativi mi caratterizzano positivamente o negativamente un'applicazione non lo faccio perchè me lo son sognato la notte, lo faccio perchè, AD ESEMPIO, sapere che un'applicazione java gira su una JVM e puo' avere un range di memoria perfettamente definito a priori mi garantisce che sia che l'applicazione in questione sia single thread sia che l'applicazione sia multi thread, il totale della memoria occupata sarà quello che è stato deciso all'avvio. E' un dettaglio implementativo. E' un dettaglio importante perchè SO che a runtime non potrà capitare che su una macchina da 4gb di memoria un'applicazione java configurata per occupare 1 gb mi finisca per esaurire la memoria totale del sistema.
Un altro dettaglio implementativo è in che modo trasferire file tra un'applicazione e un'altra: coda jms o file transfer? se non sai quanto saran grossi i file, puoi scegliere qualunque metodo: se un singolo file è piu' grande della memoria totale dell'applicazione che espone la coda jms, non funziona piu' un cazzo; col file transfer l'unico modo per non far funzionare il sistema è riempire completamente il filesystem.
Queste sono cose che puo' prevedere un bravo architetto con TUTTI i dati alla mano, oppure eviti certi problemi implementando il software rispettando le caratteristiche del linguaggio o del sistema.

basta sono stato prolisso e probabilmente neanche chiaro, ciao

Quote:

---

Originally Posted by Alkabar

E anche no, tu capitomboli proprio male, pure qua il buon Sommerville ha ragione per un banale fatto: se il sistema non è montato, software o meno, a meno di chiamarti Otelma, tu come si comporta dal punto di vista delle performance non lo sai DI CERTO. Test sui componenti non ti aiutano, test incrociati ti aiutano un po'... lo vedi quando hai una larga base di utenti che lo usano se va o no, perchè solo loro saranno in grado di ispezionare una gran parte dei sotto rami del codice.

E' lo stesso motivo per cui metti su degli omarini a giocare tutto il giorno con il giochino 3D e ripetere un miliardo di volte le stesse azioni nel gioco...

E' anche l'esatto motivo per cui i costi di mantenimento del software o di un sistema sono 3 volte piu' grandi di qualunque altro costo di sviluppo...

---

LOL. Scadiamo nel surreale, se non nel ridicolo. Se io devo ogni 12 millisecondi leggere un dato su un registro e scriverne uno su di un altro per controllare un motore elettrico, devo fare un'analisi WCET del mio software per garantire che questo avvenga e che quindi sia schedulabile ogni 12 millisecondi, altrimenti non posso fare un emerito cazzo con nessun sistema reale. Allora prendo il codice generato, prendo il tempo di esecuzione di ogni singola istruzione e conto. A quel punto posso dire che, se l'apparato sul quale eseguo l'algoritmo funziona secondo i parametri standard sui quali mi sono basato, allora il mio programma viene eseguito ogni tot e ci impiega tot1 e fine della discussione, non ci sono FATTI o cazzate altrimenti National Instruments sarebbe fallita decenni fa, Matlab non servirebbe ad un cazzo e soprattutto non avremmo l'80% della tecnologia attuale, dai PLC ai sistemi operativi in tempo reale. I test sui componenti li fa chi li produce, e io mi attengo a quel che mi dicono, altrimenti cazzi loro.

Quote:

---

Originally Posted by marlborojack

Se io devo ogni 12 millisecondi leggere un dato su un registro e scriverne uno su di un altro per controllare un motore elettrico,

---

va beh ma si parlava di programmazione a medio alto livello .... state andando OT sull OT

Quote:

---

Originally Posted by Amiag

va beh ma si parlava di programmazione a medio alto livello .... state andando OT sull OT

---

Il computo del worst-case-execution-time è pur sempre un test per sapere se il programma rispetta il requisito minimo sul tempo di esecuzione. il thread è litigio sui test. Di cosa si sta parlando? I programmi in realtime si scrivono anche in c++ con paradigma ad oggetti e vi sono svariati esempi di middleware soft-realtime

Quote:

---

Originally Posted by San Vegeta

Posto che non mi interessa piu' la discussione perchè TU sei il depositario unico della verità assoluta e chiunque non la pensi come te ha torto, e quindi io ho torto perchè non la penso come te.
Posto che sto postando (giochi di parole ftw) solo per staccare un attimo dal lavoro.
quello che volevo dire è che io mi sono limitato a dire che i test non possono mostrare tutto il ciclo di vita del software e che i dettagli implementativi di un software distinguono un'applicazione solida da una debole.
Ho persino giustificato brevemente la mia affermazione e non ho nessuna intenzione di scrivere un libro per renderla piu' prolissa nella speranza che faccia colpo su di te.
Se io sostengo che i dettagli implementativi mi caratterizzano positivamente o negativamente un'applicazione non lo faccio perchè me lo son sognato la notte, lo faccio perchè, AD ESEMPIO, sapere che un'applicazione java gira su una JVM e puo' avere un range di memoria perfettamente definito a priori mi garantisce che sia che l'applicazione in questione sia single thread sia che l'applicazione sia multi thread, il totale della memoria occupata sarà quello che è stato deciso all'avvio. E' un dettaglio implementativo. E' un dettaglio importante perchè SO che a runtime non potrà capitare che su una macchina da 4gb di memoria un'applicazione java configurata per occupare 1 gb mi finisca per esaurire la memoria totale del sistema.
Un altro dettaglio implementativo è in che modo trasferire file tra un'applicazione e un'altra: coda jms o file transfer? se non sai quanto saran grossi i file, puoi scegliere qualunque metodo: se un singolo file è piu' grande della memoria totale dell'applicazione che espone la coda jms, non funziona piu' un cazzo; col file transfer l'unico modo per non far funzionare il sistema è riempire completamente il filesystem.
Queste sono cose che puo' prevedere un bravo architetto con TUTTI i dati alla mano, oppure eviti certi problemi implementando il software rispettando le caratteristiche del linguaggio o del sistema.
basta sono stato prolisso e probabilmente neanche chiaro, ciao

---

Un bravo architetto sà che HEAP di memoria configurabile con i parametri JAVA_OPTIONS=" -xms -xmx" (su WLS WAS) o JAVA_OPTS (Tomcat e JBOSS) su non è quanto occupa il processo dell'application server, ma bensi la memoria allocata e dedicata per gli oggetti dinamici (vivi morti dell'applicazioni),
Hai un pelino di confusione ma mica tanta.....
Il processo è l'insieme della Memoria usata nello start del processo, delle librerie del classpath, startupclass, driver etc.etc.etc. e Deployato, quindi se dentro il tuo EAR per ogni componente che te hai dentro (war e ejb, gli hai ridefinito le stelle librerie) è logico che ti carica su una cosa mastodontica o metti le immagini dentro senza appoggiarti a un CMS o un Apache o usi strutture dedicate come le folder APP-INF e APP-LIB che servono per sharare le librerie a tutti i componenti del EAR, struttura propretaria di WLS



Visto che HEAP SIZE si definisce nello script di start dei Managed Server e come dicevo prima precisamente nella definizione delle JAVA_OPTIONS e non a livello di Singola applicazione quindi è comune a tutte le applicazioni deployate sul APPL.SERVER.


http://download.oracle.com/docs/cd/E...JVMTuning.html
http://www.caucho.com/resin-3.0/perf...jvm-tuning.xtp

Se fai un heap troppo piccola e invece carici diversi oggetti come sessioni, etc.etc. nell'heap questa entrarà in full garbage collection e implode il server.

Per il transfer file, beh se sei un pazzo e vuoi trasferire nella JMS quintali di dati fai pure, poi ti trovi qualcuno che inizia a definirti Threshold and Quota.

Quote:

---

Originally Posted by marlborojack

LOL. Scadiamo nel surreale, se non nel ridicolo. Se io devo ogni 12 millisecondi leggere un dato su un registro e scriverne uno su di un altro per controllare un motore elettrico, devo fare un'analisi WCET del mio software per garantire che questo avvenga e che quindi sia schedulabile ogni 12 millisecondi, altrimenti non posso fare un emerito cazzo con nessun sistema reale. Allora prendo il codice generato, prendo il tempo di esecuzione di ogni singola istruzione e conto. A quel punto posso dire che, se l'apparato sul quale eseguo l'algoritmo funziona secondo i parametri standard sui quali mi sono basato, allora il mio programma viene eseguito ogni tot e ci impiega tot1 e fine della discussione, non ci sono FATTI o cazzate altrimenti National Instruments sarebbe fallita decenni fa, Matlab non servirebbe ad un cazzo e soprattutto non avremmo l'80% della tecnologia attuale, dai PLC ai sistemi operativi in tempo reale. I test sui componenti li fa chi li produce, e io mi attengo a quel che mi dicono, altrimenti cazzi loro.

---

Quale è il punto di cio' che dici, dove da contro a quanto dico io, piu' che altro, che dico che il test è solo una parte del debugging e che non hai certezza assoluta del comportamento del codice ?
Stai cercando di sostenere che si ha il controllo totale del codice col testing? Su qualche componente del tuo immenso progetto avrai qualche certezza, questo è quanto.
Cosa vi siete fumati oggi, da quando in qua l'informatica è diventata una scienza esatta. Lo so io perchè, perchè c'è di mezzo Alka, pur di dar contro ad Alka si stravolgono anche le leggi della probabilità,
mauauauauahahah.

Quote:

---

Originally Posted by Alkabar

Quale è il punto di cio' che dici, dove da contro a quanto dico io, piu' che altro, che dico che il test è solo una parte del debugging e che non hai certezza assoluta del comportamento del codice ?
Stai cercando di sostenere che si ha il controllo totale del codice col testing? Su qualche componente del tuo immenso progetto avrai qualche certezza, questo è quanto.
Cosa vi siete fumati oggi, da quando in qua l'informatica è diventata una scienza esatta. Lo so io perchè, perchè c'è di mezzo Alka, pur di dar contro ad Alka si stravolgono anche le leggi della probabilità,
mauauauauahahah.

---

Il punto è che il tempo di esecuzione può non essere solo un elemento di prestazione, ma anche un requisito funzionale. E sì, su certi tipi di codice, tipo sui plc, devi avere il controllo totale. Ma se intendevi sui software di determinate estensioni e che non hanno requisiti sul tempo di esecuzione, allora la tua precedente affermazione è vera.

E non capita spesso di poter partecipare ad una rissa sui test per la validità del software, non potevo mancare :D

http://lh5.ggpht.com/_MqYsHWQ7fo4/So...e_Bad_Guys.jpg

Quote:

---

Originally Posted by Karidi

Un bravo architetto sà che HEAP di memoria configurabile con i parametri JAVA_OPTIONS=" -xms xxxx -xmx" (su WLS WAS) o JAVA_OPTS (Tomcat e JBOSS) su non è quanto occupa il processo dell'application server, ma bensi la memoria allocata e dedicata per gli oggetti dinamici (vivi morti dell'applicazioni),
Hai un pelino di confusione ma mica tanta.....
Il processo è l'insieme della Memoria usata nello start del processo, delle librerie del classpath, startupclass, driver etc.etc.etc. e Deployato, quindi se dentro il tuo EAR per ogni componente che te hai dentro (war e ejb, gli hai ridefinito le stelle librerie) è logico che ti carica su una cosa mastodontica o metti le immagini dentro senza appoggiarti a un CMS o un Apache o usi strutture dedicate come le folder APP-INF e APP-LIB che servono per sharare le librerie a tutti i componenti del EAR, struttura propretaria di WLS



Visto che HEAP SIZE si definisce nello script di start dei Managed Server e come dicevo prima precisamente nella definizione delle JAVA_OPTIONS e non a livello di Singola applicazione quindi è comune a tutte le applicazioni deployate sul APPL.SERVER.


http://download.oracle.com/docs/cd/E...JVMTuning.html
http://www.caucho.com/resin-3.0/perf...jvm-tuning.xtp

Se fai un heap troppo piccola e invece carici diversi oggetti come sessioni, etc.etc. nell'heap questa entrarà in full garbage collection e implode il server.

Per il transfer file, beh se sei un pazzo e vuoi trasferire nella JMS quintali di dati fai pure, poi ti trovi qualcuno che inizia a definirti Threshold and Quota.

---

-Xms1000m -Xmx1000m -XX:PermSize=128m -XX:MaxPermSize=128m
l'applicazione occupa un totale di 1128mb, non uno di più non uno di meno. le librerie sono caricate all'interno di questa memoria allocata
JAVA_OPTIONS e JAVA_OPTS sono variabili di comodo, potevano chiamarsi anche pippo e parepino e funziona tutto uguale. I parametri della JVM sono passati tramite -D e -X. -XX è specifico per alcune JVM.

non parlare di cose a vanvera per favore

Quote:

---

Originally Posted by Alkabar

Quale è il punto di cio' che dici, dove da contro a quanto dico io, piu' che altro, che dico che il test è solo una parte del debugging e che non hai certezza assoluta del comportamento del codice ?
Stai cercando di sostenere che si ha il controllo totale del codice col testing? Su qualche componente del tuo immenso progetto avrai qualche certezza, questo è quanto.
Cosa vi siete fumati oggi, da quando in qua l'informatica è diventata una scienza esatta. Lo so io perchè, perchè c'è di mezzo Alka, pur di dar contro ad Alka si stravolgono anche le leggi della probabilità,
mauauauauahahah.

---

Alka, la fase di test non è parte del Debugging ma una parte del ciclo di vita del software, che deve essere testato e integrato prima e poi collaudato per le performance.
Il debug indica che c'è un defect e quindi fai il troubleshooting per scoprirlo.
Il Test server per verificare che le nuove funzionalità richieste dalle CR che di solito arrivano dal Marketing ---> Analisti ---> Fattibilità ---> Sviluppo ---> Test Accettazione Validazione ----> Test Integrazione e ambienti complessi ---> Messa in esercizio/Produzione ---> Maintenance

Ma per fare i TEST si devono redigere prima i TESTCase partendo dai documenti di Specifiche che arrivano dagli Analisti ancor prima del software, e si fanno i test per verificare che le CR implementate sono correttamente fatte.... Ma è una fase del ciclo del software.

Il Debug, serve a trovare il problema generato a fronte da un DEFECT/Anomalia riscontrata.

Quote:

---

Originally Posted by San Vegeta

-Xms1000m -Xmx1000m -XX:PermSize=128m -XX:MaxPermSize=128m
l'applicazione occupa un totale di 1128mb, non uno di più non uno di meno. le librerie sono caricate all'interno di questa memoria allocata
JAVA_OPTIONS e JAVA_OPTS sono variabili di comodo, potevano chiamarsi anche pippo e parepino e funziona tutto uguale. I parametri della JVM sono passati tramite -D e -X. -XX è specifico per alcune JVM.

non parlare di cose a vanvera per favore

---

Heap size does not determine the amount of memory your process uses


Permanent generation (MaxPermSize setting) is separate heap space that
is not garbage collected (ergo the permanent). Whatever is allocated to
perm is in addition to the heap set with -Xmx.


Essendo definite a livello Server, quindi non è la definizione della tua applicazione ma un impostazione di sistema.

infatti è la memoria disponibile al processo.
e non hai dimostrato niente

Quote:

---

Originally Posted by marlborojack

Il computo del worst-case-execution-time è pur sempre un test per sapere se il programma rispetta il requisito minimo sul tempo di esecuzione. il thread è litigio sui test. Di cosa si sta parlando? I programmi in realtime si scrivono anche in c++ con paradigma ad oggetti e vi sono svariati esempi di middleware soft-realtime

---

sto parlando del fatto che stai usando un esempio ultra-specifico per generalizzare su tutt'altro...

ti voglio vedere a calcolare il tempo di esecuzione di ogni singola istruzione di un programma c++ :point: non hai neanche accesso a intervalli di tempo di 12 ms in linguaggi di alto livello (beh su pc "normali" almeno)

Quote:

---

Originally Posted by Karidi

Essendo definite a livello Server, quindi non è la definizione della tua applicazione ma un impostazione di sistema.

---

oddiosanto ma che cazzo stai a dì?

Quote:

---

Originally Posted by Karidi

Alka, la fase di test non è parte del Debugging ma una parte del ciclo di vita del software, che deve essere testato e integrato prima e poi collaudato per le performance.
Il debug indica che c'è un defect e quindi fai il troubleshooting per scoprirlo.
Il Test server per verificare che le nuove funzionalità richieste dalle CR che di solito arrivano dal Marketing ---> Analisti ---> Fattibilità ---> Sviluppo ---> Test Accettazione Validazione ----> Test Integrazione e ambienti complessi ---> Messa in esercizio/Produzione ---> Maintenance

Ma per fare i TEST si devono redigere prima i TESTCase partendo dai documenti di Specifiche che arrivano dagli Analisti ancor prima del software, e si fanno i test per verificare che le CR implementate sono correttamente fatte.... Ma è una fase del ciclo del software.

Il Debug, serve a trovare il problema generato a fronte da un DEFECT/Anomalia riscontrata.

---

Asp, non concordo:

una problema/anomalia non è qualcosaa che è sempre facile riprodurre. Quando la riscontri, la cosa piu' importante è definire un test che la riproduca spesso cosi' da poterla debuggare.

Quote:

---

Originally Posted by marlborojack

Il punto è che il tempo di esecuzione può non essere solo un elemento di prestazione, ma anche un requisito funzionale. E sì, su certi tipi di codice, tipo sui plc, devi avere il controllo totale. Ma se intendevi sui software di determinate estensioni e che non hanno requisiti sul tempo di esecuzione, allora la tua precedente affermazione è vera.

E non capita spesso di poter partecipare ad una rissa sui test per la validità del software, non potevo mancare :D

http://lh5.ggpht.com/_MqYsHWQ7fo4/So...e_Bad_Guys.jpg

---

Ma Marlbro, non ce l'hai mai il controllo totale. Nemmeno sul PLC, nemmeno su realtime. E' una triste verità. Poi ovviamente avrai un controllo tale che il 99.99999999999% delle volte ci prendi, ma devi fare i conti col fatto, soprattuto in sistemi realtime, che stai avendo a che fare con un ambiente non deterministico che puoi prevedere fino a un certo punto.
Se poi sono sistemi realtime distribuiti, beh li c'è da piangere.

Quote:

---

Originally Posted by San Vegeta

oddiosanto ma che cazzo stai a dì?

---

Server = Application Server sto intendendo non a livello di HOST.

e anche se fosse, tu lo sai che un application server come tomcat, jboss, weblogic server o websphere è un'applicazione java?
se non lo sai vatti a vedere come è stato lanciato il processo, vedrai un "java ecc ecc ecc"

e ora basta, smettila di darti la zappa sui piedi ti prego

State male.

Mi son perso sto thread :(

Suvvia usate le triple di hoare :D (affermazione random perchè non ho letto tutto il thread)

parliamone in PM

falso, punto

sostanzialmente abbiamo un informatico che programma con la credenza che quel che fa non può sapere esattamente come si comporterà e uno che tira supercazzole sulla gestione della memoria di java (senza rendrsi conto che uno stress test e/o un test di sistema fanno emergere eventuali problemi di memoria, ergo tramite i test verifichi i dettagli implementativi)... vado a lucca a lunedì :nod:

Quote:

---

Originally Posted by Hador

sostanzialmente abbiamo un informatico che programma con la credenza che quel che fa non può sapere esattamente come si comporterà

---

Ma quel che faccio io, so con estremamente ottima approssimazione come si comporta, quello che ti sto dicendo in realtà è che quello che fai tu sono sicuro che non sai come si comporta realmente perchè confidi solo nei test come un perfetto niubbo.

Sai che comunque non sei poi differente da Hudlok ? Tendi a far finta di non capire una sega e a ripetere a disco rotto delle boiate nella speranza che facciano presa.

Quote:

---

e uno che tira supercazzole sulla gestione della memoria di java (senza rendrsi conto che uno stress test e/o un test di sistema fanno emergere eventuali problemi di memoria, ergo tramite i test verifichi i dettagli implementativi)... vado a lucca a lunedì :nod:

---

Hai veramente scritto che tramite gli stress-test verifichi i dettagli implementativi.....

Quindi non hai una idea di cosa sia la differenza tra white box testing e black box testing.

Toh, lo sanno anche a Microsoft:

http://msdn.microsoft.com/en-us/library/ff649503.aspx

Uno stress test è tipicamente black box.

O anche qua:

http://www.google.co.uk/url?sa=t&sou...O940XA&cad=rja

Tra parentesti, è una analisi ai morsetti del sistema.... in cui prendi il sistema da un punto di vista olistico, per definizione hai questi problemi:

Disadvantages of Black Box Testing
• Possibility that coincidental aggregation of
several errors will produce the correct response
for a test case, and prevent error detection.
• Absence of control of line coverage. There is no
easy way to specify the parameters of the test
cases required to improve coverage.
• Impossibility of testing the quality of coding and
its strict adherence to the coding standards.

Il black box testing è anche quello che usi per valutare le performance del sistema. Ma e' sempre in base a un comportamento che statisticamente pensi sia quello giusto. "W i deliri di onnipotenza..."

Il white box testing d'altro canto, prende il sistema da un punto di vista interno, riduzionista, e va a testare i blocchi e i dettagli implementativi... ma ha un banale svantaggio:
Non puoi testare ogni singola linea di codice e la sua interazione con il resto del sistema, è semplicemente troppo costoso.

Quindi, prestami un gomito Hador.

a regà ma un po di bunga bunga?

Quote:

---

Originally Posted by Palur

a regà ma un po di bunga bunga?

---

Perchè? Quello che ti fanno in sport non ti bastava e sei venuto a provare qua?

Torna da dove sei venuto, hai superato i confini della mappa. Qui ci sono gli informatici

hanno confermato la squalifica a krasic :(

sapete quanto costa un biglietto per los angeles?