crearea de recomandare de script-uri automate de testare

Pentru a simplifica întreținerea și reutilizarea codului de testare a acestora ar trebui să le fie structurate de la început. Cel mai probabil veți găsi o parte comună a codului în mai multe (dacă nu toate) scenarii. Aceste părți trebuie să fie identificate și pentru a partaja.

De exemplu, vă poate însoți scenarii de testare care testează performanța diferitelor secvențe de acțiuni în legătură cu înregistrările. Această combinație poate fi adăugarea, modificarea și ștergerea înregistrărilor:

• Adăugați, modificați, ștergeți (combinația cea mai evidentă)
• Adăugați, ștergeți, modificați,
• Adăugarea, ștergerea, adăugarea, ștergerea.
• Adăugarea, adaugand, adaugand.

Identificarea și punerea în aplicare a acestor acțiuni în formă de cazuri de testare individuale, care se va ocupa de restul, va crește nivelul de reutilizare a codului.

Pentru a simplifica întreținerea de script-uri de testare, încercați să le facă mai puțin vulnerabile la „îmbunătățirea“ modificările în software-ul țintă. De exemplu, în cazul în care script-ul completează în caseta de dialog, apoi mutați între câmpurile, utilizați una dintre următoarele moduri:

• Utilizarea tastei TAB
• Cu ajutorul mouse-ului
• Utilizarea tastelor de comenzi rapide

Fiecare dintre aceste opțiuni este diferită de rezistență la schimbare. De exemplu, după introducerea unui nou câmp între celelalte două opri varianta de lucru cu TAB. După remapare comenzile rapide nu mai funcționează treia opțiune. În cazul în care metoda de determinare a câmpului indicat de mouse-ul, se va schimba, atunci a doua metodă nu este adecvată. Unele instrumente de automatizare de testare vă permit să identificați câmpul metode mai fiabile, de exemplu, de numele obiectului care este atribuit dezvoltarea de instrumente (PowerBuilder, SQLWindows sau Visual Basic). În acest caz, script-urile de test vor continua să ruleze după efectuarea mici modificări la software-ul de testare (cum ar fi: schimbarea poziției, etichete text, decorare, etc.)

În multe teste, pentru a verifica comportarea în diferite condiții, condițiile corespunzătoare acestor date sunt introduse în câmpurile de pe ecran. Procedura de introducere a datelor - este aceeași, numai modificările de date. Prin urmare, în loc de înregistrări de testare individuale pentru fiecare set de date, putem scrie un test, și apoi copiați-l, schimba doar datele introduse. De exemplu, un test „de referință“ poate fi utilizat pentru toate seturile de date, ceea ce duce la aceeași eroare (date invalide). Script-ul poate fi modificat, astfel încât datele de intrare au fost preluate dintr-un fișier sau o altă sursă externă, și apoi executați un script într-un ciclu pentru fiecare set de date.

Dacă alegeți această abordare, trebuie să cadă de acord asupra formatului datelor de intrare. De obicei, fiecare set se înregistrează ca valori de câmp string separate prin virgulă. Acest format este ușor de interpretat un scenariu și însoțit de oameni.

script-uri de testare sunt executate secvențial. Ramificarea nu este acceptat în mod explicit. Pentru erori evidente de manipulare într-un script necesită o logică suplimentară. De exemplu:

• Trecerea la alte scenarii.
• Apel script-ul, eliminând consecințele posibile ale greșelilor.
• Ieșirea script-ul și a alerga următorul.
• Ieșirea din script-ul, reporniți software-ul de testat și să continue să plaseze ultima eroare.

Pentru fiecare dintre opțiunile pe care doriți să adăugați logica corespunzătoare în script. Dacă este posibil, această logică ar trebui să fie integrate în script-uri de nivel superior, care gestionează scenarii de nivel scăzut. Din cauza acestei nu mai este nevoie de editare manuală a script-uri de nivel scăzut după înregistrarea acestora.

Pentru a testa reziliența necesare script de sincronizare, le lansa în ora exactă. În acest scop, timpul necesar este comparat cu sistemul. În sistemele distribuite, trebuie mai întâi, prin intermediul rețelei, sincroniza ceasul de fiecare stație de testare. Următorul exemplu (din script-ul BASIC) executarea script este amânată până în momentul prestabilit.

Fișierintrare $ = "TIME.DAT"
Deschideți fișierintrare $ pentru intrare Ca 1
Intrare # 1, StartTime $
Închide # 1
Face în timp ce TIMEVALUE (StartTime $)> Timp
DoEvents
buclă
[Script Executare]

În acest exemplu, timpul de pornire specificat în fișierul. Acest lucru vă permite să modificați timpul, fără necesitatea de a înțelege scenariul. Timpul este salvat în variabila StartTime $. În timp ce bucla Do este executat până la ora prestabilită. Din cauza timpului DoEvents operatorului CPU pot fi cheltuite pe sarcini de fundal. Fără acest sistem operatorul nu ar răspunde la datele introduse de utilizator înainte de ora de începere.

Când efectuați scenarii de testare pe același software pe care au fost înregistrate, nu ar trebui să apară eroarea (în script-urile în sine). Mass-media și software-ul sunt aceleași ca și în timpul înregistrării. Cu toate acestea, atunci când modificați testul poate fi rulat în mod corespunzător. Pentru a identifica aceste probleme potențiale înainte de a utiliza pentru adevăratul test script-uri au nevoie pentru a se testa. În plus, sunt luate în considerare două tipuri de probleme:

• Ambiguitatea de moduri de a selecta elemente de interfață. De exemplu, în cazul în care elementele se disting prin textul lor nu a exclus situația în care acestea vor fi unul și același text. Acest lucru va duce la ambiguitate la executarea script-ul.
• Înregistrate date interne dinamice, cum ar fi indicii, ora curentă, precum și alte date generate de sistem nou de fiecare dată când programul este rulat.

Diferența de timp de înregistrare și redare poate provoca o defecțiune. Scrierea script-ul este mai lent decât să fie difuzate. Uneori, acest lucru poate duce la faptul că software-ul pur și simplu nu va avea timp pentru a efectua comenzile script. Pentru a evita acest lucru, aveți posibilitatea să inserați în operatorilor așteptări script.