Odt și kdt într-un mit sau realitate de testare completă

În instrumentul TestComplete pentru o lungă perioadă de timp (de la vechile versiuni) există module, poziționate ca ODT (Object-driven testing) și KDT (testul bazat pe cuvinte cheie). Sunt aceste module convenabile pentru implementarea acestor abordări sau este doar un nume frumos? Despre acest lucru și discutați în această notă.

Tot ce este scris mai jos este pur și simplu opinia mea, bazată pe experiența de 5 ani a automatizării pe TestComplete, începând de la versiunea 6.0 și terminând cu ultima (în acest moment 9.10).

Câteva cuvinte despre TestComplete

TestComplete este un instrument excelent. În automatizarea aplicațiilor desktop, nu există încă niciun fel, dacă luați în considerare prețul, pragul de intrare, confortul și funcționalitatea. În cele mai recente versiuni (începând de la 8.0), abilitatea de a automatiza aplicațiile web a fost, de asemenea, îmbunătățită semnificativ. Este posibil ca, în curând, TestComplete să devină un concurent pentru WebDriver (în tot ceea ce nu are prețul).

De asemenea, un instrument foarte mare plus este suportul pentru tehnologii precum Flash, Flex, AJAX, Silverlight. Ei bine, un alt (care, cu toate acestea, este în alte instrumente).

Spre deosebire de același QTP (competitor), TestComplete, de exemplu, face posibilă alegerea unui limbaj de scripting: C ++, C #, DelphiScript, VBS, JScript. Nu totul merită să fie folosit (voi scrie o notă separată despre acest lucru), dar există o alegere - aceasta în sine este deja un plus.

Există, de asemenea, un proces complet de 30 de zile în versiunea Enterprise, care este foarte convenabil și bun.

Module de testComplete

În cadrul modulelor, înțeleg acele lucruri pe care le puteți adăuga la proiect în TestComplete. Aceste module sunt în sens "larg" al cuvântului.

Pentru a construi un costum de testare și a crea un cadru, trebuie să decideți asupra modulelor care vor fi utilizate și să înțelegeți exact cum vrem să le folosim. Modificarea selecției în modulele cheie fără refactorizări semnificative este imposibilă, deci acesta este un punct destul de subtil și important.

Dacă descrieți fiecare modul separat (dacă aveți răbdare), atunci puteți publica o carte mică. Voi descrie părerea mea cu privire la două module: ODT și KDT, care sunt adesea folosite și în utilizarea cărora am văzut multe erori în practică.

Suficient de introducere, să mergem

Este vorba de testare bazată pe obiecte. Destul de ciudat. Nicăieri, cu excepția TestComplete, eu folosesc acest termen nu am văzut. Acolo OOP, DSL, PageObject ... Googling «ODT» - va fi surprins, cred că ... ODT în TestComplete în cererea sa clasică - un depozit de obiecte - clase și date. Este convenabil sau nu - despre acest lucru de mai jos. Doar o notă rapidă: dacă utilizați ODT termenul în comunicare, amintiți-vă - este cunoscut doar celor care sunt familiarizați cu TestComplete.

Aici puteți crea cursuri. De ce? Cred că ideea principală era de a compensa "sărăcia" limbilor de scripting pentru PLO. În clase, puteți crea clase și moșteni unele clase de la alții. Metodele acestor clase pot fi introduse în scripturi, care leagă funcția dorită ca metodă de clasă. Puteți face acest lucru fie manual (dar noi suntem automatizați - nu este interesant și ineficient), și din scenarii (acest lucru este mai interesant).

Ce crează clase în ODT.Classes?

Abilitatea de a vedea metode și proprietăți disponibile ale obiectelor după "punct" în procesul de scriere a codului
Abilitatea de a descrie manual unele forme și obiecte în formă de clase
Posibilitatea de moștenire
Abilitatea de a crea structuri de date de testare de același tip ca și clasa

Acesta din urmă este destul de convenabil (dar despre acest lucru mai jos, în Data). Restul este un avantaj destul de controversat, având în vedere dezavantajele utilizării claselor:

Pentru a crea automat clase în ODT.Classes din scripturi, trebuie să descrieți constructorii cu toate metodele și să îi numiți pe acești constructori. Avem nevoie de un alt "colector" al tuturor acestor designeri. De asemenea, numele de metode sunt transmise ca șiruri de caractere (vedeți codul și descrierea de mai jos). Dacă o anumită metodă a fost redenumită în cod și ați uitat să redenumiți constructorul, puteți observa foarte curând ...
Extinderea listei pop-up a metodei și a proprietăților disponibile după "punct" este destul de lentă. Veți observa acest lucru numai pe un proiect mare, când costumul de testare crește destul de puternic. De fapt, când este deja costisitor să o schimbi

De exemplu, pentru a crea metoda AddUser și proprietatea UsersCount din clasa Users, ați scrie acest cod:

După cum puteți vedea, metoda name = UsersForm.AddUser și acesta este șirul (numele fișierului unde este stocată această metodă + numele metodei).

În practică am încercat să folosesc aceste clase din ODT. Dar, în cele din urmă au existat mai multe dezavantaje decât avantaje, și am trecut de a utiliza cursuri de limba JScript. Da, nu există nici o moștenire, dar fără ea poate construi un cadru bun (cu atât mai mult în ODT.Classes încă nici încapsulare, polimorfism, și altele asemenea, și nu există decât moștenirea și a lui terci numai sensibil gatiti greu)

