Система управления производством
Система управления производством
Sistem de management al producției
Sistem de management al producției

Cine suntem noi?

Așa cum puteți ghici cu ușurință după titlul de intrare, am fost ucenici în Syneo și sarcinile noastre au inclus scrierea testelor automate pentru aplicația web. În fiecare zi studiem la Universitatea de Tehnologie și Științe ale Vieții din Bydgoszcz, în domeniul IT aplicat.

Ce am folosit pentru a crea teste?

  • Limbă: C #,
  • IDE: Visual Studio 2015,
  • Testarea de rame: NUnit 3.4.1,
  • Instrumentul pentru servicii de browser: Selenium Web Driver,
  • Browser: Mozilla Firefox (fostă Google Chrome),
  • Sistem de control al versiunii: Git + Visual Studio Team Services

Despre ce vom scrie despre asta?

Ne-ar plăcea să prezentăm câteva din informațiile despre testarea automată din punctul de vedere al unui programator novice și să descriem avantajele și dezavantajele instrumentelor pe care le-am folosit pentru a le scrie. De asemenea, vom încerca să determinăm dacă testele automate aduc o mare valoare proiectului pentru care sunt scrise. Vă invităm să citiți.

Câteva sfaturi pentru începători

Testele automate au fost o noutate completă pentru noi, învățam regulat în timp ce scriem. Desigur, în timpul acestui proces am întâlnit câteva probleme, a căror soluționare nu era adesea atât de evidentă. De aceea, am dori să prezentăm câteva sfaturi pentru persoanele care nu au mai întâlnit niciodată acest subiect.

  1. 1. Verificați aplicația

Poate că aceasta este o declarație trivială și pentru mulți va părea evidentă, dar înainte de a începe să scrieți teste, merită să vă petreceți câteva ore pentru a vă familiariza cu cererea. Testați-l manual. Cunoscând mecanismele prin care se ghidează programul testat, vom accelera semnificativ și vom facilita procesul de scriere a testelor automate.

2. Curăță-te după tine

Imaginați-vă un scenariu de test exemplu:

  • logging-ul catre administrator,
  • crearea unui nou utilizator,
  • testarea ediției sale.

Ce lipsește aici?

Acum, să facem acest test de 150 de ori.

Da, testerii trebuie să (!) Curățesc după ei înșiși. Exemplul utilizatorului este destul de nevinovat, dar de multe ori în aplicație avem posibilitatea de a adăuga imagini sau videoclipuri. Am ajuns personal la punctul critic în care serverul a avut aproape câteva duzini de efecte GB ale testelor noastre.

3. Creați teste care „gândesc”

Presupunând în prealabil că anumite elemente din aplicație vor exista atunci când sunt executate testele este o soluție bună. Dar numai la început, când suntem mai interesați să testam o anumită funcție decât pe inteligența scenariilor noastre. Cu toate acestea, ar trebui să o lăsăm în această formă?

Să presupunem că este necesar contul utilizatorului de testare. În cazul în care se va termina ca rezultat, vom reveni la eșecul testelor în care se conectează la acest cont. Singurul lucru pe care îl putem face este să întrebați dacă este vina de a nu avea un cont sau poate să apară o eroare în aplicație. Răspunsul corect va apărea numai după înregistrarea utilizatorului și pornirea din nou a testelor. Unde e problema?

Trebuie să ne ocupăm de aplicație și să creăm manual un cont de utilizator și să rulați din nou scripturile de testare. La urma urmei, acestea sunt teste automate, ar trebui să facă asta pentru noi. De fapt, ei sunt creați pentru asta. Este în interesul nostru să construim teste care să poată reacționa la astfel de situații.

În cererea noastră, au fost îndeplinite două criterii pentru ca utilizatorul să fie conectat corect: a trebuit să se creeze un buget adecvat și să existe un cont pentru care vrem să ne logăm. Un exemplu de metodă auxiliară care a răspuns la lipsa unui buget corespunzător și lipsa unui utilizator de test poate fi văzută în imaginea de mai jos.

 

blog1

 

 

 

 

 

 

 

 

 

 

 

 

 

4. Mutați cursorul

În timpul colaborării cu Selenium, am întâmpinat o problemă care a durat mult timp pentru a rezolva problema. Anume, la unul dintre teste, acest instrument nu a făcut clic întotdeauna în locul în care am arătat. Codul în sine a fost verificat de o duzină de ori pentru a-l reprograma, ca să nu mai vorbim.

