Come si superano / falliscono i test delle prestazioni?

Performance testing seems to be popular

È popolare in teoria. In pratica, ho visto solo una manciata di test delle prestazioni automatizzati eseguiti e sono stati eseguiti a casaccio.

How would I test that Build 1.4 is a pass/fail for this test?

Definisci un criterio pass / fail. Se è necessario che i test siano coerenti, definire alcuni criteri e misure di errore. Se hai bisogno che i test siano almeno X veloci (dove X è idealmente una metrica raccolta dai test di usabilità), allora fallo. Se non è X peggiore dell'ultima build (non consigliato nei test automatici, poiché richiede memoria delle versioni precedenti), fallo.

È banale scrivere il codice di supporto per gestire misure e / o statistiche. Ma hai ancora bisogno di definire i criteri, proprio come qualsiasi altro test. È come chiedere di definire automaticamente i criteri pass / fail per le regole di business: i computer fanno un lavoro pessimo, dal momento che tutto quello che sanno sulle regole di business è quello che gli dici.

La risposta alla tua domanda è altamente specifica del caso. Sembri già a conoscenza delle varie tecniche di test delle prestazioni.

Tu devi determinare quali sono le tue misurazioni previste. Può essere accettabile iniziare dicendo "la nostra misurazione prevista è la misurazione corrente" e quindi semplicemente tracciare le modifiche nel tempo. Se è "impraticabile o addirittura impossibile" ottenere un valore atteso, allora non vedo come la misurazione della performance sarebbe significativa.

Non posso promettere che questo sia ottimale, solo che è come ho gestito i test delle prestazioni con moderato successo.

Test di integrazione "reali" abbastanza consistenti vengono eseguiti con un timer, N ripetizioni per test. Conserva i risultati in un database. Periodicamente una serie di risultati viene contrassegnata come linea di galleggiamento e le esecuzioni successive vengono confrontate con quella, ad es. per una versione, o quando l'hardware di test cambia, o quando abbiamo implementato qualcosa di furbo e tutto gira più veloce.

Il numero magico usato per il confronto è il minimo del set di risultati. Un errore si verifica se è maggiore di un numero fisso (mezzo secondo circa) ed è superiore di k% più lento della linea di galleggiamento corrente.

Il tempo minimo sembra essere piuttosto stabile, ma poiché i test delle prestazioni vengono eseguiti su una macchina Windows, il tempo peggiore salta in tutto il negozio. Periodicamente l'esecuzione del test si scontra con una scansione antivirus o aggiornamenti di Windows, ad esempio. Di conseguenza, una fase di test dei tentativi falliti automatizzati viene eseguita alla fine per cercare di eliminare alcuni errori difficili da riprodurre.

La sintonizzazione manuale coinvolta nel k% e il tempo fisso è sfortunata. Sospetto che una soluzione più strong implichi la ricerca di tendenze statisticamente significative e l'innesco di un fallimento basato su una metrica probabilistica. Tuttavia, quanto sopra è semplice ma cattura ancora le regressioni delle prestazioni.