Caratterizzazione nei test: test unitario o test funzionale [duplicato]

0

Quindi sto cercando di spingere per test più automatizzati nella mia azienda, che si concentrano molto sui prototipi e sui sistemi di proof of concept.

Al momento utilizziamo Google Test per i test delle unità. Questo test di casi di test specifici per correttezza, ma molte delle cose che facciamo le metriche per come il codice sta eseguendo seguono più di un "funziona meglio o peggio di prima, e se funziona peggio, è una perdita accettabile in performance "di un booleano" sì no ". Questi test chiamo "Caratterizzazione" per mancanza di un termine migliore (ho uno sfondo EE, quindi citato in giudizio): descrive come si comporta il codice. Abbiamo bisogno di avere la metrica per tutte le build e abbiamo bisogno di essere in grado di confrontarla tra le build per vedere quale direzione stiamo andando. Spesso possiamo fare un cuttoff generale per fare fallire un passaggio di alto livello, ma questi test possono essere estesi: richiedono molto tempo per essere eseguiti e spesso richiedono operazioni di number crunching e di pianificazione. Questo sembra essere fuori portata per un Test unitario, più per un Test funzionale nella mia mente (ma non sono un esperto di test). In che modo le persone / le aziende gestiscono questo tipo di test? C'è qualche quadro per questo tipo di test là fuori?

    
posta IdeaHat 27.03.2014 - 21:55
fonte

2 risposte

2

Stai parlando di prestazioni, che è essenzialmente un Requisito Non Funzionale.

La mia opinione è che la maggior parte di questi sono per l'intero sistema.

Un utente non dirà mai "Voglio che la classe WidgetListCollection restituisca un widget entro 20 nanosecondi" - potrebbe dire "Voglio un elenco di tutti i prodotti sul mio schermo entro 1,5 secondi".

L'unico modo per testare veramente questi è testare il sistema completo. Se la schermata degli utenti viene aggiornata entro 0,25 secondi al di sopra del NFR del 600%, non importa se la classe WdigetListCollection è sub-ottimale. Qualsiasi sforzo impiegato per ottimizzarlo potrebbe essere speso meglio altrove, facendo qualcosa che sia importante per l'utente.

Peggio ancora se testate questa roba a livello di test unitario non solo vi incoraggia a perdere tempo con le micro-ottimizzazioni, il vostro test potrebbe generare falsi allarmi:

Supponiamo che possa apportare una modifica alla classe, quindi ora è 5 volte più lento, tuttavia ora memorizza nella cache la cronologia di utilizzo del widget, facendo in modo che l'intero sistema funzioni due volte più velocemente. Comunque, durante l'incontro settimanale mi imbatto comunque per prestazioni scadenti.

Il test delle unità è buono. Ma ha i suoi limiti, alla fine è il sistema nel suo complesso che deve funzionare a spec. Essere consapevoli del fatto che il sistema può ancora fallire miseramente anche se tutti i singoli componenti sono eccellenti.

    
risposta data 28.03.2014 - 11:38
fonte
1

How do people/companies handle this type of test?

Ci sono molti tipi di test, ma i tuoi interessi sono unitari e funzionali:

  • unit test - deve essere molto veloce, per essere eseguito ad ogni cambio nel codice. Il loro scopo è testare i moduli.
  • test funzionali - sono simili ai test unitari, tranne che non devono essere veloci. Vengono eseguiti quando si lavora su di essi, quando non ci sono cambiamenti nel bagagliaio per poche ore, o quando si fanno build notturne.

Is there any framework for this type of test out there?

Per fare build notturne e per eseguirle quando non ci sono attività nel bagagliaio per poche ore, le persone usano framework come jenkins.

    
risposta data 28.03.2014 - 09:37
fonte

Leggi altre domande sui tag