Čo sú údaje z testu? Testujte techniky prípravy dát s príkladom

what is test data test data preparation techniques with example

Zistite, čo sú testovacie dáta a ako pripraviť testovacie dáta na testovanie:

V súčasnej epike revolučného rastu informačných a technologických technológií testéri bežne zažívajú rozsiahlu spotrebu testovacích údajov v životnom cykle testovania softvéru.

Testeri nezhromažďujú a neuchovávajú iba údaje z existujúcich zdrojov, ale tiež generujú obrovské objemy testovacích údajov, aby zabezpečili ich boomský prínos v kvalite dodávok produktu na skutočné použitie.

Preto ako testeri musíme neustále skúmať, učiť sa a uplatňovať najefektívnejšie prístupy k zhromažďovaniu, generovaniu, údržbe, automatizácii a komplexnej správe údajov pre všetky typy funkčných a nefunkčných testov.

V tomto návode uvediem tipy, ako pripraviť testovacie dáta, aby vám nesprávny údaj a neúplné nastavenie testovacieho prostredia nenechali ujsť žiadny dôležitý testovací prípad.

Čo sa dozviete:

• Čo sú testovacie údaje a prečo sú dôležité
  • Vyskúšajte výzvy na získavanie údajov
  • Stratégie pre prípravu testovacích dát
  • Poškodené údaje z testu
  • Testovacie údaje pre testovací prípad výkonu
  • Ako pripraviť údaje, ktoré zabezpečia maximálne pokrytie testom?
  • Údaje pre testovanie čiernej skrinky
  • Príklad testovacích dát pre Open EMR AUT
  • Vytváranie manuálnych údajov pre testovanie Otvorená aplikácia EMR
• Vlastnosti dobrých údajov z testu
  • Otestujte vlastnosti údajov
  • Skúšobné techniky prípravy údajov
  • Prístupy k vytváraniu testovacích údajov:
  • Záver
  • Odporúčané čítanie

Čo sú testovacie údaje a prečo sú dôležité

S odkazom na štúdiu uskutočnenú spoločnosťou IBM v roku 2016, hľadanie, správa, údržba a generovanie testovacích údajov predstavuje 30% - 60% času testerov. Je nepopierateľným dôkazom, že príprava údajov je časovo náročnou fázou testovania softvéru.

Postava 1: Priemerný čas testerov strávený na TDM

Napriek tomu je skutočnosťou v mnohých rôznych disciplínach, že väčšina vedcov zaoberajúcich sa údajmi trávi 50% - 80% času potrebného na vývoj svojho modelu pri organizovaní údajov. A teraz vzhľadom na legislatívu a rovnako ako aj na informácie umožňujúce identifikáciu osôb (PII) je účasť testerov v procese testovania nesmierne slušná.

Dôveryhodnosť a spoľahlivosť údajov z testov sa dnes pre majiteľov firiem považuje za nekompromisný prvok. Majitelia produktov považujú duchovné kópie testovacích údajov za najväčšiu výzvu, ktorá znižuje spoľahlivosť akejkoľvek aplikácie v tomto jedinečnom čase požiadaviek / požiadaviek klientov na zabezpečenie kvality.

Z hľadiska dôležitosti testovacích údajov drvivá väčšina vlastníkov softvéru neakceptuje testované aplikácie s falošnými dátami alebo menej v bezpečnostných opatreniach.

Prečo si v tomto okamihu nespomenieme, čo sú to testovacie dáta? Keď začneme písať naše testovacie prípady, aby sme overili a overili dané vlastnosti a vyvinuté scenáre aplikácie v rámci testu, potrebujeme informácie, ktoré sa použijú ako vstup na vykonanie testov na identifikáciu a lokalizáciu chýb.

ako vytvoriť java aplikáciu v zatmení -

A vieme, že tieto informácie musia byť presné a úplné, aby sa mohli chyby vyskytnúť. Je to to, čo nazývame testovacie údaje. Aby sme to upresnili, môžu to byť mená, krajiny atď., Ktoré nie sú citlivé, pretože údaje týkajúce sa Kontaktných informácií, SSN, anamnézy a údajov o kreditnej karte sú citlivé povahy.

Údaje môžu byť v akejkoľvek forme, ako napríklad:

• Údaje o teste systému
• Testovacie dáta SQL
• Údaje o teste výkonnosti
• Testovacie dáta XML

Ak píšete testovacie prípady, potrebujete vstupné údaje pre akýkoľvek druh testu. Tester môže poskytnúť tieto vstupné údaje v čase vykonania testovacích prípadov alebo môže aplikácia požadované vstupné údaje vybrať z vopred definovaných umiestnení údajov.