Creați o clasă (poate fi goală)

Se scrie codul pentru adăugarea obiectelor necesare (cu type = această clasă) și a proprietăților necesare

Dimensiunea ODT.Data, după cum a arătat practica, nu afectează viteza de lansare și confortul (frânele, ca și în cazul utilizării claselor, nu au observat).

Concluzie privind ODT: este posibil să se folosească, dar nu tot și nu întotdeauna. Un caz de utilizare bun (unul dintre cele posibile): ODT.Data pentru stocarea datelor de testare și ODT.Classes pentru șabloanele de obiecte.

Teste de cuvinte cheie

KDT (testul bazat pe cuvinte cheie) în clasic este o abordare destul de clară care determină cum și unde trebuie să fie proiectate testele și cum trebuie să se raporteze cadrul în sine la aceste teste.

Dezvoltatorii de testareComplete termenul "Testarea cuvintelor cheie" destul de bine evitat de la clasic: nu este vorba despre testarea bazată pe cuvinte cheie, ci de testarea cuvintelor cheie. Și la urma urmei funcționează - mulți încep să fie confuzi ...

Voi descrie ce este în TestComplete și ce ar trebui să fie în abordarea normală a KDT. Și apoi decideți dacă să utilizați acest modul sau nu

Ce este modulul Testarea cuvintelor cheie în TestComplete:

Un mediu vizual care vă permite să creați un test cu un mouse, fără a scrie cod
Set de puncte de control pentru diverse tipuri de verificări (câmpuri, tabele, imagini, servicii etc.).
Ferestre interactive în timpul înregistrării unui test sau adăugarea unui punct de control
Vizualizer, care permite să adăugați o verificare în locul potrivit la testul existent (păstrează toate ferestrele, care au fost utilizate pentru înregistrarea de test și apoi vă permite să „retroactiv“, selectați kontol și adăugați-l verificat, de exemplu)

Puteți efectua apeluri la alte teste de cuvinte cheie, deja pregătite, precum și la rutine de script. În principiu, acest modul nu are nicio limitare a funcționalității. Dar există o trăsătură: nu este o testare bazată pe cuvinte cheie, ci doar o vizualizare și o salvare a vieții în stadiile incipiente ale automatizării învățării.

Care este abordarea KDT (testul bazat pe cuvinte cheie)?

Abilitatea de a scrie teste în afara mediului de dezvoltare (testele de cuvinte cheie sunt adesea scrise de biznani-analiști sau oameni de la client care cunosc perfect domeniul, dar nu înțeleg automatizarea)
Un dicționar de cuvinte cheie care este folosit pentru a compila testele
Cadru care pune în aplicare utilizarea de cuvinte cheie (cadrul nu este de multe ori vizibile pentru cei de teste ale cuvintelor cheie nu este necesar :. Această separare se face intenționat, echipa de dezvoltare cadru separat de un grup de persoane care vor constitui teste)

Ce este asta în TestComplete? Nu face nimic. Este imposibil să scrieți teste în afara TestComplete; dicționarul este acolo, dar foarte limitat (puncte de control), toate celelalte cuvinte cheie trebuie să fie descrise (ceea ce este logic, în principiu); Cadrul trebuie, de asemenea, să fie dezvoltat independent.

TestComplete oferă o oportunitate de a simplifica crearea unui cadru sau a unor șabloane pentru compilarea unui KDT cu drepturi depline? - Nu.

Concluzie: puteți implementa abordarea KDT în TestComplete. Dar ceea ce se întâmplă la ieșire nu va avea nimic de a face cu modulul de testare a cuvintelor cheie

Răspundeți la o întrebare din titlu

ODT și KDT în TestComplete: mit sau realitate?

ODT: mit 50%, realitate de 50%. Mit în termeni de ODT.Classes, care în practică este destul de incomod și nu dau nici un avantaj semnificativ (comparativ cu clasele în limbi, de exemplu, JScript). În ODT.Data, puteți implementa moștenirea, dar utilitatea sa este iluzorie, având în vedere deficiențele descrise mai sus. ODT.Data poate și ar trebui să fie utilizat - un depozit convenabil de date de testare. În legătură cu clasele-șabloane vă permite să creați o structură complexă de date de testare, care este convenabilă pentru automatizare.

KDT: Mit. Există un modul de testare a cuvintelor cheie, care nu are nimic de-a face cu abordarea bazată pe cuvinte cheie. KDT-ul clasic poate fi implementat, dar pentru asta trebuie să scrieți codul și să proiectați cadrul. Cu toate acestea, orice automatizare serioasă implică un cadru, deci nu ar trebui să fie intimidant.

Cum să implementăm abordările ODT și KDT în practică?

În timpul instruirii, „Abordări la dezvoltarea unui cadru de test (TestComplete)» analizăm cu atenție fiecare abordare: bazată pe obiect de testare (ODT), bazate pe date de testare (DDT), testarea cu ajutorul cuvintelor cheie (KDT), să învețe cum să le pună în aplicare de la zero și să înțeleagă , care sunt mai bune pentru rezolvarea diferitelor probleme practice.

Articole similare

Pagina anterioară

Pagina următoare