Sa dovedit că cursorul mouse-ului este vinovatul. Când sa aflat în interiorul ferestrei browserului, a întrerupt testarea. Seleniul se comportă ca noi înainte de a acționa asupra unui element. Acesta găsește un element, la fel cum un om o „invadează” cu un șoarece, care poate fi observat prin schimbarea stilului unui buton, de exemplu. Prin urmare, atunci când cursorul nostru era în fereastra browserului, Selenium nu a putut face clic pe acest element.

Pentru a rezolva această problemă, trebuia să folosim clasa Cursor din spațiul System.Windows.Forms și tocmai cu fiecare lansare a browserului, cursorul mouse-ului a fost mutat în partea superioară a ecranului, unde nimeni nu putea să-l vină.

Puteți vedea un exemplu de cod care mișcă cursorul mouse-ului în imaginea de mai jos.

blog2

 

 

 

 

 

 

5. Nu trebuie întotdeauna să descărcați fișiere

În multe aplicații este posibilă descărcarea fișierelor pe disc. Ele pot fi imagini, filme, muzică și altele asemenea. Cu toate acestea, dacă scrieți teste care verifică posibilitatea descărcării unui fișier dat, trebuie să îl descărcați de pe disc de fiecare dată?

Depinde dacă vrem să facem acțiuni asupra acesteia odată ce este pe calculatorul nostru. Dacă o vom face atunci, trebuie să o descărcăm în mod necesar. În cazul în care dorim doar să testați posibilitatea descărcării unui fișier, o putem face fără descărcarea fizică a fișierului pe disc.

Pentru a face acest lucru, căutați site-ul pentru linkul către fișierul pe care doriți să îl descărcați, apoi trimiteți o interogare HTTP la acesta și citiți codul pe care îl vom primi ca răspuns. Dacă este 200 (OK), înseamnă că fișierul poate fi descărcat. Din păcate, dacă aveți nevoie de o sesiune activă de utilizator pentru a descărca fișierul, trebuie să desenați o sesiune „cookie” sau „token” și să efectuați o interogare HTTP cu ea.

Examinați codul de verificare dacă fișierele pot fi descărcate în lista de mai jos.

blog3

 

 

 

 

 

 

 

 

 

Introducerea … Modelul de Obiect

Testele sunt ele însele o aplicație. Un cod care este aparent independent de programul care este testat. Se pare că orice modificare a aplicației testate trebuie inclusă și în teste. Cum arata? Să ne uităm la o bucată de cod.

blog4

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Dar unde sunt testele din acest cod? La urma urmei, puteți vedea dintr-o privire că această clasă este utilizată numai pentru a găsi elemente pe pagină și oferă o metodă de conectare la contul administratorului.

Aceasta este ceea ce este menționat în titlul paginii Obiect Object. Acesta este un model care vă permite să separați codul responsabil pentru căutarea elementelor HTML pe pagină și interacționarea cu acestea, din codul al cărui scop este de a testa aplicația. Să examinăm acum codul de testare care utilizează clasa AdminLoginPage.

 

blog5

 

 

 

 

 

 

 

Nu puteți să nu fiți de acord cu faptul că acest model vă permite să creați teste cu adevărat lizibile. Care sunt avantajele sale?

La începutul capitolului, am menționat că fiecare schimbare a aplicației trebuie reflectată în teste. Imaginați-vă acum că nu folosim modelul Obiect..

  • În fiecare test care utilizează un anumit element, trebuie să îl căutăm pe pagină.
  • Elementele pot fi de până la o duzină pe fiecare pagină.
  • Să spunem că dezvoltatorul care a dezvoltat aplicația a schimbat clasa sau ID-ul mai multor elemente.

În câte locuri trebuie să facem schimbări în teste? Probabil în multe. Cu toate acestea, punerea în aplicare prezentat de modelul nostru, vom căuta fiecare element doar o singură dată, astfel încât orice schimbare de acest tip este, de asemenea, aplicată într-un singur loc. Nu este nevoie să spunem ce conveniență este o actualizare de cod convenabilă.