Dáta môžu byť akýkoľvek druh vstupu do aplikácie, akýkoľvek druh súboru, ktorý je načítaný aplikáciou, alebo záznamy načítané z databázových tabuliek.

Príprava správnych vstupných údajov je súčasťou nastavenia testu. Spravidla to testeri nazývajú a príprava na testovacie lôžko . V testovacom paneli sa všetky softvérové ​​a hardvérové ​​požiadavky nastavujú pomocou preddefinovaných údajov.

Ak nemáte systematický prístup k zhromažďovaniu údajov písanie a vykonávanie testovacích prípadov potom existuje šanca, že zmeškáte niektoré dôležité testovacie prípady. Testeri môžu vytvárať svoje vlastné údaje podľa testovacích potrieb.

Nespoliehajte sa na údaje vytvorené inými testermi alebo na štandardné údaje o výrobe. Vždy vytvorte nový súbor údajov podľa svojich požiadaviek.

Niekedy nie je možné vytvoriť úplne novú množinu údajov pre každé zostavenie. V takýchto prípadoch môžete použiť štandardné výrobné údaje. Nezabudnite však do tejto existujúcej databázy pridať / vložiť svoje vlastné súbory údajov. Jedným z najlepších spôsobov, ako vytvoriť údaje, je použiť existujúce vzorové údaje alebo testovacie lôžko a pripojiť svoje nové údaje o testovacích prípadoch zakaždým, keď získate na testovanie rovnaký modul. Týmto spôsobom môžete zostaviť komplexný súbor údajov za dané obdobie.

Vyskúšajte výzvy na získavanie údajov

Testéri považujú za jednu z oblastí generovania testovacích údajov požiadavku na získavanie údajov pre podmnožinu. Napríklad máte viac ako milión zákazníkov a potrebujete ich na testovanie tisíc. A tieto vzorové údaje by mali byť konzistentné a štatisticky predstavovať vhodné rozdelenie cieľovej skupiny. Inými slovami, máme nájsť tú pravú osobu na testovanie, čo je jedna z najužitočnejších metód testovania prípadov použitia.

A tieto vzorové údaje by mali byť konzistentné a štatisticky predstavovať vhodné rozdelenie cieľovej skupiny. Inými slovami, máme nájsť tú pravú osobu na testovanie, čo je jedna z najužitočnejších metód testovania prípadov použitia.

V procese navyše existujú určité environmentálne obmedzenia. Jedným z nich je mapovanie politík PII. Pretože súkromie je významnou prekážkou, testéri musia klasifikovať údaje PII.

Nástroje na správu testovacích údajov sú určené na riešenie spomínanej problematiky. Tieto nástroje navrhujú politiky na základe štandardov / katalógu, ktoré majú. Nie je to však príliš bezpečné cvičenie. Stále ponúka možnosť auditu toho, čo človek robí.

Aby sme držali krok s riešením súčasných a dokonca aj budúcich výziev, mali by sme si vždy klásť otázky ako Kedy / kde by sme mali zahájiť konanie TDM? Čo by malo byť automatizované? Koľko investícií by mali spoločnosti prideliť na testovanie v oblasti rozvoja zručností v oblasti ľudských zdrojov a využívania novších nástrojov TDM? Mali by sme začať testovať s funkčným alebo s nefunkčným testovaním? A oveľa pravdepodobnejšie otázky ako oni.

Niektoré z najbežnejších problémov so získavaním údajov z testov sú uvedené nižšie:

• Tímy nemusia mať dostatočné znalosti a zručnosti v oblasti nástrojov na generovanie testovacích údajov
• Pokrytie testovacích údajov je často neúplné
• Menej jasnosti v požiadavkách na údaje týkajúce sa špecifikácií objemov počas fázy zhromažďovania
• Testovacie tímy nemajú prístup k zdrojom údajov
• Oneskorenie poskytovania prístupu k testovacím údajom vývojárom
• Údaje produkčného prostredia nemusia byť na testovanie na základe vyvinutých obchodných scenárov úplne použiteľné
• Možno budete potrebovať veľké objemy dát za krátke časové obdobie
• Závislosti / kombinácie údajov na testovanie niektorých obchodných scenárov
• Testeri trávia viac času, ako je potrebné, komunikáciou s architektmi, správcami databáz a BA pri zhromažďovaní údajov
• Dáta sa väčšinou vytvárajú alebo pripravujú počas vykonania testu
• Viaceré aplikácie a dátové verzie
• Cykly kontinuálneho uvoľňovania naprieč niekoľkými aplikáciami
• Legislatíva týkajúca sa starostlivosti o osobné identifikačné údaje (PII)

