La correttezza in probabilità ? Cioè intendi dire che statisticamente va almeno per il 95% di quello che l'utente normale vorrebbe andasse. Si questo è corretto.Quote:
Originally Posted by marlborojack
Printable View
La correttezza in probabilità ? Cioè intendi dire che statisticamente va almeno per il 95% di quello che l'utente normale vorrebbe andasse. Si questo è corretto.Quote:
Originally Posted by marlborojack
Sei un po' troppo spocchioso Hador, Vegeta non ha detto niente di scorretto. I test ovviamente servono, ma ti dicono solo che qualcosa funziona o non funziona, spesso non ti dice molto sull'interazione nel tempo dei vari componenti.Quote:
Originally Posted by Hador
La cosa piu' importante è il processo di debugging, che puo' essere aiutato coi test.
Beh per questo che ci sono più fasi di test
- Sviluppo, ma molte volte non si usano gli ambienti predisposti ma si usano i propri portatili o Mac per fare figo poi quando rilasciano sui sistemi di Release Management ti trovi di tutto e fioccano le madonne.
- IAT/UAT ambienti di integrazione accettazione che nella maggior parte delle volte sono mononodi
- PreProduzione, enviroment scalati dalla produzione ma con architetture di Cluster e Multistanze integrate tra loro nei vari mondi (Web/PRV etc.etc.) i DB sono le copie fisiche o restore effettuati tramite Storage.
(in questo ambiente vengono fatti gli stresstest e le prove di deploy in cluster mode, che sono i maggiori bagni di sangue/caporetto che hanno i software rilasciati.
TEST: Dipende dalla bravura dei gruppi di QA dalle specifiche che seguono la CR o il progetto e qui vengono redatti i TESTCase che sono gli scenari, che vengono studiati sui documenti che arrivano dall'analisti, dalla fattibilità dagli Architetti e i PM etc.etc.
Per questo che ci sono strumenti molto diffusi come la suite Mercury etc.etc.
La maggior parte dei problemi che si hanno nelle architetture enterprise è che chi si fregia di titolo di Architetto non sa una ceppa di nulla di Sistemi/Network e architetture, quindi fa il suo Software superfunzionante sul suo MAC, poi quando vai a fare integrazione/deploy scopri che non va una bega per poi sdraiarlo in pochi secondi quando lo bombardi con LoadRunner.
Alka: 10 anni fa si chiedeva che un Software Funzionasse ora si chiede che un Software sia PErformante ed Efficace c'è una differenza abissale tra i due concetti.
sei tu che fai casino, i test mica servono a provare il software, servono a garantire l'assenza di bug (a seconda della strategia in maniera matematica o probabilistica). La ricerca infatti sta nel trovare le strategie di test migliori per minimizzare lo sforzo e ottimizzare la probabilità di identificare i bug, l'esempio del coglione è il partition testing, se ho un metodo che processa una numero intero quali sono i test migliori che posso fare? Gli input sono infiniti, scriverò un test però per i casi significativi, -1, 0, 01, 1.1, numero random. Ho coperto tutti gli stati? no. Ho coperto gli stati sensibili? Si.Quote:
Originally Posted by Alkabar
Posso infatti utilizzare diversi criteri per valutare la mia test suite, dai diversi criteri di copertura (codice, controllo, data flow) a metodi attivi quali il fault injiection.
vammi pure contro, ci sto a fare la tesi su questa cosa :sneer:non è questione di esser spocchiosi, è questione che sbagli :pQuote:
Originally Posted by Alkabar
Beh non direi che sono il primo punto, ma di certo sono importanti. Pero' sono test usati in fase di sviluppo ed eseguiti dagli stessi sviluppatori, tante' vero che una delle critiche mosse a questi processi e' cosi' si rischia di ridurre l'importanza dei test di integrazione e quality assurance.Quote:
Originally Posted by Hador
Uno dei problemi maggiori non è la funzionalità ma trovare dev. capaci di fare software tunati a dovere.
Ti stai impelagando male:Quote:
Originally Posted by Hador
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. Se vai avanti a dir di ste cose mi fai pensare male.
O magari sei tu che hai studiato male il corso di ingegneria del software. Tutto sommato molto probabile considerando che arrivi a confondere imperativo con procedurale.Quote:
Posso infatti utilizzare diversi criteri per valutare la mia test suite, dai diversi criteri di copertura (codice, controllo, data flow) a metodi attivi quali il fault injiection.
vammi pure contro, ci sto a fare la tesi su questa cosa :sneer:non è questione di esser spocchiosi, è questione che sbagli :p
Che non clasha per niente col fatto che i test sono un aiuto al debugging, non sono il debugging. Altrimenti perchè mai faresti dei test...Quote:
Originally Posted by Karidi
Perchè poppi e assumi cose che non ho detto?Quote:
Alka: 10 anni fa si chiedeva che un Software Funzionasse ora si chiede che un Software sia PErformante ed Efficace c'è una differenza abissale tra i due concetti.
Certo non l'ho detto e rileggendo: non l'ho detto. E rileggendolo di nuovo: non l'ho detto quello che scrivi.
Ho detto che il test ti dice solo se un componente funziona o no, dove per funziona o no intendo che finisce nello stato corretto dato un certo input.
I test ovviamente servono, ma ti dicono solo che qualcosa funziona o non funziona, spesso non ti dice molto sull'interazione nel tempo dei vari componenti.
E quindi stai capendo cazzi per mazzi.Quote:
Originally Posted by Karidi
ma che cazzo di seghe mentali vi state facendo? Ha chiesto se c'era qualche linguaggio veloce da imparare da usare non in ambito profesisonale. Non ci sono altre risposte se non C# o VB.NET. L'ottimizzazione della gestione della memoria, il multithreading in ambito distribuito e la gestione delle concorrenze non credo siano una sua priorità. State solamente facendo una gara a chi ce l'ha più lungo e duro. LOL
Aggiungo, tanto per concludere, citando dal sommerville:
il software ha caratteristiche funzionali e non funzionali.
Le caratteristiche funzionali, riguardano la funzione del software. Quello che fa.
Le caratteristiche non funzionali, riguardano:
-performance
-Speed
-Resource Usage
-altro
E sono caratteristiche emergenti del software. 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.
Senza rancore eh, ma seriamente ora vi state impelagando davvero davvero male.
Beh, in tutta onestà non mi sono piaciute le uscite di Hador a gamba tesa su Vegeta sulla questione dei test e ho risposto, del 3D mi interessava davvero poco. Magari foste un po' piu' civili in generale invece che fare i galletti del quartiere, dico forse, la gente non risponderebbe.Quote:
Originally Posted by Eltarion
quel che a me pare probabile è che tu non abbia idea di che cosa si stia parlando invece :sneer:
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.
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...
No, sto parlando delle fasi che vengono dopo i rilasci del software e nelle sue fasi , e delle problematiche.Quote:
Originally Posted by Alkabar
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.