aet - Online nel cloud

PROGRAMMA:

NOME

aegis test - esegui test

SINOSSI

egida -Test [ opzione... ][ Nome=APPREZZIAMO ][ nome del file...]
egida -Test -Indipendente [ opzione... ][ Nome=APPREZZIAMO ][ nome del file...]
egida -Test -Elenco [ opzione...]
egida -Test -Aiuto

DESCRIZIONE

I egida -Test comando viene utilizzato per eseguire i test. Se non viene nominato alcun file, tutti i test pertinenti
sono eseguiti. Per impostazione predefinita vengono eseguiti sia i test automatici che quelli manuali.

Puoi nominare le directory sulla riga di comando e tutti i test rilevanti in quella directory
albero nella modifica verrà eseguito. È un errore se non ci sono test pertinenti.

Ogni architettura deve essere testata separatamente. Questo perché potrebbe essere sottile
problemi che si manifestano solo su alcune architetture. Alcuni progetti potrebbero anche avere
codice diverso per architetture diverse.

Viene ricordato lo stato dell'ultimo test eseguito in modo che i test non vengano eseguiti se non c'è nessun
bisogno. (Questo non si applica a -Regressione test, sfortunatamente.) I test devono essere rieseguiti
se il test ha fallito in precedenza, se il file di test è cambiato, se c'è stata una build,
e per ogni architettura.

nome=valore
È possibile aggiungere Nome=APPREZZIAMO coppie alla riga di comando, queste verranno passate invariate al
comando di prova. Di solito alla fine della riga di comando, ma questo può essere modificato nel
file di configurazione del progetto.

I -vigore l'opzione determina l'aggiunta di una variabile implicita force=1 all'elenco di
assegnazioni di variabili, e quindi aggiunti alla fine del comando. Questo è molto utile quando
usando il batch_test_comando archiviato del file di configurazione del progetto.

Questo potrebbe inizialmente sembrare un processo di sviluppo che consente di eseguire gli script di test
scritti in modo che diano tutte le risposte giuste senza in realtà fare nulla. Voi
sono sempre stato in grado di farlo con le variabili d'ambiente, quindi non è niente di nuovo.

È possibile trasformare tutte le assegnazioni delle variabili in variabili d'ambiente
mettendo $var al inizia a del comando, prima del nome della shell, piuttosto che at
la posizione predefinita alla fine del comando.

Compila il Nome Interpretazione
Il programma aegis tenterà di determinare i nomi dei file di progetto dai nomi dei file
dato sulla riga di comando. Tutti i nomi dei file sono memorizzati all'interno dei progetti aegis come relativi
alla radice dell'albero di directory di base. La directory di sviluppo e il
directory di integrazione sono ombre di questa directory di base, e quindi questi nomi relativi
applica anche qui. I file nominati sulla riga di comando vengono prima convertiti in percorsi assoluti
se necessario. Vengono quindi confrontati con il percorso di base, la directory di sviluppo
percorso e il percorso della directory di integrazione per determinare un nome relativo alla linea di base. è
un errore se il file denominato è al di fuori di uno di questi alberi di directory.

I -BASE_RElativo l'opzione può essere usata per far interpretare i nomi di file relativi come
rispetto al percorso della linea di base; i nomi di file assoluti verranno comunque confrontati con i vari
percorsi per determinare un nome relativo alla linea di base.

I relativo_nome_file_preferenza nel file di configurazione utente può essere utilizzato per modificare
questo comportamento predefinito. Vedere aeuconf(5) per maggiori informazioni.

TEST PROCESSO

Ogni modifica deve essere accompagnata da test e tali test devono essere
eseguire contro la directory di sviluppo compilata e devono passare. Questo assicura che il nuovo
la funzionalità è accompagnata da test per verificarne la correttezza e le correzioni di bug sono
accompagnato da test che confermano che il bug è stato corretto.

Regressione Test
I test vengono trattati come qualsiasi altro file sorgente e vengono mantenuti nella linea di base e
cronologia con tutti gli altri file di origine. I test che devono accompagnare ogni cambiamento
accumularsi nella linea di base del progetto, fornendo una definizione della corretta funzione per il
linea di base. Questi test accumulati possono essere eseguiti utilizzando un comando "aegis -REGression",
per verificare che il progetto non “regredirà” a seguito di una modifica.

Linea di base Test
Le correzioni di bug sono necessarie per avere i loro test fallire rispetto alla linea di base del progetto (al contrario
alla directory di sviluppo). Ciò garantisce che il test dimostri effettivamente il bug
nella linea di base, oltre a dimostrare che è fissato dal cambiamento. Nuovo
la funzionalità fallisce banalmente rispetto alla linea di base, quindi aegis non tenta di farlo
indovina se un test è un test di correzione di bug o un test di nuove funzionalità, richiede semplicemente dei test per
fallire contro la linea di base.

Questo requisito si applica sia ai nuovi test creati da una modifica, sia ai test
che sono stati copiati in una modifica per la modifica.

Revisione Test
I revisori possono essere certi che aegis abbia applicato i requisiti del test; che un cambiamento
deve avere test, che il cambiamento deve costruire, che i test passino contro lo sviluppo
directory e che i test abbiano esito negativo rispetto alla linea di base. Queste condizioni sono applicate
by aede(1) e la modifica non verrà anticipata al essendo rivisto stato fino a questi
le condizioni sono soddisfatte. I revisori dovrebbero quindi rivedere i test per completezza di copertura di
il codice nella modifica e l'insensibilità alle modifiche nell'ambiente di esecuzione (ad es
non sensibile alla data). I revisori dovrebbero anche usare "aegis -list change_details" per verificare
che una modifica ha o non ha esenzioni dai test.

esenzioni
Varie esenzioni dai test possono essere concesse dagli amministratori del progetto, vedere aep(1) e
aepattr(5) per maggiori informazioni. Copiare i test in una modifica o aggiungere nuovi test a a
modifica, può annullare tali esenzioni.

TEST COMANDO CONFIGURAZIONE

Il comando utilizzato per eseguire i test è definito da comando_prova campo nel progetto
file di configurazione (vedi aepconf(5) per maggiori informazioni), questo per impostazione predefinita utilizza il
Bourne shell se non impostato. La directory corrente sarà la parte superiore dell'appropriata
albero di directory. Se i test richiedono file temporanei, dovrebbero crearli in / Tmp, come un
test non può aspettarsi di avere i permessi di scrittura nella directory corrente.

Se vuoi usare un motore di test più sofisticato, piuttosto che un semplice script di shell,
ma questo motore di prova non restituisce codici risultato adatti per l'uso con aegis, potresti
avvolgerlo in uno script di shell che riscrive lo stato di uscita nei valori che aegis si aspetta.
Potresti anche ottenere gli stessi risultati scrivendo un testo più complesso comando_prova nel
progetto config file.

È anche possibile scrivere comandi di test in grado di testare più di un file su
una volta. Questo è controllato dal batch_test_comando campo del progetto config file. Nel
in questo caso, la sostituzione ${output} indica il nome di un file che il comando di test deve
creare, in aetest(5) formato, per contenere i risultati dei test eseguiti. Questo è spesso usato
su sistemi con più CPU o la possibilità di distribuire lavori su più computer
su una rete.

Sostituzioni
Tutto il esub(5) le sostituzioni sono disponibili nei comandi di test. Alcuni di loro sono
di particolare rilievo:

Architettura
Questa sostituzione è sostituita dal nome dell'architettura da testare.

Cerca_Percorso
Questa sostituzione è sostituita da un elenco separato da due punti di percorsi assoluti per
ricerca quando si cercano file di supporto per i test.

Search_Path_Eseguibile
Questa sostituzione è sostituita da un elenco separato da due punti di percorsi assoluti per
ricerca quando si cercano file di supporto eseguibili (file di libreria e sotto-
comandi).

La maggior parte delle volte $Search_Path_Eseguibile sono esattamente gli stessi. Tuttavia, durante “aegis -t
-bl” saranno diversi, con $Percorso_di_ricerca a partire dalla directory di sviluppo (la
test in corso) e $Seach_Path_Eseguibile a partire dalla linea di base (l'essere eseguibile
correre).