Na druhej strane testovania údajov, vývojári pripravujú údaje o výrobe. To je miesto, kde QA potrebuje spolupracovať s vývojármi na ďalšom testovaní pokrytia AUT. Jednou z najväčších výziev je zahrnúť všetky možné scenáre (100% testovací prípad) do všetkých možných negatívnych prípadov.

V tejto časti sme hovorili o problémoch s testovacími dátami. Keď ste ich zodpovedajúcim spôsobom vyriešili, môžete pridať ďalšie výzvy. Následne sa pozrime na rôzne prístupy k spracovaniu návrhu a správy testovacích dát.

Stratégie pre prípravu testovacích dát

Z každodennej praxe vieme, že hráči v testovacom priemysle neustále prežívajú rôzne spôsoby a prostriedky na zvýšenie testovacieho úsilia, a čo je najdôležitejšie, z hľadiska jeho nákladovej efektívnosti. V krátkom priebehu vývoja informačných a technologických technológií sme videli, že keď sa nástroje integrujú do produkčných / testovacích prostredí, úroveň výstupu sa podstatne zvýšila.

Keď hovoríme o úplnosti a úplnom pokrytí testovania, záleží to hlavne na kvalite údajov. Pretože testovanie je chrbticou pri dosahovaní kvality softvéru, testovacie údaje sú základným prvkom v procese testovania.

Obrázok 2: Stratégie pre správu testovacích údajov (TDM)

Vytváranie plochých súborov na základe pravidiel mapovania. Je vždy praktické vytvoriť podmnožinu údajov, ktoré potrebujete, z produkčného prostredia, kde vývojári navrhli a kódovali aplikáciu. Tento prístup skutočne znižuje úsilie testerov o prípravu údajov a maximalizuje využitie existujúcich zdrojov na zabránenie ďalším výdavkom.

Spravidla musíme údaje vytvoriť alebo ich aspoň identifikovať na základe typu požiadaviek, ktoré má každý projekt na samom začiatku.

Pri riešení procesu TDM môžeme použiť nasledujúce stratégie:

1. Údaje z produkčného prostredia
2. Načítava sa dotazy SQL, ktoré extrahujú údaje z existujúcich databáz klienta
3. Automatizované nástroje na generovanie údajov

Testéri podporia svoje testovanie úplnými údajmi tak, že zohľadnia prvky znázornené na obrázku 3 tu. Pracovníci v agilných vývojových tímoch generujú údaje potrebné na vykonanie testovacích prípadov. Keď hovoríme o testovacích prípadoch, máme na mysli prípady pre rôzne typy testovania, ako je biela skrinka, čierna skrinka, výkon a bezpečnosť.

V tomto okamihu vieme, že údaje na testovanie výkonu by mali byť schopné určiť, ako rýchlo systém reaguje pri danom pracovnom zaťažení, aby sa čo najviac priblížil skutočnému alebo živému veľkému množstvu údajov so značným pokrytím.

Na testovanie bielej skrinky vývojári pripravujú požadované údaje tak, aby pokrývali čo najviac pobočiek, všetky cesty v zdrojovom kóde programu a negatívne rozhranie API (Application Program Interface).

Obrázok 3: Testovanie aktivít generovania údajov

Nakoniec môžeme povedať, že všetci, ktorí pracujú v životnom cykle vývoja softvéru ( SDLC ) Rovnako ako BA, vývojári a vlastníci produktov by mali byť dobre zapojení do procesu prípravy testovacích údajov. Môže to byť spoločné úsilie. A teraz vás vezmeme k problému poškodených testovacích údajov.

Poškodené údaje z testu

Pred vykonaním akýchkoľvek testovacích prípadov na našich existujúcich údajoch by sme sa mali ubezpečiť, že údaje nie sú poškodené / zastarané a aplikácia v rámci testu dokáže načítať zdroj údajov. Typicky, keď je viac ako tester, ktorý pracuje na rôznych moduloch AUT v testovacom prostredí súčasne, je pravdepodobnosť poškodenia údajov taká vysoká.

V rovnakom prostredí testeri upravujú existujúce údaje podľa svojich potrieb / požiadaviek testovacích prípadov. Väčšinou, keď sú testeri hotoví s údajmi, nechajú ich tak, ako sú. Len čo ďalší tester vyzdvihne upravené údaje a vykoná ďalšie vykonanie testu, existuje možnosť konkrétneho zlyhania testu, čo nie je chyba alebo chyba kódu.

