Litigio sui test

Il discorso uno deve imparare quello che più gli piace o si trova portato, come per i Sistemi Operativi come per altre cose ci saranno sempre divergenze chi preferisce Java o MS, per l'autore del post sarebbe giusto illustrare anche finalizzato a cosa l'imparare a programmare.

Quote:

---

Originally Posted by Karidi

No, sto parlando delle fasi che vengono dopo i rilasci del software e nelle sue fasi , e delle problematiche.
Grazie, che non puoi provare il carico (che fa parte del mondo dei TEST, visto che si chiamano STRESSTEST) perchè non hai l'architettura per poterlo fare, non hai un architettura scalata della produzione con apparati di rete e integrata etc.etc.
Non sto rispondendo a te, sto rispondendo in generale su una discussione che è ormai andata OT, parlando da NON programmatore, ma da chi deve subirsi gli ABORTI che tanti pseudo Architetti/ingegneri del software producono.

L'ultima frase era una conclusione quando ti dicevo la differenza con 10anni fà, ma come al solito la prendi sul personale.

---

Ma se mi dici "ALKA", la prendo sul personale si, scusa eh :sneer:

Quote:

---

Originally Posted by Alkabar

Ma se mi dici "ALKA", la prendo sul personale si, scusa eh :sneer:

---

Si ma un conto di dico
Alka, ma che cazzate dici

un altro

Alka, e faccio un discorso generico

Quote:

---

Originally Posted by Hador

quel che a me pare probabile è che tu non abbia idea di che cosa si stia parlando invece :sneer:

---

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.

Quote:

---

devo andare a pappa, ma tu non insegnavi sta roba? 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. Dato che non puoi utilizzi delle strategie, o ottimistiche (es partition testing), o pessimistiche (es analisi statica), o di astrazione (model checking). Il debug non centra una sega, il software critico secondo te è controllato a mano facendo debug? Ma che stai dicendo alka.
E giga lol sul fatto che il testing si fa solo su caratteristiche funzionali, la validazione che fa scusa? Va bene fare il tuttologo ma fino ad un certo punto.

---

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.

Quote:

---

Non esiste un modo per testare le performance o usabilità mentre fai le cose? ma tutta la sega sui processi iterativi a che minchia serve allora, per sport? Mha...

---

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.

Quote:

---

Originally Posted by Karidi

Si ma un conto di dico
Alka, ma che cazzate dici

un altro

Alka, e faccio un discorso generico

---

Chiaro, chiaro, ho riletto, hai ragione, mi stava montando l'astio per Hador e sei finito nel ciclone.

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...