Test Risultato Codici
Poiché ogni test viene eseguito (tramite il comando_prova campo nel progetto config file), egis
determina se il test ha avuto successo o meno guardando il suo stato di uscita. questa uscita
lo stato è per lo più come previsto per i comandi UNIX.

Storie Di
Un test dovrebbe uscire da 0 per indicare il successo, ovvero che la funzione specifica sotto test
ha funzionato come previsto.

Fallimento
Un test dovrebbe uscire da 1 per indicare un errore, ovvero che la funzione specifica in prova
non ha funzionato come previsto.

Nessun risultato
Un test dovrebbe uscire da 2 per indicare nessun risultato, vale a dire che la funzione specifica sotto
non è stato possibile eseguire il test perché qualcos'altro è andato storto. Ad esempio, correndo
esaurito lo spazio su disco durante la creazione dei file di input di prova nel / Tmp directory.

saltato
Un test dovrebbe uscire da 77 per indicare che è stato saltato. Questo di solito ha a che fare con
l'architettura attuale non è significativa. Quando possibile, usa "Nessun risultato"
Invece. (Il valore è stato scelto per la compatibilità con altri sistemi di test.)

In realtà, qualsiasi codice di uscita diverso da 0, 1 o 77 verrà interpretato come "nessun risultato".
Tuttavia, usare sempre 0, 1, 2 o 77 significa che se un nuovo codice risultato è richiesto da a
versioni successive di Aegis, i test esistenti continueranno a funzionare.

TEST CORRELAZIONI

Il comando "aegis -Test -SUGgest" può essere usato per fare in modo che aegis suggerisca una regressione adeguata
verifica la tua modifica, in base ai file di origine nella tua modifica. Questo automaticamente
concentra lo sforzo di test sui test pertinenti, riducendo il numero di test di regressione
necessario essere sicuri di non aver introdotto un bug.

Le correlazioni di test sono generate dal comando “aegis -Integrate_Pass”, che
associa ogni test nella modifica a ogni file sorgente nella modifica. Così, ogni
file sorgente accumula un elenco di test che sono stati associati in passato.
Questo non è esatto come l'analisi della copertura del codice, ma è un'approssimazione ragionevole in
pratica.

I PCEA(1) e aenf(1) i comandi vengono utilizzati per associare i file a una modifica. Mentre loro
non eseguire attivamente l'associazione, questi sono i file utilizzati da aeipass(1) e
e(1) per determinare quali file di origine sono associati a quali test.

Test Correlazione Precisione
Supponendo che le correlazioni dei test siano accurate e che i test siano uniformi
distribuito nello spazio delle funzioni, ci sarà meno di 1/numero possibilità che a
relativo test non è stato eseguito da “aegis -Test -SUGgest numerocomando. Un piccolo
la quantità di rumore viene aggiunta alla ponderazione del test, in modo che a volte si verifichino cose inaspettate
testato e gli stessi test non vengono eseguiti ogni volta.

L'accuratezza della correlazione del test può essere migliorata assicurando che:

· Ogni modifica dovrebbe essere fortemente focalizzata, senza inclusioni di file gratuite. Questo
evita correlazioni spurie.

· Ogni elemento di nuova funzionalità dovrebbe essere aggiunto in un singolo cambiamento, piuttosto che
diversi insieme. Questo correla fortemente i test con la funzionalità.

· Ogni bug dovrebbe essere corretto in un singolo cambiamento, piuttosto che diversi insieme. Questo
correla fortemente i test con la funzionalità.

· Le correlazioni di prova andranno perse se i file vengono spostati. Questo perché le correlazioni sono di
nome.

Il modo migliore per correlare accuratamente i test con i file di origine è quando un cambiamento
contiene un test ed esattamente quei file relativi alla funzionalità in prova. Pure
molti file spuri indeboliranno l'utilità delle correlazioni di test.

VERSIONI

Si intendono le seguenti opzioni:

-Automatico
Questa opzione può essere utilizzata per specificare i test automatici. I test automatici non richiedono
assistenza umana.