Týmto spôsobom sa vo väčšine prípadov poškodia alebo zastarajú údaje, ktoré vedú k zlyhaniu. Aby sme sa vyhli a minimalizovali pravdepodobnosť nezrovnalosti v údajoch, môžeme použiť nižšie uvedené riešenia. Na koniec tohto tutoriálu v sekcii komentárov môžete samozrejme pridať ďalšie riešenia.

1. Zálohovanie vašich údajov
2. Vráťte svoje upravené údaje do pôvodného stavu
3. Rozdelenie údajov medzi testerov
4. Udržujte správcu dátového skladu aktualizovaného o akejkoľvek zmene / úprave údajov

Ako uchovať vaše dáta neporušené v akomkoľvek testovacom prostredí?

Za testovanie rovnakého zostavenia je väčšinou zodpovedných veľa testerov. V takom prípade bude mať viac ako jeden tester prístup k spoločným údajom a pokúsi sa manipulovať so spoločným súborom údajov podľa svojich potrieb.

Ak ste pripravili údaje pre niektoré konkrétne moduly, najlepším spôsobom, ako zachovať neporušenú množinu údajov, je uchovať si ich záložné kópie.

Testovacie údaje pre testovací prípad výkonu

Testy výkonu vyžadujú veľmi veľkú množinu údajov. Niekedy manuálne vytváranie údajov nezistí nejaké jemné chyby, ktoré môžu byť zachytené iba skutočnými údajmi vytvorenými testovanou aplikáciou. Ak chcete údaje v reálnom čase, ktoré nie je možné vytvoriť ručne, požiadajte svojho vedúceho / správcu, aby ich sprístupnil v živom prostredí.

Tieto údaje budú užitočné na zabezpečenie hladkého fungovania aplikácie pre všetky platné vstupy.

Aké sú ideálne údaje z testu?

Dáta sa dajú považovať za ideálne, ak pre minimálnu veľkosť súboru údajov budú identifikované všetky chyby aplikácie. Pokúste sa pripraviť údaje, ktoré budú obsahovať všetky funkcionality aplikácie, ale nepresahujúce náklady a časové obmedzenia na prípravu údajov a vykonávanie testov.

Ako pripraviť údaje, ktoré zabezpečia maximálne pokrytie testom?

Navrhnite svoje údaje s ohľadom na nasledujúce kategórie:

1) Žiadne údaje: Spustite testovacie prípady na prázdnych alebo predvolených údajoch. Zistite, či sa generujú správne chybové správy.

2) Platný súbor údajov: Vytvorte ho a skontrolujte, či aplikácia funguje podľa požiadaviek a či sú platné vstupné údaje správne uložené v databáze alebo súboroch.

3) Neplatná množina údajov: Pripravte neplatnú množinu údajov na kontrolu správania aplikácie na záporné hodnoty, vstupy alfanumerických reťazcov.

4) Nezákonný formát údajov: Vytvorte jednu množinu údajov z nelegálneho formátu údajov. Systém by nemal prijímať údaje v neplatnom alebo nezákonnom formáte. Skontrolujte tiež, či sú generované správne chybové správy.

5) Súbor údajov o hraničných podmienkach: Datová sada obsahujúca údaje mimo rozsahu. Identifikujte okrajové prípady aplikácie a pripravte súbor údajov, ktorý pokryje dolné aj horné okrajové podmienky.

algoritmus rozhodovacieho stromu v dolovaní dát

6) Súbor údajov na výkonové, záťažové a záťažové testovanie: Tento súbor údajov by mal mať veľký objem.

Týmto spôsobom vytvorenie samostatných súborov údajov pre každú testovaciu podmienku zabezpečí úplné pokrytie testom.

Údaje pre testovanie čiernej skrinky

Testéri zabezpečenia kvality vykonávajú integračné testovanie, testovanie systému a akceptačné testovanie, ktoré sa nazýva testovanie čiernej skrinky. Pri tejto metóde testovania testéri nemajú prácu s vnútornou štruktúrou, dizajnom a kódom aplikácie, ktorá je predmetom testu.

Primárnym účelom testerov je identifikovať a lokalizovať chyby. Týmto spôsobom aplikujeme funkčné alebo nefunkčné testovanie pomocou rôznych techník testovania čiernej skrinky.

Obrázok 4: Metódy návrhu údajov čiernej skrinky

V tomto okamihu testéri potrebujú údaje o teste ako vstupné údaje pre vykonávanie a implementáciu techník testovania čiernej skrinky. A testéri by mali pripraviť údaje, ktoré preveria všetky funkčnosti aplikácie, aby neprekročili dané náklady a čas.

