aet - Online în cloud

PROGRAM:

NUME

Aegis test - rulați teste

REZUMAT

egidă -Test [ opțiune... ][ nume=valoare ][ nume de fișier... ]
egidă -Test -Independent [ opțiune... ][ nume=valoare ][ nume de fișier... ]
egidă -Test -Listă [ opțiune... ]
egidă -Test -Ajutor

DESCRIERE

egidă -Test comanda este folosită pentru a rula teste. Dacă nu sunt denumite fișiere, toate testele relevante
sunt conduse. În mod implicit, se execută atât testele automate, cât și cele manuale.

Puteți numi directoare pe linia de comandă și toate testele relevante din acel director
arborele în schimbare va fi rulat. Este o eroare dacă nu există teste relevante.

Fiecare arhitectură trebuie testată separat. Acest lucru se datorează faptului că poate fi subtil
probleme care sunt relevate doar pe unele arhitecturi. Unele proiecte pot avea, de asemenea
cod diferit pentru arhitecturi diferite.

Starea ultimei testări este memorată, astfel încât testele să nu fie executate dacă nu există
nevoie. (Acest lucru nu se aplică pentru -Regresie teste, din păcate.) Testele trebuie reluate
dacă testul a eșuat anterior, dacă fișierul de test s-a schimbat, dacă a existat o construcție,
și pentru fiecare arhitectură.

nume=valoare
Puteți adăuga nume=valoare perechi la linia de comandă, acestea vor fi transmise neschimbate la
comanda de testare. De obicei, la sfârșitul liniei de comandă, dar acest lucru poate fi schimbat în
fișier de configurare a proiectului.

-forta opțiunea are ca rezultat adăugarea unei variabile implicite forță=1 la lista de
atribuiri variabile și astfel adăugate la sfârșitul comenzii. Acesta este cel mai util atunci când
folosind batch_test_command arhivat din fișierul de configurare a proiectului.

Acest lucru poate arăta inițial ca un proces de dezvoltare la final, permițând scripturilor de testare să fie
scris astfel încât să dea toate răspunsurile corecte fără să facă nimic. Tu
am reușit întotdeauna să facă asta cu variabilele de mediu, așa că nu este ceva nou.

Este posibil ca toate atribuirile de variabile să se transforme în variabile de mediu
punând $var la Începe a comenzii, înainte de numele shell-ului, mai degrabă decât la
locația implicită la sfârșitul comenzii.

Fișier Nume si Prenume Interpretare
Programul Aegis va încerca să determine numele fișierelor de proiect din numele fișierelor
dat pe linia de comandă. Toate numele fișierelor sunt stocate în proiectele Aegis ca relative
la rădăcina arborelui de directoare de bază. Directorul de dezvoltare și
directorul de integrare sunt umbre ale acestui director de bază și astfel aceste nume relative
aplica si aici. Fișierele numite pe linia de comandă sunt mai întâi convertite în căi absolute
daca este necesar. Acestea sunt apoi comparate cu calea de bază, directorul de dezvoltare
cale și calea directorului de integrare, pentru a determina un nume relativ de referință. Este
o eroare dacă fișierul numit este în afara unuia dintre acești arbori de directoare.

-BAse_RElative opțiunea poate fi utilizată pentru a face ca numele de fișiere relative să fie interpretate ca
relativ la calea liniei de bază; nume de fișiere absolute vor fi în continuare comparate cu diferite
căi pentru a determina o denumire relativă de bază.

relative_filename_preference în fișierul de configurare utilizator poate fi utilizat pentru modificare
acest comportament implicit. Vedea aeuconf(5) pentru mai multe informații.

TEST PROCESUL

Fiecare modificare trebuie să fie însoțită de teste, iar acele teste trebuie să fie
rulați împotriva directorului de dezvoltare construit și trebuie să treacă. Acest lucru asigură că nou
funcționalitatea este însoțită de teste pentru a verifica corectitudinea acesteia, iar remedierea erorilor sunt
însoțită de teste care confirmă că eroarea a fost remediată.

Regres Teste
Testele sunt tratate ca orice alt fișier sursă și sunt menținute în linia de bază și
istoric cu toate celelalte fișiere sursă. Testele care trebuie să însoțească fiecare schimbare
se acumulează în linia de bază a proiectului, oferind o definiție a funcției corecte pentru
de bază. Aceste teste acumulate pot fi executate folosind o comandă „aegis -REGression”,
pentru a verifica că proiectul nu va „regresa” ca urmare a unei modificări.