-Linea di base
Questa opzione può essere utilizzata per specificare che la linea di base del progetto è oggetto di
il comando.

-BASE_RElativo
Questa opzione può essere usata per far sì che i nomi di file relativi siano considerati relativi a
la base dell'albero di origine. Vedere aeuconf(5) per l'utente corrispondente
preferenza.

-COrrent_RElativo
Questa opzione può essere usata per far sì che i nomi di file relativi siano considerati relativi a
la directory corrente. Di solito è l'impostazione predefinita. Vedere aeuconf(5) per la
corrispondente preferenza dell'utente.

-Modificare numero
Questa opzione può essere utilizzata per specificare una particolare modifica all'interno di un progetto. Vedere
egida(1) per una descrizione completa di questa opzione.

-Forza Questa opzione può essere utilizzata per specificare che tutti i test devono essere eseguiti, anche se il
lo stato dell'ultima esecuzione del test indica che non è necessario eseguire uno specifico
test.

-Aiuto
Questa opzione può essere utilizzata per ottenere maggiori informazioni su come utilizzare il egida
.

-Indipendente
Questa opzione viene utilizzata per specificare che il test deve essere eseguito indipendentemente da qualsiasi
particolare cambiamento. Se non viene nominato alcun test, verranno eseguiti tutti i test nella linea di base.

-Elenco
Questa opzione può essere utilizzata per ottenere un elenco di soggetti idonei per questo comando.
L'elenco potrebbe essere più generale del previsto.

-Manuale Questa opzione può essere utilizzata per specificare i test manuali. I test manuali richiedono un po' di persone
intervento, es: conferma di alcuni comportamenti dello schermo (X11, per esempio), oppure
qualche azione dell'utente, "scollegare il cavo ethernet ora".

-Non_registrazione
Questa opzione può essere utilizzata per disabilitare la registrazione automatica dell'output e degli errori per
un file. Questo è spesso utile quando diversi comandi di aegis sono combinati in una shell
script.

-Perseverare
Questa opzione può essere utilizzata per specificare che tutti i test devono essere eseguiti, anche se alcuni
fallire. Default a quello dell'utente perseverare_preference se non specificato, vedi
aeuconf(5) per maggiori informazioni.

-No_PERsevere
Questa opzione può essere utilizzata per specificare che l'esecuzione del test deve interrompersi dopo il primo
fallimento. Impostazioni predefinite per l'utente perseverare_preference se non specificato, vedi
aeuconf(5) per maggiori informazioni.

-Progetto Nome
Questa opzione può essere utilizzata per selezionare il progetto di interesse. quando no -Progetto
l'opzione è specificata, il AEGIS_PROGETTO viene consultata la variabile di ambiente. Se
che non esiste, l'utente $HOME/.aegisrc il file viene esaminato per un valore predefinito
campo del progetto (vedi aeuconf(5) per maggiori informazioni). Se ciò non esiste,
quando l'utente sta lavorando solo sulle modifiche all'interno di un singolo progetto, il progetto
nome predefinito su quel progetto. Altrimenti è un errore.

-Progresso
Questa opzione può essere utilizzata per specificare che i messaggi di avanzamento devono essere emessi prima
ogni esecuzione di test o prima di ogni esecuzione di test batch nel caso batch_test_comando campo
specificato nel progetto config file (vedi aeuconf(5) per maggiori informazioni).

-Nessun progresso
Questa opzione può essere utilizzata per specificare che i messaggi di avanzamento devono essere soppressi.
Questo è l'impostazione predefinita.

-Regressione
Questa opzione viene utilizzata per specificare che deve essere eseguita la suite di test di regressione. Il
la suite di test di regressione è costituita da tutti i test nella linea di base che non compaiono
nel cambiamento. È un errore se non ci sono test di regressione. potresti non
test del nome sulla riga di comando quando si utilizza l'opzione -REGression. puoi nominare
singoli test da eseguire sulla riga di comando, senza utilizzare la -REGression
opzione; se non fanno parte della modifica, le prove omonime nel
verrà eseguita la linea di base.