Údaje môžeme navrhnúť pre naše testovacie prípady s prihliadnutím na kategórie množín údajov, ako napríklad žiadne údaje, platné údaje, neplatné údaje, formát nelegálnych údajov, údaje okrajových podmienok, oddiel ekvivalencie, tabuľka rozhodovacích údajov, údaje o prechode stavu a údaje prípadu použitia. Pred vstupom do kategórií súborov údajov testeri inicializujú zhromažďovanie údajov a analýzu existujúcich zdrojov aplikácie pod testerom (AUT).

Podľa predchádzajúcich bodov, ktoré sa týkajú udržiavania dátového skladu vždy aktuálneho, mali by ste požiadavky na údaje zdokumentovať na úrovni testovacích prípadov a pri skriptovaní testovacích prípadov ich označiť ako použiteľné alebo opakovane nepoužiteľné. Pomôže vám to, aby boli údaje potrebné na testovanie prehľadné a zdokumentované od samého začiatku, na čo sa môžete neskôr obrátiť.

Príklad testovacích dát pre Open EMR AUT

Pre náš aktuálny tutoriál máme Open EMR ako testovanú aplikáciu (AUT).

=> Nájdite odkaz na otvorenú aplikáciu EMR tu pre vašu referenciu / prax.

Nasledujúca tabuľka do veľkej miery ilustruje ukážku zhromažďovania požiadaviek na údaje, ktorá môže byť súčasťou dokumentácie k testovacím prípadom, a ktorá sa aktualizuje pri písaní testovacích prípadov pre vaše testovacie scenáre.

( POZNÁMKA : Kliknite na ľubovoľnom obrázku pre zväčšené zobrazenie)

Vytváranie manuálnych údajov pre testovanie Otvorená aplikácia EMR

Urobme krok vpred k vytvoreniu manuálnych údajov na testovanie aplikácie Open EMR pre dané kategórie množiny údajov.

1) Žiadne údaje: Tester overuje adresu URL aplikácie Open EMR a funkcie „Vyhľadať alebo pridať pacienta“ bez uvedenia údajov.

dva) Platné údaje: Tester overí otvorenú adresu URL aplikácie EMR a funkciu „Vyhľadať alebo pridať pacienta“ poskytnutím platných údajov.

3) Neplatné údaje: Tester overí otvorenú adresu URL aplikácie EMR a funkciu „Vyhľadať alebo pridať pacienta“ s uvedením neplatných údajov.

4) Neplatný formát údajov: Tester overí otvorenú adresu URL aplikácie EMR a funkciu „Vyhľadať alebo pridať pacienta“ s uvedením neplatných údajov.

Testovacie údaje pre 1-4 kategórie súborov údajov:

5) Súbor údajov hraničnej podmienky: Je to na určenie vstupných hodnôt pre hranice, ktoré sú buď vo vnútri, alebo mimo daných hodnôt ako údaje.

6) Sada údajov oddielu rovnocennosti: Je to testovacia technika, ktorá rozdeľuje vaše vstupné údaje na vstupné hodnoty platných a neplatných.

Skúšobné údaje pre 5^tha 6^thkategórie množiny údajov, čo je pre používateľské meno a heslo pre otvorený EMR:

7) Sada údajov rozhodovacej tabuľky: Je to technika, ako svoje údaje kvalifikovať kombináciou vstupov a dosiahnuť tak rôzne výsledky. Táto metóda testovania čiernej skrinky vám pomôže znížiť vaše úsilie pri testovaní pri overovaní každej kombinácie testovacích údajov. Táto technika vám navyše môže zabezpečiť úplné pokrytie testom.

Nižšie nájdete súbor údajov rozhodovacej tabuľky pre používateľské meno a heslo aplikácie Open EMR.

Výpočet kombinácií vykonaných v tabuľke vyššie je podrobnejšie opísaný nižšie. Možno budete potrebovať, keď urobíte viac ako štyri kombinácie.

• Počet kombinácií Počet podmienok 1 Hodnoty * Počet podmienok 2 Hodnoty
• Počet kombinácií 2 ^ Počet pravdivých / nepravdivých podmienok
• Príklad: Počet kombinácií - 2 ^ 2 = 4

8) Sada testovacích údajov prechodu stavu: Je to testovacia technika, ktorá vám pomôže overiť prechod stavu aplikácie podľa testu (AUT) poskytnutím vstupných podmienok systému.

Napríklad, prihlásime sa do aplikácie Open EMR zadaním správneho používateľského mena a hesla na prvý pokus. Systém nám poskytuje prístup, ale ak zadáme nesprávne prihlasovacie údaje, systém prístup odmietne. Testovanie stavu prechodu overuje, koľko pokusov o prihlásenie môžete vykonať pred zatvorením aplikácie Open EMR.