De bază Teste
Remedierea erorilor este necesară pentru a avea teste eşua față de linia de bază a proiectului (în contrast
la directorul de dezvoltare). Acest lucru asigură că testul demonstrează de fapt eroarea
în linia de bază, precum și să demonstreze că este fixat de modificare. Nou
funcționalitatea eșuează trivial față de linia de bază și, prin urmare, Aegis nu încearcă să o facă
ghiciți că dacă un test este un test de remediere a erorilor sau un nou test de funcționalitate, pur și simplu necesită teste
eșuează față de linia de bază.

Această cerință se aplică atât noilor teste create printr-o modificare, cât și testelor
care au fost copiate într-o modificare pentru modificare.

revizuirea Teste
Evaluatorii pot avea încredere că Aegis a aplicat cerințele de testare; asta o schimbare
trebuie să aibă teste, că schimbarea trebuie să se construiască, că testele trec împotriva dezvoltării
director și că testele eșuează față de linia de bază. Aceste condiții sunt aplicate
by aede(1) iar modificarea nu va fi avansată la fiind revizuite stare până la acestea
sunt îndeplinite condițiile. Evaluatorii ar trebui astfel să revizuiască testele pentru deplinătate de acoperire a
codul din modificare și insensibilitatea la schimbările din mediul de execuție (de ex
nu este sensibil la dată). Evaluatorii ar trebui să folosească, de asemenea, „aegis -list change_details” pentru a verifica
că o modificare are sau nu exceptări de testare.

scutiri
Administratorii de proiect pot acorda diverse scutiri de testare, vezi aepa(1) și
aepatr(5) pentru mai multe informații. Copierea testelor într-o modificare sau adăugarea de noi teste la un
modificare, poate anula aceste scutiri.

TEST COMMAND CONFIGURARE

Comanda utilizată pentru a executa teste este definită de comandă_test domeniul din proiect
fișier de configurare (vezi aepconf(5) pentru mai multe informații), se folosește implicit
Shell Bourne dacă nu este setat. Directorul curent va fi în partea de sus a celui corespunzător
arbore de directoare. Dacă testele necesită fișiere temporare, ar trebui să le creeze în / tmp, ca
testul nu se poate aștepta să aibă permisiunea de scriere în directorul curent.

Dacă doriți să utilizați un motor de testare mai sofisticat, mai degrabă decât un simplu script shell,
dar acest motor de testare nu returnează coduri de rezultat potrivite pentru utilizare cu Aegis, ați putea
înfășurați-l într-un script shell care rescrie starea de ieșire în valorile așteptate de Aegis.
De asemenea, ați putea obține aceleași rezultate scriind o mai complexă comandă_test în
proiect config fișier.

De asemenea, este posibil să scrieți comenzi de testare care pot testa mai multe fișiere la
o singura data. Aceasta este controlată de batch_test_command domeniul proiectului config fişier. În
în acest caz, substituția ${output} indică numele unui fișier pe care trebuie să îl comandă de testare
crea, în aetest(5) format, care să conţină rezultatele testelor efectuate. Acesta este adesea folosit
pe sisteme cu mai multe procesoare sau cu capacitatea de a distribui joburi pe mai multe computere
pe o rețea.

substitutii
Toate aesub(5) substituțiile sunt disponibile în comenzile de testare. Unii dintre ei sunt
de remarcat deosebit:

Arhitectură
Această înlocuire este înlocuită cu numele arhitecturii de testat.

Căutare_Cale
Această înlocuire este înlocuită cu o listă de căi absolute separate prin puncte
căutați atunci când căutați fișiere de asistență de testare.

Căutare_Cale_Executable
Această înlocuire este înlocuită cu o listă de căi absolute separate prin puncte
căutați atunci când căutați fișiere de suport executabile (fișiere de bibliotecă și sub-
comenzi).

De cele mai multe ori $Search_Path_Executable sunt exact la fel. Cu toate acestea, în timpul „aegis -t
-bl” vor fi altfel, cu $Seach_Path începând cu directorul de dezvoltare (
testul în curs de desfășurare) și $Seach_Path_Executable începând de la linia de bază (executabilul fiind
alerga).