În proiecte mai complexe, cum ar fi cel în care am reușit să lucrăm, nu ne putem imagina că lucrăm fără un model descris. A fost foarte ușor pentru noi să introducem soluții la testele care au încetat să funcționeze datorită modificărilor din aplicație. Codul creat cu acesta a devenit mult mai clar. Cu toate acestea, cu proiecte mai mici, trebuie să vă gândiți dacă merită să investești timp suplimentar dedicat implementării sale.

Firefox vs Chrome

La începutul postului, am menționat că am folosit ambele browsere listate în titlu. În cele din urmă trebuia să folosim Firefox, dar dacă decizia ne aparținea, am rămâne cu Chromie.

Mozilla este mai lentă. Când am lansat testele noastre folosind browser-ul Google, timpul în care au fost efectuate a fost de aproximativ 11-13 minute. După schimbarea browserului, aproximativ 20-23 de minute. Așa că sa dublat.

În momentul testării, puteți bloca ochiul dacă browserul ar fi mai prietenos cu testerul. Din păcate, nu este. Chrome de fiecare dată a așteptat ca pagina să se încarce complet și numai atunci au făcut acțiuni. Din păcate, acest lucru nu se poate spune despre Mozilla. Acest lucru a dus la faptul că a trebuit să adăugăm WebDriverWait la scenariile de testare după reîncărcarea fiecărei pagini. Deci, pur și simplu forțați browser-ul să aștepte ca pagina să se încarce complet. Fără această acțiunile incluse în test au fost efectuate pe un elemente încă inexistente, ceea ce a dus la eșecul de jumătate din testele pe care Chromie au trecut fără obiecții.

Acțiunea „drag and drop” este una dintre caracteristicile oferite de Selenium. Am folosit-o în mai multe teste în browserul Google și a funcționat bine. După transferul la Firefox, aceste teste au încetat brusc să funcționeze. Sa dovedit că singura modalitate de a testa această funcție în cadrul Mozilla este de a folosi JavaScript.

Singurul lucru care a apelat în favoarea browser-ului Mozilla este WebDriver încorporat, care a fost actualizat cu browser-ul. Acest lucru vă permite să evitați problemele (care nu se pot întâmpla niciodată) legate de faptul că vom folosi WebDriver mai vechi pe un browser mai nou.

Doar să fie conștienți de faptul că browserele și sprijinul lor pentru Seleniul se schimbă destul de rapid, iar atunci când citiți acest text poate fi faptul că cel mai bun Seleniul este sprijinit sub un browser complet diferit. Cu toate acestea, în acest moment, acesta este Chrome.

Merită să scrieți teste automate?

Aceasta este o întrebare foarte dificilă, care, din păcate, nu are un răspuns simplu și lipsit de ambiguitate. Se spune frecvent: „Depinde.”

Din perspectiva noastră, ca ucenici, merită. Scrierea testelor este o experiență interesantă care dezvoltă cu siguranță abilități de programare și vă permite să lucrați la un proiect real. În același timp, vom lucra cu alte persoane responsabile pentru aplicații, dar pe de altă parte, lipsa noastră de cunoștințe și competențe nu reflectă asupra proiectului la fel de mult ca și la locul de muncă cu codul sursă al programului propriu-zis.

Cu toate acestea, testele automate au dezavantajele lor. În primul rând, trebuie să le creați pentru a se referi oameni, care ar putea, la timpul necesar pentru dezvoltarea sau crearea unui produs pentru un client (cu excepția cazului vă puteți permite pentru o persoană care să se ocupe numai testele). Cu toate acestea, acest lucru nu este sfârșitul. Odată ce testele scrise, din păcate, nu vă puteți lăsa după ce le-ați creat. Trebuie să continuați să le sprijiniți pe măsură ce se dezvoltă aplicația. Prin urmare, avem două produse dezvoltate simultan.

Știm deja că testele trebuie să fie îmbunătățite în mod constant odată cu dezvoltarea aplicației, care uneori poate consuma timp și bani suplimentari. Ar fi însă nedrept să o încheiem.

Valoarea procesului de creare a testului în sine ar trebui să fie luată în considerare. În practica noastră, dezvoltatorul responsabil pentru dezvoltarea unei aplicații adecvate, ne-am așezat „spate în spate“, astfel încât, la momentul de proiectare scenariu de testare am reușit să-l informeze cu privire la orice erori de pe site.

În total, toate testele neplătite am scris aproximativ 90. Fiecare verifică o altă funcționalitate a site-ului. Cât timp a luat testele potrivite?

blog6

 

 

 

 

 

 

 