Nasledujúca tabuľka ukazuje, ako reagujú správne alebo nesprávne pokusy o prihlásenie

9) Použiť dátum testu prípadu: Je to testovacia metóda, ktorá identifikuje naše testovacie prípady zachytávajúce komplexné testovanie konkrétnej funkcie.

Príklad, otvorené prihlásenie EMR:

Prečítajte si tiež => Techniky správy dátových údajov

Vlastnosti dobrých údajov z testu

Ako tester musíte otestovať modul ‘Výsledky skúšky’ na webovej stránke univerzity. Zvážte, že celá aplikácia bola integrovaná a je v stave „Pripravené na testovanie“. „Skúšobný modul“ je prepojený s modulmi „Registrácia“, „Kurzy“ a „Financie“.

Predpokladajme, že máte primerané informácie o aplikácii a že ste vytvorili komplexný zoznam testovacích scenárov. Teraz musíte tieto testovacie prípady navrhnúť, zdokumentovať a vykonať. V časti „Akcie / kroky“ alebo „Testovacie vstupy“ testovacích prípadov budete musieť ako vstupné údaje pre test uviesť prijateľné údaje.

Údaje uvedené v testovacích prípadoch musia byť vybrané správne. Presnosť stĺpca „Skutočné výsledky“ dokumentu s testovacím prípadom závisí predovšetkým od údajov o teste. Krok na prípravu vstupných testovacích údajov je teda veľmi dôležitý. Toto je teda môj prehľad o „Testovaní databázy DB - Stratégie prípravy testovacích údajov“.

Otestujte vlastnosti údajov

Údaje o teste by mali byť vybrané presne a musia mať nasledujúce štyri vlastnosti:

1) Realistické:

Realisticky to znamená, že údaje by mali byť presné v kontexte scenárov z reálneho života. Napríklad na otestovanie poľa „Vek“ by mali byť všetky hodnoty kladné a minimálne 18. Je celkom zrejmé, že uchádzači o prijatie na univerzitu majú zvyčajne 18 rokov (z hľadiska obchodných požiadaviek by to mohlo byť definované inak).

Ak sa testovanie vykonáva pomocou realistických údajov o teste, urobí to aplikáciu robustnejšou, pretože väčšinu možných chýb je možné zachytiť pomocou realistických údajov. Ďalšou výhodou realistických údajov je ich opätovná použiteľnosť, ktorá šetrí náš čas a úsilie pri vytváraní nových údajov znova a znova.

Keď hovoríme o realistických údajoch, rád by som vám predstavil koncept súboru zlatých údajov. Zlatým súborom údajov je ten, ktorý pokrýva takmer všetky možné scenáre, ktoré sa vyskytujú v skutočnom projekte. Použitím GDS môžeme poskytnúť maximálne pokrytie testom. Používam GDS na vykonávanie regresného testovania v mojej organizácii a to mi pomáha testovať všetky možné scenáre, ktoré môžu nastať, ak sa kód dostane do produkčného poľa.

Na trhu existuje veľa nástrojov na generovanie testovacích údajov, ktoré analyzujú charakteristiky stĺpcov a definície používateľov v databáze a na základe nich pre vás generujú realistické testovacie údaje. Niekoľko dobrých príkladov nástrojov, ktoré generujú údaje na testovanie databázy, je Generátor údajov DTM , Generátor údajov SQL a Mockaroo .

2. Prakticky platné:

Je to podobné ako realistické, ale nie rovnaké. Táto vlastnosť skôr súvisí s obchodnou logikou AUT, napr. hodnota 60 je v poli veku realistická, ale pre uchádzača o absolvovanie magisterského alebo magisterského programu je prakticky neplatná. V takom prípade by platný rozsah bol 18 - 25 rokov (to môže byť definované v požiadavkách).

3. Všestranný na pokrytie scenárov:

najlepší anti spyware pre Windows 10

V jednom scenári môže byť niekoľko ďalších podmienok, takže údaje voľte premyslene, aby ste pokryli maximálne aspekty jedného scenára minimálnym súborom údajov, napr. pri vytváraní testovacích údajov pre modul výsledku neberte do úvahy iba prípad bežných študentov, ktorí hladko dokončujú svoj program. Venujte pozornosť študentom, ktorí opakujú rovnaký kurz a patria do rôznych semestrov alebo dokonca do iných programov. Súbor údajov môže vyzerať takto:

Môže existovať niekoľko ďalších zaujímavých a zložitých čiastkových podmienok. Napr. obmedzenie rokov na absolvovanie študijného programu, absolvovanie nevyhnutného kurzu na zápis do kurzu, maximálne č. kurzov, ktoré si môže študent zapísať do jedného semestra, atď. atď. Nezabudnite všetky tieto scenáre pokryť múdro pomocou konečnej množiny údajov.

4. Výnimočné údaje (ak je to potrebné / požadované):

Môžu existovať určité výnimočné scenáre, ktoré sa vyskytujú menej často, ale v prípade ich výskytu si vyžadujú veľkú pozornosť, napr. zdravotne postihnutých študentov.

Ďalšie dobré vysvetlenie a príklad výnimočnej množiny údajov nájdete na obrázku nižšie:

Zobrať:

Údaje o teste sú známe ako dobré údaje z testu, ak sú realistické, platné a univerzálne. Ďalšou výhodou je, ak údaje poskytujú pokrytie aj pre výnimočné scenáre.

Skúšobné techniky prípravy údajov

Stručne sme diskutovali o dôležitých vlastnostiach testovacích dát a tiež sme rozpracovali dôležitosť výberu testovacích dát pri testovaní databázy. Teraz poďme diskutovať o „ techniky na prípravu údajov o skúškach „ .

Existujú iba dva spôsoby, ako pripraviť údaje o teste:

Metóda č. 1) Vložte nové údaje

Získajte čistý DB a vložte všetky údaje, ako sú uvedené vo vašich testovacích prípadoch. Po zadaní všetkých požadovaných a požadovaných údajov začnite vykonávať svoje testovacie prípady a vyplňte stĺpce Pass / Fail (Porovnanie skutočného výstupu s očakávaným výstupom). Znie to jednoducho, však? Ale počkajte, nie je to také jednoduché.

Existuje niekoľko základných a kritických obáv:

• Prázdna inštancia databázy nemusí byť k dispozícii
• Vložené údaje z testu nemusia byť dostatočné na testovanie niektorých prípadov, ako je testovanie výkonu a zaťaženia.
• Vloženie požadovaných testovacích údajov do prázdnej databázy DB nie je ľahká práca kvôli závislostiam databázovej tabuľky. Z dôvodu tohto nevyhnutného obmedzenia sa vkladanie údajov môže stať pre testera náročnou úlohou.
• Vloženie obmedzených údajov o teste (len podľa potrieb testovacieho prípadu) môže skryť niektoré problémy, ktoré možno nájsť iba pri veľkej množine údajov.
• Na vkladanie údajov môžu byť potrebné zložité dotazy a / alebo postupy, a preto by bola potrebná dostatočná pomoc alebo pomoc vývojárov DB.

Vyššie uvedených päť problémov je najkritickejších a najočividnejších nevýhod tejto techniky na prípravu testovacích údajov. Existujú však aj niektoré výhody:

• Vykonávanie TC sa stáva efektívnejším, pretože DB má iba požadované údaje.
• Izolácia chýb nevyžaduje žiadny čas, pretože v databáze sa nachádzajú iba údaje uvedené v testovacích prípadoch.
• Menej času potrebného na testovanie a porovnanie výsledkov.
• Neusporiadaný testovací proces

Metóda č. 2) Vyberte podmnožinu vzorových údajov zo skutočných údajov databázy

Toto je uskutočniteľná a praktickejšia technika na prípravu údajov o teste. Vyžaduje však dôkladné technické zručnosti a vyžaduje podrobné znalosti schémy DB a SQL. V tejto metóde musíte skopírovať a použiť produkčné údaje nahradením niektorých hodnôt polí fiktívnymi hodnotami. Toto je najlepšia podmnožina údajov pre vaše testovanie, pretože predstavuje výrobné údaje. To však nemusí byť vždy možné z dôvodu problémov so zabezpečením údajov a ochranou súkromia.

Zobrať:

Vo vyššie uvedenej časti sme vyššie diskutovali techniky prípravy testovacích údajov. Stručne povedané, existujú dve techniky - buď vytvorenie čerstvých údajov, alebo výber podmnožiny z už existujúcich údajov. Oboje je potrebné vykonať spôsobom, aby vybrané údaje poskytovali pokrytie pre rôzne testovacie scenáre, hlavne platný a neplatný test, test výkonu a nulový test.

V poslednej časti sa poďme rýchlo pozrieť aj na prístupy generovania údajov. Tieto prístupy sú užitočné, keď potrebujeme generovať nové údaje.

Prístupy k vytváraniu testovacích údajov:

• Ručné generovanie testovacích údajov: V tomto prístupe sú testovacie údaje ručne zadávané testermi podľa požiadaviek testovacieho prípadu. Je to čas, ktorý trvá proces a tiež náchylný k chybám.
• Automatické generovanie testovacích dát: To sa deje pomocou nástrojov na generovanie údajov. Hlavnou výhodou tohto prístupu je jeho rýchlosť a presnosť. Je to však vyššia cena ako pri manuálnom generovaní testovacích údajov.
• Vkladanie údajov typu back-end : Toto sa deje pomocou dotazov SQL. Tento prístup môže tiež aktualizovať existujúce údaje v databáze. Je to rýchle a efektívne, ale malo by sa implementovať veľmi opatrne, aby sa nepoškodila existujúca databáza.
• Používanie nástrojov tretích strán : Na trhu sú k dispozícii nástroje, ktoré najskôr porozumejú vašim testovacím scenárom a potom zodpovedajúcim spôsobom generujú alebo vkladajú údaje, aby poskytli široké pokrytie testom. Tieto nástroje sú presné, pretože sú prispôsobené podľa obchodných potrieb. Ale sú dosť nákladné.

Zobrať:

Existujú 4 prístupy k generovaniu testovacích údajov:

1. Príručka,
2. automatizácia,
3. back-end vkladanie dát,
4. a nástroje tretích strán.

Každý prístup má svoje vlastné výhody a nevýhody. Mali by ste zvoliť prístup, ktorý uspokojí vaše obchodné a testovacie potreby.

Záver

Vytváranie kompletných údajov o testoch softvéru v súlade s priemyselnými štandardmi, legislatívou a základnými dokumentmi uskutočneného projektu patrí medzi základné zodpovednosti testerov. Čím efektívnejšie spravujeme testovacie dáta, tým viac môžeme nasadiť produkty bez chýb pre používateľov v reálnom svete.

Správa testovacích dát (TDM) je proces, ktorý je založený na analýze výziev a zavádzaní a uplatňovaní najlepších nástrojov a metód na správne riešenie identifikovaných problémov bez toho, aby bola ohrozená spoľahlivosť a úplné pokrytie konečného produktu (produktu).

Vždy musíme prísť s otázkami ohľadom hľadania inovatívnych a nákladovo efektívnych metód analýzy a výberu metód testovania vrátane použitia nástrojov na generovanie údajov. Je všeobecne dokázané, že dobre navrhnuté údaje nám umožňujú identifikovať chyby testovanej aplikácie v každej fáze viacfázového SDLC.

Musíme byť kreatívni a zúčastňovať sa všetkých členov v našom agilnom tíme i mimo neho. Podeľte sa o svoje pripomienky, skúsenosti, otázky a komentáre, aby sme mohli pokračovať v našich technických diskusiách a maximalizovať tak náš pozitívny vplyv na AUT spravovaním údajov.

Príprava správnych údajov o teste je kľúčovou súčasťou „nastavenia testovacieho prostredia projektu“. Nemôžeme jednoducho prehliadnuť testovací prípad, ktorý hovorí, že na testovanie neboli k dispozícii úplné údaje. Tester by mal k svojim existujúcim štandardným výrobným údajom vytvárať svoje vlastné údaje o skúškach. Váš súbor údajov by mal byť ideálny z hľadiska nákladov a času.

Buďte kreatívni, používajte svoje vlastné schopnosti a úsudky na vytváranie rôznych súborov údajov namiesto toho, aby ste sa spoliehali na štandardné produkčné údaje.

Časť II - Druhá časť tohto tutoriálu je na webe „ Vyskúšajte generovanie údajov pomocou online nástroja GEDIS Studio “.

Stretli ste sa s problémom neúplných údajov o testovaní? Ako ste to zvládli? Podeľte sa so svojimi tipmi, skúsenosťami, komentármi a otázkami na ďalšie obohatenie tejto témy diskusie.

Odporúčané čítanie

• Výukový program na testovanie dátových skladov ETL (kompletný sprievodca)
• Čo je to testovanie mutácií: Návod s príkladmi
• Ako vykonať testovanie na základe údajov pomocou nástroja TestComplete
• Testovanie na základe dát alebo parametrizovanie pomocou Spock Framework
• 4 kroky k testovaniu Business Intelligence (BI): Ako testovať obchodné údaje
• Výukový program na testovanie objemu: Príklady a nástroje na testovanie objemu
• Vynikajúci spôsob testovania údajov pomocou technológií XML (biela kniha)
• Top 10 nástrojov na testovanie a overovanie štruktúrovaných údajov pre SEO