Test Rezultat Coduri
Pe măsură ce fiecare test este rulat (prin intermediul comandă_test domeniul din proiect config dosar), aegis
determină dacă testul a reușit sau a eșuat analizând starea de ieșire. Aceasta iesire
starea este în mare parte cea așteptată pentru comenzile UNIX.

Succes
Un test ar trebui să iasă din 0 pentru a indica succesul, adică funcția specifică testată
a funcționat conform așteptărilor.

Eșec
Un test ar trebui să iasă din 1 pentru a indica eșecul, adică funcția specifică testată
nu a funcționat așa cum era de așteptat.

Nici un rezultat
Un test ar trebui să iasă din 2 pentru a indica niciun rezultat, de exemplu că funcția specifică sub
testul nu a putut fi exercitat deoarece altceva a mers prost. De exemplu, alergarea
spațiu pe disc la crearea fișierelor de intrare de testare în fișierul / tmp director.

Sărit
Un test ar trebui să iasă din 77 pentru a indica că a fost omis. Acest lucru are de-a face de obicei cu
arhitectura actuală nefiind semnificativă. Ori de câte ori este posibil, utilizați „Fără rezultat”
in schimb. (Valoarea a fost aleasă pentru compatibilitatea cu alte sisteme de testare.)

De fapt, orice cod de ieșire, altul decât 0, 1 sau 77, va fi interpretat ca „fără rezultat”.
Cu toate acestea, folosirea întotdeauna a 0, 1, 2 sau 77 înseamnă că dacă un nou cod de rezultat este cerut de a
Lansarea ulterioară a Aegis, testele dvs. existente vor continua să funcționeze.

TEST CORELATII

Comanda „aegis -Test -SUGgest” poate fi folosită pentru ca aegis să sugereze o regresie adecvată
teste pentru modificarea dvs., pe baza fișierelor sursă din modificarea dvs. Aceasta automat
concentrează efortul de testare pe testele relevante, reducând numărul de teste de regresie
necesar să fii sigur că nu ai introdus un bug.

Corelațiile de testare sunt generate de comanda „aegis -Integrate_Pass”, care
asociază fiecare test din modificare cu fiecare fișier sursă din modificare. Astfel, fiecare
fișierul sursă acumulează o listă de teste care au fost asociate cu acesta în trecut.
Aceasta nu este la fel de exactă ca analiza acoperirii codului, dar este o aproximare rezonabilă în
practică.

aecp(1) și aenf(1) comenzile sunt folosite pentru a asocia fișiere cu o modificare. În timp ce ei
nu efectuați activ asocierea, acestea sunt fișierele folosite de aeipass(1) și
și(1) pentru a determina ce fișiere sursă sunt asociate cu ce teste.

Test Corelație Acuratete
Presupunând că corelațiile de testare sunt corecte și că testele sunt egale
distribuit în spațiul funcțional, va exista un mai puțin decât 1/număr sansa ca a
testul relevant nu a fost rulat de „aegis -Test -SUGgest număr” comanda. O mică
cantitatea de zgomot este adăugată la ponderarea testului, astfel încât să apară uneori lucruri neașteptate
testat, iar aceleași teste nu sunt executate de fiecare dată.

Precizia corelației testelor poate fi îmbunătățită asigurându-se că:

· Fiecare modificare ar trebui să fie puternic concentrată, fără includeri gratuite de fișiere. Acest
evită corelațiile false.

· Fiecare element de funcționalitate nouă ar trebui adăugat într-o modificare individuală, mai degrabă decât
mai multe împreună. Acest lucru corelează puternic testele cu funcționalitatea.

· Fiecare bug ar trebui remediat printr-o modificare individuală, mai degrabă decât mai multe împreună. Acest
corelează puternic testele cu funcționalitatea.

· Corelațiile de testare se vor pierde dacă fișierele sunt mutate. Acest lucru se datorează faptului că corelațiile sunt de
nume.

Cel mai bun mod pentru ca testele să se coreleze corect cu fișierele sursă este atunci când o schimbare
conține un test și exact acele fișiere referitoare la funcționalitatea testată. De asemenea
multe fișiere false vor slăbi utilitatea corelațiilor de testare.

OPŢIUNI

Se înțeleg următoarele opțiuni:

-Automat
Această opțiune poate fi utilizată pentru a specifica teste automate. Testele automate necesită nr
asistență umană.

-De bază
Această opțiune poate fi utilizată pentru a specifica faptul că linia de bază a proiectului face obiectul
comanda.

-BAse_RElative
Această opțiune poate fi folosită pentru a face ca numele de fișiere relative să fie considerate relativ la
baza arborelui sursă. Vedea aeuconf(5) pentru utilizatorul corespunzător
preferinţă.

-Current_RElative
Această opțiune poate fi folosită pentru a face ca numele de fișiere relative să fie considerate relativ la
directorul curent. Acesta este de obicei implicit. Vedea aeuconf(5) pentru
preferința corespunzătoare a utilizatorului.

-Schimbare număr
Această opțiune poate fi utilizată pentru a specifica o anumită modificare în cadrul unui proiect. Vedea
egidă(1) pentru o descriere completă a acestei opțiuni.

-Forta Această opțiune poate fi utilizată pentru a specifica că toate testele ar trebui să fie executate, chiar dacă
starea ultimei testări indică faptul că nu este nevoie să rulați un anumit
Test.

-Ajutor
Această opțiune poate fi folosită pentru a obține mai multe informații despre cum să utilizați egidă
programul.

-Independent
Această opțiune este utilizată pentru a specifica faptul că testul urmează să fie rulat independent de oricare
schimbare specială. Dacă nu sunt denumite teste, toate testele din linia de bază vor fi executate.

-Listă
Această opțiune poate fi folosită pentru a obține o listă de subiecte potrivite pentru această comandă.
Lista poate fi mai generală decât se aștepta.

-Manual Această opțiune poate fi utilizată pentru a specifica teste manuale. Testele manuale necesită ceva uman
intervenție, de exemplu: confirmarea unui comportament de ecran (X11, de exemplu) sau
unele acțiuni ale utilizatorului, „deconectați cablul ethernet acum”.

-Nu_Logging
Această opțiune poate fi utilizată pentru a dezactiva înregistrarea automată a rezultatelor și a erorilor
un fișier. Acest lucru este adesea util atunci când mai multe comenzi Aegis sunt combinate într-un shell
script-ul.

-Persevera
Această opțiune poate fi utilizată pentru a specifica că toate testele ar trebui să fie executate, chiar dacă unele
eșuează. Valori implicite ale utilizatorului persevere_preference dacă nu este specificat, vezi
aeuconf(5) pentru mai multe informații.

-Nu_PERsever
Această opțiune poate fi utilizată pentru a specifica că rularea de testare ar trebui să se oprească după prima
eșec. Valori implicite ale utilizatorului persevere_preference dacă nu este specificat, vezi
aeuconf(5) pentru mai multe informații.

-Proiect nume
Această opțiune poate fi utilizată pentru a selecta proiectul de interes. Când nu -Proiect
este specificată opțiunea AEGIS_PROJECT este consultată variabila de mediu. Dacă
care nu există, al utilizatorului $HOME/.aegisrc fișierul este examinat pentru o valoare implicită
domeniul proiectului (vezi aeuconf(5) pentru mai multe informații). Daca asta nu exista,
atunci când utilizatorul lucrează doar la modificări în cadrul unui singur proiect, proiectul
numele este implicit la acel proiect. Altfel, este o eroare.

- PROGRES
Această opțiune poate fi utilizată pentru a specifica faptul că mesajele de progres ar trebui să fie emise înainte
fiecare test de rulare sau înainte de fiecare test de lot, în caz că batch_test_command camp
specificate în proiect config dosar (vezi aeuconf(5) pentru mai multe informații).

-Nici un progres
Această opțiune poate fi utilizată pentru a specifica faptul că mesajele de progres trebuie suprimate.
Aceasta este valoarea implicită.

-Regresie
Această opțiune este utilizată pentru a specifica faptul că suita de teste de regresie urmează să fie rulată. The
Suita de teste de regresie constă din toate testele din linia de bază care nu apar
în schimbare. Este o eroare dacă nu există teste de regresie. Tu nu poți
teste de nume pe linia de comandă atunci când utilizați opțiunea -REGression. Puteți numi
teste individuale să fie rulate pe linia de comandă, fără a utiliza -REGression
opțiune; dacă nu fac parte din modificare, testele cu același nume în
linia de bază va fi rulată.

