Introducere
În multe proiecte cu care am lucrat, oamenii nu au personalizat TestRail pentru ei înșiși și s-au descurcat cu setările standard. Prin urmare, în acest articol voi încerca să descriu un exemplu de setări individuale care vă pot ajuta să vă îmbunătățiți eficiența muncii. De exemplu, să luăm un proiect de dezvoltare a aplicațiilor mobile.
O mică declinare a răspunderii. Acest articol nu conține o descriere a funcționalității de bază a TestRail (există multe ghiduri în acest sens) și expresii de vânzări care descriu plin de culoare de ce trebuie să alegeți acest anumit furnizor pentru a crea un depozit cu teste.
Plan de justificare (ce va fi implementat)
-
Cerințe generale
-
Absolut oricine ar trebui să poată trece cazul.
-
Cazurile ar trebui să rămână relevante cât mai mult timp posibil
-
Cazurile ar trebui să acopere funcționalitatea aplicației mobile cât mai detaliat posibil, în măsura în care acest lucru nu contrazice primele două puncte.
-
-
Împărțit în TestCase și TestScenario
-
Generare rapidă de TestRun de diferite tipuri
-
Fumuriu
-
Regres
-
Testarea impactului etc.
-
-
Optimizarea suportului de caz
-
Renunțarea la capturile de ecran codificate „moarte” și trecerea la „date mobile”
-
Cerinţe
Pentru a edita câmpuri, veți avea nevoie de acces de administrator
Selectarea unui tip de proiect
Există trei tipuri de proiecte din care puteți alege:
Vom selecta tipul implicit. Toate cazurile vor fi disponibile în el în același timp. Vom folosi filtrarea inteligentă și vom gestiona dinamic toate cazurile simultan.
Adăugarea de câmpuri pentru a vizualiza o listă de cazuri de testare
Să adăugăm un câmp pentru a afișa cazurile de testare prioritare:
Puteți adăuga și alte câmpuri.
Configurarea câmpurilor de caz de testare și a etichetelor
Deschideți meniul de setări:
Vom avea nevoie de următoarele câmpuri:
Câmp „Rezumat” (antetul cazului de testare)
Acest domeniu există deja, doar sistematizăm utilizarea lui. Vom împărți cazurile în TestCase și TestScenario. Pentru o mai bună lizibilitate a unei liste mari de cazuri, este mai bine să conveniți în prealabil asupra regulilor pentru scrierea unui rezumat.
TestScenario:
Exemplu: TestScenario - Scenariu de bază pentru utilizarea unei aplicații mobile
TestCase:
Exemplu: MainScreen - Secțiunea Autorizare - Introduceți autentificare
În total, vedem în rezumatul cazului înțelegerea clasică: „ce, unde, când”. De asemenea, separăm vizual scripturile de testare de nivel înalt și cazurile de testare de nivel scăzut în forma cea mai potrivită pentru automatizare.
Eticheta „StartScreen” (ecranul de la care începe TestScenario; de asemenea, multe cazuri de testare pot atinge ecranele adiacente)
Pentru ce ar putea fi nevoie: vom elimina din text textul cazurilor pași tipici care conduc utilizatorul la ecranul cazului de testare curent. (pași tipici pentru crearea unei situații de testare specifice) Toți pașii tipici pentru toate cazurile de testare vor fi scrise într-un singur fișier. Voi scrie despre el mai detaliat separat.
Creați un câmp nou:
Completați componentele noului câmp:
În acest caz, creăm un câmp selectat dintr-o listă de valori. Introduceți valorile acestui câmp:
Vă rugăm să rețineți că valorile id nu încep cu unul și nu sunt consecutive. De ce se face asta? Ideea este că, dacă avem cazuri de testare cu ID-ul introdus înregistrat,
iar după aceea va trebui să creăm un al treilea ecran între cele două existente,
atunci va trebui să rescriem id-ul și, deoarece etichetele cazurilor de text existente sunt deja atașate acestuia, acestea vor fi pur și simplu șterse. Va fi foarte neplăcut.
Etichetă „Ecran” (numele ecranului care afectează TestCase)
Ce ai putea avea nevoie: una dintre ancorele pentru testarea la impact. De exemplu, dezvoltatorii au creat o nouă caracteristică cool. Trebuie să-l testăm, dar pentru aceasta trebuie să înțelegem ce anume ar putea afecta această caracteristică. În mod implicit, putem pleca de la paradigma că diferite ecrane (Activități) ale unei aplicații au clase diferite și, prin urmare, constituie componente diferite ale aplicației. Desigur, în acest caz este necesară o abordare individuală.
Exemplu: home_screen, MapScreen, PayScreen etc.
Câmp „MovableData” (link la o bază de date proxy cu date de testare modificabile)
În continuare, vom încerca să rezolvăm problema menținerii relevanței datelor în cazurile de testare:
-
Link-uri către machete curente (aceasta este mult mai bună decât să faceți capturi de ecran moarte)
-
Pași tipici pentru a ajunge la ecran cu o situație de testare
-
interogări SQL
-
Legături către date externe și alte date
În loc să scriem date de testare în fiecare caz de testare, vom crea un fișier extern și vom conecta la acesta în toate cazurile de testare. La actualizarea acestor date, nu va trebui să parcurgem toate cazurile de testare și să le modificăm, dar va fi posibilă modificarea acestor date într-un singur loc. Dacă cineva nepregătit deschide un caz de testare, va vedea în corpul cazului de testare un link către un fișier și un indiciu că trebuie să meargă la el pentru date de testare.
Vom împacheta toate aceste date într-un singur fișier extern, care va fi disponibil pentru toată lumea din proiect. De exemplu, puteți utiliza Google Sheet sau Excel și puteți configura o căutare în fișier. De ce anumiți furnizori? Cert este că plecăm de la paradigma că orice persoană din echipă ar trebui să poată deschide și trece un caz de testare fără a fi nevoie să instaleze mai întâi vreun instrument.
Pentru Foița Google puteți folosi interogări SQL. Exemplu:
=query(DATA!A1:M1146;"
SELECT C,D
WHERE
C contains '"&SEARCH!A2&"'")Pentru Excel Puteți configura macrocomenzi de căutare instantanee convenabile. (filtrare) Exemplu .
De fapt, ideea nu este nouă și este descrisă în cartea primului tester „Testing dot com”. (autor Savin Roman) Doar integrăm metodele propuse de Roman Savin în TestRail. Pentru a face acest lucru, creați un câmp cu un link către fișierul creat:
completați valoarea implicită a linkului, astfel încât fiecare nou caz de testare să aibă deja un link:
Dacă locația fișierului extern se modifică (vă oferim pentru orice forță majoră), atunci puteți modifica convenabil unul sau mai multe câmpuri simultan în toate cazurile de testare:
Câmpul „Descriere” (descrierea sau ideea unui caz de testare, instrucțiuni standard)
De ce aveți nevoie: În acest câmp de text vom plasa o scurtă descriere a cazului de testare și instrucțiuni standard.
Exemplu: Toate datele de testare (aspecte curente, utilizarea instrumentelor și alte date) din acest caz de testare sunt indicate prin link-uri {...} și se află în fișierul MovableData. Link către MovableData în câmpul corespunzător din partea de sus.
Etichetă „Componentă” (componenta aplicației mobile)
Pentru ce ar putea fi nevoie: pentru testarea impactului. Dacă o aplicație mobilă poate fi împărțită în componente (care se afectează cât mai puțin una pe cealaltă), atunci modificările dintr-o componentă vor fi suficiente (cu unele riscuri) pentru a fi verificate în cadrul aceleiași componente și vor exista mai puține motive pentru a efectua regresii generale ale tuturor. Dacă există informații că o componentă poate afecta alta, atunci este compilată o matrice de testare a impactului.
Exemple de componente: GooglePay, Comandă, Utilizatori, Hartă, Autorizare etc.
Etichetă „TAG” (Alte etichete pentru filtrare)
Etichetarea unui caz de testare cu etichete pentru filtrare arbitrară.
Foarte util pentru:
-
compilarea rapidă a TestRun pentru diferite sarcini tipice: fum, regresie etc.
-
testele vor fi automatizate sau deja automatizate?
-
orice alte etichete
Exemplu: Smoke, Automated, WhiteLabel, ForDelete etc.
Configurarea ordinii de afișare a câmpurilor în cazul de testare
Am creat o mulțime de câmpuri noi, este timpul să le aranjam într-o ordine convenabilă:
Se creează TestRun
Acum vom crea un nou test cu cazurile actuale pentru efectuarea testelor de fum în trei clicuri:
Alte sfaturi utile
-
Dacă TestRail are mai multe proiecte, atunci nu uitați să creați noi câmpuri doar pentru proiectul dvs., altfel colegii din echipele vecine vor fi foarte surprinși de apariția unor noi câmpuri neobișnuite. Este posibil leșinul local.
2. Cazurile cu un număr mare de câmpuri sunt mai ușor de copiat dintr-un tip de grup similar decât de a crea altele noi:
3. Conturile pot fi partajate. De exemplu: un administrator, mai mulți utilizatori.
Concluzie
Exemplele descrise mai sus au fost implementate pe mai multe proiecte și și-au arătat eficacitatea. Sper că vă vor ajuta la îmbunătățirea înțelegerii acestui instrument și vă vor ajuta să creați „stocare de testare” eficiente și convenabile. Aș fi foarte recunoscător dacă ați descrie experiența dvs. de utilizare a TestRail și sfaturi utile în comentarii.
referințe:
Carte:
Mulțumesc foarte mult pentru atenție!
Sursa: www.habr.com