Se intendi come vengono trovati i requisiti minimi / consigliati del sistema, l'applicazione viene semplicemente provata su macchine diverse.
Nella maggior parte dei casi, c'è no hard limit : se l'applicazione funziona con 512 MB di memoria, probabilmente funzionerà anche con 511 MB di RAM (a meno che non controlli esplicitamente la memoria) . Ciò significa che potresti avere un numero limitato di macchine da utilizzare per il benchmarking e dedurre i limiti da lì. Ad esempio, se la macchina con 1 GB di RAM riesce a eseguire a malapena l'app, mentre una macchina con 4 GB di RAM lo esegue abbastanza bene e mantiene in media da 1 a 2 GB gratuiti, i requisiti minimi di sistema possono includere 2 GB di memoria.
Precisione
Nota che il benchmarking e la profilazione sono precisi. Un requisito di prestazione non funzionale, ad esempio, specificherà in dettaglio l'hardware di test e il carico, il numero di millisecondi che rappresentano la soglia e la percentuale di soglia. È quindi possibile eseguire un test automatico che passa o non riesce, a ogni commit, che indica quando l'app è diventata più lenta del previsto. Parlare di sentimenti ("questa parte dell'app sembra rallentare per me") è inaccettabile, perché l'avvocato del tuo cliente può affermare che l'app non si sente ancora abbastanza veloce, mentre hai speso negli ultimi due mesi, ottimizzandolo e trovandolo estremamente veloce.
Quando si tratta di requisiti minimi / consigliati del sistema, tale precisione è raramente richiesta. La persona che annota i requisiti di sistema può infatti semplicemente testare l'app su più macchine e utilizzare il suo sentimento di veloce / lento come unico criterio. Se invece il contratto prevede che l'app debba essere eseguita su una macchina con 2 GB di memoria, dovrebbe essere nella specifica dei requisiti del software, scritta in termini non ambigui (vedi sopra).
Ambiente di test
Nota anche che:
-
Dovresti testare il software su hardware diverso comunque (a meno che, ovviamente, il software non sia distribuito in un ambiente controllato, come un singolo data center), quindi ci sono possibilità che tu hai già l'infrastruttura di cui hai bisogno.
-
Le macchine virtuali rendono tali test meno costosi rispetto all'acquisto di dozzine di macchine reali e reali.
Tuttavia, il testing su macchine virtuali potrebbe non essere semplice come lanciare una VM nel pool: mentre molti hypervisor (o sistemi operativi stessi) svolgono un ottimo lavoro consentendo di limitare alcuni aspetti (come la larghezza di banda della rete), richiede ancora una configurazione aggiuntiva.
Complessità
Ho usato la RAM come illustrazione, ma la stessa logica si applica a qualsiasi altro aspetto: velocità della CPU, spazio libero su disco rigido, velocità di tali dischi rigidi, larghezza di banda della rete, ecc. Senza contare che lo stesso hardware potrebbe non funzionare esattamente lo stesso ogni volta.
Ad esempio, uno dei miei prodotti software ha avuto un bug che ho speso un sacco di tempo per eseguire il debug. Sembra che quando Windows mette i dischi rigidi in stand-by quando non vengono utilizzati per alcuni minuti e hanno dormito a lungo, svegliarli richiede un po 'di tempo, che a volte ha attivato un timeout nella mia app.
Ciò rende questo test un compito difficile, anche con macchine virtuali. Questa è una delle due maggiori complessità del software desktop, l'altra è il fatto che il prodotto software deve sopravvivere in natura, vale a dire andare d'accordo con migliaia di altri prodotti software (incluso il malware) che possono essere installati, gestire diverse configurazioni , opzioni di accessibilità, cose rotte, ecc.