Se è relativamente facile ottenere una buona copertura del codice dal profiling (perché la profilazione ti dice quali funzioni sono / non vengono chiamate, quante volte, e con quali parametri), come ottengo buona copertura dello scenario delle prestazioni quando si eseguono benchmark delle prestazioni?
Come faccio a sapere che non ci sono "buchi di prestazione" che non possono essere scoperti se non quando alcuni parametri di test sono molto vicini al "buco nero"?
Per un esempio di giocattolo, un algoritmo di ordinamento può essere testato con insiemi di dati di dimensione 1, 10, 100, 1000, 10000, ... . Un esempio di copertura non numerica consisterebbe nel testare l'algoritmo di ordinamento con sorted data , unsorted data o evil-constructed data intended to expose the worst case . Questi scenari sono stati investigati esaurientemente dal mondo accademico nel caso di algoritmi di ordinamento.
Come applicare quel pensiero in altri tipi di sistemi software?