Bazat pe date de testare (DDT) - abordare la teste automate / arhitectură de construcție (unitate, integrare, cele mai multe ori se aplică pentru testarea backend), în care testul este în măsură să ia un set de intrări și un rezultat de referință sau condiție de referință. cu care trebuie să compare rezultatul obținut în timpul derulării parametrilor de intrare. O astfel de comparație este afirmarea unui astfel de test. În plus, ca parte a parametrilor de intrare, pot fi trecute opțiunile de execuție a testelor sau steaguri care afectează logica sa.
Adesea, sistemul care trebuie acoperit sau metoda este foarte complexă și apoi este imposibil să se introducă valori de referință explicite, aici putem vorbi despre stările de ieșire de referință. Uneori, trebuie să aplicați înțelepciune pentru a înțelege ce va fi descrierea de intrare și care va fi rezultatul. De exemplu:
- O parte din descrierea de intrare poate fi starea bazei de date. și anume Funcția DDT va include setUp de bază de date. Această stare poate fi luată dintr-un dump SQL și o puteți genera programabil pe java (al doilea mod este mai ușor de întreținut). Vezi exemplele 4 și 6.
- O parte din starea de ieșire de referință poate fi din nou starea bazei de date. Dar se întâmplă că totul este mult mai complicat și trebuie să verificăm nu numai statul, ci secvența de apeluri, evenimente și chiar contextul după fiecare apel în interiorul sistemului, atunci o idee bună poate fi construirea unui arbore de apel în timpul testului. și anume înregistrarea formatelor necesare (de exemplu, XML sau JSON), iar apoi datele de referință vor fi arborele de apel testat anterior. Apropo, arborele de apel de referință poate fi scris în prima rulare, apoi verificați manual. că este cea corectă, iar apoi este deja folosită pentru teste. Vezi exemplele 3 și 7.
Beneficiile utilizării
Sau, creatorul unui astfel de test poate oferi colegilor un flux de lucru, prin care puteți pregăti pur și simplu valorile de referință. Ie este de dorit să evităm dependența de crearea de seturi de date de la programatori și automate, oricine din proiect ar trebui să le poată pregăti.
De asemenea, devine mai ușor pentru managerul de proiect să controleze dezvoltarea, el nu trebuie să se îngrădească în esența algoritmilor, și chiar și calitatea codului, testele DDT sunt destul de suficiente pentru a avansa.
Utilizarea DDT-ului, destul de ciudat, pot fi folosite pe proiecte de ingineri mai puțin calificați, ca zone dificile de bună acoperire care folosesc DDT, de îndată ce toate spectacolele și oamenii în detrimentul testelor de integrare si Sweep continue la nivel local sau asupra mediului Dev, are posibilitatea de a rezolva problemele aduse .
Observ că, cu o anumită abordare a utilizării, testele Robot Framework pot fi foarte orientate spre DDT și oferă multe beneficii.
Cea mai simplă formă de DDT este testele parametrizate în JUnit, când seturile de date pentru testare sunt furnizate testului utilizând furnizorii de date.
DDT - nu este un panaceu, dar aplicația competentă în locurile potrivite ajută foarte mult.
Cum să înțelegeți când să creați DDT
Cum se creează DDT
Cel mai adesea e suficient să faci o buclă asupra testului principal și să compari datele de ieșire și cele de referință și să implementezi și rapoartele - prin logare sau prin alte mijloace.
Dar, în cazuri netriviale, este posibil să se construiască o arhitectură în jurul necesității de a crea un DDT. Vezi exemplele 3 și 7.
Sarcină. Traducerea unui număr într-o înregistrare digitală într-un șir. De exemplu, 134345 va fi "o sută treizeci și patru de mii trei sute patruzeci și cinci". * Luați în considerare deceniile - diferența dintre sfârșituri (de exemplu, două și două).
- Algoritmul ar trebui să funcționeze pentru cât mai multe numere arbitrare, respectiv valorile biților - milioane, mii, miliarde etc. - ar trebui să fie luate din director, de exemplu, un fișier text.
- Asigurați-vă că ați creat un test de date (I, ca utilizator, ar trebui să poată introduce mai multe seturi de 1. număr 2. rezultatul corect de referință, testul verifică independent toate seturile și spune că este incorect), ceea ce demonstrează că algoritmul funcționează corect. Utilizați JUnit.
- Dacă este posibil, utilizați OOP.
Sarcină. Implementați parserul HTML de la zero. Aceasta este implementarea unei rupturi de linie în modelul DOM.
Un inginer va merge așa. El va cere timp pentru a scădea specificația. Apoi vă va cere să vă gândiți la arhitectură. Apoi va face prototipuri. Cumva le testează. În tot acest timp, zile, săptămâni, managerul și echipa nu vor putea să-și verifice starea în practică.
Al doilea inginer în prima zi va efectua primul test de unitate, care va verifica cel mai simplu caz - un șir gol sau o etichetă goală
, sau altceva simplu. Și în fiecare zi el va arunca noi stări, extindându-și codul. În mod logic ar înveliți de DDT în, și lăsați întreaga echipă, manageri și testeri pentru a arunca diferite versiuni de HTML, iar rezultatul de referință (de exemplu, arborele DOM de obiecte care pot fi scrise la prima rulare a acestui algoritm și verificate manual). În această abordare, cazurile acumulate, schimbări în algoritmul și logica nu aduce în jos seturile de date anterioare, și este posibil să se înțeleagă în mod clar ceea ce a fost deja pusă în aplicare. Mai mult, seturile de intrare și valorile de referință pot fi împărțite în foldere, subfoldere și, astfel, pot crea documentația pentru parser.3. Abordarea utilizată în testarea platformei pentru automatizarea testelor XML2Selenium
XML2Selenium este un sistem construit pe plug-in-uri și pe interacțiunea plug-in-urilor. Pluginurile generează evenimente, se abonează la evenimente ale altor plug-in-uri. Adică, din interacțiunea complexă a utilizatorului ascunsă.
XML2Selenium poate să treacă prin testele scrise în format XML și să testeze aplicația Web UI (în interiorul căreia folosim Selenium / Web Driver).
Firește, orice schimbare în nucleul sistemului poate sparge logica interacțiunii, poate ucide compatibilitatea înapoi (atunci când apar noi plug-inuri), în plus, nucleul sistemului a impus munca inginerilor de seniori, prețul erorii a fost ridicat.
Am aplicat această abordare. A fost introdus un parametru special JVM care se solicită să păstreze în centrul tuturor arborelui de apel și eveniment pentru acest test, inclusiv înregistrarea, inițializarea și întregul ciclu de viață de plug-in-uri, precum și contextul trecut între rotitor după fiecare test de acțiune atomică. Astfel, am primit un fișier generat care conținea un instantaneu complet al comportamentului sistemului, aici este un exemplu de astfel de fișier:
Odată ce un dezvoltator sau un tester verificat manual că arborele pentru acest test - corect, acesta trimite în setul de valori de referință, și așa mai departe serverul de integrare continuă Jenkins maestru de ramură pentru fiecare test rulează în comparație un copac parsare, care este foarte stare stabilizată a sistemului .
4. Abordarea care a fost aplicată unuia dintre proiectele de testare a încărcării datelor
În acest caz, proiectul era obligat să testeze cât de bine funcționa componenta de descărcare a datelor. Descărcarea nu a fost banală, depinzând de starea bazei de date și în ea au apărut tot timpul bug-uri. Se poate spune că echipa nu a controlat stabilitatea acestei componente. A fost necesară o creștere radicală a stabilității sale.
Soluția era de a utiliza DDT. Parametrul de intrare a fost o descărcare a bazei de date în format XML. Valoarea de referință este fișierul de descărcare verificat anterior, care este cu siguranță fără erori. Astfel, testarea a fost redusă la crearea de versiuni diferite ale bazei de date, precum și la verificarea fișierelor de referință și la crearea unor seturi de astfel de teste.
Proiectul a avut o regresie suficientă. De fiecare dată când un bug a apărut în descărcare, a fost adăugat un alt set de date, care a acoperit această situație. Seturile au fost acumulate, existența lor nu a permis producerea unor noi bug-uri și, după un timp, componenta sa stabilizat.
După cum îmi amintesc, am implementat, de asemenea, generarea stadiului necesar al bazei de date din Java, astfel încât să nu depindem de gropile de gunoi și să nu le actualizăm în mod continuu cu modificările din schema de date.
5. Proiect real - testarea gestiunii erorilor în gramatica complexă
Esența proiectului a fost după cum urmează. Pe partea de client a serverului a apărut XML cu o descriere completă a nu numai a UI-ului care trebuia să fie desenat, ci și a comportamentului care a fost transmis într-un format binar în același XML. Asta este, comportamentul ar putea fi orice, există un sistem plug-in.
Acest XML avea o sintaxă destul de complexă, iar echipa noastră era independentă de dezvoltatorii backend. A trebuit să ne protejăm de XML greșit, trebuia să începem să construim UI numai când 100% înțelege că XML-ul era corect.
Pentru aceasta, a fost utilizat DDT. Am creat un număr imens de variante de XML de intrare, inclusiv incorecte, incorecte și am verificat dacă sunt eliminate excepțiile necesare cu mesajele necesare.
Astfel, parametrul de intrare este XML, starea de referință este tipul de excepție, mesajul sau chiar partea de trasare a stivei. Au fost create mai multe sute de seturi de test și de fiecare dată când sa schimbat ceva în format, au apărut noi parametri sau au existat noi excepții și bug-uri - testele au fost extinse. La sfârșitul proiectului, aceasta a fost cea mai stabilă parte a sistemului.
Această imagine prezintă o parte a fișierului Excel în care parametrul de intrare și comportamentul de referință - în cazul nostru, sunt specificate informații despre excepții (tip și mesaj).
6. Testarea încărcării complexe a datelor. Izolarea logicii procedurilor stocate
Pe unul dintre proiecte, datele sunt descărcate într-un format CSV (format foarte complex intern) în baza de date. Mai mult decât atât, am primit codul vechi și toată logica încărcării are loc în procedurile stocate, în care aproximativ zece mii de linii. Sarcina a fost aceea de a stabiliza această componentă a descărcării și de a furniza teste de regresie.
Ca și în exemplul 4, cu un depozit de date, am folosit DDT-ului, și ca parametri de intrare utilizate 1) starea bazei de date (am folosit benă în format SQL) și 2) fișierul care urmează să fie descărcat. Ca valoare de referință am folosit un fișier XLS care reprezintă conținutul de care avem nevoie de tabele bazei de date după încărcare.
Toate bug-urile care s-au întâmplat adesea, am pus în DDT.
Curând am constatat că remedieri noastre nu afectează ultimele bug-uri și erori care au devenit mai puțin și controlul asupra lor - a devenit mai mare, pentru că acum este posibil sa de a le reda rapid și eficient în mod automat prin adăugarea de noi seturi.
În cazul acestui proiect, din cauza lipsei de timp, au fost folosite haldele crude, în consecință, potențial sprijinul unui astfel de sistem în viitor va necesita costuri.
Când creați o platformă SOA (de exemplu, cadrul pentru proiecte SOA) de testare a fost însărcinat să efectueze, sistem de autobuz, jucând toate situațiile posibile care pot apărea în timpul ciclului de viață al proiectului SOA.
Pentru a implementa această sarcină, a fost creat un cadru care vă permite să îl implementați prin descrierea sistemului - în realitate acestea sunt servere virtuale diferite care sunt conectate între ele prin intermediul platformei SOA. Fiecare dintre servere a implementat o aplicație care a fost conectată la magistrala de sistem și a executat cu pricepere scripturile pe care le-a primit. În scripturile transmise am cusut comportamentul necesar și scriptul necesar.
Astfel, datele de intrare au fost 1) dosar care descrie topologia sistemului, și 2) un set de scripturi pentru fiecare nod al topologiei, care a spus că are loc pe fiecare nod și valorile de referință au fost copac (un fel de log) prelucrarea mesajelor într-un astfel de sistem.
Trimiteți-le prietenilor: