Litigio sui test

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.