ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 140
Numărul 139 Numărul 138 Numărul 137 Numărul 136 Numărul 135 Numărul 134 Numărul 133 Numărul 132 Numărul 131 Numărul 130 Numărul 129 Numărul 128 Numărul 127 Numărul 126 Numărul 125 Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
×
▼ LISTĂ EDIȚII ▼
Numărul 67
Abonament PDF

Testare automată fără programare

Robin Molnar
QA Consultant @ NTT DATA Romania



TESTARE


Poate că unii dintre voi vă întrebați de ce am ales acest titlu. Răspunsul scurt este că nu sunt prea mulți testeri care să-și dorească să învețe programare, deși aceștia ar prefera testarea automată în locul celei manuale. Dar am o veste bună! Cu toate că pare dificil la început, testarea automată fără programare este posibilă, iar acest lucru se poate realiza utilizând testarea bazată pe modele, în care testerul creează modele pentru controalele pe care dorește să le utilizeze. De exemplu, într-o aplicație web, un model pentru teste și un model pentru date. Prin urmare, ca expert în testarea bazată pe modele, la NTT Data Romania, doresc să vă împărtășesc din experiența mea.

În primul rând, trebuie precizat că nu putem vorbi despre testare automată care să nu utilizeze deloc programarea. Conform Tricentis, Tricentis Tosca este o platformă de testare continuă ce accelerează testarea pentru a ține pasul cu Agile și DevOps. Utilizând cele mai inovatoare tehnologii de testare funcțională, Tricentis Tosca sparge barierele uneltelor convenționale de testare software.

Mai concret, Tricentis Tosca este o aplicație ce permite scrierea de teste utilizând funcționalitate de tip drag-and-drop, ce stochează și gestionează datele de test, ce execută teste automate sau manuale și care generează rapoarte. În acest fel, se acoperă o mare varietate de sisteme ce pot fi testate: web, desktop, mobil, cu suport avansat pentru tehnologiile Java FX, SAP, .Net sau HTML. De asemenea, oferă posibilitatea testării bazate pe imagini (image-based testing), dar și suport pentru tehnologii non-UI (API). Desigur, Tricentis Tosca poate fi extins pentru a facilita și testarea sistemelor BI precum și load testing. Toate acestea sunt posibile după doar câteva săptămâni de training, spre deosebire de testarea automată tradițională ce utilizează OOP și programare, care necesită o perioadă de instruire de o mai lungă durată. Din toate aceste motive, Tricentis Tosca este o unealtă cu adevărat impresionantă.

Totuși, să nu ne lăsăm purtați de val și să vorbim despre aspectele evidente ale testării bazate pe modele: mai întâi trebuie create modele ale obiectelor ce vor fi folosite în test. De exemplu, să zicem că vrem să automatizăm o simplă căutare pe Google, din rațiuni SEO, de exemplu.

Acest lucru presupune că trebuie mai întâi să creăm un model al elementelor ce vor fi folosite. Acest lucru înseamnă scanarea paginii de start din Google pentru a identifica elementele pe care dorim să le folosim. De exemplu, caseta de căutare (search input box). Identificarea unui element web se face utilizând cunoștințe de HTML de bază, întrucât cunoștințe mai avansate de HTML sunt necesare doar dacă aplicațiile web sunt complexe sau problematice. Pe scurt, fiecare element cu care interacționăm se numește control, deci fiecare control HTML- dar nu numai - este modelat într-un control mapat pe Tosca.

Al doilea aspect evident al testării bazate pe modele este că testele consumă modelele obiectelor care determină acțiunea sau interacțiunea, implicația fiind că testele doar consumă modelele. Deci, până acum avem: elemente web mapate pe controale și incluse în module, precum și teste ce conțin controale abstractizate. Poate părea dificil la început, dar este logic să avem containere pentru modele, iar aceste containere se numesc module. De exemplu, un modul login conține numele de utilizator și parola drept câmpuri, împreună cu butonul de login și, poate, linkul pentru recuperarea parolei uitate. Acest construct are sens, în timp ce un construct unde fiecare controler are propriul modul nu are sens cu excepția situației în care vreți să aveți de-a face cu o complexitate zdrobitoare.

Mai mult, testele în sine sunt abstractizări ale unor colecții de module. Așadar, pentru a putea monitoriza unde se află fiecare element, trebuie să înțelegem cum utilizează Tricentis abstractizările:

  1. Controalele aplicației sunt mapate pe controalele Tosca, controalele aplicației sunt abstractizate în controalele Tosca.

  2. Controalele Tosca se află în colecții numite module, acest nivel de abstractizare permițând reutilizarea controalelor.

  3. Tiparele de teste (test templates) sunt abstractizări. Cum? Ce? Citiți mai departe.

Al treilea aspect evident al testării bazate pe modele este că datele pot fi - și de obicei chiar sunt

- modelate, implicația fiind că testele utilizează atât modele de obiecte, cât și modele de date, ceea ce are sens deoarece în testare avem aproape mereu obiecte ale aplicației și date de test. Este același lucru. Dar lucrurile merg mai departe de atât. Din moment ce utilizăm abstractizări pentru controale și pentru date, de ce să nu folosim și pentru teste, pentru a permite crearea de teste automate?

Implementarea este următoarea: crearea unui template/ tipar de test și furnizarea de date de test către acesta duce la instanțierea testului propriu-zis. Deci, template + fișa de date de test = instanțe de teste, deoarece un tipar/ template conține instanțe ale datelor conținute în fișa de test, ceea ce face ca numărul de teste să fie egal cu numărul de instanțe existente în foaia de date de test. Așadar, un test este creat din date de test, pe baza unui tipar/ template, în timp ce un tipar/ template de test este un model generic - o abstractizare - pentru teste.

Dar lucrurile sunt mai profunde decât ar părea la prima vedere, deoarece abstractizările ne permit realmente să scriem teste pentru multe tipuri de aplicații, nu doar web. În exemplul din video-ul de mai jos, vom crea infrastructura de test utilizând controale pe baza imaginilor, de exemplu pentru aplicații ce rulează pe VDI.

În concluzie, este fezabil să scriem teste automate fără utilizarea efectivă a unui limbaj de programare. Aceasta se aplică nu doar pentru aplicațiile web, ci și pentru aplicațiile mobile, API/ OSV și chiar aplicații desktop, păstrând totodată un mod de gândire mai puțin tehnic, dar introducând viteza testelor automate cu efort minim și nivel calitativ ridicat.

Evident, există și anumite trucuri pe care le-am folosi pentru a ne face testarea mai ușoară dar, sincer, ce poate fi mai frumos decât să faci testare automată fără programare?

NUMĂRUL 138 - Maps & AI

Sponsori

  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • Connatix
  • BoatyardX
  • .msg systems
  • Yardi
  • Colors in projects

INTERVIURI VIDEO

Robin Molnar a mai scris