A durat un total de aproximativ 21 de minute. Cu viteza computerului, care nu trebuie să caute elementul ochi pe o pagină, sau mutați cursorul mouse-ului pentru ao click. De asemenea, el nu trebuie să fie atent să nu introducă date incorecte, pentru că noi, ca dezvoltatori de test, am anticipat o astfel de eventualitate.

Imaginați-vă cât de mult ar lua unul sau chiar doi oameni. De asemenea, trebuie adăugat că testele au fost completate de noi în aproximativ 2,5 săptămâni. Prin urmare, este sigur să presupunem că este o modalitate rapidă și precisă de verificare a corectitudinii produsului.

Ce s-ar schimba scriind teste pentru a doua oară?

Privind din perspectiva timpului (după ce scriem peste o lună după ce am creat teste), ne-am schimba foarte puțin. Credem că codul pe care îl scriem este lizibil și nu ar trebui să existe probleme cu întreținerea acestuia. Desigur, în timp ce testele sunt actualizate în mod regulat, împreună cu noutățile introduse în cerere. În caz contrar, chiar și codul cel mai bine scris va fi dificil de înțeles.

Schimbările care ar putea introduce în acest moment sunt mai degrabă orientate spre proiect mai larg de a organiza și să se alăture metode de extensie care permit mai natural pentru a verifica rezultatele testelor.

Pentru a realiza prima dintre ipotezele de mai sus, divizia ar introduce teste de bază care testează numai reacțiile generale ale paginii. De exemplu, dacă linkul redirecționează spre locul potrivit sau dacă trimiterea unui formular duce la un mesaj despre (nu) succesul. Iar pentru cei care testează aspectul normal al acestei este că rezultatele ar trebui să declanșeze acțiuni specifice, de exemplu, sau ștergerea unui utilizator determină o modificare a numărului de utilizatori afișate în fila corespunzătoare, și altele asemenea.

Metodele de extindere pe care le-am menționat sunt numite Aspecte fluente. Am vorbit despre faptul că acestea permit testarea mai naturală a rezultatelor testelor. Poate că sunt mai utile pentru unitatea de testare / integrare în cazul în care rezultatele pot fi mai complicat decât testele automate, cu toate acestea, în ciuda a tot ceea ce le-am citit singur. Ele sunt mult mai intuitive și mai clare decât cele încorporate în NUnit. Mai jos este un exemplu simplu care verifică rezultatul unui test de unitate cu utilizarea lor.

 

blog7

 

 

 

 

însumării

Sperăm că postul nostru a ajutat un număr mic de oameni care, ca noi, nu au avut niciodată contact cu teste automate. Dacă am găsi acest tip de post la început, cu siguranță ne-ar salva mult timp. În același timp, ne cerem scuze tuturor celor care sunt mai familiarizați cu acest subiect pentru toate erorile pe care, din păcate, nu le vedem la nivelul nostru.

Am încercat să transmitem experiențele noastre (modeste) în cel mai bun mod. Totuși, acesta este primul nostru text publicat și suntem conștienți de faptul că este posibil să nu fie perfect. Prin urmare, vă invităm să verificați intrarea (atât în ceea ce privește conținutul, cât și abilitățile noastre de utilizare a limbii materne) și să împărtășiți rezultatele în comentarii. Poate că voi veți găsi o greșeală pe care va trebui să o corectăm? 🙂

Aveți întrebări?
Aveți întrebări?

O echipă de specialiști OptiMES are deja peste 14 ani de experiență în implementarea soluțiilor IT în întreprinderile producătoare

Dacă aveți întrebări, scrieți-ne! Suntem disponibili prin telefon
0048 535 455 855 și adresa de e-mail biuro@syneo.pl.

Încercați OptiMES timp de 14 zile gratuit
și salvați pe producție sute de clienți mulțumiți.
Verifică numele
Numele este gratuit
Această adresă de e-mail are deja o aplicație de testare înregistrată
Introduceți adresa de e-mail corectă
Numele trebuie să aibă cel puțin 4 caractere
Verifică numele
Numele este gratuit
Numele este ocupat
Numele trebuie să aibă cel puțin 4 caractere
Vă rugăm să introduceți un nume de aplicație valid. Numai litere și numere

Înregistrări recente

Încercați OptiMES pentru GRATUIT!

14 zile fără obligații! Nu este necesară o carte de credit.