-Suggerire [ numero ]
Il "egida -Integra_Pass" Il comando raccoglie le statistiche di correlazione dei test quando
le modifiche sono integrate. Questa opzione può essere utilizzata per richiedere che aegis suggerisca
quali test devono essere eseguiti, utilizzando queste correlazioni di test. Se nessun numero è
specificato, verranno suggerite 10 prove. Questa opzione implica il -Regressione
opzione.

-SUGgest_Limite verbale
Questa opzione può essere utilizzata per limitare il numero di test a un certo numero di
minuti. Saranno eseguiti dal più rilevante al meno rilevante.

-SUGgest_Rumore numero
Questa opzione può essere utilizzata per controllare la quantità di rumore iniettato nel test
selezione effettuata dal -Suggerire opzione. Il numero è una percentuale di rumore
da iniettare. Il valore predefinito è 10 se non specificato. L'iniezione di rumore assicura
che una varietà di test viene eseguita su esecuzioni successive, e anche alcuni dal campo sinistro
come un controllo di sanità mentale.

-TERse
Questa opzione può essere utilizzata per far sì che le inserzioni producano il minimo indispensabile di
informazione. Di solito è utile per gli script di shell.

-Verboso
Questa opzione può essere utilizzata per far sì che aegis produca più output. Per impostazione predefinita egida
produce solo output sugli errori. Se utilizzato con il -Elenco opzione questa opzione
causa l'aggiunta di intestazioni di colonna.

-Aspettare Questa opzione può essere utilizzata per richiedere ai comandi Aegis di attendere i blocchi di accesso, se
non possono essere ottenuti immediatamente. Impostazioni predefinite per l'utente lock_wait_preference
se non specificato, vedi aeuconf(5) per maggiori informazioni.

-Non aspettare
Questa opzione può essere utilizzata per richiedere ai comandi Aegis di emettere un errore fatale se access
i blocchi non possono essere ottenuti immediatamente. Impostazioni predefinite per l'utente
lock_wait_preference se non specificato, vedi aeuconf(5) per maggiori informazioni.

Vedi anche egida(1) per le opzioni comuni a tutti i comandi aegis.

Tutte le opzioni possono essere abbreviate; l'abbreviazione è documentata come le lettere maiuscole,
tutte le lettere minuscole ei caratteri di sottolineatura (_) sono facoltativi. Devi usare consecutivo
sequenze di lettere facoltative.

Tutte le opzioni non fanno distinzione tra maiuscole e minuscole, puoi digitarle in maiuscolo o minuscolo o a
combinazione di entrambi, il caso non è importante.

Ad esempio: gli argomenti "-project, "-PROJ" e "-p" sono tutti interpretati come il
-Progetto opzione. L'argomento "-prj" non sarà compreso, perché consecutivo
caratteri facoltativi non sono stati forniti.

Opzioni e altri argomenti della riga di comando possono essere mescolati arbitrariamente sulla riga di comando,
dopo i selettori di funzione.

I nomi lunghi delle opzioni GNU sono compresi. Poiché tutti i nomi delle opzioni per egida sono lunghi,
questo significa ignorare l'extra '-'. Il "--opzione=APPREZZIAMO"convenzione è anche
inteso.

CONSIGLIATO ALIAS

L'alias consigliato per questo comando è
csh% alias aet 'aegis -t \!* -v'
sh$ aet(){aegis -t "$@" -v}

ERRORI

È un errore se il cambiamento non è in uno dei essendo sviluppato or essendo integrato
stati.
È un errore se la modifica non è assegnata all'utente corrente.
È un errore se non si dispone di test pertinenti e di esenzioni pertinenti.

EXIT STATUS

I egida il comando uscirà con uno stato di 1 su qualsiasi errore. Il egida il comando sarà solo
esci con stato 0 se non ci sono errori.

AMBIENTE VARIABILI

See egida(1) per un elenco di variabili d'ambiente che possono influenzare questo comando. Vedere
aepconf(5) per i file di configurazione del progetto specifico del progetto campo per come impostare
variabili d'ambiente per tutti i comandi eseguiti da Aegis.

Utilizzare aet online utilizzando i servizi onworks.net