-Sugera [ număr ]
"egidă -Integrare_Pass” comanda colectează statistici de corelare a testelor când
modificările sunt integrate. Această opțiune poate fi utilizată pentru a solicita sugestia Aegis
ce teste ar trebui efectuate, folosind aceste corelații de testare. Dacă nu există un număr
specificate, vor fi sugerate 10 teste. Această opțiune implică -Regresie
opțiune.

-SUGgest_Limit minute
Această opțiune poate fi utilizată pentru a limita numărul de teste la un anumit număr de
minute. Acestea vor fi derulate de la cele mai relevante la cele mai puțin relevante.

-SUGgest_Noise număr
Această opțiune poate fi utilizată pentru a controla cantitatea de zgomot injectată în test
selecția efectuată de către -Sugera opțiune. Numărul este un procent de zgomot
a fi injectat. Valoarea implicită la 10 dacă nu este specificată. Injectia de zgomot asigura
că o varietate de teste sunt executate pe runde ulterioare și, de asemenea, unele din câmpul stâng
ca un control al minții.

-Concis
Această opțiune poate fi folosită pentru a determina ca listările să producă minimum
informație. Este de obicei util pentru scripturile shell.

- Verbos
Această opțiune poate fi folosită pentru a determina ca Aegis să producă mai multă ieșire. Implicit egida
produce numai rezultate pentru erori. Când este utilizat cu -Listă opțiunea acestei opțiuni
determină adăugarea titlurilor de coloană.

-Aștepta Această opțiune poate fi utilizată pentru a solicita comenzilor Aegis să aștepte blocarea accesului, dacă
nu pot fi obținute imediat. Valori implicite ale utilizatorului lock_wait_preference
dacă nu este specificat, vezi aeuconf(5) pentru mai multe informații.

-Nu așteptați
Această opțiune poate fi utilizată pentru a solicita comenzilor Aegis să emită o eroare fatală în cazul accesului
încuietori nu pot fi obținute imediat. Valori implicite ale utilizatorului
lock_wait_preference dacă nu este specificat, vezi aeuconf(5) pentru mai multe informații.

Vezi si egidă(1) pentru opțiunile comune tuturor comenzilor Aegis.

Toate opțiunile pot fi prescurtate; abrevierea este documentată ca litere mari,
toate literele mici și literele de subliniere (_) sunt opționale. Trebuie să utilizați consecutive
secvențe de litere opționale.

Toate opțiunile nu fac distincție între majuscule și minuscule, le puteți tasta cu litere mari sau mici sau a
combinația dintre ambele, cazul nu este important.

De exemplu: argumentele „-proiect, „-PROJ” și „-p” sunt toate interpretate ca însemnând
-Proiect opțiune. Argumentul „-prj” nu va fi înțeles, deoarece consecutiv
caracterele opționale nu au fost furnizate.

Opțiunile și alte argumente ale liniei de comandă pot fi amestecate în mod arbitrar pe linia de comandă,
după selectoarele de funcţii.

Numele lungi ale opțiunilor GNU sunt înțelese. Deoarece toate numele opțiunilor pentru egidă sunt lungi,
aceasta înseamnă ignorarea semnului „-” suplimentar. "--opțiune=valoare„Convenția este, de asemenea
înțeles.

RECOMANDAT ALIAS

Aliasul recomandat pentru această comandă este
csh% alias aet 'aegis -t \!* -v'
sh$ aet(){aegis -t „$@” -v}

ERORI

Este o eroare dacă modificarea nu se află într-unul dintre fiind dezvoltat or fiind integrate
state.
Este o eroare dacă modificarea nu este atribuită utilizatorului curent.
Este o eroare dacă nu aveți teste relevante și nicio scutire relevantă.

EXIT STAREA

egidă comanda va ieși cu starea 1 la orice eroare. The egidă comanda va numai
ieșiți cu starea 0 dacă nu există erori.

MEDIUL VARIABILE

Vedea egidă(1) pentru o listă de variabile de mediu care pot afecta această comandă. Vedea
aepconf(5) pentru fișierele de configurare a proiectului specific_proiectului câmp pentru modul de setare
variabile de mediu pentru toate comenzile executate de Aegis.

Utilizați aet online folosind serviciile onworks.net